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

[Alan DeKok <[e-mail]>]

On Dec 2, 2014, at 4:11 PM, Alissa Cooper <[e-mail]> 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.