Subject: [MSEC] Re: new version of ESP ID

From: Mark Baugher <[email-masked]>
Date: Mon, 01 Jul 2002 09:42:34 -0700

Karen, Steve,
At 06:55 PM 6/28/2002 -0400, Karen Seo wrote:
><text deleted>
>
>A question was posed to the working group (6/17) as to whether to change 
>the SA demuxing values to allow use of the Source IP address for 
>source-specific multicast protocols. There has been no feedback so far so 
>no changes were made.

I missed the 6/17 note.  I have a few comments on use of the source IP 
address for source-specific multicast.

First, section 2.2 deprecates sharing an SA among multiple senders to a 
multicast group and in effect mandates single-sender multicast for ESP 
groups.  The same is true for AH.  I'm aware of only one protocol, the VRRP 
specification, that is affected by this change.  VRRP uses AH or ESP but 
allows multi-source multicast groups.  We should notify the VRRP WG of this 
potential change.

Second, I think there is an inconsistency between 2.2 and 3.4.2 in that 2.2 
disallows sharing of an SA among multiple senders and 3.4.2 states that 
anti-replay SHOULD NOT be used in a multi-sender environment.  Doesn't the 
first restriction obviate the need for the second?

Finally, If we are going to restrict a multicast SA to single-source 
multicast groups, then I don't understand how we can avoid identifying 
associating that sender with the SA.  If a member of the single-source 
multicast group who is not the authorized sender begins sending to that 
group, there is no way to identify this problem, which will likely break 
the anti-replay mechanism.

regards, Mark

>Thank you,
>Karen

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Tue, 02 Jul 2002 08:30:35 -0700

Steve,

At 05:07 PM 7/1/2002 -0400, Stephen Kent wrote:
<text deleted>

>  The SA for a single-sender, multicast SA should specify the address of 
> the one, authorized sender and that would be checked by each receiver.

I'm okay with this.  It limits us strictly to single-sender multicast 
groups.  Given the complexities of multicast security, that's probably the 
best approach at least for the near term.  Shouldn't we document this 
constraint in the ESP (and AH) I-Ds?  That is, the receiver SHALL check the 
source address of a received packet to ensure that it is from the 
authorized sender for the particular SA?

>This is separate from the fact that the IP source address is not (and 
>never has been) used in selecting the SA for inbound traffic, i.e., it is 
>the destination address and the SPI that are used for that demuxing.

Yes, and this is consistent with what RFC 2401 says:  "The concept is 
applicable in the point-to-multipoint case as well."  We disallow having 
multiple senders share an SA.  Annalies point was (if I understand her 
correctly) that we cannot have multiple SAs for a particular multicast 
destination address because the SPIs might collide.  The SPIs might collide 
if different group controllers assign them independently.  Do you agree?

Mark

>Steve

---

From: Andrea Colegrove <[email-masked]>
Date: Tue, 02 Jul 2002 12:19:19 -0400

Mark and Steve,
    I agree that if only one sender is authorized than that sender should be
indicated in the SA as policy that must be adhered to.  This should not cause
one to disallow multiple senders sharing an SA.  The policy rule must be
flexible enough to allow an entity, a list, a rule, a wildcard, etc. to cover
all multicast scenarios.  It would be a shame to break future advanced
multicast uses.
    I agree with Annalies that anti-replay is still a problem.  We all
acknowledged that several years ago in smug.  We also discussed the SPI
collision problem at that time.  The probability that two sender-specific SAs
would be assigned the same SPI in the same destination (multicast) address
space is rather slim.  Do you anticipate using different group keys for each of
those SAs?

--- Andrea

---

From: Andrea Colegrove <[email-masked]>
Date: Tue, 02 Jul 2002 13:11:20 -0400

Stephen Kent wrote:

>
> Andrea,
>
> The current facilities in 2401 do not mandate support for lists of IP
> addresses for an SA, although that is a feature we plan to put in
> 2401bis. So, relative to current standards, there is no way to
> associate a list of authorized senders for a single SA.  You can
> specify a single address, a range of addresses, or allow any address,
> but not an enumerated list. (This was a feature in the ID that was
> deleted before we went to RFC, to match what IKE could negotiate.)
>

Could the opaque value be used and decoded only by multicast aware versions?  Or
is general name flexible enough?

Are there plans to expand the SPD facility to support more generic policy, as
well?  It appears that while RFC 2401 designates IKE as the default security
management mechanism, allowing others, as a "MAY", multiple management mechanisms
may be needed for different uses. (e.g., IKEv2 for gateways, JFK for small mobile
devices, gdoi for single source multicast groups, KMI for government, etc.)  These
mechanisms may also have different policy needs.  For example, GDOI might want to
check that it has received out-of-band, a group policy token that is valid before
proceeding to key distribution.  It would probably be important to show that the
correct management mechanism is selected according to policy and that the security
operating assumptions for each is met.

>
> Every SA nominally has a different set of keys, and that's what IKE,
> IKE v2, and JFK provide. However one could imagine a key management
> protocol which created multiple SAs with a common key, e.g., for the
> purposes you cite here. However,
> I would not expect Ipsec to treat such SAs specially, e.g., to know
> that the keys are common and thus to svae state space as a result.
>
> In any case, we have always required that SPI assignment be
> coordinated for all parties using the same multicast address. This is
> essential for the reasons I cited in my recent, previous message.
> Thus I do not understand the notion of SPI collisions relative to a
> single multicast address, irrespective of whether there is one sender
> or multiple senders.
>
> Steve

My thought was that if a lack of coordination did exist and if a collision did
occur (two BIG ifs), then separate keys would cause decryption errors.  A
management channel could then rekey, including the SPI.

--- Andrea

---

From: Andrea Colegrove <[email-masked]>
Date: Tue, 02 Jul 2002 14:48:06 -0400

Steve,

Stephen Kent wrote:

> IKEv2 and JFK are competing replacements for IKE v1. I don't see the
> split you allude to above, i.e., I expect the WG to select one
> replacement, because the choice affects not only the local device,
> but also any device with which it communicates. So a I can't have one
> protocol for security gateways and another for small, mobile devices,
> if these devices ever want to communicate with a computer behind a
> security gateway, for example.
>
> Nonetheless, your question is relevant. There is a distinction
> between what 2401 will mandate in terms of SPD capabilities, and what
> any key/SA management protocol provides. I think it is reasonable for
> IPsec to be able to use more than one key/SA management protocol, but
> the SPD should be uniform and the protocols should support what the
> SPD allows users to express. The concern I have re support of
> multicast is any imposition of new requirements on the "fast path"
> processing required of all IPsec implementations. As more of these
> move into hardware, to accommodate higher speeds, we cannot easily
> make changes on things such as SA demuxing without severely affecting
> this hardware.

Re:  IKEv2 and JFK -- a couple of recent postings have mentioned the use of both.
But, yes, I agree it would be an interoperability nightmare.

Nevertheless, even the different domains of pairwise dynamic keying, single-source
multicast, multi-sender multicast, pre-placed (if it survives) update management,
and centralized keying, all have slightly different needs for the SPD.  I would
suspect that unless the policy issues were pushed up to the application layer, that
the SPD will need to have a flexible format for any implementation.  Indeed, I
would suspect that for management purposes, it would even make sense in the future
to take on standardized approaches for remote management of SPDs.  (2401-bis).

This complexity probably does fly in the face of the simplicity needed for high
speed applications.

--- Andrea