Subject: [eap] Proposed resolution to Issue 124: Identity Protection

From: [email-masked] (Bernard Aboba)
Date: Sat, 10 May 2003 20:44:11 -0700 (PDT)

The text of Issue 124 is given below. The proposed resolution is as
follows:

Change text in Section 5.1 from:
"The Identity Type is used to query the identity of the peer.
Generally, the authenticator will issue this as the initial
Request. An optional displayable message MAY be included to prompt
the peer in the case where there expectation of interaction with a
user. A Response of Type 1 (Identity) SHOULD be sent in Response
to a Request with a Type of 1 (Identity).

Since Identity Requests and Responses are not protected, from a
security perspective, it may be preferable for protected method-
specific Identity exchanges to be used instead."
To:
"The Identity Type is used to query the identity of the peer.
Generally, the authenticator will issue this as the initial
Request. An optional displayable message MAY be included to prompt
the peer in the case where there expectation of interaction with a
user. A Response of Type 1 (Identity) SHOULD be sent in Response
to a Request with a Type of 1 (Identity).

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
providing only the realm portion of the NAI [RFC2486])"

------------------------------------------------------------------
Issue 124: Identity Protection
Submitter name: Mark Schurman
Submitter email address: [email-masked]
Date first submitted: May 6, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-May/001183.html
Document: EAP-02
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
I had a few comments on this doc, with regards to identity protection:

Page 4: When the term Confidentiality is defined, it includes the sentence
"A method making this claim MUST support identity protection." However,
"identity protection" is not defined in this list, and is not seen until
page 29. This list should include a quick description for the term.

Page 5, heading 2, point 1: This paragraph mentions that the initial
Identity Request is optional, and gives a few scenarios as examples. I'd
suggest adding identity protection in this list as well. (Knowing that
some implementations can determine it from other information is somewhat
useful, but it seems more useful to me to state that, even if the identity
can't be determined yet, delaying the identity request could be desirable
from a security standpoint.)

Page 29: Heading "Identity Protection", paragraph 1: Should we provide
more details on this? One question I had was whether a complete identity
response could be delayed only at the EAP server's discretion (by delaying
the identity request), or if the EAP peer (client) could unilaterally
choose to delay the complete identity response. For example, if the client
were configured to perform an EAP type that supports identity protection
(like PEAP), which of the following statements is appropriate, or do we
want to leave this unspecified in the draft?

A) The EAP peer MUST always respond to an identity request with complete
identity information. [The next paragraph in the draft qualifies this,
describing different requirements for the peer-name portion vs. the realm
portion of the identity response.]

B) In cases where the EAP peer is performing an EAP type that supports
identity protection, the EAP peer {SHOULD, MAY} respond to an identity
request with {complete, complete or partial} identity information.

C) In cases where the EAP peer is performing an EAP type that supports
identity protection, the EAP peer MAY disregard the initial (cleartext)
identity request, providing an incomplete [or blank?] response. However,
the EAP peer {SHOULD, MUST} provide complete identity information to the
protected identity request.

or some other permutation. Is this information / behavior that we want to
require/restrict, allow/disallow, or leave unspecified?
I also have one comment on page 10. The first sentence in this paragraph
and the last sentence in the paragraph seem to contradict - may be we need
to remove the first sentence completely.

Lower layer CRC or checksum is not necessary. In EAP, the authenticator
retransmits Requests that have not yet received Responses, so that EAP
does not assume that lower layers are reliable. Since EAP defines its own
retransmission behavior, when run over a reliable lower layer, it is
possible (though undesirable) for retransmission to occur both in the
lower layer and the EAP layer.

If lower layers exhibit a high loss rate, then retransmissions are likely,
and since EAP Success and Failure are not retransmitted, timeouts are also
likely to result. EAP methods such as EAP TLS [RFC2716] include a message
integrity check (MIC) and regard MIC errors as fatal. Therefore if a
checksum or CRC is not provided by the lower layer, then some methods may
not behave well.

