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

From: [email-masked]
Date: Tue, 2 Jul 2002 18:09:11 +0200

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.

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?

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 <[email-masked]>@securemulticast.org on 02/07/2002
17:30:35

Sent by:  [email-masked]

To:   Stephen Kent <[email-masked]>
cc:   [email-masked], [email-masked]
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
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

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

---

From: Mark Baugher <[email-masked]>
Date: Tue, 02 Jul 2002 11:48:52 -0700

Annalies,

>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.

>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

---

From: Haitham Cruickshank <[email-masked]>
Date: Mon, 29 Jul 2002 11:48:36 +0100

Hi Everybody,

I have attended the ipsec meeting at the ieft 54 meeting and Steve Kent has
presented some interworking problems with IP multicast.  Is it possible to
start a discussion on how to solve such problems.

I can see two major multicast problems:

1. Scalability:  For very large groups (thousands of members) or very dynamic
multicast groups (frequent join and leaves), having a single group controller
might not scale well specially for re-keying problem (changing keys when
members join or leave).  If this problems is true, then we need to have a
distributed group controller/controllers and this brings new problems which has
been discussed in some previous emails.

2. Anti-relay procedures for multiple senders:  Steve has pointed (quite
rightly) the problem that anti-replay procedures (receivers keeping track of
sequence numbers and sequence number windows) works OK for unicast or single
source multicast.  The potential problem is having unbounded number of senders,
where the ipsec receivers (especially hardware implementations) have to track
of sequence numbers and sequence number windows for each individual senders.
In my personal opinion, the anti-replay should be switched off for multi
senders.  Of course, this will weaken the security system against DOS attacks.

Can ipsec and msec people express opinion on how to solve these issues.
Thanks.

Haitham

Stephen Kent wrote:

> At 6:09 PM +0200 7/2/02, [email-masked] wrote:
> >Mark and Steve,
> >
> The second case would be consistent with the IPsec architecture. The
> common key server needs to assign the SPIs uniquely for the multicast
> group as well as provide keys to the group members. In this model,
> each SA has just one authorized sender and so anti-replay can be
> employed, and each receiver can use the SPD to constrain the source
> address appropriately. But, the granularity of the source
> authentication is still just the group, since each receiver also
> could send traffic claiming to be from the authorized sender.
>
> It is effective for unicast SAs, but it is a less effective control
> for multicast SAs, in so far as any multicast group member has the
> requisite key material to spoof. However I do not envision changing
> this general requirement to special case multicast SAs. As noted
> earlier, if you don't feel that the check is really useful in the
> multicast context, you can set the source address to be * for these
> SAs.
>
> What problem? We still require coordination for SPI management on a
> per multicast group address basis, so if you want to create multiple
> SAs for the multicast group, one per sender, why not use SPIs for
> this purpose. I am hesitant, to say the least, to impose a new,
> additional burden on all IPsec implementations to use sources
> addresses for demuxing, when the same effect can be achieved using
> the SPI.
>
> Steve

--
Dr. Haitham S. Cruickshank

Senior Research Fellow in Communications
Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey
Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: [email-masked]
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/

---

From: Hugh Harney <[email-masked]>
Date: Mon, 29 Jul 2002 09:51:56 -0400

Haitham,

I tend to agree with Steve. Large groups or dynamic groups will need 
distributed key and security management. I'd point out that GSAKMP (heavy 
and Lite) allow for distribution of the key and security management functions.

One of the key points to setting up distributed management for large groups 
is ensuring that the system is secure. GSAKMP does this by incorporating a 
policy token in the key exchanges.

On your second point anti-replay. I think the decision to switch off that 
feature is dependant on the system your protecting. In many cases, I'd do 
as you suggested, turn off the anti-replay. However, it depends on the 
threats to the system.

Hugh

________________________________________________________
Hugh Harney		[email-masked]		410-381-9400 x203
________________________________________________________