Subject: IKEv2 SA rekeying - naming an initial SA

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Aug 2003 11:25:32 -0700

I'm glad to see that there is some SA rekeying functionality in IKEv2
that is somewhat like the rekeying functionality in SSHv2, that is, that
a new SA can be established under the protection of and bound to a
previous (still live) SA.

Now, if only there was a concept similar to the SSHv2 session ID.  (Or
is it there and I just missed it?)

If there is no IKEv2 equivalent to the SSHv2 session ID, I would like to
have one defined.

We have a need for a way to name a [transport mode] SA and its rekeyed
replacements where the name is cryptographically bound to the initial SA
key exchange.

See:

http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt

(and please note that we already know that sections 5.1 and 5.2 of
draft-ietf-nfsv4-ccm-01.txt are wrong.)

Thanks,

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Aug 2003 17:08:08 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
    Nicolas> I'm glad to see that there is some SA rekeying functionality in
    Nicolas> IKEv2 that is somewhat like the rekeying functionality in SSHv2,
    Nicolas> that is, that a new SA can be established under the protection
    Nicolas> of and bound to a previous (still live) SA.

    Nicolas> Now, if only there was a concept similar to the SSHv2 session
    Nicolas> ID.  (Or is it there and I just missed it?)

  I'd like to see such a thing as well.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Aug 2003 14:40:40 -0700

>   I'd like to see such a thing as well.

Perhaps a quantity derived from SK_d and the SPIs of the initial IKE_SA,
or from SKEYSEED and the SPIs of the initial IKE_SA.  Perhaps it would
be useful generally to include AUTH or other material pertaining to
authentication in the derivation, but for use with CCM (the proposed
GSS-API mechanism, not the cipher mode) that is not necessary.

Background:

The Channel Conjunction Mechanism (CCM) is a GSS-API pseudo-mechanism
for negotiating the use of GSS-API channel bindings and the non-use of
session cryptographic protection at the application/GSS-API layer
because a lower layer provides acceptable session protection.  Thus, if
the GSS-API initiator and acceptor have the same channel bindings to a
lower layer session (e.g., an SSHv2 session, or an IKEv2 SA) and a GSS
security context bound to those channel bindings, and if these channel
bindings are derived from a key exchange involving DH, then there is no
MITM and the GSS-API need not provide any session cryptographic
protection.

Summary:  Authentication at one layer (application/GSS-API) bound to
secure sessions at a lower layer (IPsec).

See the NFSv4 list's archives from last December through May or so for
more information, including expected performance savings from using the
CCM GSS-API mechanism in conjunction with secure transports.

Cheers,

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Aug 2003 19:30:53 -0400

-----BEGIN PGP SIGNED MESSAGE-----

    >> I'd like to see such a thing as well.

    Nicolas> Perhaps a quantity derived from SK_d and the SPIs of the initial
    Nicolas> IKE_SA, or from SKEYSEED and the SPIs of the initial IKE_SA.

  Hmm. That wasn't what I was thinking about.
  Such a thing would not be able to persist across phase 1 rekeys.
 
  I was thinking more like... initiator contributes 16 or 32 bits from a
PRNG, and responder the same. We have a 32 or 64 bit value which we call
"Channel ID" or some such, and we then mention this in the rekey operation
to be clear we want a rekey (add/delete) rather than an entirely new SA
that might be identical, but will be used for a different QoS or some such.
(based upon a selector that we do not need to communicate to the peer)

  The PPVPN people wanted this.  
  I gotta read -9 and -10 :-(

  The number is also

    Nicolas> Summary: Authentication at one layer (application/GSS-API) bound
    Nicolas> to secure sessions at a lower layer (IPsec).

    Nicolas> See the NFSv4 list's archives from last December through May or
    Nicolas> so for more information, including expected performance savings
    Nicolas> from using the CCM GSS-API mechanism in conjunction with secure
    Nicolas> transports.

  It makes a good number to stick on the packets as they wander through the
kernel. I think that's what you are saying.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Aug 2003 22:32:05 -0400

Michael,

A while ago I proposed using the combination of the sender and 
receiver SPIs, for a pair of SAs when we need to refer to them, as we 
tend to create them in pairs and the numbers are unique relative to 
the sender and receiver.

Steve

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Aug 2003 21:43:53 -0700

> (based upon a selector that we do not need to communicate to the peer)

No, it HAS to be cryptographically bound to the DH exchange.

The whole point of CCM (the proposed GSS mech) is to prove that an
underlying secure layer has no MITM - we can do this by proving that
both peers had the same DH public numbers and/or DH key.

> kernel. I think that's what you are saying.

No, that's not what I'm saying.

Please see:

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Aug 2003 22:12:21 -0700

> tend to create them in pairs and the numbers are unique relative to 

This is fine for a lot of things, but it's not ok when it comes to
defining a quantity that can be bound to by other crypto protocols.
That's because the SPIs are self-selected (IIUC) and not bound to the
key exchange, so a MITM could cause the SPIi/r pairss to match on both
sides, whereas it could not force the DH public numbers and g^ir mod p
to match on both sides.

You may answer "sure, but IKEv2 takes care of this by authenticating the
KE," but there's a problem with that: if you're trying to securely bind
authentication at an application layer to IKEv2 at a lower layer you may
not care about or be able to intelligently say anything about the
identities authenticated at the IKEv2 layer.  One could use those
identities as the channel bindings quantity, but that automatically and
forever prevents the combined use of anonymous key exchanges at the
lower layer with channel binding (I realize that there is no recognized
anonymous mode for IPsec, but the proposed CCM GSS-API mechanism makes
such a thing worthwhile).

Cheers,

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Aug 2003 11:10:33 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:
    Stephen> A while ago I proposed using the combination of the sender and
    Stephen> receiver SPIs, for a pair of SAs when we need to refer to them,
    Stephen> as we tend to create them in pairs and the numbers are unique
    Stephen> relative to the sender and receiver.

  This will work if you keep this number for all subsequent SAs which are
keyed. How we create the number isn't so important - what matters is that
there is a place to put it when we rekey.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 Aug 2003 16:31:36 -0400

Nico,

sorry for the confusion on my part. I though you were trying to find 
a way to ID SAs for rekeying in IKE.  That was the context in which I 
made my original suggestion. With the sorts of authentication we have 
historically defined for use with IKE, MITM attacks are not an issue, 
s

IPsec has no anonymous mode, because access control is an essential 
feature of IPsec, unlike SSL.  So, no arguments based on the latter 
paragraph of your message are likely to be appropriate in this 
context.

Steve

---

From: [email-masked]
Date: Tue, 19 Aug 2003 21:02:20 -0400

I believe this functionality was added as a side effect of addressing
Issue #64 (though it's a little different and might not address all
imaginable cases). When an SA is rekeyed, the SPI of the old SA is
now specified, so there is no ambiguity. The binding between the old
SA and the new is not cryptographic, but in every case I could think of
the assertion of the SPI by the trusted IKE association defeats the
same attacks.

      --Charlie

p.s. There remains the problem - inherent to the layering in IPsec - that
there is no specified API by which an app receiving packets can ask IPsec
whether this packet is coming from the same authenticated entity as
another packet with the same source address received in the past.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Aug 2003 07:43:25 -0400

At 20:25 -0700 8/19/03, Nicolas Williams wrote:
>On Tue, Aug 19, 2003 at 04:31:36PM -0400, Stephen Kent wrote:
>>  Nico,
>>
>One would never want to use anonymous IPsec with any application *other*
>than applications which bind authentication at higher layers to IPsec
>SAs.
>
>But if one can do that, then the authenticated identities at the IPsec
>layer become irrelevant, particularly if such applications are doing
>mutual authentication at the application layer.
>
>Thus one would want to set policies that allow the use of anon IPsec
>ONLY for apps such as NFS (w/ RPCSEC_GSS & CCM).
>
>Cheers,
>
>Nico
>--

Nico,

I'm not arguing about one might do with an IP layer security protocol 
in general. I am noting that this WG has made a decision about the 
services offered in IPsec a number of years ago.

steve

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Aug 2003 19:58:34 -0700

> another packet with the same source address received in the past.

Indeed.  But I'm taking each step one at a time.  The crucial feature we
need for the CCM GSS-API mechanism is cryptographically chained SA
re-keys and an identifier cryptographically bound to the initial SA.

The interface issue is relatively simple to deal with, but it won't help
to have it and not have the above.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Aug 2003 10:54:11 -0700

> the assertion of the SPI by the trusted IKE association defeats the

