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

  Sam and I had extensive conversations about it this week.  I think his summary below is critical to get everyone talking about the same thing.

  We also need to discuss where these identities are derived from.  For example, wpa_supplicant allows you to configure the outer identity, and the inner identity, though it gives them different names.  I can't see where the method-specific identify is configured.

  From looking at the code, the method-specific identity is just a copy of the inner identity.

  This process is different in windows.  The inner and outer identities can be configured via the 802.1X GUI.  The method-specific identify cannot be configured.  And it is NOT the same as the inner identity.  Instead, some (essentially magic) process is used to transform one into the other.  In typical cases, the inner identity "user@example.com" gets transformed to an EAP-MSCHAPv2 identity "EXAMPLE\user".

  I would suggest that such processes should be discouraged.  It is difficult enough to analyze the security of EAP without introducing 3 potentially unrelated identities.

  What does it mean when the inner identity is "user@example.com", and the method identity is "CORP/bob"  ?  Who is being authenticated here?

  I don't think anyone knows.

  In the case of Windows, it would be good for an EAP server to check via an API that "user@example.com" gets transformed to "EXAMPLE\user".  The server can then verify that the method identity, while opaque, is transformationally equivalent to the inner identity.  This verification would likely prevent some attacks.

On Jul 22, 2015, at 5:21 AM, Sam Hartman <hartmans@painless-security.com> wrote:
> ONe thing to clarify in this document is which identities are we talking
> about.  There are:
> 
> * The outer identity carried in an EAP response in RADIUS/Diameter.  I
>  know we're talking about that one.  That's the primary point of the
>  document.
> 
> * The Inner identity (if you have a tunnel method) often carried in an
>  EAP response/identity in the tunnel.  You could argue this one is
>  either in or out of scope.  You could argue this is an internal
>  identifier of the tunnel method.
> 
> * The method specific identifier of the EAP method within the tunnel.
>  In case of password authentication in something like TEAP this
>  identity may be carried and the classic inner identity may not.  I
>  think this identity is clearly out of scope for this document.
> 
> --Sam
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext