[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Question regarding user identity confidentiality



hi hugo, 

thank you for your quick response. 

> Hannes,
> 
> You are late to this party...

i know. sorry about it. 

> 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?").

i roughly followed the discussions. i will, however, look at them again. 

to provide the required protection only a single sentence needs to be
changed - no modification to ikev2 itself. 

the following sentence in section 3.16 should be changed (particularly the
should not part):

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

if user identity conf. is required then the initiator would not provide its
user identity with message 3. instead the eap-request/identity is
transmitted by the responder in message 4. message 4 authenticates the
responder to the initiator. the identity of the client is subsequently
provided with message 5 as part of the eap-response/identity message. 

using this procedure the client is can enable user identity confidentiality
only if required. 

what do you think?

ciao
hannes


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