Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2

[Nico Williams <[e-mail]>]

On Thu, Apr 14, 2011 at 12:24 PM, Yaron Sheffer <[e-mail]> wrote:
> I am unfamiliar with SCRAM, and never claimed otherwise. I just quoted your
> own analysis during the ipsec ML discussion. *Still* not having read the
> documents, I'd like to remind you that any auth protocol over IKE is
> vulnerable to passive attackers until authentication is complete, channel
> binding or not.

Not if you encrypt the relevant bits with the session key agreed via
the KE payloads (which PACE sure does, near as I can tell, since the
"ENONCE" is sent protected by the session key: "IKE_PACE: HDR, SK{IDi,
[IDr,], SAi2, TSi, TSr, ENONCE, PKEi}").

But the protocol is vulnerable to an active attack.  If you
authenticate the responder with PKIX first then PACE would not be
vulnerable even to an active attack.  Certainly an option to be able
to authenticate the responder this way would be nice.

> We can apply random salt, not just salt with the user name, because the PACE
> "action" only starts at the *second* exchange of IKEv2. So we can piggyback
> a salt payload along with the Responder's notification that it supports the
> protocol.

Ah, good point.  SCRAM would not allow you to get that one round-trip
optimization because it'd be an abstraction violation to run its
initial round-trip in parallel with the KE exchange then add in the
channel binding in the second round-trip of SCRAM.  *This* could be a
good reason to not use SCRAM (though I won't concede that just yet),
but the points regarding salting and iteration count remain.

Nico
--