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

Re: IPSEC WORKING GROUP LAST CALL



>    Encryption keys used to protect the ISAKMP SA are derived from
>    SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long
>    enough to supply all the necessary keying material an algorithm
>    requires, the key is derived from feeding the results of a pseudo-
>    random function into itself, concatenating the results, and taking
>    the highest necessary bits.
> 
>    For example, if (ficticious) algorithm AKULA requires 320-bits of key
>    (and has no weak key check) and the prf used to generate SKEYID_e
>    only generates 120 bits of material, the key for AKULA, would be the
>    first 320-bits of Ka, where:
> 
>        Ka = K1 | K2 | K3
>    and
>        K1 = prf(SKEYID_e, 0)
>        K2 = prf(SKEYID_e, K1)
>        K3 = prf(SKEYID_e, K2)
> 
> I'm not really clear as to what we do if SKEYID_e has enough bits to
> provide us with the encryption key we're looking for.  Perhaps one of
> the following clarifications is appropriate?  (Without the
> clarification, there exists a definite ambiuity).

What's unclear!!??  It says quite succinctly "When SKEYID_e is not long
enough to supply all the necessary keying material ...".  So do this when
it's not long enough.  DO NOT do this when it is.

>    Encryption keys used to protect the ISAKMP SA are derived from
>    SKEYID_e in an algorithm-specific manner.  If SKEYID_e is long enough
>    to supply the necessary keying material the algorithm requires, then
>    it is used without modification.  If it is not long enough, the key
>    is derived from feeding the results of a pseudo-random function into
>    itself, concatenating the results, and taking the highest necessary
>    bits.
> 
>    For example,...
> 
> or
> 
>    Encryption keys used to protect the ISAKMP SA are derived from
>    SKEYID_e in an algorithm-specific manner.  The key material is
>    generated by taking the high order bits of the following string K:
> 
>        K = K1 | K2 | K3 | ...
>    where
>        K1 = prf(SKEYID_e, 0)
>        KN+1 = prf(SKEYID_e, KN)
> 
>    and 0 is represented by a single octet.
> 
>    For example, if (ficticious) algorithm AKULA requires 320-bits of key
>    (and has no weak key check) and the prf used to generate SKEYID_e
>    only generates 120 bits of material, the key for AKULA, would be the
>    first 320-bits of Ka, where:
> 
>        Ka = K1 | K2 | K3
>    and
>        K1 = prf(SKEYID_e, 0)
>        K2 = prf(SKEYID_e, K1)
>        K3 = prf(SKEYID_e, K2)
> 
>    where prf is the negotiated prf or the HMAC version of the negotiated
>    hash function. Each result of the prf provides 120 bits of material
>    for a total of 360 bits. AKULA would use the first 320 bits of that
>    360 bit string.
> 
> I'm also not certain to do in the case where the first 8 bytes of this
> keystring are weak.  Do we instead take bytes 1-9, or bytes 9-16?  Does
> anyone see the need to include the weak key check in 3DES-CBC?  If so,
> do we not allow keys for which any of the DES keys is weak, or only keys
> where all three are weak?  If the first is the case, shold we allow
> non-contiguous keys?  (ie, if bytes 9-16 are a weak key, do I build my
> 3DES key from bytes 1-8, 17-24 and 25-32, or take the contiguous block
> of bytes 17-40 or 25-48?)

That is an algorithm specific issue.  What's weak???  That is not something
that IKE can determine without knowing every encryption algorithm.  What is
an acceptable fallback when it is weak???  That is also something that IKE
should not know.  The question of 3DES has been beaten to death.  Please
see the archives.  For algorithm specific weak key checks, please refer to
the appropriate document.

Dave


References: