Re: [IPsec] [ippm] WGLC on draft-ietf-ippm-ipsec-03

[Tero Kivinen]

Kostas Pentikousis writes:
> (adding ipsec folks in CC)

I quickly read this document and I think it needs much broaders review
from the IPsec people. This document is using internal IKEv2 keying
material outside IKEv2 SA context, meaning it can cause problems with
the actual security of the IKEv2 SA.

It uses

Shared secret key = PRF( SKEYSEED, "IPPM" )

to generate the shared key to be used in the ippm. The SKEYSEED is
internal IKEv2 keying material, and should not be exposed outside
IKEv2. All IKEv2 keying material to protect the IKEv2 SA is also
derived from that value. The generation looks quite safe, so it most
likely do not directly cause IKEv2 SA to be broken, but also as
SKEYSEED is internal to the IKEv2, it might not be available at all
outside the IKEv2 library. For example my IKEv2 code will never store
the SKEYSEED, it is temporary calculated and then used to calculate
the derived SK_* keys, and then immediately zeroed out.

It would be much better to use the SK_d or KEYMAT which is derived
from the SK_d for that purposes, as that is what SK_d was meant to be
used, (i.e to derive keys for other uses than IKEv2 SA protection or
authentication).

Also the section 4.1 talks about the lifetime of the shared secret
key, but I have no idea what expire time it is refering to. If it
refers to the Shared secret key generated above, then where is its
expire time defined?  IKEv2 does not negotiate lifetimes, and IKEv2 SA
rekey is the closest thing we have about lifetime in the IKEv2, but
the text explictly says that "shared secret key generated" can
continue to be used...

Anyways I thing this document needs more reviews especially from the
IPsec community, as it is using IKEv2 as KMP for something else than
IPsec (which is not a wrong thing to do, but you need to know what you
are doing).
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IP Security for multiple interfaces

[Daniel Migault]

Hi,

We believe our document for multiple interfaces security using IPsec
 is closed
to its final version.

To go further we collect interests of various WG concerned by multiple
interfaces. So please let us know:

- 1) if you think this topic is of interests and should be addressed
- 2) if you would like to review the documents

Comments on the draft are also welcome!

BR,
Daniel

[1] http://tools.ietf.org/html/draft-mglt-ipsecme-clone-ike-sa-02


-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Diet-ESP

[Stephen Kent]

Daniel,

I read the very brief IV-generation I-D and I didn't see an explanation 
of how
to perform IV "compression." As someone else already noted on the list, 
an IV
is carried with each packet to enable decryption of packets that may 
arrive out
of order. Thus it's not enough to have each peer use the same PRF and 
seed to
generate IVs which are not explicitly transported, because of this 
requirement.
Also, if the IV is required to be pesudorandom, there is likely no 
opportunity
for compression in the usual sense. Finally, note that the specs for 
algorithm
modes like GCM treat the IV as a security critical piece of info, for 
good reason.
Thus if one tries to re-use a value such as an ESP sequence number as an 
IV, all of
the ESP sequence number generation/management code becomes security 
critical wrt
algorithm mode evaluation. This topic was discussed in London in the TLS 
WG meeting,
when considering use of Cha-Cha. I can forward the relevant messages and 
my slides

if you wish.

Steve

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec