Clarification that doesn't effect interoperability

• A new Diffie-Hellman group should be added. There are already 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.
  

• 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 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 who did otherwise said Quick Mode made more sense and was going to change.
• 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.
• 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)?
• Addition of new elliptic curve groups. Possibly add groups over F2^p, where p is prime. Open item is whether this goes in IKE or becomes a standalone BCP-type RFC.
• 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".
• Clarification on hashing when a public key algorithm mandates the use of a certain hash. Reading the draft it sounds like HMAC-SHA should be used with DSS. That is not the intent and is incorrect.
• Verbage in the Security Considerations stating that the message ID should be randomly generated.
• Verbage in the Security Considerations recommending the OAEP mode for PKCS #1 encryption.
• A description of which of the various IDs make sense in which phase. More of a DOI issue.
• A new attribute (both phases) for "block size". We have "key length", and "number of rounds" but no way to specify the block size of a cipher which has a variable block size-- like the Hasty Pudding Cipher.
• There are issues surrounding the rekeying of both phase1 (IKE) and phase2 (IPSec) SAs. IPSec Re-keying Issues discusses these.
• Clarification on what SPI to use during transactional exchanges like new group mode or configuration mode.
• Some verbage needed to specify when to start using the IKE SA to protect notification exchanges. As soon as "crypto active" which could screw up the running IV or after the phase 1 exchange which could leave some notifies unprotected?
• A rewrite of the wording in section 3.5 in the ISAKMP document that seems to mandate a covert channel.

Changes that affect interoperability (IPSecond issues)

• 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!
• None of the optional payloads-- cert, cert_req, notify for initial contact, vendor ID-- are authenticated.
• It is not possible to express sets of IDs, nor port ranges, nor the "everything except" construct-- e.g. all ports less than 1024 except 80.