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

issues with IKE that need resolution



  I'm compiling a list of issues with IKE that need addressing. Once
the RFCs come out of the shoot I understand IKE will again be open
for edits. To that end, here are the issues I've received. I divided
it into two sections: one for clarifications and codification of 
behavior that, while most all implementations do already, is open to 
interpretation; and, another for changes that will effect interoperability.

  Clarification and Codification:

     1. A new Diffie-Hellman group should be added. I know of vendors
	that already implement this as group 5-- that's what it should
	become:

	A MODP group with a 1536 bit prime

	The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] +  741804 }.
	Its hexadecimal value is
            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
            C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
            83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
            670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF

	The generator is 2.

     2. Verbage on the deprication of DES and the mandatory status of 3DES.

     3. Clarification of use of the commit bit in IKE. This will constrain
	the freeform (and confusing) verbage in the base ISAKMP document.
	For IKE the commit bit only makes sense in Quick Mode. Most people
	I spoke to said that they return a "INVALID_FLAGS" notify message
	if the peer tries to set it in any other mode. They also only use it
	to extend Quick Mode by a single message-- from the responder back
	to the initiator. This was its intended use anyway. Also, most
	people send this message as a final Quick Mode exchange message
	and not an Informational. The only person I spoke to who did
	otherwise said Quick Mode made more sense and was going to change.

     4. Verbage similar to what is in the IP DOI regarding lifetime
	negotiation for phase 2 has to be added to IKE for phase 1
	negotiation.

     5. What type of cert encoding is used in a cert request payload if
	you wish to obtain the peer's encryption certificate (assuming
	the peer has one signature only and one for encipherment only)?
	This might actually be a draft-ietf-ipsec-pki-req-01.txt issue and
	will defer to Rodney if that's where people think this should go.

     6. There was also some desire to add new elliptic curve groups for
	Diffie-Hellman. Perhaps new groups would be best handled by a
	separate document. What do people feel? IKE or seperate document?

     7. There's a IP DOI issue to partition the protocol (4.4.1) and
	transform (4.4.2) numberspace to reserve the bulk to IANA and
	leave some for "private use".

  Changes to affect interoperability

     1. The ISAKMP header is not authenticated! An attack can be launched
	against Quick Mode by selectively setting and clearing the commit
	bit to make one side wait for a final message that the other side
	does not think it has to send!

     2. None of the optional payloads-- cert, cert_req, notify for initial
	contact, vendor ID-- are authenticated.

  Any other things, please post. I'm generating some html for Ted to
include in http://web.mit.edu/tytso/www/ipsec and will happily include
more. Ted and Bob want a central repository of issues to focus work
on them-- and so things don't get forgotten

  Dan.



Follow-Ups: