From msec-admin@securemulticast.org  Mon Nov  4 10:22:40 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17681
	for <msec-archive@lists.ietf.org>; Mon, 4 Nov 2002 10:22:40 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 966C5537F6; Mon,  4 Nov 2002 10:24:36 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id CA8D653580
	for <msec@lists.securemulticast.org>; Mon,  4 Nov 2002 10:22:43 -0500 (EST)
Received: (qmail 98906 invoked by uid 3269); 4 Nov 2002 15:22:43 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 98902 invoked from network); 4 Nov 2002 15:22:43 -0000
Received: from gorilla.mchh.siemens.de (194.138.158.18)
  by klesh.pair.com with SMTP; 4 Nov 2002 15:22:43 -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 QAA19850;
	Mon, 4 Nov 2002 16:22:36 +0100 (MET)
Received: from mchh169e.mch4.siemens.de ([139.21.130.176])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA27042;
	Mon, 4 Nov 2002 16:22:34 +0100 (MET)
Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <VAPQ5KK6>; Mon, 4 Nov 2002 16:22:35 +0100
Message-ID: <DA6599EBFD6CF042B0B77964CFF62095C9AD62@mchh162e.mch4.siemens.de>
From: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
To: "'Mark Baugher'" <mbaugher@cisco.com>, msec@securemulticast.org,
        Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [MSEC] MESP: The order of security primitives and some more questions...
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, 4 Nov 2002 16:22:25 +0100

Regarding the order of MESP security primitives 

Section 4.1 in paragraphs 1 and 5 state that
1) GS-then-GA = ENC, EXT	for both IPSEC ESP and MESP.

Section 4 implicitly says that
2) SrA-then-GA = INT, EXT

addressing the principles
that the expensive operation (GS, SrA) comes first and then the less
expensive one (GA)
and first encrypt then authenticate.

Now these two partial orders alone do not yet define the order of GS, SrA
and GA security primitives when applied in composition, yet one may be
tempted to deduce and assume the following order would be correct:
3) GS-SrA-then-GA = ENC, INT, EXT



However, section 5 last paragraph comes to a different order, namely
4) SrA-then-GS-then-GA = INT, ENC, EXT

I agree this arrangement would make sense, when the SrA operation is
significantly more expensive than GS such as when using digital signature
for INT.

However, as TELSA shows, INT operation may be cheap and would not be
significantly more expensive than EXT operation for GA. Thus, 4) would not
be optimal in any case and 3) would be better.

From a security perspective, 4) allows to protect (encrypt) the Internal
Authentication Parameters, giving an external attacker less information. I'm
not convinced if this is worthwhile, since for internal attackers, the
Internal Authentication Parameters are available anyway.

In 3), the Internal Authentication Parameters would of course not be
encrypted, since INT occurs after GS.


I believe that some more considerations on these ordering aspects should be
given (e.g. in the security considerations section, or in section 4).

Some other comments:
* Why does MESP not support AH (e.g. MAH)? Is there any reason?
* Table 5.1-1 lists TESLA as an external transform. However, the TELSA
drafts raise the impression, that TELSA actually be an internal mechanism
for source authentication. This appears confusing.

With kind regards


Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 62366
| 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: 	Mark Baugher [mailto:mbaugher@cisco.com] 
Sent:	Tuesday, October 29, 2002 9:35 PM
To:	msec@securemulticast.org
Subject:	[MSEC] Re: I-D ACTION:draft-ietf-msec-mesp-00.txt

Folks,
   We updated this draft to fix an error and also a diagram, which was very 
confusing.  So, the I-D you should work from is at
http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-00.txt

thanks, Mark
At 06:19 AM 10/29/2002 -0500, Internet-Drafts@ietf.org wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Multicast Security Working Group of the
IETF.
>
>         Title           : MESP: Multicast Encapsulating Security Payload
>         Author(s)       : M. Baugher, R. Canetti et al.
>         Filename        : draft-ietf-msec-mesp-00.txt
>         Pages           : 16
>         Date            : 2002-10-28
>
>Multicast ESP (MESP) is a security protocol for IP multicast data.
>MESP extends the IPsec Encapsulating Security Payload (ESP) protocol
>for multicast operation and supports source message authentication
>for multicast packets. MESP offers three improvements to IPsec ESP
>for multicast operation.  First, it allows a mix of group-secrecy,
>group-authentication, and source-authentication transforms to be
>applied to an MESP packet. Second, it extends ESP to authenticate
>messages sent by a member of the group using a digital signature or
>hybrid MAC and signature transform. And third, MESP identifies a
>security association (SA) using the IP address of the source in
>addition to the destination address and SPI.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-msec-mesp-00.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the
username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-ietf-msec-mesp-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         mailserv@ietf.org.
>In the body type:
>         "FILE /internet-drafts/draft-ietf-msec-mesp-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <2002-10-28163608.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-msec-mesp-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-msec-mesp-00.txt>


_______________________________________________
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  Mon Nov  4 11:01:02 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19515
	for <msec-archive@lists.ietf.org>; Mon, 4 Nov 2002 11:01:01 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 463895380B; Mon,  4 Nov 2002 11:02:56 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 4DE4953678
	for <msec@lists.securemulticast.org>; Mon,  4 Nov 2002 11:01:55 -0500 (EST)
Received: (qmail 3533 invoked by uid 3269); 4 Nov 2002 16:01:55 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 3530 invoked from network); 4 Nov 2002 16:01:55 -0000
Received: from sj-msg-core-4.cisco.com (171.71.163.54)
  by klesh.pair.com with SMTP; 4 Nov 2002 16:01:55 -0000
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gA4G1qot010000;
	Mon, 4 Nov 2002 08:01:52 -0800 (PST)
Received: from nisser.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA4G1nSW029797;
	Mon, 4 Nov 2002 08:01:50 -0800 (PST)
Received: from cscoamera13263.cisco.com (sjc-vpn1-899.cisco.com [10.21.99.131]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA09365; Mon, 4 Nov 2002 08:01:42 -0800 (PST)
Message-Id: <5.1.1.5.2.20021104073030.02dd9f18@agora.rdrop.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
To: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: [MSEC] MESP: The order of security primitives and some
  more questions...
Cc: msec@securemulticast.org,
        Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>,
        sfluhrer@cisco.com
In-Reply-To: <DA6599EBFD6CF042B0B77964CFF62095C9AD62@mchh162e.mch4.sieme
 ns.de>
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, 04 Nov 2002 08:01:41 -0800

hi Martin

At 04:22 PM 11/4/2002 +0100, Euchner Martin ICN M SR 3 wrote:
>Regarding the order of MESP security primitives
>
>Section 4.1 in paragraphs 1 and 5 state that
>1) GS-then-GA = ENC, EXT        for both IPSEC ESP and MESP.

Yes, this is the order applied at the sender.  The order at the receiver is 
of course the reverse and this allows a relatively cheaper message 
authentication code to be applied prior to the more expensive decryption 
operation.  This lessens the effects of denial of service attacks that 
attempt to force receiver decryptions of bogus packets.


>Section 4 implicitly says that
>2) SrA-then-GA = INT, EXT

This is true only when the SrA transform is a digital signature.  This is 
not what we intend in general in 
http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-00.txt.  There 
is no restriction that SrA must be an internal transform though Scott 
Fluhrer recommends that TESLA be protected by a MAC (GA) and we need to 
consider this.


>addressing the principles
>that the expensive operation (GS, SrA) comes first and then the less
>expensive one (GA)
>and first encrypt then authenticate.

TESLA is an SrA transform that is not more expensive than a MAC in terms of 
computation.  It could be expensive in terms of receiver memory.  So what 
you say is true for decryption (GS) and digital signature source 
authentication.


>Now these two partial orders alone do not yet define the order of GS, SrA
>and GA security primitives when applied in composition, yet one may be
>tempted to deduce and assume the following order would be correct:
>3) GS-SrA-then-GA = ENC, INT, EXT
>
>
>
>However, section 5 last paragraph comes to a different order, namely
>4) SrA-then-GS-then-GA = INT, ENC, EXT

We perhaps don't state this clearly in the current I-D.  The order is 
always INT, ENC, EXT.  But SrA is not necessarily an internal 
authentication transform (INT).


>I agree this arrangement would make sense, when the SrA operation is
>significantly more expensive than GS such as when using digital signature
>for INT.
>
>However, as TELSA shows, INT operation may be cheap and would not be
>significantly more expensive than EXT operation for GA. Thus, 4) would not
>be optimal in any case and 3) would be better.

The I-D essentially says what you are saying (if somewhere the I-D equates 
SrA with INT, then this is an error).  But there may be a need to protect 
TESLA with a MAC since TESLA cannot authenticate messages until a key is 
revealed.  Over that interval, the receiver will be caching packets that 
are addressed to the group and appear to have a valid source address.  This 
is a denial of service attack that can be partly mitigated by the MAC; when 
GA is applied to TESLA, only group members can spoof the GA.  If the TESLA 
authentication subsequently fails, then the receiver recognizes that its 
attacker holds the group authentication key.


> >From a security perspective, 4) allows to protect (encrypt) the Internal
>Authentication Parameters, giving an external attacker less information. I'm
>not convinced if this is worthwhile, since for internal attackers, the
>Internal Authentication Parameters are available anyway.

I assume by "internal attacker" you mean "group member."  We should keep in 
mind that the authentication needs to be secure independently of whether 
encryption is applied to the packet or not.


>In 3), the Internal Authentication Parameters would of course not be
>encrypted, since INT occurs after GS.

It is always an option that the INT parameters are not encrypted.  We 
cannot require encryption for internal or external authentication.



>I believe that some more considerations on these ordering aspects should be
>given (e.g. in the security considerations section, or in section 4).

I think we need to be more clear in section 4.


>Some other comments:
>* Why does MESP not support AH (e.g. MAH)? Is there any reason?

It's not clear that IPsec is going to continue to support AH.  What we lose 
without AH is authentication of certain IP header fields.  Some claim that 
this is a marginal benefit given the added costs of having a second 
security protocol, NAT traversal, and some other issues.  Regardless of the 
future of AH, it makes sense to start with one protocol for multicast 
extensions and we have chosen ESP because it has both encryption and 
(group) message authentication.  (This is actually the course recommended 
to IRTF SMuG in the original MESP/AMESP draft document).

>* Table 5.1-1 lists TESLA as an external transform. However, the TELSA
>drafts raise the impression, that TELSA actually be an internal mechanism
>for source authentication. This appears confusing.

I read the old TESLA I-D prior to the posting of the latest I-Ds.  I think 
TESLA should be an internal transform based on Scott's observations.

thanks, Mark


>With kind regards
>
>
>Martin Euchner.
>-----------------------------------------------------------------------
>| Dipl.-Inf.                     Rapporteur Q.G/SG16
>| Martin Euchner                 Phone: +49 89 722 55790
>| Siemens AG.....................Fax  : +49 89 722 62366
>| 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:   Mark Baugher [mailto:mbaugher@cisco.com]
>Sent:   Tuesday, October 29, 2002 9:35 PM
>To:     msec@securemulticast.org
>Subject:        [MSEC] Re: I-D ACTION:draft-ietf-msec-mesp-00.txt
>
>Folks,
>    We updated this draft to fix an error and also a diagram, which was very
>confusing.  So, the I-D you should work from is at
>http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-00.txt
>
>thanks, Mark
>At 06:19 AM 10/29/2002 -0500, Internet-Drafts@ietf.org wrote:
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >This draft is a work item of the Multicast Security Working Group of the
>IETF.
> >
> >         Title           : MESP: Multicast Encapsulating Security Payload
> >         Author(s)       : M. Baugher, R. Canetti et al.
> >         Filename        : draft-ietf-msec-mesp-00.txt
> >         Pages           : 16
> >         Date            : 2002-10-28
> >
> >Multicast ESP (MESP) is a security protocol for IP multicast data.
> >MESP extends the IPsec Encapsulating Security Payload (ESP) protocol
> >for multicast operation and supports source message authentication
> >for multicast packets. MESP offers three improvements to IPsec ESP
> >for multicast operation.  First, it allows a mix of group-secrecy,
> >group-authentication, and source-authentication transforms to be
> >applied to an MESP packet. Second, it extends ESP to authenticate
> >messages sent by a member of the group using a digital signature or
> >hybrid MAC and signature transform. And third, MESP identifies a
> >security association (SA) using the IP address of the source in
> >addition to the destination address and SPI.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-msec-mesp-00.txt
> >
> >To remove yourself from the IETF Announcement list, send a message to
> >ietf-announce-request with the word unsubscribe in the body of the message.
> >
> >Internet-Drafts are also available by anonymous FTP. Login with the
>username
> >"anonymous" and a password of your e-mail address. After logging in,
> >type "cd internet-drafts" and then
> >         "get draft-ietf-msec-mesp-00.txt".
> >
> >A list of Internet-Drafts directories can be found in
> >http://www.ietf.org/shadow.html
> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >Internet-Drafts can also be obtained by e-mail.
> >
> >Send a message to:
> >         mailserv@ietf.org.
> >In the body type:
> >         "FILE /internet-drafts/draft-ietf-msec-mesp-00.txt".
> >
> >NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before the "FILE"
> >         command.  To decode the response(s), you will need "munpack" or
> >         a MIME-compliant mail reader.  Different MIME-compliant mail
>readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which have been split
> >         up into multiple messages), so check your local documentation on
> >         how to manipulate these messages.
> >
> >
> >Below is the data which will enable a MIME compliant mail reader
> >implementation to automatically retrieve the ASCII version of the
> >Internet-Draft.
> >Content-Type: text/plain
> >Content-ID:     <2002-10-28163608.I-D@ietf.org>
> >
> >ENCODING mime
> >FILE /internet-drafts/draft-ietf-msec-mesp-00.txt
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-msec-mesp-00.txt>
>
>
>_______________________________________________
>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


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


From msec-admin@securemulticast.org  Mon Nov  4 11:18:36 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20231
	for <msec-archive@lists.ietf.org>; Mon, 4 Nov 2002 11:18:35 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 858585362F; Mon,  4 Nov 2002 11:20:16 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id C581F53805
	for <msec@lists.securemulticast.org>; Mon,  4 Nov 2002 11:18:41 -0500 (EST)
Received: (qmail 6833 invoked by uid 3269); 4 Nov 2002 16:18:41 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 6827 invoked from network); 4 Nov 2002 16:18:41 -0000
Received: from zcars04f.nortelnetworks.com (47.129.242.57)
  by klesh.pair.com with SMTP; 4 Nov 2002 16:18:41 -0000
Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA4GIMc20956;
	Mon, 4 Nov 2002 11:18:22 -0500 (EST)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id TWX0NVBJ; Mon, 4 Nov 2002 11:18:21 -0500
Received: from nortelnetworks.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id TSNC9JZ7; Mon, 4 Nov 2002 11:18:20 -0500
Message-ID: <3DC691DD.4040805@nortelnetworks.com>
X-Sybari-Space: 00000000 00000000 00000000
From: Lakshminath Dondeti <ldondeti@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Baugher <mbaugher@cisco.com>
Cc: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>,
        msec@securemulticast.org, sfluhrer@cisco.com
Subject: Re: [MSEC] MESP: The order of security primitives and some  more
 questions...
References: <5.1.1.5.2.20021104073030.02dd9f18@agora.rdrop.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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, 04 Nov 2002 10:27:25 -0500
Content-Transfer-Encoding: 7bit

Why not make the SrA always an INT?  Thus we will have SrA, GC followed 
by GA, which makes it easy to understand, analyze and implement. 
Besides, SrA, even if it is TESLA is more expensive than GA anyway.

Or perhaps, GC, SrA, GA is better considering delayed and probabilistic 
authentication by some source authentication schemes.  This limits the 
DoS attacks to consuming just buffer space; why decrypt until we know 
that the packets are legitimate.  We lose non-repudiation (not provided 
by TESLA, but the hash chaining schemes support it)  in this case, however.

The different options bother me, I am hoping we can avoid that.

cheers,
Lakshminath

Mark Baugher wrote:
> hi Martin
> 
> At 04:22 PM 11/4/2002 +0100, Euchner Martin ICN M SR 3 wrote:
> 
>> Regarding the order of MESP security primitives
>>
>> Section 4.1 in paragraphs 1 and 5 state that
>> 1) GS-then-GA = ENC, EXT        for both IPSEC ESP and MESP.
> 
> 
> Yes, this is the order applied at the sender.  The order at the receiver 
> is of course the reverse and this allows a relatively cheaper message 
> authentication code to be applied prior to the more expensive decryption 
> operation.  This lessens the effects of denial of service attacks that 
> attempt to force receiver decryptions of bogus packets.
> 
> 
>> Section 4 implicitly says that
>> 2) SrA-then-GA = INT, EXT
> 
> 
> This is true only when the SrA transform is a digital signature.  This 
> is not what we intend in general in 
> http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-00.txt.  
> There is no restriction that SrA must be an internal transform though 
> Scott Fluhrer recommends that TESLA be protected by a MAC (GA) and we 
> need to consider this.
> 
> 
>> addressing the principles
>> that the expensive operation (GS, SrA) comes first and then the less
>> expensive one (GA)
>> and first encrypt then authenticate.
> 
> 
> TESLA is an SrA transform that is not more expensive than a MAC in terms 
> of computation.  It could be expensive in terms of receiver memory.  So 
> what you say is true for decryption (GS) and digital signature source 
> authentication.
> 
> 
>> Now these two partial orders alone do not yet define the order of GS, SrA
>> and GA security primitives when applied in composition, yet one may be
>> tempted to deduce and assume the following order would be correct:
>> 3) GS-SrA-then-GA = ENC, INT, EXT
>>
>>
>>
>> However, section 5 last paragraph comes to a different order, namely
>> 4) SrA-then-GS-then-GA = INT, ENC, EXT
> 
> 
> We perhaps don't state this clearly in the current I-D.  The order is 
> always INT, ENC, EXT.  But SrA is not necessarily an internal 
> authentication transform (INT).
> 
> 
>> I agree this arrangement would make sense, when the SrA operation is
>> significantly more expensive than GS such as when using digital signature
>> for INT.
>>
>> However, as TELSA shows, INT operation may be cheap and would not be
>> significantly more expensive than EXT operation for GA. Thus, 4) would 
>> not
>> be optimal in any case and 3) would be better.
> 
> 
> The I-D essentially says what you are saying (if somewhere the I-D 
> equates SrA with INT, then this is an error).  But there may be a need 
> to protect TESLA with a MAC since TESLA cannot authenticate messages 
> until a key is revealed.  Over that interval, the receiver will be 
> caching packets that are addressed to the group and appear to have a 
> valid source address.  This is a denial of service attack that can be 
> partly mitigated by the MAC; when GA is applied to TESLA, only group 
> members can spoof the GA.  If the TESLA authentication subsequently 
> fails, then the receiver recognizes that its attacker holds the group 
> authentication key.
> 
> 
>> >From a security perspective, 4) allows to protect (encrypt) the Internal
>> Authentication Parameters, giving an external attacker less 
>> information. I'm
>> not convinced if this is worthwhile, since for internal attackers, the
>> Internal Authentication Parameters are available anyway.
> 
> 
> I assume by "internal attacker" you mean "group member."  We should keep 
> in mind that the authentication needs to be secure independently of 
> whether encryption is applied to the packet or not.
> 
> 
>> In 3), the Internal Authentication Parameters would of course not be
>> encrypted, since INT occurs after GS.
> 
> 
> It is always an option that the INT parameters are not encrypted.  We 
> cannot require encryption for internal or external authentication.
> 
> 
> 
>> I believe that some more considerations on these ordering aspects 
>> should be
>> given (e.g. in the security considerations section, or in section 4).
> 
> 
> I think we need to be more clear in section 4.
> 
> 
>> Some other comments:
>> * Why does MESP not support AH (e.g. MAH)? Is there any reason?
> 
> 
> It's not clear that IPsec is going to continue to support AH.  What we 
> lose without AH is authentication of certain IP header fields.  Some 
> claim that this is a marginal benefit given the added costs of having a 
> second security protocol, NAT traversal, and some other issues.  
> Regardless of the future of AH, it makes sense to start with one 
> protocol for multicast extensions and we have chosen ESP because it has 
> both encryption and (group) message authentication.  (This is actually 
> the course recommended to IRTF SMuG in the original MESP/AMESP draft 
> document).
> 
>> * Table 5.1-1 lists TESLA as an external transform. However, the TELSA
>> drafts raise the impression, that TELSA actually be an internal mechanism
>> for source authentication. This appears confusing.
> 
> 
> I read the old TESLA I-D prior to the posting of the latest I-Ds.  I 
> think TESLA should be an internal transform based on Scott's observations.
> 
> thanks, Mark
> 
> 
>> With kind regards
>>
>>
>> Martin Euchner.
>> -----------------------------------------------------------------------
>> | Dipl.-Inf.                     Rapporteur Q.G/SG16
>> | Martin Euchner                 Phone: +49 89 722 55790
>> | Siemens AG.....................Fax  : +49 89 722 62366
>> | 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:   Mark Baugher [mailto:mbaugher@cisco.com]
>> Sent:   Tuesday, October 29, 2002 9:35 PM
>> To:     msec@securemulticast.org
>> Subject:        [MSEC] Re: I-D ACTION:draft-ietf-msec-mesp-00.txt
>>
>> Folks,
>>    We updated this draft to fix an error and also a diagram, which was 
>> very
>> confusing.  So, the I-D you should work from is at
>> http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-00.txt
>>
>> thanks, Mark
>> At 06:19 AM 10/29/2002 -0500, Internet-Drafts@ietf.org wrote:
>> >A New Internet-Draft is available from the on-line Internet-Drafts
>> >directories.
>> >This draft is a work item of the Multicast Security Working Group of the
>> IETF.
>> >
>> >         Title           : MESP: Multicast Encapsulating Security 
>> Payload
>> >         Author(s)       : M. Baugher, R. Canetti et al.
>> >         Filename        : draft-ietf-msec-mesp-00.txt
>> >         Pages           : 16
>> >         Date            : 2002-10-28
>> >
>> >Multicast ESP (MESP) is a security protocol for IP multicast data.
>> >MESP extends the IPsec Encapsulating Security Payload (ESP) protocol
>> >for multicast operation and supports source message authentication
>> >for multicast packets. MESP offers three improvements to IPsec ESP
>> >for multicast operation.  First, it allows a mix of group-secrecy,
>> >group-authentication, and source-authentication transforms to be
>> >applied to an MESP packet. Second, it extends ESP to authenticate
>> >messages sent by a member of the group using a digital signature or
>> >hybrid MAC and signature transform. And third, MESP identifies a
>> >security association (SA) using the IP address of the source in
>> >addition to the destination address and SPI.
>> >
>> >A URL for this Internet-Draft is:
>> >http://www.ietf.org/internet-drafts/draft-ietf-msec-mesp-00.txt
>> >
>> >To remove yourself from the IETF Announcement list, send a message to
>> >ietf-announce-request with the word unsubscribe in the body of the 
>> message.
>> >
>> >Internet-Drafts are also available by anonymous FTP. Login with the
>> username
>> >"anonymous" and a password of your e-mail address. After logging in,
>> >type "cd internet-drafts" and then
>> >         "get draft-ietf-msec-mesp-00.txt".
>> >
>> >A list of Internet-Drafts directories can be found in
>> >http://www.ietf.org/shadow.html
>> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> >
>> >
>> >Internet-Drafts can also be obtained by e-mail.
>> >
>> >Send a message to:
>> >         mailserv@ietf.org.
>> >In the body type:
>> >         "FILE /internet-drafts/draft-ietf-msec-mesp-00.txt".
>> >
>> >NOTE:   The mail server at ietf.org can return the document in
>> >         MIME-encoded form by using the "mpack" utility.  To use this
>> >         feature, insert the command "ENCODING mime" before the "FILE"
>> >         command.  To decode the response(s), you will need "munpack" or
>> >         a MIME-compliant mail reader.  Different MIME-compliant mail
>> readers
>> >         exhibit different behavior, especially when dealing with
>> >         "multipart" MIME messages (i.e. documents which have been split
>> >         up into multiple messages), so check your local 
>> documentation on
>> >         how to manipulate these messages.
>> >
>> >
>> >Below is the data which will enable a MIME compliant mail reader
>> >implementation to automatically retrieve the ASCII version of the
>> >Internet-Draft.
>> >Content-Type: text/plain
>> >Content-ID:     <2002-10-28163608.I-D@ietf.org>
>> >
>> >ENCODING mime
>> >FILE /internet-drafts/draft-ietf-msec-mesp-00.txt
>> >
>> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-msec-mesp-00.txt>
>>
>>
>> _______________________________________________
>> 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
> 
> 
> 
> _______________________________________________
> 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  Mon Nov  4 11:44:37 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21893
	for <msec-archive@lists.ietf.org>; Mon, 4 Nov 2002 11:44:37 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 74DCF53846; Mon,  4 Nov 2002 11:46:29 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 3F1AD53867
	for <msec@lists.securemulticast.org>; Mon,  4 Nov 2002 11:45:02 -0500 (EST)
Received: (qmail 10055 invoked by uid 3269); 4 Nov 2002 16:45:02 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 10052 invoked from network); 4 Nov 2002 16:45:01 -0000
Received: from beamer.mchh.siemens.de (194.138.158.163)
  by klesh.pair.com with SMTP; 4 Nov 2002 16:45:01 -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 RAA03396;
	Mon, 4 Nov 2002 17:44:29 +0100 (MET)
Received: from mchh169e.mch4.siemens.de ([139.21.130.176])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA08541;
	Mon, 4 Nov 2002 17:44:29 +0100 (MET)
Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <VAPQ5LDJ>; Mon, 4 Nov 2002 17:44:30 +0100
Message-ID: <DA6599EBFD6CF042B0B77964CFF62095C9AD6A@mchh162e.mch4.siemens.de>
From: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
To: "'Mark Baugher'" <mbaugher@cisco.com>,
        Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
Cc: msec@securemulticast.org, sfluhrer@cisco.com
Subject: RE: [MSEC] MESP: The order of security primitives and some more q
	uestions...
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: Mon, 4 Nov 2002 17:44:20 +0100

Mark,

thanks for the quick response and the clarifications.


With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 62366
| 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: 	Mark Baugher [mailto:mbaugher@cisco.com] 
Sent:	Monday, November 04, 2002 5:02 PM
To:	Euchner Martin  ICN M SR 3
Cc:	msec@securemulticast.org; Euchner Martin  ICN M SR 3;
sfluhrer@cisco.com
Subject:	Re: [MSEC] MESP: The order of security primitives and some
more questions...

hi Martin

At 04:22 PM 11/4/2002 +0100, Euchner Martin ICN M SR 3 wrote:
>Regarding the order of MESP security primitives
>
>Section 4.1 in paragraphs 1 and 5 state that
>1) GS-then-GA = ENC, EXT        for both IPSEC ESP and MESP.

Yes, this is the order applied at the sender.  The order at the receiver is 
of course the reverse and this allows a relatively cheaper message 
authentication code to be applied prior to the more expensive decryption 
operation.  This lessens the effects of denial of service attacks that 
attempt to force receiver decryptions of bogus packets.

MEU:> I fully agree.

>Section 4 implicitly says that
>2) SrA-then-GA = INT, EXT

This is true only when the SrA transform is a digital signature.  This is 
not what we intend in general in 
http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-00.txt.  There 
is no restriction that SrA must be an internal transform though Scott 
Fluhrer recommends that TESLA be protected by a MAC (GA) and we need to 
consider this.

MEU:> ok, I see now.

>addressing the principles
>that the expensive operation (GS, SrA) comes first and then the less
>expensive one (GA)
>and first encrypt then authenticate.

TESLA is an SrA transform that is not more expensive than a MAC in terms of 
computation.  It could be expensive in terms of receiver memory.  So what 
you say is true for decryption (GS) and digital signature source 
authentication.


MEU:>ok. 

>Now these two partial orders alone do not yet define the order of GS, SrA
>and GA security primitives when applied in composition, yet one may be
>tempted to deduce and assume the following order would be correct:
>3) GS-SrA-then-GA = ENC, INT, EXT
>
>
>
>However, section 5 last paragraph comes to a different order, namely
>4) SrA-then-GS-then-GA = INT, ENC, EXT

We perhaps don't state this clearly in the current I-D.  The order is 
always INT, ENC, EXT.  
MEU:> I found that clear.

But SrA is not necessarily an internal 
authentication transform (INT).

MEU:> correct. Perhaps I've overseen something trivially or such a statement
should be added.

>I agree this arrangement would make sense, when the SrA operation is
>significantly more expensive than GS such as when using digital signature
>for INT.
>
>However, as TELSA shows, INT operation may be cheap and would not be
>significantly more expensive than EXT operation for GA. Thus, 4) would not
>be optimal in any case and 3) would be better.

The I-D essentially says what you are saying (if somewhere the I-D equates 
SrA with INT, then this is an error).  But there may be a need to protect 
TESLA with a MAC since TESLA cannot authenticate messages until a key is 
revealed.  Over that interval, the receiver will be caching packets that 
are addressed to the group and appear to have a valid source address.  This 
is a denial of service attack that can be partly mitigated by the MAC; when 
GA is applied to TESLA, only group members can spoof the GA.  If the TESLA 
authentication subsequently fails, then the receiver recognizes that its 
attacker holds the group authentication key.


> >From a security perspective, 4) allows to protect (encrypt) the Internal
>Authentication Parameters, giving an external attacker less information.
I'm
>not convinced if this is worthwhile, since for internal attackers, the
>Internal Authentication Parameters are available anyway.

I assume by "internal attacker" you mean "group member."  We should keep in 
mind that the authentication needs to be secure independently of whether 
encryption is applied to the packet or not.


MEU:> right, that's what I meant.

>In 3), the Internal Authentication Parameters would of course not be
>encrypted, since INT occurs after GS.

It is always an option that the INT parameters are not encrypted.  We 
cannot require encryption for internal or external authentication.


MEU:> The last two points are really minor in my eyes.

>I believe that some more considerations on these ordering aspects should be
>given (e.g. in the security considerations section, or in section 4).

I think we need to be more clear in section 4.

MEU: I appreciate this.

>Some other comments:
>* Why does MESP not support AH (e.g. MAH)? Is there any reason?

It's not clear that IPsec is going to continue to support AH.  What we lose 
without AH is authentication of certain IP header fields.  Some claim that 
this is a marginal benefit given the added costs of having a second 
security protocol, NAT traversal, and some other issues.  Regardless of the 
future of AH, it makes sense to start with one protocol for multicast 
extensions and we have chosen ESP because it has both encryption and 
(group) message authentication.  (This is actually the course recommended 
to IRTF SMuG in the original MESP/AMESP draft document).

MEU:> ok.

>* Table 5.1-1 lists TESLA as an external transform. However, the TELSA
>drafts raise the impression, that TELSA actually be an internal mechanism
>for source authentication. This appears confusing.

I read the old TESLA I-D prior to the posting of the latest I-Ds.  I think 
TESLA should be an internal transform based on Scott's observations.

MEU:> great, that's my understanding too, so we have common view.

thanks, Mark


>With kind regards
>
>
>Martin Euchner.
>-----------------------------------------------------------------------
>| Dipl.-Inf.                     Rapporteur Q.G/SG16
>| Martin Euchner                 Phone: +49 89 722 55790
>| Siemens AG.....................Fax  : +49 89 722 62366
>| 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:   Mark Baugher [mailto:mbaugher@cisco.com]
>Sent:   Tuesday, October 29, 2002 9:35 PM
>To:     msec@securemulticast.org
>Subject:        [MSEC] Re: I-D ACTION:draft-ietf-msec-mesp-00.txt
>
>Folks,
>    We updated this draft to fix an error and also a diagram, which was
very
>confusing.  So, the I-D you should work from is at
>http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-00.txt
>
>thanks, Mark
>At 06:19 AM 10/29/2002 -0500, Internet-Drafts@ietf.org wrote:
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >This draft is a work item of the Multicast Security Working Group of the
>IETF.
> >
> >         Title           : MESP: Multicast Encapsulating Security Payload
> >         Author(s)       : M. Baugher, R. Canetti et al.
> >         Filename        : draft-ietf-msec-mesp-00.txt
> >         Pages           : 16
> >         Date            : 2002-10-28
> >
> >Multicast ESP (MESP) is a security protocol for IP multicast data.
> >MESP extends the IPsec Encapsulating Security Payload (ESP) protocol
> >for multicast operation and supports source message authentication
> >for multicast packets. MESP offers three improvements to IPsec ESP
> >for multicast operation.  First, it allows a mix of group-secrecy,
> >group-authentication, and source-authentication transforms to be
> >applied to an MESP packet. Second, it extends ESP to authenticate
> >messages sent by a member of the group using a digital signature or
> >hybrid MAC and signature transform. And third, MESP identifies a
> >security association (SA) using the IP address of the source in
> >addition to the destination address and SPI.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-msec-mesp-00.txt
> >
> >To remove yourself from the IETF Announcement list, send a message to
> >ietf-announce-request with the word unsubscribe in the body of the
message.
> >
> >Internet-Drafts are also available by anonymous FTP. Login with the
>username
> >"anonymous" and a password of your e-mail address. After logging in,
> >type "cd internet-drafts" and then
> >         "get draft-ietf-msec-mesp-00.txt".
> >
> >A list of Internet-Drafts directories can be found in
> >http://www.ietf.org/shadow.html
> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >Internet-Drafts can also be obtained by e-mail.
> >
> >Send a message to:
> >         mailserv@ietf.org.
> >In the body type:
> >         "FILE /internet-drafts/draft-ietf-msec-mesp-00.txt".
> >
> >NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before the "FILE"
> >         command.  To decode the response(s), you will need "munpack" or
> >         a MIME-compliant mail reader.  Different MIME-compliant mail
>readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which have been split
> >         up into multiple messages), so check your local documentation on
> >         how to manipulate these messages.
> >
> >
> >Below is the data which will enable a MIME compliant mail reader
> >implementation to automatically retrieve the ASCII version of the
> >Internet-Draft.
> >Content-Type: text/plain
> >Content-ID:     <2002-10-28163608.I-D@ietf.org>
> >
> >ENCODING mime
> >FILE /internet-drafts/draft-ietf-msec-mesp-00.txt
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-msec-mesp-00.txt>
>
>
>_______________________________________________
>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

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


From msec-admin@securemulticast.org  Mon Nov  4 13:24:41 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27178
	for <msec-archive@lists.ietf.org>; Mon, 4 Nov 2002 13:24:41 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id D8ABA537DD; Mon,  4 Nov 2002 13:26:36 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id BF249537DD
	for <msec@lists.securemulticast.org>; Mon,  4 Nov 2002 13:24:47 -0500 (EST)
Received: (qmail 24739 invoked by uid 3269); 4 Nov 2002 18:24:47 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 24736 invoked from network); 4 Nov 2002 18:24:47 -0000
Received: from beamer.mchh.siemens.de (194.138.158.163)
  by klesh.pair.com with SMTP; 4 Nov 2002 18:24:47 -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 TAA06127
	for <msec@securemulticast.org>; Mon, 4 Nov 2002 19:24:46 +0100 (MET)
Received: from mchh169e.mch4.siemens.de ([139.21.130.176])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id TAA14802
	for <msec@securemulticast.org>; Mon, 4 Nov 2002 19:24:44 +0100 (MET)
Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <VAPQ5LVY>; Mon, 4 Nov 2002 19:24:41 +0100
Message-ID: <DA6599EBFD6CF042B0B77964CFF62095C9AD6B@mchh162e.mch4.siemens.de>
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>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [MSEC] gkmarch-03: host computer block diagram unclear
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, 4 Nov 2002 19:24:32 +0100

Folks,

Figure 2 shows a block diagram for a host computer. To me, this figure is
pretty confusing for the following reasons:

- Actually, I'm assuming that the figure shows two host computers: one host
computer for the GCKS and another one for the group member.
- The figure shows various arrows; some appear labelled as group key
management protocols (Reg, Rek), while many others are unlabeled. I'm
assuming that the latter ones be just internal communication
interfaces/APIs?
- It is very confusing to see a box "security protocol" within the host of
the member, but similar box is found missing in the GCKS host. What is the
function of the box "security protocol"? Is it a parsing function of the
group key management protocols? Or is this the "Data Security Protocol"
function, which I understood not part of the group key management
architecture directly?
- Shouldn't GCKS host computer provide a "security protocol" box and
attached SAD/SPD too?
In this case, hardly any difference would remain between the GCKS and the
member functional components and the entire figure might be simplified.
- What is the function of "GKM"?
- What is the work split between "GKM", "Security Protocol"  and "CONTROL"
box? How do these boxes interact in terms during the procession of the group
key management protocols?
- The member host shows SAD and SPD attached to the "GKM" and to the
"Security Protocol" box. It is intentional that these be separate stores?
- Figure 1 shows also interaction with external components such as
policy/authorization infrastructure. It is not shown in Figure 2 how such
external components interface with the building blocks.
- CONTROL on one hand is described as a function which is fine but on the
other hand as a telephony signalling protocol (SIP) which sounds strange. I
would roughly understand this intuitively something as "SIP signalling
protocol being terminated by a CONTROL function". Is that the intention? If
that is the case, then there should be CONTROL <-- SIP --> CONTROL
communication too, although such communication arcs would leave/enter the
outer dashed box.


Some other observations:

Figure 1 is subtitled " Group Security Association Model", yet the figure
actually shows only protocols but not any SAs. Thus, I would subtitle the
figure more as "Group Security Protocol Architecture".
I could imagine a similar different figure that shows a mapping of the
various SAs to the security protocols.


While the GKMA document focuses on the protocol view with the registration
and re-key protocol, I would like to see some considerations given how
typical multicast applications can make use of these atomic protocols for
performing tasks like
- GCKS adds/removes one or more group member(s),
- Join/leave of a member.
- Are there other typical "higher-layer" operations (which?) that could be
realized through the GKM protocols (how?) ?


With kind regards


Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 62366
| 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  Mon Nov  4 13:48:50 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28681
	for <msec-archive@lists.ietf.org>; Mon, 4 Nov 2002 13:48:50 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id BF50453811; Mon,  4 Nov 2002 13:50:39 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id CBDF35363E
	for <msec@lists.securemulticast.org>; Mon,  4 Nov 2002 13:48:57 -0500 (EST)
Received: (qmail 27679 invoked by uid 3269); 4 Nov 2002 18:48:57 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 27676 invoked from network); 4 Nov 2002 18:48:57 -0000
Received: from sj-msg-core-4.cisco.com (171.71.163.54)
  by klesh.pair.com with SMTP; 4 Nov 2002 18:48:57 -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 gA4Imeot012008;
	Mon, 4 Nov 2002 10:48:40 -0800 (PST)
Received: from cscoamera13263.mbaugher.com (sjc-vpn3-395.cisco.com [10.21.65.139])
	by mira-sjc5-6.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA)
	with ESMTP id AAV38953;
	Mon, 4 Nov 2002 10:45:06 -0800 (PST)
Message-Id: <5.1.1.5.2.20021104104637.064ed5c8@agora.rdrop.com>
X-Sender: mbaugher@agora.rdrop.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
To: Lakshminath Dondeti <ldondeti@nortelnetworks.com>
From: Mark Baugher <mark@mbaugher.com>
Subject: Re: [MSEC] MESP: The order of security primitives and some 
  more questions...
Cc: Mark Baugher <mbaugher@cisco.com>,
        Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>,
        msec@securemulticast.org, sfluhrer@cisco.com
In-Reply-To: <3DC691DD.4040805@nortelnetworks.com>
References: <5.1.1.5.2.20021104073030.02dd9f18@agora.rdrop.com>
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, 04 Nov 2002 10:48:37 -0800

We had SrA always be an internal authentication transform (INT) in an 
earlier version of this draft but changed it so as to not unduly restrict 
source message authentication options.  Following Scott's observation and 
some more consideration, I'm inclined to agree with you.

Mark

At 10:27 AM 11/4/2002 -0500, Lakshminath Dondeti wrote:
>Why not make the SrA always an INT?  Thus we will have SrA, GC followed by 
>GA, which makes it easy to understand, analyze and implement. Besides, 
>SrA, even if it is TESLA is more expensive than GA anyway.
>
>Or perhaps, GC, SrA, GA is better considering delayed and probabilistic 
>authentication by some source authentication schemes.  This limits the DoS 
>attacks to consuming just buffer space; why decrypt until we know that the 
>packets are legitimate.  We lose non-repudiation (not provided by TESLA, 
>but the hash chaining schemes support it)  in this case, however.
>
>The different options bother me, I am hoping we can avoid that.
>
>cheers,
>Lakshminath
>
>Mark Baugher wrote:
>>hi Martin
>>At 04:22 PM 11/4/2002 +0100, Euchner Martin ICN M SR 3 wrote:
>>
>>>Regarding the order of MESP security primitives
>>>
>>>Section 4.1 in paragraphs 1 and 5 state that
>>>1) GS-then-GA = ENC, EXT        for both IPSEC ESP and MESP.
>>
>>Yes, this is the order applied at the sender.  The order at the receiver 
>>is of course the reverse and this allows a relatively cheaper message 
>>authentication code to be applied prior to the more expensive decryption 
>>operation.  This lessens the effects of denial of service attacks that 
>>attempt to force receiver decryptions of bogus packets.
>>
>>>Section 4 implicitly says that
>>>2) SrA-then-GA = INT, EXT
>>
>>This is true only when the SrA transform is a digital signature.  This is 
>>not what we intend in general in 
>>http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-00.txt.
>>There is no restriction that SrA must be an internal transform though 
>>Scott Fluhrer recommends that TESLA be protected by a MAC (GA) and we 
>>need to consider this.
>>
>>>addressing the principles
>>>that the expensive operation (GS, SrA) comes first and then the less
>>>expensive one (GA)
>>>and first encrypt then authenticate.
>>
>>TESLA is an SrA transform that is not more expensive than a MAC in terms 
>>of computation.  It could be expensive in terms of receiver memory.  So 
>>what you say is true for decryption (GS) and digital signature source 
>>authentication.
>>
>>>Now these two partial orders alone do not yet define the order of GS, SrA
>>>and GA security primitives when applied in composition, yet one may be
>>>tempted to deduce and assume the following order would be correct:
>>>3) GS-SrA-then-GA = ENC, INT, EXT
>>>
>>>
>>>
>>>However, section 5 last paragraph comes to a different order, namely
>>>4) SrA-then-GS-then-GA = INT, ENC, EXT
>>
>>We perhaps don't state this clearly in the current I-D.  The order is 
>>always INT, ENC, EXT.  But SrA is not necessarily an internal 
>>authentication transform (INT).
>>
>>>I agree this arrangement would make sense, when the SrA operation is
>>>significantly more expensive than GS such as when using digital signature
>>>for INT.
>>>
>>>However, as TELSA shows, INT operation may be cheap and would not be
>>>significantly more expensive than EXT operation for GA. Thus, 4) would not
>>>be optimal in any case and 3) would be better.
>>
>>The I-D essentially says what you are saying (if somewhere the I-D 
>>equates SrA with INT, then this is an error).  But there may be a need to 
>>protect TESLA with a MAC since TESLA cannot authenticate messages until a 
>>key is revealed.  Over that interval, the receiver will be caching 
>>packets that are addressed to the group and appear to have a valid source 
>>address.  This is a denial of service attack that can be partly mitigated 
>>by the MAC; when GA is applied to TESLA, only group members can spoof the 
>>GA.  If the TESLA authentication subsequently fails, then the receiver 
>>recognizes that its attacker holds the group authentication key.
>>
>>> >From a security perspective, 4) allows to protect (encrypt) the Internal
>>>Authentication Parameters, giving an external attacker less information. I'm
>>>not convinced if this is worthwhile, since for internal attackers, the
>>>Internal Authentication Parameters are available anyway.
>>
>>I assume by "internal attacker" you mean "group member."  We should keep 
>>in mind that the authentication needs to be secure independently of 
>>whether encryption is applied to the packet or not.
>>
>>>In 3), the Internal Authentication Parameters would of course not be
>>>encrypted, since INT occurs after GS.
>>
>>It is always an option that the INT parameters are not encrypted.  We 
>>cannot require encryption for internal or external authentication.
>>
>>
>>>I believe that some more considerations on these ordering aspects should be
>>>given (e.g. in the security considerations section, or in section 4).
>>
>>I think we need to be more clear in section 4.
>>
>>>Some other comments:
>>>* Why does MESP not support AH (e.g. MAH)? Is there any reason?
>>
>>It's not clear that IPsec is going to continue to support AH.  What we 
>>lose without AH is authentication of certain IP header fields.  Some 
>>claim that this is a marginal benefit given the added costs of having a 
>>second security protocol, NAT traversal, and some other issues.
>>Regardless of the future of AH, it makes sense to start with one protocol 
>>for multicast extensions and we have chosen ESP because it has both 
>>encryption and (group) message authentication.  (This is actually the 
>>course recommended to IRTF SMuG in the original MESP/AMESP draft document).
>>
>>>* Table 5.1-1 lists TESLA as an external transform. However, the TELSA
>>>drafts raise the impression, that TELSA actually be an internal mechanism
>>>for source authentication. This appears confusing.
>>
>>I read the old TESLA I-D prior to the posting of the latest I-Ds.  I 
>>think TESLA should be an internal transform based on Scott's observations.
>>thanks, Mark
>>
>>>With kind regards
>>>
>>>
>>>Martin Euchner.
>>>-----------------------------------------------------------------------
>>>| Dipl.-Inf.                     Rapporteur Q.G/SG16
>>>| Martin Euchner                 Phone: +49 89 722 55790
>>>| Siemens AG.....................Fax  : +49 89 722 62366
>>>| 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:   Mark Baugher [mailto:mbaugher@cisco.com]
>>>Sent:   Tuesday, October 29, 2002 9:35 PM
>>>To:     msec@securemulticast.org
>>>Subject:        [MSEC] Re: I-D ACTION:draft-ietf-msec-mesp-00.txt
>>>
>>>Folks,
>>>    We updated this draft to fix an error and also a diagram, which was very
>>>confusing.  So, the I-D you should work from is at
>>>http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-00.txt
>>>
>>>thanks, Mark
>>>At 06:19 AM 10/29/2002 -0500, Internet-Drafts@ietf.org wrote:
>>> >A New Internet-Draft is available from the on-line Internet-Drafts
>>> >directories.
>>> >This draft is a work item of the Multicast Security Working Group of the
>>>IETF.
>>> >
>>> >         Title           : MESP: Multicast Encapsulating Security Payload
>>> >         Author(s)       : M. Baugher, R. Canetti et al.
>>> >         Filename        : draft-ietf-msec-mesp-00.txt
>>> >         Pages           : 16
>>> >         Date            : 2002-10-28
>>> >
>>> >Multicast ESP (MESP) is a security protocol for IP multicast data.
>>> >MESP extends the IPsec Encapsulating Security Payload (ESP) protocol
>>> >for multicast operation and supports source message authentication
>>> >for multicast packets. MESP offers three improvements to IPsec ESP
>>> >for multicast operation.  First, it allows a mix of group-secrecy,
>>> >group-authentication, and source-authentication transforms to be
>>> >applied to an MESP packet. Second, it extends ESP to authenticate
>>> >messages sent by a member of the group using a digital signature or
>>> >hybrid MAC and signature transform. And third, MESP identifies a
>>> >security association (SA) using the IP address of the source in
>>> >addition to the destination address and SPI.
>>> >
>>> >A URL for this Internet-Draft is:
>>> >http://www.ietf.org/internet-drafts/draft-ietf-msec-mesp-00.txt
>>> >
>>> >To remove yourself from the IETF Announcement list, send a message to
>>> >ietf-announce-request with the word unsubscribe in the body of the 
>>> message.
>>> >
>>> >Internet-Drafts are also available by anonymous FTP. Login with the
>>>username
>>> >"anonymous" and a password of your e-mail address. After logging in,
>>> >type "cd internet-drafts" and then
>>> >         "get draft-ietf-msec-mesp-00.txt".
>>> >
>>> >A list of Internet-Drafts directories can be found in
>>> >http://www.ietf.org/shadow.html
>>> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>> >
>>> >
>>> >Internet-Drafts can also be obtained by e-mail.
>>> >
>>> >Send a message to:
>>> >         mailserv@ietf.org.
>>> >In the body type:
>>> >         "FILE /internet-drafts/draft-ietf-msec-mesp-00.txt".
>>> >
>>> >NOTE:   The mail server at ietf.org can return the document in
>>> >         MIME-encoded form by using the "mpack" utility.  To use this
>>> >         feature, insert the command "ENCODING mime" before the "FILE"
>>> >         command.  To decode the response(s), you will need "munpack" or
>>> >         a MIME-compliant mail reader.  Different MIME-compliant mail
>>>readers
>>> >         exhibit different behavior, especially when dealing with
>>> >         "multipart" MIME messages (i.e. documents which have been split
>>> >         up into multiple messages), so check your local documentation on
>>> >         how to manipulate these messages.
>>> >
>>> >
>>> >Below is the data which will enable a MIME compliant mail reader
>>> >implementation to automatically retrieve the ASCII version of the
>>> >Internet-Draft.
>>> >Content-Type: text/plain
>>> >Content-ID:     <2002-10-28163608.I-D@ietf.org>
>>> >
>>> >ENCODING mime
>>> >FILE /internet-drafts/draft-ietf-msec-mesp-00.txt
>>> >
>>> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-msec-mesp-00.txt>
>>>
>>>
>>>_______________________________________________
>>>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
>>
>>_______________________________________________
>>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


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


From msec-admin@securemulticast.org  Mon Nov  4 14:10:37 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29867
	for <msec-archive@lists.ietf.org>; Mon, 4 Nov 2002 14:10:36 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 0FBA853871; Mon,  4 Nov 2002 14:08:56 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 797C253868
	for <msec@lists.securemulticast.org>; Mon,  4 Nov 2002 14:07:46 -0500 (EST)
Received: (qmail 29908 invoked by uid 3269); 4 Nov 2002 19:07:46 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 29903 invoked from network); 4 Nov 2002 19:07:46 -0000
Received: from zcars04e.nortelnetworks.com (47.129.242.56)
  by klesh.pair.com with SMTP; 4 Nov 2002 19:07:46 -0000
Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62])
	by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA4J7cc23091;
	Mon, 4 Nov 2002 14:07:38 -0500 (EST)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id TWX0NXAF; Mon, 4 Nov 2002 14:07:37 -0500
Received: from nortelnetworks.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id TSNC9KDA; Mon, 4 Nov 2002 14:07:37 -0500
Message-ID: <3DC6C51E.4000607@nortelnetworks.com>
X-Sybari-Space: 00000000 00000000 00000000
From: Lakshminath Dondeti <ldondeti@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
Cc: msec@securemulticast.org
Subject: Re: [MSEC] gkmarch-03: host computer block diagram unclear
References: <DA6599EBFD6CF042B0B77964CFF62095C9AD6B@mchh162e.mch4.siemens.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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, 04 Nov 2002 14:06:06 -0500
Content-Transfer-Encoding: 7bit

Hi,

I will try and answer some of your questions below.