Section 2.18 says pretty clearly shows that rekeyed IKE_SAs are
cryptographically bound to their immediate predecessors by binding the
new SKEYSEED (and the new SK_d, SK_ai, SK_ar, and SK_ei, and SK_er) to
the SK_d of the previous IKE_SA.  The SKEYSEED, of course, is bound to
the key exchange.

(Thus every rekeyed IKE_SAs is ultimately bound to its initial IKE_SA by
 chained binding to each previous IKE_SA's SK_d.  Does the binding
 decrease in strength with each rekey?)

I proposed that the session ID of an initial IKE_SA be derived from
either its SKEYSEED or SK_d.  E.g.,

       {SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_id}
                 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )

       session ID = SK_id | SPIi | SPIr

or

       session ID = prf(SK_d | "IKE session ID") | SPIi | SPIr

Or something of the sort.  It should fit right in.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Aug 2003 20:42:47 -0700

> the assertion of the SPI by the trusted IKE association defeats the

My understanding of the text in -9/-10 is that "rekeys" occur under the
protection of the SA being rekeyed.  That suffices, from my p.o.v. to
bind the new SA to the old SA and all that's missing is a session ID
cryptographically bound to the initial IKE_SA KE.

It's more than possible that I misunderstood the text on rekeying in
draft-ietf-ipsec-ikev2-10 - if so I hope it's not too late to fix the
rekeying functionality (and in any case I hope it's not too late to add
the session ID I also need).

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Aug 2003 22:55:20 -0500

> than applications which bind authentication at higher layers to IPsec
...

I'd also like to point out that if we allow non-kg EAPs then we might as
well allow anonymous IKEv2 :) :)

And if we allow IKEv2 w/ non-kg EAPs (with loud warnings) because we
think that others will implement the same regardless of whether it is a
MUST NOT, then we ought to allow anon IKEv2 for the same reason (and
also with loud warnings).

And note that anon IPsec with GSS-API CCM channel bindings to the same
is quite strong[*], compared to IPsec w/ non-kg EAPs.  The former is not
subject to MITMs or spoofing, the latter is.

[*]  As strong as the authentication and integrity protection services
     of the underlying GSS-API mechanism.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Aug 2003 20:25:24 -0700

Cheers,

Nico
--

---

From: Stephen Kent <[email-masked]>
Date: Fri, 22 Aug 2003 09:12:28 -0400

>      of the underlying GSS-API mechanism.

what part of "no" do you find puzzling :-)

Steve

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Aug 2003 15:42:50 -0700

On Mon, Aug 25, 2003 at 08:39:36AM -0400, Stephen Kent wrote:
> At 8:39 -0700 8/22/03, Nicolas Williams wrote:
> >If there will never be anon IPsec then the AUTH values will do - but I'd
> >like to not discount the possibility that there might be an anon IPsec
> >formulation in the future.
> 
> Any admin managing an IPsec environment has the ability to issue 
> credentials that are effectively anonymous, and that allows the 
> effect of anonymous use of IPsec, in a given context.  Unless the WG 
> changes direction in a significant way, to support unauthenticated 
> IPsec, then it would be inappropriate to use the possibility of this 
> change as an input in deciding on how to make a decision re this IKE 
> v2 authentication issue.

Sure, but this does not dispose of the issue - you're merely rejecting
one rationale for specifying a "session ID" as anything other than the
AUTH values.  But then, if the WG ignores the session ID issue we can
default to using the AUTH values as such, since they are bound to the
KE.

Between each IKE_SA rekey being bound to the previous IKE_SA's KE and
the AUTH values I think we have enough to specify how to use th GSS CCM
mechanism with IKEv2 and the IPSEC interfaces requirements.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 Aug 2003 12:24:46 -0700

On Wed, Aug 27, 2003 at 03:10:39PM -0400, Stephen Kent wrote:
> At 15:42 -0700 8/25/03, Nicolas Williams wrote:
> I'm rejecting an argument for why we should change the specs to 
> accommodate a function that we can already provide, irrespective of 
> the discussion about session IDs.

I'll wait a bit for answers from other participants.  If there are none
I will go ahead and use the AUTH values as the session ID to bind
GSS-API contexts to.

I would rather see a session ID defined that is bound to the KE but not
to the authentication.

Cheers,

Nico
--

---

From: Stephen Kent <[email-masked]>
Date: Wed, 27 Aug 2003 15:10:39 -0400

Steve