Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00

From: Martin Willi <[email-masked]>
Date: Tue, 05 Oct 2010 14:42:20 +0200

Hi Keith,

> subject "[IPsec] Reauthentication extension for IKEv2"

> certainly rough consensus was not reached.

There was not much demand for such as an extension at this time. To sum
it up, the two main arguments against such an extension were:
1. The current procedure is good enough / it's not worth the effort to
   define and implement an extension.
2. There is not really much demand for reauthentication at all

> I would appreciate comments from the subscribers of this list as to
> whether or not a reauthentication extension for IKEv2 is worth doing

I still think the current reauthentication procedure is problematic,
mainly because of the mentioned INTERNAL_ADDRESS and housekeeping
issues. It is really hard to implement it properly in my opinion.

I also see demand for reauthentication, for example with:
- reauthenticating users periodically with a password based EAP methods
- certificate based smartcard reauthentication, by reentering PIN
- reauthenticating with renewed client certificates
- periodic certificate revocation checking with inline OCSP, RFC4806

> of course I would also appreciate comments on the draft itself. 

I like the approach in your draft. It is relatively lightweight, but
should give enough flexibility in conjunction with repeated
authentication (RFC4478). I would at least mention RFC4478 to show how
each party can trigger the reauthentication procedure.

One problem that is currently not addressed is the handling of
INTERNAL_ADDRESS or other configuration attributes. This is rather
important, as the CHILD_SAs to inherit usually have traffic selectors
derived from the INTERNAL_ADDRESS. We could either:
- silently inherit these attributes along with the CHILD_SAs, as it is
  done during IKE_SA rekeying, or
- re-enroll the attributes in the given reauthentication context
I'd tend to the second option, as the first gets a little complicated if
the responder does not support REAUTH_SA.

Best regards
Martin

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Oct 2010 16:33:33 +0200

Hi Keith.

After reading your draft, I wish I had done this in RFC 4478. Still, I have some comments.

What are the considerations for the responder accepting a re-authentication?

Suppose we have an active IKE SA between Alice and Bob.  Now Bob gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs for the old IKE SA. When should Bob accept?  When should Bob decline? What if later (in the IKE_AUTH exchange) the authenticated identity turns out to be Mallory?

The way the draft is now, anyone can probe for the existence of IKE SPIs by sending IKE_SA_INIT requests with arbitrary IKE SPIs in the REAUTH_SA notification. This is not a particularly useful attack, but no need to expose ourselves to it. I think it would be better to move the notifications to the IKE_AUTH exchange. Once there, the intuitive logic would be:
 - If the peer authenticates as other than Alice, deny REAUTH (fail the exchange?)
 - If authentication fails, ignore it. The old IKE SA remains alive.
 - If the peer authenticates as Alice, allow the reauth.

This leads me to another issue. If the peer authenticates as Alice, we can treat it as an "Alice". Is it OK for "an Alice" to inherit the child SAs of any other "Alice"?  Ideally, there is only one "Alice" and if the peer authenticates as "Alice" it may inherit any child SAs belonging to any IKE SA belonging to "Alice", but I think it would be better to somehow tie the old SA to the new SA with non-public information. Perhaps something derived from the SKEYSEED along with SK_d and the rest.

One final issue. The IKE_AUTH exchange in your draft does not include what's needed for creating new Child SAs. This is not allowed by RFC 5996. There is, however, a soon-to-be-published RFC for this (draft-nir-ipsecme-childless)

Yoav

On Sep 28, 2010, at 10:03 PM, Keith Welter wrote:

> 
> A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has been successfully submitted by Keith Welter and posted to the IETF repository.
> 
> Filename:                  draft-welter-ipsecme-ikev2-reauth
> Revision:                  00
> Title:                                   Reauthentication Extension for IKEv2
> Creation_date:                  2010-09-28
> WG ID:                                   Independent Submission
> Number_of_pages: 10
> 
> Abstract:
> This document extends the Internet Key Exchange (IKEv2) Protocol
> document [IKEv2].  IKEv2 reauthentication does not scale well when an
> IKE SA has multiple Child SAs because each Child SA of the IKE SA to
> be reauthenticated must be renegotiated.  In addition,
> reauthentication is susceptible to the same kinds of exchange
> collisions as those that may occur during rekeying.  This document
> describes a mechanism to detect reauthentication and avoid
> renegotiating the Child SAs.  In addition, this document describes
> proper handling of exchange collisions that may occur during
> reauthentication.
>                                                                                  
> 
> 
> The IETF Secretariat.
> 
> 
> 
> <ATT00001..txt>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 05 Oct 2010 19:48:13 +0200

Hi Yoav,

you are discussing two separate issues related to identity: the "alleged 
identity" (the name presented as IDi and/or authenticated by the 
IKE_AUTH exchange) and the ability to correlate the two SAs using some 
secret information.

I think we should be flexible about the alleged identity. If Alice has 
had a medical operation and is now Alistair, your policy might still 
allow him to reuse the old SA. Some EAP methods support anonymity and 
pseudonymity, and I don't think we want to force them to employ stable 
identities.

But this implies that we need something else to ensure continuity of the 
identity, and mixing the old SK_d into the new authentication certainly 
makes sense.

Thanks,
	Yaron

On 10/05/2010 04:33 PM, Yoav Nir wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Oct 2010 20:47:50 +0200

> pseudonymity, and I don't think we want to force them to employ stable 

All the more reason to have set rules on when a new IKE SA can inherit.

> Scanned by Check Point Total Security Gateway.

---

From: Keith Welter <[email-masked]>
Date: Wed, 6 Oct 2010 14:17:51 -0700

Yoav Nir <[email-masked]> wrote on 10/05/2010 07:33:33 AM:

> Hi Keith.
> 
> After reading your draft, I wish I had done this in RFC 4478. 
That's encouraging.  Thanks.

> Still, I have some comments.
> 
> Suppose we have an active IKE SA between Alice and Bob.  Now Bob 
> gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs
> for the old IKE SA. When should Bob accept?  When should Bob 
> decline? What if later (in the IKE_AUTH exchange) the authenticated 
> identity turns out to be Mallory?
Interesting question.  Would you say that the same problem exists for 
re-authentication as defined in RFC 5996?  It seems to me that in general 
there is nothing but local policy to stop a different IKE peer from 
establishing a child SA with the same traffic selectors as an existing 
child SA.  So I wonder what makes that different from moving an existing 
child SA to a new IKE SA with a different peer.  Can you describe a 
problem that would occur with moving a child SA that would not occur with 
RFC 5996-style reauthentication?

> 
> The way the draft is now, anyone can probe for the existence of IKE 
> SPIs by sending IKE_SA_INIT requests with arbitrary IKE SPIs in the 
> REAUTH_SA notification. This is not a particularly useful attack, 
> but no need to expose ourselves to it. I think it would be better to
> move the notifications to the IKE_AUTH exchange. 
Good point about the potential for SPI probing. 

My first version (unpublished) of the draft actually had the REAUTH_SA 
notification in the IKE_AUTH exchange.  There were three advantages I saw 
for including the REAUTH_SA notification in the IKE_SA_INIT exchange 
instead.  The main advantage was that I could use the presence of the 
REAUTH_SA notification in the IKE_SA_INIT request to signal usage of the 
IKE_AUTH exchange described in the draft that adds no additional children. 
 Even though the child SA piggy-backed on the IKE_AUTH exchange doesn't 
cost any additional round-trips it does cost additional CPU that is 
unnecessary.  And, to be tidy, one would also need to delete the old child 
SA that was re-negotiated before moving all the remaining children to the 
new IKE SA.  So, eliminating the piggy-backed child SA this way seemed 
like a very attractive enhancement.

The second advantage I saw to including the notification in the 
IKE_SA_INIT exchange was that it eliminated an obscure collision case. The 
collision case was awkward to describe but I still have the text for it. 
To be clear, this was written for the version in which the IKE_AUTH 
exchange carried the REAUTH_SA notification:
   If a peer receives a request to reauthenticate an IKE SA for which it
   has not yet sent a request to reauthenticate, but has sent the
   IKE_SA_INIT request with intent to reauthenticate, it SHOULD reply as
   usual but SHOULD NOT include the REAUTH_SA notification in the
   IKE_AUTH request that it will send and SHOULD close the new IKE SA it
   creates after it receives the IKE_AUTH response.

That text hints at the third and final reason.  With the REAUTH_SA 
notification in the IKE_AUTH exchange, one doesn't know that a new IKE SA 
is reauthenticating an old IKE SA until the IKE_AUTH exchange begins. 
Alternatively, with the REAUTH_SA in the IKE_SA_INIT exchange, one knows 
immediately, from the very first IKE message, whether or not a given IKE 
SA is intended to reauthenticate another IKE SA or not.  Whether or not 
removing this ambiguity is really an advantage or a disadvantage is 
debatable I suppose.

I'm not sure those three reasons outweigh your SPI probing concern.  I'm 
assuming there is not already a way to probe for SPIs without the 
REAUTH_SA (I did a quick review of RFC 5996 from that angle and couldn't 
see another way to accomplish such a probe).  If I could still omit the 
piggy-backed child SA from the IKE_AUTH exchange for a reauthentication I 
would be happy to move the notification back to the IKE_AUTH exchange 
where I originally had it.

> Once there, the intuitive logic would be:
> This leads me to another issue. If the peer authenticates as Alice, 
> we can treat it as an "Alice". Is it OK for "an Alice" to inherit 
> the child SAs of any other "Alice"?  Ideally, there is only one 
> "Alice" and if the peer authenticates as "Alice" it may inherit any 
> child SAs belonging to any IKE SA belonging to "Alice", but I think 
> it would be better to somehow tie the old SA to the new SA with non-
> public information. Perhaps something derived from the SKEYSEED 
> along with SK_d and the rest.
I'll defer to Yaron's response here though I'd still like to understand if 
this issue is really isolated to the proposed movement of child SAs for 
reauthentication as I asked above.

> 
> One final issue. The IKE_AUTH exchange in your draft does not 
> include what's needed for creating new Child SAs. This is not 
> allowed by RFC 5996. There is, however, a soon-to-be-published RFC 
> for this (draft-nir-ipsecme-childless)
I was aware of this draft.  Assuming we conclude that it would be best to 
move the REAUTH_SA notification to the IKE_AUTH exchange then I would want 
to refer to that document and specify that it's mechanisms be used to 
avoid creating an additional child SA when reauthenticating an IKE SA. 
However, I'm not clear why the approach described in the current version 
of my draft is a not an acceptable way to specify a childless IKE_AUTH 
exchange.

> > A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has
> been successfully submitted by Keith Welter and posted to the IETF 
repository.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 06 Oct 2010 23:33:28 +0200

Hi Keith,

I think you can exchange the REAUTH notification in the *original* 
IKE_AUTH exchange (when you authenticate for the first time), probably 
with an empty notification data. This would let both peers know that 
they both support the protocol. And then during reauth, you can still 
have the notification in IKE_AUTH. Am I missing anything?

Thanks,
	Yaron

On 10/06/2010 11:17 PM, Keith Welter wrote:
[...]

> piggy-backed child SA from the IKE_AUTH exchange for a reauthentication
> I would be happy to move the notification back to the IKE_AUTH exchange

---

From: Keith Welter <[email-masked]>
Date: Wed, 6 Oct 2010 15:50:17 -0700

Hi Yaron,

Adding an empty REAUTH_SA notification in the original IKE_AUTH exchange 
is a nice way to determine in advance of a reauth if both peers support 
the protocol.  It might be sufficient to only include it in the response 
as is done with the CHILDLESS_IKE_SUPPORTED notification in 
draft-nir-ipsecme-childless.  For the sake of argument though, I could put 
an empty REAUTH_SA notification in the original IKE_SA_INIT exchange and 
accomplish the same thing.  The essential change to avoid the SPI probe 
that Yoav pointed out is that the REAUTH_SA notification be in the 
IKE_AUTH exchange regardless of whether the initiator knows in advance 
that the responder supports the protocol.  At this point, including the 
REAUTH_SA notification in the IKE_AUTH exchange seems like the right thing 
to do and I like your suggestion too.  I can use the peer protocol support 
knowledge to disambiguate the following case:
   If the response
   does not include the REAUTH_SA notification it indicates that either
   the responder does not recognize the IKE SA to be reauthenticated or
   the responder does not support the REAUTH_SA notification.

I also think that the right thing to do is to make 
draft-nir-ipsecme-childless a normative reference in my draft and 
incorporate it's methods for making the IKE_AUTH exchange childless. 

Thanks,
Keith

Yaron Sheffer <[email-masked]> wrote on 10/06/2010 02:33:28 PM:

[...]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Oct 2010 09:48:17 +0200

Hi Keith.

My responses are below, but first I would like to know if you have considered a different solution - having an IKE_AUTH exchange in the middle of the IKE SA lifetime. Suppose the IKE SA has been around for a couple of hours, and has been used for creating some child SAs, why not keep it and just pass one or more IKE_AUTH exchanges?

I had considered this when making 4478, and the only thing that "blocked" me was that I couldn't figure out what to sign in the AUTH payloads. In regular IKE, they sign the IKE_SA_INIT messages, and I didn't like the idea of storing those for the lifetime of the IKE SA. Perhaps we could store the contents of the previous AUTH payload (or a hash thereof) and sign that.

On Oct 6, 2010, at 11:17 PM, Keith Welter wrote:

> Interesting question.  Would you say that the same problem exists for re-authentication as defined in RFC 5996?

In RFC 5996, the new IKE SA does not inherit the old child SAs. New child SAs will be created according to the policy relevant to Mallory.

>  It seems to me that in general there is nothing but local policy to stop a different IKE peer from establishing a child SA with the same traffic selectors as an existing child SA.  So I wonder what makes that different from moving an existing child SA to a new IKE SA with a different peer.  Can you describe a problem that would occur with moving a child SA that would not occur with RFC 5996-style reauthentication? 

The problem is having a child SA that belongs to Mallory, that is not allowed by policy (for Mallory).  Another problem is one user getting another user's IP address, because the servers behind the gateway often rely on IP address for continuation of a session. One way is that when inheriting the child SAs, the IKE implementation goes over them, and only transfers those that agree with policy. That might work for inter-domain, but with remote access, there's usually no pre-defined policy as to what selectors are allowed for the user. 

As Tero pointed out, re-authenticating implies also inheriting the assigned IP address, so I really think you need to set rules (or at least guidance) about the relationship between the old and new authenticated identity (is "Alice" with a password the same as the user who presents a certificate with "CN=Alice,OU=Users"?  What about same DN but a different certificate?)

> My first version (unpublished) of the draft actually had the REAUTH_SA notification in the IKE_AUTH exchange.  There were three advantages I saw for including the REAUTH_SA notification in the IKE_SA_INIT exchange instead.  The main advantage was that I could use the presence of the REAUTH_SA notification in the IKE_SA_INIT request to signal usage of the IKE_AUTH exchange described in the draft that adds no additional children.  Even though the child SA piggy-backed on the IKE_AUTH exchange doesn't cost any additional round-trips it does cost additional CPU that is unnecessary.  And, to be tidy, one would also need to delete the old child SA that was re-negotiated before moving all the remaining children to the new IKE SA.  So, eliminating the piggy-backed child SA this way seemed like a very attractive enhancement. 

The childless notification can be used for signaling, and I agree with Yaron, that support for REAUTH_SA can be signaled in the original IKE_AUTH.

> 
> The second advantage I saw to including the notification in the IKE_SA_INIT exchange was that it eliminated an obscure collision case.  The collision case was awkward to describe but I still have the text for it.  To be clear, this was written for the version in which the IKE_AUTH exchange carried the REAUTH_SA notification: 

I think you can require never to send a REAUTH_SA if you have already received one from the peer. If that means leaving a half-open SA, so be it. RFC 5996 already requires implementations to handle these cases, and you can reduce them with guidance for original initiators to re-authenticate earlier than original responders.

This leaves just the case of both sides having performed the IKE_SA_INIT, and sending the IKE_AUTH request before either receives the other IKE_AUTH request. This can be handled by having the one with lower Initiator SPI win, while the other exchange gets some error message (no proposal chosen?  or a new one?)

> 
> That text hints at the third and final reason.  With the REAUTH_SA notification in the IKE_AUTH exchange, one doesn't know that a new IKE SA is reauthenticating an old IKE SA until the IKE_AUTH exchange begins.  Alternatively, with the REAUTH_SA in the IKE_SA_INIT exchange, one knows immediately, from the very first IKE message, whether or not a given IKE SA is intended to reauthenticate another IKE SA or not.  Whether or not removing this ambiguity is really an advantage or a disadvantage is debatable I suppose. 

