Subject: [eap] Issue 124: Identity Protection

From: [email-masked] (Bernard Aboba)
Date: Sat, 10 May 2003 08:30:15 -0700 (PDT)

Issue 124: Identity Protection
Submitter name: Mark Schurman
Submitter email address: [email-masked]
Date first submitted: May 6, 2003
Reference:
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.

---

From: [email-masked] (Jari Arkko)
Date: Sat, 10 May 2003 21:01:47 +0300

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

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

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

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Sat, 10 May 2003 19:45:47 -0700 (PDT)

> "[email-masked]"? This does not appear to have been specified anywhere.

In fact, the RFC 2284bis doesn't say anything at all about what can be in
the Identity Response -- not even that it should contain an NAI. I think that's
intentional, actually. If the goal is to specify this, then I'd suggest
an update to RFC 2486 (as you've proposed), or a change to RFC 2869bis.

> authenticator is going to ask it to do?

Yes. It only knows what methods it would accept. The peer could be set to
only accept methods that support identity protection, and therefore could
provide a userid-less response to the Identity Request.

> enough identity response for M2 & M3?

If the peer cares that much about identity protection, it won't accept M2
and M3. Otherwise, I think it has to provide the identity, since it won't
know whether it will be asked to do M1, M2 or M3.

> support identity privacy, then you don't send full identity

Yes, that makes sense to me.