[radext] Fwd: New Version Notification for draft-winter-radext-populating-eapidentity-01.txt

[Stefan Winter <[e-mail]>]

Hi,

just to let you know that I've updated my "homeless" draft regarding the
interplay of EAP methods, EAP-Response/Identity and the AAA User-Name field.

As per the discussion at IETF90, I have removed the claim that
intermediate proxies or pass-through authenticators might drop the
packet due to malformedness as this has not been observed in the wild.

The general point in that regard, the possibility of mis-routing the
packet due to different interpretations of the content by intermediate
systems, is still as valid as it was before :-)

There was a comment about RFC3748 and RFC3579's identity hints in
EAP-Request/Identity which could help alleviate one of the two problems
in the draft (client has multiple identities to choose from; and EAP
negotiation is not enough for an exhaustive try).

The provisions in RFC3579 are not sufficient to solve the problem, because

* EAP-Request/Identity is optional in some scenarios; peers can (and at
least in the Wi-Fi case, typically *do*) initiate the conversation with
their EAP-Response/Identity (EAPoL-Start) immediately; i.e. they make
the identity selection at a point in time where no hint is available

* EAP-Request/Identity may be sent by the NAS instead of the EAP server,
and the NAS may not have all identity hints available if it is part of a
large multi-operator network (e.g. if a roaming consortium contains
thousands of realms, while the NAS only has a "Default Route" to a
clearinghouse).

* The piggybacking of identity hints in EAP-Request/Identity after a NUL
separator is in general a horrible hack. It is bound to fail *at least*
in a situation where the list of acceptable realms gets longer than 1020
octets (which is a tiny amount when again looking at a roaming
consortium with thousands of realms), see RFC3748 section 5.1. So even
if the NAS or a RADIUS server has the full list of realms, it may not be
able to send it.

A much more general solution than trailing bytes in an optional Request
packet are needed, unfortunately.

Also, none of this removes the second problem which the draft addresses,
namely the requirement of UTF-8 encoding for the EAP-Response/Identity.

Greetings,

Stefan Winter

-------- Forwarded Message --------
Subject: New Version Notification for
draft-winter-radext-populating-eapidentity-01.txt
Date: Mon, 27 Oct 2014 04:51:49 -0700
From: [e-mail]
To: Stefan Winter <[e-mail]>, Stefan Winter
<[e-mail]>


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

Name:		draft-winter-radext-populating-eapidentity
Revision:	01
Title:		Considerations regarding the correct use of EAP-Response/Identity
Document date:	2014-10-27
Group:		Individual Submission
Pages:		7
URL:
http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapidentity-01.txt
Status:
https://datatracker.ietf.org/doc/draft-winter-radext-populating-eapidentity/
Htmlized:
http://tools.ietf.org/html/draft-winter-radext-populating-eapidentity-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-winter-radext-populating-eapidentity-01

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