Re: [radext] Review of draft-winter-radext-populating-eapidentity-01

[Stefan Winter <[e-mail]>]

Hi,

>>>>>> "Bernard" == Bernard Aboba <[e-mail]> writes:
>     Bernard> On Jul 20, 2015, at 13:29, Sam Hartman <[e-mail]> wrote:
>     >> Other implementations request both identities from the user.
>     >> However, I don't know anything that tries to map back from a
>     >> method identity to an eap response.
>
>     Bernard> [BA] Neither do I - it's a bad idea.  That's why Section
>     Bernard> 4's advice seems so strange:
>
>     Bernard>     If an EAP authentication gets rejected, the EAP peer
>     Bernard> SHOULD re-try the authentication using a different
>     Bernard> EAP-Response/Identity than before.  The EAP peer SHOULD try
>     Bernard> all user identifiers from the entire set of configured EAP
>     Bernard> types before declaring final authentication failure.
>
>     Bernard> [BA] "all user identities" appears to imply using
>     Bernard> method-specific identities to construct the
>     Bernard> EAP-Response/Identity.
>
> Ah, that's not how I read it at all.
> I read that as saying that you try all the identities you have.
> If you're an implementation that stores outer identities separately from
> inner identities, then try all your outer identities.
> If you're an implementation that maps both from a common principal, do
> that for all your principals.

Thanks both for taking this thread so far - now I see the shortcomings
in my formulation.

FWIW, the intention of the wording was Sam's POV and I will re-phrase it
to be clearer.

>     Bernard>    EAP peers need to maintain state on the encoding of the
>     Bernard> user identifiers which are used in their locally configured
>     Bernard> EAP types.  When constructing an EAP-Response/Identity from
>     Bernard> that user identifier,
>
>     Bernard> [BA] Again, this seems to imply using method-specific
>     Bernard> identities to construct the EAP-Response/Identity.
>
> I see what you're saying now.
> I think what the text is trying to talk about there is constructing both
> from some common principal/idea about an account.  However it could be
> read as constructing one from another.
> And also, it doesn't deal as well with the case where they are separate.

I had a specific example in my head when thinking about this, it's a
Redmond one :-)

The Win 7 PEAP config allows to configure the method inner identity.
There's also a separate place for the outer identity.
However: you can't type a NAI realm in the outer ID box, only a non-NAI
string.

What happens when you type "anonymous" as outer ID, and
"[e-mail]" as the inner ID, is that the supplicant will send an
EAP-Response/Identity of "[e-mail]".

Just like Bernard says, yes, this is using (parts of) a method-specific
(inner) identity to construct the EAP-Response/Identity.

That is, the config options for inner vs. outer are different, yet
related. The supplicant blends two different config items into one
resulting string. Hopefully, both are in the same encoding, and
hopefully, the encoding is UTF-8. If not, both parts of it need to be
converted to a common encoding before concat'ing them, and the result be
converted to UTF-8 before sending.

Source: MSDN EAP Team Blog
http://blogs.msdn.com/b/eapteam/archive/2009/01/16/peap-identity-privacy-support-in-windows7.aspx

The draft's intention is exactly to move implementations towards UTF-8
for the EAP-Response/Identity *no matter where they take the string
from, be it from an inner identity, explicit configuration of an outer
identity, or a blend of the two*. It is not the intention to spill inner
identities to EAP-Response/Identity if an outer identity is configured.

Greetings,

Stefan Winter

>
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext