Subject: [IPsec] Transform IDs for AES-GMAC in IKEv1

From: <[email-masked]>
Date: Thu, 30 Apr 2009 11:28:19 +0200

Hi,

RFC 4543 specifies how to use AES-GMAC mode in AH and ESP and how to
negotiate them in IKEv1 and IKEv2 (see Section 5, 1st paragraph).

However, as Soo-Fei Chew pointed out, the IANA considerations text in
the final document didn't actually ask IANA to assign the numbers for
IKEv1. 

Here's my proposal for fixing the situation:

(1) ask IANA to assign the four missing numbers (after IESG approval).

(2) submit an RFC Editor errata, saying something like this:
 
   The following text should have been included in Section 9:

   For the negotiation of AES-GMAC in AH with IKEv1, the following
   values have been assigned in the IPsec AH Transform Identifiers
   registry (in isakmp-registry). Note that IKEv1 and IKEv2 use
   different transform identifiers.

      "TBD1" for AH_AES_128_GMAC

      "TBD2" for AH_AES_192_GMAC

      "TBD3" for AH_AES_256_GMAC

   For the negotiation of AES-GMAC in ESP with IKEv1, the following
   value has been assigned from the IPsec ESP Transform Identifiers
   registry (in isakmp-registry). Note that IKEv1 and IKEv2 use a
   different transform identifier.
   
      "TBD4" for ESP_NULL_AUTH_AES_GMAC

(where we will in TBD1..4 after we know the numbers)

(3) ask IANA to include a pointer to this errata in the isakmp-registry
entries.

Does this sound like a reasonable plan?

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 30 Apr 2009 15:01:25 +0300

> Does this sound like a reasonable plan?

I think this is good way to solve the issue. 
-- 
[email-masked]

---

From: "Grewal, Ken" <[email-masked]>
Date: Thu, 30 Apr 2009 14:38:31 -0600

All, 
As we prepare to submit the next revision of the WESP draft, we wanted to
get some discussion / feedback on some open ticket items.

Issue #90: shorter WESP negotiation

In the current traffic visibility draft, we indicate that WESP can be
negotiated via IKEv2 using a new protocol identifier. 
Charlie Kaufman suggested that it may be plausible to use a notification
method along the lines of USE_TRANSPORT_MODE in RFC 4306, where the type of
transport is negotiated independently of the cryptographic parameters. 

Pros: Shorted negotiation using notifications.
Cons: Some flexibility is lost in not being able to negotiate different
Crypto algorithms combinations with/without WESP. 	

Comments / opinions appreciated...

Thanks, 
- Ken