Subject: Re: [IPsec] Proposed work item: Childless IKE SA

From: "Alper Yegin" <[email-masked]>
Date: Tue, 1 Dec 2009 14:29:19 +0200

One of the (or main?) motivations of this proposal is to turn IKEv2 into
"EAP-based network access authentication protocol".  RFC 5191 is designed
for that purpose, and I'm not sure if we need to twist a protocol for the
same purpose.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yaron Sheffer
> Sent: Sunday, November 29, 2009 7:21 PM
> To: [email-masked]
> Subject: [IPsec] Proposed work item: Childless IKE SA
> 
> This draft proposes an IKEv2 extension to allow the setup of an IKE SA
> with no Child SA, a situation which is currently disallowed by the
> protocol.
> 
> Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme-
> childless-01.txt.
> 
> Please reply to the list:
> 
> - If this proposal is accepted as a WG work item, are you committing to
> review multiple versions of the draft?
> - Are you willing to contribute text to the draft?
> - Would you like to co-author it?
> 
> Please also reply to the list if:
> 
> - You believe this is NOT a reasonable activity for the WG to spend
> time on.
> 
> If this is the case, please explain your position. Do not explore the
> fine technical details (which will change anyway, once the WG gets hold
> of the draft); instead explain why this is uninteresting for the WG or
> for the industry at large. Also, please mark the title clearly (e.g.
> "DES40-export in IPsec - NO!").
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Dec 2009 14:42:44 +0200

There were several motivations listed for childless IKE SAs.
 - remote access, where you create an IKE SA when the user wants to connect, and only create child SAs in response to traffic
 - authentication only over a physically secure network (not necessarily EAP, but I think this is the use case you referred to)
 - Location awareness (as in the SecureBeacon draft)
 - Some "weird" uses such as liveness checks without IPsec, NAT detection, etc.

On Dec 1, 2009, at 2:29 PM, Alper Yegin wrote:

> Scanned by Check Point Total Security Gateway.

---

From: Hui Deng <[email-masked]>
Date: Tue, 1 Dec 2009 21:27:48 +0800

During the last 3GPP SA3 meeting, such requirement about HNB has also
been approved as well.

thanks

-Hui

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 2 Dec 2009 15:49:25 +0200

Hi Hui,

Are all 4 motivations below part of 3gpp discussion?

Alper

> Of Hui Deng
> Sent: Tuesday, December 01, 2009 3:28 PM
> To: Yoav Nir
> Cc: [email-masked]; Alper Yegin
> Subject: Re: [IPsec] Proposed work item: Childless IKE SA
> 
> >  - remote access, where you create an IKE SA when the user wants to
> connect, and only create child SAs in response to traffic
> >  - authentication only over a physically secure network (not
> necessarily EAP, but I think this is the use case you referred to)

---

From: Matthew Cini Sarreo <[email-masked]>
Date: Wed, 2 Dec 2009 16:33:08 +0100

Hello Yoav,

This seems to be very interesting, I like it due to the first motivation you
mentioned. I would be ready to review if this is accepted as a WG item.

If some of the motivations are already tackled, it would be wise to check if
making additions to IKEv2 tackling those motivations would be worth while.

Regards,
Matt

2009/12/2 Alper Yegin <[email-masked]>

---

From: Hui Deng <[email-masked]>
Date: Thu, 3 Dec 2009 22:47:03 +0800

Hi, Alper

Not all of them.

-Hui

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 3 Dec 2009 16:53:55 +0200

Hi Hui,

I think it'd also be very useful if you indicate which ones are.

Thanks.

Alper

> Sent: Thursday, December 03, 2009 4:47 PM
> To: Alper Yegin
> Cc: [email-masked]; Yoav Nir
> >> >> One of the (or main?) motivations of this proposal is to turn
> IKEv2
> >> into
> >> >>> This draft proposes an IKEv2 extension to allow the setup of an
> IKE
> >> SA
> >> >>> If this is the case, please explain your position. Do not
> explore
> >> the
> >> >>> fine technical details (which will change anyway, once the WG
> gets
> >> hold
> >> >>> of the draft); instead explain why this is uninteresting for the
> WG
> >> or

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Dec 2009 22:18:30 -0500

Yaron Sheffer wrote:
> This draft proposes an IKEv2 extension to allow the setup of an IKE SA with no Child SA, a situation which is currently disallowed by the protocol.
> 
> Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme-childless-01.txt.
>  

