Subject: Question regarding user identity confidentiality

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 6 Jun 2003 15:20:36 +0200

hi all, 

i have read the ikev2 tuturial and ikev2 and i have a question about the
user identity confidentiality: 

before secure legacy authentication was added to ikev2 i agreed with the
selected user id confidentiality approach where the identity of the
initiator is revealed first. at that time it is was difficult to assume a
client-server architecture (i.e. which entity starts ike) and therefore
which entity has to be protected. 

for remote access solutions using secure legacy authentication (by using
eap) things are a little bit different. 

with eap you have the following message flow (taken from section 3.16 of
[draft-ietf-ipsec-ikev2-08.txt]):

    Initiator                          Responder
      -----------                        -----------
       HDR, SAi1, KEi, Ni         -->

                                  <--    HDR, SAr1, KEr, Nr, [CERTREQ]

       HDR, SK {IDi, [CERTREQ,] [IDr,]
                SAi2, TSi, TSr}   -->

                                  <--    HDR, SK {IDr, [CERT,] AUTH,
                                                EAP }

       HDR, SK {EAP, [AUTH] }     -->

The draft says "By including an IDi payload but not an AUTH payload, the
initiator has declared an identity but has not proven it." (message 3)

Section 3.16 additionally says: "Note that since IKE passes an indication of
initiator identity in message 3 of the protocol, EAP based prompts for
Identity SHOULD NOT be used." 

To me this seems that protection of the user identity against an active
attack cannot be provided for eap methods (except if tunneled methods are
used). this seems to have some disadvantages for remote access solutions
where you have a client-server relationship. 

possible solutions are: 

a) ignore user id conf. 
b) suggest to use a tunneled method within ikev2/eap when user identity
confidentiality is required. this clearly has a performance disadvantage
since you create two tunnels (for server to client authentication) in
addition to the eap method for client to server authentication. 
c) change the handling for secure legacy auth. and let the responder
authenticate to the initiator first
d) others? 

am i wrong with my observations? 

ciao
hannes

---

From: Hugo Krawczyk <[email-masked]>
Date: Sat, 7 Jun 2003 02:48:48 +0300 (IDT)

Hannes,

You are late to this party...
This issue has been discussed in a couple of threads in this list
(the last of which took place in March and carried the subject
"Do ipsec vendors care about privacy?").
This represented my failed attempt to get the WG to decide on what seems 
as the obvious requirement to protect the user's id in the EAP exchange. 
Even the "provocative" subject of the thread (and the positive answer to
that question given by several ipsec vendors) was insufficient to market
the idea. If you read the thread you'll see some people claiming that
doing so would add significant complexity to the protocol. I do not agree.
I have the feeling that a silent majority would have supported this,
but that's how silent majorities work, they  remain silent... :)

Hugo