Subject: [IPsec] transform id for ESP GMAC for IKEv1 Phase2

From: Soo-Fei Chew <[email-masked]>
Date: Thu, 9 Apr 2009 13:14:41 -0700

Hi

Per RFC4543, section 9, for ike v2 the ESP Phase 2 transform ID is 21 but it doesn't specify for IKEv1.  If I use 21 for ikev1, it conflicts with RFC4196 section 5.2.
Please advise what to put as transform ID for ESP IKEv1.

Thanks,
SooFei

Soo-Fei Chew
Senior Engineer
Mocana Corporation

Securing the Internet of Things
Request a free trial of Mocana's software at <http://> http://www.mocana.com/evaluate.html
[email-masked]<mailto:[email-masked]>
350 Samsome Street Suite 1010,
San Francisco, CA 94105
p +1 415 617 0055 ext. 3011
f +1 415 617 0056

Confidentiality Notice:  The information contained in this electronic transmission is confidential, and may be protected from disclosure under applicable law.  This transmission is intended only for the use of the individual to whom it is addressed.  If you are not the addressee, or the employee or agent responsible for delivering this transmission to the intended recipient, please notify us immediately by telephone at the telephone number above, and destroy this transmission in its entirety.  Any use, dissemination, review, distribution, disclosure, copying or taking of any action whatsoever in reliance upon or in connection with the contents of this transmission is strictly prohibited.

---

From: [email-masked]
Date: Fri, 10 Apr 2009 14:39:45 -0400

Hmm - the IKEv1 (actually ISAKMP) and IKEv2 encryption
algorithm registries appear to have diverged, starting
with the value 21 (e.g., Camellia in CBC mode has
different values in the two registries).
 
The current answer for GMAC usage in IKEv1 appears to
be "Not Supported".  In order to change this, IANA
would need to be directed to allocate a new value in
the appropriate ISAKMP registry.

Thanks,
--David

----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Soo-Fei Chew
	Sent: Thursday, April 09, 2009 4:15 PM
	To: [email-masked]
	Subject: [IPsec] transform id for ESP GMAC for IKEv1 Phase2

	Hi

	Per RFC4543, section 9, for ike v2 the ESP Phase 2 transform ID
is 21 but it doesn't specify for IKEv1.  If I use 21 for ikev1, it
conflicts with RFC4196 section 5.2.

	Thanks,

	SooFei

	Soo-Fei Chew   
	Senior Engineer
	Mocana Corporation

	Securing the Internet of Things
	Request a free trial of Mocana's software at  <http://> 
http://www.mocana.com/evaluate.html 

	[email-masked]

	San Francisco, CA 94105

	f +1 415 617 0056
	
	Confidentiality Notice:  The information contained in this
electronic transmission is confidential, and may be protected from
disclosure under applicable law.  This transmission is intended only for
the use of the individual to whom it is addressed.  If you are not the
addressee, or the employee or agent responsible for delivering this
transmission to the intended recipient, please notify us immediately by
telephone at the telephone number above, and destroy this transmission
in its entirety.  Any use, dissemination, review, distribution,
disclosure, copying or taking of any action whatsoever in reliance upon
or in connection with the contents of this transmission is strictly
prohibited.

---

From: Soo-Fei Chew <[email-masked]>
Date: Fri, 10 Apr 2009 12:10:37 -0700

Hi

If AES-GMAC is 'Not Supported" in IKEv1, then in RFC4869

      3.3. Suite "Suite-B-GMAC-128" ...................................4
      3.4. Suite "Suite-B-GMAC-256" ...................................5

The mentioning of IKEv1 is not applicable at all!

Thanks,
SooFei

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 10, 2009 11:40 AM
To: Soo-Fei Chew; [email-masked]
Subject: RE: [IPsec] transform id for ESP GMAC for IKEv1 Phase2

Thanks,
--David

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Soo-Fei Chew
Sent: Thursday, April 09, 2009 4:15 PM
To: [email-masked]
Subject: [IPsec] transform id for ESP GMAC for IKEv1 Phase2
Hi

Thanks,
SooFei

Soo-Fei Chew
Senior Engineer
Mocana Corporation

---

From: [email-masked]
Date: Fri, 10 Apr 2009 16:44:10 -0400

That looks like an oversight at least wrt RFC 4869.
 
Chairs (of ipsecme) and Pasi (AD) - is a new RFC needed to
allocate this value, or is there a lower overhead and faster
means of getting this done?

Thanks,
--David

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Soo-Fei Chew
	Sent: Friday, April 10, 2009 3:11 PM
	To: [email-masked]
	Subject: Re: [IPsec] transform id for ESP GMAC for IKEv1 Phase2

	Hi

	      3.3. Suite "Suite-B-GMAC-128"
...................................4

	      3.4. Suite "Suite-B-GMAC-256"
...................................5

	Thanks,

	SooFei

	Thanks,
	--David

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Soo-Fei Chew
		Sent: Thursday, April 09, 2009 4:15 PM
		To: [email-masked]
		Subject: [IPsec] transform id for ESP GMAC for IKEv1
Phase2

		Hi

		Per RFC4543, section 9, for ike v2 the ESP Phase 2
