Subject: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt

From: [email-masked]
Date: Mon, 21 Mar 2016 07:21:12 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions of the IETF.

        Title           : Considerations regarding the correct use of EAP-Response/Identity
        Author          : Stefan Winter
	Filename        : draft-ietf-radext-populating-eapidentity-00.txt
	Pages           : 9
	Date            : 2016-03-21

Abstract:
   There are some subtle considerations for an EAP peer regarding the
   content of the EAP-Response/Identity packet when authenticating with
   EAP to an EAP server.  This document describes two such
   considerations and suggests workarounds to the associated problems.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-radext-populating-eapidentity/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-radext-populating-eapidentity-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Stefan Winter <[email-masked]>
Date: Mon, 21 Mar 2016 15:29:11 +0100

Hi,

this draft is the follow-up of
draft-winter-radext-populating-eapidentity-01, which was adopted as a WG
item earlier.

The main change is the inclusion of a section "Taxonomy of identities in
EAP" which hopefully clears up the previous confusions over which
identity is used where. In particular, it makes clear that there are
identities (which identify a user) and there are outer identities (which
do not).

It also talks about how outer identities and EAP-Identity come to be;
that they are sometimes derived from inner identities and sometimes
explicitly configured. The core bits of it being:

EAP-Response/Identity is chosen from the set:

      *  all method-specific outer identities from all configured EAP
         types supporting the notion of an outer identity union

      *  all method-specific identities from all configured EAP types
         without the notion of an outer identity

and

Method-specific outer identities are either

      *  explicitly configured (e.g. string input UI: "Outer Identity")

      *  implicitly configured by copying the actual Method-specific
         (Inner) Identity

      *  implicitly configured by copying the NAI realm of the Method-
         specific (Inner) Identity and prefixing it non-configurably
         with a fixed privacy-preserving local username part like
         "anonymous" or the empty string (see [RFC7542])

      *  configured in a mixed way, e.g. using a explicit string input
         UI for the local part of the outer identity and combining it
         implicitly with a copy of the NAI realm part of the Method-
         specific (Inner) Identity

Please let me know if this makes things clearer.

Let's discuss the next steps for this draft at the meeting (I've
reserved 5 min).

Greetings,

Stefan Winter

Am 21.03.2016 um 15:21 schrieb [email-masked]:
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
> 

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Mar 2016 10:31:58 -0400

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

    Stefan> Please let me know if this makes things clearer.

It's more clear, but I'm not sure it's particularly related to reality.

Are there actually methods that have a concept of an outer identity as
you describe?

---

From: Stefan Winter <[email-masked]>
Date: Mon, 21 Mar 2016 15:42:39 +0100

Hi,

> Are there actually methods that have a concept of an outer identity as

I was thinking of PEAP and TTLS: there is an identity for Phase 1 (TLS
setup) and there is another in Phase 2 (inside the tunnel).

The phase 1 one being the outer; and that is the one used for
EAP-Response/Identity as well.

Both have implementations which allow to either configure the phase 1
identity explicitly or let the supplicant derive it (well, simply copy)
from the phase 2 identity.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Mar 2016 11:45:48 -0400

> identities (which identify a user) and there are outer identities (which

  I suggest referencing RFC 7542, and using it's nomenclature.  It refers to "identifiers", as they identify a user.  The strings isn't the user's "identity".  As acknowledged in that document, EAP still uses "identity".

  My $0.02 is to use the following terminology:

* user identifier - the NAI as per Section 1 of RFC 7542

* realm identifier - an NAI where the username portion is omitted, or is "anonymous"
  as per Section 2.4 of RFC 7542.

  That qualification makes it clear *why* the identifiers are different.  There's no "inner" and "outer" identities.  Just an identifier which says "authentication is related to realm X".  Realm X is then capable of authenticating the user, because it has a user identifier.

  I think the document also needs a recommendation that all EAP identities SHOULD use the NAI format.  All new EAP methods SHOULD use UTF-8 for identifiers.

  I'd like to make those a MUST, but realistically, we can't.

>      *  implicitly configured by copying the actual Method-specific

  Along with encoding issues.  e.g. EAP-MSCHAPv2 uses a method-specific identity which is not UTF-8.  Copying that field to an outer EAP-Identity is... problematic, to be polite.

>         "anonymous" or the empty string (see [RFC7542])

  I would call this the "realm" identifier.  And make it clear that the "outer" EAP-Identity SHOULD map to the "realm identifier", but it doesn't always... which is why we give them different names.

> Please let me know if this makes things clearer.

  Any attempt to make this clearer is better than the mess we have now.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Mar 2016 12:09:56 -0400

I am really sad to read this discussion.
Unfortunately, I'm moving away from the IETF, and I am not going to have
the energy to participate in this, but I think we're going to make a
huge mess with this approach.

Here are some issues I don't think this captures very well.

1) It's not clear to me that in implementations the phase1/outer
identity is really part of a method, so much as part of the EAP stack.
At least in TTLS, I don't think the outer identity is ever actually
carried in the method payloads, so I'm not actually sure that as a
matter of protocol it is a method concept, even if it is carried in
method-specific data structures in some implementations.

