Subject: [eap] Proposed Resolution to Issue 189: Handling of the Identity Response

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Nov 2003 22:15:49 -0800 (PST)

The text of Issue 189 is enclosed below.  The proposed fix is as follows:

In Section 5.1, change:
"Since Identity Requests and Responses are not protected, from a privacy
perspective, it may be preferable for protected method-specific Identity
exchanges to be used instead. Where the peer is configured to only accept
authentication methods supporting protected identity exchanges, the peer
MAY provide an abbreviated Identity Response (such as omitting the
peer-name portion of the NAI [RFC2486]). For further discussion of
identity protection, see Section 7.3."

To the following:

"It is RECOMMENDED that the Identity Response be used primarily
for routing purposes and that EAP Methods SHOULD include an
method-specific mechanism for obtaining the identity, so that
they do not have to rely on the Identity Response. Identity
Requests and Responses are not protected, so from a privacy
perspective it is preferable for an EAP method to include its
own protected identity exchange. The Identity Response may
not be the appropriate identity for the method; it may have
been truncated or obfuscated so as to provide privacy; or it
may have been decorated for routing purposes. Where the peer
is configured to only accept authentication methods
supporting protected identity exchanges, the peer MAY
provide an abbreviated Identity Response (such as omitting
the peer-name portion of the NAI [RFC2486]). For further
discussion of identity protection, see Section 7.3.

--------------------------------------------------------
Issue 189: Handling of the Identity Response
Submitter name: Joe Salowey
Submitter email address: [email-masked]
Date first submitted: 10/30/3003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-October/001787.html,
http://mail.frascone.com/pipermail/public/eap/2003-October/001788.html
Document: RFC2284bis
Comment type: 'E'ditorial
Priority: '1' Should fix
Section: Section 5.1 and Section 2.2
Rationale/Explanation of issue:

The data in the EAP-Identity Response method is typically provided to a
method for processing.  There are several reasons why a method may not
be able to process this identity.  First the identity may not be the
appropriate identity for the method chosen by the server.  Second the
identity may have been decorated to ensure that it is routed correctly
to the appropriate EAP-Server.

The recommendation is to suggest that the EAP-Identity response be used
primarily for routing and method selection.  EAP-Methods should provided
a separate mechanism for obtaining identity and not rely upon the
identity response.  Many proposed methods already have a way to do this.

Requested change:

Modify the following text in section 2.2:

"Since some EAP authentication methods may wish to access the Identity,
implementations SHOULD make the Identity Request and Response accessible
to authentication methods (Types 4 or greater) in addition to the
Identity method.  However, it is recommended that future EAP Methods not
rely upon the identity received in the Identity Response and have an
alternate way of obtaining identity.  There are several reasons why a
method may not be able to process this identity; the identity may not be
the appropriate identity for the method chosen by the server, the
identity may have been decorated to ensure that it is routed correctly
to the appropriate EAP-Server, or the identity may have been truncated
or obfuscated for privacy reasons.  It is recommended that the identity
be used primarily for routing the request to an appropriate EAP server
and that the identity response be ignored by the EAP Method. The
Identity Type is discussed in Section 5.1."

I 'm not sure we need to add anything to section 5.1 (although I think
the implementation note needs to be fixed).  There may be security
considerations: in order to prevent mechanisms from revealing too much
information about valid users method implementations may always ignore
the identity response and use the mechanism specific identity query.
The reason is that the Data in the Identity Response may not be
the appropriate identity for the method chosen by the server: the identity
may have been decorated to ensure that it is routed correctly by a NAS or
Proxy AAAA Server to the appropriate EAP-Server, or the identity may have
been truncated or obfuscated for privacy reasons. It is recommended that
the Identity Response Data be used primarily for routing the request to an
appropriate EAP server and/or selecting an EAP method, and that the
Identity Response Data be ignored by subsequent the EAP Method. Identity
Type is discussed in Section 5.1.

[John Vollbrecht]

how about:

When an EAP Identity Method is used, Data in the EAP-Identity Response is
typically provided to subsequent EAP Methods.  The subsequent Method MAY
use this in its processing its algorithm.  Note that the information in
the Identity Response is primarily used for routiing following EAP requests
and for selecting a method to process the request.  A method SHOULD NOT use
information in the Identity response as the actual Identity to be
authenticated.

[Joe] I'm not sure about the last sentence. The SHOULD NOT may conflict
with the previous MAY.  How about.
"A method SHOULD provide a method specific means for obtaining identity
so it does not have to rely upon the information in identity response.

[John] I understand your point.  I was trying to say that the algorithm
MAY use the information, otherwise why would we give it to him?  However, it
should not use it as the method's identity.  Note that it may use the
identity or identity as modified by the NAS to select which EAP method to
use.  That is different than using it in the method.

[Joe] Isn't the method section is done before the method gets the
identity?  Some existing methods may require the identity that is why it
should be provided to the method.  I think we want to discourage
reliance on the identity response in methods moving forward.

[John] I think the Identity may be used by some methods (actually I am not
sure this is true) which are capable of doing whatever treating of the
method to get its meaning.  However some methods may also use the identity
from the RADIUS User-ID to get the identity.  These are not the same, as
the NAS may modify the EAP Identity data to support RADIUS proxy routing.

I am thinking the second case [routing] is governed by a set of rules
agreed to by the organization of clients and NASs not covered in this
spec. This is ok.

The first case - where the method uses the Identity Response data from the
previous request as an identity does not seem right.  In thinking about it
I am not sure it actually happens in any implementations [as opposed to
selecting the method instance based on the Response Data].  I think this
is what you are saying should be discouraged, and I am wondering if it is
SHOULD or MUST not.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap