Subject: [IPsec] Issue #157: Illustrate the SA payload with a diagram

From: Yaron Sheffer <[email-masked]>
Date: Fri, 22 Jan 2010 23:57:56 +0200

The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might be helpful.

Here's a first shot (we'll need to add some descriptive text):

                        SA Payload
                            |
                      ---------------............-
                      |             |            |
               Proposal #1       Proposal #2   Proposal #n
                     ESP           ESP
                     SPIx          SPIy
                      |             |
           ---------------------    --------------------
           |                   |             |         |
      Transform A        Tranform B    Transform C Transform D
          ENCR               AUTH          ENCR       ESN
          AES            HMAC-SHA-256    AES-CCM     ESN=1
           |
   -----------------
   |       |       |
Attr Ax Attr Ay Attr Az
  128     192     256

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/157#comment:1>
ipsecme <http://tools.ietf.org/ipsecme/>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 Jan 2010 17:27:51 -0800

>Here's a first shot (we'll need to add some descriptive text):

In order for this not to be confusing, Transform A should be "ENCR" and "AES-CBC", and Transform C needs to (in fact, MUST) have at least one attribute specified.

Transform B should be listed as "INTEG", not "AUTH".

Further, is there a good reason for you to have not included an ESN transform on Proposal #1? Section 3.3 says "The number of different transforms is generally determined by the Protocol. ... ESP generally has three: ESN, an encryption algorithm and an integrity check algorithm."

Ditto for Proposal #2: is there a good reason for you to not have included an INTEG transform?

This begs the related question: given that there is no MUST or should for what goes into a Proposal, what does an ESP proposal that only has an ENCR and INTEG in it mean with respect to what is being proposed for ESN? What does an ESP proposal that has only an ENCR and ESN in it mean with respect to what is being proposed for INTEG? I see no MUSTs or SHOULDs answering this.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 23 Jan 2010 20:06:45 +0200

Hi Paul,

Please see below.

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Saturday, January 23, 2010 3:28
> To: Yaron Sheffer; [email-masked]
> Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a
> diagram
> 
> In order for this not to be confusing, Transform A should be "ENCR" and
> "AES-CBC", and Transform C needs to (in fact, MUST) have at least one
> attribute specified.
Agree.
> Transform B should be listed as "INTEG", not "AUTH".
Yes.
> 
> Further, is there a good reason for you to have not included an ESN
> transform on Proposal #1? Section 3.3 says "The number of different
> transforms is generally determined by the Protocol. ... ESP generally
> has three: ESN, an encryption algorithm and an integrity check
> algorithm."
According to 3.3.3, ESN is mandatory for ESP and AH. So I should have included it.
> included an INTEG transform?
I was trying to illustrate a combined mode algorithm. May have got it wrong...
> 
> This begs the related question: given that there is no MUST or should
> for what goes into a Proposal, what does an ESP proposal that only has
> an ENCR and INTEG in it mean with respect to what is being proposed for
> ESN? What does an ESP proposal that has only an ENCR and ESN in it mean
> with respect to what is being proposed for INTEG? I see no MUSTs or
> SHOULDs answering this.
3.3.3 says ESN is mandatory. Which means if it is omitted, the recipient will reject the proposal.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> Scanned by Check Point Total Security Gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 23 Jan 2010 11:18:54 -0800

>According to 3.3.3, ESN is mandatory for ESP and AH. So I should have included it.

Good.

>I was trying to illustrate a combined mode algorithm. May have got it wrong...

That would be INTEG = NULL.

>3.3.3 says ESN is mandatory. Which means if it is omitted, the recipient will reject the proposal.

As I said, I don't see any MUST or SHOULD for that. It would be better if this was stated. A possible addition to 3.3.3 would be "A proposal that does not contain all of the mandatory transforms is malformed and MUST be rejected".

--Paul Hoffman, Director
--VPN Consortium

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 25 Jan 2010 10:04:38 +0300

Hi Paul,

> That would be INTEG = NULL.

Omitting it completely is also allowed (section 3.3.3):

   A proposal MAY omit the optional types if the only value for them it will
accept is
   NONE.

Look also at section 2.7

   If an initiator proposes both normal ciphers with integrity
   protection as well as combined-mode ciphers, then two proposals are
   needed.  One of the proposals includes the normal ciphers with the
   integrity algoritms for them, and the other proposal includes all the
   combined mode ciphers without the integrity algorithms (because
   combined mode ciphers are not allowed to have any integrity algorithm
   other than "none").

...ant at section 3.3:

   Combined-mode ciphers include both
   integrity and encryption in a single encryption algorithm, and MUST
   either offer no integrity algorithm or a single integrity algorithm
   of "none", with no integrity algorithm being the RECOMMENDED method.

Probably both cases (NONE and omitting) could be included in the diagram.

Regards,
Valery Smyslov.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 25 Jan 2010 10:40:06 +0200

3.3.6 mentions it quite explicitly, and I don't think need to say it again is 3.3.3:

"If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual."

Thanks,
	Yaron

> Sent: Saturday, January 23, 2010 21:19
> Subject: RE: [IPsec] Issue #157: Illustrate the SA payload with a
> diagram
> 
[snip]
> As I said, I don't see any MUST or SHOULD for that. It would be better
> if this was stated. A possible addition to 3.3.3 would be "A proposal
> that does not contain all of the mandatory transforms is malformed and
> MUST be rejected".
> 
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 Jan 2010 11:59:03 +0200

> Here's a first shot (we'll need to add some descriptive text):

Remove the Proposal #n part, as there is no need for that. It is bad
idea to include more than 2 proposals, as it just makes the payloads
bigger, and causes all kind of problems (for example in IKEv1 this
only way to do this, and vendors had very small upper limit for
number of proposals (2, 4 or 8 or so)). 

As in IKEv2 multiple proposals is really needed only for normal
ciphers + authentication vs combined mode ciphers, so the example
should also show two, and this is something we should try to get
vendors to implement.

I have noticed that some vendors have taken their IKEv1 SA payload
processing and are making lots of proposals each having one algorithm
suite and in some cases they still have combination suite including
all alrogithms. This is just stupid and makes packets bigger and can
cause for example fragmentation for the packets, which would be much
smaller if the normal IKEv2 SA payload would be used.

This might be better example:
----------------------------------------------------------------------

                          SA Payload
                              |
           +------------------+---------------------------+
           |                                              |
           |                                              |
       Proposal #1                                    Proposal #2
   Proto ID = ESP (3)                             Proto ID = ESP (3)
     SPI size = 4                                   SPI size = 4
     5 transforms                                   2 transforms
   SPI = 0x95903423                               SPI = 0x12345678
         |                                              |
     +---+-----+---------+---------+---------+          +---------+
     |         |         |         |         |          |         |
 Transform Transform Transform Transform Transform  Transform Transform
   ENCR      INTEG     INTEG      ESN       ESN       ENCR       ESN
   ENCR    AUTH_HMAC  AUTH_AES   ESN=0     ESN=1    AES-GCM     ESN=1
 _AES_CBC   _SHA1_96  _XCBC_96                      w/8 octet
     |                                                ICV
     |                                                 |
   +-+---------+-----------+            +-----------+--+--------+
   |           |           |            |           |           |
Attribute   Attribute   Attribute    Attribute   Attribute   Attribute
Key Length  Key Length  Key Length   Key Length  Key Length  Key Length
   128         192         256          128         192         256

----------------------------------------------------------------------
And that proposes 3 (ciphers) * 2 (integrity algorithms) * 2 (esn or
no esn) + 3 (combined mode with 3 key lengths) = 15 combinations:

ENCR_AES_CBC 128 bit key, AUTH_HMAC_SHA1_96, ESN=0
ENCR_AES_CBC 128 bit key, AUTH_HMAC_SHA1_96, ESN=1
ENCR_AES_CBC 128 bit key, AUTH_HMAC_XCBC_96, ESN=0
ENCR_AES_CBC 128 bit key, AUTH_HMAC_XCBC_96, ESN=1
ENCR_AES_CBC 192 bit key, AUTH_HMAC_SHA1_96, ESN=0
ENCR_AES_CBC 192 bit key, AUTH_HMAC_SHA1_96, ESN=1
ENCR_AES_CBC 192 bit key, AUTH_HMAC_XCBC_96, ESN=0
ENCR_AES_CBC 192 bit key, AUTH_HMAC_XCBC_96, ESN=1
ENCR_AES_CBC 256 bit key, AUTH_HMAC_SHA1_96, ESN=0
ENCR_AES_CBC 256 bit key, AUTH_HMAC_SHA1_96, ESN=1
ENCR_AES_CBC 256 bit key, AUTH_HMAC_XCBC_96, ESN=0
ENCR_AES_CBC 256 bit key, AUTH_HMAC_XCBC_96, ESN=1
AES-GCM with 8 octet ICV 128 bit key, ESN=1
AES-GCM with 8 octet ICV 192 bit key, ESN=1
AES-GCM with 8 octet ICV 256 bit key, ESN=1

and the full SA payload takes 108 bytes.

BTW, If expanded to IKEv1 style the same SA payload would contain 15
proposals and would be 576 bytes...

If someone wanted to also allow PFS with for example 2 different
groups (plus none) it would add 48 bytes to the IKEv2 style payload,
but would multiply be IKEv1 style payload with 3 plus some raising it
to 2088 bytes...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 Jan 2010 12:48:06 +0200

> included an INTEG transform?

Proposal #2 is the combined mode cipher, thus it cannot have INTEG
other than none, and I though we agreed that it would be better to
leave the whole INTEG transform out in those cases (in section 3.3):

> This begs the related question: given that there is no MUST or
> should for what goes into a Proposal, what does an ESP proposal that
> only has an ENCR and INTEG in it mean with respect to what is being
> proposed for ESN? What does an ESP proposal that has only an ENCR
> and ESN in it mean with respect to what is being proposed for INTEG?
> I see no MUSTs or SHOULDs answering this. 

As already pointed out that would be incorrect proposal, but I would
expect lots of the implementations will actually accept it and assume
it means the same thing as ESN=0.

So complient implementation cannot send such proposals. If complient
implementations receives such proposal it should either return error
or assume ESN=0. This is because RFC4306 said in 3.3.3:

                                A proposal MAY
   omit the optional types if the only value for them it will accept is
   NONE.

and implementations assumed NONE == 0 == No Extended Sequence Numbers,
meaning if No Extended Sequence Numbers were to be proposed, that
transform could be left out.

As this was confusing that was the reason ESN text was clarified a bit
(i.e. added the paragraph after ESN section in IKEv2bis) and there is
more about it in the RFC4718 section 4.4.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 25 Jan 2010 13:20:27 +0200

> Here's a first shot (we'll need to add some descriptive text):

I'm sorry I just noticed this, but is this even allowed?  Can you include multiple key length attributes in the same transform?

Section 3.3.6 says:

                 If there are multiple proposals, the responder MUST
   choose a single proposal.  If the selected proposal has multiple
   Transforms with the same type, the responder MUST choose a single
   one.

So far, it's OK. The responder chooses one proposal, and if that proposal contains multiple transforms of the same type (say AUTH=HMAC-SHA-1 and AUTH=HMAC-SHA-256) then the responder chooses just one of those.

         Any attributes of a selected transform MUST be returned
   unmodified.

To me, "unmodified" does not mean choose one of three. So IMO the above Proposal #1 should be as follows (ignoring the missing ESN):

              Proposal #1 
                    ESP   
                    SPIx  
                     |    
      ---------------------  
      |                   |     
 Transform A   Transform B   Transform C   Transform D  
     ENCR          ENCR          ENCR          AUTH    
     AES           AES           AES       HMAC-SHA-256 
      |             |             |
   Attr Ax       Attr Ay       Attr Az
     128           192           256

                The initiator of an exchange MUST check that the
   accepted offer is consistent with one of its proposals, and if not
   that response MUST be rejected.

BTW: how do you reject a response?

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 Jan 2010 14:33:01 +0200

Yoav Nir writes:
> I'm sorry I just noticed this, but is this even allowed?  Can you
> include multiple key length attributes in the same transform?

Yes, you are right, you cannot include multiple key length attributes,
as they would be AND for all of them. So yes, they need to be separate
transform each of them. 

Here is my fixed proposal picture:
----------------------------------------------------------------------

                          SA Payload
                              |
           +------------------+---------------------------+
           |                                              |
           |                                              |
       Proposal #1                                    Proposal #2
   Proto ID = ESP (3)                             Proto ID = ESP (3)
     SPI size = 4                                   SPI size = 4
     7 transforms                                   4 transforms
   SPI = 0x95903423                               SPI = 0x12345678
           |                                              |
  +------+-+----+------+------+------+------+      +------+------+------+
  |      |      |      |      |      |      |      |      |      |      |
 Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans
 form   form   form   form   form   form   form   form   form   form   form
 ENCR   INTEG  ENCR   INTEG  ENCR    ESN   ESN    ENCR   ESN    ENCR   ESN
 ENCR   AUTH   ENCR   AUTH   ENCR    No    Use    AES-   No     AES-   Use
 _AES   _HMAC  _AES   _AES   _AES    ESN   ESN    GCM    ESN    GCM    ESN
 _CBC   _SHA1  _CBC   _XCBC  _CBC     0     1     w/8     0     w/8     1
   |    _96      |    _96      |                  octet         octet
   |             |             |                  ICV           ICV
   |             |             |                   |             |
   |             |             |                   |             |
Attribute     Attribute     Attribute           Attribute     Attribute
Key Length    Key Length    Key Length          Key Length    Key Length
   128           192           256                 128           256

> BTW: how do you reject a response?

Silently drop the negotiation (or just the packet if this is
IKE_SA_INIT) with the peer, as it is clearly not following the
specification, and this is not a problem that will be fixed by
changing configuration or similar, it does require software update of
the other end.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Tue, 26 Jan 2010 11:33:54 +0100

Hi Tero,

This picture looks correct to me.

Best regards,
Pasi

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Tero Kivinen
> Sent: 25 January, 2010 14:33
> To: Yoav Nir
> Cc: [email-masked]
>   |      |      |      |      |      |      |      |      |      |
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec