Re: Moving forward with IKE V2: A proposal for final edits to ikev2-04

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

A few responses below.

On Sat, 1 Feb 2003 Charlie_Kaufman@notesdev.ibm.com wrote:

> 
> 
> 
> 
> "Theodore Ts'o" <tytso@mit.edu> wrote:
> > Hugo has suggested that for EAP mechanisms that generate a shared key,
> > the responder should send an AUTH message based on the shared key in the
> > message containing the EAP(success) message, as backup in case for some
> > reason the CERT based exchange might have gotten spoofed somehow.  This
> > seems to me to be a case of gilding the lilly, and is probably not be
> > worth the extra complexity, but I encourage comment on the working group
> > about whether or not this additional twist should be included.
> 
> I agree with Hugo on this one. We've been assuming that legacy auth is
> always going to have the responder first authenticating to the
> initiator with certificates the initiator will know how to process.
> But I can imagine cases where legacy auth is mutual and the cert
> based authentication is only a formality (or perhaps skipped). For
> example, a legacy auth scheme based on EKE, SPEKE, SRP, or PDM
> might have this property. What do others think?

> 
> 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 don't
> think it matters much. But it does matter that we decide.
> 
> If IDi is included in message 3, it is exposed to active attacks.
> (Someone impersonating the gateway can learn the claimed name of the
> initiator and subsequently break the connection). We decided we
> could live with that for cert based authentication, but if the
> case for preventing it is a little stronger here. If it is not
> included in message 3, then the gateway may not be able to
> produce the challenge it needs for message 4 and the protocol could
> require an extra round trip. If we make it optional in message
> 3, the spec has to say (and the implementations have to code
> and test) all of the options.
> 
> I put a stake in the ground in ikev2-04 and said it was required
> in message 3. Do people want it to say something else? Should it
> be legacy authentication mechanism specific?

All this business of identity protection was in ipsec from day one since
Phil Karn thought it was essential. Except for a short period of
agreement with this view, this need or no-need for anonymity in ipsec's
key exchange protocol was always a source of debate.
In particular, all past proposals started with mandatory identity
protection and then relaxed it to optional (including Karn's
Photuris). The whole cryptography of the IKE (v1 and v2) protocol
is directed to support identity protection (there are more
straightforward protocols if you do not require id protection).

Was all this mess worth it? I do not know.
But if there is ONE place where identity protection makes sense is in
the remote access environment. ANd then here we are going to give it up?
Either leave it optional in msg 3, or forbid it msg 3, or define it to be
legacy method specific, but do not force its disclosure to trivial active
attacks.

 > 
> Hugo Krawczyk <hugo@ee.technion.ac.il>  wrote:
> > I have no practical (or other) experience with such key-providing
> > legacy authentication methods. However, since these are LEGACY methods
> > then I assume that if they generate a shared key then this key may be
> > intended for other uses. Can we be sure that this key (call it LK for
> > "legacy key"), if used by SLA, will be used ONLY by SLA?  Otherwise we
> may
> > end having one key LK which is used in two different settings.  In
> > particular, one may end using one key LK for two different cryptographic
> > algorithms. Are you sure that this is NOT possible?
> 
> When an authentication mechanism generates a shared
> key as a side effect, it is generally for the purpose of
> protecting subsequent data exchanges with that key. When
> used in IPsec, it is likely that the subsequent data
> exchanges will be protected with IPsec, so the key will
> have no uses other than generating AUTH.
> 
> That said, who knows what someone might do in the future.
> We could specify that using the key for anything else is
> forbidden. We could instead of using the key directly
> hash it with an IKE-related constant and use the result
> as the key. I'd be happy with either of these, though
> I believe that both are overkill.
> 
> Do you have a concrete proposal for addressing this?
> 

I am not proposing to do any of the "overkill" (and ineffective) tricks
mentioned above. I was mainly raising the concern hoping someone can shed 
light on how these keys are used.
At this point I believe that the only thing that can be done is to
have a "MUST NOT use this key for any other purpose (in IKE or elsewhere)"
kind of directive in the draft.


> Hugo Krawczyk <hugo@ee.technion.ac.il>  wrote:
> > One other question raised in the appended note is when should the AUTH
> > field be sent. Seems to me that the simplest specification is to send it
> > in the last client's message in SLA.  Even if this key (LK) is available
> > earlier, it does not buy you much to compute AUTH earlier (and you can
> > always keep the key for authentication at the end).  An early
> > authentication using LK can only help against a DoS attack mounted by a
> > MitM attacker; however I doubt that anyone will choose this costly (for
> > the attacker) way to to mount a DoS attack.
> 
> I didn't say the client's last message because for some legacy auth
> methods the exchange is variable length and the client doesn't know
> which of his messages will be the last until the server accepts it.
> 

OK.

Hugo
> 
> 
>           --Charlie
> 
> Opinions expressed may not even be mine by the time you read them, and
> certainly don't reflect those of any other entity (legal or otherwise).
> 
>