Re: Question regarding user identity confidentiality

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

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



On Fri, 6 Jun 2003, Tschofenig Hannes wrote:

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