Subject: RE: [Ipsec] doubts about IKEv2 implementation

From: "Charlie Kaufman" <[email-masked]>
Date: Wed, 6 Apr 2005 10:08:58 -0700

Hilarie Orman pointed out to me that part of my posting was
tantalizingly glib (my characterization, not hers).

What I said was:
> Perfect forward secrecy comes from forgetting the DH private key (and
> SK_d) no later
> than when the child SA is closed. To get PFS for the initial pair of
> child SAs, it is necessary to first rekey the IKE SA, forget the
keying
> material associated with it, and then rekey the child SA. By design,
> PFS does not require an additional DH exchange, though it is allowed
> because some crypto people don't believe it.

What I meant was that there is disagreement over the exact definition of
perfect forward secrecy. IKEv2 key rollover meets some definitions even
without additional D-H exchanges, but some people don't believe those
definitions are sufficiently constraining.

I define PFS as the property that once a session has ended neither
endpoint holds any information that would be helpful in decrypting a
recorded conversation.

The process of rekeying an IKE SA generates new keying material by
taking what is effectively a one way hash of the previous keying
material (and the previous keying material cannot be derived from any
long lived state), so by my definition that exchange provides PFS even
without an additional D-H exchange.

A tighter definition of PFS is that no information stored on either
endpoint before a conversation begins is useful in decrypting a
subsequent conversation except by means of a man-in-the-middle attack.
The process of rekeying an IKE SA without D-H does not meet that bar. I
claim that tighter constraint provides no practical additional security,
but this would be a philosophical debate rather than a technical one.

	--Charlie

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Apr 2005 11:03:46 +0300

Hi.

I've read sections 2.19 and 4, and I still have two questions about 
internal addressing:

1. The initiator may send a CFG_REQUEST during the AUTH exchange.  
There are several cases for the responder:
    (A) - the responder does not support CFG
    (B) - the responder supports CFG, but policy says that this user 
does not get it.
    (C) - the responder supports CFG, but not only for IPv4 addresses, 
and the client asked for IPv6 (or vice versa)
    (D) - the responder supports CFG, but its pool is exhausted (or the 
external server is down)

If my understanding is correct, in case (A) the responder will not send 
a CFG_REPLY.  It makes sense that in case (B) the responder will do the 
same.  The question is about cases (C) and (D). I'm assuming that 
internal addresses are not mandatory.  Is there a way to indicate the 
failure to the initiator so that the initiator can decide whether to 
tear down the connection?  Would it be appropriate to send a CFG_REPLY 
with the internal address equal to zero as an indication of failure, or 
MUST the gateway simply not send a CFG_REPLY?

2. Section 4 refers to renewal before the ADDRESS_EXPIRY elapses.  How 
is this renewal performed?  MUST it be done with a CCSA exchange even 
if the SA is not expired?  Can it be done in an informational exchange 
like the APPLICATION_VERSION query?

Thanks, and maybe the answers should go in the clarifications draft.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Apr 2005 14:27:06 +0300

> 2. Section 4 refers to renewal before the ADDRESS_EXPIRY elapses.  How 

And note also that ADDRESS_EXPIRY is optional to implement for the
server, server can simply refuse to give them out, and client can
simply not request it. Clients MUST understand if it replied to them,
but that is all.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Apr 2005 14:25:27 +0300

>     (B) - the responder supports CFG, but policy says that this user 

Yes, simply do not send CFG_REPLY at all. 