Euchner Martin ICN M SR 3 wrote:
> Folks,
> 
> Figure 2 shows a block diagram for a host computer. To me, this figure is
> pretty confusing for the following reasons:
> 
> - Actually, I'm assuming that the figure shows two host computers: one host
> computer for the GCKS and another one for the group member.
> - The figure shows various arrows; some appear labelled as group key
> management protocols (Reg, Rek), while many others are unlabeled. I'm
> assuming that the latter ones be just internal communication
> interfaces/APIs?
> - It is very confusing to see a box "security protocol" within the host of
> the member, but similar box is found missing in the GCKS host. What is the
> function of the box "security protocol"? Is it a parsing function of the
> group key management protocols? Or is this the "Data Security Protocol"
> function, which I understood not part of the group key management
> architecture directly?

It is data security protocol.  We will make the correction in the next 
version.  Thanks.

> - Shouldn't GCKS host computer provide a "security protocol" box and
> attached SAD/SPD too?
> In this case, hardly any difference would remain between the GCKS and the
> member functional components and the entire figure might be simplified.
> - What is the function of "GKM"?
> - What is the work split between "GKM", "Security Protocol"  and "CONTROL"
> box? How do these boxes interact in terms during the procession of the group
> key management protocols?
> - The member host shows SAD and SPD attached to the "GKM" and to the
> "Security Protocol" box. It is intentional that these be separate stores?

I believe they are logical function blocks.  We are not (cannot) 
dictating how to implement them in real systems.

> - Figure 1 shows also interaction with external components such as
> policy/authorization infrastructure. It is not shown in Figure 2 how such
> external components interface with the building blocks.
> - CONTROL on one hand is described as a function which is fine but on the
> other hand as a telephony signalling protocol (SIP) which sounds strange. I
> would roughly understand this intuitively something as "SIP signalling
> protocol being terminated by a CONTROL function". Is that the intention? If
> that is the case, then there should be CONTROL <-- SIP --> CONTROL
> communication too, although such communication arcs would leave/enter the
> outer dashed box.
> 
> 
> Some other observations:
> 
> Figure 1 is subtitled " Group Security Association Model", yet the figure
> actually shows only protocols but not any SAs. Thus, I would subtitle the
> figure more as "Group Security Protocol Architecture".
> I could imagine a similar different figure that shows a mapping of the
> various SAs to the security protocols.

Agreed.  We will make this change as well.

> 
> 
> While the GKMA document focuses on the protocol view with the registration
> and re-key protocol, I would like to see some considerations given how
> typical multicast applications can make use of these atomic protocols for
> performing tasks like
> - GCKS adds/removes one or more group member(s),
> - Join/leave of a member.

The short answer is that we intentionally left these parts out of the 
I-D (please see the discussion on deregistration in the mailing list's 
archive :-)).

best,
Lakshminath

> - Are there other typical "higher-layer" operations (which?) that could be
> realized through the GKM protocols (how?) ?
> 
> 
> With kind regards
> 
> 
> Martin Euchner.
> -----------------------------------------------------------------------
> | Dipl.-Inf.                     Rapporteur Q.G/SG16
> | Martin Euchner                 Phone: +49 89 722 55790
> | Siemens AG.....................Fax  : +49 89 722 62366
> | 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  Mon Nov  4 19:14:26 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15768
	for <msec-archive@lists.ietf.org>; Mon, 4 Nov 2002 19:14:26 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id A949D5369E; Mon,  4 Nov 2002 19:16:22 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 7E13C5359E
	for <msec@lists.securemulticast.org>; Mon,  4 Nov 2002 19:15:00 -0500 (EST)
Received: (qmail 87267 invoked by uid 3269); 5 Nov 2002 00:15:00 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 87258 invoked from network); 5 Nov 2002 00:15:00 -0000
Received: from sj-msg-core-3.cisco.com (171.70.157.152)
  by klesh.pair.com with SMTP; 5 Nov 2002 00:15:00 -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 gA50EbxF016112;
	Mon, 4 Nov 2002 16:14:37 -0800 (PST)
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 gA50Ehkw006843;
	Mon, 4 Nov 2002 16:14:44 -0800 (PST)
Received: from cscoamera13263.cisco.com (sjc-vpn3-395.cisco.com [10.21.65.139]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA20623; Mon, 4 Nov 2002 16:14:41 -0800 (PST)
Message-Id: <5.1.1.5.2.20021104161306.02ebff80@agora.rdrop.com>
X-Sender: mbaugher@mira-sjc5-6.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
To: Lakshminath Dondeti <ldondeti@nortelnetworks.com>
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: [MSEC] gkmarch-03: host computer block diagram unclear
Cc: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>,
        msec@securemulticast.org
In-Reply-To: <3DC6C51E.4000607@nortelnetworks.com>
References: <DA6599EBFD6CF042B0B77964CFF62095C9AD6B@mchh162e.mch4.siemens.de>
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, 04 Nov 2002 16:14:40 -0800

At 02:06 PM 11/4/2002 -0500, Lakshminath Dondeti wrote:
>Hi,
>
>I will try and answer some of your questions below.
>
>Euchner Martin ICN M SR 3 wrote:
>>Folks,
>>Figure 2 shows a block diagram for a host computer. To me, this figure is
>>pretty confusing for the following reasons:
>>- Actually, I'm assuming that the figure shows two host computers: one host
>>computer for the GCKS and another one for the group member.
>>- The figure shows various arrows; some appear labelled as group key
>>management protocols (Reg, Rek), while many others are unlabeled. I'm
>>assuming that the latter ones be just internal communication
>>interfaces/APIs?
>>- It is very confusing to see a box "security protocol" within the host of
>>the member, but similar box is found missing in the GCKS host. What is the
>>function of the box "security protocol"? Is it a parsing function of the
>>group key management protocols? Or is this the "Data Security Protocol"
>>function, which I understood not part of the group key management
>>architecture directly?
>
>It is data security protocol.  We will make the correction in the next 
>version.  Thanks.
>
>>- Shouldn't GCKS host computer provide a "security protocol" box and
>>attached SAD/SPD too?
>>In this case, hardly any difference would remain between the GCKS and the
>>member functional components and the entire figure might be simplified.
>>- What is the function of "GKM"?
>>- What is the work split between "GKM", "Security Protocol"  and "CONTROL"
>>box? How do these boxes interact in terms during the procession of the group
>>key management protocols?
>>- The member host shows SAD and SPD attached to the "GKM" and to the
>>"Security Protocol" box. It is intentional that these be separate stores?
>
>I believe they are logical function blocks.  We are not (cannot) dictating 
>how to implement them in real systems.
>
>>- Figure 1 shows also interaction with external components such as
>>policy/authorization infrastructure. It is not shown in Figure 2 how such
>>external components interface with the building blocks.
>>- CONTROL on one hand is described as a function which is fine but on the
>>other hand as a telephony signalling protocol (SIP) which sounds strange. I
>>would roughly understand this intuitively something as "SIP signalling
>>protocol being terminated by a CONTROL function". Is that the intention? If
>>that is the case, then there should be CONTROL <-- SIP --> CONTROL
>>communication too, although such communication arcs would leave/enter the
>>outer dashed box.
>>
>>Some other observations:
>>Figure 1 is subtitled " Group Security Association Model", yet the figure
>>actually shows only protocols but not any SAs. Thus, I would subtitle the
>>figure more as "Group Security Protocol Architecture".
>>I could imagine a similar different figure that shows a mapping of the
>>various SAs to the security protocols.
>
>Agreed.  We will make this change as well.

I think this is explained in that there is a security association that 
protects each of the three protocols.



>>While the GKMA document focuses on the protocol view with the registration
>>and re-key protocol, I would like to see some considerations given how
>>typical multicast applications can make use of these atomic protocols for
>>performing tasks like
>>- GCKS adds/removes one or more group member(s),
>>- Join/leave of a member.
>
>The short answer is that we intentionally left these parts out of the I-D 
>(please see the discussion on deregistration in the mailing list's archive 
>:-)).
>
>best,
>Lakshminath
>
>>- Are there other typical "higher-layer" operations (which?) that could be
>>realized through the GKM protocols (how?) ?

It's just key management.

regards, Mark


>>With kind regards
>>
>>Martin Euchner.
>>-----------------------------------------------------------------------
>>| Dipl.-Inf.                     Rapporteur Q.G/SG16
>>| Martin Euchner                 Phone: +49 89 722 55790
>>| Siemens AG.....................Fax  : +49 89 722 62366
>>| 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


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


From msec-admin@securemulticast.org  Tue Nov  5 06:12:25 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11503
	for <msec-archive@lists.ietf.org>; Tue, 5 Nov 2002 06:12:25 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 8A8C95385B; Tue,  5 Nov 2002 06:14:13 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 463045385B
	for <msec@lists.securemulticast.org>; Tue,  5 Nov 2002 06:12:41 -0500 (EST)
Received: (qmail 51947 invoked by uid 3269); 5 Nov 2002 11:12:41 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 51944 invoked from network); 5 Nov 2002 11:12:41 -0000
Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176)
  by klesh.pair.com with SMTP; 5 Nov 2002 11:12:40 -0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11114;
	Tue, 5 Nov 2002 06:10:11 -0500 (EST)
Message-Id: <200211051110.GAA11114@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: msec@securemulticast.org
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: [MSEC] I-D ACTION:draft-ietf-msec-mikey-05.txt
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, 05 Nov 2002 06:10:11 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multicast Security Working Group of the IETF.

	Title		: MIKEY: Multimedia Internet KEYing
	Author(s)	: J. Arkko et al.
	Filename	: draft-ietf-msec-mikey-05.txt
	Pages		: 53
	Date		: 2002-11-4
	
Security protocols for real-time multimedia applications have started
to appear. This has brought forward the need for a key management
solution to support these protocols. Such a solution has to be
suitable to be used in the context of conversational multimedia in a
heterogeneous environment.
This document describes a key management scheme that can be used for
real-time applications (both for peer-to-peer communication and group
communication), and shows how it may work together with protocols
such as SIP and RTSP. In particular, its use to support the Secure
Real-time Transport Protocol, [SRTP], is described in detail.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-msec-mikey-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-msec-mikey-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-11-4172350.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-msec-mikey-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-msec-mikey-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-11-4172350.I-D@ietf.org>

--OtherAccess--

--NextPart--



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


From msec-admin@securemulticast.org  Wed Nov  6 05:10:17 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10595
	for <msec-archive@lists.ietf.org>; Wed, 6 Nov 2002 05:10:16 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 85DCF53549; Wed,  6 Nov 2002 05:12:14 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 2935353547
	for <msec@lists.securemulticast.org>; Wed,  6 Nov 2002 05:10:24 -0500 (EST)
Received: (qmail 27577 invoked by uid 3269); 6 Nov 2002 10:10:24 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 27574 invoked from network); 6 Nov 2002 10:10:23 -0000
Received: from goliath.siemens.de (192.35.17.28)
  by klesh.pair.com with SMTP; 6 Nov 2002 10:10:23 -0000
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA6AAMr15391
	for <msec@securemulticast.org>; Wed, 6 Nov 2002 11:10:22 +0100 (MET)
Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237])
	by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id gA6AALB08161
	for <msec@securemulticast.org>; Wed, 6 Nov 2002 11:10:21 +0100 (MET)
Received: from mhpaba5c (mhpaba5c [139.23.204.46])
		by mail-k.mchp.siemens.de with ESMTP id gA6AAP5V019309
		for <msec@securemulticast.org>; Wed, 6 Nov 2002 11:10:25 +0100 (MET)
From: "Steffen Fries" <steffen.fries@siemens.com>
Organization: Siemens AG
To: msec@securemulticast.org
MIME-Version: 1.0
Reply-To: steffen.fries@siemens.com
Message-ID: <3DC8F899.3647.39CB0EE@localhost>
Priority: normal
X-mailer: Pegasus Mail for Windows (v4.02a)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Subject: [MSEC] MIKEY - SRTP Interaction
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, 06 Nov 2002 11:10:17 +0100
Content-Transfer-Encoding: 7BIT

Hi,

I've got a question to the interworking of MIKEY and SRTP. 

In SRTP section 9.1 it is recommended that RTP senders on 
different hosts not use the same master key to send RTP data. 

From the MIKEY perspective this (the SRTP master key) relates 
to the TEK according to MIKEY Appendix A. 

This means, that from an initiators perspective for a voice 
connection between two entities two TEKs are necessary, one for 
sending RTP packets, one for receiving.

How is the signaling, which TEK is used for which direction 
being done? My assumption is, that the SSRC may be used for 
this, but I'm not quite sure how. MIKEY exchanges the TGK, from 
which the TEKs are derived loacally. There needs to be a 
mapping between the different TEKs generated and the streams to 
which they are applied. Could somebody please explain this 
mapping?

Regards
	Steffen




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


From msec-admin@securemulticast.org  Wed Nov  6 07:10:18 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14536
	for <msec-archive@lists.ietf.org>; Wed, 6 Nov 2002 07:10:18 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 0D0D2535A0; Wed,  6 Nov 2002 07:12:14 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 44D4F5354C
	for <msec@lists.securemulticast.org>; Wed,  6 Nov 2002 07:10:14 -0500 (EST)
Received: (qmail 37977 invoked by uid 3269); 6 Nov 2002 12:10:14 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 37968 invoked from network); 6 Nov 2002 12:10:13 -0000
Received: from penguin-ext.wise.edt.ericsson.se (HELO penguin.wise.edt.ericsson.se) (193.180.251.47)
  by klesh.pair.com with SMTP; 6 Nov 2002 12:10:13 -0000
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA6CAAQ1028558;
	Wed, 6 Nov 2002 13:10:10 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <WJZXG42M>; Wed, 6 Nov 2002 13:10:10 +0100
Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D028386FB@Esealnt877.al.sw.ericsson.se>
From: "Elisabetta Carrara (EAB)" <Elisabetta.Carrara@era.ericsson.se>
To: "'steffen.fries@siemens.com'" <steffen.fries@siemens.com>,
        msec@securemulticast.org
Cc: "Fredrik Lindholm (EAB)" <Fredrik.Lindholm@era.ericsson.se>
Subject: RE: [MSEC] MIKEY - SRTP Interaction
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
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, 6 Nov 2002 13:10:06 +0100


Hi Steffen.

With one common TGK, the differentiation is done 
in the TEK derivation process. Section 4.1.4: you input 
cs_id, the crypto session id. Note that the cs_id is 
defined by the mapping in 6.1.1. for SRTP (where each 
policy, ssrc & roc are mapped to a specific cs_id).  

In the new version of MIKEY that was published yesterday,
we actually tried to make this more clear.

cheers
 

> -----Original Message-----
> From: Steffen Fries [mailto:steffen.fries@siemens.com]
> Sent: den 6 november 2002 11:10
> To: msec@securemulticast.org
> Subject: [MSEC] MIKEY - SRTP Interaction
> 
> 
> Hi,
> 
> I've got a question to the interworking of MIKEY and SRTP. 
> 
> In SRTP section 9.1 it is recommended that RTP senders on 
> different hosts not use the same master key to send RTP data. 
> 
> From the MIKEY perspective this (the SRTP master key) relates 
> to the TEK according to MIKEY Appendix A. 
> 
> This means, that from an initiators perspective for a voice 
> connection between two entities two TEKs are necessary, one for 
> sending RTP packets, one for receiving.
> 
> How is the signaling, which TEK is used for which direction 
> being done? My assumption is, that the SSRC may be used for 
> this, but I'm not quite sure how. MIKEY exchanges the TGK, from 
> which the TEKs are derived loacally. There needs to be a 
> mapping between the different TEKs generated and the streams to 
> which they are applied. Could somebody please explain this 
> mapping?
> 
> Regards
> 	Steffen
> 
> 
> 
> 
> _______________________________________________
> 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  Wed Nov  6 07:38:50 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15417
	for <msec-archive@lists.ietf.org>; Wed, 6 Nov 2002 07:38:49 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 8A57A5354E; Wed,  6 Nov 2002 07:40:02 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 01DDE5354E
	for <msec@lists.securemulticast.org>; Wed,  6 Nov 2002 07:38:02 -0500 (EST)
Received: (qmail 40748 invoked by uid 3269); 6 Nov 2002 12:38:01 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 40745 invoked from network); 6 Nov 2002 12:38:01 -0000
Received: from goliath.siemens.de (192.35.17.28)
  by klesh.pair.com with SMTP; 6 Nov 2002 12:38:01 -0000
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA6Cc0827327;
	Wed, 6 Nov 2002 13:38:00 +0100 (MET)
Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237])
	by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id gA6Cc0B18078;
	Wed, 6 Nov 2002 13:38:00 +0100 (MET)
Received: from mhpaba5c (mhpaba5c [139.23.204.46])
		by mail-k.mchp.siemens.de with ESMTP id gA6Cc45V021002;
		Wed, 6 Nov 2002 13:38:04 +0100 (MET)
From: "Steffen Fries" <steffen.fries@siemens.com>
Organization: Siemens AG
To: "Elisabetta Carrara (EAB)" <Elisabetta.Carrara@era.ericsson.se>
MIME-Version: 1.0
Subject: RE: [MSEC] MIKEY - SRTP Interaction
Reply-To: steffen.fries@siemens.com
Cc: msec@securemulticast.org
Message-ID: <3DC91B34.22907.423DC0C@localhost>
Priority: normal
In-reply-to: <4E85E49D1F0CBF4F96EA08E335750D7D028386FB@Esealnt877.al.sw.ericsson.se>
X-mailer: Pegasus Mail for Windows (v4.02a)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
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, 06 Nov 2002 13:37:56 +0100
Content-Transfer-Encoding: 7BIT

Hi Elisabetta,

> With one common TGK, the differentiation is done 
> in the TEK derivation process. Section 4.1.4: you input 
> cs_id, the crypto session id. Note that the cs_id is 
> defined by the mapping in 6.1.1. for SRTP (where each 
> policy, ssrc & roc are mapped to a specific cs_id).  

Just to sumarize it for myself, both sides calculate the TEKs, 
where the CD ID is also an input parameter for the PRF. Each 
entity is now able to associate the SSRC delivered in the CS ID 
map info field to a dedicated CS ID. Since the i-th SSRC will 
have the CS ID equeal to i one can associate the TEK to the 
SSRC. Is this right?

Ciao
	Steffen

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


From msec-admin@securemulticast.org  Wed Nov  6 08:02:17 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16075
	for <msec-archive@lists.ietf.org>; Wed, 6 Nov 2002 08:02:16 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 8C4EA5364B; Wed,  6 Nov 2002 08:04:13 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 36DDE53644
	for <msec@lists.securemulticast.org>; Wed,  6 Nov 2002 08:03:34 -0500 (EST)
Received: (qmail 42819 invoked by uid 3269); 6 Nov 2002 13:03:34 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 42816 invoked from network); 6 Nov 2002 13:03:33 -0000
Received: from penguin-ext.wise.edt.ericsson.se (HELO penguin.wise.edt.ericsson.se) (193.180.251.47)
  by klesh.pair.com with SMTP; 6 Nov 2002 13:03:33 -0000
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA6D3XQ1014862;
	Wed, 6 Nov 2002 14:03:33 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <WJZXH1XY>; Wed, 6 Nov 2002 14:03:33 +0100
Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D02838700@Esealnt877.al.sw.ericsson.se>
From: "Elisabetta Carrara (EAB)" <Elisabetta.Carrara@era.ericsson.se>
To: "'steffen.fries@siemens.com'" <steffen.fries@siemens.com>
Cc: msec@securemulticast.org,
        "Fredrik Lindholm (EAB)" <Fredrik.Lindholm@era.ericsson.se>
Subject: RE: [MSEC] MIKEY - SRTP Interaction
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
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, 6 Nov 2002 14:03:27 +0100

correct



> -----Original Message-----
> From: Steffen Fries [mailto:steffen.fries@siemens.com]
> Sent: den 6 november 2002 13:38
> To: Elisabetta Carrara (EAB)
> Cc: msec@securemulticast.org
> Subject: RE: [MSEC] MIKEY - SRTP Interaction
> 
> 
> Hi Elisabetta,
> 
> > With one common TGK, the differentiation is done 
> > in the TEK derivation process. Section 4.1.4: you input 
> > cs_id, the crypto session id. Note that the cs_id is 
> > defined by the mapping in 6.1.1. for SRTP (where each 
> > policy, ssrc & roc are mapped to a specific cs_id).  
> 
> Just to sumarize it for myself, both sides calculate the TEKs, 
> where the CD ID is also an input parameter for the PRF. Each 
> entity is now able to associate the SSRC delivered in the CS ID 
> map info field to a dedicated CS ID. Since the i-th SSRC will 
> have the CS ID equeal to i one can associate the TEK to the 
> SSRC. Is this right?
> 
> Ciao
> 	Steffen
> 

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


From msec-admin@securemulticast.org  Wed Nov  6 16:54:24 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14260
	for <msec-archive@lists.ietf.org>; Wed, 6 Nov 2002 16:54:24 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 6FE90538C9; Wed,  6 Nov 2002 16:53:29 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id CC4605354C
	for <msec@lists.securemulticast.org>; Wed,  6 Nov 2002 14:51:08 -0500 (EST)
Received: (qmail 17250 invoked by uid 3269); 6 Nov 2002 19:51:08 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 17247 invoked from network); 6 Nov 2002 19:51:08 -0000
Received: from igw3.watson.ibm.com (198.81.209.18)
  by klesh.pair.com with SMTP; 6 Nov 2002 19:51:08 -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 gA6Jp7d11490;
	Wed, 6 Nov 2002 14:51:07 -0500
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 gA6Jp7j30584;
	Wed, 6 Nov 2002 14:51:07 -0500
Received: (from canetti@localhost)
	by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id OAA38484;
	Wed, 6 Nov 2002 14:51:07 -0500
From: Ran Canetti <canetti@watson.ibm.com>
Message-Id: <200211061951.OAA38484@ornavella.watson.ibm.com>
To: msec@securemulticast.org
Cc: thardjono@yahoo.com
Subject: [MSEC] Call for agenda items for the Atlanta meeting
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, 6 Nov 2002 14:51:07 -0500


Folks,

Msec will be meeting in Atlanta between 9-11:30 AM on Tuesday, 
November 19, 2002. Please send suggestions for agenda items to Thomas 
and myself asap.

Best,

Ran


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


From msec-admin@securemulticast.org  Wed Nov  6 21:38:53 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20981
	for <msec-archive@lists.ietf.org>; Wed, 6 Nov 2002 21:38:51 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 10397535D5; Wed,  6 Nov 2002 21:40:49 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id A7FA153569
	for <msec@lists.securemulticast.org>; Wed,  6 Nov 2002 21:38:21 -0500 (EST)
Received: (qmail 77150 invoked by uid 3269); 7 Nov 2002 02:38:21 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 77147 invoked from network); 7 Nov 2002 02:38:21 -0000
Received: from smtp012.mail.yahoo.com (216.136.173.32)
  by klesh.pair.com with SMTP; 7 Nov 2002 02:38:21 -0000
Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Nov 2002 02:38:20 -0000
Message-Id: <5.0.0.25.2.20021106150028.022fce58@pop.mail.yahoo.com>
X-Sender: thardjono@pop.mail.yahoo.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: msec@securemulticast.org
From: Thomas Hardjono <thardjono@yahoo.com>
Cc: canetti@watson.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [MSEC] Tentative agenda for MSEC at IETF55
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, 06 Nov 2002 21:38:17 -0500


Folks,

Here is a tentative Agenda for the MSEC WG meeting at IETF55 in
Atlanta, GA (Nov 002):

    - Review of WG status (T. Hardjono/R. Canetti)
    - Key Management Architecture doc (L. Dondeti/M. Baugher)
    - MIKEY (F. Lindholm/E. Carrara)
    - IPsec signatures (B. Weis)
    - A/MESP draft (M. Baugher)
    - TESLA draft (R. Canetti)
    - GDOI update (B. Weis/L. Dondeti)
    - MSEC Architecture doc (T. Hardjono)
    - Discussion: Last call items

Please email Ran/Thomas for corrections/additions.


Note that MSEC will meet on:

	TUESDAY, November 19, 2002
	0900-1130 Morning Sessions

Regards

Ran/Thomas
----------


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


From msec-admin@securemulticast.org  Wed Nov  6 22:56:47 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22682
	for <msec-archive@lists.ietf.org>; Wed, 6 Nov 2002 22:56:47 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 4D821537F2; Wed,  6 Nov 2002 22:56:46 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 7B4DC535A3
	for <msec@lists.securemulticast.org>; Wed,  6 Nov 2002 22:55:58 -0500 (EST)
Received: (qmail 85241 invoked by uid 3269); 7 Nov 2002 03:55:58 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 85238 invoked from network); 7 Nov 2002 03:55:58 -0000
Received: from igw3.watson.ibm.com (198.81.209.18)
  by klesh.pair.com with SMTP; 7 Nov 2002 03:55:58 -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 gA73tdd03226;
	Wed, 6 Nov 2002 22:55:39 -0500
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 gA73tcj38256;
	Wed, 6 Nov 2002 22:55:38 -0500
Received: (from canetti@localhost)
	by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id WAA35668;
	Wed, 6 Nov 2002 22:55:38 -0500
From: Ran Canetti <canetti@watson.ibm.com>
Message-Id: <200211070355.WAA35668@ornavella.watson.ibm.com>
To: ldondeti@nortelnetworks.com, mbaugher@cisco.com
Subject: Re: [MSEC] MESP: The order of security primitives and some  more questions...
Cc: Martin.Euchner@icn.siemens.de, msec@securemulticast.org,
        sfluhrer@cisco.com
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, 6 Nov 2002 22:55:38 -0500

> From msec-admin@securemulticast.org Mon Nov  4 11:20:54 2002
> 
> Why not make the SrA always an INT?  Thus we will have SrA, GC followed 
> by GA, which makes it easy to understand, analyze and implement. 
> Besides, SrA, even if it is TESLA is more expensive than GA anyway.
> 
> Or perhaps, GC, SrA, GA is better considering delayed and probabilistic 
> authentication by some source authentication schemes.  This limits the 
> DoS attacks to consuming just buffer space; why decrypt until we know 
> that the packets are legitimate.  We lose non-repudiation (not provided 
> by TESLA, but the hash chaining schemes support it)  in this case, however.
> 
> The different options bother me, I am hoping we can avoid that.
> 
> cheers,
> Lakshminath
> 

Lakshminath,

There are a couple good reasons to do TESLA on the ciphertext rather than
on the plaintext:
1. On the receiving end, it is best to do the TESLA processing as 
early as possible from the moment the packet is received, to minimize 
the delay in revealing the key, and consequently the buffer size.
2. In general authenticating the ciphertext provides better security
(as far as authentication is concerned) than authenticating 
the plaintext.

On the other hand, for the purpose of non-repudiation, the signature-based
SrA methods are better applies to the plaintext, rather than the
ciphertext.



However, I totally agree with your aversion towards options.
In fact, in case we decide we don't care about non-repudiation then 
I see no reason not to do what you suggest - i.e., GA[SrA[ENC[DATA]]].
And I'm not sure we should worry too much about non-repudiation,
at least not in the network layer...

What do people say.

Ran


 


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


From msec-admin@securemulticast.org  Thu Nov  7 10:22:41 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27857
	for <msec-archive@lists.ietf.org>; Thu, 7 Nov 2002 10:22:39 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id E526153830; Thu,  7 Nov 2002 10:24:36 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 8DABB536CF
	for <msec@lists.securemulticast.org>; Thu,  7 Nov 2002 10:22:51 -0500 (EST)
Received: (qmail 62378 invoked by uid 3269); 7 Nov 2002 15:22:51 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 62375 invoked from network); 7 Nov 2002 15:22:51 -0000
Received: from smtp014.mail.yahoo.com (216.136.173.58)
  by klesh.pair.com with SMTP; 7 Nov 2002 15:22:51 -0000
Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Nov 2002 15:22:50 -0000
Message-Id: <5.0.0.25.2.20021107101646.037d5408@pop.mail.yahoo.com>
X-Sender: thardjono@pop.mail.yahoo.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: msec@securemulticast.org
From: Thomas Hardjono <thardjono@yahoo.com>
Cc: canetti@watson.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [MSEC] Tentative agenda for MSEC at IETF55 (as on today Nov/7)
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, 07 Nov 2002 10:22:47 -0500


Folks,

Here is a tentative Agenda as of (today Nov/7) for the MSEC WG meeting at 
IETF55 in Atlanta, GA (Nov 002).

Please email Ran/Thomas for corrections/additions.


MSEC WG Meeting at IETF55
-------------------------

    - Review of WG status (T. Hardjono/R. Canetti)
    - Key Management Architecture doc (L. Dondeti/M. Baugher)
    - MIKEY (F. Lindholm/E. Carrara)
    - MIKEY-DHHMAC (M. Euchner)
    - IPsec signatures (B. Weis)
    - A/MESP draft (M. Baugher)
    - TESLA draft (R. Canetti)
    - GDOI update (B. Weis/L. Dondeti)
    - MSEC Architecture doc (T. Hardjono)
    - Discussion: Last call items


Note that MSEC will meet on:

	TUESDAY, November 19, 2002
	0900-1130 Morning Sessions

Regards

Ran/Thomas
----------


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


From msec-admin@securemulticast.org  Fri Nov  8 04:52:49 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11708
	for <msec-archive@lists.ietf.org>; Fri, 8 Nov 2002 04:52:49 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 3FA09538AF; Fri,  8 Nov 2002 04:54:28 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 18E7F53552
	for <msec@lists.securemulticast.org>; Fri,  8 Nov 2002 04:53:21 -0500 (EST)
Received: (qmail 7610 invoked by uid 3269); 8 Nov 2002 09:53:21 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 7607 invoked from network); 8 Nov 2002 09:53:20 -0000
Received: from gorilla.mchh.siemens.de (194.138.158.18)
  by klesh.pair.com with SMTP; 8 Nov 2002 09:53:20 -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 KAA18596
	for <msec@securemulticast.org>; Fri, 8 Nov 2002 10:53:17 +0100 (MET)
Received: from mchh168e.mch4.siemens.de ([139.21.130.175])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA02402
	for <msec@securemulticast.org>; Fri, 8 Nov 2002 10:53:18 +0100 (MET)
Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <4YDF52Z2>; Fri, 8 Nov 2002 10:53:18 +0100
Message-ID: <DA6599EBFD6CF042B0B77964CFF62095C9AD99@mchh162e.mch4.siemens.de>
From: Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
To: "'msec@securemulticast.org'" <msec@securemulticast.org>,
        Euchner Martin ICN M SR 3 <Martin.Euchner@icn.siemens.de>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [MSEC] elliptic-curve cryptography in 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: Fri, 8 Nov 2002 10:53:17 +0100

Dear experts,

MIKEY-05 and MIKEY-DHMAC-00 currently deploy classical RSA/Diffie-Hellman
asymmetric cryptographic operations but do not deploy ECC.

Nevertheless, it is well known that ECC yields significant performance
improvements with shorter key material while at the same time it is widely
believed that ECC preserves a comparable security level as least as good as
the "classical" mod p RSA/DH cryptography. The gains become particularly
attractive for long and very long primes (>= 1024 bit).

I believe that ECC techniques are particularly attractive in multimedia key
management protocols for secure real-time multimedia applications as under
scope of MIKEY.
Thus, I see gains in the MIKEY key management protocols when deploying ECC
techniques for digital signatures (MIKEY) and/or for DH operations (MIKEY,
~DHHMAC).

I would like to hear if there is interest and/or support for that and
whether it is considered worthwhile to enhance MIKEY protocols by ECC
techniques as an extension?


With kind regards


Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 62366
| 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  Fri Nov  8 05:16:03 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12159
	for <msec-archive@lists.ietf.org>; Fri, 8 Nov 2002 05:16:02 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id CC83A538BA; Fri,  8 Nov 2002 05:18:01 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 3758D538BA
	for <msec@lists.securemulticast.org>; Fri,  8 Nov 2002 05:16:07 -0500 (EST)
Received: (qmail 9175 invoked by uid 3269); 8 Nov 2002 10:16:07 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 9172 invoked from network); 8 Nov 2002 10:16:06 -0000
Received: from goliath.siemens.de (192.35.17.28)
  by klesh.pair.com with SMTP; 8 Nov 2002 10:16:06 -0000
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA8AG5U27790
	for <msec@securemulticast.org>; Fri, 8 Nov 2002 11:16:05 +0100 (MET)
Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237])
	by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id gA8AG5B19744
	for <msec@securemulticast.org>; Fri, 8 Nov 2002 11:16:05 +0100 (MET)
Received: from mhpaba5c (mhpaba5c [139.23.204.46])
		by mail-k.mchp.siemens.de with ESMTP id gA8AG95V019752
		for <msec@securemulticast.org>; Fri, 8 Nov 2002 11:16:09 +0100 (MET)
From: "Steffen Fries" <steffen.fries@siemens.com>
Organization: Siemens AG
To: msec@securemulticast.org
MIME-Version: 1.0
Reply-To: steffen.fries@siemens.com
Message-ID: <3DCB9CEF.11819.5DD8259@localhost>
Priority: normal
X-mailer: Pegasus Mail for Windows (v4.02a)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Subject: [MSEC] SRTP/SRTCP key management parameter
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, 08 Nov 2002 11:15:59 +0100
Content-Transfer-Encoding: 7BIT

Hi,

in the current SRTP draft, section 8.2 describes the parameter, 
which need to be supplied by key management. Within the list 
the SRTCP index is mentioned. I was wondering why it is 
necessary to transmit this values, since in section it is 
stated that this value is set to zero before the first SRTCP 
packet is sent. The index is incremented by one and after a re-
key, the SRTCP it is not reset to zero.

Why is it necessary that the key management may provide this 
parameter, when the value is already determined?

Regards
   Steffen

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


From msec-admin@securemulticast.org  Fri Nov  8 05:46:27 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12585
	for <msec-archive@lists.ietf.org>; Fri, 8 Nov 2002 05:46:26 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 19DC4538BD; Fri,  8 Nov 2002 05:48:26 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 73689535E8
	for <msec@lists.securemulticast.org>; Fri,  8 Nov 2002 05:47:45 -0500 (EST)
Received: (qmail 12582 invoked by uid 3269); 8 Nov 2002 10:47:45 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 12579 invoked from network); 8 Nov 2002 10:47:45 -0000
Received: from thoth.sbs.de (192.35.17.2)
  by klesh.pair.com with SMTP; 8 Nov 2002 10:47:45 -0000
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id gA8Alhv20914
	for <msec@securemulticast.org>; Fri, 8 Nov 2002 11:47:44 +0100 (MET)
Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237])
	by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id gA8AlhB20281
	for <msec@securemulticast.org>; Fri, 8 Nov 2002 11:47:43 +0100 (MET)
Received: from mhpaba5c (mhpaba5c [139.23.204.46])
		by mail-k.mchp.siemens.de with ESMTP id gA8Alm5V020109
		for <msec@securemulticast.org>; Fri, 8 Nov 2002 11:47:48 +0100 (MET)
From: "Steffen Fries" <steffen.fries@siemens.com>
Organization: Siemens AG
To: msec@securemulticast.org
MIME-Version: 1.0
Reply-To: steffen.fries@siemens.com
Message-ID: <3DCBA45A.10186.5FA7B4E@localhost>
Priority: normal
X-mailer: Pegasus Mail for Windows (v4.02a)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Subject: [MSEC] MIKEY key data transport
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, 08 Nov 2002 11:47:38 +0100
Content-Transfer-Encoding: 7BIT

Hi,

hope it is not a beancounter question ;-)

Section 6.2 of the MIKEY draft states the length of the 
encrypted data with 16 bit. The encrypted data itself is the 
key data sub payload (section 6.13), which also consists of two 
length information field. Both length fields have a size of 16 
bit too.
When someone tries to use the use these fields to the full 
extent, the payload will not fit into the KEMAC payload.
I'm not sure if this can really happen. The remark is more 
regarding consistency.

Regards
	Steffen



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


From msec-admin@securemulticast.org  Fri Nov  8 11:46:44 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26753
	for <msec-archive@lists.ietf.org>; Fri, 8 Nov 2002 11:46:43 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 5CEDA539D7; Fri,  8 Nov 2002 11:34:36 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 6383F5362E
	for <msec@lists.securemulticast.org>; Fri,  8 Nov 2002 10:55:36 -0500 (EST)
Received: (qmail 46257 invoked by uid 3269); 8 Nov 2002 15:55:36 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 46254 invoked from network); 8 Nov 2002 15:55:36 -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; 8 Nov 2002 15:55:36 -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 gA8FtYKV014463;
	Fri, 8 Nov 2002 16:55:34 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <WPSXYBSL>; Fri, 8 Nov 2002 16:55:30 +0100
Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D02838740@Esealnt877.al.sw.ericsson.se>
From: "Elisabetta Carrara (EAB)" <Elisabetta.Carrara@era.ericsson.se>
To: "'steffen.fries@siemens.com'" <steffen.fries@siemens.com>
Cc: msec@securemulticast.org
Subject: RE: [MSEC] SRTP/SRTCP key management parameter
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
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, 8 Nov 2002 16:46:18 +0100

Hi Steffen
the Section you mention from the SRTP draft
contains the parameters that key management _may_ 
need to supply.
We added the SRTCP index there to give the possibility,
if wanted, to better initialise the state for a new joining
member (the incoming SRTCP index might not be zero then). 
However, we could not identify any serious attack. 

cheers
/E

> -----Original Message-----
> From: Steffen Fries [mailto:steffen.fries@siemens.com]
> Sent: den 8 november 2002 11:16
> To: msec@securemulticast.org
> Subject: [MSEC] SRTP/SRTCP key management parameter
> 
> 
> Hi,
> 
> in the current SRTP draft, section 8.2 describes the parameter, 
> which need to be supplied by key management. Within the list 
> the SRTCP index is mentioned. I was wondering why it is 
> necessary to transmit this values, since in section it is 
> stated that this value is set to zero before the first SRTCP 
> packet is sent. The index is incremented by one and after a re-
> key, the SRTCP it is not reset to zero.
> 
> Why is it necessary that the key management may provide this 
> parameter, when the value is already determined?
> 
> Regards
>    Steffen
> 
> _______________________________________________
> 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 Nov  8 11:51:03 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26915
	for <msec-archive@lists.ietf.org>; Fri, 8 Nov 2002 11:51:02 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 1544353A46; Fri,  8 Nov 2002 11:41:13 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id BEE53535AC
	for <msec@lists.securemulticast.org>; Fri,  8 Nov 2002 11:20:33 -0500 (EST)
Received: (qmail 50376 invoked by uid 3269); 8 Nov 2002 16:20:33 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 50371 invoked from network); 8 Nov 2002 16:20:33 -0000
Received: from penguin-ext.wise.edt.ericsson.se (HELO penguin.wise.edt.ericsson.se) (193.180.251.47)
  by klesh.pair.com with SMTP; 8 Nov 2002 16:20:33 -0000
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA8GKWQ1007917;
	Fri, 8 Nov 2002 17:20:32 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <WPSXYGQA>; Fri, 8 Nov 2002 17:20:32 +0100
Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D02838741@Esealnt877.al.sw.ericsson.se>
From: "Elisabetta Carrara (EAB)" <Elisabetta.Carrara@era.ericsson.se>
To: "'steffen.fries@siemens.com'" <steffen.fries@siemens.com>
Cc: msec@securemulticast.org
Subject: RE: [MSEC] MIKEY key data transport
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
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, 8 Nov 2002 17:11:18 +0100

Hi again

well, I see what you mean ;o)
however, as you say, it is really improbable that it happens.

thanks, cheers
/E 

> -----Original Message-----
> From: Steffen Fries [mailto:steffen.fries@siemens.com]
> Sent: den 8 november 2002 11:48
> To: msec@securemulticast.org
> Subject: [MSEC] MIKEY key data transport
> 
> 
> Hi,
> 
> hope it is not a beancounter question ;-)
> 
> Section 6.2 of the MIKEY draft states the length of the 
> encrypted data with 16 bit. The encrypted data itself is the 
> key data sub payload (section 6.13), which also consists of two 
> length information field. Both length fields have a size of 16 
> bit too.
> When someone tries to use the use these fields to the full 
> extent, the payload will not fit into the KEMAC payload.
> I'm not sure if this can really happen. The remark is more 
> regarding consistency.
> 
> Regards
> 	Steffen
> 
> 
> 
> _______________________________________________
> 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  Mon Nov 11 15:07:18 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29559
	for <msec-archive@lists.ietf.org>; Mon, 11 Nov 2002 15:07:18 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id BF662536D1; Mon, 11 Nov 2002 15:09:20 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 18B54535A0
	for <msec@lists.securemulticast.org>; Mon, 11 Nov 2002 15:07:52 -0500 (EST)
Received: (qmail 13447 invoked by uid 3269); 11 Nov 2002 20:07:51 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 13444 invoked from network); 11 Nov 2002 20:07:51 -0000
Received: from pigeon.verisign.com (65.205.251.71)
  by klesh.pair.com with SMTP; 11 Nov 2002 20:07:51 -0000
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55])
        by pigeon.verisign.com (8.12.1/) with ESMTP id gABK7447013236;
        Mon, 11 Nov 2002 12:07:04 -0800 (PST)
Received: from THARDJONO-LAP.verisign.com (THARDJONO-LAP [10.35.42.230]) by vhqpostal-gw1.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id VPFV9KTH; Mon, 11 Nov 2002 12:07:50 -0800
Message-Id: <5.0.0.25.2.20021111150543.0255aba8@pop.mail.yahoo.com>
X-Sender: thardjono@vhqpostal3.verisign.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: msec@securemulticast.org
From: Thomas Hardjono <thardjono@verisign.com>
Cc: bew@cisco.com, thardjono@yahoo.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [MSEC] MSEC Architecture draft now on website
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, 11 Nov 2002 15:07:47 -0500


Folks,

The MSEC Architecture document is now on the website:
http://www.securemulticast.org/draft-ietf-msec-arch-00.txt

My apologies for being late (and missing the IETF55 cut-off date).

cheers,

thomas
------






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


From msec-admin@securemulticast.org  Mon Nov 11 19:01:51 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06557
	for <msec-archive@lists.ietf.org>; Mon, 11 Nov 2002 19:01:51 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 885DD536AA; Mon, 11 Nov 2002 19:03:46 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 3DCB5535AF
	for <msec@lists.securemulticast.org>; Mon, 11 Nov 2002 17:49:52 -0500 (EST)
Received: (qmail 52201 invoked by uid 3269); 11 Nov 2002 22:49:52 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 52198 invoked from network); 11 Nov 2002 22:49:52 -0000
Received: from m5.sparta.com (157.185.61.1)
  by klesh.pair.com with SMTP; 11 Nov 2002 22:49:52 -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 gABMnnlU027710
	for <msec@securemulticast.org>; Mon, 11 Nov 2002 16:49:50 -0600
Received: from LoughLaptop (dhcp-9.columbia.sparta.com [157.185.80.20])
	by columbia.sparta.com (8.9.1a/8.9.1) with SMTP id RAA05286
	for <msec@securemulticast.org>; Mon, 11 Nov 2002 17:49:47 -0500 (EST)
Message-ID: <001201c289d4$9dd02090$1450b99d@LoughLaptop>
From: "Peter Lough" <loughp@sparta.com>
To: <msec@securemulticast.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000F_01C289AA.B4615B00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: [MSEC] GSAKMP Revisons
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, 11 Nov 2002 17:49:38 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C289AA.B4615B00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

As noted previously, several changes are being made to GSAKMP =
incorporating the Original and Light protocols into one single document =
and dropping support for the original five message transaction.  This =
note will cover a few of the major areas of change in advance of the =
draft being available.

The Group ID field in the header was changed to a variable length field. =
 GSAKMP is designed to be used in IP v4 as well as IP v6 and other =
environments.  The size and format of the Group ID field was specific to =
IP v4.  Now, the Group Type used will dictate the size of the Group ID =
field.

Additionally, since this paper incorporates both GSAKMP and GSAKMP =
Light, but drops support for the original transaction, several items =
available in the tables throughout the document were no longer =
supported.  To reduce the requirements on any possible existing =
implementations, those fields that are no longer used will be marked as =
RESERVED.  For example, in GSAKMP Light Table 8: Exchange Types read:

Request to Join                     0
Invitation                               1
Invitation Response                2
Key Download                        3
Acknowledgement                  4
Rekey Event                          5
Group Removal/Destruction     6
No Message                          7
Light Request to Join              8
Light Key Download                9
Other                                    10-255

The same table is now represented in Table 8: Exchange Types as:

Reserved                              0 - 3
Notification                            4
Reserved                             5 - 6
No Message                          7
Light Request to Join             8
Light Key Download               9
Other                                   10 - 255

Note that type 4 "Acknowledgement" and "Notification" actually refer to =
the same message.  It has been renamed to more correctly indicate that =
it could be an ACK or a NACK.  Notification was the proper term.

The paper is currently under review and expected to be released in the =
near future.

Peter Lough
SPARTA, Inc.
------=_NextPart_000_000F_01C289AA.B4615B00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>As noted previously, several changes =
are being made=20
to GSAKMP incorporating the Original and Light protocols into one single =

document and dropping support for the original five message =
transaction.&nbsp;=20
This note will cover a few of the major areas of change in advance of =
the draft=20
being available.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The Group ID field in the header was =
changed to a=20
variable length field.&nbsp; GSAKMP is designed to be used in IP v4 as =
well as=20
IP v6 and other environments.&nbsp; The size and format of the Group ID =
field=20
was specific to IP v4.&nbsp; Now, the Group Type used will dictate the =
size of=20
the Group ID field.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Additionally, since this paper =
incorporates both=20
GSAKMP and GSAKMP Light, but drops support for the original transaction, =
several=20
items available in the tables throughout the document were no longer=20
supported.&nbsp; To reduce the requirements on any possible existing=20
implementations, those fields that are no longer used will be marked as=20
RESERVED.&nbsp; For example, in GSAKMP Light&nbsp;Table 8: Exchange =
Types=20
read:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Request to=20
Join&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>Invitation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
1</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Invitation=20
Response&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
2</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Key=20
Download&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
3</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>Acknowledgement&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
4</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Rekey=20
Event&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
5</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Group =
Removal/Destruction&nbsp;&nbsp;&nbsp;&nbsp;=20
6</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>No=20
Message&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
7</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Light Request to=20
Join&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
8</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Light Key=20
Download&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=20
&nbsp;9</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>Other&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
10-255</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The same table is now represented in =
Table 8:=20
Exchange Types as:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>Reserved&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
0 - 3</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>Notification&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
4</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>Reserved&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
5 - 6</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>No=20
Message&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
7</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Light Request to=20
Join&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
8</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Light Key=20
Download&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=20
9</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>Other&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

10 - 255</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Note that type 4 "Acknowledgement" and=20
"Notification" actually refer to the same message.&nbsp; It has been =
renamed to=20
more correctly indicate that it could be an ACK or a NACK.&nbsp; =
Notification=20
was the proper term.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The paper is currently under review and =
expected to=20
be released in the near future.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Peter Lough</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>SPARTA, Inc.</FONT></DIV></BODY></HTML>

------=_NextPart_000_000F_01C289AA.B4615B00--



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


From msec-admin@securemulticast.org  Tue Nov 12 05:00:57 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26251
	for <msec-archive@lists.ietf.org>; Tue, 12 Nov 2002 05:00:57 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 99D4753983; Tue, 12 Nov 2002 05:01:22 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from itsky.com.cn (unknown [211.153.20.96])
	by pairlist.net (Postfix) with ESMTP id AB4B6535DD
	for <msec@lists.securemulticast.org>; Tue, 12 Nov 2002 03:06:21 -0500 (EST)
Received: (smail 22051 invoked by uid 511); 12 Nov 2002 07:30:11 -0000
Received: from unknown (HELO lion) (free@61.48.8.23)
  by 0 with SMTP; 12 Nov 2002 07:30:11 -0000
From: "dj" <free@itsky.com.cn>
To: "msec@lists.securemulticast.org" <msec@lists.securemulticast.org>
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 7bit
Message-Id: <20021112080621.AB4B6535DD@pairlist.net>
Subject: [MSEC] (no subject)
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, 12 Nov 2002 16:6:56 +0800
Content-Transfer-Encoding: 7bit





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


From msec-admin@securemulticast.org  Tue Nov 12 05:02:47 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26296
	for <msec-archive@lists.ietf.org>; Tue, 12 Nov 2002 05:02:46 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 43C3F539B0; Tue, 12 Nov 2002 05:01:34 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id A57C6535DD
	for <msec@lists.securemulticast.org>; Tue, 12 Nov 2002 03:16:23 -0500 (EST)
Received: (qmail 14033 invoked by uid 3269); 12 Nov 2002 08:16:23 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 14030 invoked from network); 12 Nov 2002 08:16:23 -0000
Received: from rumba.cefriel.it (131.175.53.6)
  by klesh.pair.com with SMTP; 12 Nov 2002 08:16:23 -0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Message-ID: <28C92BFE6EB5C943B15743D0E11E6036056778@rumba.cefriel.it>
Thread-Index: AcKKJBYT9k9/b2h0QguFaI8NmP/VMw==
From: "Luca Venturi" <venturi@cefriel.it>
To: <msec@securemulticast.org>
Subject: [MSEC] (no subject)
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, 12 Nov 2002 09:18:31 +0100
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id FAA26296

For those who might be interested in it (and for those who understand
italian), the results of my master thesis work on the analisis of gdoi
performance are now available under this page:
http://www.cefriel.it/units/resources/default.xml?id=8&aid=4, where you can
read the abstract and download the full version.
Sadly enough, no english version is available at the moment, but I am
evaluating the chance to write some kind of article or publication in
english if there is some interest in the issue.
That's why I would like to get some feedback from you. Thanks a lot in
advance.

Best regards

Luca Venturi

�������������������������������������&j)b�	b�٬y��y˫zk��'���m����0����X���޷���Y���b�ا~��


From msec-admin@securemulticast.org  Tue Nov 12 11:54:01 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06275
	for <msec-archive@lists.ietf.org>; Tue, 12 Nov 2002 11:53:59 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id CE4BB535E4; Tue, 12 Nov 2002 11:56:02 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 2987753598
	for <msec@lists.securemulticast.org>; Tue, 12 Nov 2002 11:54:04 -0500 (EST)
Received: (qmail 75649 invoked by uid 3269); 12 Nov 2002 16:54:04 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 75645 invoked from network); 12 Nov 2002 16:54:03 -0000
Received: from pigeon.verisign.com (65.205.251.71)
  by klesh.pair.com with SMTP; 12 Nov 2002 16:54:03 -0000
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55])
        by pigeon.verisign.com (8.12.1/) with ESMTP id gACGrE47001727;
        Tue, 12 Nov 2002 08:53:15 -0800 (PST)
Received: from THARDJONO-LAP.verisign.com (THARDJONO-LAP [10.35.42.230]) by vhqpostal-gw1.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id VPFWADHH; Tue, 12 Nov 2002 08:54:01 -0800
Message-Id: <5.0.0.25.2.20021112114950.02624e08@pop.mail.yahoo.com>
X-Sender: thardjono@vhqpostal3.verisign.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: msec@securemulticast.org
From: Thomas Hardjono <thardjono@verisign.com>
Cc: canetti@watson.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [MSEC] MSEC WG Agenda at IETF55 (as of Nov/12)
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, 12 Nov 2002 11:53:59 -0500


