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

[Mark Baugher <mbaugher@cisco.com>]

Annalies,

At 06:09 PM 7/2/2002 +0200, annelies.van_moffaert@alcatel.be wrote:
>Mark and Steve,
>
>I am not sure I completely understand your arguments. I would think that
>there is a difference between saying that
>1. IPsec can only be used to protect SSM or single-source multicast groups
>and
>2. When using IPsec to protect multicast traffic one should use a seperate
>SA per sender.
>
>In the second case there can be more than 1 sender allowed to send to the
>same group. Both legitimate senders and receivers should then e.g.
>authenticate to a common key server and the key server could create for
>each sender a seperate SA. Additionally the key server would push the SAs
>to the group of receivers.

I think we need to introduce the constraint that one and only
one controller or key server will establish SAs for a
given multicast address for all multicast applications,
or we would need to constrain multicast SAs to apply
to SSM only.  The latter seems to be a more robust
approach to me.  Sorry if I have not been clear about this.

So, although the correct answer to your question is #2,
#1 ensures that we won't have an SPI collision in the
absence of a single controller per multicast group.  It's
true that a collision of SPIs is unlikely _if they are
random_, but the SPI is not required to be random.  Besides
that, I think we want to avoid even unlikely failures.

>A concrete example could be hosts that all send IGMP messages to the group
>address to which all IGMP capable routers listen  or PIM routers that all
>send PIM messages to the PIM group address. It could also be a multicast
>data service with more than one legitimate source (all sources should then
>probably be under the control of a single key server).
>
>Do you have scenario 1 in mind or scenario 2 or again something else?
>
>
>A second question I have relates to the statement that "the receiver SHALL
>check the source address to ensure that it is from the authorized sender".
>Isn't this a weak check given that a source address can be spoofed by a
>receiver who wants to impersonate the sender?

Yes, but this is always true since we use an HMAC for message
authentication in IPsec rather than a digital signature.  We
must assume that group members are trusted not to impersonate
one another.  Otherwise IPsec message authentication is not
secure.  The sender check by the receiver protects the receiver
from cases where some member is not impersonating an
authorized sender, e.g. in a faulty implementation.

Mark


>Mark explained correctly my concern related to colliding SPI values when
>independent group controllers manage SAs for the same destination address.
>Thanks! ;-) I think this problem could be solved by adding the source
>address to the triplet (SPI, protocol, dest IP addr).
>
>Kind regards, Lies.
>
>
>
>
>
>
>
>Mark Baugher <mbaugher@cisco.com>@securemulticast.org on 02/07/2002
>17:30:35
>
>Sent by:  msec-admin@securemulticast.org
>
>
>To:   Stephen Kent <kent@bbn.com>
>cc:   ipsec@lists.tislabs.com, msec@securemulticast.org
>Subject:  [MSEC] Re: new version of ESP ID
>
>
>Steve,
>
>At 05:07 PM 7/1/2002 -0400, Stephen Kent wrote:
><text deleted>
>
>
> >>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.
> >
> >  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
>
>
>_______________________________________________
>msec mailing list
>msec@securemulticast.org
>http://www.pairlist.net/mailman/listinfo/msec