pasi.ero...@nokia.com writes:
> 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)
When I was checking out this thing more I found that we need to do
even more for GMAC. The reason is that In IKEv1 the AH_* "Transform
Identifiers" MUST include "Authentication Algorithm" attribute also.
I.e. it is not enough to just set "AH Transform Identifier" to
AH_AES_128_GMAC, but in addition to that the proposal MUST include
"Authentication Algorithm" attribute with suitable value.
Text from RFC2407:
----------------------------------------------------------------------
4.4.3 IPSEC AH Transform Identifiers
...
Note: the Authentication Algorithm attribute MUST be specified to
identify the appropriate AH protection suite. For example, AH_MD5
can best be thought of as a generic AH transform using MD5. To
request the HMAC construction with AH, one specifies the AH_MD5
transform ID along with the Authentication Algorithm attribute set to
HMAC-MD5. This is shown using the "Auth(HMAC-MD5)" notation in the
following sections.
Transform ID Value
------------ -----
RESERVED 0-1
AH_MD5 2
AH_SHA 3
AH_DES 4
...
4.4.3.1 AH_MD5
...
All implementations within the IPSEC DOI MUST support AH_MD5 along
with the Auth(HMAC-MD5) attribute. This suite is defined as the
HMAC-MD5-96 transform described in [HMACMD5].
The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH
transform (Key/Pad/Data/Key) described in RFC-1826.
Use of AH_MD5 with any other Authentication Algorithm attribute value
is currently undefined.
4.4.3.2 AH_SHA
The AH_SHA type specifies a generic AH transform using SHA-1. The
actual protection suite is determined in concert with an associated
SA attribute list. A generic SHA transform is currently undefined.
All implementations within the IPSEC DOI MUST support AH_SHA along
with the Auth(HMAC-SHA) attribute. This suite is defined as the
HMAC-SHA-1-96 transform described in [HMACSHA].
Use of AH_SHA with any other Authentication Algorithm attribute value
is currently undefined.
...
Authentication Algorithm
RESERVED 0
HMAC-MD5 1
HMAC-SHA 2
DES-MAC 3
KPDK 4
Values 5-61439 are reserved to IANA. Values 61440-65535 are
for private use.
There is no default value for Auth Algorithm, as it must be
specified to correctly identify the applicable AH or ESP
transform, except in the following case.
When negotiating ESP without authentication, the Auth
Algorithm attribute MUST NOT be included in the proposal.
When negotiating ESP without confidentiality, the Auth
Algorithm attribute MUST be included in the proposal and the
ESP transform ID must be ESP_NULL.
...
----------------------------------------------------------------------
I.e it is not enough to add the AH_AES_*_GMAC values, but we also need
to specify the corresponding "Authentication Algorithm" attribute
values.
As those "Authentication Algorithm" numbers requires more text
explaining for example that they are no other Authentication Algorithm
than AES_128_GMAC is to be allowed with AH_AES_128_GMAC, this might
actually require more than just errata...
There is also multiple ways to define those, i.e. we might for example
just make one "IPSEC AH Transform Identifier" called AH_AES_GMAC which
is used for 3 different "Authentication Algorithms" for different key
lengths, or we can keep the current practice which makes one Transform
ID to have one allowed Authenticating Algorithm (except for MD5, where
the KPDK is also allowed).
Actually only AH_MD5, AH_SHA1 and AH_DES restrict valid
"Authentication Algorithms", none of the other documents adds such
limitations, so actually it would be valid to be using AH_SHA2-256
with Auth(KPDK) or even with HMAC-MD5, in which case I guess HMAC-MD5
algorithm would actually be used...
I am not more sure how we should fix this problem, as the deeper we
get there the more we need to fix, and we already have solution called
IKEv2 to fix these problems... :)
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
