RE: comments on draft-adrangi-radius-attributes-extension-00.tx

["Adrangi, Farid" <farid.adrangi@intel.com>]

Hi Jari,
Thanks again for your thorough review and detailed comments.   I will
update the document according to your comments/proposed text.
CapExchange is currently discussed on a different thread - please see my
response for the remaining inline.  
BR,
Farid


> >    2.1 RADIUS Support for Specifying User Alias Identity 
> >     
> >       Rationale 
> >         In certain authentication methods such as, EAP-PEAP or EAP-
> >         TTLS, the true identity of the subscriber is hidden 
> from the 
> >         RADIUS AAA infrastructure.  In these methods the 
> User-name(1) 
> >         attribute contains an anonymous identity sufficient 
> to route 
> >         the RADIUS packets to the home network but otherwise 
> >         insufficient to identify the subscriber.  While 
> this mechanism 
> >         is good practice there are situations where this creates 
> >         problems.  For example, in certain roaming situations 
> >         intermediaries and visited network require to be able to 
> >         correlate an authentication session with a user 
> identity;  A 
> >         broker may require to implement a policy where by 
> only session 
> >         is allowed per user entity.  Third party billing 
> brokers may 
> >         require to match accounting records to a user identity. 
> >          
> >         The User Identity Alias provides a solution to the above 
> >         problem.  When the home network assigns a value to the User 
> >         Identity Alias it asserts that this value 
> represents a user in 
> >         the home network.  The assertion should be temporary.  Long 
> >         enough to be useful for the external applications 
> and not too 
> >         long to such that it can be used to identify the user. 
> 
> Here's what RFC 3579 says: "The User-Name attribute within the Access-
> Accept packet need not be the same as the User-Name attribute in the
> Access-Request."
> 
> I wonder if this could be used to implement the functionality that
> you want, without adding a new attribute. But you could still
> include the explanation of the problem and guidelines for the
> servers.
> 
Good question.  We had a long discussion on this subject amongst GSMA
delegates.  In summary, the decision was made not to use UserName(1)
rewrite because:

1) Some NASes may not like user-name rewriting
2) Need for a structured identity for indicating user's chargeable
identity
3) Avoid overloading the UserName(1) attribute for this purpose

> >      When the home network assigns a value to the User 
> >      Identity Alias it asserts that this value represents a user in 
> >      the home network.  The assertion should be temporary.  Long 
> >      enough to be useful for the external applications and not too 
> >      long to such that it can be used to identify the user. 
> 
> (snip)
> 
> >         00   reserved 
> >         01   IMSI 
> >         02   NAI 
> >         03   E.164 number 
> >         04   SIP URL (as defined in [13]) 
> >         05   Opaque string 
> 
> I find the first statement and types 1, 3, and 4
> contradictory. This appears to be another reason why
> the RFC 3579 approach might be better. Alternatively,
> define the opaque string case only.
> 

The options here do not have to reveal the actual identity of the user
-- for example, for IMSI, pseudonym IMSI can be used. 
 

> (Type 2 is problematic too if not constructed the right way.)
> 


> >         A RADIUS server MUST NOT include this attribute in 
> the Access-
> >         Accept if the IP Address Type options were not 
> advertised in 
> 
> Why? Seems like this adds a rule to the server side, but
> sending an attribute which the NAS will ignore does not
> seem to harm anyone. Or am I missing something?

I see your point.  Would that be okay if I change "MUST NOT" to "SHOULD
NOT"?
> 
> >         the Access-Request.  If an invalid IP Address Type 
> option is 
> >         received in the Access-Accept, then the AN MUST use 
> its default 
> >         IP Address Type option for the client.  Otherwise, 
> 
> In the other document an invalid attribute resulted in an
> Access-Reject. Why is this different?

Good point!  In the other draft, if an invalid attribute is received,
the NAS rejects/discards the packet.  It makes sense to do the same
thing here.

> 
> >         assign an IP address according to the specified 
> type option.  
> >         In either case it MUST include this attribute in Accounting-
> >         Request packets to indicate the used IP address 
> type option.  
> 
> Which one? The one that the server sent, or the one that the NAS
> chose?

The one that server sent.  You are right - I should be more specific
about it.

> 
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
> 6 7 8 9 0 1 
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >       |     Type      |    Length     |IP Address Type| 
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >   
> (snip)
> >         Length 
> >          
> >           1 
> 
> This does not seem to match the usual (?) RADIUS style
> where integer/enumerated attributes have a 32-bit
> integer.

Will fix it.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>