2) Alan's proposal to use NAI for method identifiers is tempting but
seems like a really bad idea to me.  It depends a lot of the underlying
authentication technology.  Trying to shove an X.500 subject, a Kerberos
principal, or whatever a concrete implementation of an OAUTH-based EAP
method would use into NAI seems like a really bad idea, no matter how
convenient it would be for a RADIUS implementation.

I'm hoping that someone who will be involved in the working group on an
ongoing basis shares my concerns and is willing to champion them.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Mar 2016 12:15:55 -0400

Hmm, thinknig more.

Alan's approach addresses most of my concern.
If rather than saying SHOULD use NAI for method identifiers, we could
say something like SHOULD use NAI if the method's architecture does not
empose some other namespace, I'd be reasonably happy.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Mar 2016 12:20:57 -0400

> huge mess with this approach.

  It's EAP and RADIUS.  It's already a huge mess.  I'd like to have recommendations for implementors and EAP method designers which aren't "make the mess worse".

> identity is really part of a method, so much as part of the EAP stack.

  I agree.  This should be made clearer.

  i.e. due to the issues you raise below in (2), the outer identifier is likely NOT method specific, and SHOULD be taken from configuration, not from the method.

> method-specific data structures in some implementations.

  The outer identity is usually derived from the inner identity.

> seems like a really bad idea to me.

  I agree.

>  It depends a lot of the underlying

  I agree completely.

  RADIUS has much the same problem as EAP here.  The identity and much of the authentication credentials are taken from an external source, and RADIUS / EAP restrictions don't apply to them.

  The recommendation to use the NAI is really a plea of "PLEASE, whatever you do, DON'T invent a new user identifier.  Use the NAI".

  The rules should be:

- outer identity == realm identifier, and SHOULD be taken from configuration.  It SHOULD NOT be taken from the inner method, as there is no guarantee that the inner identity is even UTF-8

- inner method identity SHOULD be the NAI for new EAP methods, and where permitted by existing EAP methods

- inner method identity SHOULD otherwise be taken from the existing EAP method, which is likely NOT UTF-8

> ongoing basis shares my concerns and is willing to champion them.

  I'll be sad to see you go, and will do my best to champion your views.

  Alan DeKok.

---

From: <[email-masked]>
Date: Mon, 21 Mar 2016 16:24:11 +0000

Hi,

in principles, I agree with Alan's approach (rely on RFC 7542) and with the generic guidelines "all EAP identities SHOULD use the NAI format". This gives a clear framework without forbidding exceptions to this rule but with the potential related issue(s) not to follow the recommended rule.

regards,

Lionel

> -----Message d'origine-----
> De : radext [mailto:[email-masked]] De la part de Sam Hartman
> Envoyé : lundi 21 mars 2016 17:16
> À : Alan DeKok
> Cc : Winter Stefan; [email-masked]
> Objet : Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-
> 00.txt
> 
> Hmm, thinknig more.
> 
> If rather than saying SHOULD use NAI for method identifiers, we could say
> something like SHOULD use NAI if the method's architecture does not

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Stefan Winter <[email-masked]>
Date: Tue, 22 Mar 2016 08:57:04 +0100

Hello Sam,

> method-specific data structures in some implementations.

It really depends on the point of view, I think. Those outer IDs can be
configured per method, and they are dependent on the inner ID of "their"
method - they need to have a routing component which matches the inner
ID so that the request terminates at the correct EAP server.

That makes one outer ID specific to exactly one method, hence my calling
it method-specific.

It's true that they are not actually used inside the EAP method's
payload on the wire; they are rather an abstract property of the EAP
method that is solely used to populate the choice of candidates for
EAP-Response/Identity and for transmission before the actual EAP method
payload is underway.

Formulation suggestions warmly welcome.

> convenient it would be for a RADIUS implementation.

Yes, I don't like that either; the NAI is a good choice if you have a
choice - but there are situations where you don't. I think the later
points made in the thread provide a clear insight here: SHOULD, unless
your method architecture demands otherwise.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Tue, 22 Mar 2016 09:38:43 -0400

> ID so that the request terminates at the correct EAP server.

  Define "matches".  i.e. how UTF-8 identifiers can be "matched" to identifiers in other character sets.

  It's not easy.

  My $0.02 is that we have to be very careful about terminology here.  And make it clear in the document *why* we're being clear on terminology.

> Formulation suggestions warmly welcome.

  I like my distinction between the "realm identifier" and "user identifier".  The "user identifier" can be method specific, but SHOULD be the NAI.  The "realm identifier" MUST be an NAI with no user name portion, or a user name of "anonymous".

  That avoids any "inner" and "outer" discussion, which is also method-specific.

  i.e. an EAP method has a "user identifier" which is placed into a method-specific identity field.  An EAP method also has a "realm identifier", which identifies the realm for which the EAP method is relevant.  Where the EAP method has "inner" and "outer" identities, the realm identifier MUST be used for the outer identity, and the user identifier MUST be used for the inner identity.

  When we re-euse existing terminology for these identifiers, we have to explain in each case why the EAP-Identity here is not, in fact the same as the EAP-Identity in another situation... even though they have the same name.  That's confusing.

> your method architecture demands otherwise.

  And where there are inner/outer identities, the outer identity / realm identifier MUST be an NAI.

  Alan DeKok.