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

[Stefan Winter <[e-mail]>]

Hi,

croping to the remaining bits...

> Also, the EAP-Response/Identity is frequently anonymous and is used
> to prevent a snooping attacker from obtaining the method-specific
> identities, which are typically encrypted.  For this reason and others
> described below, it is not advisable for EAP implementations to
> determine the EAP-Response/Identity based on the method-specific
> identities.

And yet, this is what pretty much every supplicant I've seen does.
Inner ID: [e-mail]
Outer ID: (not configured)
EAP-Response/Identity: [e-mail]

(again, an example: this is what Windows 7 does if you do not configure
Identity Privacy)

That may be a bad idea (but what's the alternative? Bail out with
"config error, need outer ID"?). The draft does not take any position on
whether that's a good or bad thing to do. It merely states that if an
implementation does that, it needs to be cautious to convert the inner
ID to UTF-8 before sending at as outer ID.

> Most EAP methods created subsequent to RFC 3748 have incorporated
> their own Identity Exchanges, and those methods are therefore not
> influenced by the EAP-Response/Identity.   Since the
> EAP-Response/Identity is distinct from the method-specific identity,
> the recommendations of Section 4 will not have an effect on EAP
> authentication, other than perhaps forcing the selection of a
> different EAP server:  
>  
>    If an EAP authentication gets rejected, the EAP peer SHOULD re-try
> the authentication using a
>    different EAP-Response/Identity than before.  The EAP peer SHOULD try
>    all user identifiers from the entire set of configured EAP types
>    before declaring final authentication failure.

>  The advice has a number of major downsides.  Since most
> authentication failures will be due to mistyping the password,
> responding to an authentication failure by retrying all conceivable
> user identities will lead to major delays

... in the order of magnitude of several hundred milliseconds ...
> and very high levels of user annoyance.
... or user joy and happiness, if going that extra mile turned a DoS
into a successful authentication.

> By responding to an authentication failure by trying method-specific
> identities, implementations would divulge identity information that
> was designed to be kept secret, compromising privacy. Also, an
> implementation following this advice would utilize method-specific
> identities that may not be in the appropriate format or character
> encoding for an EAP-Response/Identity. 

That's exactly why the draft states that a conversion to UTF-8 needs to
be done before sending as EAP-Response/Identity. True, if the format is
not what is needed on the routing level, the authentication still won't
succeed. However, in the absence of an actual outer ID config, there's
nothing an RFC can do to fix this; the user needs to fix his config then.

>  Since RFC 3748 makes it clear that the EAP-Response/Identity is not
> related to the method-specific identity, constructing the
> EAP-Response/Identity from the method-specific one is inadvisable.  
> The re-encoding described above may not be possible for a variety of
> reasons, including the fact that the method-specific identity need not
> be in NAI form at all. 

Encoding (as in: to UTF-8) should always be possible (the EAP peer
hopefully knows the original encoding). Again, if the resulting string
is not a NAI but a NAI would be needed to route the authentication -
time to give up.

Greetings,

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