OK. I'll debate for the other side. There's no reason to expose to eavesdroppers that we're doing a re-authentication. IKE_AUTH is encrypted, while IKE_SA_INIT is not. 

> 
> I'm not sure those three reasons outweigh your SPI probing concern.  I'm assuming there is not already a way to probe for SPIs without the REAUTH_SA (I did a quick review of RFC 5996 from that angle and couldn't see another way to accomplish such a probe).  If I could still omit the piggy-backed child SA from the IKE_AUTH exchange for a reauthentication I would be happy to move the notification back to the IKE_AUTH exchange where I originally had it. 
> 
> I'll defer to Yaron's response here though I'd still like to understand if this issue is really isolated to the proposed movement of child SAs for reauthentication as I asked above. 

If I connect to work from both computer and my phone, should the phone be able to "steal" the computer's SAs? If IKE is ever integrated with NEA work, it might imply moving SAs that were created with one posture to a host with another posture. Without NEA, it's not so much a security issue, as it is a networking issue.

> I was aware of this draft.  Assuming we conclude that it would be best to move the REAUTH_SA notification to the IKE_AUTH exchange then I would want to refer to that document and specify that it's mechanisms be used to avoid creating an additional child SA when reauthenticating an IKE SA.  However, I'm not clear why the approach described in the current version of my draft is a not an acceptable way to specify a childless IKE_AUTH exchange. 
> 
> > 
> > Yoav
> > 
> > been successfully submitted by Keith Welter and posted to the IETF repository.
> > >

---

From: Keith Welter <[email-masked]>
Date: Thu, 7 Oct 2010 09:44:11 -0700

Answering my own question...

> Interesting question.  Would you say that the same problem exists 
> for re-authentication as defined in RFC 5996?  It seems to me that 
> in general there is nothing but local policy to stop a different IKE
> peer from establishing a child SA with the same traffic selectors as
> an existing child SA.  So I wonder what makes that different from 
> moving an existing child SA to a new IKE SA with a different peer. 
> Can you describe a problem that would occur with moving a child SA 
> that would not occur with RFC 5996-style reauthentication? 

RFC 4301 section 4.4.3.4 "How the PAD is Used" says:
   Child SAs are created based on the exchange of traffic selector
   payloads, either at the end of the initial IKE exchange or in
   subsequent CREATE_CHILD_SA exchanges.  The PAD entry for the (now
   authenticated) IKE peer is used to constrain creation of child SAs;
   specifically, the PAD entry specifies how the SPD is searched using a
   traffic selector proposal from a peer.  There are two choices: either
   the IKE ID asserted by the peer is used to find an SPD entry via its
   symbolic name, or peer IP addresses asserted in traffic selector
   payloads are used for SPD lookups based on the remote IP address
   field portion of an SPD entry.  It is necessary to impose these
   constraints on creation of child SAs to prevent an authenticated peer
   from spoofing IDs associated with other, legitimate peers.

Moving the child SAs for a reauthenticated IKE SA could circumvent the 
checking that allows the PAD to constrain the creation of a child SA to a 
particular IKE peer.  So, I agree that the initiator of a reauth must 
prove that he is the same entity with which the original IKE SA was 
established.  Having the reauth initiator supply the old SK_d as Yoav 
suggested would accomplish that.  The old SK_d can be appended to the SPIs 
in the REAUTH_SA notification.

---

From: Keith Welter <[email-masked]>
Date: Thu, 7 Oct 2010 10:00:36 -0700

A colleague pointed-out that including the old SK_d itself in the 
REAUTH_SA notification is a bad idea.  A better approach would be to 
incorporate it into the new AUTH payload.

> Moving the child SAs for a reauthenticated IKE SA could circumvent 
> the checking that allows the PAD to constrain the creation of a 
> child SA to a particular IKE peer.  So, I agree that the initiator 
> of a reauth must prove that he is the same entity with which the 
> original IKE SA was established.  Having the reauth initiator supply
> the old SK_d as Yoav suggested would accomplish that.  The old SK_d 
> can be appended to the SPIs in the REAUTH_SA 
> notification.

---

From: Keith Welter <[email-masked]>
Date: Thu, 7 Oct 2010 10:26:56 -0700

Hi Yoav,
I made a couple posts before reading this.  Sorry about that.

Yoav Nir <[email-masked]> wrote on 10/07/2010 12:48:17 AM:
[...]
> Hi Keith.
> 
> My responses are below, but first I would like to know if you have 
> considered a different solution - having an IKE_AUTH exchange in the
> middle of the IKE SA lifetime. Suppose the IKE SA has been around 
> for a couple of hours, and has been used for creating some child 
> SAs, why not keep it and just pass one or more IKE_AUTH exchanges?
Interesting.  If support for the new reauth protocol is signaled in the 
original IKE_AUTH exchange then I think you could do a modified IKE_AUTH 
exchange in the old IKE SA to accomplish reauthentication.  That would 
eliminate moving the children and having to prove that the reauth 
initiator is the same entity as he was before.  It also would reduce the 
variety of collision cases substantially.  That sounds very attractive. 
Offhand, I can't think of any reason not to do it.

> 
> I had considered this when making 4478, and the only thing that 
> "blocked" me was that I couldn't figure out what to sign in the AUTH
> payloads. In regular IKE, they sign the IKE_SA_INIT messages, and I 
> didn't like the idea of storing those for the lifetime of the IKE 
> SA. Perhaps we could store the contents of the previous AUTH payload
> (or a hash thereof) and sign that.
Choosing suitable material to sign for a modified IKE_AUTH is not really 
my strong point.  Scott Moonen and Dave Wierbowski are colleagues of mine 
and I suspect they would have good input here.  I'll ask them.

> for re-authentication as defined in RFC 5996?
> 
> In RFC 5996, the new IKE SA does not inherit the old child SAs. New 
> child SAs will be created according to the policy relevant to Mallory.
> 
> >  It seems to me that in general there is nothing but local policy 
> to stop a different IKE peer from establishing a child SA with the 
> same traffic selectors as an existing child SA.  So I wonder what 
> makes that different from moving an existing child SA to a new IKE 
> SA with a different peer.  Can you describe a problem that would 
> occur with moving a child SA that would not occur with RFC 5996-
> style reauthentication? 
> 
> The problem is having a child SA that belongs to Mallory, that is 
> not allowed by policy (for Mallory).  Another problem is one user 
> getting another user's IP address, because the servers behind the 
> gateway often rely on IP address for continuation of a session. One 
> way is that when inheriting the child SAs, the IKE implementation 
> goes over them, and only transfers those that agree with policy. 
> That might work for inter-domain, but with remote access, there's 
> usually no pre-defined policy as to what selectors are allowed for the 
user. 
> 
> As Tero pointed out, re-authenticating implies also inheriting the 
> assigned IP address, so I really think you need to set rules (or at 
> least guidance) about the relationship between the old and new 
> authenticated identity (is "Alice" with a password the same as the 
> user who presents a certificate with "CN=Alice,OU=Users"?  What 
> about same DN but a different certificate?)
> 
> > 
> > > 
> > My first version (unpublished) of the draft actually had the 
> REAUTH_SA notification in the IKE_AUTH exchange.  There were three 
> advantages I saw for including the REAUTH_SA notification in the 
> IKE_SA_INIT exchange instead.  The main advantage was that I could 
> use the presence of the REAUTH_SA notification in the IKE_SA_INIT 
> request to signal usage of the IKE_AUTH exchange described in the 
> draft that adds no additional children.  Even though the child SA 
> piggy-backed on the IKE_AUTH exchange doesn't cost any additional 
> round-trips it does cost additional CPU that is unnecessary.  And, 
> to be tidy, one would also need to delete the old child SA that was 
> re-negotiated before moving all the remaining children to the new 
> IKE SA.  So, eliminating the piggy-backed child SA this way seemed 
> The childless notification can be used for signaling, and I agree 
> with Yaron, that support for REAUTH_SA can be signaled in the 
> original IKE_AUTH.
> 
> > 
> IKE_SA_INIT exchange was that it eliminated an obscure collision 
> case.  The collision case was awkward to describe but I still have 
> the text for it.  To be clear, this was written for the version in 
> which the IKE_AUTH exchange carried the REAUTH_SA notification: 
> I think you can require never to send a REAUTH_SA if you have 
> already received one from the peer. If that means leaving a half-
> open SA, so be it. RFC 5996 already requires implementations to 
> handle these cases, and you can reduce them with guidance for 
> original initiators to re-authenticate earlier than original responders.
> 
> This leaves just the case of both sides having performed the 
> IKE_SA_INIT, and sending the IKE_AUTH request before either receives
> the other IKE_AUTH request. This can be handled by having the one 
> with lower Initiator SPI win, while the other exchange gets some 
> error message (no proposal chosen?  or a new one?)
> 
> > 
> notification in the IKE_AUTH exchange, one doesn't know that a new 
> IKE SA is reauthenticating an old IKE SA until the IKE_AUTH exchange
> begins.  Alternatively, with the REAUTH_SA in the IKE_SA_INIT 
> exchange, one knows immediately, from the very first IKE message, 
> whether or not a given IKE SA is intended to reauthenticate another 
> IKE SA or not.  Whether or not removing this ambiguity is really an 
> advantage or a disadvantage is debatable I suppose. 
> 
> OK. I'll debate for the other side. There's no reason to expose to 
> eavesdroppers that we're doing a re-authentication. IKE_AUTH is 
> encrypted, while IKE_SA_INIT is not. 
> 
> > 
> > I'm not sure those three reasons outweigh your SPI probing 
> concern.  I'm assuming there is not already a way to probe for SPIs 
> without the REAUTH_SA (I did a quick review of RFC 5996 from that 
> angle and couldn't see another way to accomplish such a probe).  If 
> I could still omit the piggy-backed child SA from the IKE_AUTH 
> exchange for a reauthentication I would be happy to move the 
> notification back to the IKE_AUTH exchange where I originally had it. 
> > 
> > I'll defer to Yaron's response here though I'd still like to 
> understand if this issue is really isolated to the proposed movement
> of child SAs for reauthentication as I asked above. 
> 
> If I connect to work from both computer and my phone, should the 
> phone be able to "steal" the computer's SAs? If IKE is ever 
> integrated with NEA work, it might imply moving SAs that were 
> created with one posture to a host with another posture. Without 
> NEA, it's not so much a security issue, as it is a networking issue.
> 
> > 
> > > 
> > I was aware of this draft.  Assuming we conclude that it would be 
> best to move the REAUTH_SA notification to the IKE_AUTH exchange 
> then I would want to refer to that document and specify that it's 
> mechanisms be used to avoid creating an additional child SA when 
> reauthenticating an IKE SA.  However, I'm not clear why the approach
> described in the current version of my draft is a not an acceptable 
> way to specify a childless IKE_AUTH exchange. 
> > 
> > > 
> > > Yoav
> > >

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Oct 2010 21:26:36 +0200

I was not suggesting to use  SK_d itself. 

RFC 5996 says this:

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

I suggest replaceing/augmenting it with this:

   {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr | SK_ri | SK_rr}
                   = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )

Where SK_ri and SK_rr are x number of bits each (128? 256? same as the SK_d?) and these can be used for re-authentication later.

On Oct 7, 2010, at 7:00 PM, Keith Welter wrote:

> 
> A colleague pointed-out that including the old SK_d itself in the REAUTH_SA notification is a bad idea.  A better approach would be to incorporate it into the new AUTH payload. 
>

---

From: Keith Welter <[email-masked]>
Date: Thu, 7 Oct 2010 13:50:17 -0700

> I was not suggesting to use  SK_d itself. 
Sorry, I misread your note.  You clearly did not suggest using SK_d 
itself.

> Where SK_ri and SK_rr are x number of bits each (128? 256? same as 
> the SK_d?) and these can be used for re-authentication later.
First, to level-set, I assume that we are talking about key generation 
during an IKE_AUTH that occurs on a new IKE SA rather than the alternative 
approach you described of doing a subsequent IKE_AUTH exchange on the 
original IKE SA.  I'm confused by what you suggest here though.  Wouldn't 
the augmentation go in the data to which prf+ is applied, rather than the 
output?  For example:
    {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } << new keys >>
    = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | SK_ri | SK_rr ) << augmented 
