Subject: [IPsec] Resolution of some open issues

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Jan 2009 15:46:04 -0800

--Paul Hoffman

#9: Notification when creation of CHILD_SA fails
	No comments, but seems important. New text will say:
	- Failure of CHILD SA creation should not tear down IKE SA because
	  there is no reason to lose the work done
	- When IKE SA is not created, and we need to send error message back
	  about that, do not encrypt the message because it will not
	  authenticate. 

#50: Change the SHOULD for KE in Section 1.3.2 to a MUST
	Accepted; easy change to 1.3.2.

#22: Add section on simultaneous IKE SA rekey
	Accepted; need to come up with draft changes

#30: Conflicts in DH proposals
	Accepted.

	In section 3.4:

	The DH Group # identifies the Diffie-Hellman group in which the Key
	Exchange Data was computed (see Section 3.3.2).  If the selected
	proposal uses a different Diffie-Hellman group (other than NONE), the
	message MUST be rejected with a Notify payload of type
	INVALID_KE_PAYLOAD.
	
	becomes
	
	The DH Group # identifies the Diffie-Hellman group in which the
	Key Exchange Data was computed (see Section 3.3.2).  This Group #
	MUST match a DH Group specified in a proposal in the SA payload
	that is sent in the same message, and SHOULD match the DH group in
	the first group in the first proposal, if such exists. If none of
	the proposals in that SA payload specifies a DH Group, the  KE
	payload MUST NOT be present. If the selected proposal uses a
	different Diffie-Hellman group (other than NONE), the message MUST
	be rejected with a Notify payload of type INVALID_KE_PAYLOAD.

#40: Floating to port 4500 'by default', and use of UDP when no NAT detected
	Accepted; need to come up with draft changes. Text will say something like:

	An initiator can float to port 4500, regardless whether or not
	there is NAT, even at the beginning of IKE. When either side is
	using port 4500, sending with UDP encapsulation is not required,
	but understanding received packets with UDP encapsulation is
	required. UDP encapsulation MUST NOT be done on port 500. If NAT-T
	is supported, all devices MUST be able to receive and process both
	UDP encapsulated and non-UDP encapsulated packets at any time.
	Either side can decide whether or not to use UDP encapsulation
	irrespective of the choice made by the other side. However, if a
	NAT is detected, both devices MUST send UDP encapsulated packets.

#46: Exchange type for INVALID_IKE_SPI outside of an IKE_SA
	Accepted. In section 1.5, say that the the responder should copy
	the Exchange Type from the request for the one-way INVALID_IKE_SPI
	notification for an unrecognized SPI?
 
#55: Exponential reuse - reference for section 2.12
	We don't have a good model for what we mean by "secure" reuse (the
	new keys are related but not predictable), so we can skip this.

#56: Address and config values lifetime
	No comment on this, so it is still open. There were two proposed
	solutions:
	- Gateway should try to renew DHCP leases, but nuke the SA if lease
	  renewal fails
	- Lifetime of the first lease is the lifetime of the SA, no renewals

#65: Original initiator and rekeying
	No comments, but is a clearly desired clarification. This will say:
	- The old SA uses the old roles and old message IDs
	- The new SA that is created by rekeying  will use the roles of the
	  original initiator and responder (never changed) and the mesage IDs are reset to 0
	- Will add diagram

#79: IKEv2 CP with CREATE-CHILD-SA exchange
	Accepted. Add to the end of the first paragraph of 2.19:
	Note, however, it is usual to only assign one IP address during
	the IKE_AUTH exchange.  That address persists at least until the
	deletion of the IKE SA.

#81: NO_PROPOSAL_CHOSEN and USE_TRANSPORT_MODE or IPCOMP_SUPPORTED
	Accepted. Tero's proposal for a change to "NO_PROPOSAL_CHOSEN"
	will be used:
   NO_PROPOSAL_CHOSEN                       14

       None of the proposed crypto suites was acceptable. This can be
       sent in any case where the offered proposal (including but not
       limited to SA payload values, USE_TRANSPORT_MODE notify,
       IPCOMP_SUPPORTED notify) are not acceptable for the responder.
       This can also be used as "generic" Child SA error when Child SA
       cannot be created for some other reason. See also Section 2.7.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 23 Jan 2009 08:00:08 -0500

Paul, regarding #40:

        > If NAT-T is supported, all devices MUST be able to receive and 
process
        > both UDP encapsulated and non-UDP encapsulated packets at any 
time.

How should I read this statement in the context of multiple address 
families?  If an implementation supports IPv4 and IPv6, but supports NAT-T 
only for IPv4, can I read this statement to say that the implementation 
MUST tolerate UDP-encapsulation in the absence of a NAT only for IPv4?

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Paul Hoffman <[email-masked]>
To:
IPsecme WG <[email-masked]>
Date:
01/22/2009 06:46 PM
Subject:
[IPsec] Resolution of some open issues

Sorry for the long delay here. We want to clear these off so we can start 
on the next batch before the interim call.

--Paul Hoffman

#9: Notification when creation of CHILD_SA fails
                 No comments, but seems important. New text will say:
                 - Failure of CHILD SA creation should not tear down IKE 
SA because
                   there is no reason to lose the work done
                 - When IKE SA is not created, and we need to send error 
message back
                   about that, do not encrypt the message because it will 
not
                   authenticate. 

                 In section 3.4:

                 The DH Group # identifies the Diffie-Hellman group in 
which the Key
                 Exchange Data was computed (see Section 3.3.2).  If the 
selected
                 proposal uses a different Diffie-Hellman group (other 
than NONE), the
                 message MUST be rejected with a Notify payload of type
                 INVALID_KE_PAYLOAD.
 
                 becomes
 
                 The DH Group # identifies the Diffie-Hellman group in 
which the
                 Key Exchange Data was computed (see Section 3.3.2).  This 
Group #
                 MUST match a DH Group specified in a proposal in the SA 
payload
                 that is sent in the same message, and SHOULD match the DH 
group in
                 the first group in the first proposal, if such exists. If 
none of
                 the proposals in that SA payload specifies a DH Group, 
the  KE
                 payload MUST NOT be present. If the selected proposal 
uses a
                 different Diffie-Hellman group (other than NONE), the 
message MUST
                 be rejected with a Notify payload of type 
INVALID_KE_PAYLOAD.

#40: Floating to port 4500 'by default', and use of UDP when no NAT 
detected
                 Accepted; need to come up with draft changes. Text will 
say something like:

                 An initiator can float to port 4500, regardless whether 
or not
                 there is NAT, even at the beginning of IKE. When either 
side is
                 using port 4500, sending with UDP encapsulation is not 
required,
                 but understanding received packets with UDP encapsulation 
is
                 required. UDP encapsulation MUST NOT be done on port 500. 
If NAT-T
                 is supported, all devices MUST be able to receive and 
process both
                 UDP encapsulated and non-UDP encapsulated packets at any 
time.
                 Either side can decide whether or not to use UDP 
encapsulation
                 irrespective of the choice made by the other side. 
However, if a
                 NAT is detected, both devices MUST send UDP encapsulated 
packets.

#46: Exchange type for INVALID_IKE_SPI outside of an IKE_SA
                 Accepted. In section 1.5, say that the the responder 
should copy
                 the Exchange Type from the request for the one-way 
INVALID_IKE_SPI
                 notification for an unrecognized SPI?
 
#55: Exponential reuse - reference for section 2.12
                 We don't have a good model for what we mean by "secure" 
reuse (the
                 new keys are related but not predictable), so we can skip 
this.

#56: Address and config values lifetime
                 No comment on this, so it is still open. There were two 
proposed
                 solutions:
                 - Gateway should try to renew DHCP leases, but nuke the 
SA if lease
                   renewal fails
                 - Lifetime of the first lease is the lifetime of the SA, 
no renewals

#65: Original initiator and rekeying
                 No comments, but is a clearly desired clarification. This 
will say:
                 - The old SA uses the old roles and old message IDs
                 - The new SA that is created by rekeying  will use the 
roles of the
                   original initiator and responder (never changed) and 
the mesage IDs are reset to 0
                 - Will add diagram

#79: IKEv2 CP with CREATE-CHILD-SA exchange
                 Accepted. Add to the end of the first paragraph of 2.19:
                 Note, however, it is usual to only assign one IP address 
during
                 the IKE_AUTH exchange.  That address persists at least 
until the
                 deletion of the IKE SA.

#81: NO_PROPOSAL_CHOSEN and USE_TRANSPORT_MODE or IPCOMP_SUPPORTED
                 Accepted. Tero's proposal for a change to 
"NO_PROPOSAL_CHOSEN"
                 will be used:
   NO_PROPOSAL_CHOSEN                       14

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 23 Jan 2009 15:37:13 +0200

> Sorry for the long delay here. We want to clear these off so we can
> start on the next batch before the interim call.

So do any of these require any actions from us, or is this just
informational mail listing the resolution for open issues, and
ikev2bis document will be modified accordingly?

> 	  about that, do not encrypt the message because it will not

Actually someone pointed out one benefit for the second case, i.e.
when IKE SA cannot be created and we are sending error message back.
If the error message is encrypted (even when it is unauthenticated)
that proofs that the message was sent by the same peer who replied to
the IKE_SA_INIT.

Because of this I think it would be good to split the original #9 to
two cases, one that I do not think anybody disagrees is that failure
of CHILD SA creation should not tear down IKE SA.

And the other is how is the fatal IKE SA creation errors sent back
(i.e. whether to encrypt them or not). 

> 	- Lifetime of the first lease is the lifetime of the SA, no renewals

I think we should left that for implementations to decide. I.e. in
some implementations the gateway can renew the DHCP lease, on some
implementations it can simply delete the IKE SA (as there is no agreed
upon lifetime of IKE SAs in IKEv2 anyways). 

> 	the IKE_AUTH exchange.  That address persists at least until the

Note, that this might have connection to the
draft-ietf-ipsecme-ikev2-ipv6-config draft too. The current solution
in that draft works with this change, but for example Appendix "A.4
IPv4-like Sketch" would not be compatible with this change. This does
not require any changes to the resolution of this item, but the
connection needs to be kept in mind...

Otherwise I do agree on your resolutions... 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 23 Jan 2009 15:42:03 +0200

> MUST tolerate UDP-encapsulation in the absence of a NAT only for IPv4?

I would interpret it that if you support NAT-T only for IPv4, and you
do not support NAT-T for IPv6, then you must be able to receive and
process UDP encapsulated and non-UDP encapsulated packets only from
IPv4.

If you negotiated with IPv6 with a remote peer, the remote peer will
only see that you do not support NAT-T, and that is the situation for
him. He does not know that you support NAT-T for some other address
family.

This is also same if you have NAT-T support disabled by policy for
some interfaces or IP-addresses.

Perhaps the "If NAT-T is supported, ..." should be changed to "If
NAT-T is supported (i.e. NAT_DETECTION_*_IP payloads were exchanged
during IKE_SA_INIT), ...".
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 23 Jan 2009 11:36:37 -0500

Thanks, Tero.

One more comment -- the non-ESP marker is defined only for use on port 
4500.  When data is received on port 500, implementations do not expect it 
to be present.  Consequently, to avoid any ambiguity, we should probably 
take care to stipulate here that if you unilaterally choose to float to 
port 4500, even in the absence of a NAT, you MUST send to port 4500.

From:
Tero Kivinen <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
Paul Hoffman <[email-masked]>, IPsecme WG <[email-masked]>
Date:
01/23/2009 08:42 AM
Subject:
Re: [IPsec] Resolution of some open issues

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 25 Jan 2009 17:46:10 +0200

> upon lifetime of IKE SAs in IKEv2 anyways).

I agree with Tero. But in any case, we need to clarify that config values (and in particular the IP address) are valid exactly for the lifetime of the IKE SA.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 25 Jan 2009 18:00:41 +0200

Hi Paul,

I propose to append the following text to Sec. 2.12:

The reader is referred to Sec. 5 of [1] for a security analysis of this practice, and for additional security considerations when reusing ephemeral ECDH keys.

[1] On reusing ephemeral public keys in Diffie-Hellman key agreement protocols, http://www.cacr.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf (preprint).

Thanks,

      Yaron

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Jan 2009 12:26:49 -0800

>during IKE_SA_INIT), ...".

I like that wording. Scott, does that clear it up for you?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Jan 2009 12:36:13 -0800

At 11:36 AM -0500 1/23/09, Scott C Moonen wrote:
>One more comment -- the non-ESP marker is defined only for use on port 4500.  When data is received on port 500, implementations do not expect it to be present.  Consequently, to avoid any ambiguity, we should probably take care to stipulate here that if you unilaterally choose to float to port 4500, even in the absence of a NAT, you MUST send to port 4500.

This seems gratuitous. Only ports 500 and 4500 are listed in the document, and there are statements like "IKE runs over UDP ports 500 and 4500" in a few places.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Jan 2009 13:24:30 -0800

>that proofs that the message was sent by the same peer who replied to

It does, but it also forces all implementations to keep around keys they know are unauthenticated. That might violate some security policies.

>(i.e. whether to encrypt them or not).

I agree that we should be focusing on the second issue. However, I disagree with the idea that we should support unauthenticated encryption, even for this one error message. How do others feel?

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Jan 2009 13:29:12 +0200

Paul Hoffman wrote:
> It does, but it also forces all implementations to keep around keys they
> know are unauthenticated. That might violate some security policies.

Maybe, but I'm not aware of any such policies. Besides, the keys are only kept long enough to produce an error message (at the time, the initiator thinks everything is going well)

> I agree that we should be focusing on the second issue. However, I
> disagree with the idea that we should support unauthenticated encryption,
> even for this one error message. How do others feel?

The IKE_AUTH exchange is encrypted but not authenticated. I don't see any problem with sending an encrypted message after authentication has failed.

OTOH I see plenty wrong with allowing IKE-SA-destroying messages in the clear after IKE_AUTH has ended.

Sure you can get around this problem with liveness check and waiting before believing the failure message, but requiring it to be encrypted and protected foils such DoS attacks much more effectively.

Email secured by Check Point
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 26 Jan 2009 07:00:26 -0500

Paul, Tero, that sounds good.  Thanks,

From:
Paul Hoffman <[email-masked]>
To:
Tero Kivinen <[email-masked]>, Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
IPsecme WG <[email-masked]>
Date:
01/25/2009 03:27 PM
Subject:
Wording for issue #40

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Jan 2009 15:47:35 +0200

Scott C Moonen writes:
> to be present.

Yes, and I think this is well specified in the RFC (section 2.23 says
that IKE header has four octects of zero prepended if IKE is run over
port 4500).

> Consequently, to avoid any ambiguity, we should probably take care
> to stipulate here that if you unilaterally choose to float to port
> 4500, even in the absence of a NAT, you MUST send to port 4500.

The generic text says that you MUST reply back with port numbers
reversed, so initial requests are processed correctly.

The question is when the responder wants to initiate exchange himself.
I think the current document is missing the text saying whether
responder MUST use the port 4500 in such cases where there is no NAT
(i.e. where initiator decides to float to port 4500 even when there is
no NAT).

I agree that such text should be added.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Jan 2009 16:34:22 +0200

Yoav Nir writes:
> The IKE_AUTH exchange is encrypted but not authenticated. I don't
> see any problem with sending an encrypted message after
> authentication has failed.

Actually there will be message authentication check done for that
packet too, as we do have SK_a* keys already after we finished the
diffie-hellman, and we already did verify the MAC of the incoming
message (if that MAC check fails, implementation will most likely
silently drop that packet without any messages sent back).

The problem is that if we cannot verify the AUTH payload in the
message, we are not sure that we are really talking to the peer we
think we are talking, and that means we are really doing anonymous
Diffie-Hellman.

The packet format will be exactly same than normally, only thing is
that as responder could not verify the AUTH payload, it does not know
that the initiator really was who he claimed to be, and as it does not
include AUTH payload at all, the initiator does not have any way to
verify identity of the responder.

On the other hand only entity who can send those error messages using
the SK_e* and SK_a* generated by the Diffie-Hellman must be either the
other end or the man-in-the-middle. If there was man-in-the-middle
then the exchange will fail anyways, so no harm is done by trusting
the man-in-the-middle claiming he was there... :-)

So in the end I am myself more starting to think that the encrypted
and mac'ed but not authenticated error message might be better.

> the clear after IKE_AUTH has ended.

We are now talking message coming back to the IKE_AUTH request, this
means IKE_AUTH is not ended yet.

> Sure you can get around this problem with liveness check and waiting
> before believing the failure message, but requiring it to be
> encrypted and protected foils such DoS attacks much more
> effectively. 

You need to do that anyways, as there are errors where timeout is only
option. Also old implementations might still send error messages in
clear, or even skip them completely, so you still need to have code to
cope with them. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Jan 2009 16:46:50 +0200

> silently drop that packet without any messages sent back).

What I meant was that we are willing to do the IKE_AUTH exchange when the peer is not authenticated, so doing the same for the error message should not matter.

> means IKE_AUTH is not ended yet.

We are talking about two cases: one is when the responder failed to authenticate the initiator, the other is when the responder authenticated the initiator, but the initiator hasn't authenticated the responder. In the latter case, the responder thinks the IKE SA succeeded, while the initiator knows it hasn't.

IMO the error message should be encrypted and MAC'ed (*not* authenticated!) in both cases.

> clear, or even skip them completely, so you still need to have code to

Yes, you have to have the code, but if the message is encrypted and MAC'ed you can delete the IKE SA (and log/display a message) immediately.

---

From: David Wierbowski <[email-masked]>
Date: Mon, 26 Jan 2009 10:04:03 -0500

>The IKE_AUTH exchange is encrypted but not authenticated. I don't see any,
>problem with sending an encrypted message after authentication has failed.
>
>before believing the failure message, but requiring it to be encrypted
>and protected foils such DoS attacks much more effectively.

I agree.  Sending an unauthenticated but encrypted message allows the SA
to be disposed of in a more timely fashion.

I see nothing wrong with sending an unauthenticated encrypted response if
the IKE AUTH
exchange fails due to an authentication error on the responder side.

If the authentication error occurred on the initiator side I would expect
the initiator to
initiate an encrypted info exchange to delete the IKE SA.

Dave Wierbowski

z/OS Comm Server Developer

Dave Wierbowski

z/OS Comm Server Developer

 Phone:
    Tie line:   620-4055
    External:  607-429-4055

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Jan 2009 19:14:26 +0200

Yoav Nir writes:
> We are talking about two cases: one is when the responder failed to
> authenticate the initiator, the other is when the responder
> authenticated the initiator, but the initiator hasn't authenticated
> the responder. In the latter case, the responder thinks the IKE SA
> succeeded, while the initiator knows it hasn't.

I was only talking the case where the responder failed to authenticate
the initiator and send error message back, i.e:

(1)
       Initiator                          Responder
      -----------                        -----------
       HDR(IKE_SA_INIT), SAi1, KEi, Ni   -->
                            <--    HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ]

       HDR(IKE_AUTH), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                  AUTH, SAi2, TSi, TSr}     -->
                            <--    HDR(IKE_AUTH), SK {N(AUTHENTICATION_FAILED)}

The question is whether the N(AUTHENTICATION_FAILED) is encrypted
(i.e. inside SK {}), or just sent as plain text reply or whether it is
just not set at all.

I do not think there is anything in the document that says the
initiator could or could not send N(AUTHENTICATION_FAILED) error
message after the exchange, i.e. your second case would be:

(2)
       Initiator                          Responder
      -----------                        -----------
       HDR(IKE_SA_INIT), SAi1, KEi, Ni   -->
                            <--    HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ]

       HDR(IKE_AUTH), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                  AUTH, SAi2, TSi, TSr}     -->
                                   <--    HDR(IKE_AUTH), SK {IDr, [CERT,] AUTH,
                                                SAr2, TSi, TSr}

       HDR(INFORMATIONAL), SK {N(AUTHENTICATION_FAILED)} -->
                                   <--    HDR(INFORMATIONAL), SK {}

At least our implementations do consider AUTHENTICATION_FAILED error
as fatal error to IKE SA, so sending it as INFORMATIONAL exchange
after will also work and it does cause IKE SA to be deleted.

The question is whether following be accepted:

(3)
       Initiator                          Responder
      -----------                        -----------
       HDR(IKE_SA_INIT), SAi1, KEi, Ni   -->
                            <--    HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ]

       HDR(IKE_AUTH), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                  AUTH, SAi2, TSi, TSr}     -->
                            <--    HDR(IKE_AUTH), N(AUTHENTICATION_FAILED)

I.e. where the N(AUTHENTICATION_FAILED) is not encrypted in the reply
from responder.

It is clear it MUST NOT be accepted in the (2) case, i.e. the last
INFORMATINAL request having N(AUTHENTICATION_FAILED) notify must be
encrypted, as responder belives the IKE SA is up and working, thus it
will throw away all messages which come without encryption and MAC.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 27 Jan 2009 08:02:28 +0200

> the initiator and send error message back, i.e:

I think the (1) and (2) case are similar enough and an un-MAC'ed AUTHENTICATION_FAILED should be rejected in both cases.