Subject: [IPsec] IANA ikev2 registry and FC values

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Jan 2013 19:03:49 +0200

I got question now about the values allocated for the "IKEv2 in the
Fibre Channel Security Association Management Protocol" and their use
in the normal IPsec use over IP. This question was about support for
AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 for IPsec over IP, instead of
using the normal AUTH_HMAC_MD5_96 and AUTH_HMAC_SHA1_96 values
everybody in IP world are using. When those values were allocated it
was assumed that they were only to be used in the FC world.

I noticed that when all other RFC4595 allocated numbers have FC_ in
their names, but these AUTH_* does not have those. Also there is
nothing that explictly forbid their use in the IKEv2/ESP over IP, it
has been implicit because there is nothing that says they can be used
in the IP world either.

One of the reasons for these is that this allocation happened when we
had this process flaw and those drafts never came to the IANA expert
for review (i.e. to me), so I only did some early comments to their
-00 draft, and then later noticed that the values had been added to
the registry.

To clear up this confusion, I would like to add note to the IANA table
saying "Only for Fibre Channel use" for those two values.

Does anybody have any objections for doing that? 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 17 Jan 2013 19:13:32 +0200

Actually, why? At first sight they look entirely reasonable to me 
(untruncated versions of MAC, where we usually truncate). Are you saying 
they are not well defined?

If they're both well-defined and secure, I don't see any reason to add 
this limitation.

After all, we do have much weirder algorithms in the registry.

Thanks,
	Yaron

---

From: "Black, David" <[email-masked]>
Date: Thu, 17 Jan 2013 12:16:01 -0500

No problem here - I'm one of the authors of RFC 4595.

Thanks, --David +++Sent from Blackberry

----- Original Message -----
From: Tero Kivinen [mailto:[email-masked]]
Sent: Thursday, January 17, 2013 12:03 PM
To: [email-masked] <[email-masked]>
Subject: [IPsec] IANA ikev2 registry and FC values

Does anybody have any objections for doing that? 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 17 Jan 2013 09:19:16 -0800 (PST)

Hello,

> Does anybody have any objections for doing that?

  I don't actually see what the problem is that this note would solve.
Unless there's a problem then I have an objection to adding this note.
Can you restate the problem?

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Jan 2013 19:38:39 +0200

> they are not well defined?

I do not think they offer anything compared to the truncated versions,
i.e. it just adds a 2nd way to do exactly same thing with no clear
reason.

Note that RFC2104 section 5 says that there are some advantages of
truncating the output of the hash-based MAC functions (even though the
results are not absolute).

> If they're both well-defined and secure, I don't see any reason to add 

They are not defined for IP use at all. None of the IKEv2/ESP over IP
uses those values. Ah, found text from our IPsec/IKE Roadmap:

		   For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry
   contains values for both the truncated version and the standard non-
   truncated version; thus, IKEv2 has the capability to negotiate either
   version of the algorithm.  However, only the truncated version is
   used for IKEv2 SAs and for IPsec SAs.  The non-truncated version is
   reserved for use by the Fibre Channel protocol [RFC4595].  For the
   other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC-
   RIPEMD), only the truncated version can be used for both IKEv2 and
   IPsec-v3 SAs.

which actually says we always use truncated version (so I was wrong
they are not forbidden anywhere, missed this text last time as it uses
SHA-1 spelling not SHA1, which I was searching for :-).

> After all, we do have much weirder algorithms in the registry.

That is true, and I do not consider that as a good thing. It is much
better to have one good way of doing things than two ways of doing
same thing, especially if those two ways are about the same.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Jan 2013 19:41:41 +0200

> Can you restate the problem?

Mostly because then saying integrity protection with SHA-1 is not well
defined anymore. Currently it is assumed it always means
AUTH_HMAC_SHA1_96, but if implementations start supporting
AUTH_HMAC_SHA1_160 too, then the GUI etc needs to be modified to be
explicit about the truncation length, and that just causes confusion
and interoperability problems. Especially as I do not know any
implementation out there that supports AUTH_HMAC_SHA1_160 for IP
use... 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 17 Jan 2013 19:48:03 +0200

Hi Tero,

please see below.

Thanks,
	Yaron

> i.e. it just adds a 2nd way to do exactly same thing with no clear

Whether they're adding anything or not is for cryptographers to say. 
Sec. 5 of RFC 2104 is very equivocal about this.

OTOH your proposal would mean one more difference between "regular" 
IPsec implementations and FC-specific ones. I don't think that would be 
a good thing.

> results are not absolute).

See above.

> SHA-1 spelling not SHA1, which I was searching for :-).

This text is simply describing the existing situation. It is not at all 
normative.

> same thing, especially if those two ways are about the same.

Yes, but people have good reasons to add algorithms, which is (part of 
the reason) why we negotiate them in the protocol. Thus "Tiger", 
"camellia" and the like, and I'm sure the FC folks had a good reason for 
the untruncated algorithms, too.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Jan 2013 20:13:30 +0200

> IPsec implementations and FC-specific ones. I don't think that would be 

FC-specific ones are only using these non-truncated ones, and they are
using special ID payloads, separate protocol ID values, different
types of traffic selectors etc. They are reusing the basic IKEv2
protocol, and some of the payloads, but it is different protocol than
IKEv2. 

> This text is simply describing the existing situation. It is not at all 

Which is why I also want to describe that existing situation in the
IANA registry. If you want to use those non-truncated versions in
IPsec, you can write draft describing that... 

> the untruncated algorithms, too.

They had some reason, but on the other hand IPsec people did not want
those untruncated algorithms, and have not specified them for IP use.
This is one of the problems when sharing registries causes problems.
Suddenly you might have options for protocols which did not request
them added to them, because someone else who shares the same registry
added them.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 17 Jan 2013 20:23:52 +0200

I agree that sharing registries with related but different protocols is 
not a good thing. I just think this is not one of these cases.

Thanks,
	Yaron

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 17 Jan 2013 11:44:21 -0800 (PST)

Hello,

> not a good thing. I just think this is not one of these cases.

  I agree that this is not the case but sharing registries should not
be a problem. We use OIDs all the time with different protocols.
The problems arise when a group of people attempts to impose
administrative rules on protocol use and say that some completely
legitimate technical application is prohibited for the simple reason
that they say it is.

  Dan.