Subject: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr

From: raj singh <[email-masked]>
Date: Wed, 22 Apr 2009 09:30:06 +0530

Hi Group,

What is the expected behavior if as a responder we do not receive TSi and
TSr in IKE_AUTH exchange ?
Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out TSi and
TSr ?
Or we should reject the packet ?
If we reject the packet during packet validation with doing ID and AUTH
payload processing, what ERROR should be send ?

Thanks,
Raj

---

From: Matthew Cini Sarreo <[email-masked]>
Date: Wed, 22 Apr 2009 08:10:31 +0200

In IKE_AUTH TSi and TSr are mandatory, so it is not possible to omit them
from an authentication exchange message, as there would be no way for the SA
to know what traffic should be forwarded through the SA.

It seems that the correct error message would be INVALID_SYNTAX. This would
require the message ID and the checksum to be valid. Note that this has (may
only) be sent in an encrypted response.

Please correct me if I am wrong.

Regards,
Matt

> 2009/4/22 raj singh <[email-masked]>
>
>> Hi Group,
>>
>> Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out TSi
>> and TSr ?
>> _______________________________________________
>> IPsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>

---

From: raj singh <[email-masked]>
Date: Wed, 22 Apr 2009 11:58:22 +0530

Hi Matt,

There is possibility of just IKEv2 SA gets established during IKE_AUTH and
IPsec SA getting established via CREATE_CHILD_SA.
The question is what behavior RFC mandate ? What you think ?

Thanks for your reply.

Regards,
Raj

---

From: Matthew Cini Sarreo <[email-masked]>
Date: Wed, 22 Apr 2009 08:38:04 +0200

Hello Raj,

According to Appendix C, for IKE_AUTH:

   error in Child SA  <--  IDr, [CERT+],
   creation                AUTH,
                              N(error),
                              [V+]

So sending an authenticated and encrypted INVALID_SYNTAX notification over
the IKE_SA that has just been authenticated seems to be correct.

Regards,
Matt

>>> It seems that the correct error message would be INVALID_SYNTAX. This
>>> would require the message ID and the checksum to be valid. Note that this
>>> has (may only) be sent in an encrypted response.
>>>
>>>>> What is the expected behavior if as a responder we do not receive TSi
>>>>> and TSr in IKE_AUTH exchange ?
>>>>> Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out
>>>>> TSi and TSr ?

---

From: raj singh <[email-masked]>
Date: Wed, 22 Apr 2009 12:21:20 +0530

Hi Matt,

Let me re-phrase my questions:
1. If there is no TSi and TSr payload in IKE_AUTH exchange, whether we go
ahead and process IKE_AUTH payloads or not ?
2. Appendix C: IKE_AUTH: Error in CHILD SA creation. It will come into
picture if we process the packet.
    If we go ahead and process the packet, according to appendix C, we
SHOULD/MUST establish the IKE SA ?
    Looks like, if we go ahead to process the IKE_AUTH packet with no TSi
and TSr, we can establish the IKEv2 SA.

I request more experts to comment.

Thanks for your reply.

Regards,
Raj

On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini Sarreo <[email-masked]>wrote:

>>> There is possibility of just IKEv2 SA gets established during IKE_AUTH
>>> and IPsec SA getting established via CREATE_CHILD_SA.
>>>> In IKE_AUTH TSi and TSr are mandatory, so it is not possible to omit
>>>> them from an authentication exchange message, as there would be no way for
>>>> the SA to know what traffic should be forwarded through the SA.
>>>>
>>>>>> If we reject the packet during packet validation with doing ID and
>>>>>> AUTH payload processing, what ERROR should be send ?
>>>>>>
>>>>>> Thanks,
>>>>>> Raj
>>>>>>
>>>>>>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 22 Apr 2009 10:41:31 +0300

Hi Raj

Matt is correct. There is no way in IKEv2 to do a phase1-only exchange, and then wait for traffic to establish the child SAs.

While we do establish an IKE SA if the piggy-backed child SA failed for whatever reason (bad selectors, no proposal chosen), we don't allow for an IKE_AUTH exchange that is missing the child payloads.

An IKE_AUTH request without the TSi and TSr payloads is considered malformed, and so MUST NOT be processed. Instead, you should reply with INVALID_SYNTAX

As to question 2, the text refers to a child SA creation that failed, not to one that was never attempted.

Of course it is possible to generate that effect - propose non-existant cryptographic algorithms, or IPv7 addresses in the selectors, but that IMO is a misuse of the protocol.

Yoav

Raj Singh wrote:
Hi Matt,

Let me re-phrase my questions:
1. If there is no TSi and TSr payload in IKE_AUTH exchange, whether we go ahead and process IKE_AUTH payloads or not ?
2. Appendix C: IKE_AUTH: Error in CHILD SA creation. It will come into picture if we process the packet.
    If we go ahead and process the packet, according to appendix C, we SHOULD/MUST establish the IKE SA ?
    Looks like, if we go ahead to process the IKE_AUTH packet with no TSi and TSr, we can establish the IKEv2 SA.

Thanks for your reply.

Regards,
Raj

On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini Sarreo <[email-masked]<mailto:[email-masked]>> wrote:
Hello Raj,

So sending an authenticated and encrypted INVALID_SYNTAX notification over the IKE_SA that has just been authenticated seems to be correct.

Regards,
Matt

2009/4/22 raj singh <[email-masked]<mailto:[email-masked]>>
Hi Matt,