>     (D) - the responder supports CFG, but its pool is exhausted (or the 

Send CFG_REPLY, with other parameters, but leave out the
INTERNAL_IP{4,6}_ADDRESS parameters, as you do not have address for
him. This is suitable if he asked both IPv4 and IPv6 and you only had
one of those addresses. Then you probably also fail the IPsec SA
exchange (if this was part of the IKE_AUTH) with
INTERNAL_ADDRESS_FAILURE error, as you cannot narrow down the traffic
selectors if you do not have address where to narrow.

You could also fail the whoe CFG_REQUEST exchange with
INTERNAL_ADDRESS_FAILURE.

> is this renewal performed?

This whole thing is leftover from the IKEv1, and I think it SHOULD NOT
be used at all. The address is valid as long as the IKE SA is valid,
thus if server wants to free unused addresses, he can simply delete
IKE SAs to free the addresses. In the IKEv2 all information related to
the IKE SA goes away when it is deleted, and I see no reason why the
paramters allocated with configuration payload would be exception to
this.

Renewals are only needed when the communication channel is not
reliable, i.e. the server does not have a way to know if the client is
still there and using the address. In IKEv2 we do know when the client
disappears, so we can free the addresses at that point, at the same
time we delete the IKE SA and IPsec SAs tied to it (using that
address).

> MUST it be done with a CCSA exchange even if the SA is not expired?

CREATE_CHILD_SA exchange cannot have CP payloads, so it must be done
as separate informational exchange.

> Can it be done in an informational exchange like the
> APPLICATION_VERSION query?
> 

The whole configuration payload thing is quite badly defined as it is
taken directly from the mode config of IKEv1, and nobody wanted to
modify things from there. The problem is that IKEv2 and IKEv1 do have
different ways of doing that, and for example that ADDRESS_EXPIRY
should have been removed completely when the text was taken to IKEv2
draft etc.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Apr 2005 16:08:26 +0300

> INTERNAL_ADDRESS_FAILURE.

How can you ever avoid this, even with cases (A) and (B) ?

Suppose the initiator sends message #3 as in section 2.19:

       CP(CFG_REQUEST)=
         INTERNAL_ADDRESS(0.0.0.0)
         INTERNAL_NETMASK(0.0.0.0)
         INTERNAL_DNS(0.0.0.0)
       TSi = (0, 0-65536,0.0.0.0-255.255.255.255)
       TSr = (0, 0-65536,0.0.0.0-255.255.255.255)

If the responder is not configured to support CP it cannot narrow the 
selectors and will have to fail anyway.  But it gets weirder still.  In 
the description of the INTERNAL_ADDRESS_FAILURE notification it says 
this:
         INTERNAL_ADDRESS_FAILURE                 36

             Indicates an error assigning an internal address (i.e.,
             INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the
             processing of a Configuration Payload by a responder.  If
             this error is generated within an IKE_AUTH exchange no
             CHILD_SA will be created.

This says that no CHILD_SA is created, but it does not say that no 
IKE_SA is created.  Does this mean that we have an exchange that 
creates an IKE_SA but not a CHILD_SA?  If I understand this correctly, 
at this point the client is supposed to start a new CCSA exchange with 
its own IP address.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Apr 2005 16:09:35 +0300

I guess this parameter originated from expecting to have the IP 
addresses assigned by a DHCP server and not wanting the server to have 
to keep track of DHCP leases.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Apr 2005 16:38:47 +0300

> How can you ever avoid this, even with cases (A) and (B) ?

In case the traffic selectors have something else than any to any,
i.e. if the client already has a IP-address, but only tries to get
additional IP-address allocated from the internal pool. But, yes I
agree that in most cases you simply return INTERNAL_ADDRESS_FAILURE. 

> IKE_SA is created.

Yes, that is right. If there is any problems with the IPsec SA if the
IKE_AUTH, you still do create the IKE SA, but simply fail the IPsec SA
with error code. This applies to the NO_PROSAL_CHOSEN,
SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED,
and TS_UNACCEPTALBE.

The idea is that we have all the information needed to create the IKE
SA, and we have already done the Diffie-Hellman, signature
verification etc, so it would be wasting resources to throw all that
away, just because there was something wrong with the IPsec SA. If the
initiator knows how to fix the situation (add CP, change traffic
selectors, modify algorithms etc) he can do that and initiate
CREATE_CHILD_SA to create new SAs.

If he cannot do anything, he can simply delete the IKE SA if he does
not wnat to have it. 

> Does this mean that we have an exchange that creates an IKE_SA but
> not a CHILD_SA?

Yes.

> If I understand this correctly, at this point the client is supposed
> to start a new CCSA exchange with its own IP address.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Apr 2005 16:44:32 +0300

> to keep track of DHCP leases.

Hmm.... probably true, but the server still needs to keep track of the
IP-addresses assigned to each client and so on, soaddding the lease
time there does not cause that much more bookkeeping. But perhaps this
current way is the best, server can simply leave it out if he
allocates addresses from internal pool and send it if it is using DHCP
server. 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 10 Apr 2005 08:59:24 -0700

>simply not request it. Clients MUST understand if it replied to them,

I'm not sure what you mean by "optional to implement for the server". 
The IKEv2 document says:

    A minimal IPv4 initiator will generate a CP payload containing only
    an INTERNAL_IP4_ADDRESS attribute and will parse the response
    ignoring attributes it does not know how to use. The only attribute
    it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must
    use to bound the lifetime of the SA unless it successfully renews the
    lease before it expires. Minimal initiators need not be able to
    request lease renewals and minimal responders need not respond to
    them.

That doesn't sound optional to me.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Mon, 11 Apr 2005 07:16:34 +0300

> That doesn't sound optional to me.

It is not optional for the initiator (=client), but it is optional for 
the responder (=server)

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 11 Apr 2005 12:56:20 +0300

> That doesn't sound optional to me.

It is not optional to initiator (client). Client must process it if
server sends it. Server can ignore requests to it, and it can simply
never send it. So for server it is optional, as can be seen from here:

   A minimal IPv4 responder implementation will ignore the contents of
   the CP payload except to determine that it includes an
   INTERNAL_IP4_ADDRESS attribute and will respond with the address and
   other related attributes regardless of whether the initiator
   requested them.
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 11 Apr 2005 08:32:44 -0700

>    other related attributes regardless of whether the initiator

Ah, got it. Thanks.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Apr 2005 12:25:20 -0400

At 7:16 AM +0300 4/11/05, Yoav Nir wrote:
>>I'm not sure what you mean by "optional to implement for the 
>>server". The IKEv2 document says:
>>
>It is not optional for the initiator (=client), but it is optional 
>for the responder (=server)

Remember that IPsec is a peer protocol and thus has no clients not 
servers.  The terms "initiator" and "responder" were chosen for use 
in IKE to avoid conveying any client/server model notions ala SSL/TLS.

Steve

---

From: "Marcus D. Leech" <[email-masked]>
Date: Mon, 11 Apr 2005 18:12:35 -0400

Stephen Kent wrote:

> in IKE to avoid conveying any client/server model notions ala SSL/TLS.

In this particular case (which looks to me like the "roadwarrior" case), the
  semantic binding between "initiator"/"client" and
"responder"/"server"/"gateway"
  is stronger than in most other cases, and strikes me as entirely appropriate.

But maybe I'm just easily struck...

-- 
Marcus Leech                Mail:   Dept W669, M/S: 04352P16
Advisor                     Phone: (ESN) 393-9145  +1 613 763 9145
Internet & Security Services
Nortel Networks                          [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Apr 2005 11:34:18 +0300

> in IKE to avoid conveying any client/server model notions ala SSL/TLS.

For configuration payloads there is client/server model to be
processed. IPsec is peer protocol, configuration payload is
client/server protocol (it is used in the remote access, where we have
server (SGW, responder, remote access server/gateway), and client
(remote access client, initiator, client etc).

I think that in remote access scenario (1.1.3 scenario) it is easier
to use remote access client and remote access server names, as it
makes things much easier. Initiator and responder might not match
client and server every time, i.e. server might initiate rekey to the
client, but client must be the one initiating the configuration
payload request to the server, if it wants to get configuration data.
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Apr 2005 10:11:44 -0400

>But maybe I'm just easily struck...

Maybe :-), but the point is that IPsec does not make special 
accommodations for client/server model interactions, unlike SSL/TLS. 
IPsec assumes a peer communication architecture; one is free to use 
it in a client/server context, but should not expect special 
accommodations for that more restrictive case.

Steve

---

From: Yoav Nir <[email-masked]>
Date: Wed, 13 Apr 2005 07:00:22 +0300

As far as I can tell there are three things that break the symmetry 
between peers:
  1. Only the initiator in the initial exchange can ask for CFG
  2. Only the initiator in the initial exchange can be authenticated 
with EAP
  3. Only the initiator in the initial exchange, not the responder can 
be behind a NAT device

The first two are very specific to "roadwarrior" or "work-from-home".  
The third might also apply to small networks using broadband.  Having 
these three things in IKE means that there is a difference between the 
peers.  Perhaps we need some term to differentiate between the original 
initiator and the original responder.

On Apr 12, 2005, at 5:11 PM, Stephen Kent wrote:

> IPsec assumes a peer communication architecture; one is free to use it 
> in a client/server context, but should not expect special