Folks,

Here is the tentative Agenda (as of today Nov/12) for the MSEC WG meeting
at IETF55 in Atlanta.

Please email Ran/Thomas for corrections/additions.


MSEC WG Meeting at IETF55
-------------------------

    - Review of WG status (T. Hardjono/R. Canetti)
    - Key Management Architecture doc (L. Dondeti/M. Baugher)
    - MIKEY (F. Lindholm/E. Carrara)
    - MIKEY-DHHMAC (M. Euchner)
    - IPsec signatures (B. Weis)
    - A/MESP draft (M. Baugher)
    - TESLA draft (R. Canetti)
    - GDOI update (B. Weis/L. Dondeti)
    - GSAKMP Update (H. Harney)
    - MSEC Architecture doc (T. Hardjono)
    - Discussion: Last call items


Note that MSEC will meet on:

	TUESDAY, November 19, 2002
	0900-1130 Morning Sessions

Regards

Ran/Thomas
----------



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


From msec-admin@securemulticast.org  Tue Nov 12 17:15:25 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18207
	for <msec-archive@lists.ietf.org>; Tue, 12 Nov 2002 17:15:24 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 18E4F5371D; Tue, 12 Nov 2002 17:17:21 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 6115F535C2
	for <msec@lists.securemulticast.org>; Tue, 12 Nov 2002 17:14:03 -0500 (EST)
Received: (qmail 29135 invoked by uid 3269); 12 Nov 2002 22:14:03 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 29130 invoked from network); 12 Nov 2002 22:14:03 -0000
Received: from sj-msg-core-4.cisco.com (171.71.163.54)
  by klesh.pair.com with SMTP; 12 Nov 2002 22:14:03 -0000
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gACMDrNi004577;
	Tue, 12 Nov 2002 14:13:53 -0800 (PST)
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 gACMDqK4007578;
	Tue, 12 Nov 2002 14:13:52 -0800 (PST)
Received: from cisco.com (stealth-10-34-255-62.cisco.com [10.34.255.62]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA28879; Tue, 12 Nov 2002 14:13:46 -0800 (PST)
Message-ID: <3DD146A3.A1BA8254@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: Luca Venturi <venturi@cefriel.it>
Cc: msec@securemulticast.org
Subject: gdoi master thesis (was Re: [MSEC] (no subject))
References: <28C92BFE6EB5C943B15743D0E11E6036056778@rumba.cefriel.it>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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, 12 Nov 2002 10:21:23 -0800
Content-Transfer-Encoding: 8bit

Hi Luca,

I'd really appreciate seeing your findings, and there are probably
others on the MSEC list who would as well.

Thanks,
Brian

Luca Venturi wrote:
> 
> For those who might be interested in it (and for those who understand
> italian), the results of my master thesis work on the analisis of gdoi
> performance are now available under this page:
> http://www.cefriel.it/units/resources/default.xml?id=8&aid=4, where you can
> read the abstract and download the full version.
> Sadly enough, no english version is available at the moment, but I am
> evaluating the chance to write some kind of article or publication in
> english if there is some interest in the issue.
> That's why I would like to get some feedback from you. Thanks a lot in
> advance.
> 
> Best regards
> 
> Luca Venturi
> 
> s�??��Sx%S�f��,y˫zk��'��+,m����
> ZS�b��޷�sSYsY�b�ا~?�sec=

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


From msec-admin@securemulticast.org  Wed Nov 13 13:14:00 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11162
	for <msec-archive@lists.ietf.org>; Wed, 13 Nov 2002 13:13:59 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 5A3645388F; Wed, 13 Nov 2002 13:13:05 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 6B869537CD
	for <msec@lists.securemulticast.org>; Wed, 13 Nov 2002 11:31:52 -0500 (EST)
Received: (qmail 55521 invoked by uid 3269); 13 Nov 2002 16:31:52 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 55516 invoked from network); 13 Nov 2002 16:31:52 -0000
Received: from pigeon.verisign.com (65.205.251.71)
  by klesh.pair.com with SMTP; 13 Nov 2002 16:31:52 -0000
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55])
        by pigeon.verisign.com (8.12.1/) with ESMTP id gADGV347018541
        for <msec@securemulticast.org>; Wed, 13 Nov 2002 08:31:03 -0800 (PST)
Received: from THARDJONO-LAP.verisign.com (stargate.verisign.com [10.25.248.5]) by vhqpostal-gw1.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id VPFWCKBL; Wed, 13 Nov 2002 08:31:50 -0800
Message-Id: <5.0.0.25.2.20021113112943.02fb4e98@pop.mail.yahoo.com>
X-Sender: thardjono@vhqpostal3.verisign.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: msec@securemulticast.org
From: Thomas Hardjono <thardjono@verisign.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [MSEC] MSEC Agenda (as of Wed Nov/13)
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, 13 Nov 2002 11:31:47 -0500


Folks,

Here is the tentative Agenda (as of Wed Nov/13) for the MSEC WG meeting
at IETF55 in Atlanta.

Please email Ran/Thomas for corrections/additions.


MSEC WG Meeting at IETF55
-------------------------

    - Review of WG status (T. Hardjono/R. Canetti)
    - MIKEY (E. Carrara/F. Lindholm)
    - MESP draft (M. Baugher)
    - Key Management Architecture doc (L. Dondeti/M. Baugher)
    - MIKEY-DHHMAC (M. Euchner)
    - IPsec signatures (B. Weis)
    - TESLA draft (R. Canetti)
    - GDOI update (B. Weis/L. Dondeti)
    - GSAKMP Update (H. Harney)
    - MSEC Architecture doc (T. Hardjono)
    - Discussion: Last call items


Note that MSEC will meet on:

	TUESDAY, November 19, 2002
	0900-1130 Morning Sessions

Regards

Ran/Thomas
----------


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


From msec-admin@securemulticast.org  Sat Nov 16 11:04:17 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19708
	for <msec-archive@lists.ietf.org>; Sat, 16 Nov 2002 11:04:17 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id C59B153D1C; Sat, 16 Nov 2002 10:57:39 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id AB0F0537E8
	for <msec@lists.securemulticast.org>; Fri, 15 Nov 2002 15:02:43 -0500 (EST)
Received: (qmail 48235 invoked by uid 3269); 15 Nov 2002 20:02:43 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 48231 invoked from network); 15 Nov 2002 20:02:43 -0000
Received: from m5.sparta.com (157.185.61.1)
  by klesh.pair.com with SMTP; 15 Nov 2002 20:02:43 -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 gAFK22lU024700;
	Fri, 15 Nov 2002 14:02:32 -0600
Received: from robin (robin.columbia.sparta.com [157.185.80.228])
	by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA17856;
	Fri, 15 Nov 2002 15:02:00 -0500 (EST)
Message-Id: <4.2.2.20021115145148.013b9b00@pop.columbia.sparta.com>
X-Sender: hh@pop.columbia.sparta.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
To: Mark Baugher <mbaugher@cisco.com>, "Peter Lough" <loughp@sparta.com>
From: Hugh Harney <hh@sparta.com>
Subject: Re: [MSEC] GSAKMP Light Cookies
Cc: <msec@securemulticast.org>
In-Reply-To: <5.1.1.5.2.20021029123356.0210f6d0@mira-sjc5-6.cisco.com>
References: <005b01c27f5a$1c1d4660$7750b99d@SNOWBALL>
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: Fri, 15 Nov 2002 15:02:47 -0500

Mark,

I'm really sorry it took me so long to respond to you. I've been too busy.

I took some time and tried to answer your question below.

At 12:34 PM 10/29/02 -0800, Mark Baugher wrote:
>hi Peter
>   when I read that you all are incorporating additional ISAKMP features, 
> I have to ask the question:  What are the significant differentiators 
> between GSAKMP Light and GDOI?


GDOI vs GSAKMP

Mark Baugher asked about the difference between GDOI and GSAKMP recently. 
The two protocols are similar and have some overlapping functions. I think 
it would be useful to describe the similarities and differences between the 
two protocols.

Similarities

GDOI and GSAKMP are designed to be key management protocols. The 
similarities are as follows.

Secure download of key

Both GDOI and GSAKMP download a key from a Group Controller to a Group 
Member. GDOI can either download the group key under an IKE phase 1 key, or 
it can employ a key exchange to create a key encryption key to further 
protect the group key during download. GSAKMP always uses a key 
determination protocols to create a key encryption key for protection of 
the group key.

Support IPSec ESP and group membership management

Both GDOI and GSAKMP supply key and policy information necessary to set up 
IPSec ESP. Both provide group membership rekey mechanisms.

Differences

The main difference between GDOI and GSAKMP stems from the authors handling 
of security policy. GDOI specifically provides IPSec SPD policy 
information. GSAKMP provides a "policy token" as a flexible policy 
dissemination mechanism within the protocol.

The other difference stem from the requirements each protocol was designed 
to meet. GDOI was aimed at a single source broadcast requirement. GSAKMP 
was aimed at multi-application, distributed operations requirements.
Single vs. multiple data sources in a group

In peer to peer IKE both parties verify that they want to talk to each 
other. Everyone in fully knowledgeable of the security policy for that peer 
to peer SA. In a Group SA, the key is distributed from a single site. The 
members do not necessarily understand the access control policies that is 
enforced for that group. This is a problem for members that may want to 
contribute data to that group. The member has no information about who will 
get access to the data they encrypt with that group key.

GDOI assumes that the group controller (enforcer of the access control 
policy) is the only contributor of data to the group. If multiple members 
want to distribute key to the group, those members will have to get the 
access control policy from another protocol.

GSAKMP assumes that all members will need the access control parameters in 
order to trust the group key. The policy token contains an explicit 
definition of the access control policy and is distributed as part of the 
GSAKMP exchange.

Scalability

The MSEC architecture framework document, shows that distributed key 
dissemination, and access control enforcement, is desirable in a multicast 
key management protocol to support large groups.

The distribution of security functionality to facilitate scalability must 
be done in a manner that allows all group members the ability to verify the 
authority of the action. Failure to allow verification will result in the 
overall group to be vulnerable to various DoS and masquerade attacks.

GDOI uses a shadow certificate approach where distributed key dissemination 
points will all present the same authorization information to joining 
members in a group. This allow all joining members to verify that they are 
joining the correct group from an authorized keying agent. The distribution 
of these shadow certificates is undefined in the GDOI protocol. It is 
important to note that the secure distribution of these shadow certificates 
directly impact the security and trust of the group key.

GSAKMP explicitly defines the authorized distribution agents (subordinate 
group controllers) as part of the policy token. The policy token itself is 
signed by a trusted policy creation authority allowing the joining members 
a direct verification mechanism for accepting keys.

Expandability

Group security spans several cryptographic applications - multicast IPSec 
(to be sure), distributed computing applications, video audio conferencing, 
s-mime, and collaborative workspaces. Each of these applications could 
benefit from a single group key management protocol that is flexible enough 
to supply key and configuration information.

Even in the realm of IPSec there are several security protocols that may 
need key to provide a secure GSA system. Some of these other security 
protocols that are relevant to the GSA system are group source 
authentication protocols (ref: tesla, lam/wong, etc), various group 
management protocols (ref: LKH, OFC, OFT, Subset Diff), multi-layer 
encryption protocols (ref: session layer encrypt for video, app msec 
protocol). A single key and security management protocols that is flexible 
enough to support all these protocols would be a boon to security.

GDOI is tightly coupled with IPSec ESP. It provides the keys and policy 
information necessary to set up this SA for a group. Any expansion of the 
policy distribution requirements,  (for example: to support for example the 
Tesla time information), would require a modification to GDOI (addition of 
a policy payload for Tesla).

GSAKMP provides a generic policy distribution mechanism in the policy 
token. The policy token could be modified to support any number of 
different group applications without modification of the GSAKMP protocol 
itself.

Relationship to "other" protocols

Creation of a trusted group security association requires trust in all the 
security relevant events that set up that GSA. For example, you could have 
the strongest key download protocol in the world, but if the system that 
distributed the security policy is faulty the key would be "at risk". The 
point here is that trust is created when the entire system is secure, not 
just a subset of the system is secure.

GDOI is secure as specified to set up a IPSec ESP group, if the key 
dissemination point is also the sole source of data in that group. GDOI 
could use other protocols to distribute security policy to facilitate 
multiple data sources in a group. GDOI could use a certificate delegation 
protocol to delegate authority for multiple key dissemination sites in a 
group. Any support protocols used to expand the functionality of GDOI must 
be trusted the same level that GDOI is trusted. Group security is 
unfortunately, a system.

GSAKMP is largely self contained. It contains a flexible policy 
dissemination data structure that facilitates distributed architectures and 
full policy enforcement at the Group Controllers and the Group Members.





________________________________________________________
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  Sat Nov 16 11:15:09 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20008
	for <msec-archive@lists.ietf.org>; Sat, 16 Nov 2002 11:15:09 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id A193853BDB; Sat, 16 Nov 2002 11:02:42 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 9ED7453B14
	for <msec@lists.securemulticast.org>; Sat, 16 Nov 2002 10:53:32 -0500 (EST)
Received: (qmail 77979 invoked by uid 3269); 16 Nov 2002 15:53:32 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 77976 invoked from network); 16 Nov 2002 15:53:32 -0000
Received: from unknown (HELO itsky.com.cn) (211.153.20.96)
  by klesh.pair.com with SMTP; 16 Nov 2002 15:53:32 -0000
Received: (smail 18661 invoked by uid 511); 16 Nov 2002 15:16:15 -0000
Received: from unknown (HELO lion) (free@61.48.10.215)
  by 0 with SMTP; 16 Nov 2002 15:16:15 -0000
From: "dj" <free@itsky.com.cn>
To: "msec@securemulticast.org" <msec@securemulticast.org>
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 7bit
Message-Id: <20021116155332.9ED7453B14@pairlist.net>
Subject: [MSEC] give some advice
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, 16 Nov 2002 23:54:15 +0800
Content-Transfer-Encoding: 7bit

hi,
I am preparing my master thesis work on security multicast ,So could anyone give some advice on how I should begin in study of multicast Security? 
  Thanks! :-)
 li
											



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


From msec-admin@securemulticast.org  Mon Nov 18 17:43:22 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06350
	for <msec-archive@lists.ietf.org>; Mon, 18 Nov 2002 17:43:22 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id A03B95368B; Mon, 18 Nov 2002 17:45:30 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id DEC96535CE
	for <msec@lists.securemulticast.org>; Mon, 18 Nov 2002 13:12:29 -0500 (EST)
Received: (qmail 76328 invoked by uid 3269); 18 Nov 2002 18:12:29 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 76325 invoked from network); 18 Nov 2002 18:12:29 -0000
Received: from smtp015.mail.yahoo.com (216.136.173.59)
  by klesh.pair.com with SMTP; 18 Nov 2002 18:12:29 -0000
Received: from thardjono-lap.ietf55.ops.ietf.org (HELO THARDJONO-LAP.yahoo.com) (thardjono@204.42.68.173 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Nov 2002 18:12:28 -0000
Message-Id: <5.0.0.25.2.20021118130932.026dbb68@pop.mail.yahoo.com>
X-Sender: thardjono@pop.mail.yahoo.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: msec@securemulticast.org, gsec@lists.tislabs.com
From: Thomas Hardjono <thardjono@yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [MSEC] Bibliography of papers
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, 18 Nov 2002 13:12:25 -0500



Folks,

I have just uploaded a bibliography of papers related to multicast security 
and group security.
http://www.securemulticast.org/MSEC-GSEC-bib18nov02.pdf

A big thank you to Lakshminath Dondeti for providing the file.

The next plan is to link actual papers (pdf or ps) to these entries.

cheers,

thomas
------



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


From msec-admin@securemulticast.org  Tue Nov 19 07:24:54 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03139
	for <msec-archive@lists.ietf.org>; Tue, 19 Nov 2002 07:24:54 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 1FE595389A; Tue, 19 Nov 2002 07:26:50 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id DCCDB53573
	for <msec@lists.securemulticast.org>; Mon, 18 Nov 2002 15:32:22 -0500 (EST)
Received: (qmail 96609 invoked by uid 3269); 18 Nov 2002 20:32:22 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 96606 invoked from network); 18 Nov 2002 20:32:22 -0000
Received: from willow.eecs.umich.edu (141.213.4.14)
  by klesh.pair.com with SMTP; 18 Nov 2002 20:32:22 -0000
Received: from willow.eecs.umich.edu (localhost.eecs.umich.edu [127.0.0.1])
	by willow.eecs.umich.edu (8.12.2/8.12.2) with ESMTP id gAIKW3wJ029644;
	Mon, 18 Nov 2002 15:32:04 -0500
Received: from localhost (zhaoxin@localhost)
	by willow.eecs.umich.edu (8.12.2/8.12.2) with ESMTP id gAIKW3Fl029641;
	Mon, 18 Nov 2002 15:32:03 -0500
