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

From: Keith Welter <[email-masked]>
Date: Tue, 28 Sep 2010 13:03:21 -0700

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.

---

From: Keith Welter <[email-masked]>
Date: Tue, 28 Sep 2010 13:09:43 -0700

After writing this draft (
http://www.ietf.org/id/draft-welter-ipsecme-ikev2-reauth-00.txt), I 
re-discovered an old thread about the same issue.  The post that started 
the thread was from Martin Willi on Tue, 16 Sep 2008 with subject "[IPsec] 
Reauthentication extension for IKEv2" (
http://www.ietf.org/mail-archive/web/ipsec/current/msg03106.html).  The 
discussion in the thread wandered quite a bit, so much so that it was 
renamed "Identifying encrypted traffic" midstream.  Following all the 
posts on the thread, it appears to me that Martin's original question of 
whether or not there should be a reauthentication extension for IKEv2 was 
forgotten and never answered (certainly rough consensus was not reached). 
I named my draft to match the subject of Martin's original post and I hope 
to use the draft to re-invigorate the discussion on this topic.  I would 
appreciate comments from the subscribers of this list as to whether or not 
a reauthentication extension for IKEv2 is worth doing and of course I 
would also appreciate comments on the draft itself.

Thanks,

Keith Welter
IBM z/OS Communications Server Developer

> 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.
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 28 Sep 2010 23:40:46 +0200

Hi Keith,

thanks for exploring this important issue. Here are a few preliminary 
comments:

- The intro is short on motivation: what *exactly* happens today, and 
why it is a problem that needs to be solved: bandwidth? CPU? Memory? 
Complexity?

- There's a long treatment of simultaneous reauth. I'm not saying it is 
unimportant, but it's certainly more important to spell out *exactly 
when* the new SA inherits the old one's baggage (immediately when the 
IKE_AUTH completes successfully, I guess); and very important to say 
what happens in error cases, for example if authentication fails.

Thanks,
	Yaron

On 09/28/2010 10:09 PM, Keith Welter wrote:
>
> After writing this draft
> (http://www.ietf.org/id/draft-welter-ipsecme-ikev2-reauth-00.txt), I
> the thread was from Martin Willi on Tue, 16 Sep 2008 with subject
> "[IPsec] Reauthentication extension for IKEv2"
> (http://www.ietf.org/mail-archive/web/ipsec/current/msg03106.html). The
> whether or not there should be a reauthentication extension for IKEv2
> was forgotten and never answered (certainly rough consensus was not
> reached). I named my draft to match the subject of Martin's original
> post and I hope to use the draft to re-invigorate the discussion on this
> topic. I would appreciate comments from the subscribers of this list as
> to whether or not a reauthentication extension for IKEv2 is worth doing
> and of course I would also appreciate comments on the draft itself.
>
> Thanks,
>
> Keith Welter

---

From: Keith Welter <[email-masked]>
Date: Wed, 29 Sep 2010 09:09:19 -0700

Hi Yaron,

Thanks for your preliminary comments.  In-line responses below.

Keith Welter

Yaron Sheffer <[email-masked]> wrote on 09/28/2010 02:40:46 PM:
> - The intro is short on motivation: what *exactly* happens today, 
> and why it is a problem that needs to be solved: bandwidth? CPU? Memory? 

> Complexity?
Fair point.  After discovering Martin's post I should have borrowed 
elements from it because he did a good job of reiterating how 
reauthentication works in RFC 5996 and listing problems, including an 
INTERNAL_ADDRESS assigment problem I wasn't aware of because my platform 
doesn't do INTERNAL_ADDRESS assignment.  I would add exchange collisions 
to Martin's list.  On my platform, the redundant SAs that result from 
simultaneous reauthentication was noticed by testers and reported as a 
possible problem which was actually my original motivation for writing the 
draft.  I will forego a re-write of the intro at this point and construct 
an outline of points that the intro ought to cover for discussion:
1. reiterate how reauthentication works in RFC 5996 (quote third paragraph 
of section 2.8.3)
2. include wire-flow diagram of RFC 5996 style reauthentication?
3. list problems:
   a. Excessive bandwidth is consumed because each Child SA of the IKE SA 
being reauthenticated must be renegotiated.
   b. The responder in the reauthentication operation cannot detect that 
reauthentication is occuring.  This may cause problems such as preventing 
an IRAS from assigning the same INTERNAL_ADDRESS to an IRAC.
   c. The reauthentication operation is susceptible to simultaneous 
reauthentication which usually results in redundant SAs which wastes 
memory and CPU and is confusing to operators.
   d. Other exchange collisions may occur such as one side creating a new 
Child SA at the same time that the other side is trying to reauthenticate 
the IKE SA.  Interoperability when such collisions occur may suffer from 
under-specification in RFC 5996 and the inability of the responder to 
detect reauthentication.

> what happens in error cases, for example if authentication fails.
When I put the draft together I used existing text from RFC 5996 with as 
little modification as possible.  My motivation was two-fold.  First, I 
wanted the text to look familiar.  Second, I didn't want to expend an 
excessive amount of effort writing original text in case the working group 
was uninterested in the topic.  As such, the lengthy parts and skimpy 
parts of the draft reflect lengthy and skimpy treatments of the 
corresponding topics in RFC 5996.  For example, the lengthy treatment of 
simultaneous reauth borrows paragraphs from RFC 5996 section 2.8.1 and 
2.8.2 nearly verbatim with a few substitutions such as replacing "rekey" 
with "reauthenticate" and "rekeying" with "reauthenticating".  The 
wire-flow diagrams are also closely modeled on existing ones from RFC 
5996.

I would actually like to solicit help for describing exactly when the new 
IKE SA inherits the old one's Child SAs since it ought to mirror when that 
happens when rekeying the IKE SA.  However, the latter movement is barely 
described in RFC 5996.  The only text I found in RFC 5996 describing the 
movement of the Child SAs when rekeying the IKE SA is in section 2.18 
"Rekeying":
   To rekey an IKE SA, establish a new equivalent IKE SA (see
   Section 2.18 below) with the peer to whom the old IKE SA is shared
   using a CREATE_CHILD_SA within the existing IKE SA.  An IKE SA so
   created inherits all of the original IKE SA's Child SAs, and the new
   IKE SA is used for all control messages needed to maintain those
   Child SAs.  After the new equivalent IKE SA is created, the initiator
   deletes the old IKE SA, and the Delete payload to delete itself MUST
   be the last request sent over the old IKE SA.

I copied this same paragraph into section 2 "IKE SA Reauthentication With 
N(REAUTH_SA)" of my draft with a few substitutions:
   The new IKE SA created as a result of the reauthentication inherits
   all of the original IKE SA's Child SAs, and the new IKE SA is used
   for all control messages needed to maintain those Child SAs.  After
   the new IKE SA is created, the initiator deletes the old IKE SA, and
   the Delete payload to delete itself MUST be the last request sent
   over the old IKE SA.

I would welcome suggestions for improving this.

Your point about the need to discuss what happens when authentication 
fails is well taken.  I imagine I would point to RFC 5996 section 2.21.2. 
"Error Handling in IKE_AUTH" and say that all of that applies to 
reauthentication and that movement of the child SAs does not occur if the 
reauthentication fails.  I think that perhaps it would be too strong to 
say that the old IKE SA should be closed if the reauthentication fails but 
I would welcome other opinions.  Are there other error cases that you are 
concerned about?

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 29 Sep 2010 22:58:10 +0200

Hi Keith,

I am responding only to your last point, on error cases.

If the new SA setup fails, the old IKE SA MUST NOT be affected in any 
way. Otherwise (if we recommend to drop the old SA), we would have an 
unauthenticated attacker DOS'ing an entire IKE SA and its Child SAs.

Yes, I think auth failure is the main error case we should be concerned 
with.

Thanks,
	Yaron

On 09/29/2010 06:09 PM, Keith Welter wrote:
> possible problem which was actually my original motivation for writing
> the draft. I will forego a re-write of the intro at this point and
> construct an outline of points that the intro ought to cover for
> discussion:
> 1. reiterate how reauthentication works in RFC 5996 (quote third
> paragraph of section 2.8.3)
> Child SA at the same time that the other side is trying to
> reauthenticate the IKE SA. Interoperability when such collisions occur
> may suffer from under-specification in RFC 5996 and the inability of the
> responder to detect reauthentication.
>
>  >
> excessive amount of effort writing original text in case the working
> group was uninterested in the topic. As such, the lengthy parts and
> skimpy parts of the draft reflect lengthy and skimpy treatments of the
> wire-flow diagrams are also closely modeled on existing ones from RFC 5996.
>
> I would actually like to solicit help for describing exactly when the
> new IKE SA inherits the old one's Child SAs since it ought to mirror
> when that happens when rekeying the IKE SA. However, the latter movement
> is barely described in RFC 5996. The only text I found in RFC 5996
> describing the movement of the Child SAs when rekeying the IKE SA is in
> section 2.18 "Rekeying":
> I copied this same paragraph into section 2 "IKE SA Reauthentication
> With N(REAUTH_SA)" of my draft with a few substitutions:
> reauthentication and that movement of the child SAs does not occur if
> the reauthentication fails. I think that perhaps it would be too strong
> to say that the old IKE SA should be closed if the reauthentication
> fails but I would welcome other opinions. Are there other error cases
> that you are concerned about?
>
>  >
>  > Thanks,
>  > Yaron
>  >

---

From: Keith Welter <[email-masked]>
Date: Wed, 29 Sep 2010 14:15:11 -0700

> unauthenticated attacker DOS'ing an entire IKE SA and its Child SAs.
Good point.  Thanks.

> Yes, I think auth failure is the main error case we should be concerned 
Good.  I tried to be thorough about covering possible errors involving the 
new N(REAUTH_SA) but I forgot to deal with an authentication failure 
during re-authentication.  That is certainly important to cover!

5996.
> >  > > post and I hope to use the draft to re-invigorate the discussion 
on
> > this

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 30 Sep 2010 12:13:40 +0300

> 1. reiterate how reauthentication works in RFC 5996 (quote third paragraph 

I have not yet read your draft, but how dows it relate to the RFC
4478? Isn't that already defining things that would help a lot, for
example I think that can be used to force one side to do
reauthentication (which might be required anyways because of eap etc)
and that solves exchange collision problem.

Note, that INTERNAL_ADDRESS allocation and EAP both require that the
same party starts the reauthentication. 
-- 
[email-masked]

---

From: Keith Welter <[email-masked]>
Date: Thu, 30 Sep 2010 08:04:19 -0700

> > 1. reiterate how reauthentication works in RFC 5996 (quote third 
paragraph 
> same party starts the reauthentication. 

draft-welter-ipsecme-ikev2-reauth-00 and RFC 4478 are complimentary.  The 
principal problem solved by the former is that it allows the Child SAs of 
the reauthenticated IKE SA to be moved to the new IKE SA rather than being 
re-negotiated under the new IKE SA.  There is some overlap in the sense 
that simultaneous reauthentication would be eliminated by RFC 4478 but 
other exchange collisions such as one side creating or rekeying a child SA 
while the other is reauthenticating the IKE SA could still occur.