Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-nai-11: (with DISCUSS and COMMENT)

From: Alan DeKok <[email-masked]>
Date: Tue, 2 Dec 2014 16:50:43 -0500

On Dec 2, 2014, at 4:11 PM, Alissa Cooper <[email-masked]> wrote:
> This document seems to confuse an identifier format with an identifier,
> and I'd like to discuss that.

  The document defines an identifier format, and then describes how to use a well-known format to get one identity across multiple protocols.

> In my reading, all this document specifies is an identifier format and
> length, plus some processing rules for use by AAA systems. It does not
> specify the particular contents of the identifier for any specific
> protocol or usage, nor does it specify any semantic rules for the
> construction of such identifiers (e.g., "the same user should always use
> the same identifier”).

  It specifies that the contents of the identifier are:

	<thing you define>@your.domain.name

  The domain name has a well-known content, and is defined by the DNS registry.  The “username” portion is under the control of each domain.  We can’t control how people allocate or manage identifiers in their own namespace.

  We *can* require that the identifiers be *recognizable* as identifiers.

> However, the document repeatedly makes the case -- in sections 1, 1.3,
> 2.1, 2.7, 2.8 -- that "the NAI" (whether the actual identifier or the
> format, it's not clear) should be the universal identifier of choice for
> all situations and protocols, because it "simplifie[s] the management of
> credentials," allows other protocols to "leverage AAA for user
> authentication," removes the need to "maintain multiple identifiers for
> one user," etc. The claims in all of these sections seem to conflate a
> single user's use of the same identifier with a single user's use of the
> same identifier *format*. I thought what is being defined in this
> document is a format and nothing more.

  I’m wondering how we can define an identifier format without also discussing when / where it’s used.  In addition, people are *already* using one identifier in multiple protocols.  How many systems require a login identifier to be an email address?

  This document doesn’t change current practice.  It codifies it, and explains *why* the practice is useful.

  Section 2.8 makes it clear that the NAI format can be used for multiple identifiers.  There is no requirement that a user has one, and only one, identifier.

> I'm perfectly fine with encouraging the use of a standard format across
> protocols and applications (although I still don't see the need to repeat
> the same recommendation over and over again in the document). That has
> basically happened already in lots of places.
> 
> I'm not fine at all with a blanket recommendation to use a single
> identifier for the same user everywhere.

  The document doesn’t recommend the use of a “universal” identifier.  The Introduction explains the historical practice behind re-using identifiers:

When the NAI was defined for network access, it had the side effect of
defining an identifier which could be used in non-AAA systems.  Some
non-AAA systems defined identifiers which were compatible with the
NAI, and deployments used the NAI.  This process simplified the
management of credentials, by re-using the same credential in multiple
situations.

  This document in no way *requires* each user to have only one identifier.  Instead, it suggests that if you want to use one “identifier” to identify a user across multiple protocols (as is widely one today), then that identifier must follow a standard format, and should be detectable as the same identifier.

> The ability to authenticate to
> different services (and even to different networks!) using different
> identities is a fundamental building block for privacy on the Internet.
> The message from this document seems to be that we should erase that
> protection.

  I disagree completely.  I can add text to clarify that if necessary.

  The document in no way forbids the use of multiple identifiers for one user.  Section 2.8 explicitly allows such practice:

   It is often useful to create new identifiers for use in specific
   contexts.

 Which seems clear to me.

> I note that although the stated motivation for this document relates to
> internationalization, pretty much all of the text recommending One
> Identifier to Rule Them All is new. So perhaps there were multiple
> motivations for this document update?

  The stated motivations of the document are the real ones.  There is no underhanded motivation to remove internet privacy.

  Such insinuations are… odd, to be polite.

> I could offer a bunch of detailed text suggestions, but first I'd like to
> understand what this document is actually trying to do, and whether the
> term "the NAI" is meant to refer to an identifier or an identifier
> format. 

  The stated motivations of the document are the overt (and covert) intentions of the document.

  To fix errors in RFC 4282.  To codify existing practices.  To suggest that use of standard formats is better than ad hoc formats.

> = Section 2.4 =
> "Therefore, the utf8-username portion 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."
> 
> What does it mean to treat a cleartext username as opaque data? Should
> the nodes outside the realm not log these usernames, or not process them
> in any way?

  Nodes outside of the realm are free to log anything they wish.  The text is simply a statement that the only *interpretation* of the “username” portion is… that it is a username.  It cannot (with any confidence) be subdivided into fields, or to be interpreted as the name if a person (it may be only digits).

> "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."
> 
> I don't understand why this is true, other than by convention. If I
> process a bunch of authentication transactions that use "@example.com" as
> the NAI, how am I supposed to know that each of those was intended to
> identify a single user? Is the usage of an NAI to authenticate a group of
> users discussed somewhere?

  The intent was to discuss EAP methods such as PEAP or TTLS.  They provide for an opaque outer identity: “anonymous@realm”, or simply “@realm”.  The only purpose of that identity is to allow intermediate nodes to *route* the traffic.

  The home node will terminate the EAP / TLS tunnel, and decode the inner data.  That data will contain an NAI which will identify one user to be authenticated.

> In general, I'm uncomfortable with the approach this document takes of
> making a few notes about how the username part could be constructed
> without providing a more thorough analysis of threats and mitigations
> related to identifiability, uniqueness and persistence.

  Allocation of usernames is something best managed by organizations, using practices specific to that organization.  I see no feasible way that the IETF can mandate internal organizational behaviour.  All we can do is recommend that the *publicly* visible portions of the identifier are anonymous.

  See my suggested text (response to Barry) for details.  If the public face of the NAI is simple “@realm”, then there are *no* IETF activities related to username identifiability, uniqueness, and persistence.

> This also comes
> up with the example in Section 2.8, where uniqueness is discussed in the
> context of the example, but there is no generalized discussion about
> uniqueness in identifier construction.

  I fail to see why uniqueness is a consideration.  It is perfectly valid for an organization to re-use the same identifier for multiple users across time.  Or even to simultaneously use the same identifier for multiple users, with (say) different passwords.

  The issues of internal organizational management of identifiers is *completely* outside of the scope of this document.  This document simply specifies the format of an NAI, and how organizations can exchange data which is associated with a particular NAI.

> This might get back to my larger
> point above about format versus content -- if this document is just
> specifying a format, it probably shouldn't be commenting on the
> identifier content

  It’s not.  The text in 2.8 is an example of how organizations can use the NAI.  It doesn’t *require* organizations to have any particular content in the “username” portion.

> or the consequences of it (although being able to omit
> the username part is certainly a format issue).

  Only in that there’s a requirement that the username portion be omitted, and that requirement affects the format.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> = Section 1 =
> Is dial-up really a prevalent use case to be highlighting first here? If
> we're going to obsolete an old document, it's worth making it current.

  That text is largely left over from RFC 4282.   People still use dial-up.

> Similarly, I wonder how current this text is in Section 1.3?
> 
> "As described in [RFC2194], there are a number of providers offering
>   network access services, and the number of Internet Service Providers
>   involved in roaming consortia is increasing rapidly.”

  Perhaps that could say:

   As described in [RFC2194], there are a number of providers offering
   network access services, and essentially all Internet Service Providers
   are involved in roaming consortia.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 3 Dec 2014 16:11:04 -0800

Hi Alan,

Thanks. I think I have a little more clarity now, so I’ll try to make some suggestions that are in line with your responses. It seems that “NAI” is used interchangeably to describe both the format and a specific use of an identifier, so a lot of my suggestions aim to increase the clarity about the distinction between the two.

= Section 1 =
s/a standardized method for identifying users/a standardized user identifier format/

OLD
   We suggest that this re-use is good practice,
   so long as privacy issues are dealt with.  The alternative is to have
   protocol-specific identifiers, which increases cost to both the user
   and the administrator.

NEW
Protocols that re-use the same credential or the same identifier format can benefit from this management simplicity. The alternative is to have protocol-specific credentials or identifier formats, which increases cost to both the user and the administrator.

[If protocols require credential re-use, I’m not sure what it means for the privacy issues to be dealt with.]

OLD
We hope to encourage the wide-spread adoption of the NAI as an identifier. This adoption will decrease work required to leverage identification and authentication in other protocols.

NEW
We hope to encourage the wide-spread adoption of the NAI format. This adoption can help decrease work required to leverage identification and authentication across protocols.

s/only suggest that the NAI be used/only suggest that the NAI format be used/

= Section 1.3 =
s/can take advantage of the NAI/can take advantage of the NAI format/

s/definition of a user identifier/definition of a user identifier format/

s/It is hoped that the NAI is a user identifier/It is hoped that the NAI is a user identifier format/

s/identifier is itself kept private/identifier is itself protected against unauthorized access/
[wasn’t sure what was meant by “kept private”]

= Section 1.4 =
I would suggest that either the title of this section be changed to “Motivation Related to Internationalization Concerns” or the following text (based on your response below) be added to the final paragraph in the section:

Furthermore, this document was motivated by a desire to codify existing practice related to the use of the NAI format and to encourage widespread use of the format.

= Section 2.1 =
s/which is a user identifier/which is a user identifier format/

= Section 2.4 =
Thanks for the new text here, it’s very helpful. 

OLD
since it provides an unambiguous way to
   determine whether the username is intended to uniquely identify a
   single user.

NEW
since including a fixed username part is ambiguous as to whether the NAI refers to a single user or not.

s/use-case of such behavior/use case of omitting or obfuscating the username part/

s/user privacy is preserved/the username part is kept confidential from the visited network/

= Section 2.7 =
s/the NAI MAY be used in other/the NAI format MAY be used in other/

OLD
   It is RECOMMENDED that protocols requiring the use of
   a user identifier reference this specification, and suggest that the
   use of an NAI is RECOMMENDED.

NEW
  It is RECOMMENDED that protocols requiring the use of
   a user identifier use the NAI format.

[ISTM that some protocols will have the specific identifier format as REQUIRED, so it seems awkward to suggest that they all make it a RECOMMENDED.]

s/to use the NAI/to use the NAI format/

s/This format ensures/The format as defined by 3GPP ensures/

"It is RECOMMENDED that methods similar to that described above for 3GPP be
   used to derive the identifier.”

>  It’s not.  The text in 2.8 is an example of how organizations can use the NAI.  It doesn’t *require* organizations to have any particular content in the “username” portion.

If the 3GPP example is just an example, why is there a recommendation that identifiers used in all new specifications and protocols be constructed according to the same methods used to construct the 3GPP identifiers (including the requirement that the username part be in a well-known format)?

= Section 3 =
s/similar in format to the NAI/similar in format to the NAI format/

= Section 4 = 
The new text is very helpful, thanks.

= Section 4.2 =
It seems that the problem described here is not one of using multiple identifier formats, but using multiple identifiers. So it seems slightly different from what was described in 1.3.

Best,
Alissa

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 3 Dec 2014 20:03:41 -0500

Forwarding for Alyssa, she is having some trouble with email to [email-masked].

---------- Forwarded message ----------
From: Alissa Cooper <[email-masked]>
Date: Wed, Dec 3, 2014 at 8:01 PM
Subject: Fwd: Alissa Cooper's Discuss on draft-ietf-radext-nai-11:
(with DISCUSS and COMMENT)
To: Kathleen Moriarty <[email-masked]>

Begin forwarded message:

From: Alissa Cooper <[email-masked]>
Subject: Re: Alissa Cooper's Discuss on draft-ietf-radext-nai-11:
(with DISCUSS and COMMENT)
Date: December 3, 2014 at 4:11:04 PM PST
To: Alan DeKok <[email-masked]>
Cc: IESG <[email-masked]>, [email-masked],
[email-masked], [email-masked]

Hi Alan,

Thanks. I think I have a little more clarity now, so I’ll try to make
some suggestions that are in line with your responses. It seems that
“NAI” is used interchangeably to describe both the format and a
specific use of an identifier, so a lot of my suggestions aim to
increase the clarity about the distinction between the two.

= Section 1 =
s/a standardized method for identifying users/a standardized user
identifier format/

OLD

NEW
Protocols that re-use the same credential or the same identifier
format can benefit from this management simplicity. The alternative is
to have protocol-specific credentials or identifier formats, which
increases cost to both the user and the administrator.

[If protocols require credential re-use, I’m not sure what it means
for the privacy issues to be dealt with.]

OLD
We hope to encourage the wide-spread adoption of the NAI as an
identifier. This adoption will decrease work required to leverage
identification and authentication in other protocols.

NEW
We hope to encourage the wide-spread adoption of the NAI format. This
adoption can help decrease work required to leverage identification
and authentication across protocols.

= Section 1.3 =

s/It is hoped that the NAI is a user identifier/It is hoped that the
NAI is a user identifier format/

s/identifier is itself kept private/identifier is itself protected
against unauthorized access/
[wasn’t sure what was meant by “kept private”]

= Section 1.4 =
I would suggest that either the title of this section be changed to
“Motivation Related to Internationalization Concerns” or the following
text (based on your response below) be added to the final paragraph in
the section:

Furthermore, this document was motivated by a desire to codify
existing practice related to the use of the NAI format and to
encourage widespread use of the format.

= Section 2.1 =

= Section 2.4 =

OLD

NEW
since including a fixed username part is ambiguous as to whether the
NAI refers to a single user or not.

s/use-case of such behavior/use case of omitting or obfuscating the
username part/

s/user privacy is preserved/the username part is kept confidential
from the visited network/

= Section 2.7 =

OLD

NEW

[ISTM that some protocols will have the specific identifier format as
REQUIRED, so it seems awkward to suggest that they all make it a
RECOMMENDED.]

This also comes

I fail to see why uniqueness is a consideration.  It is perfectly
valid for an organization to re-use the same identifier for multiple
users across time.  Or even to simultaneously use the same identifier
for multiple users, with (say) different passwords.

The issues of internal organizational management of identifiers is
*completely* outside of the scope of this document.  This document
simply specifies the format of an NAI, and how organizations can
exchange data which is associated with a particular NAI.

It’s not.  The text in 2.8 is an example of how organizations can use
the NAI.  It doesn’t *require* organizations to have any particular
content in the “username” portion.

If the 3GPP example is just an example, why is there a recommendation
that identifiers used in all new specifications and protocols be
constructed according to the same methods used to construct the 3GPP
identifiers (including the requirement that the username part be in a
well-known format)?

= Section 3 =

= Section 4 =

= Section 4.2 =
It seems that the problem described here is not one of using multiple
identifier formats, but using multiple identifiers. So it seems
slightly different from what was described in 1.3.

Best,
Alissa

The document defines an identifier format, and then describes how to
use a well-known format to get one identity across multiple protocols.

The domain name has a well-known content, and is defined by the DNS
registry.  The “username” portion is under the control of each domain.
We can’t control how people allocate or manage identifiers in their
own namespace.

I’m wondering how we can define an identifier format without also
discussing when / where it’s used.  In addition, people are *already*
using one identifier in multiple protocols.  How many systems require
a login identifier to be an email address?

This document doesn’t change current practice.  It codifies it, and
explains *why* the practice is useful.

Section 2.8 makes it clear that the NAI format can be used for
multiple identifiers.  There is no requirement that a user has one,
and only one, identifier.

The document doesn’t recommend the use of a “universal” identifier.
The Introduction explains the historical practice behind re-using
identifiers:

This document in no way *requires* each user to have only one
identifier.  Instead, it suggests that if you want to use one
“identifier” to identify a user across multiple protocols (as is
widely one today), then that identifier must follow a standard format,
and should be detectable as the same identifier.

The document in no way forbids the use of multiple identifiers for one
user.  Section 2.8 explicitly allows such practice:

Which seems clear to me.

The stated motivations of the document are the real ones.  There is no
underhanded motivation to remove internet privacy.

The stated motivations of the document are the overt (and covert)
intentions of the document.

To fix errors in RFC 4282.  To codify existing practices.  To suggest
that use of standard formats is better than ad hoc formats.

The intent was to discuss EAP methods such as PEAP or TTLS.  They
provide for an opaque outer identity: “anonymous@realm”, or simply
“@realm”.  The only purpose of that identity is to allow intermediate
nodes to *route* the traffic.

The home node will terminate the EAP / TLS tunnel, and decode the
inner data.  That data will contain an NAI which will identify one
user to be authenticated.

Allocation of usernames is something best managed by organizations,
using practices specific to that organization.  I see no feasible way
that the IETF can mandate internal organizational behaviour.  All we
can do is recommend that the *publicly* visible portions of the
identifier are anonymous.

See my suggested text (response to Barry) for details.  If the public
face of the NAI is simple “@realm”, then there are *no* IETF
activities related to username identifiability, uniqueness, and
persistence.

Only in that there’s a requirement that the username portion be
omitted, and that requirement affects the format.

= Section 1 =

Perhaps that could say:

-- 

Best regards,
Kathleen

---

From: Benoit Claise <[email-masked]>
Date: Thu, 04 Dec 2014 12:38:13 +0100

Thanks Alissa for the suggestions.
This clarifies the document.

Regards, Benoit

> .