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

From: Stefan Winter <[email-masked]>
Date: Mon, 4 Apr 2016 09:25:44 -0300

Hi,

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

That nomenclature change is fine for me. I'll update the document with
that in the next rev.

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

Why? In IETF91 Bernard Aboba was in the room and he actually suggested
we do exactly that: EAP-Response/Identity should have been UTF-8 ever
since, and not doing that was a mistake - so better to fix it late than
never.

We are on BCP track and probably we'll have an Updates: relationship
with RFC3748 anyway. So it's not impossible to do it. Let's discuss this
in the room on Friday.

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

Yes, it's one of the purposes of the document to raise the awareness
that a copy (without caring about encodings) is a very bad idea.

The text meant to state (but it may have come across differently):
inside your supplicant, you can copy around and store the config in any
encoding you like. Only when you actually put the string onto the wire
(i.e. use it to construct an EAP-Response/Identity) then you need to
convert to UTF-8.

This means that "what happens in the supplicant stays in the supplicant"
- we are only imposing a rule on its outside obervable behaviour. This
puts the gentlest-possible requirement on the supplicant: use whatever
encodings you are most comfortable with locally - just be aware what
that encoding is so that you can convert it to UTF-8 when you need it.

>>      *  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])
>   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.

I'll try to reformulate in the next rev. If you don't like the result,
text suggestions will be welcome :-)
>
>> Please let me know if this makes things clearer.
>   Any attempt to make this clearer is better than the mess we have now.

Good, that sets a low bar :-)

Stefan

>
>   Alan DeKok.
>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Stefan Winter <[email-masked]>
Date: Mon, 4 Apr 2016 09:52:08 -0300

Hi,

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

There is a string A for the realm identifier.
There is a string B for the user identifier in a given EAP method.

There is a dependency between the two: A must be chosen so that the EAP
method which uses B will actually reach an EAP server which is prepared
to handle B.

If "match" is not a good choice of word, maybe "dependency between" is?

The consequence, no matter the chosen word, is: when multiple EAP
methods are configured (there are multiple instances of B) then there
may need to be more than instance of A as well.

Point taken: A is not part of the EAP method payload. But it needs to
exist, and be available for transmission, and there has to be a
possibility to configure more than one instance of A, depending on which
B is tried in the method. Many UIs pack the A string into the
configuration items for the EAP method around B. Granted, that's not the
conceptually the cleanest place, but it's a viable choice (but we don't
mind UI anyway).

There is not necessarily a 1:1 relationship (multiple instances of B
might share a common A) but there is an n:m relationship with n < m.

That's as close to a definition I get right now.

>> 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.
>   I like my distinction between the "realm identifier" and "user identifier".  The "user identifier" can be method specific, but SHOULD be the NAI. 

I think the discussion with Sam has gotten to a point where the
following was agreed:

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

>  The "realm identifier" MUST be an NAI with no user name portion, or a user name of "anonymous".

Well the empty string is a good suggestion, but why is "anonymous"
better than "someone", "wonttell", "secret" or "streng-geheim"? Is there
any specific reason why we should put strong wording around one
particular English string? An EAP server operator here in Buenos Aires
might want "anonimico" or so :-)

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

Yes, point taken. Terminology update pending.

>> 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.
>   And where there are inner/outer identities, the outer identity / realm identifier MUST be an NAI.

Here again I think we discussed that a MUST is too much. It would be
more like a SHOULD, unless local requirements mandate otherwise. I
believe we shold acknowledge and accomodate the reality of DOMAIN/user
in some places out there.

Greetings,

Stefan Winter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 4 Apr 2016 09:00:18 -0400

> since, and not doing that was a mistake - so better to fix it late than

  I'm OK with that.

> (i.e. use it to construct an EAP-Response/Identity) then you need to

  That makes sense.

> that encoding is so that you can convert it to UTF-8 when you need it.

  I can only hope that supplicant vendors read, understand, and update.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 4 Apr 2016 09:08:27 -0400

> If "match" is not a good choice of word, maybe "dependency between" is?

  Yes.  "Match" implies string comparison.  Which doesn't work for UTF-8 to non-UTF-8 strings.

  If both strings are UTF-8, then in general, A will be a subset of B.  However, one realm MAY have multiple user identifier spaces.  This is because the realm identifier will identify an organization, and the user identifier may identity a subset of that organization.

  e.g. "example.com" may have users "[email-masked]", "[email-masked]", and "[email-masked]" (if .com bought .org)