I believe that this is a useful extension to IKEv2.
I am willing to review drafts, and I might co-author.

In particular, I would like to be able to negotiate IKEv2, specifically
so that I can send a DELETE.
Alternatively, I would like to negotiate a non-SA for some traffic
selector.  I mention this, because I'm not sure that the reasons for
CHILDLESS are the same for different people, and therefore, we may be
trying to use a hammer on a screw.

---

From: "Murthy N Srinivas-B22237" <[email-masked]>
Date: Tue, 8 Dec 2009 23:12:36 +0530

Hi

Interested in coauthoring this draft.

Thanks
-ns murthy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Michael Richardson
Sent: Friday, December 04, 2009 8:49 AM
To: [email-masked]
Subject: Re: [IPsec] Proposed work item: Childless IKE SA

> Proposed starting point:
http://tools.ietf.org/id/draft-nir-ipsecme-childless-01.txt.

---

From: Hui Deng <[email-masked]>
Date: Wed, 9 Dec 2009 23:42:06 +0800

would like to co-author, thanks

-Hui

2009/11/30 Yaron Sheffer <[email-masked]>:
> - If this proposal is accepted as a WG work item, are you committing to review multiple versions of the draft?
> - You believe this is NOT a reasonable activity for the WG to spend time on.
>
> If this is the case, please explain your position. Do not explore the fine technical details (which will change anyway, once the WG gets hold of the draft); instead explain why this is uninteresting for the WG or for the industry at large. Also, please mark the title clearly (e.g. "DES40-export in IPsec - NO!").

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 9 Dec 2009 21:46:14 +0200

Hi Hui,

You named 3GPP as a consumer of this, acknowledged that 3GPP is not behind
all of the requirements, but you didn't respond to my question about which
one of the requirements are coming from 3GPP.

I object to this work, because it intends to create yet another network
access authentication protocol out of IKEv2. As you know, PANA is designed
for that purpose. IETF community needs to understand why PANA does not fit
the need, and why we need to turn IKEv2 into a general-purpose network
access authentication protocol. (IKE needs to get in line with the other
similar proposals, such as hacking up DHCP into access authentication
protocol, and even HTTP. I guess everyone has his/her favorite protocol to
hack.)

Similar questions arise for the other motivations. "Liveness checking", and
"NAT detection".... Turning IKEv2 into a dedicated protocol for these
purposes is likely to grow IKE in many unintended directions.

Alper

> Sent: Wednesday, December 09, 2009 5:42 PM
> To: Yaron Sheffer
> Cc: [email-masked]
> > This draft proposes an IKEv2 extension to allow the setup of an IKE
> SA with no Child SA, a situation which is currently disallowed by the
> protocol.
> >
> > - If this proposal is accepted as a WG work item, are you committing
> to review multiple versions of the draft?

---

From: Hui Deng <[email-masked]>
Date: Thu, 10 Dec 2009 13:29:20 +0800

Hi, Alper

I think previous Yoav's reply already answered you, so confused why
you ask again,
if you want me repeat, I could copy Yoav's reply to you here.
 - authentication only over a physically secure network (not
necessarily EAP, but I think this is the use case you referred to)

I am not convinced why vendor need implement two security mechanism to
one product,
just because the second one need some market to use it.

-Hui

---

From: Yoav Nir <[email-masked]>
Date: Thu, 10 Dec 2009 08:07:02 +0200

Hi Alper.

The "Do phase 1 first, and phase 2 as traffic demands it" motivation is from the remote access VPN domain (though may be useful for others).

The "Do only phase 1, because we don't need encryption and MAC, just peer authentication" motivation is from the 3GPP (though it could be useful for others)

The "Do only phase 1 to discover if we're in or out of the secure network (then do phase 2 if we're out)" motivation is also mostly a remote access VPN thing.

The other motivations were from suggestions by others, and will be hashed out (or taken out of the document) should this become a WG document.

Hope this helps

Yoav

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 10 Dec 2009 10:04:03 +0200

Hi Hui,

> just because the second one need some market to use it.

Unfortunately, protocol classification is more granular than that.
You don't identify one protocol as "security protocol" and make it serve all
security related purposes: access authentication, IPsec SA establishment,
transport-layer security, application-layer security, mobility signaling
security, etc. etc. Obviously, you need several distinct protocols for these
things.

