Re: Do ipsec vendors care about privacy?

["Scott G. Kelly" <scott@airespace.com>]

Hi Russ,

I think Hugo may have something here. Lots of us implementers get so
busy sometimes that we overlook things which are important, and I think
this is one of them (at least in my case). This problem becomes much
more immediate when you consider that wireless lan access is in some
cases indistinguishable from remote access, and that exposing the user
identity on a public network is an issue under such circumstances. I
think we should consider this before ruling out the change.

Scott

Russ Housley wrote:
> 
> Hugo, in my view it is too late to be raising a question that will cause
> major surgery on the document.  It is time to fix things that are broken,
> make the document internally consistent, and publish it.  I do not think it
> is time to raise new requirements.
> 
> Russ
> Your local, friendly, incoming Security Area Director
> 
> At 05:34 AM 3/19/2003 +0200, Hugo Krawczyk wrote:
> >The catchy subject is mainly to grab the attention of ipsec vendors in this
> >list (but it also reflects the contents of this note).
> >
> >The question that I want to resurrect is whether leaving the user's identity
> >open to active disclosure attacks as done now in the "legacy authentication"
> >solution of IKEv2 (described in section 2.16 of ikev2-05) is a reasonable
> >decision given that protecting against such attacks can be done at a moderate
> >price (see explicit specification below). This decision seems especially
> >dubious given that the roaming/remote user scenario is the only case in which
> >identity protection clearly makes sense, and constitutes a natural requirement
> >for ipsec solutions in the legacy authentication world.
> >
> >I raised this question some time ago (beginning of Feb) and its resolution
> >was mainly based on the fact that protecting the user's identity is a bit
> >more complex than not doing it. I remain unconvinced, however, that the WG
> >(in particular ipsec vendors) made here an informed decision on this
> >trade-off.
> >I got the feeling that no one was really paying attention. (The only
> >people to express opinions on this on the list were: Charlie who was
> >"genuinely conflicted about this one", Derrell Piper and I that supported
> >protecting the user's identity, and Marcus Leech who was against.)
> >
> >So before we close the ikev2 specification please take a look at what it takes
> >to change the legacy authentication protocol in ikev2 to protect the user's
> >identity from active attacks. Here are the two main candidate solutions:
> >
> >(1) Simply defer the sending of the user's identity IDi from message
> >3 to message 5 (that is, after message 4 in which the responder authenticates
> >itself).  The difficuty here is that the responder does not have IDi to base
> >its choice of EAP method in message 4. I do not know how much of a practical
> >problem this is (it was never pointed as such in the case of PIC in the ipsra
> >wg), but others will know better.
> >
> >p
> >(2) Let the responder authenticate itself already  in message 2.  This can
> >be achieved by moving the AUTH and IDr payloads from message 4 to message 2.
> >If we do not require encrypting these fields then the change is simple.
> >Adding encryption is possible but requires applying SK{} from the middle of
> >message 2 which is more complex. I suggest doing it simple, i.e. without
> >encryptioni (also integrity protection is not needed here). This leaves
> >the identity of R in the plain but this is ONLY for
> >the legacy authentication scenario in which protecting the responder
> >(server/gateway) identity is of little (or no) importance.
> >
> >Either change requires minimal change to the current specification,
> >and none has major implementation complexity. They do not change at all the
> >main protocol, and are relevant only to implementations that support legacy
> >authentication (where user's privacy is a real issue).
> >It seems to me that in this case the "complexity vs security trade-off"
> >is easily resolved in favor of the user's identity protection.
> >
> >What others think?
> >(If this time no one cares then we can easily forget about this issue; at
> >least this will help to document that this was a conscious decision of the
> >WG.)
> >
> >Hugo
> >
> >PS: I'd have liked to raise this in the meeting in San Francisco but I
> >couldn't make it. Hopefully there may still be some discussion on this there,
> >or in the list in the nexy week.
> >
> >
> >Lacking clear support for either way, Charlie
> >decided to go with the simplest solution that is now in 05. This is
> >certainly the right way to go if people do not really care about this
> >privacy issue. In this case, however, I think that this decision needs
> >to be documented in Radia's "rationale" draft (since this issue will be, I
> >bet, something critiques of ikev2 will like to highlight).
> >However, , before doing so I'd like to really sense if this is a thoughtful
> >decision, or something that no one really cares about
> >This note is intended to explicitl;y raise this issue before the closure
> >of ikev2 specification. If people still support the current solution (or
> >just shut up) then we will have a clear documentation that this decision
> >reflects the WG view (if not strong consensus).
> >
> >
> >On the other hand, I can bet
> >that the future
> >papers criticizing IKEv2 (there will be such papers no matter what we do)
> >
> >of the
> >type written about IKEv1) will critically point
> >to this issue. After all, they will say, a protocol that provides identity
> >protection  with me IF
> >
> > >
> > > Hugo Krawczyk <hugo@ee.technion.ac.il>  wrote:
> > > > The one thing that I definitely dislike in the appended proposal is
> >that
> > > > it opens IDi (sent in message 3) to active attacks.  If there is one
> > > > application where identity protection really makes sense is in hiding
> > > > identities and locations of mobile users, which will be among the main
> > > > users of SLA. I suggest to make IDi optional in message 3, and make it
> > > > clear that implementations should NOT assume that this IDi value is
> > > > available, certainly not in a way that compromises the user's
> >identity.
> > >
> > > I am genuinely conflicted about this one - like the donkey between the
> > > two bales of hay. I see equally good arguments on both sides, and I
> >
> >
> >This WG has a long tradition of making decisions that become controversial
> >later (see the paper by Kaufman and Perlman, ,Ferguson and Scneier, etc).