> may need to be more than instance of A as well.

  Yes.  Getting the dependency here is critical.  My thoughts are that the key should be the user identifier.  When authenticating user X, realm Y and EAP method E must be used.

> might share a common A) but there is an n:m relationship with n < m.

  Yes.  But that also means the dependency must be B -> A, not A -> B.

  If the dependency is B -> A, then multiple B's share an A, and it doesn't really matter, because no one can tell.

  If the dependency is A -> B, then when you choose A, you have no real idea which B to use.

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

  Yes.

> might want "anonimico" or so :-)

  The realm identifier SHOULD be "@realm".  "anonymous" is allowed by the NAI RFC for backwards compatibility, but is deprecated.

  "anonymous@" SHOULD NOT be used.

> in some places out there.

  I'm inclined to disagree.

  The realm identifier MUST be an NAI.  It's for public consumption.  The user identifier can have a different form, as it's usually buried inside of an inner-tunnel exchange.  Only the end user and home EAP server see it.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Tue, 5 Apr 2016 12:48:10 -0300

Hi,

good... we seem to be converging on most points!

>   e.g. "example.com" may have users "[email-masked]", "[email-masked]", and "[email-masked]" (if .com bought .org)

Yes. I'll make that clear in the next rev. It's why I wrote n < m is a
possibility. Multiple configured EAP methods with different user
identifiers may share a commonly usable realm identifier. This is where
EAP type negotiation can be of help. The worries in the I-D are mostly
about the cases where different realm idenfiers need to be used; then
they all need to be tried.

>   Yes.  Getting the dependency here is critical.  My thoughts are that the key should be the user identifier.  When authenticating user X, realm Y and EAP method E must be used.

The one thing that worries me here is that you introduce the new concept
of a "user"; and that you seem to imply that X -> E -> Y is a
deterministic choice.

While E -> is a clear "follows from" arrow, the X -> E is not: a user
(as in "human being") may have multiple credentials, and multiple
configured EAP types on his machine.

Say, I have a client certificate for EAP-TLS, a username/password for
EAP-TTLS and a SIM card for EAP-AKA'.

In that case, user X does not yield a unique choice for E. It is up to
the user's preference, or the network's acceptance of credential types
which one to use.

I'd prefer to leave the notion of a user out of the document. So far, we
are only talking about multiple EAP types which are configured on a
system. Whether they all relate to the same human being is not very
relevant. The choice of EAP method is largely out of the hands of the
user - he has all those types configured in the hope that one of them
gets him online. There may be a preference configured on the system, and
if yes, that should be honoured. But we can talk about the config item
"preference" without introducing the notion of a user.

>   If the dependency is A -> B, then when you choose A, you have no real idea which B to use.

This one is clear: of course you need to choose B first, and then use
the A that corresponds to this choice.

>   "anonymous@" SHOULD NOT be used.

Ok.

>   The realm identifier MUST be an NAI.  It's for public consumption.  The user identifier can have a different form, as it's usually buried inside of an inner-tunnel exchange.  Only the end user an…

Public consumption is a big word: EAP is often used within closed
enterprise environments. EAP methods may only travel to a single AAA/EAP
server without any choices in routing. In those cases, the form of the
realm identifier is irrelevant; all identifiers get routed along the
"one and only" default route.

I totally agree that the idenfiers really should be a NAI as soon as
roaming comes into play.

The wording "MUST" without the qualifier ... "in a roaming environment" (or "if the EAP session is sent to a different entity") is then too harsh. I'd be happy to add the MUST with that extra qualifier; and to leave closed enterprise EAP deployments alone.

Greetings,

Stefan Winter

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Apr 2016 17:23:32 -0400

> of a "user"; and that you seem to imply that X -> E -> Y is a

  "entity being authenticated", commonly user or device.

> EAP-TTLS and a SIM card for EAP-AKA'.

  All for the same realm and SSID?

  This is where it gets vague... there should only be one EAP configuration for a particular way of getting network access.

> the user's preference, or the network's acceptance of credential types

  I'd be wary of allowing multiple EAP configurations for one network access method.  It involves users, who we know make mistakes.

  Yes.

