RE: [RFC2486bis] Issue 42: Definition of "Privacy"

[<Pasi.Eronen@nokia.com>]

Bernard Aboba wrote:

> Sent: Friday, December 17, 2004 9:42 AM
> To: radiusext@ops.ietf.org
> Subject: [RFC2486bis] Issue 42: Definition of "Privacy"
> 
> 
> Issue 42: Definition of "Privacy"
> Submitter name: Bernard Aboba
> Submitter email address: aboba@internaut.com
> Date first submitted: December 16, 2004
> Reference:
> Document: RFC2486bis-03
> Comment type: T
> Priority: S
> Section: 2.3
> Rationale/Explanation of issue:
> 
> The Abstract of this document states:
> 
> "Enhancements include international character set and
> privacy support"
> 
> However, Section 2.3 does not explicitly state what a privacy 
> NAI looks like, only that the "username" portion of the NAI 
> SHOULD be treated as opaque and that the NAI MAY be provided in 
> abbreviated form.
> 
> This has the potential to result in interoperability 
> problems, since some implementations will embue userids such 
> as "anonymous" with special properties, while others will not.  
> It also makes it difficult for specifications such as CUI to 
> define when "Privacy" is being requested.

Hmm... privacy is not a on/off feature, and I don't think this
document should treat it as such. For instance, you can use
pseudonyms (either one-time or at least changed frequently)
to provide better privacy than just sending the long-term
identifier, and CUI would be useful in such cases, too.

> Suggested fix:
> 
> In Section 2.3, change:
> 
> "  Interpretation of the "username" part of the NAI depends 
>    on the realmin question.  Therefore, the "username" part 
>    SHOULD be treated as opaque data when processed by nodes that 
>    are not a part of the authoritative domain (in the sense of 
>    Section 4) for that realm.
> 
>    Where privacy is a concern, NAIs MAY be provided in an 
>    abbreviated form by omitting the username portion.  This 
>    is possible only when NAIs are used together with a 
>    separate authentication method that can transfer the 
>    username in a secure manner."
> 
> To:
> 
> "  Interpretation of the "username" part of the NAI depends 
>    on the realm in question.  Therefore, the "username" part 
>    SHOULD be treated as opaque data when processed by nodes that 
>    are not a part of the authoritative domain (in the sense of 
>    Section 4) for that realm.
> 
>    Where it is desired that the username portion of the NAI 
>    not be sent in the clear, an authentication method that 
>    encrypts the NAI MUST be used, along with the "privacy" 
>    NAI format, which omits the "username" portion entirely.  
>    Note that since the "username" part of the NAI is considered 
>    an opaque blob, if this is included, there is no way for
>    nodes not part of the authoritative domain to determine
>    that "privacy" is desired.

How about this?

   "In some situations NAIs are are used together with a
   separate authentication method that can transfer the username
   part in a more secure manner to increase privacy.  In this
   case, NAIs MAY be provided in an abbreviated form by omitting
   the username part.  Omitting the username part is RECOMMENDED
   over using a fixed username part, such as "anonymous", since
   it provides an unambiguous way to determine whether the
   username is intended to uniquely identify a single user."

Best regards,
Pasi

--
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/>