[jari arkko]:

> Page 29: Heading "Identity Protection", paragraph 1: Should we provide
> more details on this? One question I had was whether a complete identity
> response could be delayed only at the EAP server's discretion (by
>  delaying the identity request), or if the EAP peer (client) could
> unilaterally choose to delay the complete identity response. For
> example, if the client were configured to perform an EAP type that
> supports identity protection (like PEAP), which of the following
> statements is appropriate, or do we want to leave this unspecified in
> the draft?
>
> A) The EAP peer MUST always respond to an identity request with complete
> identity information. [The next paragraph in the draft qualifies this,
> describing different requirements for the peer-name portion vs. the
> realm portion of the identity response.]

This may be the best we can do. But the current draft sections 7.3 and
5.1 appear incomplete with regards to how you actually leave the username
portion out. Should I send "@foo.com" or "foo.com" or perhaps even
"[email-masked]"? This does not appear to have been specified anywhere.

> B) In cases where the EAP peer is performing an EAP type that supports
> identity protection, the EAP peer {SHOULD, MAY} respond to an identity
> request with {complete, complete or partial} identity information.

The peer may support many things, but how does it know what the
authenticator is going to ask it to do?

> C) In cases where the EAP peer is performing an EAP type that supports
> identity protection, the EAP peer MAY disregard the initial (cleartext)
> identity request, providing an incomplete [or blank?] response. However,
> the EAP peer {SHOULD, MUST} provide complete identity information to the
> protected identity request.

Again, it is unclear to me what the order of events is. Assuming the
peer supports M1, M2, and M3 where only M1 supports identity
protection, does this mean that the peer never provides a good
enough identity response for M2 & M3? If yes, the introduction of the
first
identity-protecting method would disable all other methods...
This appears to be a problem for all alternatives A-C, assuming
the 7.3 approach is considered a part of A.

Policy would be one way of fixing this problem. Policy could say
that now we will use identity protection. In general, I'm
not too happy about introducing new policy knobs, however.
Perhaps we could say that if all the methods you are prepared
to accept (in terms of policy and availability of credentials)
support identity privacy, then you don't send full identity
information?

---

From: [email-masked] (Jari Arkko)
Date: Sun, 11 May 2003 09:48:46 +0300

> providing only the realm portion of the NAI [RFC2486])"

Very good.

But I'm still wondering whether we should be more explicit
about what the spec says about the format of Identity
Responses. In issue 33 we decided not to tie the Identity
Response to always be a NAI. (Is that decision still wise,
if we intend to update NAI RFC later? Perhaps it is, we can't do the
update simultaneously...) Anyway, should we be more explicit
in Section 5.1 that this is the case? For instance: "Note that
the identity is often represented as a NAI [RFC2486], but
this specification allows any format to be used."

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Sun, 11 May 2003 05:25:01 -0700 (PDT)

> (Is that decision still wise,
> update simultaneously...)

We have to decide if we're going to make RFC 2284bis dependent on RFC
2486bis.

> Anyway, should we be more explicit

I think the point is that the NAI is not required for peer-to-peer
authentication or use outside of roaming. However, if the EAP
peer wishes to support roaming, then the NAI format is required. Something
along those lines should probably be stated in RFC 2486bis.

---

From: [email-masked] (Jari Arkko)
Date: Sun, 11 May 2003 23:54:35 +0300

> We have to decide if we're going to make RFC 2284bis dependent on RFC

I really don't want additional dependencies, so the choices are
really referring to 2486 classic, or none at all... if we refer
to it I'm sure folks will pick up the 2486bis later when it comes
out even if 2284bis isn't updated for the reference. However,
if we put in the reference now to 2284bis, this will restrict
the current usage to current 2486.

Thus it appears that the possible choices we have are:

    (1) Leave the format open (maybe add a note that typically
        NAI is used)
    (2) Reference 2486 and describe the additional cases
        such as domain-only-for-id-protection in 2284bis.

--Jari