[RFC2486bis] Issue 42: Definition of "Privacy"

[Bernard Aboba <aboba@internaut.com>]

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.

Suggested fix:

In Section 2.3, change:

"  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 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.


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