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

Re: [Cfrg] Re: Changing the key deriveration



On Sat, 14 Feb 2004 at 03:21:00 +0200 (IST) Hugo Krawczyk
commented:

> In this case, however, there is zero cost. No
> real specification or implementation complexity. No performance issue at
> all.  No delay in advancing the document (a two-minute change to the
> draft). 

I've spent more than 15 minutes trying to find out exactly where the
objectionable material resides.  Previous messages have referred to
sections 2.14, 2.15, and 2.16.  In draft-ietf-ipsec-ikev2-12.txt, the
only case of the cross-algorithm keying seems to be in section 2.15,
"Authentication of the IKE_SA", first paragraph.

In defense of the mechanism, we see that the value never appears on
the wire.  It's unlikely to create any problems.

Against it, we see that (as Greg Rose pointed out), the key was
created for one algorithm and might not have enough entropy to be used
safely for another.  And, as Hugo points out, it is needlessly
unclean.  In fact, wouldn't it be better to use SK_d for the purpose of
generating the not-on-the-wire authenticating value?  This would avoid
having to generate two additional keys --- given that the additional
keys would be generated with the prf and SK_d anyway, the security
analysis seems a toss-up.

I don't see any misuse of keys in section 2.16, "Extended
Authentication Protocol Methods", though it might be implicit in a
formula and I'm just not seeing it.

Hilarie