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

From: Stefan Winter <[email-masked]>
Date: Fri, 14 Feb 2014 10:08:32 +0100

Hello,

I've just submitted an -00 on a topic that we've been struggling with in
ABFAB recently (but which exists in every EAP-over-AAA scenario, not
limited to ABFAB).

http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapidentity-00.txt

Abstract:
   There are some subtle considerations for an EAP peer regarding the
   content of the EAP-Response/Identity packet when authenticating with
   EAP to an EAP server.  This document describes two such
   considerations and suggests workarounds to the associated problems.

The issue touches multiple areas and working groups (EAP, EAP methods,
RADIUS, Diameter) so I had to do a guesstimate for a proper home. I
would think radext is the best match, cc'ing abfab and dime, and also
emu even though it's shutting down).

If you recall those in-depth discussions about fixing either EAP methods
to use UTF-8, or why EAP Identity would need to be restrained to UTF-8
even if a method doesn't do it, then yes: the draft is about that.

In ABFAB, we added a ABFAB-specific band-aid sentence to RFC7057:
"Circumstances might require that applications need to perform
conversion of identities from an application specific character set to
UTF-8 or another character set required by a particular EAP method."

Which was enough to get the document through IESG, but this should
better be fixed more generally for every EAP use case; hence this new draft.

It's short and concise - I'd appreciate if you could give it a read and
comment.

If there's still free time on the agenda, I would also merrily discuss
it in London.

Greetings,

Stefan Winter

P.S.: Don't miss my other submission about an EAP Configuration File
Format, which I've been told to submit to ops-area/opsawg:

http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/

Annoucement here:
http://www.ietf.org/mail-archive/web/ops-area/current/msg01114.html

-------- Original Message --------
Subject: New Version Notification for
draft-winter-radext-populating-eapidentity-00.txt
Date: Fri, 14 Feb 2014 00:43:29 -0800
From: [email-masked]
To: Stefan Winter <[email-masked]>, "Stefan Winter"
<[email-masked]>

A new version of I-D, draft-winter-radext-populating-eapidentity-00.txt
has been successfully submitted by Stefan Winter and posted to the
IETF repository.

Name:		draft-winter-radext-populating-eapidentity
Revision:	00
Title:		Considerations regarding the correct use of EAP-Response/Identity
Document date:	2014-02-14
Group:		Individual Submission
Pages:		6
URL:
http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapidentity-00.txt
Status:
https://datatracker.ietf.org/doc/draft-winter-radext-populating-eapidentity/
Htmlized:
http://tools.ietf.org/html/draft-winter-radext-populating-eapidentity-00

Abstract:
   There are some subtle considerations for an EAP peer regarding the
   content of the EAP-Response/Identity packet when authenticating with
   EAP to an EAP server.  This document describes two such
   considerations and suggests workarounds to the associated problems.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Alan DeKok <[email-masked]>
Date: Sat, 15 Feb 2014 18:03:06 -0500

Some comments:

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.

  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.

  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.

   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.

   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.

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

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.

   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"

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.

  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.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 17 Feb 2014 10:02:15 +0100

Hi,

> to be UTF-8.  So if it's not, the supplicant is non-compliant, and

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

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

> EAP-Response/Identity to User-Name.  It's just data, so that copying is

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

>   I would suggest "user identifier", to avoid confusion with User-Name.

Sure, no problem.

>  They can be completely different.

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

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

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

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

> they should proceed to more insecure methods.  This prevents leakage.

Good idea!

>   How the supplicant determines that this is "the same" system is a

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: +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: Alan DeKok <[email-masked]>
Date: Mon, 17 Feb 2014 08:36:28 -0500

> It mentions that the *request* MAY contain displayable text, which needs

  That's worse than I remembered.

> someplace that it's outright forbidden.

  I agree.

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

  Forward anyways.  It's what they do now.  We can't mandate that 10^9
EAP supplicants upgrade.  It's probably easier to fix the AAA
infrastructure to work with broken clients.

> try the configured EAP-TTLS that the user sets.

  Weird.

> user identifier when starting EAP would lead nowhere.

  That's just dumb.  The way sane vendors deal with this is that they
allow the user to choose which identity to use.  It's ridiculous for the
vendor to force a particular identity on the user / device.

> again someplace in the future.

  Yes.  The RFCs are unfortunately silent on a wide variety of topics.
RFC 2865 even says:

      The secret MUST NOT be empty (length 0) since this would allow
      packets to be trivially forged.

  Because I ran into a vendor who didn't allow admins to set a shared
secret... and always used a zero-length string.  It *was* allowed in RFC
2158.  I poked the RADIUS WG, and everyone was appalled.

> the EAP method's user identifier.

  The idea was to allow *provisioning* of the Response/Identity.
Automatically deriving it from the method-specific "user identity" is
just as bad as automatically using a 3GPP identity.

> the draft gets adopted in ... "some" working group. Suggestions welcome :-)

  I'd support a "roaming inter-operations" WG.  Some of the documents
now in RADEXT could move there, and maybe DIME.  This document could
live there.

  The goal for the WG would be to define inter-domain standards for
authentication, accounting, EAP, etc.

  Alan DeKok.

---

From: Josh Howlett <[email-masked]>
Date: Mon, 17 Feb 2014 16:33:45 +0000

>authentication, accounting, EAP, etc.

+1, excellent idea. draft-wierenga-ietf-eduroam, if generalised, could
provide a good basis on which to define the issues that need addressing.
If it were broader than "roaming" then ABFAB could also fall into scope.

Josh.

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: Sam Hartman <[email-masked]>
Date: Fri, 14 Feb 2014 11:11:15 -0500

Hi.
My life has been hectic, and I completely dropped the ball on this!
Thanks for doing this.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Feb 2014 10:19:53 -0500

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   The idea was to allow *provisioning* of the
    Alan> Response/Identity.  Automatically deriving it from the
    Alan> method-specific "user identity" is just as bad as
    Alan> automatically using a 3GPP identity.

Unfortunately in contexts like ABFAB, you're only going to have one
username.
I appreciate that there are environments where you need a different
outer username, but I think we want to be moving towards anonymous outer
usernames derived from the realm, and I do not support a spec that would
make that more difficult.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 19 Feb 2014 13:32:15 +0100

Hi Stefan:

I have taken a look to this draft. Regarding the conversion to UTF-8 nothing to say.

Regarding 

"1.  The choice of identity to send in EAP-Response/Identity may have
       detrimental effects on the subsequent EAP type negotiation."

as far as I remember, it was discussed long time ago as a problem of network selection (http://tools.ietf.org/html/rfc5113). See section 2.2. Identity Selection. Your approach here (if I properly understood) seems to allow the user to try all the identities before reporting an error (note that this may imply association/dissociation processes at link-layer to re-start the whole authentication process). The approach there is to provide the user with the required information to select the right username. 

In the particular case of WiFi networks it would be also good to take a look to IEEE 802.11u and hotspot 2.0 (e.g. these slides, which you may already know, are interesting http://www.terena.org/activities/tf-mobility/meetings/26/07-11u-Dave.pptx)

Just my 0.02 cents.

Best Regards.

P.D: Btw, I agree with Alan: it would good to have a "roaming inter-operations" WG. 

P.D.2: Among other things, it would be also good if some information about accessible realms from a NAS could be provided in a dynamic way to the peer. 

El 14/02/2014, a las 10:08, Stefan Winter <[email-masked]> escribió:

> <0x8A39DC66.asc>_______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------