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

RE: Question regarding user identity confidentiality



You are right that the solution you propose achieves user's id protection,
and that it is trivial to specify this solution given the current text.
However, it is also true that this adds a round-trip to the protocol.
It seemed from the discussion in the past on this issue that people 
did not consider this as a justified trade-off between privacy and 
communication latency.

In any case, I believe that the WG made a decision here. One that I do not
like but certainly not one that can be blamed on people not paying
attention. If you want to support the review of this issue during last
call you should support Scott Kelly's recent motion in this regard.
(Having said the above, I am quite sure that if this issue would have
brought to a "show of hands" in an ipsec meeting there would have been
majority to the identity protection measure -- provided that someone
presented the options and their trade-offs in that same meeting).

 Hugo

On Tue, 10 Jun 2003, Tschofenig Hannes wrote:

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