Subject: [MSEC] shared SA w/ automatic keying

From: Michael Noisternig <[email-masked]>
Date: Mon, 03 Nov 2008 15:59:48 +0100

Hi all,

the IPsec SA/SP management framework supports SAs shared among multiple 
devices (for unicast communication). This is probably frequently done 
when keys are set up manually. Because of this sharing, IKE cannot be 
used for automatic keying. However, also GKM protocols cannot be used 
since the SPI (selected by the GCKS) may conflict with current SPIs. 
(SAs for unicast packets are looked up using the SPI solely. A 
distinguisher like a multicast dst. address as in msec-ipsec-extensions 
is not at hand.)

It seems that SA sharing is not compatible with automatic keying (or at 
least, automatic SPI selection); however, I could not find any statement 
on this in the ipsec/msec documents.

Of course, a question is why you would want to do SA sharing. (a) One 
point is connection state overhead. (b) Another may be unidirectional 
links. Consider this (contrived) scenario:

        A (GCKS)
       ^ ^
      /   \
     v     v
     B---->C

A can communicate bidirectionally with B and C, but C cannot send data 
to B. Therefore, B and C cannot negotiate keys; however, C may receive 
shared keys from A (which could be the GCKS in addition to a normal 
group member).

Not sure if (b) would happen in real world, but (a) may.

What is your opinion on this issue?

Thanks for any answers,
Michael
_______________________________________________
MSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/msec

---

From: [email-masked]
Date: Mon, 03 Nov 2008 22:14:17 -0500

Hi Michael, 

I am not sure that I understand your question. I think you are describing an 
application wherein one unicast IPsec SA is shared by a set of three or more 
endpoints. Although this proposed SA resembles a group IPsec SA, in your 
scenario the SA is identified only by its SPI, and not using the 2-tuple 
{destination multicast IP address, SPI}. The SA identifier topic is 
discussed in section 4.1 of RFC4301. It explains how SPI assignments of a 
GKM are kept independent of the SPI assigned by an IKE subsystem. 

Perhaps your question could be rephrased to be: how could IKE and a GKM 
coordinate their SPI assignments such that IKE does not assign a unicast SPI 
that has been allocated by the GKM to a group IPsec SA? or assure that an 
SPI allocated by the IKE is not used by the GKM? 

There is no IPsec standardized method to achieve this constraint on unicast 
SPI assignment. Coordination of IKE and the GKM would require the 
distributed management of the SPI identifier space across all key management 
systems (both IKE and GKM) participating in a security domain. 

hth,
    George 

Michael Noisternig writes: 

> devices (for unicast communication). This is probably frequently done when 
> keys are set up manually. Because of this sharing, IKE cannot be used for 
> automatic keying. However, also GKM protocols cannot be used since the SPI 
> (selected by the GCKS) may conflict with current SPIs. (SAs for unicast 
> packets are looked up using the SPI solely. A distinguisher like a 
> multicast dst. address as in msec-ipsec-extensions is not at hand.) 
> 
> A can communicate bidirectionally with B and C, but C cannot send data to 
> B. Therefore, B and C cannot negotiate keys; however, C may receive shared 
> keys from A (which could be the GCKS in addition to a normal group 
> member). 
>

---

From: [email-masked]
Date: Mon, 03 Nov 2008 22:14:17 -0500

Hi Michael, 

hth,
    George

---

From: Michael Noisternig <[email-masked]>
Date: Tue, 04 Nov 2008 15:53:21 +0100

Hi George,

[email-masked] schrieb:
> Hi Michael,
> I am not sure that I understand your question. I think you are 
> describing an application wherein one unicast IPsec SA is shared by a 
> set of three or more endpoints. Although this proposed SA resembles a 

Right. A unicast SA shared among several endpoints.

> group IPsec SA, in your scenario the SA is identified only by its SPI, 
> and not using the 2-tuple {destination multicast IP address, SPI}. The 

Sure, because there is no multicast address used; communication is 
unicast, just the SA (the keys) are shared/coordinated among all the 
endpoints.

> SA identifier topic is discussed in section 4.1 of RFC4301. It explains 
> how SPI assignments of a GKM are kept independent of the SPI assigned by 
> an IKE subsystem.

But this only considers multicast SAs, i.e. packets with a multicast 
address as destination.

> coordinate their SPI assignments such that IKE does not assign a unicast 
> SPI that has been allocated by the GKM to a group IPsec SA? or assure 
> that an SPI allocated by the IKE is not used by the GKM?

Or: How could IKE and a GKM coordinate their SPI assignments such that 
GKM does not assign a SPI for a group (shared unicast) SA that has been 
allocated by the IKE to a unicast SA? I could rephrase my question like 
that, yes.

> There is no IPsec standardized method to achieve this constraint on 
> unicast SPI assignment. Coordination of IKE and the GKM would require 
> the distributed management of the SPI identifier space across all key 
> management systems (both IKE and GKM) participating in a security domain.

That is what I was thinking, but I was wondering if this issue was 
touched in any IETF documents. Apparently not.

>    George

Thanks,
Michael

>> the IPsec SA/SP management framework supports SAs shared among 
>> multiple devices (for unicast communication). This is probably 
>> frequently done when keys are set up manually. Because of this 
>> sharing, IKE cannot be used for automatic keying. However, also GKM 
>> protocols cannot be used since the SPI (selected by the GCKS) may 
>> conflict with current SPIs. (SAs for unicast packets are looked up 
>> using the SPI solely. A distinguisher like a multicast dst. address as 
>> in msec-ipsec-extensions is not at hand.)
>> It seems that SA sharing is not compatible with automatic keying (or 
>> at least, automatic SPI selection); however, I could not find any 
>> statement on this in the ipsec/msec documents.

---

From: Michael Noisternig <[email-masked]>
Date: Tue, 04 Nov 2008 15:53:21 +0100

Hi George,

Thanks,
Michael

---

From: Paul Lambert <[email-masked]>
Date: Tue, 4 Nov 2008 11:22:27 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Subject: Re: [MSEC] shared SA w/ automatic keying
>
> Hi Michael,
>
> SPI

This would be easy if one bit were set aside (like the high order) in the SPI that would be reserved only for multicast SPI.

Looking at RFC 4303 ... this is not there :-(  but it could be done as a implementation guideline.

The notion in RFC 4301 that reuse is possible and then mandating that you are able to demultiplex the overlap is a flawed approach and should be depreciated.  The use of an IP address with the SPI should really never be required.

Paul

> unicast
> when
> to

---

From: Paul Lambert <[email-masked]>
Date: Tue, 4 Nov 2008 11:22:27 -0800

Paul