There is possibility of just IKEv2 SA gets established during IKE_AUTH and IPsec SA getting established via CREATE_CHILD_SA.
The question is what behavior RFC mandate ? What you think ?

Thanks for your reply.

Regards,
Raj

On Wed, Apr 22, 2009 at 11:40 AM, Matthew Cini Sarreo <[email-masked]<mailto:[email-masked]>> wrote:
In IKE_AUTH TSi and TSr are mandatory, so it is not possible to omit them from an authentication exchange message, as there would be no way for the SA to know what traffic should be forwarded through the SA.

It seems that the correct error message would be INVALID_SYNTAX. This would require the message ID and the checksum to be valid. Note that this has (may only) be sent in an encrypted response.

Regards,
Matt

2009/4/22 raj singh <[email-masked]<mailto:[email-masked]>>
Hi Group,

What is the expected behavior if as a responder we do not receive TSi and TSr in IKE_AUTH exchange ?
Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out TSi and TSr ?
Or we should reject the packet ?
If we reject the packet during packet validation with doing ID and AUTH payload processing, what ERROR should be send ?

Thanks,
Raj

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

Email secured by Check Point

---

From: raj singh <[email-masked]>
Date: Wed, 22 Apr 2009 14:37:14 +0530

Hi Matt/Youv,

Thanks for your reply.
I will conclude as IKE_AUTH exchange MUST have TSi and TSr payload. We MUST
NOT process IKE_AUTH packet without TSi and TSr and we should reply with
INVALID_SYNTAX notification without IDr, AUTH, TSi and TSr payloads.

Regards,
Raj

On Wed, Apr 22, 2009 at 1:11 PM, Yoav Nir <[email-masked]> wrote:

>  Hi Raj
>
> Matt is correct. There is no way in IKEv2 to do a phase1-only exchange, and
> then wait for traffic to establish the child SAs.
>
> While we do establish an IKE SA if the piggy-backed child SA failed for
> whatever reason (bad selectors, no proposal chosen), we don't allow for an
> IKE_AUTH exchange that is missing the child payloads.
>
> An IKE_AUTH request without the TSi and TSr payloads is
> considered malformed, and so MUST NOT be processed. Instead, you should
> reply with INVALID_SYNTAX
>
> Of course it is possible to generate that effect - propose non-existant
> cryptographic algorithms, or IPv7 addresses in the selectors, but that IMO
> is a misuse of the protocol.
>
> Yoav
>
> Raj Singh wrote:
>
> Hi Matt,
>
>>>> On Wed, Apr 22, 2009 at 11:40 AM, Matthew Cini Sarreo <[email-masked]
>>>> > wrote:
>>>>

---

From: Matthew Cini Sarreo <[email-masked]>
Date: Wed, 22 Apr 2009 11:18:47 +0200

Hello Raj,

You still need the IDr and AUTH payloads in the reply. This is needed as
INVALID_SYNTAX is authenticated and encrypted.

Regards,
Matt

>> Matt is correct. There is no way in IKEv2 to do a phase1-only exchange,
>> and then wait for traffic to establish the child SAs.
>>
>>> So sending an authenticated and encrypted INVALID_SYNTAX notification
>>> over the IKE_SA that has just been authenticated seems to be correct.
>>>
>>> Regards,
>>> Matt
>>>
>>>
>>>>
>>>>> On Wed, Apr 22, 2009 at 11:40 AM, Matthew Cini Sarreo <
>>>>> [email-masked]> wrote:
>>>>>

---

From: raj singh <[email-masked]>
Date: Wed, 22 Apr 2009 14:55:39 +0530

Hi Matt,

Buy as per Youv, we should not process the request.
Is that means, that we will not process the request but send IDr and AUTH
payloads ?

Thanks,
Raj

On Wed, Apr 22, 2009 at 2:48 PM, Matthew Cini Sarreo <[email-masked]>wrote:

>> I will conclude as IKE_AUTH exchange MUST have TSi and TSr payload. We
>> MUST NOT process IKE_AUTH packet without TSi and TSr and we should reply
>> with INVALID_SYNTAX notification without IDr, AUTH, TSi and TSr payloads.
>>
>> Regards,
>> Raj
>>
>>
>>>>>>>  In IKE_AUTH TSi and TSr are mandatory, so it is not possible to
>>>>>>> omit them from an authentication exchange message, as there would be no way
>>>>>>> for the SA to know what traffic should be forwarded through the SA.
>>>>>>>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 22 Apr 2009 14:13:29 +0300

> INVALID_SYNTAX is authenticated and encrypted.

INVALID_SYNTAX is fatal error meaning that other end didn't follow the
protocol specification, and the IKE SA is going to be removed anyways,
and there is not really point of putting AUTH payload there (it can be
there, but there is no need).

If the other end is not following protocol specification (i.e. is
non-complient), there is not really point of trying to be nice. This
is something that cannot be seen by normal customers ever, it should
only be seen by the implementors when they are testing against broken
implementations.

So better just send error message back as it is easiest for your
implementation (i.e. if it is easy to include AUTH etc to the error
message, then do so, if not, then leave them out). 
-- 
[email-masked]

---

From: raj singh <[email-masked]>
Date: Wed, 22 Apr 2009 18:57:48 +0530

Hi Tero,

It make sense.
The same point i want to make, if we as a responder are not going to process
the packet,
there is NO need to add IDr and AUTH with INVALID_SYNTAX during IKE_AUTH.

Regards,
Raj