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

ISAKMP + IKE, questions.

Hello,

a few questions about draft-ietf-ipsec-isakmp-{10,oakley-08}.txt.

The questions concern Cookie Exchange to protect against Denial-of-Service,
PRF, IV generation in phase 1 resp. 2 and finally size of the Diffie-Hellman
groups.

In '1.7.1 Anti-Clogging' it is stated:

	A ``cookie'' or anti-clogging token (ACT) is aimed at protecting the
	computing resources from attack without spending excessive CPU
	resources to determine its authenticity. [...]
	Such aggressive memory management techniques SHOULD be employed by
	protocols using ISAKMP that do not go through an initial, anti-
	clogging only phase, as was done in [Karn].

Originally in Photuris the Responder Cookie was generated on behalf of a
Cookie Request from the Initiator. The Responder would not create any state
at all. The cookie is generated by hashing i.a. a local secret. The passage
in the draft should probably be modified to:

	A ``cookie'' or anti-clogging token (ACT) is aimed at protecting the
	responder against resource starvation, e.g. spending exessive CPU
	resources to determine its authenticity or exessive memory allocation
	due to faked initiator messages.

In '2.5.3 Anti-Clogging Token (``Cookie'') Creation' it is stated:

	' ... the cookie be unique for each SA establishment to help prevent
	replay attacks, therefore, the date and time MUST be added to the
	information hashed.'

This passage seems to be very implementation dependant. Hashing the date and
time will force you to keep state. The section should probably state:

	' ... the cooke be unique for each SA establishment to help prevent
	replay attacks, therefore, a conforming implementation MUST ensure
	that the generated cookies are unique.'

In 4.1 ISAKMP Exchange Types:

	Additionally, none of the examples include an initial exchange of
	ISAKMP Headers (containing initiator and responder cookies) which
	would provide protection against clogging (see section 2.5.3).

All in all, the draft is not very precise about how the cookies protect
against clogging.  The easiest solution would probably be to remove the
references to Denial of Service in sections 1.7.1 and 2.5.3 and define
the cookie pairs as a token which is used to reference the ISAKMP SA.

Another solution would be to add a Cookie Exchange to Main Mode in IKE,
or define a new exchange type 'Conservative' which adds a separate Cookie
Exchange at the beginning and afterwards just proceeds as Main Mode does.

In Appendix A of oakley-08.txt:

	- PRF
	There are currently no pseudo-random functions defined.

is a bit confusing when you want to lookup what prf does. One should probably
add a sentence like:
	
	'When no prf has been negotiated the HMAC version of negotiated hash
	algorithm is used (see 4. Introduction).' 

In Appendix B of oakley-08.txt:

	'Subsequent messages MUST use the last CBC encryption block from the
	previous message as their initialization vector.'

Normally I would interpret this as using the last CBC encypted block from
the last message I sent, virtually one CBC encryption of the concatention
of all payloads sent. It seems the SSH ISAKMP/Oakley testing site uses the
last encrypted block of the last message received. This should be clarified.
It might read as:

	'Subsequent messages MUST use the last CBC encryption block from the
	previous message received by this party.'

Regarding the predefined DH groups, MODP(1-2) and EC2N(3-4). The group
orders are probably not high enough, at least when only considering
the time complexities (as stated in P1363).

The DL in MODP1 has an asymptotic running time of O(2**72) and in MODP2 in
O(2**82) using GNFS with

	O(exp(1.9223 * (ln q)^(1/3) (ln ln q)^(2/3))).

For large groups finding the DL using GNFS is probably infeasable because
of storage complexity.

For EC2N this is about O(2**76) for group 3 and O(2**91) for group 4, roughly. Also, for the elliptic curve case there have been rumours that composite
exponents reduce the time needed to obtain the DL.

Since nearly all implementations will support at least the predefined groups,
it would be advisable to include groups in the draft with group orders high
enough to derive keys for at least 3DES.

In the section about Security Consideration there should be paragraph which
discusses how many key bits are assumed to be derivable from the predefined
groups.

It might also be helpful for implementors if references to

	P1363 (http://stdsbbs.ieee.org/groups/1363/) 

or perhaps

	A. Menezes, Elliptic Curve Public Key Cryptosystems, Kluwer
	Academic Publishers, 1993.

would be added.

Greetings,
	Niels

- PHYSnet Rechnerverbund     PGP V2.6 Public key via finger or key server
  Niels Provos               
  Universitaet Hamburg       WWW: http://www.physnet.uni-hamburg.de/provos/   
  Jungiusstrasse 9           E-Mail: provos@wserver.physnet.uni-hamburg.de
  Germany 20355 Hamburg      Tel.:   +49 40 4123-2404     Fax: -6571