data from which to derive keys >>

Is that what you meant?  It seems to me that any piece of keying material 
from the old IKE SA that both sides incorporate into the key generation 
for the new IKE SA ought to be sufficient.  So here is another option to 
consider:
    {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } << new keys >>
    = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | prior SK_d ) << augmented 
data from which to derive keys >>

---

From: Keith Welter <[email-masked]>
Date: Thu, 7 Oct 2010 14:15:27 -0700

Keith Welter <[email-masked]> wrote on 10/07/2010 10:26:56 AM:
[...]
> Interesting.  If support for the new reauth protocol is signaled in 
> the original IKE_AUTH exchange then I think you could do a modified 
> IKE_AUTH exchange in the old IKE SA to accomplish reauthentication. 
> That would eliminate moving the children and having to prove that 
> the reauth initiator is the same entity as he was before.  It also 
> would reduce the variety of collision cases substantially.  That 
> sounds very attractive.  Offhand, I can't think of any reason not to do 
it. 
Actually, one down-side does come to mind.  RFC5996-style reauthentication 
and the kind described in my draft both allow the IKE SA attributes such 
as the encryption algorithm to be changed by virtue of the new IKE_SA_INIT 
exchange.  That capability would be lost with IKE_AUTH on the old IKE SA. 
I wouldn't want to take that capability away.  To affect an IKE SA policy 
change you'd have to deactivate/reactivate. 

> Choosing suitable material to sign for a modified IKE_AUTH is not 
> really my strong point.  Scott Moonen and Dave Wierbowski are 
> colleagues of mine and I suspect they would have good input here. 
> I'll ask them. 
Scott responded and said, "I can't think of a problem with Yoav's idea of 
signing the previous Auth payload."

> > usually no pre-defined policy as to what selectors are allowed forthe 
user. 
> > > >  - If the peer authenticates as other than Alice, deny REAUTH 
(fail 
> > > > the exchange?)

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Oct 2010 00:28:34 +0200

On Oct 7, 2010, at 10:50 PM, Keith Welter wrote:

> I was not suggesting to use  SK_d itself.
Sorry, I misread your note.  You clearly did not suggest using SK_d itself.

> the SK_d?) and these can be used for re-authentication later.
First, to level-set, I assume that we are talking about key generation during an IKE_AUTH that occurs on a new IKE SA rather than the alternative approach you described of doing a subsequent IKE_AUTH exchange on the original IKE SA.  I'm confused by what you suggest here though.  Wouldn't the augmentation go in the data to which prf+ is applied, rather than the output?  For example:
    {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } << new keys >>
   = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | SK_ri | SK_rr ) << augmented data from which to derive keys >>

Is that what you meant?  It seems to me that any piece of keying material from the old IKE SA that both sides incorporate into the key generation for the new IKE SA ought to be sufficient.  So here is another option to consider:
    {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } << new keys >>
   = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | prior SK_d ) << augmented data from which to derive keys >>

Nope. I just meant that in the original IKE SA creation, you generate some more values and keep them (in both sides). Later, when we do a re-auth, the peers prove linkage to the old SA by including these SK_ri and SK_rr in the REAUTH_SA notification.

I didn't mean to change the calculation of the keys in the new SA, just produce some more material.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Oct 2010 00:30:22 +0200

On Oct 7, 2010, at 11:15 PM, Keith Welter wrote:

Keith Welter <[email-masked]<mailto:[email-masked]>> wrote on 10/07/2010 10:26:56 AM:
[...]
> Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote on 10/07/2010 12:48:17 AM:
> [...]
> > Hi Keith.
> >
> sounds very attractive.  Offhand, I can't think of any reason not to do it.
Actually, one down-side does come to mind.  RFC5996-style reauthentication and the kind described in my draft both allow the IKE SA attributes such as the encryption algorithm to be changed by virtue of the new IKE_SA_INIT exchange.  That capability would be lost with IKE_AUTH on the old IKE SA.  I wouldn't want to take that capability away.  To affect an IKE SA policy change you'd have to deactivate/reactivate.

We're not taking away the ability to rekey IKE SAs. In rekey, you get to choose new algorithms.