Re: [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt

[Stefan Winter <[e-mail]>]

Hi,

> Section 3:
> 
>    ... EAP-
>    Response/Identity does not carry encoding information itself, so a
>    conversion between a non-UTF-8 encoding and UTF-8 is not possible for
>    the AAA entity doing the EAP-Response/Identity to User-Name copying.
> 
>   I'm unsure about this.  The EAP-Response/Identity field is *supposed*
> to be UTF-8.  So if it's not, the supplicant is non-compliant, and
> anything can happen.

Unfortunately, that is not how I read the EAP spec. RFC3748 section 5.1
on the "Identity" packet does not mention UTF-8 for the *Response* at all.

It mentions that the *request* MAY contain displayable text, which needs
to be UTF-8 if present.

For response, no encoding is mandated. The RFC even mentions weirdnesses
such as an intermediate NUL character followed by "various options" -
but only notes them, they are not forbidden. The use of such a construct
breaks the UTF-8 requirement.

I totally agree that anything besides UTF-8 in the Response is a bad
idea, and these days hopefully a seldom find - but it should be said
someplace that it's outright forbidden.

Which reminds me that my text speaks of SHOULD NOT in the
recommendations (given that I've preliminarily aimed for BCP status, I
found a MUST NOT not to be fitting; but maybe it is more spot on
nontheless).

>   I think the recommendation here for EAP to RADIUS gateways (e.g.
> Access Points) is to do as little translation as possible.  They should
> just copy the Identity blob into the User-Name attribute.

And do what if they find that the blob is not UTF-8? Drop the packet?
Forward anyway?

>   The next paragraph does explain why this is a problem, but the quoted
> text above seems misleading to me.  The AAA entity *can* copy the
> EAP-Response/Identity to User-Name.  It's just data, so that copying is
> always possible.

Sure; but you create a malformed packet with it - so everybody who
consumes that data is at a gamble.

>    Consequence: If an EAP method's username is not encoded in UTF-8, and
> 
>   I would suggest "user identifier", to avoid confusion with User-Name.

Sure, no problem.

>    the EAP peer verbatimly uses that method's notion of a username for
>    its EAP-Response/Identity field, then the AAA entity is forced to
>    violate its own specification because it has to, but can not use
>    UTF-8 for its own User-Name attribute.  This jeopardizes the
>    subsequent EAP authentication as a whole; request routing may fail or
>    lead to a wrong destinationi, or the AAA payload may be discarded by
>    the recipient due to the malformedness of the User-Name attribute.
> 
> 
>   That is all true.  I would note that the EAP-Response/Identity field
> does *not* have to be taken from the EAP methods user identifier field.
>  They can be completely different.

Will do (the completely different content would be the outer identity).

>   That should be noted here.  Where the EAP methods user identifier
> field is *not* UTF-8, the supplicant MUST provide a UTF-8 compatible
> string for the EAP-Response/Identity field.  How it gets that string is
> implementation dependent. :(

Yes, that's why I wrote the (somewhat hollow) statement that it "needs
to maintain state of the encoding used". How it does that... no spec can
mandate.

> Section 4:
> 
>    Where usernames between configured EAP types in an EAP peer differ,
>    the EAP peer can not rely on the EAP type negotiation mechanism alone
>    to provide useful results.  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 usernames
>    from the entire set of configured EAP types before declaring final
>    authentication failure.
> 
>   I see why this can be necessary, but it's ugly.

I totally agree that it's ugly. Adding "Note: That is ugly." to the spec
doesn't provide much added value though :-)

I feel strong about stating the problem though. We had an actual
real-life support case from a device manufacturer whose handset
customers couldn't use eduroam and the manufacturer said our RADIUS
infrastructure is broken, because it always rejects before they can even
try the configured EAP-TTLS that the user sets.

It was totally unthinkable for them that someone would not have a
business relationship with 3GPP and that always trying the same 3GPP
user identifier when starting EAP would lead nowhere.

After a lot of explaining and escalation to some senior engineering, we
could make that clear, and the firmware got a fix. Having this described
in an RFC to point to will certainly help if such states of mind pop up
again someplace in the future.

>    EAP peers need to maintain state on the encoding of the usernames
>    which are used in their locally configured EAP types.  When
>    constructing an EAP-Response/Identity from that username information,
>    they SHOULD (re-)encode that username as UTF-8 and use the resulting
>    value for the EAP-Response/Identity.  If the EAP type is configured
>    for the use of anonymous outer identities, the desired outer identity
>    should also be (re-)encoded in UTF-8 encoding before being put into
>    the EAP-Response/Identity.
> 
>  I would add "or allow the provisioning of an EAP-Response/Identity
> field independent form the EAP method user identifier"

Well... that degree of freedom exists - outer ID *is* independent from
the EAP method's user identifier.

I'm not sure what the effect of this (third!) notion of (non-)identity
could add? The example of the 3GPP vs. realm.example shows that there
may well be *no* common EAP-Response/Identity which actually fits all
configured EAP types.

> Section 5
> 
>   It may be worth noting that supplicants should try the most secure EAP
> methods first (i.e. ones with anonymous outer identity).  If those fail,
> they should proceed to more insecure methods.  This prevents leakage.

Good idea!

>   Also, supplicants could cache information about successful
> authentications.  If the system appears to be "the same" as one where
> EAP method X previously worked, it makes sense to start off with EAP
> method X.
> 
>   How the supplicant determines that this is "the same" system is a
> subject for discussion.

Interesting thought, and a bit complex. I suggest we discuss this when
the draft gets adopted in ... "some" working group. Suggestions welcome :-)

Greetings,

Stefan Winter


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]

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