Subject: Re: [IPsec] Issue #90: Shorter WESP negotiation

From: Yoav Nir <[email-masked]>
Date: Sun, 3 May 2009 00:41:06 +0300

Grewal, Ken wrote:
> 
> 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...

I think the con really addresses a non-problem. I don't think anyone is going to want NULL encryption if WESP is selected, but AES-256 if regular ESP is selected. I think we should go with Charlie's suggestion.

Yoav
Email secured by Check Point

---

From: "Grewal, Ken" <[email-masked]>
Date: Sat, 2 May 2009 23:38:58 -0600

Agreed - minor issue for the 'con', but needed to be raised.
We actually added in a notification method to 'negotiate' WESP in the updated revision of the draft.

Look forward to other opinions on this approach...

Thanks, 
- Ken
 
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Yoav Nir
>Sent: Saturday, May 02, 2009 2:41 PM
>To: Grewal, Ken; [email-masked]
>Subject: Re: [IPsec] Issue #90: Shorter WESP negotiation
>
>Grewal, Ken wrote:
>>
>I think the con really addresses a non-problem. I don't think anyone is
>going to want NULL encryption if WESP is selected, but AES-256 if regular
>ESP is selected. I think we should go with Charlie's suggestion.
>
>Yoav
>_______________________________________________
>IPsec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 4 May 2009 14:49:02 +0300

> Pros: Shorted negotiation using notifications.

For pros you can also put down "automatic fallback to normal ESP if
other end does not support WESP". There is no guarantee that other end
will properly fall back to other protocol if protocol identifier is
used when negotiating WESP, but responder MUST ignore unrecognized
status notification types.

There is no specified requirement for IKEv2 implementation to support
multiple proposal substructures, thus trying to propose ESP-NULL or
WESP-NULL might not work (i.e. implementation can only check first the
most preferred proposal and ignore the others). 

The current RFC does not specify how many proposals implementations
should check, and at least some implementations do have some kind
limit for number of proposals they check (and that limit might even be
1).
-- 
[email-masked]

---

From: "Grewal, Ken" <[email-masked]>
Date: Mon, 4 May 2009 11:49:48 -0600

Thanks Tero. 
I agree with your additional observations on the pros of taking this approach for a simpler and shorter WESP negotiation. Furthermore,  your point regarding undesirable behavior using a multiple proposals approach with WESP is well noted. 

The notification method for WESP negotiation has already been added to the updated draft we submitted last week and unless someone raises additional points on why this may not work, we can leave it as it stands.

Thanks, 
- Ken

>From: Tero Kivinen [mailto:[email-masked]]
>Sent: Monday, May 04, 2009 4:49 AM
>To: Grewal, Ken
>Cc: [email-masked]
>Subject: [IPsec] Issue #90: Shorter WESP negotiation
>
>Grewal, Ken writes:

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 May 2009 16:08:39 +0300

[email-masked] 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... :)
-- 
[email-masked]

---

From: <[email-masked]>
Date: Thu, 28 May 2009 18:16:02 +0200

Thanks for looking into this, Tero!

I would propose we just allocate both AH transform identifier 
and Authentication Algorithm numbers for AH_AES_128/192/256_GMAC.
This is what e.g. RFC 3566 did for XCBC-PRF. 

While in theory it could be nice to have more text explaining how this
works, compared to the other ambiguous places in IKEv1 specs, this one
looks something implementors would quite likely get right even without
the additional explanation....

Best regards,
Pasi

> From: ext Tero Kivinen [mailto:[email-masked]]
> Sent: 28 May, 2009 16:09
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> Subject: [IPsec] Transform IDs for AES-GMAC in IKEv1
>