> "one and only" default route.

  What people do in their own networks is their own business.  But there is a definite overlap with public networks.

  If private enterprises are *at any point* interested in connecting their networks to a public infrastructure, they should be compatible with that infrastructure from day 1.  Migration from "internal" identifiers to "public" identifiers is a nightmare.

  i.e. there is no large benefit in using identifiers in an internal format.  Therefore, we recommend using ones which are compatible with public networks.

> I totally agree that the idenfiers really should be a NAI as soon as

  Even before.  Migration is  nightmare.  These people shouldn't think that they're smarter than everyone else on the planet.  They're not.  They should use NAIs, because it's the best thing we know.

> The wording "MUST" without the qualifier ... "in a roaming environment" (or "if the EAP session is sent to a different entity") is then too harsh. I'd be happy to add the MUST with that extra quali…

  Sure.

  And say that close enterprise deployments SHOULD use the NAI, for reasons outlined above.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Wed, 6 Apr 2016 18:56:10 -0300

Hi,

>   This is where it gets vague... there should only be one EAP configuration for a particular way of getting network access.

WI-Fi gets more complicated over time. Thinking in SSID only is not
future-proof :-/

Passpoint brought the new capability of identifying a joinable network
not by SSID, but by many other properties; for the sake of my argument
below let's look at the one which is a mobile operator's MCC/MNC code.

Assume there is a Wi-Fi network with an SSID "eduroam" and a Passpoint
MCC/MNC roaming code of 123/45.

Assume further that you have a PEAP credential for eduroam and a SIM
card of the 123/45 operator.

The device now sees the network, and realises that it can join with PEAP
because the SSID is "eduroam" and with EAP-AKA' because the MCC/MNC code
matches the SIM credentials.

Which one is actually chosen? Who knows. So here we see one network with
two usable EAP types for the same entity that wants to connect.

This is not very far-fetched: it's going to be somewhat common whenever
a Wi-Fi offloading deal with a mobile operator is in place.

>   I'd be wary of allowing multiple EAP configurations for one network access method.  It involves users, who we know make mistakes.

Luckily, it *may* be deterministic without the user. I believe the
Passpoint specs state that Passpoint properties are supposed to "beat"
normal SSID discovery. In the example above, this /probably/ means that
the device will always join with EAP-AKA'.