transform ID is 21 but it doesn't specify for IKEv1.  If I use 21 for
ikev1, it conflicts with RFC4196 section 5.2.

		Thanks,

		SooFei

		Soo-Fei Chew   
		Senior Engineer
		Mocana Corporation

		[email-masked]

		San Francisco, CA 94105

		f +1 415 617 0056
		
		Confidentiality Notice:  The information contained in
this electronic transmission is confidential, and may be protected from

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Apr 2009 16:35:46 -0700

>That looks like an oversight at least wrt RFC 4869.

Actually, this started with an oversight in RFC 4543. Section 5 clearly says that it is for IKEv1 and IKEv2, but section 9 only seems to cover IKEv2.

>means of getting this done?

This can probably be done by Pasi, given the nature of the error. Otherwise, we probably need a revision to RFC 4543.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Apr 2009 14:31:39 +0300

Paul Hoffman writes:
> Actually, this started with an oversight in RFC 4543. Section 5
> clearly says that it is for IKEv1 and IKEv2, but section 9 only
> seems to cover IKEv2.

Yes. 

> This can probably be done by Pasi, given the nature of the error.
> Otherwise, we probably need a revision to RFC 4543. 

It would be easier to fix that if the value would be missing from the
IKEv2 registry as those are expert review actions.

The whole ikev1 (http://www.iana.org/assignments/isakmp-registry)
registry is completele mess. For example the top level iana list
(http://www.iana.org/protocols/) only contains following registries
pointing to the isakmp-registry:

  - ISAKMP AH Transform Identifiers
  - IPSEC Security Association Attributes
  - ISAKMP Identifiers
  - Signature Encoding Algorithm Values

The RFC2407 lists more registries:

   6.1 IPSEC Situation Definition
   6.2 IPSEC Security Protocol Identifiers
   6.3 IPSEC ISAKMP Transform Identifiers
   6.4 IPSEC AH Transform Identifiers
   6.5 IPSEC ESP Transform Identifiers
   6.6 IPSEC IPCOMP Transform Identifiers
   6.7 IPSEC Security Association Attributes
   6.8 IPSEC Labeled Domain Identifiers
   6.9 IPSEC Identification Type
   6.10 IPSEC Notify Message Types

And those are the registries actually included in the isakmp-registry
file.

In addition to those the isakmp-registry also contains the "ISAKMP
Domain of Interpretation (DOI)", and "Next Payload Types" registries.
The "Next Payload Types" which was created afterwords when we noticed
we do need it. I do not think its creation is specified in any RFC.
Don't even know when the DOI registry was created. 

Most of those IKEv1 registries do require RFC and IESG review (IPsec
Situation Definition, IPSEC Security Protocol Identifiers, IPSEC
ISAKMP Transform Identifiers, IPSEC AH Transform Identifiers, IPSEC
ESP Transform Identifiers, IPSEC IPCOMP Transform Identifiers, IPSEC
Identification Type). Rest just require Internet Draft to specify
it...

As this change to the isakmp-registry changes the IPSEC ESP Transform
Identifiers registry, which do require Standard Track RFC or IESG
review, I think we cannot simply modify the registry, but we at
minimum need to make errata for the RFC4543 which reserves values also
from the IKEv1 registry.

Of course as everybody should be using the IKEv2, and everybody should
be moving away from the obsoleted IKEv1 protocol, we can also just say
that you cannot use those algorithms with obsoleted IKEv1 protocol,
and you need to use IKEv2 for it :-)

Anyways IANA should fix their toplevel list
(http://www.iana.org/protocols/) to include all the registries listed
in the isakmp-registry file, i.e.:
----------------------------------------------------------------------
IPSEC Situation Definition
	RFC 2407
	Standards Action

IPSEC Security Protocol Identifiers
	RFC 2407
	0-248 Standards Track RFC; 249-255 Reserved for private use
	amongst cooperating systems

IPSEC ISAKMP Transform Identifiers
	RFC 2407
	0-248 Standards Track RFC; 249-255 Reserved for private use
	amongst cooperating systems

IPSEC AH Transform Identifiers
	RFC 2407
	0-248 Standards Track RFC; 249-255 Reserved for private use
	amongst cooperating systems

IPSEC ESP Transform Identifiers
	RFC 2407
	0-248 Standards Track RFC; 249-255 Reserved for private use
	amongst cooperating systems

IPSEC IPCOMP Transform Identifiers
	RFC 2407
	0-47 Standards Track RFC; 48-63 Reserved for private use
	amongst cooperating systems

IPSEC Security Association Attributes
	RFC 2407
	1-32000 Specification Required; 32001-32767 Reserved for
	private use amongst cooperating systems

Signature Encoding Algorithm Values
	RFC 4359
	Standards Action

IPSEC Labeled Domain Identifiers
	RFC 2407
	First Come First Serve 

IPSEC Identification Type
	RFC 2407
	0-248 Standards Track RFC; 249-255 Reserved for private use
	amongst cooperating systems

IPSEC Notify Message Types
	RFC 2407
	8192-16000 and 24576-32000 Specification Required;
	16001-16383 and 32001-32767 Reserved for private use amongst
	cooperating systems 

ISAKMP Domain of Interpretation (DOI)
	RFC ?
	Specification Required

Next Payload Types
	RFC ?
	0-127 ???, 128-255 Reserved for private use amongst
	cooperating systems 
-- 
[email-masked]