[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: