Re: Do ipsec vendors care about privacy?

[Russ Housley <housley@vigilsec.com>]

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