Subject: [Ipsec] RFC4306bis and SA proposals

From: <[email-masked]>
Date: Tue, 19 Jun 2007 08:43:11 +0200

Section 3.3, first paragraph, fifth sentence: This sentence should
be modified (perhaps replacing may with must) because the
text "multiple IPsec protocols" in RFC4306 has been replaced
with "single IPsec protocol".  But the formulation seems to
allow the following SA payload
 
    SA payload
        proposal 1
            protocol ID: IKE
            SPI size: 8
            # transforms: 4
            ...
        proposal 2
            protocol ID: ESP
            SPI size: 4
            # transforms: 3
            ...
 
If such an SA payload appears in an INIT_IKE_SA packet, only proposal 1
can be considered, whereas if the SA payload appears in an IKE_AUTH
packet, only proposal 2 can be considered.
 
Section 3.3, fifth paragraph: Correction, AH has generally two
transforms and ESP has generally three transforms, because ESN is
mandatory.
 
Section 3.3, sixth paragraph: Replace 'Transformation Type 2' (which
means PRF) with 'Transformation Type 3' (INTEG).
 
Section 3.3.2: In the transformation type 3 table, replace RFC 3566 with
RFC 4434.
 
Section 3.3.6, second paragraph: Assume a CREATE_CHILD_SA packet
is received with
    SA payload
        proposal 1
            D-H=2
            ...
        proposal 2
            D-H=0
            ...
    KE payload
        D-H=2
        ...
Assume the responder wants to pick proposal number 2.  Because the
KE payload refers to D-H=2, the responder must return
INVALID_KE_PAYLOAD, event though the responder could just
select proposal 2 and omit the KE payload in the response.
 
Reading section 3.3 with section 2.7, I should like to understand
how already defined proposals can be augmented.  Suppose ESP some
time in future is augmented with a new optional transformation FUT
(transformation type 6), and this transformation has two values
FUT_OFF = 0 and FUT_ON = 1.  If the Initiator sends an SA payload
with a single proposal
    SA payload
        proposal 1
            protocol ID: ESP
            ENCR=ENCR_NULL
            ENCR=ENCR_DES
            FUT=FUT_NULL
            FUT=FUT_ON
            ESN=ESN_OFF
what is the Responder supposed to return?  If the Responder also
knows FUT, no problem.  But if the Responder does not know FUT,
and follows "The accepted cryptographic suite MUST contain exactly
one transform of each type included in the proposal." then the
Responder has to reject the proposal.
 
A similar situation is relevant for attributes.  Suppose ENCR
transformations allow a new attribute, say AAA.  If the
Initiator wants to use AAA, it may in an SA payload send
        ENCR=AES_CBC
             Attribute KeyLength 192
             Attribute AAA "01020304"
If the Responder is not knowing of AAA, it has to avoid this
transformation because of section 3.3.6 ("Any attributes of a selected
transform MUST be returned unmodified.").  Again, it makes it
difficult to add new attributes.
 
Christian

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Thu, 21 Jun 2007 12:38:31 +0300

[email-masked] wrote:

> with "single IPsec protocol". 

You're right, it probably should read "MUST contain a single 
IPsec protocol".

> But the formulation seems to allow the following SA payload
>  
>     SA payload
>         proposal 1
>             protocol ID: IKE
>             SPI size: 8
>             # transforms: 4
>             ...
>         proposal 2
>             protocol ID: ESP
>             SPI size: 4
>             # transforms: 3
>             ...
>  
> If such an SA payload appears in an INIT_IKE_SA packet, only
> proposal 1 can be considered, whereas if the SA payload appears 
> in an IKE_AUTH packet, only proposal 2 can be considered.

It doesn't make much sense to send this kind of SA payload, but the
receiver should still be able to process it correctly.

> transforms and ESP has generally three transforms, because ESN is

Good catch!
  
> means PRF) with 'Transformation Type 3' (INTEG).

Quite right.
  
> Section 3.3.2: In the transformation type 3 table, replace 
> RFC 3566 with RFC 4434.

Yep.
  
> select proposal 2 and omit the KE payload in the response.

Sending INVALID_KE_PAYLOAD in this case certainly wasn't the intent,
but you're right that the text doesn't explicitly say this.
I'll add this to my todo list...

> Responder has to reject the proposal.

Yes, the responder has to reject the proposal if it doesn't
know about FUT. The initiator could have included a second proposal
without the FUT transform type.

> transformation because of section 3.3.6 ("Any attributes of a 
> selected transform MUST be returned unmodified.").  Again, it 
> makes it difficult to add new attributes.

Not really -- in the example you give, the initiator clearly says that
it only accepts AES_CBC with AAA "01020304", nothing else.  If the
responder doesn't support this, rejecting the proposal is the 
correct action.

If the initiator's intent is to also accept AES_CBC without AAA,
it will send two transforms:

   ENCR=AES_CBC 
        Attribute KeyLength 192
   ENCR=AES_CBC 
        Attribute KeyLength 192
        Attribute AAA "01020304"

This encoding might be a bit unefficient if we had a really large
number of optional attributes and transform types -- but during
the last 12+ years of IPsec, we've basically added only ESN.
So I wouldn't worry too much about this..

Best regards,
Pasi

---

From: <[email-masked]>
Date: Thu, 21 Jun 2007 13:10:34 +0200

And correct processing of the SA in an IKE_AUTH may lead to
proposal 2 being chosen.  Thus if one SA payload has different protocol IDs in
different proposals, this fact should not return INVALID_SYNTAX.  (There
could of course be other reasons for returning INVALID_SYNTAX, for
example is the PRF transformation is missing in an IKE proposal.)
 
Christian 

________________________________

Fra: [email-masked] [mailto:[email-masked]]
Sendt: to 21-06-2007 11:38
Til: [email-masked]; Kaas-Petersen Christian
Emne: RE: [Ipsec] RFC4306bis and SA proposals