So, saying we have IKEv2, and we'll twist and turn it into some other
protocol for some other purpose may make sense when you are looking at
things from within the box (that implements IKEv2), but it does not make
sense when you are looking from outside the box (like from IETF
perspective).

Your proposal is for turning IKEv2 into an EAP transport for generic network
access authentication. It requires taking some stuff out, twisting some
stuff, and adding stuff. It's technically doable, but "IETF" needs to be
convinced why it needs to reinvent PANA by taking IKEv2 as the baseline. 

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 10 Dec 2009 10:12:54 +0200

Hello Yoav,

I'm particularly concerned about reinventing the wheel aspect with your
second bullet, as I elaborated in response to Hui in my previous email.

As for the other motivations, I'm not sure the savings are worth the effort.
Imho....

Alper 

> The "Do phase 1 first, and phase 2 as traffic demands it" motivation is
> from the remote access VPN domain (though may be useful for others).
>
> The "Do only phase 1, because we don't need encryption and MAC, just
> peer authentication" motivation is from the 3GPP (though it could be
> useful for others)
> 
> The "Do only phase 1 to discover if we're in or out of the secure
> network (then do phase 2 if we're out)" motivation is also mostly a
> remote access VPN thing.
> 
> The other motivations were from suggestions by others, and will be
> hashed out (or taken out of the document) should this become a WG
> document.
> 
> Hope this helps
> 
> Yoav
>

---

From: Hui Deng <[email-masked]>
Date: Fri, 11 Dec 2009 22:43:26 +0800

Hi Alper,

It seems that your argument goes to 3GPP only not this new work item,
then I would suggest that you propose your solution to 3GPP HNB.

Back to your questions, the scenarios is that some user need this IKE/IPsec
or other don't need IPsec for the first, and also could be upgraded to
need IKE/IPsec,

I also found you didn't classify different access authenticaiton protocol.

this is not a granularity issue, how could your proposal to support
this scenario and migration scenarios simultaneously?

thanks

-Hui

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 12 Dec 2009 00:29:45 +0200

Hi Hui,

> then I would suggest that you propose your solution to 3GPP HNB.

We are having this discussion in IETF right now. So, there is no point in
telling us to go elsewhere. If the discussions is here, it is here.

> or other don't need IPsec for the first, and also could be upgraded to

Is this a real scenario? I'd like to understand how a user moves from a
non-IPsec to IPsec.

> I also found you didn't classify different access authenticaiton

Could you please elaborate on what exactly you are asking about? 

> this scenario and migration scenarios simultaneously?

If you can explain to us what migration scenarios you have, we can discuss
them.

Thanks.

Alper

> >> > You named 3GPP as a consumer of this, acknowledged that 3GPP is
> not
> >> behind
> >> > all of the requirements, but you didn't respond to my question
> about
> >> which

---

From: Hui Deng <[email-masked]>
Date: Mon, 14 Dec 2009 23:35:04 +0800

Hi Alper,

> Is this a real scenario? I'd like to understand how a user moves from a
It is not handover case, it is just physical link sometime is securied enough
sometime it is, and some user support this, other are not support this.

> Could you please elaborate on what exactly you are asking about?
I mean normally we won't do two different type authentication
mechanism for the same device.

> If you can explain to us what migration scenarios you have, we can discuss
Secenario above.

thanks

-Hui

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 15 Dec 2009 19:28:03 +0200

Hello Hui,

If the same box needs to be plugged into networks with different security
characteristics, sure you need a stack that can handle all cases. Not sure
how this relates to our discussion about hacking up IKEv2 vs using a proper
protocol.

> mechanism for the same device.

There are different authentication procedures authenticating different
entities for different purposes -- all on the same node. You cannot say I
have one authentication for all purposes....

Use IKEv2 to "authenticate" IKE peers for establishing IPsec SA, use EAP/foo
to "authenticate" subscriber and the access network for network access AAA,
use Mobile IP to "authenticate" MN and HA for mobility binding, etc. etc....

The minute you intend to use one as a substitute of another (or all), you
are entering the hacking domain....

Alper

> From: Hui Deng [mailto:[email-masked]]
> Sent: Monday, December 14, 2009 5:35 PM
> To: Alper Yegin
> Cc: [email-masked]
> >> >> I am not convinced why vendor need implement two security
> mechanism
> >> to
> >> >> one product,
> >> > protocol for some other purpose may make sense when you are
> looking
> >> at
> >> > things from within the box (that implements IKEv2), but it does
> not
> >> make
> >> > Your proposal is for turning IKEv2 into an EAP transport for
> generic
> >> network
> >> > stuff, and adding stuff. It's technically doable, but "IETF" needs
> to
> >> be
> >> >> > access authentication protocol out of IKEv2. As you know, PANA
> is
> >> >> designed
> >> >> > for that purpose. IETF community needs to understand why PANA
> does
> >> >> not fit
> >> >> > access authentication protocol. (IKE needs to get in line with
> the
> >> >> other
> >> >> >> From: [email-masked] [mailto:[email-masked]]
> On
> >> >> Behalf
> >> >> >> Of Hui Deng
> >> >> >> SA with no Child SA, a situation which is currently disallowed
> by
> >> >> the
> >> >> >> protocol.
> >> >> >> >
> >> >> >> > - You believe this is NOT a reasonable activity for the WG
> to
> >> >> spend
> >> >> >> time on.
> >> >> >> >

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Dec 2009 12:37:42 -0600

> As for the other motivations, I'm not sure the savings are worth the effort.

Suppose you want a combination of "peer authentication only" for some
traffic and "peer authentication + ESP/AH" for other kinds of traffic
(think of this as differentiated services).  Then to use PANA for one
and IPsec for the other seems silly.

I don't see why an applicability statement should not suffice to prevent
the scenario that you dislike (which I think is: IKEv2 displacing PANA
where IKEv2 should be considered to not be applicable).  But see below.

The issue to settle here, as I see it, is: are there any uses of
childless IKEv2 SAs that justify the work?

Of the various use case scenarios given in the I-D the first is the most
convincing, though the lack of childless IKEv2 SAs hardly seems
problematic there.  The last use case is very interesting, but very
forward looking.  The next to last use case is specific to an EAP
method, thus not very interesting to this WG (IMO) except as a way to
keep divergence between base spec and the EAP method to a minimum.  The
other use case scenarios seem to encroach on the applicability of PANA.

Just based on that my support is lukewarm.

Quite aside from that, I question the applicability statement that you
seem to be making.  PANA and IKEv2-with-childless-SAs seem roughly
equivalent, with IKEv2 being more general.  Why should we forbid use of
the latter for network access control?  Certainly having two such
protocols is not exactly desirable, but it's not clear to me that PANA
is the protocol that should win.  What's really not desirable is non-
interoperability, and that, I believe, we can achieve by making PANA the
required to implement network access protocol.  I don't see why we
couldn't let IKEv2 have a go at displacing PANA in the marketplace.  If
there is support in the WG for it, so be it.

Nico
--

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 18 Dec 2009 01:49:49 +0200

Hi,

I'm hoping by now it is understood that "childless IKE SA" is just a
technical detail of what is really on the table. The proposal on the table
is "designing a network access authentication protocol based on IKEv2".
That's what this WG and IETF should be discussing.

Having multiple solutions for the very same problem space creates
interoperability problem.  If IETF has defined a protocol for a given
problem, and if some other people come along and ask another solution be
standardized for the very same problem, IETF needs a justification.
Otherwise, we end up working "against" interoperability, not "for".

The only justification I'm hearing is "we don't want to use PANA because it
is not implemented in my stack." This is an extremely poor justification.
One can say it for any new protocol, and choose to hack up whatever he/she
has. How can growing PANA out of IKEv2 be any better than using PANA. 

IKEv2 is defined and used for creating IPsec SAs. Yeah, it needs to perform
peer authentication, but that's for creating securing the IPsec SA creation.
There are many other protocols that authenticate the peers for the sake of
securely performing their own dedicated objectives. E.g., Mobile IP
authenticates MN and HA for securely creating binding caches; RFC 3118
authenticates DHCP client and DHCP server for secure host configuration;
etc. etc. Taking the peer authentication parts of these protocols and use it
for totally different purposes is not right.

> I don't see why we couldn't let IKEv2 have a go at displacing PANA in the
marketplace.

Few folks want to twist IKEv2 into network access authentication protocol
(this proposal).
Few other folks want to twist DHCP into network access authentication
protocol (EAP-over-DHCP proposal).
Few other folks want to twist HTTP into network access authentication
protocol (EAP-over-HTTP proposal).

They all have the exact same (poor) justification: We need EAP-over-Foo
because we already have Foo. 

The above list is what is already being entertained here and there. The list
is very likely to grow.

How can that not be a problem if all were getting standardized (for the sake
of argument, let's forget about the technical brokenness of the last two
proposals). Every one of them think they were saving by implementing "one",
but in fact all are getting implemented eventually. Each access
authentication specific feature needs to be reproduced on each such
protocol. A multi-mode terminal (host) and NAS need to implement all..... 

> What's really not desirable is non-interoperability, and that, I believe,
we can achieve by making PANA the required to implement network access
protocol.

"We" (IETF) do not and cannot make PANA "required to implement" network
access authentication protocol. Other SDOs/platforms make such mandates. So,
I don't think saying "no" to redundant solutions is a bad thing that that
way.

If someone is truly hung up on using IKEv2 purely for network access
authentication, why can't they already do so? So what if it creates an IPsec
SA. Just don't use it.

> and IPsec for the other seems silly.

Is this a real scenario? This is not the scenario Hui brought up. He's
talking about Femto AP connecting to femto access network via WAN; in one
case (a) WAN is already secured (e.g., via physical security) and he does
not need to use IPsec at all; in the other case (b) WAN is open Internet and
ne needs to use IPsec. In both cases, he needs to authenticate the Femto AP
and he wants to use IKEv2 for that. And I say use PANA instead.

So, PANA-based solution becomes this:
For case (a): Use PANA for Femto AP authentication. That's all you need.
For case (b): Use PANA for Femto AP authentication, use IKEv2 for setting up
IPsec SA. 

....

I'm not disputing doability of this proposal. See, an even worse example is
3GPP2 using Mobile IPv4 authentication for L3 network access authentication
between the MS (MN) and PDSN (FA). I guess we are lucky that they didn't
come to IETF for tweaking RFC 4004 for that (they could get good number of
support, if we were going with that indication only). This can also made to
work, but IMHO there is much bigger harm than benefit in this case.

Alper

 

> Of Nicolas Williams
> Sent: Tuesday, December 15, 2009 8:38 PM
> To: Alper Yegin
> Cc: 'Hui Deng'; [email-masked]; 'Yoav Nir'

---

From: Raj Singh <[email-masked]>
Date: Fri, 18 Dec 2009 08:20:04 +0530

Hi Alper,

On Fri, Dec 18, 2009 at 5:19 AM, Alper Yegin <[email-masked]> wrote:

> IKEv2 is defined and used for creating IPsec SAs.

IKE is Internet Key Exchange protocol NOT IPsec Key Exchange protocol.
IKEv2 is not just a mean of exchanging keys but its a full package.
This package provides mutual authentication, keys and readiness to secure
data as needed.
The main motivation for this draft is Remote Access VPN scenario.

Yeah, it needs to perform
> > there is support in the WG for it, so be it.

Thanks,
Raj

---

From: Hui Deng <[email-masked]>
Date: Sat, 19 Dec 2009 00:11:43 +0800

what if the request is during the IKE authenticaiton,
network side need to signal the fermto about whether to support IPsec or not?
if not, will fall back to usual IPsec tunnel.

-Hui

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 21 Dec 2009 11:31:46 +0200

Hi Raj,

> This package provides mutual authentication, keys and readiness to secure data as needed.

Reading from RFC 4306:

IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs).

…

   IKE performs mutual authentication between two parties and
   establishes an IKE security association (SA) that includes shared
   secret information that can be used to efficiently establish SAs for
   Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication
   Header (AH) [RFC4302] and a set of cryptographic algorithms to be
   used by the SAs to protect the traffic that they carry. 

Obviously IKE is designed and used for IPsec. If it weren’t we’d not be discussing a proposal that tried to break that tie.

Alper

 

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Raj Singh
Sent: Friday, December 18, 2009 4:50 AM
To: Alper Yegin
Cc: Hui Deng; ipsec; Yoav Nir; Nicolas Williams
Subject: Re: [IPsec] Proposed work item: Childless IKE SA

Hi Alper,

Hi,

This package provides mutual authentication, keys and readiness to secure data as needed.

marketplace.

....

Alper

Thanks,

Raj

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Dec 2009 14:26:09 -0500

At 8:20 AM +0530 12/18/09, Raj Singh wrote:
>...

Depite the name, IKE really is the IPsec Key Exchange Protocol. It is 
true that the original vision for IKE was much broader, but over time 
we have tailored IKE to support IPsec.

Steve