X-Authentication-Warning: willow.eecs.umich.edu: zhaoxin owned process doing -bs
From: Xin Zhao <zhaoxin@eecs.umich.edu>
To: <canetti@watson.ibm.com>
Cc: <msec@securemulticast.org>
Message-ID: <Pine.LNX.4.33.0211181530590.29578-100000@willow.eecs.umich.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [MSEC] About source authentication in many-to-many multicast scenario
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, 18 Nov 2002 15:32:03 -0500 (EST)

Hi, Ran and other researchers,
 
I am working to solve the source authentication in many-to-many multicast 
scenario, I plan to use TESLA protocol as part of solutioin. So I am 
writing to you to seek for your comments. 
 
The many-to-many multicast scenario is like this:
1) multiple members in a multicast group. 
2) some members have the right of sending messages, others don't have
3) data packets and re-key distribution packets are sent asynchronously
4) data packets are encrypted/decrypted with a single group key.
 
Because we have only one group key, everyone in the group has the ability 
of compose a packet. Receivers need to determine whether the packet 
originated from the purposed member who has appropriate data sending 
right. 
 
Current we have two choices: centralized scheme and distributed scheme. 
 
For completely distributed scheme, suppose we let each sender to prove 
that it is the sender of the packet, and  has appropriate right.  An easy 
way to achieve this goal is to let the sender use one-way key chain, and 
send the first key to some authority to sign it, if the authority this the 
sender is a valid sender with appropriate right, it will sign it and 
return the signed key to the sender. Then the sender broadcasts the signed 
signature to other members. After that, the sender can use TESLA to  
distribute packet with source authentication. 
 
The advantage of the distributed scheme is:
1) no single failure point
2) performance of data sending and authentication is desirable(but not for 
dynamicaly changed  group)
 
The problems of this scheme is:
1) If the sending right of a sender is revoked by the authority, it might 
take long time to distribute the invalidated right information to all 
group members. Due to the propagation delay, the sender can send out some 
malicious packets during the delay and those packets will still be 
accepted by many members who haven't received(or will never receive if the 
information is lost) the updated right information. That is a potential 
security problem. 
2) If a member joins the group late, and miss the initial signed key, it 
was forced to request the signed key information from some point. That 
might cause request implosion. A possible solution is to let some point to 
broadcast the signed keys periodically, a new join member simple wait for 
next key broadcast. The problem of this solution is that if the number of 
sender is very large, such kind of broadcast will use many system 
resources. 
 
As a alternative, I am thinking of using a hierarical, centralized scheme.  
Just like IGKMP,  I splitted the group members into several subgroups. 
Each subgroup has one subgroup leader. Members can authenticate whether a 
packet is from their subgroup leader through TESLA protocol. Each member 
shares a pair key with its subgroup leader.  All subgroup leaders form a 
subgroup leader group which share a subgroup key. All subgroup leaders are 
assumed to be trustable.
 
Packet sending and authenticating steps:
1) the sender multicast the packet to the group.
2) the sender send to its subgroup leader the packet's message 
authentication code encrypted with its pair key shared with the subgroup 
leader.
3) The subgroup leader authenticate it and sign it using subgroup key 
shared by all subgroup leader, and multicast the signed authentication 
information to all other subgroup leaders.
3) other subgroup leaders verify the authentication information, if 
correct, they will use TESLA to broadcast the authentication information 
to its subgroup members.
4) For all other receivers, they buffered the packets and wait for the 
corresponding authentication information for some fixed time.  If it still 
hasn't receive correct authentication information, it will drop the 
buffered packets; otherwise, it can authenticate the buffered packet. 
 
Therefore, I actually transfer the many-to-many source authentication 
problem to a peer-to-peer source authentication plus a one-to-many 
authentication problem. Each packet goes as it usual does, but the 
authentication information will be authenticated and forwarded by some 
centralized subgroup leaders.  The overhead of sending and authentication 
one packet should be: one packet payload sending+3 authentication 
information sending(sender to subgroup leader, subgroup leader to other 
subgroup leaders, other subgroup leaders to their subgroup members). 
Currently, I think the size of authentication information is small, so the 
overhead seems to be acceptable. But I am not sure before the simulation 
result comes out. 
 
The benefit of this scheme is:
1) It is unidirectional communication and can prevent request implosion
2) it can easily solve the sending right revoking problem
3) Each member only needs to negotiate a pair key with its subgroup 
leader, it doesn't need to take care of other senders signed key 
information. 
 
The fatal disadvantage of this scheme should be:
1) It has single failure point. That is, it has to keep the assumption 
that EACH subgroup leader is trustable. That is, the whole system might 
crash if one subgroup leader is compromised during the session.
 
Any comments on the source authentication problem is highly welcomed. 
Thanks.
 
 
Xin
 
 
   ("`-''-/").___..--''"`-._
     `6_ 6  )   `-.  (     ).`-.__.`)
     (_Y_.)'  ._   )  `._ `. ``-..-'
  _..`--'_..-_/  /--'_.' ,'
 (il),-''  (li),'  ((!.-'       
 
 


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


From msec-admin@securemulticast.org  Tue Nov 19 10:34:09 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07639
	for <msec-archive@lists.ietf.org>; Tue, 19 Nov 2002 10:34:08 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 1B29D53801; Tue, 19 Nov 2002 10:36:16 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 545585371A
	for <msec@lists.securemulticast.org>; Tue, 19 Nov 2002 10:35:00 -0500 (EST)
Received: (qmail 37596 invoked by uid 3269); 19 Nov 2002 15:35:00 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 37587 invoked from network); 19 Nov 2002 15:34:59 -0000
Received: from unknown (HELO itsky.com.cn) (211.153.20.96)
  by klesh.pair.com with SMTP; 19 Nov 2002 15:34:59 -0000
Received: (smail 5800 invoked by uid 511); 19 Nov 2002 14:56:58 -0000
Received: from unknown (HELO lion) (free@61.48.8.132)
  by 0 with SMTP; 19 Nov 2002 14:56:58 -0000
From: "zen" <free@itsky.com.cn>
To: Bob Lund <bob.lund@visi.com>
Cc: "msec@securemulticast.org" <msec@securemulticast.org>
X-mailer: Foxmail 4.2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 7bit
Message-Id: <20021119153500.545585371A@pairlist.net>
Subject: [MSEC] thanks
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, 19 Nov 2002 23:35:49 +0800
Content-Transfer-Encoding: 7bit

Hi,Bob,
Thanks your advices. I have read some papers from the websites.

I hope i can continuously get your help in my master thesis work on security multicast.
thanks.

 zen




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


From msec-admin@securemulticast.org  Tue Nov 19 11:30:30 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09022
	for <msec-archive@lists.ietf.org>; Tue, 19 Nov 2002 11:30:30 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 1BE5053832; Tue, 19 Nov 2002 11:32:39 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id 2DD68537B6
	for <msec@lists.securemulticast.org>; Tue, 19 Nov 2002 11:31:43 -0500 (EST)
Received: (qmail 46319 invoked by uid 3269); 19 Nov 2002 16:31:43 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 46316 invoked from network); 19 Nov 2002 16:31:42 -0000
Received: from smtp.eecs.umich.edu (141.213.4.43)
  by klesh.pair.com with SMTP; 19 Nov 2002 16:31:42 -0000
Received: from earth (earth.eecs.umich.edu [141.213.10.58])
	(authenticated bits=0)
	by smtp.eecs.umich.edu (8.12.3/8.12.3) with ESMTP id gAJGMCVX006112;
	Tue, 19 Nov 2002 11:22:14 -0500
Message-ID: <000201c28fe8$9fa5e7f0$3a0ad58d@earth>
Reply-To: "Xin Zhao" <zhaoxin@eecs.umich.edu>
From: "Xin Zhao" <zhaoxin@eecs.umich.edu>
To: "Adrian Perrig" <adrian@ece.cmu.edu>
Cc: <msec@securemulticast.org>
References: <Pine.LNX.3.96L.1021119091450.12683A-100000@finch.ece.cmu.edu>
Subject: Re: [MSEC] About source authentication in many-to-many multicast scenario
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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Scanned-By: MIMEDefang 2.25 (www . roaringpenguin . com / mimedefang)
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, 19 Nov 2002 11:27:20 -0500
Content-Transfer-Encoding: 7bit

Yes, It is similar to Iolus. It is actually more similar to IGKMP, since the
subgroup leaders don't involve
the encryption of message content. That saves much cost and reduces the
probability of becoming
the bottleneck of the system.  But it totally relies on the safety and
reliability of subgroup leaders, once one of
the subgroup leaders is compromised, the security of the whole system will
turn to be zero if we cannot
find the compromised machine. I think that is a fatal problem of this kind
of approach.

I think many-to-many system is not used for human interaction or multimedia
broadcasting. Too many senders
in that kind of system will only bring chaos. But it could be used in
information collecting systems. For example,
if we have many sensors in a battlefield, and we also have many terminals to
receive information sent back by
those sensors. The many-to-many system could be useful.

Even in a large group with only several senders, the approach is still
useful. For example, if we have some
sending right control on the senders, simply keep keys of those senders can
not guarantee the safety of the system.
i.e. if we have a stock quoto system: several quoto servers have sending
right, let's say two server in Asia to take care
of the stock information of Asia stock market, two in US, two in Euro, etc.
The administrator notices that one server A
in Asia is compromised, it want to revoke the sending right of the server A.
What can he do? The server A has full
authentication certificate, even the administrator broadcast some emergency
notices to all receivers, there are still some
possibilities that some receivers lost the notification packets. Then the
server A still can send out some false information
which could bring huge loss to customers. That's why I think a authenticator
is necessary for the system with right control.

Many thanks for your kind feedback. Hope to keep in touch with you. :)

Xin


----- Original Message -----
From: "Adrian Perrig" <adrian@ece.cmu.edu>
To: "Xin Zhao" <zhaoxin@eecs.umich.edu>
Cc: <canetti@watson.ibm.com>; <msec@securemulticast.org>
Sent: Tuesday, November 19, 2002 10:51 AM
Subject: Re: [MSEC] About source authentication in many-to-many multicast
scenario


> Hi Xin,
> keeping keys in large dynamic groups up to date can indeed be
> expensive. The hierarchical decomposition you propose is similar to Iolus.
> Your approach is efficient for very large groups with many senders,
however, it
> seems that this is an infrequent case. Usually, very large groups have few
> senders, such as in multimedia broadcasting. In smaller groups, the
per-sender
> key distribution may be sufficient. Greetings,
>   Adrian
>
> > Hi, Ran and other researchers,
> >
> > I am working to solve the source authentication in many-to-many
multicast
> > scenario, I plan to use TESLA protocol as part of solutioin. So I am
> > writing to you to seek for your comments.
> >
> > The many-to-many multicast scenario is like this:
> > 1) multiple members in a multicast group.
> > 2) some members have the right of sending messages, others don't have
> > 3) data packets and re-key distribution packets are sent asynchronously
> > 4) data packets are encrypted/decrypted with a single group key.
> >
> > Because we have only one group key, everyone in the group has the
ability
> > of compose a packet. Receivers need to determine whether the packet
> > originated from the purposed member who has appropriate data sending
> > right.
> >
> > Current we have two choices: centralized scheme and distributed scheme.
> >
> > For completely distributed scheme, suppose we let each sender to prove
> > that it is the sender of the packet, and  has appropriate right.  An
easy
> > way to achieve this goal is to let the sender use one-way key chain, and
> > send the first key to some authority to sign it, if the authority this
the
> > sender is a valid sender with appropriate right, it will sign it and
> > return the signed key to the sender. Then the sender broadcasts the
signed
> > signature to other members. After that, the sender can use TESLA to
> > distribute packet with source authentication.
> >
> > The advantage of the distributed scheme is:
> > 1) no single failure point
> > 2) performance of data sending and authentication is desirable(but not
for
> > dynamicaly changed  group)
> >
> > The problems of this scheme is:
> > 1) If the sending right of a sender is revoked by the authority, it
might
> > take long time to distribute the invalidated right information to all
> > group members. Due to the propagation delay, the sender can send out
some
> > malicious packets during the delay and those packets will still be
> > accepted by many members who haven't received(or will never receive if
the
> > information is lost) the updated right information. That is a potential
> > security problem.
> > 2) If a member joins the group late, and miss the initial signed key, it
> > was forced to request the signed key information from some point. That
> > might cause request implosion. A possible solution is to let some point
to
> > broadcast the signed keys periodically, a new join member simple wait
for
> > next key broadcast. The problem of this solution is that if the number
of
> > sender is very large, such kind of broadcast will use many system
> > resources.
> >
> > As a alternative, I am thinking of using a hierarical, centralized
scheme.
> > Just like IGKMP,  I splitted the group members into several subgroups.
> > Each subgroup has one subgroup leader. Members can authenticate whether
a
> > packet is from their subgroup leader through TESLA protocol. Each member
> > shares a pair key with its subgroup leader.  All subgroup leaders form a
> > subgroup leader group which share a subgroup key. All subgroup leaders
are
> > assumed to be trustable.
> >
> > Packet sending and authenticating steps:
> > 1) the sender multicast the packet to the group.
> > 2) the sender send to its subgroup leader the packet's message
> > authentication code encrypted with its pair key shared with the subgroup
> > leader.
> > 3) The subgroup leader authenticate it and sign it using subgroup key
> > shared by all subgroup leader, and multicast the signed authentication
> > information to all other subgroup leaders.
> > 3) other subgroup leaders verify the authentication information, if
> > correct, they will use TESLA to broadcast the authentication information
> > to its subgroup members.
> > 4) For all other receivers, they buffered the packets and wait for the
> > corresponding authentication information for some fixed time.  If it
still
> > hasn't receive correct authentication information, it will drop the
> > buffered packets; otherwise, it can authenticate the buffered packet.
> >
> > Therefore, I actually transfer the many-to-many source authentication
> > problem to a peer-to-peer source authentication plus a one-to-many
> > authentication problem. Each packet goes as it usual does, but the
> > authentication information will be authenticated and forwarded by some
> > centralized subgroup leaders.  The overhead of sending and
authentication
> > one packet should be: one packet payload sending+3 authentication
> > information sending(sender to subgroup leader, subgroup leader to other
> > subgroup leaders, other subgroup leaders to their subgroup members).
> > Currently, I think the size of authentication information is small, so
the
> > overhead seems to be acceptable. But I am not sure before the simulation
> > result comes out.
> >
> > The benefit of this scheme is:
> > 1) It is unidirectional communication and can prevent request implosion
> > 2) it can easily solve the sending right revoking problem
> > 3) Each member only needs to negotiate a pair key with its subgroup
> > leader, it doesn't need to take care of other senders signed key
> > information.
> >
> > The fatal disadvantage of this scheme should be:
> > 1) It has single failure point. That is, it has to keep the assumption
> > that EACH subgroup leader is trustable. That is, the whole system might
> > crash if one subgroup leader is compromised during the session.
> >
> > Any comments on the source authentication problem is highly welcomed.
> > Thanks.
> >
> >
> > Xin
> >
> >
> >    ("`-''-/").___..--''"`-._
> >      `6_ 6  )   `-.  (     ).`-.__.`)
> >      (_Y_.)'  ._   )  `._ `. ``-..-'
> >   _..`--'_..-_/  /--'_.' ,'
> >  (il),-''  (li),'  ((!.-'
> >
> >
> >
> >
> > _______________________________________________
> > 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 Nov 19 13:49:56 2002
Received: from pairlist.net (pairlist.net [216.92.1.92])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12847
	for <msec-archive@lists.ietf.org>; Tue, 19 Nov 2002 13:49:55 -0500 (EST)
Received: from pairlist.net (localhost.pair.com [127.0.0.1])
	by pairlist.net (Postfix) with ESMTP
	id 010FA539F5; Tue, 19 Nov 2002 13:47:53 -0500 (EST)
Delivered-To: msec@pairlist.net
Received: from klesh.pair.com (klesh.pair.com [209.68.2.45])
	by pairlist.net (Postfix) with SMTP id E3AD353A52
	for <msec@lists.securemulticast.org>; Tue, 19 Nov 2002 13:38:25 -0500 (EST)
Received: (qmail 65010 invoked by uid 3269); 19 Nov 2002 18:38:25 -0000
Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org
Received: (qmail 65007 invoked from network); 19 Nov 2002 18:38:25 -0000
Received: from pigeon.verisign.com (65.205.251.71)
  by klesh.pair.com with SMTP; 19 Nov 2002 18:38:25 -0000
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55])
        by pigeon.verisign.com (8.12.1/) with ESMTP id gAJIbW47013120;
        Tue, 19 Nov 2002 10:37:32 -0800 (PST)
Received: from THARDJONO-LAP.verisign.com (stargate.verisign.com [10.25.248.5]) by vhqpostal-gw1.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id VPFWNHN9; Tue, 19 Nov 2002 10:38:23 -0800
Message-Id: <5.0.0.25.2.20021119133539.027112f8@pop.mail.yahoo.com>
X-Sender: thardjono@vhqpostal3.verisign.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: msec@securemulticast.org
From: Thomas Hardjono <thardjono@verisign.com>
Cc: gsec@lists.tislabs.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [MSEC] Slides from this morning's MSEC now on the website
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, 19 Nov 2002 13:38:20 -0500


Folks,

Some of the slides from this morning's MSEC meeting at IETF55
are now available on the website.
http://www.securemulticast.org/msec-meetings.htm

cheers,

thomas
------




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