This is not as deterministic as it would seem though: it's easy to
construct more pathological cases. Like a network which has the MCC/MNC
passpoint property (EAP-AKA') but also a Roaming Consortium OI passpoint
property for a non-cellular roaming consortium of choice (say, with a
EAP-TLS client certificate).

Now there are two passpoint properties, attached to two different EAP
types. Who wins? I don't think this is well-defined. But I'd be happy to
be proven wrong if anyone happens to know.

In any case, a pool of more than one EAP type for more than one network
is something that should be considered.

Ok.

Greetings,

Stefan Winter

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 6 Apr 2016 16:01:43 -0700

On Mar 21, 2016, at 9:09 AM, Sam Hartman <hart [email-masked]> wrote:
> 
> 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.

[BA] I completely agree.

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

[BA] Agree. In modern EAP methods the EAP-Response/Identity is always part of the EAP stack. RFC 3748 makes this clear. 

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

[BA] I agree. Also, trying to retrofit this on existing methods is very likely to introduce interop failures. 

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

[BA] I share your concerns though I'm also spending more time outside IETF these days (in groups more attuned to open source).

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 6 Apr 2016 17:06:26 -0700

On Mar 21, 2016, at 9:20 AM, Alan DeKok <[email-masked]> wrote:
> 
>  The outer identity is usually derived from the inner identity.

[BA] No. Where anonymity is supported, the outer identity is anonymous and the inner is not. Also, the inner may not be an NAI (e.g. for PAP or MS-CHAPv1/v2). 

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

[BA] For new methods, sure. But imposing this on legacy methods will break them.

> 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

[BA] Yes!

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

[BA] Yes.

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

[BA] Yup.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 6 Apr 2016 17:10:30 -0700

> since, and not doing that was a mistake - so better to fix it late than

[BA] I believe this was the intent in RFC 3748, so we can clarify this now (and update RFC 3748). 

[BA] Yes.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 6 Apr 2016 17:17:02 -0700

> method which uses B will actually reach an EAP server which is prepared

[BA] Be careful. The statement is true for the EAP-Response/Identity, but may not be true for an EAP-method specific identity, which might not be an NAI. Even if it is an NAI, the results may depend on things like the federation structure of the underlying LDAP directory.  We are very much outside RADIUS-land with EAP-method specific identities.

> may need to be more than instance of A as well.

[BA] Only one EAP-Response/Identity is permitted in RFC 3748. That is fundamental to EAP.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 6 Apr 2016 17:37:03 -0700

Alan said:

"All for the same realm and SSID?

  This is where it gets vague... there should only be one EAP configuration
for a particular way of getting network access.
"

[BA] Indeed - anything else invites a bid-down attack.  For example,
EAP-SIM is vulnerable to attack and should NEVER be allowed on an SSID
where it is not expected.

"Identifiers should be an NAI when roaming comes into play"

[BA] The EAP-Response/Identity should be an NAI - for roaming and other
reasons.  But the EAP-method specific identity is not used for external
routing, so how does roaming come into play with that?

" What people do in their own networks is their own business.  But there is
a definite overlap with public networks.
"

[BA] Only in some *very* specific scenarios used in failed schemes such as
WiMax (where there was routing based on EAP-specific Identities).  Overall,
I think we should STRONGLY discourage that - so that WiMAX will not have
died in vain.

"And say that close enterprise deployments SHOULD use the NAI, for reasons
outlined above."

[BA] Enterprise deployments are *exactly* the kind of deployments that
would be most likely to be broken by forcing use of an NAI for
method-specific identities, because they often migrate in stages.  Such a
recommendation would only be safe in the very last phase of a migration to
the cloud, when legacy on-premise equipment has been completely replaced by
cloud-based authentication where the NAI is a virtual requirement.

On Tue, Apr 5, 2016 at 2:23 PM, Alan DeKok <[email-masked]>
wrote:

>   This is where it gets vague... there should only be one EAP
> configuration for a particular way of getting network access.
>
>   I'd be wary of allowing multiple EAP configurations for one network
> access method.  It involves users, who we know make mistakes.
>
>   What people do in their own networks is their own business.  But there
> is a definite overlap with public networks.
>
>   If private enterprises are *at any point* interested in connecting their
> networks to a public infrastructure, they should be compatible with that
> infrastructure from day 1.  Migration from "internal" identifiers to
> "public" identifiers is a nightmare.
>
>   i.e. there is no large benefit in using identifiers in an internal
> format.  Therefore, we recommend using ones which are compatible with
> public networks.
>
>   Even before.  Migration is  nightmare.  These people shouldn't think
> that they're smarter than everyone else on the planet.  They're not.  They
> should use NAIs, because it's the best thing we know.
>
> > The wording "MUST" without the qualifier ... "in a roaming environment"
> (or "if the EAP session is sent to a different entity") is then too harsh.
> I'd be happy to add the MUST with that extra qualifier; and to leave closed
> enterprise EAP deployments alone.
>
>   Sure.
>

---

From: Stefan Winter <[email-masked]>
Date: Thu, 7 Apr 2016 17:42:19 -0300

Hi,

> [BA] Be careful. The statement is true for the EAP-Response/Identity, but may not be true for an EAP-method specific identity, which might not be an NAI. Even if it is an NAI, the results may depen…

Absolutely: the I-D is exclusively about the contents of
EAP-Response/Identity. The newly coined term "realm identifier" is meant
to mean "a candidate for a UTF-8 string to be put into
EAP-Response/Identity".

That is, there is a really arbitrary method-specific identity - no
format requirements, no encoding requirements: that's the B above. When
you decide to use the corresponding EAP method in your authentication
attempt, then you'll need to get that realm identifier A, and A needs to
be good enough to make the EAP-method payload end up at an EAP server
that can handle it.

Where you get that A from is undefined, and EAP method implementations /
OS UIs have their own ideas about it. (e.g. use identical strings for
both without asking the user; or provide a config item that the user
needs to fill out; or ...).

The important thing here is the sequence: you choose an EAP method with
a user identifier B, then you determine the realm identifier A to use as
a basis for what to send in EAP-Response/Identity.

> [BA] Only one EAP-Response/Identity is permitted in RFC 3748. That is fundamental to EAP. 

Sure. Nobody disputes that. The concern in the I-D is that you may have
multiple EAP methods configured in your supplicant. Those may require
the use of more than one realm identifier (e.g. @eduroam.org for PEAP
and @mnc45.mcc123.3gppnetwork.org for AKA') and that you consequently
*would* need more than one EAP-Response/Identity to route both
alternatives correctly.

Since that is not possible, the only solution if you really want to try
both EAP methods is to run an EAP conversation with one A. And then, if
that doesn't succeed, you run a second EAP conversation with the other
A. Only when you've tried all your EAP methods and none authenticated
you, give up and tell the user he is busted.

This is actually written in the draft.

Greetings,

Stefan Winter

---

From: Stefan Winter <[email-masked]>
Date: Thu, 7 Apr 2016 17:45:56 -0300

Hi,

reading this, I think all that's needed is the re-iteration: we are
talking about mandating structure in realm identifiers ("things that end
up in EAP-Response/Identity") - not method-specific identities.

Greetings,

Stefan Winter

On 06.04.16 21:37, Bernard Aboba wrote:
> [BA] The EAP-Response/Identity should be an NAI - for roaming and
> other reasons.  But the EAP-method specific identity is not used for
> external routing, so how does roaming come into play with that?
>
> " What people do in their own networks is their own business.  But
> there is a definite overlap with public networks.
> "
>
> [BA] Only in some *very* specific scenarios used in failed schemes
> such as WiMax (where there was routing based on EAP-specific
> Identities).  Overall, I think we should STRONGLY discourage that - so
> that WiMAX will not have died in vain. 
>
> "And say that close enterprise deployments SHOULD use the NAI, for
> reasons outlined above."
>
> method-specific identities, because they often migrate in stages. 
> Such a recommendation would only be safe in the very last phase of a
> migration to the cloud, when legacy on-premise equipment has been
> completely replaced by cloud-based authentication where the NAI is a
> virtual requirement.  
>
>  
>
> On Tue, Apr 5, 2016 at 2:23 PM, Alan DeKok <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Apr 5, 2016, at 11:48 AM, Stefan Winter
>     <[email-masked] <mailto:[email-masked]>> wrote:
>       I'd be wary of allowing multiple EAP configurations for one
>     network access method.  It involves users, who we know make mistakes.
>
>       What people do in their own networks is their own business.  But
>     there is a definite overlap with public networks.
>
>       If private enterprises are *at any point* interested in
>     connecting their networks to a public infrastructure, they should
>     be compatible with that infrastructure from day 1.  Migration from
>     "internal" identifiers to "public" identifiers is a nightmare.
>
>       i.e. there is no large benefit in using identifiers in an
>     internal format.  Therefore, we recommend using ones which are
>     compatible with public networks.
>
>       Even before.  Migration is  nightmare.  These people shouldn't
>     think that they're smarter than everyone else on the planet. 
>     They're not.  They should use NAIs, because it's the best thing we
>     know.
>
>     > The wording "MUST" without the qualifier ... "in a roaming
>     environment" (or "if the EAP session is sent to a different
>     entity") is then too harsh. I'd be happy to add the MUST with that
>     extra qualifier; and to leave closed enterprise EAP deployments alone.
>
>       Sure.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 7 Apr 2016 17:18:43 -0400

> *would* need more than one EAP-Response/Identity to route both

  I think in the majority of cases, the mapping of SSID to EAP type is 1-1.  That's how supplicants are designed and implemented today.

> you, give up and tell the user he is busted.

  That worries me.  It's new behaviour.  We're not clear if this will work, or when it will work, or how it will work.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 7 Apr 2016 18:20:17 -0300

Hi,
> [BA] No. Where anonymity is supported, the outer identity is anonymous and the inner is not. Also, the inner may not be an NAI (e.g. for PAP or MS-CHAPv1/v2). 

"Derived from" does not mean they have to be *identical*. If say an
inner is "[email-masked]" then it's easily possible to derive
from that an outer ID "@restena.lu".

Of course it *can* be configured separately without mangling anything
from inner (and that's arguably good, because you never know what you
find inside the EAP method). And of course it *can* be identical in some
cases (which is arguably bad because it doesn't provide privacy).

Real life BTW typically swings to "identical" in many UIs because when
you click on a .1X Wi-Fi network, devices which did not get prior config
info typically ask for "username" and "password" and nothing else. In
which case the supplicant uses "username" both for EAP-Response/Identity
and as an inner ID for the EAP method which gets negotiated.

All in all, "usually" describes the situation quite well IMHO.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 7 Apr 2016 17:24:22 -0400

> from that an outer ID "@restena.lu".

  Or "DOMAIN\user" maps to "@example.com"

  Because the system administrators at the company know (a) the local AD domain name, and (b) the public realm of the company.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 7 Apr 2016 18:24:48 -0300

Hi,

>   I think in the majority of cases, the mapping of SSID to EAP type is 1-1.  That's how supplicants are designed and implemented today.

Sure, SSID -> EAP type is typically unique. 802.11 Roaming Consortium OI
-> EAP type is as well.

So when a network with the configured SSID also emits the same Roaming
Consortium OI? All of a sudden the supplicant has two choices.

>   That worries me.  It's new behaviour.  We're not clear if this will work, or when it will work, or how it will work.

Me, too. The addition of IEEE 802.11 Interworking to the mix brings a
whole new set of complexity.

The alternative though is: try one of the methods, and if that account
doesn't work / has no credit / expired then you are stranded - even
though there would be an alternative EAP method to log on with, and
possibly successfully?

Greetings,

Stefan Winter

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Apr 2016 14:49:18 -0700

Alan said:

"  That worries me.  It's new behaviour.  We're not clear if this will
work, or when it will work, or how it will work."

[BA] RFC 3748 and the EAP State Machine (RFC 4137) forbids chaining of EAP
methods outside a tunnel.  I know of no EAP implementation that supports
this.
So in general, it will not work - and moreover, is forbidden by the
standard.

On Thu, Apr 7, 2016 at 2:18 PM, Alan DeKok <[email-masked]>
wrote:

>   I think in the majority of cases, the mapping of SSID to EAP type is
> 1-1.  That's how supplicants are designed and implemented today.
>
>   That worries me.  It's new behaviour.  We're not clear if this will
> work, or when it will work, or how it will work.
>
>   Alan DeKok.
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Apr 2016 14:52:20 -0700

Alan said:

"  Or "DOMAIN\user" maps to "@example.com"

  Because the system administrators at the company know (a) the local AD
domain name, and (b) the public realm of the company."

[BA] It is difficult to generalize, because it can be company-specific.
For example, within Microsoft, REDMOND\bernarda happens to map to
[email-masked] but how would any implementation know
this?

On Thu, Apr 7, 2016 at 2:24 PM, Alan DeKok <[email-masked]>
wrote:

> >> [BA] No. Where anonymity is supported, the outer identity is anonymous
> and the inner is not. Also, the inner may not be an NAI (e.g. for PAP or
> MS-CHAPv1/v2).
> >
>   Because the system administrators at the company know (a) the local AD
> domain name, and (b) the public realm of the company.
>
>   Alan DeKok.
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Apr 2016 14:56:56 -0700

Stefan said:

"Me, too. The addition of IEEE 802.11 Interworking to the mix brings a
whole new set of complexity.

[BA] As Alan noted, the mapping of IEEE 802.11 SSID to EAP method is
typically 1:1.  This is a major obstacle to deployment of more complex
schemes, particularly since it is increasingly easy to add SSIDs since
support for "virtual APs" has become more and more common.

Just because something is complicated doesn't mean it is worthwhile -
particularly if it requires major changes to existing standards.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 7 Apr 2016 18:03:49 -0400

> On Apr 7, 2016, at 5:52 PM, Bernard Aboba <[email-masked]> wrote:
> 
> Alan said: 
> 
>   Because the system administrators at the company know (a) the local AD domain name, and (b) the public realm of the company."
> 
> [BA] It is difficult to generalize, because it can be company-specific.  For example, within Microsoft, REDMOND\bernarda happens to map to [email-masked] but how would any implementation know this?  

  It doesn't.

  The administrator needs to know this, and to provision it.

  The implementation just knows that it uses byte string A for a "realm" identifier, and byte string B for an EAP-MSCHAPv2 identifier.

  We should make it *very* clear in the document that the implementation should be *provisioned* with the identifiers.  And should not *derive* them.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 8 Apr 2016 10:32:11 -0300

Hi,

> particularly if it requires major changes to existing standards. 

What major changes are you talking about?

IEEE 802.11 Interworking is an existing standard.

Stefan

>
>
>
> On Thu, Apr 7, 2016 at 2:24 PM, Stefan Winter
>     >> the use of more than one realm identifier (e.g. @eduroam.org
>     <http://eduroam.org> for PEAP
>     >> and @mnc45.mcc123.3gppnetwork.org
>     <http://mnc45.mcc123.3gppnetwork.org> for AKA') and that you
>     consequently
>     >   I think in the majority of cases, the mapping of SSID to EAP
>     type is 1-1.  That's how supplicants are designed and implemented
>     today.
>
>     >   That worries me.  It's new behaviour.  We're not clear if this
>     will work, or when it will work, or how it will work.
>     >
>

---

From: Stefan Winter <[email-masked]>
Date: Fri, 8 Apr 2016 10:34:06 -0300

Hi,

> [BA] RFC 3748 and the EAP State Machine (RFC 4137) forbids chaining of
> EAP methods outside a tunnel.  I know of no EAP implementation that
> supports this. 

I don't think anybody in this whole thread ever talked about EAP method
chaining.

It's all about running an entirely separate second EAP conversation
(this time, choosing a different EAP type, consequently with a different
realm idntifier) if the first one didn't have a favourable outcome.

Stefan

>
> On Thu, Apr 7, 2016 at 2:18 PM, Alan DeKok <[email-masked]
>     On Apr 7, 2016, at 4:42 PM, Stefan Winter

---

From: Alan DeKok <[email-masked]>
Date: Fri, 8 Apr 2016 09:39:14 -0400

> What major changes are you talking about?

  Retrying the same SSID with a different set of credentials is a big change.  No one does it today.  It's hard to know what is the "correct" thing to do.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 8 Apr 2016 10:44:41 -0300

Hi,

>   Retrying the same SSID with a different set of credentials is a big change.  No one does it today.  It's hard to know what is the "correct" thing to do.

But those are no protocol changes. It's supplicants doing an extra step
which is completely compliant with existing standards.

And really, please do consider the examples I used earlier in this
thread: situations where multiple sets of credentials are applicable to
a single hotspot are becoming a reality right now.

Thinking "SSID" is simply not sufficient any more. I'd rephrase your
sentence above as

"Retrying the same Wi-Fi hotspot with a different set of credentials
because that hotspot matches multiple network selection criteria is a
big change".

But those multiple network selection criteria are hitting the street. We
should be prepared for it.

Greetings,

Stefan

---

From: Stefan Winter <[email-masked]>
Date: Fri, 8 Apr 2016 10:48:21 -0300

Hi,

> a single hotspot are becoming a reality right now.

Speaking of those examples: I guess it would really help readers of the
draft if those were included in the I-D. I'll be sure to add them, along
with some beautiful ASCII art.

Greetings,

Stefan Winter

---

From: Alan DeKok <[email-masked]>
Date: Fri, 8 Apr 2016 10:03:23 -0400

> which is completely compliant with existing standards.

  Sure.  But they are behavioural changes.

> a single hotspot are becoming a reality right now.

  Ugh.  This means that people see a need for it, but not necessarily that they're doing it *right*.

  Which means that this document is even more time-sensitive.

> should be prepared for it.

  Who is doing this, and why?

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 8 Apr 2016 11:11:54 -0300

Hi,

>   Who is doing this, and why?

Wi-Fi offloading: ordinary Wi-Fi hotspots partner with cellular
providers. The Wi-Fi network still has its SSID and users - 802.11
Interworking throws in new users to the same hotspot based on their SIM
card. As soon as the first user has an SSID-based account with the Wi-Fi
provider *and* a matching SIM card in his device, the ambiguity begins.

Stefan

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 8 Apr 2016 07:25:41 -0700

Stefan said:

"

[BA] They are "hitting the street" in the same sense that an egg thrown
from a tall building will "hit the street" - and go "splat!"

We don't change the side walk just because people throw rotten eggs from
tall buildings.

The reality is that "IEEE 802.11 internetworking" has virtually no
deployment today.

Is *any* major OS vendor (iOS, Android, etc.) intending to implement this?

If not, we can very happily ignore it.  In fact, I'd claim it is our *duty*
to ignore it, rather than trying to turn EAP into IMS.

On Fri, Apr 8, 2016 at 6:44 AM, Stefan Winter <[email-masked]>
wrote:

> >   Retrying the same SSID with a different set of credentials is a big
> change.  No one does it today.  It's hard to know what is the "correct"
> thing to do.
> >
>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 8 Apr 2016 07:30:40 -0700

Stefan said:

"Wi-Fi offloading: ordinary Wi-Fi hotspots partner with cellular
providers. The Wi-Fi network still has its SSID and users - 802.11
Interworking throws in new users to the same hotspot based on their SIM
card. As soon as the first user has an SSID-based account with the Wi-Fi
provider *and* a matching SIM card in his device, the ambiguity begins."

[BA] The Wi-Fi hotspot could just as easily create a new SSID for the
cellular network, and then it would "just work" with existing
implementations.

Sorry, but the mere existance of an undeployed standard is not a good
reason to make major changes in the implementation of 3+ billion devices,
especially when operational choices exist that would make those changes
unnecessary.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 8 Apr 2016 10:33:08 -0400

> should be prepared for it.

  I would lean towards "discourage", rather than "be prepared"

> [BA] They are "hitting the street" in the same sense that an egg thrown from a tall building will "hit the street" - and go "splat!"
> 
> We don't change the side walk just because people throw rotten eggs from tall buildings.
> 
> The reality is that "IEEE 802.11 internetworking" has virtually no deployment today. 
> 
> If not, we can very happily ignore it.  In fact, I'd claim it is our *duty* to ignore it, rather than trying to turn EAP into IMS. 

  I would say ignoring it is insufficient.  We should explain why it's a bad idea.

  Trying credentials until one works is a *terrible* idea.  I understand why people do it, but I also understand why people nail their feet to the floor: incompetence, lack of attention, etc.

  For the case Stefan mentioned, the choice of credentials is simple, and can be made once, when the new credentials are provisioned.  The cheapest one is used.

  The alternative is to over-bill the user, which they will complain about.

  This says that the 802.1X config utility Stefan is also pushing needs to have an way of describing cost (or preference of credentials), so that the decision process can be documented, and made automatically.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 11 Apr 2016 09:03:06 +0200

Hello,

> Is *any* major OS vendor (iOS, Android, etc.) intending to implement this? 

Funny that you ask this question. It is part of the Windows 10 Wi-Fi config:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms706965%28v=vs.85%29.aspx

You may want to take a look at "WLANProfile -> Hotspot2 -> NAIRealm /
Network3GPP / RoamingConsortium" fields particularly.

And it is also in iOS and Mac OS X.

https://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html#//apple_ref/doc/uid/TP40010206-CH1-SW30

The parts "RoamingConsortiumOIs, NAIRealmNames, MCCAndMNCs are the
important bits here.

Also, note how "SSID_STR" states: "In iOS 7.0 and later, this is
optional if a DomainName value is provided".

Finally, even Android (extra emphasis on EVEN) has introduced support in
Android M:

https://developer.android.com/reference/android/net/wifi/WifiConfiguration.html

Things to look for here is roamingConsortiumIDs, the method
isPasspoint() etc. They do miss the MCC/MNC bits admittedly, but it's
Android after all and they have to lag behind *somewhere* :-)

> If not, we can very happily ignore it.  In fact, I'd claim it is our
> *duty* to ignore it, rather than trying to turn EAP into IMS. 

The answer to the previous question was a Yes.

Greetings,

Stefan Winter

> 
> On Fri, Apr 8, 2016 at 6:44 AM, Stefan Winter <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 

-- 
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: Stefan Winter <[email-masked]>
Date: Mon, 11 Apr 2016 09:09:24 +0200

Hi,

> cellular network, and then it would "just work" with existing

But they don't. Probably because popular advice in the Wi-Fi world is:
don't add more SSIDs, the beacon time will clog up the network. Folks
have been saying that for a decade (and as deployers, we've been hit by
this; where eduroam would not be added by a commercial vendor because
the extra SSID was unpopular on their side), and as an unsurprising
consequence, people are looking for alternatives to yet-another-SSID.

> reason to make major changes in the implementation of 3+ billion
> devices, especially when operational choices exist that would make those
> changes unnecessary. 

It seems like you want to start a fight against the existence of
Interworking, Passpoint, and/or the mindset of people considering
deploying it.

That may even be a good idea in general - I have mixed feelings about
Passpoint, too. But radext is not the place to fight this fight. We
really have little to do with it, except that there are consequences for
EAP method selection. And as my other mail already alluded too,
supplicants are already being implemented and shipped; which makes it
logical to provide words of wisdom to proper implementation. We are even
already late, considering that finished code is out in the wild already.

I strongly suggest not to go down a rathole of "Passpoint sucks, we must
boycot it!" here. There are certainly other venues where such a plea is
more on-topic.

Greetings,

Stefan Winter

> 
> On Fri, Apr 8, 2016 at 7:11 AM, Stefan Winter <[email-masked]

Tel: +352 424409 1
Fax: +352 422473