From msec-admin@securemulticast.org Thu Jan 3 08:14:31 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00513 for ; Thu, 3 Jan 2002 08:14:31 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1E89A53600; Thu, 3 Jan 2002 08:14:03 -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 F2CB953712 for ; Thu, 3 Jan 2002 08:12:04 -0500 (EST) Received: (qmail 48212 invoked by uid 3269); 3 Jan 2002 13:12:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48209 invoked from network); 3 Jan 2002 13:12:04 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 3 Jan 2002 13:12:04 -0000 Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.24.13]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g03DBSq23257; Thu, 3 Jan 2002 05:11:28 -0800 (PST) Received: from MCGREWW2K (sjc-vpn2-67.cisco.com [10.21.112.67]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AAN59698; Thu, 3 Jan 2002 05:07:02 -0800 (PST) From: "David A. Mcgrew" To: "Ran Canetti" , , Subject: RE: [MSEC] GDOI fix Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200112191946.OAA36210@ornavella.watson.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 3 Jan 2002 05:08:30 -0800 Content-Transfer-Encoding: 7bit Ran, Cathy, > -----Original Message----- > From: msec-admin@securemulticast.org > [mailto:msec-admin@securemulticast.org]On Behalf Of Ran Canetti > Sent: Wednesday, December 19, 2001 11:47 AM > To: meadows@itd.nrl.navy.mil; msec@securemulticast.org > Subject: Re: [MSEC] GDOI fix > > > > > Hi Cathy, Good catch! > These are indeed potentially bad attacks. > > Fortunately, they are easy to thwart, as you noted in your mail: > > >It also occurred to me, after following the discussion on IPSEC, that it > >would be possible to foil this attack by requiring POP signatures > >to be on the two nonces followed by some short non-random field. Thus, > >POP_I could be over (N_i || N_r || 0 ) and POP_R could be over > >(N_i || N_r || 1), although we might want to use different integers > >besides 0 and 1, since those are the ones currently being used by JFK. > >If we don't want to put a limit on the nonce sizes for whatever reason, > >this could be preferable. > > I agree - all that has to be done is when the GCKS signs a POP challenge, > it should add to the signed text a reserved string that is > interpreted as the > message "this is a signature on a POP challenge". > This way, the POP signatures will be worthless as GROUPKEY-PUSH signatures > and the attacks will be thwarted. I'd suggest though that: > -The special string will be prepended rahter than appended, to avoid > potential decoding ambiguities. > -The special string be a bit more distinctive, again to avoid mistakes. > How about, say, the string "POP" in ascii. > > > (A general lesson for us in protocol design: When using a signature in a > protocol, make sure to add a special string that ties the signature to its > particular use in the protocol.) right, I agree that what we have here is a test case for a fundamental law, so to speak. "Each use of an authentication key to protect data within a protocol MUST protect the information about the type of data and/or how to decode that data." Any chance that the protocol analyzer can help elucidate such rules for us? This principle applies to other crypto services as well. Clearly symmetric authentication can be undermined if a message of type A can be substituted for a message of type B without detection, and the same for non-repudiation. I'm not sure if a similar principle applies for confidentiality. It might provide strength against chosen ciphertext/plaintext attacks, but I'm not sure that it's really necessary. Encodings in crypto protocols are an interesting topic, Manger's attack on OAEP implementations (which works by causing a failure in the integer-to-octet conversion) being a fun example of the problems a protocol designer can get into. David mcgrew@cisco.com > > (A first place to implement the above lesson: Add a similar string also > to the POP signature by the group member.) > > > Ran > > > _______________________________________________ > 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 Jan 7 15:12:38 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26683 for ; Mon, 7 Jan 2002 15:12:37 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C221E53B0D; Mon, 7 Jan 2002 15:06:15 -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 AA0D453687 for ; Mon, 7 Jan 2002 15:04:51 -0500 (EST) Received: (qmail 31695 invoked by uid 3269); 7 Jan 2002 20:04:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 31689 invoked from network); 7 Jan 2002 20:04:51 -0000 Received: from nisser.cisco.com (171.71.176.85) by klesh.pair.com with SMTP; 7 Jan 2002 20:04:51 -0000 Received: from cisco.com (bew@byost-w2k-1.cisco.com [128.107.163.146]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA18728; Mon, 7 Jan 2002 12:04:05 -0800 (PST) Message-ID: <3C39FF34.D3367903@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: fredrik.lindholm@era.ericsson.se, elisabetta.carrara@era.ericsson.se, jari.arkko@ericsson.com, mats.naslund@era.ericsson.se Cc: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] MIKEY mapping of keys to steams -- possible vulnerability 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 07 Jan 2002 12:04:04 -0800 Content-Transfer-Encoding: 7bit I have a question on how MIKEY accurately maintains a mapping of keys to audio/video streams in an SDP specification. I've given my understanding of how this happens so you can check my assumptions, and then I suggest a possibly vulnerability. MIKEY specifies a new concept of "crypto session id" which it uses to label media streams which are later defined in an SDP description The crypto session id is a logical identity where the first media session ("m=") statement is associated with the first crypto session id, the second media session statement is associated with the second crypto session id, etc. (This seems clear from section 6. of MIKEY.) The format of the crypto session id is specified in section A.1. The concept of the MCS ID is defined to be an 80-bit random number which doesn't describe the media session at all, and I can't tell how the CS IDs are defined but I see nothing which is mappable to the actual media streams. MIKEY protects the "a=keymgmt-data" data such that tampering can be detected within the key management data. But MIKEY cannot detect if the "m=" statements in the SDP description have been replaced or otherwise modified. To illustrate my point, here is the example in the MIKEY document: | a=keymgmt-prot:MIKEY | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... MCS < CS 1 < m=audio 49000 RTP/SAVP 98 | a=rtpmap:98 AMR/8000 | CS 2 < m=video 2232 RTP/SAVP 31 Suppose this was modified by a man-in-the-middle and the SDP was changed to this: | a=keymgmt-prot:MIKEY | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... MCS < CS 1 < m=video 53172 RTP/SAVP 98 | CS 2 < m=audio 49170 RTP/SAVP 31 The keys in keymgmt-data will be correctly transmitted in the MIKEY description, but applied to the wrong media streams. This could be considered a DoS attack. In the case of a multicast group, it's a more serious attack: if a dishonest group member (holding the encryption keys) changes the SDP before other group members see it, he can source different media streams which match the new SDP definition. These will be authenticated in MIKEY and accepted as the valid streams, when in fact they are not what the person who sent the MIKEY definition intended. I realize that MIKEY did not intend to protect the "m=" statements in any way. But it seems to me that the implicit references to the rest of the SDP definition affects the validity of MIKEY. One way to solve this might be to include something in the CS ID so that the media can be verified (e.g., a hash of the "m=" statement). But that doesn't handle all of the dependencies on the SDP statements. MIKEY is also dependent on the "c=" statement defining the actual multicast address. Another solution would be to require that MIKEY be used in conjunction with a separate authentication system which authenticates the entire SDP definition. (For example, SIP defines some authentication using PGP although I've heard comments that on one actually uses it.) This seems to me to be the safest approach, but it is too bad that MIKEY would be dependent on other systems. I'm anxious to hear your comments. Thanks, Brian -- 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 Jan 9 07:14:30 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02955 for ; Wed, 9 Jan 2002 07:14:30 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BF6CF53D0A; Wed, 9 Jan 2002 07:14: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 9415F53714 for ; Wed, 9 Jan 2002 07:13:16 -0500 (EST) Received: (qmail 42121 invoked by uid 3269); 9 Jan 2002 12:13:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 42118 invoked from network); 9 Jan 2002 12:13:15 -0000 Received: from albatross-ext.wise.edt.ericsson.se (194.237.142.116) by klesh.pair.com with SMTP; 9 Jan 2002 12:13:15 -0000 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g09CD9J20485 for ; Wed, 9 Jan 2002 13:13:09 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Jan 09 13:12:37 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 13:12:21 +0100 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE3F86@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Brian Weis'" Cc: msec@securemulticast.org, "'mmusic@ietf.org'" , "Elisabetta Carrara (ERA)" , jari.arkko@ericsson.com, =?iso-8859-1?Q?Mats_N=E4slund_=28ERA=29?= MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] RE: MIKEY mapping of keys to steams -- possible vulnerability 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 9 Jan 2002 13:12:13 +0100 Hi Brian, and thanks for the comments. They are most valid. I see three ways of solving it (without making a too complex solution). 1) Assume that SIP, RTSP, or SDP can transport the description in a secure and reliable way to its destination (e.g. we have the SIP security group that are working with this problem). This is mainly what we have done so far. 2) Begin using the extra keymgmt-auth attribute that we are introducing in SDP. We introduced an extra SDP attribute in order to be able to authenticate part of the SDP description if necessary (this is however still an undocumented feature in the current MIKEY draft). Your comments may give us a reason to pursue with that attribute and use it to "tie" the media description to the MIKEY data (in case it is not already provided by SIP/RTSP/SDP). A small example of how it could work: | a=keymgmt-prot:MIKEY | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... | a=keymgmt-auth:q9wuIs5du2ISD7 MCS < CS 1 < m=audio 49000 RTP/SAVP 98 | a=rtpmap:98 AMR/8000 | CS 2 < m=video 2232 RTP/SAVP 31 where the authentication field is computed over a well-defined subset of SDP (this could of course include the c= line). There is mainly one problem with this. If the user is behind a NAT, the SIP server (or another intermediate node) may need to change things like IP addresses and ports in the SDP, and thereby the authentication will fail (if it is computed over these fields). 3) An idea, similar to the one you proposed. Instead of including the hash of some specific field, a hash over a well-defined subset or the entire SDP description could be provided (but not as input to any id), i.e. set q = hash(the sdp lines, except "a=keymgmt-data:..."). Let the signature/MAC in MIKEY include q. The hash could in this case be as just another payload in MIKEY. It would of course be authenticated and the result would be equal to that in 2). This will however have the same NAT problems as in 2). This approach will have the disadvantage that we might need to build in too much knowledge about SDP in MIKEY. Exactly what to aim at is something that needs to be discussed. In the future, we will probably be able to rely on 1) (and we need doing so unless we want to solve the same issues the security protocols for 1) will solve). Best Regards, Fredrik > -----Original Message----- > From: Brian Weis [mailto:bew@cisco.com] > Sent: den 7 januari 2002 21:04 > To: fredrik.lindholm@era.ericsson.se; > elisabetta.carrara@era.ericsson.se; jari.arkko@ericsson.com; > mats.naslund@era.ericsson.se > Cc: msec@securemulticast.org > Subject: MIKEY mapping of keys to steams -- possible vulnerability > > > I have a question on how MIKEY accurately maintains a mapping > of keys to > audio/video streams in an SDP specification. I've given my > understanding > of how this happens so you can check my assumptions, and then > I suggest > a possibly vulnerability. > > MIKEY specifies a new concept of "crypto session id" which it uses to > label media streams which are later defined in an SDP description The > crypto session id is a logical identity where the first media session > ("m=") statement is associated with the first crypto session id, the > second media session statement is associated with the second crypto > session id, etc. (This seems clear from section 6. of MIKEY.) > > The format of the crypto session id is specified in section A.1. The > concept of the MCS ID is defined to be an 80-bit random number which > doesn't describe the media session at all, and I can't tell how the CS > IDs are defined but I see nothing which is mappable to the > actual media > streams. > > MIKEY protects the "a=keymgmt-data" data such that tampering can be > detected within the key management data. > > But MIKEY cannot detect if the "m=" statements in the SDP description > have been replaced or otherwise modified. To illustrate my point, here > is the example in the MIKEY document: > > > | a=keymgmt-prot:MIKEY > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > MCS < CS 1 < m=audio 49000 RTP/SAVP 98 > | a=rtpmap:98 AMR/8000 > | CS 2 < m=video 2232 RTP/SAVP 31 > > Suppose this was modified by a man-in-the-middle and the SDP > was changed > to this: > > | a=keymgmt-prot:MIKEY > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > MCS < CS 1 < m=video 53172 RTP/SAVP 98 > | CS 2 < m=audio 49170 RTP/SAVP 31 > > The keys in keymgmt-data will be correctly transmitted in the MIKEY > description, but applied to the wrong media streams. > > This could be considered a DoS attack. In the case of a > multicast group, > it's a more serious attack: if a dishonest group member (holding the > encryption keys) changes the SDP before other group members see it, he > can source different media streams which match the new SDP definition. > These will be authenticated in MIKEY and accepted as the > valid streams, > when in fact they are not what the person who sent the MIKEY > definition > intended. > > I realize that MIKEY did not intend to protect the "m=" statements in > any way. But it seems to me that the implicit references to > the rest of > the SDP definition affects the validity of MIKEY. > > One way to solve this might be to include something in the CS > ID so that > the media can be verified (e.g., a hash of the "m=" > statement). But that > doesn't handle all of the dependencies on the SDP statements. MIKEY is > also dependent on the "c=" statement defining the actual multicast > address. > > Another solution would be to require that MIKEY be used in conjunction > with a separate authentication system which authenticates the > entire SDP > definition. (For example, SIP defines some authentication using PGP > although I've heard comments that on one actually uses it.) This seems > to me to be the safest approach, but it is too bad that MIKEY would be > dependent on other systems. > > I'm anxious to hear your comments. > > Thanks, > Brian > -- > 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 Fri Jan 11 21:00:27 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04413 for ; Fri, 11 Jan 2002 21:00:26 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 47DD153871; Fri, 11 Jan 2002 20:57: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 253C653680 for ; Fri, 11 Jan 2002 20:54:01 -0500 (EST) Received: (qmail 36382 invoked by uid 3269); 12 Jan 2002 01:54:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36379 invoked from network); 12 Jan 2002 01:54:00 -0000 Received: from nisser.cisco.com (171.71.176.85) by klesh.pair.com with SMTP; 12 Jan 2002 01:54:00 -0000 Received: from cisco.com (rajitha-w2k3.cisco.com [128.107.163.156]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA02843; Fri, 11 Jan 2002 17:53:26 -0800 (PST) Message-ID: <3C3F9716.6E1CDA89@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Fredrik Lindholm (ERA)" Cc: msec@securemulticast.org, "'mmusic@ietf.org'" , " Elisabetta Carrara (ERA)" , jari.arkko@ericsson.com, "Mats =?iso-8859-1?Q?N=E4slund?= (ERA)" References: <0DAEDF148988D411BB980008C7E65D2E04FE3F86@esealnt416> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] Re: [MMUSIC] RE: MIKEY mapping of keys to steams -- possible vulnerability 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 17:53:26 -0800 Content-Transfer-Encoding: 7bit Hi Fredrik, Thanks for your response. I've got some more comments inline. "Fredrik Lindholm (ERA)" wrote: > > Hi Brian, > > and thanks for the comments. They are most valid. > > I see three ways of solving it (without making a too complex solution). > > 1) Assume that SIP, RTSP, or SDP can transport the description in a secure and reliable way to its destination (e.g. we have the SIP security group that are working with this problem). This is mainly what we have done so far. Right, that would be work in terms of securing a system. But as Mark pointed out, in terms of the protocol definition this approach means that your statement in Section 2.2 of MIKEY may not be quite true * Independent of the security of the underlying transport. if you think of the session establishment protocol being part of the term "underlying transport". > 2) Begin using the extra keymgmt-auth attribute that we are introducing in SDP. We introduced an extra SDP attribute in order to be able to authenticate part of the SDP description if necessary (this is however still an undocumented feature in the current MIKEY draft). Your comments may give us a reason to pursue with that attribute and use it to "tie" the media description to the MIKEY data (in case it is not already provided by SIP/RTSP/SDP). > > A small example of how it could work: > | a=keymgmt-prot:MIKEY > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > | a=keymgmt-auth:q9wuIs5du2ISD7 > MCS < CS 1 < m=audio 49000 RTP/SAVP 98 > | a=rtpmap:98 AMR/8000 > | CS 2 < m=video 2232 RTP/SAVP 31 > > where the authentication field is computed over a well-defined subset of SDP (this could of course include the c= line). There is mainly one problem with this. If the user is behind a NAT, the SIP server (or another intermediate node) may need to change things like IP addresses and ports in the SDP, and thereby the authentication will fail (if it is computed over these fields). Thanks for pointing out the proposed keymgmt-auth attribute It does begin to solve the authentication problem, but I don't think specifying it will be so easy. The NAT problem is interesting. I didn't know that NAT boxes were SDP (or SIP and RTSP) aware. But if the c= line isn't in the authenticated subset of the SDP definition then it's questionable whether validating the integrity of the rest of the SDP definition is worthwhile -- an attacker can still change the media streams to which the MIKEY keys will be applied to (same ports, different machine). > 3) An idea, similar to the one you proposed. Instead of including the hash of some specific field, a hash over a well-defined subset or the entire SDP description could be provided (but not as input to any id), i.e. set q = hash(the sdp lines, except "a=keymgmt-data:..."). Let the signature/MAC in MIKEY include q. The hash could in this case be as just another payload in MIKEY. It would of course be authenticated and the result would be equal to that in 2). This will however have the same NAT problems as in 2). This approach will have the disadvantage that we might need to build in too much knowledge about SDP in MIKEY. Yes, I think that no matter what you choose to hash you'll either have too much knowledge of SDP in MIKEY, or too much knowledge of MIKEY in SDP. In the example above, who does the hash() on the local system? If the SDP code does it then it has to know about creating a MIKEY-specific hash. If the MIKEY code does it, then it has to be given access to the entire SDP description and it has to know how to parse it. This applies to both solutions 2) and 3). You can think of it as a protocol layering violation problem. I suggest that you put some more thought into the a=keymgmt-auth attribute defined in draft-ietf-mmusic-kmgmt-ext-00.txt draft. If you can't come up with a way of addressing the layering problem you should probably remove it from that draft and mention the integrity issue there too. > Exactly what to aim at is something that needs to be discussed. In the future, we will probably be able to rely on 1) (and we need doing so unless we want to solve the same issues the security protocols for 1) will solve). Yes, 1) is your best bet for now. But you should add some text to the MIKEY draft pointing out the problem and describe the dependency. I have put some thought into a generic SDP authentication attribute (which would not be part of any particular key management system, and could be used by itself to authenticate any SDP description.) If that's seen as appropriate I'll submit it mmusic. Thanks, Brian > Best Regards, > Fredrik > > > -----Original Message----- > > From: Brian Weis [mailto:bew@cisco.com] > > Sent: den 7 januari 2002 21:04 > > To: fredrik.lindholm@era.ericsson.se; > > elisabetta.carrara@era.ericsson.se; jari.arkko@ericsson.com; > > mats.naslund@era.ericsson.se > > Cc: msec@securemulticast.org > > Subject: MIKEY mapping of keys to steams -- possible vulnerability > > > > > > I have a question on how MIKEY accurately maintains a mapping > > of keys to > > audio/video streams in an SDP specification. I've given my > > understanding > > of how this happens so you can check my assumptions, and then > > I suggest > > a possibly vulnerability. > > > > MIKEY specifies a new concept of "crypto session id" which it uses to > > label media streams which are later defined in an SDP description The > > crypto session id is a logical identity where the first media session > > ("m=") statement is associated with the first crypto session id, the > > second media session statement is associated with the second crypto > > session id, etc. (This seems clear from section 6. of MIKEY.) > > > > The format of the crypto session id is specified in section A.1. The > > concept of the MCS ID is defined to be an 80-bit random number which > > doesn't describe the media session at all, and I can't tell how the CS > > IDs are defined but I see nothing which is mappable to the > > actual media > > streams. > > > > MIKEY protects the "a=keymgmt-data" data such that tampering can be > > detected within the key management data. > > > > But MIKEY cannot detect if the "m=" statements in the SDP description > > have been replaced or otherwise modified. To illustrate my point, here > > is the example in the MIKEY document: > > > > > > | a=keymgmt-prot:MIKEY > > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > > MCS < CS 1 < m=audio 49000 RTP/SAVP 98 > > | a=rtpmap:98 AMR/8000 > > | CS 2 < m=video 2232 RTP/SAVP 31 > > > > Suppose this was modified by a man-in-the-middle and the SDP > > was changed > > to this: > > > > | a=keymgmt-prot:MIKEY > > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > > MCS < CS 1 < m=video 53172 RTP/SAVP 98 > > | CS 2 < m=audio 49170 RTP/SAVP 31 > > > > The keys in keymgmt-data will be correctly transmitted in the MIKEY > > description, but applied to the wrong media streams. > > > > This could be considered a DoS attack. In the case of a > > multicast group, > > it's a more serious attack: if a dishonest group member (holding the > > encryption keys) changes the SDP before other group members see it, he > > can source different media streams which match the new SDP definition. > > These will be authenticated in MIKEY and accepted as the > > valid streams, > > when in fact they are not what the person who sent the MIKEY > > definition > > intended. > > > > I realize that MIKEY did not intend to protect the "m=" statements in > > any way. But it seems to me that the implicit references to > > the rest of > > the SDP definition affects the validity of MIKEY. > > > > One way to solve this might be to include something in the CS > > ID so that > > the media can be verified (e.g., a hash of the "m=" > > statement). But that > > doesn't handle all of the dependencies on the SDP statements. MIKEY is > > also dependent on the "c=" statement defining the actual multicast > > address. > > > > Another solution would be to require that MIKEY be used in conjunction > > with a separate authentication system which authenticates the > > entire SDP > > definition. (For example, SIP defines some authentication using PGP > > although I've heard comments that on one actually uses it.) This seems > > to me to be the safest approach, but it is too bad that MIKEY would be > > dependent on other systems. > > > > I'm anxious to hear your comments. > > > > Thanks, > > Brian > > -- > > Brian Weis > > Strategic Cryptographic Development, ITD, Cisco Systems > > Telephone: +1 408 526 4796 > > Email: bew@cisco.com > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- 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 Fri Jan 11 23:13:58 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07655 for ; Fri, 11 Jan 2002 23:13:58 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8215C539F8; Fri, 11 Jan 2002 23:11:48 -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 114E9538B1 for ; Fri, 11 Jan 2002 17:37:30 -0500 (EST) Received: (qmail 5338 invoked by uid 3269); 11 Jan 2002 22:37:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 5335 invoked from network); 11 Jan 2002 22:37:29 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 11 Jan 2002 22:37:29 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0BMa4414825; Fri, 11 Jan 2002 14:36:04 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (sjc-vpn1-718.cisco.com [10.21.98.206]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAQ18951; Fri, 11 Jan 2002 14:35:30 -0800 (PST) Message-Id: <4.3.2.7.2.20020111141119.0460bdc8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Fredrik Lindholm (ERA)" From: Mark Baugher Subject: Re: [MSEC] RE: MIKEY mapping of keys to steams -- possible vulnerability Cc: "'Brian Weis'" , msec@securemulticast.org, "'mmusic@ietf.org'" , "Elisabetta Carrara (ERA)" , jari.arkko@ericsson.com, Mats =?iso-8859-1?Q?N=E4slund?= (ERA) In-Reply-To: <0DAEDF148988D411BB980008C7E65D2E04FE3F86@esealnt416> 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 14:33:56 -0800 Hi Fredrik Doesn't this problem conflict with one of your stated design goals of Section 2.2: Independence of the security of the underlying transport? All three of these solutions seem to me to violate that design goal. It seems to me that you need to remove the dependency that you have on the integrity of SDP messages in order to preserve your goals. Mark At 01:12 PM 1/9/2002 +0100, Fredrik Lindholm (ERA) wrote: >Hi Brian, > >and thanks for the comments. They are most valid. > >I see three ways of solving it (without making a too complex solution). > >1) Assume that SIP, RTSP, or SDP can transport the description in a secure >and reliable way to its destination (e.g. we have the SIP security group >that are working with this problem). This is mainly what we have done so far. > >2) Begin using the extra keymgmt-auth attribute that we are introducing in >SDP. We introduced an extra SDP attribute in order to be able to >authenticate part of the SDP description if necessary (this is however >still an undocumented feature in the current MIKEY draft). Your comments >may give us a reason to pursue with that attribute and use it to "tie" the >media description to the MIKEY data (in case it is not already provided by >SIP/RTSP/SDP). > >A small example of how it could work: > | a=keymgmt-prot:MIKEY > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > | a=keymgmt-auth:q9wuIs5du2ISD7 > MCS < CS 1 < m=audio 49000 RTP/SAVP 98 > | a=rtpmap:98 AMR/8000 > | CS 2 < m=video 2232 RTP/SAVP 31 > >where the authentication field is computed over a well-defined subset of >SDP (this could of course include the c= line). There is mainly one >problem with this. If the user is behind a NAT, the SIP server (or another >intermediate node) may need to change things like IP addresses and ports >in the SDP, and thereby the authentication will fail (if it is computed >over these fields). > >3) An idea, similar to the one you proposed. Instead of including the hash >of some specific field, a hash over a well-defined subset or the entire >SDP description could be provided (but not as input to any id), i.e. set q >= hash(the sdp lines, except "a=keymgmt-data:..."). Let the signature/MAC >in MIKEY include q. The hash could in this case be as just another payload >in MIKEY. It would of course be authenticated and the result would be >equal to that in 2). This will however have the same NAT problems as in >2). This approach will have the disadvantage that we might need to build >in too much knowledge about SDP in MIKEY. > >Exactly what to aim at is something that needs to be discussed. In the >future, we will probably be able to rely on 1) (and we need doing so >unless we want to solve the same issues the security protocols for 1) will >solve). > >Best Regards, >Fredrik > > > > -----Original Message----- > > From: Brian Weis [mailto:bew@cisco.com] > > Sent: den 7 januari 2002 21:04 > > To: fredrik.lindholm@era.ericsson.se; > > elisabetta.carrara@era.ericsson.se; jari.arkko@ericsson.com; > > mats.naslund@era.ericsson.se > > Cc: msec@securemulticast.org > > Subject: MIKEY mapping of keys to steams -- possible vulnerability > > > > > > I have a question on how MIKEY accurately maintains a mapping > > of keys to > > audio/video streams in an SDP specification. I've given my > > understanding > > of how this happens so you can check my assumptions, and then > > I suggest > > a possibly vulnerability. > > > > MIKEY specifies a new concept of "crypto session id" which it uses to > > label media streams which are later defined in an SDP description The > > crypto session id is a logical identity where the first media session > > ("m=") statement is associated with the first crypto session id, the > > second media session statement is associated with the second crypto > > session id, etc. (This seems clear from section 6. of MIKEY.) > > > > The format of the crypto session id is specified in section A.1. The > > concept of the MCS ID is defined to be an 80-bit random number which > > doesn't describe the media session at all, and I can't tell how the CS > > IDs are defined but I see nothing which is mappable to the > > actual media > > streams. > > > > MIKEY protects the "a=keymgmt-data" data such that tampering can be > > detected within the key management data. > > > > But MIKEY cannot detect if the "m=" statements in the SDP description > > have been replaced or otherwise modified. To illustrate my point, here > > is the example in the MIKEY document: > > > > > > | a=keymgmt-prot:MIKEY > > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > > MCS < CS 1 < m=audio 49000 RTP/SAVP 98 > > | a=rtpmap:98 AMR/8000 > > | CS 2 < m=video 2232 RTP/SAVP 31 > > > > Suppose this was modified by a man-in-the-middle and the SDP > > was changed > > to this: > > > > | a=keymgmt-prot:MIKEY > > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > > MCS < CS 1 < m=video 53172 RTP/SAVP 98 > > | CS 2 < m=audio 49170 RTP/SAVP 31 > > > > The keys in keymgmt-data will be correctly transmitted in the MIKEY > > description, but applied to the wrong media streams. > > > > This could be considered a DoS attack. In the case of a > > multicast group, > > it's a more serious attack: if a dishonest group member (holding the > > encryption keys) changes the SDP before other group members see it, he > > can source different media streams which match the new SDP definition. > > These will be authenticated in MIKEY and accepted as the > > valid streams, > > when in fact they are not what the person who sent the MIKEY > > definition > > intended. > > > > I realize that MIKEY did not intend to protect the "m=" statements in > > any way. But it seems to me that the implicit references to > > the rest of > > the SDP definition affects the validity of MIKEY. > > > > One way to solve this might be to include something in the CS > > ID so that > > the media can be verified (e.g., a hash of the "m=" > > statement). But that > > doesn't handle all of the dependencies on the SDP statements. MIKEY is > > also dependent on the "c=" statement defining the actual multicast > > address. > > > > Another solution would be to require that MIKEY be used in conjunction > > with a separate authentication system which authenticates the > > entire SDP > > definition. (For example, SIP defines some authentication using PGP > > although I've heard comments that on one actually uses it.) This seems > > to me to be the safest approach, but it is too bad that MIKEY would be > > dependent on other systems. > > > > I'm anxious to hear your comments. > > > > Thanks, > > Brian > > -- > > 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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Jan 12 10:30:51 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21302 for ; Sat, 12 Jan 2002 10:30:51 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0FDF253B1A; Sat, 12 Jan 2002 10:28:12 -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 3E83D53AF0 for ; Sat, 12 Jan 2002 10:27:01 -0500 (EST) Received: (qmail 18999 invoked by uid 3269); 12 Jan 2002 15:27:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18996 invoked from network); 12 Jan 2002 15:27:00 -0000 Received: from chmls18.ne.ipsvc.net (24.147.1.153) by klesh.pair.com with SMTP; 12 Jan 2002 15:27:00 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.201]) by chmls18.ne.ipsvc.net (8.11.6/8.11.6) with ESMTP id g0CFQsG00096; Sat, 12 Jan 2002 10:26:54 -0500 (EST) Message-Id: <5.0.0.25.2.20020111173418.01ce54f8@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_48405203==_" Subject: [MSEC] Draft of minutes from IETF52 Salt Lake City 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 17:41:37 -0500 --=====================_48405203==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Folks, Attached is the draft of the minutes from the MSEC WG meeting at IETF52 in Salt Lake City. My apologies for being late. Please look at it and comment a.s.a.p. This was my effort at merging the two pieces of the minutes (Thanks to Dennis and Lakshminath for consecutively taking the minutes). If there are no major objections I might try to include it with the slides for submission to the formal IETF52 Proceedings (deadline Jan/14). All the slides are now on the website, and only this minutes-file is missing/late. cheers, thomas ------ --=====================_48405203==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: attachment; filename="msec52_minutes-draft1.txt" Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Multicast Security WG Minutes at 52nd IETF Friday December 14, 2001, Salt Lake City =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Agenda: ------- Agenda Bashing Review of WG Status (T. Hardjono/R. Canetti) GKM Architecture (L.Dondeti) Rekey protocol (L. Dondeti) MIKEY (F. Lindholm/E. Carrara) GDOI Implementation (B. Weis) Discussion: Last call for GDOI Review of WG Status (T. Hardjono) --------------------------------- Co-Chair Thomas Hardjono opened the Multicast Security WG meeting=20 promptly at 9:00 AM Friday, December 14, 2001. He was the only=20 chair present during this meeting. Thomas summarized the three categories of documents that are=20 required to be delivered per the terms of this WG's charter. =20 Unfortunately, the document production is behind schedule. A=20 brief overview of the schedule looks like this: - High level or framework drafts - Architecture/functionality drafts - Protocol and algorithms drafts Additionally, there has been additional work submitted to the=20 MSEC WG, such as the MIKEY draft. Thomas reports that within the RMT WG forum, there is a lack of=20 clarity as to what they are seeking in the way of security=20 support. There has been no firm security definition put forward=20 by RMT. Mark Baugher agrees with Thomas' assessment. He further=20 suggests that MSEC co-chairs asks RMT specifically what are the=20 necessary security requirements while at the same time have GSEC=20 issue a report on what elements of IGMP security currently exist. =20 However, some basic requirements exist and Thomas articulated=20 those. They are:=20 Multicast routing protection (PIM Authentication Draft in the PIM WG begins to out line minimal requirements.) Sender/receiver access control (controlling distribution to the access tree.) Key management (work being done in this WG =96 securing the Content is the next critical element of this work.) Thomas states that an ad hoc group of the chairs from GSEC, RMT,=20 Magma and the Area Directors from Transport will form in the near=20 future. Their purpose is to define and stipulate in writing what=20 are the security requirements that best serve the needs of the=20 involved parties and move forward with the creation of relevant=20 documents. Co-chair provides a status of the WG's documentation thus far. =20 Under the major categories, the following documents exist. High Level Drafts - Security Requirements =96 Canetti - MSEC Architecture =96 Hardjono/Baugher Architecture/Functionalities - Data Transforms (A/MESP) =96 Canetti - Group Key Management Architecture =96 Baugher/Dondeti - Group Security Policy Architecture =96 needs authorship Protocols and Algorithms =09 - Group DOI =96 Weis et al - GSAKMP & GSAKMP Light =96 Harney et al - TESLA with A/MESP - Canetti - TESLA Algorithms - Perrig/Canetti - LKH/OFT =96 Dondeti/McGrew - Policy Token Definition & Structure =96 needs authorship Other Issues With respect to Group Policy, Thomas indicates a need for an=20 overall policy architecture and to make the defined policies=20 known to the appropriate consumers. He raises the question,=20 "should policy be driven by the applications of group security?". =20 This concluded Thomas' WG status presentation. GKM Architecture =96 L. Dondeti ----------------------------- Lakshminath Dondeti made next presentation on his Group Key=20 Management (GKM) Architecture draft. Current draft is v.01 and=20 review help is requested. There were no comments following the=20 presentation. Rekey Protocol =96 Dondeti/McGrew ------------------------------- One important aspect of this draft protocol is that rekey was a=20 spin-off from the GKM architecture. In hindsight, this bifurcation was not a good move as, among=20 other things, it created the burden of a separate protocol, two=20 sets of documentation, and additional packet header space. Mark=20 Baugher expands on the issue, implosion and scalability. At this=20 point it might make sense to keep rekey as a separated entity=20 under KM =96 Key Management. =20 Discussion from the floor suggested an inclination that rekey=20 work should fall under the WG's Architecture/Functionalities=20 document category. The group is aware that "swirling" rekey may=20 adversely impact development of GODI. Membership will comment=20 further on the mailing list. Back channel was another issue raised during the presentation=20 that requires further attention. Likewise, Brian Coan brings up=20 from the floor the issue of Reliable Multicast over TCP. =20 MIKEY (F. Lindholm/E. Carrara) ------------------------------ MMUSIC wants it done by Mar 2002 for a WG last-call (chair Colin Perkins) Baugher: We can separate into various issues. Security issues will be discussed in MSEC in more detail SDP, RTSP issues can go on independently in MMUSIC GDOI might also be able to ship keys using SDP, RTSP etc. Another person (?) mentioned that he has a fourth key establishment scheme in mind. Will write an I-D and post to the mailing list. The chair (Thomas) had no problem. MIKEY authors had no problem, but they= want to see the I-D and the discussion in the mailing list. =20 GDOI Implementation (B. Weis) ----------------------------- port 500 SHOULD not to be changed to MUST not Lakshminath mentioned and Thomas seconded. Presented deltas from 01 IANA considerations for payloads Security issues brought up by Cathy Meadows (during presentation) being addressed. =20 A man in the middle attack in real-time. Dishonest member problem (could send a bogus rekey message). Could send a rekey message as N_i and get it signed by GCKS. Resolve this by a) proposal to use a different algm for Reg and rekey b) bounding the nonce size and rekey message size Cathy proposes a redefined POP payload Conclusion: Bring the discussion to the mailing list! Interop: two implementations Nortel's based on FreeSWAN on Linux (Lakshminath) Cisco's based on isakmpd on Linux (Brian) GDOI Registration protocol interoperates! Brian went further: and implemented SA downloads and IPsec testing and SRTP as data security protocol Discussion: Last call for GDOI ------------------------------ Last call (5th version including SMuG versions) - Security analysis done (Cathy Meadows) - Two interoperating implementations - Testing shows GDOI creates IPsec and SRTP SAs properly Mark: Ran had issues with rekey being up in the air Brian and Mark disagree with Ran Mark proposes removing: AMESP, LKH, SRTP support and so on (from GDOI draft) We could keep SRTP in. There are important apps without the need for LKH. Thomas: GDOI is more or less done. Having a last call does not preclude new additions or corrections (ie. old RFCs can be deprecated) Lakshminath: Does GDOI propose support for only small scale groups? Mark: We will support large scale groups. Lakshminath: Proposed a discussion in the mailing list. Thomas: Last call ending two weeks into January (Jan 18th). There were no objections. isakmpd implementation will be released later next year. Thomas noted that Rekey issue is complicated! Thomas mentioned that we need definitive and quick resolution. Lakshminath mentioned that in the interest of progress he supports the=20 last call discussion. He agreed with Ran's observation that rekey protocol is up in the air. It was noted that rekey protocol has a lot of baggage: -- reliability -- splitting a rekey message in case of batch rekeying or group= initialization -- key tree management -- detailed documents on LKH, OFT etc., to support interoperability It was more or less agreed that rekey protocol work should not hinder GDOI= going forward! To be discussed in the mailing list as noted earlier. Meeting Closed ----------------------------------------------------------------------------= ----------- --=====================_48405203==_-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jan 14 09:40:45 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03226 for ; Mon, 14 Jan 2002 09:40:45 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id F3F0C540FD; Mon, 14 Jan 2002 09:39:04 -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 6D42F53F73 for ; Mon, 14 Jan 2002 05:43:50 -0500 (EST) Received: (qmail 81764 invoked by uid 3269); 14 Jan 2002 10:43:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81759 invoked from network); 14 Jan 2002 10:43:49 -0000 Received: from albatross-ext.wise.edt.ericsson.se (194.237.142.116) by klesh.pair.com with SMTP; 14 Jan 2002 10:43:49 -0000 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0EAhhJ02672 for ; Mon, 14 Jan 2002 11:43:43 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Jan 14 11:43:20 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 11:34:38 +0100 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE3F9A@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Brian Weis'" , "'Mark Baugher'" Cc: msec@securemulticast.org, "'mmusic@ietf.org'" , "Elisabetta Carrara (ERA)" , jari.arkko@ericsson.com, =?iso-8859-1?Q?Mats_N=E4slund_=28ERA=29?= , "'Rolf Blom'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] RE: RE: MIKEY mapping of keys to steams -- possible vulnerabilit y 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 14 Jan 2002 11:43:14 +0100 Brian, Mark, "Independence of the security of the underlying transport" means that no security mechanism of the underlying transport is used to protect the MIKEY message. However, the intention was not to let people think that MIKEY would solve all the problems that will come from using SIP, RTSP and SDP. I guess the formulation may be a bit misguiding, but I will put a clarification of this. More comments below. > > > 3) An idea, similar to the one you proposed. Instead of > including the hash of some specific field, a hash over a > well-defined subset or the entire SDP description could be > provided (but not as input to any id), i.e. set q = hash(the > sdp lines, except "a=keymgmt-data:..."). Let the > signature/MAC in MIKEY include q. The hash could in this case > be as just another payload in MIKEY. It would of course be > authenticated and the result would be equal to that in 2). > This will however have the same NAT problems as in 2). This > approach will have the disadvantage that we might need to > build in too much knowledge about SDP in MIKEY. > > Yes, I think that no matter what you choose to hash you'll either have > too much knowledge of SDP in MIKEY, or too much knowledge of MIKEY in > SDP. In the example above, who does the hash() on the local system? If > the SDP code does it then it has to know about creating a > MIKEY-specific > hash. If the MIKEY code does it, then it has to be given access to the > entire SDP description and it has to know how to parse it. > > This applies to both solutions 2) and 3). You can think of it as a > protocol layering violation problem. > Ok, put it like this. Some stuff that exists in SDP must be duplicated and put in MIKEY, e.g. IP address(es), and ports. This is a very common thing to put in a key management protocol, and are in general not treated as a layer violation. Then if you choose to hash it or not, that's another issue. The big issue resulting from this discussion as I see it (not only for MIKEY but to all key management protocols for secure groups) is, how do we treat NATs? If a NAT exists, you cannot bind IP addresses and ports in the key management scheme in a good way. In theory, I guess it would be possible to launch an attack (equal to Brian's where the SDP were changed), by fooling the NAT to map the incoming stream from a group wrong (assuming as Brian did that SOA is not used). This is an issue that we will look more into. I guess that NAT traversal may be a topic for a general MSEC discussion and a new thread. Some drafts on the NAT vs SDP/UDP topic from the mmusic group: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-natreq4udp-00.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-00.txt Fredrik _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jan 14 15:02:05 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16220 for ; Mon, 14 Jan 2002 15:02:05 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0343F535F2; Mon, 14 Jan 2002 14:58:48 -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 8451A535E9 for ; Mon, 14 Jan 2002 14:57:19 -0500 (EST) Received: (qmail 40843 invoked by uid 3269); 14 Jan 2002 19:57:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40840 invoked from network); 14 Jan 2002 19:57:18 -0000 Received: from lennon.multicasttech.com (HELO multicasttech.com) (root@63.105.122.7) by klesh.pair.com with SMTP; 14 Jan 2002 19:57:18 -0000 Received: from [209.178.148.205] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1225805 for ; Mon, 14 Jan 2002 14:57:11 -0500 From: "Marshall Eubanks" To: msec@securemulticast.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_===1225805====multicasttech.com===_" Subject: [MSEC] Fwd: [AVT] Unicast RTCP back traffic 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 14 Jan 2002 14:57:11 -0500 This is a multi-part MIME message --_===1225805====multicasttech.com===_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Let's try again... --- the forwarded message follows --- --_===1225805====multicasttech.com===_ Content-Type: message/rfc822 Return-Path: Received: from optimus.ietf.org ([132.151.1.19] verified) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1225716; Mon, 14 Jan 2002 14:06:03 -0500 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20398; Mon, 14 Jan 2002 14:05:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20373 for ; Mon, 14 Jan 2002 14:05:18 -0500 (EST) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13264 for ; Mon, 14 Jan 2002 14:05:15 -0500 (EST) Received: from [209.178.148.205] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1225710; Mon, 14 Jan 2002 14:05:14 -0500 From: "Marshall Eubanks" To: avt@ietf.org Cc: msec@securemulticast.org, Toerless Eckert X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Mon, 14 Jan 2002 14:05:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Subject: [AVT] Unicast RTCP back traffic Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Audio/Video Transport Working Group X-BeenThere: avt@ietf.org Content-Transfer-Encoding: 8bit Hello; Here is a first cut at the security implications and a possible fix for unicast back traffic for SSM type RTCP. This is obviously an AVT issue, I am sending it to MSEC as well. This is also available as a pdf on http://www.multicasttech.com/papers/unicast_rtcp_analysis.pdf Regards Marshall Eubanks tme@multicasttech.com --------------------------------- To : AVT, MSEC From : T.M. Eubanks Subject : Security of Unicast Back Traffic in RTCP Date : January 14, 2002 In the standard Any Source Multicast (ASM) model for the Real Time Control Protocol (RTCP), the ?back traffic? (the Receiver Reports, or RR?s, the Sender Reports, or SR?s, and possibly other user defined auxiliary data, all currently issued by a receiver as part of RTCP) is sent to the source and all receivers on a multicast group, with the back traffic bandwidth being set to a fraction of the total bandwidth, as determined at each receiver. This model must change to support Single Source Multicast (SSM), and there may be ASM or even unicast applications where SSM-like RTCP back traffic would be desirable [Chesterfield and Ott, 2001]. In the existing ASM RTCP back traffic model, data are multicast onto a group listened to by the source or sources and all receivers. For a network that only implements SSM, this is not possible, and it may not be desirable even for an ASM enabled network, as SSM only protocols should not depend on the existence of ASM network capabilities. An obvious modification of the ASM RTCP model to handle this situation is to unicast RR and other back traffic to the source, and then optionally to multicast the data (either in the form of RR?s, or as summary digests) to the receivers on a separate SSM group. In many cases, it would be convenient to separate the functions of the SSM source and the SSM RTCP server, and thus to send the unicast RTCP back traffic to an arbitrary Internet address. I will call the general case of unicast back traffic to an arbitrary location ?SSM-like? back traffic. The Problem The existence of unicast SSM-like back traffic presents a possibly serious security problem. If any receiver were to source an arbitrarily high rate of back traffic, then local resources could be overwhelmed. In addition, if every receiver were to source an arbitrarily high rate of back traffic, then the SSM RTCP report server could be overwhelmed. Even if receiver back traffic were limited to a low level for each receiver (say by specifying a limit to the rate of receiver back traffic), then it will still be possible to create problems by directing the back traffic to a different IP address. In fact, a large flow of SSM like RTCP back traffic would constitute a pre-made Distributed Denial of Service (DDOS) attack if the traffic could be redirected by an attacker. This attack is called ?packet bombing? in Chesterfield and Ott [2001]. For this security analysis, I assume that the attacker can spoof IP addresses and insert traffic in such a fashion that Reverse Path Forwarding (RPF) and other possible checks of the integrity of the IP routing are passed. (These checks are an important line of defense, but they cannot be the only defense as they can be compromised almost trivially in certain situations, for example for a multicast source on a large LAN with an exploited host.) I also assume that the attacker can become a legitimate member of the group, and thus has access to any keys or other cryptographic information available to group members. This of course makes the authentication problem much harder. For example, it means that simple symmetric key encryption of the RTCP traffic, or even of the underlying RTP traffic, as is suggested in Chesterfield and Ott [2001], will not improve the security of the SSM-like back traffic, as it must be assumed that the attacker will possess the keys. I will assume that the basic means of authentication of back traffic direction will be through cryptographic hash functions, such as MD-5 or SHA-1, coupled with public-key cryptography. These functions are described in detail in Schneier [1996]. In Chesterfield and Ott [2001], the basic means of protecting against using the back traffic for denial of service attacks is to only send back traffic to the source, and to verify the source by verifying the Session Description Protocol (SDP) message announcing the source. There are several objections to this procedure : 1.) The source may not be the appropriate place to deal with the back traffic. The source may not even be reachable by unicast from the receivers, as is the case with certain means of distributing IP data by satellite. Conversely, there may be multiple sources and it may be desirable to squelch the back traffic to most of the sources, while still sending it to others. 2.) This does not solve the security problem. I may be able to perform a denial of service on the source by spoofing the control traffic coming from the source, even if the source was originally authenticated. (For example, I could increase the amount of back traffic to a point beyond the capacity of the source to handle.) This is recognized by Chesterfield and Ott [2001], who state as requirements that - The information providing the unicast feedback address needs to be authenticated as being from a trusted source. - Data integrity of the RTCP traffic from the source, particularly RSI + LJS packets is also required. but without stating the means for achieving this. CISCO?s IPTV currently sends back unicast RTCP traffic back upon request. A new APP packet is defined and reports can only be sent to the source. This packet is protected against change by signing it with an MD5 hash [Toerless Eckert, personal communication]. Since every receiver presumably has access to the shared secret, it is hard to see how this protocol can stop spoofing of the APP messages, independent of the cryptographic weakness of the MD5 hash. Of course, there may be multicast applications where there is tight communication between sources and receivers, such that each receiver could have a unique shared secret. This is not an adequate solution, however, in the context of the current multicast service model. Another solution (suggested by Bill Fenner) is to include the back traffic information in the SDP file, which could then be subject to authentication. The problem I see with this is that it makes it impossible to change the back traffic model once it is set up (many applications/users store SDP information for long periods of time) and it also complicates the SDP model. SDP information can be sent now by SAP, by http or by e-mail. Only http could easily be changed at present to support the new authentication. A Protocol for Authenticating Back Traffic Requests In my opinion, authentication of back traffic requests requires more infrastructure than is available in Chesterfield and Ott [2001]. Here, I set forth what I see is one means of performing this authentication. The new protocol involves getting a public key for the source, presumably from a Certificate Authority (related sources could share private keys and announce the same public one). (The SDP protocol could be amended to optionally request this.) A new RTCP message, the Report Direction Message (RDM), is required. Then 1.) The source sends RDM?s containing the IP address for the source traffic the IP address for the back traffic the group (or SSM channel) address the desired bandwidth for the traffic (the receiver bandwidth of Chesterfield and Ott) and the timestamp of the RDM 2.) The RDM is signed with a cryptographic hash covering all of the items in # 1 above. 3.) The cryptographic hash is encrypted with the private key of the source. The corresponding public key could be found, e.g. from a Certificate Authority for the source. This signature, plus the cryptographic hash, is included in the RDM and multicast to the group. 4.) The RDM is optionally encrypted. 5.) The RDM is sent to the group members as part of the RTCP traffic from the sender. 6.) Each receiver verifies the RDM and uses it to direct the flow of its RTCP back traffic. This includes decryption if necessary, verifying that the cryptographic hash is correct, decryption of the RDM signature using the public key of the source, verifying that the IP address of the source matches the IP address of the incoming SSM RTP traffic, verifying that the correct group address is present, and the timestamp is in the recent past. In many situations RDM?s need not change for long periods of time. In that case, the RDM may be verified by simply checking the cryptographic hash. If the RDM does not change the direction or the rate of the back traffic, there is no reason to authenticate it further. 7.) Optionally, the receiver uses information from the received RDM to provide integrity checks in its back traffic. The most secure version of this would be to hash the return RR with some information being sent directly on the multicast group, which would verify that the receiver was actually receiving the multicast data. Also, there needs to be an upper limit to the amount of RTCP traffic a receiver may source, of order 1 message per second, as there is no reason to allow an arbitrarily large amount of back traffic from any specific receiver. Possible attacks on this protocol include : 1.) The conflict attack. If I can take a valid RPM message from the source, modify information (say the IP address of the RTCP server) and then find a variant of the compromised message that has the same cryptographic hash as the original RPM message, then the receiver has no way of knowing that the message has been corrupted, as this message will give the same public key signature as the original. This is why it is necessary to digitally sign the RDM message, as otherwise the attacker could simply modify the RDM as desired, and generate a new cryptographic hash for the new message. It is reasonable to assume that MD5 is subject to conflict attacks [Dobbertin, 1996], which is presumably why the IESG has ruled its use out for new protocols. It is often stated that the keyed HMAC-MD5 extension of MD5 [RFC2403, 1998] is still secure. However, this is clearly not the case for this protocol. The additional security for HMAC-MD5 comes from the use of a key. Since, in this case, the attacker must be presumed to know the key (which must be shared with the entire multicast group), the HMAC-MD5 hash could be compromised in roughly the same time as an unprotected MD5 hash. 2.) The birthday attack. This is not much of a worry. The SHA-1 algorithm produces a 160 bit hash function. The number of messages from the same authority that would have to be searched to have a 50% chance of finding a pair of messages producing the same hash function is thus about 2^80. If there were 1 Giga-RPM messages produced per second from one authority, it would take 38 million years to find such a pair. 3.) The replay attack. If I capture a valid RDM message, I can replay it. The utility of this is limited by including the group and source address in the RDM hash (this makes it impossible to send the traffic from a very populated group to the SSM RTCP server for a much lower bandwidth group). If a (S,G) is being reused by a sloppy source, an attack would be possible by reusing a RDM from a high bandwidth application for a lower bandwidth one. The best way to prevent this would be to include a timestamp, and only allow RDM?s to be valid for a limit period (say 180 seconds). Conclusions I see no way to authenticate RDM type information for large public SSM sessions without using public key cryptography. This is much slower than symmetric key cryptography, which may be a problem for this protocol. On the other hand, it is only necessary to protect an RDM for the duration of its validity, and one key verification per minute (which can be done entirely at the receiver once the public key for the source is obtained) does not sound especially onerous. This rate can be kept even lower if, as is reasonable for many applications, the contents of the RDM message are not changed for long periods of time. One specific conclusion I reached is that HMAC-MD5 for this application is to be avoided. I recommend that SHA-1 be used instead. This protocol imposes a fair amount of extra complexity into the SSM service model. The response of some application developers may be not to make use of back traffic authentication. In that case, a reasonable question is whether multicast is better served by simply not sending any RTCP back traffic at all, or whether RTCP should include a low bandwidth default for back traffic information to the source (under the assumption that extremely large groups could afford to pay for the extra complexity of authentication if the back traffic bandwidth became problematic). If the default were to unicast one message to the source every 50 seconds in the absence of valid authentication, then (assuming that the message were 500 bytes), then it would take 700 group members to saturate a dial-up connection, and several thousand to saturate a typical DSL connection. Whether this is a reasonable risk is open to debate. References [Dobbertin, 1996] The Status of MD5 after a Recent Attack, Hans Dobbbertin, CryptoBytes, Vol. 2, 1-5, 1996. [Chesterfield and Ott, 2001] RTCP Extension for Single Source Multicast Sessions with Unicast RTCP feedback, Julian Chesterfield and Joerg Ott, draft-chesterfield-avt-rtcpssm-02.txt, 2001. [RFC2104, 1997] HMAC: Keyed-Hashing for Message Authentication, H. Krawczyk, M. Bellare, and R. Canetti, IETF Request for Comments: 2104, 1997. [RFC2403, 1998] The Use of HMAC-MD5-96 within ESP and AH, C. Madson and R. Glenn, IETF Request for Comments: 2403, 1998. [Schneier, 1996] Applied Cryptography, Bruce Schneier, J. Wiley, 1996. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org http://www1.ietf.org/mailman/listinfo/avt --_===1225805====multicasttech.com===_-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jan 14 16:09:18 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19333 for ; Mon, 14 Jan 2002 16:09:18 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C7E365363A; Mon, 14 Jan 2002 16:08:27 -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 14F7A53664 for ; Mon, 14 Jan 2002 16:06:57 -0500 (EST) Received: (qmail 51166 invoked by uid 3269); 14 Jan 2002 21:06:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51162 invoked from network); 14 Jan 2002 21:06:56 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 14 Jan 2002 21:06:56 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0EL5jF04310; Mon, 14 Jan 2002 13:05:45 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (sjc-vpn3-479.cisco.com [10.21.65.223]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAQ43835; Mon, 14 Jan 2002 13:05:17 -0800 (PST) Message-Id: <4.3.2.7.2.20020114125733.06aa4930@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Fredrik Lindholm (ERA)" From: Mark Baugher Cc: "'Brian Weis'" , msec@securemulticast.org, "'mmusic@ietf.org'" , "Elisabetta Carrara (ERA)" , jari.arkko@ericsson.com, Mats =?iso-8859-1?Q?N=E4slund?= (ERA) , "'Rolf Blom'" In-Reply-To: <0DAEDF148988D411BB980008C7E65D2E04FE3F9A@esealnt416> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: [MMUSIC] RE: RE: MIKEY mapping of keys to steams -- possible vulnerabilit y 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 14 Jan 2002 13:03:42 -0800 After exchanging some private notes and considering the nature of an attack using the CS identifiers, I don't think the issue that I raised about security dependencies between MIKEY and SDP amounts to very much. thanks, Mark At 11:43 AM 1/14/2002 +0100, Fredrik Lindholm (ERA) wrote: >Brian, Mark, > >"Independence of the security of the underlying >transport" means that no security mechanism of >the underlying transport is used to protect the >MIKEY message. However, the intention was not >to let people think that MIKEY would solve all >the problems that will come from using SIP, RTSP >and SDP. I guess the formulation may be a bit >misguiding, but I will put a clarification of >this. > >More comments below. > > > > > > 3) An idea, similar to the one you proposed. Instead of > > including the hash of some specific field, a hash over a > > well-defined subset or the entire SDP description could be > > provided (but not as input to any id), i.e. set q = hash(the > > sdp lines, except "a=keymgmt-data:..."). Let the > > signature/MAC in MIKEY include q. The hash could in this case > > be as just another payload in MIKEY. It would of course be > > authenticated and the result would be equal to that in 2). > > This will however have the same NAT problems as in 2). This > > approach will have the disadvantage that we might need to > > build in too much knowledge about SDP in MIKEY. > > > > Yes, I think that no matter what you choose to hash you'll either have > > too much knowledge of SDP in MIKEY, or too much knowledge of MIKEY in > > SDP. In the example above, who does the hash() on the local system? If > > the SDP code does it then it has to know about creating a > > MIKEY-specific > > hash. If the MIKEY code does it, then it has to be given access to the > > entire SDP description and it has to know how to parse it. > > > > This applies to both solutions 2) and 3). You can think of it as a > > protocol layering violation problem. > > > > >Ok, put it like this. Some stuff that exists in >SDP must be duplicated and put in MIKEY, e.g. IP >address(es), and ports. This is a very common >thing to put in a key management protocol, and >are in general not treated as a layer violation. >Then if you choose to hash it or not, that's >another issue. > >The big issue resulting from this discussion as >I see it (not only for MIKEY but to all key >management protocols for secure groups) is, how >do we treat NATs? If a NAT exists, you cannot >bind IP addresses and ports in the key management >scheme in a good way. In theory, I guess it would >be possible to launch an attack (equal to Brian's >where the SDP were changed), by fooling the NAT >to map the incoming stream from a group wrong >(assuming as Brian did that SOA is not used). >This is an issue that we will look more into. I >guess that NAT traversal may be a topic for a >general MSEC discussion and a new thread. > >Some drafts on the NAT vs SDP/UDP topic from the >mmusic group: >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-natreq4udp-00.txt >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-00.txt > > >Fredrik > > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jan 15 15:16:19 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11986 for ; Tue, 15 Jan 2002 15:16:18 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3E95A5376C; Tue, 15 Jan 2002 15:14:45 -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 BE5265369D for ; Tue, 15 Jan 2002 15:13:07 -0500 (EST) Received: (qmail 35567 invoked by uid 3269); 15 Jan 2002 20:13:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35564 invoked from network); 15 Jan 2002 20:13:07 -0000 Received: from unknown (HELO darkstar.cpovo.net) (200.174.229.130) by klesh.pair.com with SMTP; 15 Jan 2002 20:13:07 -0000 X-Internal-ID: 3C35C3CA00068FE9 Received: from homelxptx6b7q6 (200.248.244.178) by darkstar.cpovo.net (NPlex 2.0.108); 15 Jan 2002 18:12:39 -0200 Message-ID: <001101c19e00$cc6ba5c0$b2f4f8c8@homelxptx6b7q6> From: "Sandro Rafaeli" To: , 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [MSEC] I-D ACTION:draft-rafaeli-lkh2-00.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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 15 Jan 2002 18:11:18 -0200 Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LKH+2: An improvement on the LKH+ algorithm for removal operations Author(s) : S. Rafaeli, L. Mathy and D. Hutchison Filename : draft-rafaeli-lkh2-00.txt Pages : 13 Date : January-02 Several algorithms have been proposed to deal with the group key management problem. The most promising are those based on Logical Key Hierarchies (LKH). An LKH reduces the size of the rekey messages, reducing also the storage and processing requirements. An improved LKH algorithm called LKH+2 is described here. Using LKH+2, a group manager can use keys already in the tree to derive new keys. Using previously known keys saves information to be transmitted to members when a membership change occurs and new keys have to be created or updated. LKH+2 achieves K log_2 n message size (K is the size of a key) for leave operations. It is also shown that the LKH+2 algorithm does not increase the storage and processing requirements when compared to other LKH schemes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rafaeli-lkh2-00.txt _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jan 18 11:29:03 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17319 for ; Fri, 18 Jan 2002 11:29:03 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1597F53D10; Fri, 18 Jan 2002 11:28: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 4333A53A8C for ; Fri, 18 Jan 2002 06:57:48 -0500 (EST) Received: (qmail 53067 invoked by uid 3269); 18 Jan 2002 11:57:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53064 invoked from network); 18 Jan 2002 11:57:47 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 18 Jan 2002 11:57:47 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07421; Fri, 18 Jan 2002 06:57:40 -0500 (EST) Message-Id: <200201181157.GAA07421@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-gdoi-03.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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 06:57:40 -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 : The Group Domain of Interpretation Author(s) : M. Baugher et al. Filename : draft-ietf-msec-gdoi-03.txt Pages : 31 Date : 17-Jan-02 This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The 'GDOI' incorporates the definition of a Phase 1 SA of the Internet DOI, and proposes new payloads and exchanges according to the ISAKMP standard. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-03.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-gdoi-03.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-gdoi-03.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: <20020117103351.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gdoi-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gdoi-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020117103351.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jan 18 11:30:17 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17424 for ; Fri, 18 Jan 2002 11:30:17 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 164A553D15; Fri, 18 Jan 2002 11:28: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 1846453C3A for ; Fri, 18 Jan 2002 09:42:11 -0500 (EST) Received: (qmail 69048 invoked by uid 3269); 18 Jan 2002 14:42:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69045 invoked from network); 18 Jan 2002 14:42:10 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 18 Jan 2002 14:42:10 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12878; Fri, 18 Jan 2002 09:42:07 -0500 (EST) Message-Id: <200201181442.JAA12878@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-gdoi-03.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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 09:42:06 -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 : The Group Domain of Interpretation Author(s) : M. Baugher et al. Filename : draft-ietf-msec-gdoi-03.txt Pages : 31 Date : 17-Jan-02 This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The 'GDOI' incorporates the definition of a Phase 1 SA of the Internet DOI, and proposes new payloads and exchanges according to the ISAKMP standard. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-03.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-gdoi-03.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-gdoi-03.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: <20020117103351.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gdoi-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gdoi-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020117103351.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jan 18 12:33:18 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19943 for ; Fri, 18 Jan 2002 12:33:17 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 376CC53CD3; Fri, 18 Jan 2002 12:29:25 -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 EEC3953D2C for ; Fri, 18 Jan 2002 12:27:23 -0500 (EST) Received: (qmail 88763 invoked by uid 3269); 18 Jan 2002 17:27:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88760 invoked from network); 18 Jan 2002 17:27:19 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 18 Jan 2002 17:27:19 -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 g0IHQci09460; Fri, 18 Jan 2002 12:26: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 g0IHQcJ08198; Fri, 18 Jan 2002 12:26:38 -0500 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id MAA25550; Fri, 18 Jan 2002 12:26:38 -0500 From: Ran Canetti Message-Id: <200201181726.MAA25550@ornavella.watson.ibm.com> To: msec@securemulticast.org Cc: jis@mit.edu, mleech@nortelnetworks.com Subject: [MSEC] GDOI: Last call for proposed standard Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 12:26:38 -0500 Folks, Following the discussion in the last meeting, I'd like to initiate a formal last-call process for moving GDOI to proposed standard. (This is the first level in the standards ladder.) Please take time within the next two weeks (i.e., before 2/2/2) to make another pass over the draft and make sure you agree with what's written there. If there will be no substantial corrections to make, we will pass the draft to the IESG for approval. The new version of the draft contains the fix discussed on the list to the security flaw discovered by Cathy's protocol analyzer last month. Best, Ran > From: Internet-Drafts@ietf.org > > 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 : The Group Domain of Interpretation > Author(s) : M. Baugher et al. > Filename : draft-ietf-msec-gdoi-03.txt > Pages : 31 > Date : 17-Jan-02 > > This document presents an ISAMKP Domain of Interpretation (DOI) for > group key management to support secure group communications. The > 'GDOI' incorporates the definition of a Phase 1 SA of the Internet > DOI, and proposes new payloads and exchanges according to the ISAKMP > standard. The GDOI manages group security associations, which are > used by IPSEC and potentially other data security protocols running > at the IP or application layers. These security associations protect > one or more key-encrypting keys, traffic-encrypting keys, or data > shared by group members. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-03.txt > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jan 18 14:06:01 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23764 for ; Fri, 18 Jan 2002 14:06:01 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CCA4E53665; Fri, 18 Jan 2002 14:04:09 -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 DBEE053E29 for ; Fri, 18 Jan 2002 14:02:20 -0500 (EST) Received: (qmail 1341 invoked by uid 3269); 18 Jan 2002 19:02:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1338 invoked from network); 18 Jan 2002 19:02:20 -0000 Received: from zcars0m9.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by klesh.pair.com with SMTP; 18 Jan 2002 19:02:20 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0IJ1gf02827 for ; Fri, 18 Jan 2002 14:01:43 -0500 (EST) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0IJ1eO29755 for ; Fri, 18 Jan 2002 14:01:40 -0500 (EST) Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CFL6RR8M; Fri, 18 Jan 2002 14:01:39 -0500 Received: from nortelnetworks.com (dhcp225-228.engeast.baynetworks.com [192.32.225.228]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XRHA1Q1L; Fri, 18 Jan 2002 14:01:39 -0500 Message-ID: <3C48723D.2F329102@nortelnetworks.com> From: Lakshminath Dondeti X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Subject: Re: [MSEC] I-D ACTION:draft-ietf-msec-gdoi-03.txt References: <200201181442.JAA12878@ietf.org> Content-Type: text/plain; charset=us-ascii 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 14:06:37 -0500 Content-Transfer-Encoding: 7bit GDOI authors, Some comments and questions, mostly minor, on the latest version follow. ++++++ Missing Section 6 (Application Scenarios) Several keywords and phrases have ?? marks around them in page 3! Page 4, para 1: GDOI sender (or should it be GCKS?) encrypts the GROUPKEY-PUSH message using the KEK Re-key SA. Section 3.0, para1: "The GROUPKEY-PULL exchange downloads the group key encrypting key (KEK) or KEK array under the protection of the Phase 1 SA." What about TEK(s) and the Data Security SA? Section 3.2: *an* Phase 2 4.6: Could the delete payload go anywhere in the PUSH message? Does it mean delete all SAs? Can we delete (expiring SAs based on criteria other than time, for example) some of the SAs and keep others around? Use of the word Initiator is confusing (3.3 and 4.7). It could be Rekey initiator in Section 4.7, to distinguish from the earlier use in the context of the Registration message (PUSH). 5.3: Is SAK an IPsec SA as well? 5.5.1.1. Brian, is the change -we agreed on during the interop testing- for sending TEK attributes regardless of whether we are using DES or 3DES still valid? FIO, it was to send 64 bits in case of DES, 192 bits in case of 3DES and so on. In other words, keys are bunched together, so we only send one TEK_ALGORITHM_KEY attribute instead of 3 in case of 3DES for example. References: No references to other MSEC drafts (existing and forthcoming) :) I will comment separately on the last call and the issues thereof :-) best regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jan 18 18:55:29 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01132 for ; Fri, 18 Jan 2002 18:55:29 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 12D5753DF7; Fri, 18 Jan 2002 18:52: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 5D77D53D8F for ; Fri, 18 Jan 2002 17:26:08 -0500 (EST) Received: (qmail 27272 invoked by uid 3269); 18 Jan 2002 22:26:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 27269 invoked from network); 18 Jan 2002 22:26:07 -0000 Received: from mailbox1.cc.stevens-tech.edu (155.246.1.26) by klesh.pair.com with SMTP; 18 Jan 2002 22:26:07 -0000 Received: by mailbox1.cc.stevens-tech.edu (Postfix, from userid 99) id 46AE546095; Fri, 18 Jan 2002 17:25:57 -0500 (EST) To: msec@securemulticast.org Message-ID: <1011392757.3c48a0f542e9f@mailbox1.cc.stevens-tech.edu> From: rarmente@stevens-tech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8-cvs Subject: [MSEC] Please, would somebody tell me about msec? 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 17:25:57 -0500 (EST) Content-Transfer-Encoding: 8bit I am ruinning linux mandrake and I just found out that they use a program "msec" and I wonder if this has anything to do with the msec in this maling list. Is msec for mac only or was it ported to linux as well. Please, I would appreciate if somebody gives me a little description of msec to see if it matches the one I have installed on my system. "I hope they match." Roberto _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jan 18 19:10:03 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01397 for ; Fri, 18 Jan 2002 19:10:03 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E53CE53E41; Fri, 18 Jan 2002 19:04: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 4E6CF53B99 for ; Fri, 18 Jan 2002 19:03:14 -0500 (EST) Received: (qmail 40941 invoked by uid 3269); 19 Jan 2002 00:03:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40932 invoked from network); 19 Jan 2002 00:03:12 -0000 Received: from softdnserror (HELO nisser.cisco.com) (171.71.176.85) by klesh.pair.com with SMTP; 19 Jan 2002 00:03:12 -0000 Received: from cisco.com (dhcp-128-107-163-191.cisco.com [128.107.163.191]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA19524; Fri, 18 Jan 2002 16:02:29 -0800 (PST) Message-ID: <3C48B794.86676AED@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lakshminath Dondeti Cc: msec@securemulticast.org Subject: Re: [MSEC] I-D ACTION:draft-ietf-msec-gdoi-03.txt References: <200201181442.JAA12878@ietf.org> <3C48723D.2F329102@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 18 Jan 2002 16:02:28 -0800 Content-Transfer-Encoding: 7bit Hi Lakshminath, Many thanks for your comments. Lakshminath Dondeti wrote: > > GDOI authors, > > Some comments and questions, mostly minor, on the latest version follow. > > ++++++ > Missing Section 6 (Application Scenarios) This section was mostly background information and while it was helpful throughout the development of GDOI we didn't deem it appropriate for an RFC. The content of the old section 6 was summarized in a new section 1.1. > Several keywords and phrases have ?? marks around them in page 3! Thanks for pointing that out. The double-quotes were mis-translated when converting from Word. > Page 4, para 1: GDOI sender (or should it be GCKS?) encrypts the > GROUPKEY-PUSH message using the KEK Re-key SA. Yes, we should specifically say GCKS. > Section 3.0, para1: > > "The GROUPKEY-PULL exchange downloads the group key encrypting key > (KEK) or KEK array under the protection of the Phase 1 SA." > > What about TEK(s) and the Data Security SA? Seems like they ought be added here too. > Section 3.2: > *an* Phase 2 Got it. > 4.6: Could the delete payload go anywhere in the PUSH message? > Does it mean delete all SAs? Can we delete (expiring SAs based on > criteria other than time, for example) some of the SAs and keep others > around? Where the Delete payload is placed in the push message is not well enough defined. I propose that it should follow the SEQ payload. That is, <---- HDR*, SEQ, [D,] SA, KD, [CERT,] SIG I further propose that if the GCKS has no more SAs to send in the GROUPKEY-PUSH message the the SA and KD payloads be omitted, so that the full message is as follows: <---- HDR*, SEQ, D, [CERT,] SIG Regarding the format of the payload, by 'ISAKMP Delete payload" we meant those defined in section 3.15 of RFC 2408. That definition has an explicit format, including a Protocol-Id and list of SPIs for that Protocol-Id. So it can't mean "delete all SPIs"; you have to itemize them. GDOI does have a TEK Protocol-Id field and we've defined SPIs for TEKs so that fits nicely. I'll add text declaring that the Protocol-ID namespace for Delete payloads is the same as the TEK namespace. This section makes no judgment about why a peer chose to delete the SA (e.g., by time, or by user intervention) so no such criteria is mentioned. > Use of the word Initiator is confusing (3.3 and 4.7). It could be > Rekey initiator in Section 4.7, to distinguish from the earlier use > in the context of the Registration message (PUSH). Good point. Initiator/Responder terminology make sense in the registration message, but not completely in the rekey message. I'll change Section 4.7 to be "GCKS Operations" and 4.8 to be "Group Member Operations". > 5.3: Is SAK an IPsec SA as well? The identity fields were added to convey to the group member how the rekey message will be sent. E.g., in the multicast case what is the valid sender (source in the IP header), and multicast group (dest in the IP header), as well as defining the protocol and port. We specified he same format for identities as in the TEK SA (i.e., IPSEC identities) for simplicity. These identities give us both IPv4 and IPv6 identity types. > 5.5.1.1. Brian, is the change -we agreed on during the interop > testing- > for sending TEK attributes regardless of whether we are using DES or > 3DES > still valid? Yes, absolutely -- I'll add text clarifying this. > FIO, it was to send 64 bits in case of DES, 192 bits in case of 3DES and > so > on. In other words, keys are bunched together, so we only send one > TEK_ALGORITHM_KEY attribute instead of 3 in case of 3DES for example. > > References: No references to other MSEC drafts (existing and > forthcoming) :) Right. Referencing I-Ds in a standards-track RFC is tricky so we removed references to all I-Ds. It can be done in a limited way, but we thought it would be safer to not refer to them at this time. Thanks! Brian > I will comment separately on the last call and the issues thereof :-) > > best regards, > Lakshminath > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- 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 Mon Jan 21 13:51:56 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19877 for ; Mon, 21 Jan 2002 13:51:55 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 66CA653A7F; Mon, 21 Jan 2002 13:46:37 -0500 (EST) Delivered-To: msec@pairlist.net Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by pairlist.net (Postfix) with ESMTP id 938035359C for ; Mon, 21 Jan 2002 13:44:02 -0500 (EST) Received: from cisco.com (dhcp-128-107-163-191.cisco.com [128.107.163.191]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA06746 for ; Mon, 21 Jan 2002 10:44:01 -0800 (PST) Message-ID: <3C4C616C.67AB6CD7@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: msec@lists.securemulticast.org Content-Type: multipart/mixed; boundary="------------52EF63ED4A18020BF3CB66B6" Subject: [MSEC] [Fwd: Questions on GDOI] Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 21 Jan 2002 10:43:56 -0800 This is a multi-part message in MIME format. --------------52EF63ED4A18020BF3CB66B6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------52EF63ED4A18020BF3CB66B6 Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3C4876E5.FCC8426F@cisco.com> Date: Fri, 18 Jan 2002 11:26:29 -0800 From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ran Canetti CC: mbaugher@cisco.com, hh@sparta.com, thardjono@mediaone.net Subject: Re: Questions on GDOI References: <200201181840.NAA34140@ornavella.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Ran, Ran Canetti wrote: > > Hey. I have a question on version 03: > > In section 5.7 you say: > > The GCKS, GCKS delegate or member signs a prf (i.e., RFC 2409 keyed > MAC) of the following values: > POP_HASH = prf("pop" | Ni | Nr) > > My question: How is the prf keyed? what is the key? > (in fact, is a key needed here at all or is a regular, unkeyed hash enough?) Ooops. I guess we have our first "last call" comment. :-) Indeed we meant for this to be a hash, not an HMAC. The use of "prf" is incorrect. This should say The GCKS, GCKS delegate or member signs a hash of the following values: POP_HASH = hash("pop" | Ni | Nr) And, I think we'll have to define the syntax of hash() someplace. Thanks for the catch! Brian > Thx, > > Ran > -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --------------52EF63ED4A18020BF3CB66B6-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jan 30 12:13:31 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25679 for ; Wed, 30 Jan 2002 12:13:31 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D64F85364E; Wed, 30 Jan 2002 12:12:06 -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 4A1DA5363F for ; Wed, 30 Jan 2002 12:08:33 -0500 (EST) Received: (qmail 95093 invoked by uid 3269); 30 Jan 2002 17:08:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95090 invoked from network); 30 Jan 2002 17:08:32 -0000 Received: from zcars0m9.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by klesh.pair.com with SMTP; 30 Jan 2002 17:08:32 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0UH7N817806; Wed, 30 Jan 2002 12:07:23 -0500 (EST) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0UH7Jh27001; Wed, 30 Jan 2002 12:07:19 -0500 (EST) Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CFL6R8TG; Wed, 30 Jan 2002 12:07:17 -0500 Received: from nortelnetworks.com (dhcp225-242.engeast.baynetworks.com [192.32.225.242]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XRHA1RNB; Wed, 30 Jan 2002 12:07:17 -0500 Message-ID: <3C58299C.E7B44B93@nortelnetworks.com> From: Lakshminath Dondeti X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ran Canetti Cc: msec@securemulticast.org, jis@mit.edu, "Marcus Leech" , thardjono@verisign.com Subject: Re: [MSEC] GDOI: Last call for proposed standard References: <200201181726.MAA25550@ornavella.watson.ibm.com> Content-Type: text/plain; charset=us-ascii 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 30 Jan 2002 12:13:00 -0500 Content-Transfer-Encoding: 7bit I was at the last meeting and as I recall the only one to have some reservations about the last call. First, I would like to state that I am very much interested in seeing GDOI (preferably a modified version :-), I can wish, can't I?) as a standard. That said, here are the two problems I see with the current version. For those at the SLC meeting, this may be a repetition. 1) The PUSH message: For scalable and reliable transport of batch rekey messages, it may be appropriate to have two types of PUSH messages. Briefly, for group initialization and batch rekeying, the rekey/PUSH message can get too long (initialization of a logical hierarchy with n=2^16 members requires sending 2^16 KP payloads = ~2845 packets; note that each member needs only logn = 16 KP payloads = ~1 packet. There are proposals in the literature for various groupings of keys for efficient transport). Proposal: Allow splitting PUSH messages. 2) LKH definitions: LKH interoperability issues need further discussion. That stuff might be pulled out of the GDOI draft; instead the authors might propose generic payloads that accommodate any key management algorithm. Besides, Sun has a PATENT on LKH. Of course, LKH is also published as an RFC by another group. I am not a lawyer, so I don't understand how that can be resolved. Proposal: Make GDOI LKH independent. Thanks much. best regards, Lakshminath Ran Canetti wrote: > > Folks, > > Following the discussion in the last meeting, I'd like to initiate a formal > last-call process for moving GDOI to proposed standard. (This is the > first level in the standards ladder.) Please take time within the next two > weeks (i.e., before 2/2/2) to make another pass over the draft and make > sure you agree with what's written there. If there will be no substantial > corrections to make, we will pass the draft to the IESG for approval. > > The new version of the draft contains the fix discussed on the list to > the security flaw discovered by Cathy's protocol analyzer last month. > > Best, > > Ran > > > From: Internet-Drafts@ietf.org > > > > 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 : The Group Domain of Interpretation > > Author(s) : M. Baugher et al. > > Filename : draft-ietf-msec-gdoi-03.txt > > Pages : 31 > > Date : 17-Jan-02 > > > > This document presents an ISAMKP Domain of Interpretation (DOI) for > > group key management to support secure group communications. The > > 'GDOI' incorporates the definition of a Phase 1 SA of the Internet > > DOI, and proposes new payloads and exchanges according to the ISAKMP > > standard. The GDOI manages group security associations, which are > > used by IPSEC and potentially other data security protocols running > > at the IP or application layers. These security associations protect > > one or more key-encrypting keys, traffic-encrypting keys, or data > > shared by group members. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-03.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 Wed Jan 30 22:58:08 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09343 for ; Wed, 30 Jan 2002 22:58:08 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 570B653F93; Wed, 30 Jan 2002 22:56:51 -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 8408D53587 for ; Wed, 30 Jan 2002 20:31:45 -0500 (EST) Received: (qmail 67868 invoked by uid 3269); 31 Jan 2002 01:31:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67865 invoked from network); 31 Jan 2002 01:31:44 -0000 Received: from nisser.cisco.com (171.71.176.85) by klesh.pair.com with SMTP; 31 Jan 2002 01:31:44 -0000 Received: from cisco.com (dhcp-128-107-163-191.cisco.com [128.107.163.191]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA29392; Wed, 30 Jan 2002 17:29:09 -0800 (PST) Message-ID: <3C589DDE.8A20A2CF@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lakshminath Dondeti Cc: Ran Canetti , msec@securemulticast.org, jis@mit.edu, Marcus Leech , thardjono@verisign.com Subject: Re: [MSEC] GDOI: Last call for proposed standard References: <200201181726.MAA25550@ornavella.watson.ibm.com> <3C58299C.E7B44B93@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 30 Jan 2002 17:29:02 -0800 Content-Transfer-Encoding: 7bit Hi Lakshminath, As always, thanks for your comments. I'm going to deal with the issues in reverse order: > 2) LKH definitions: LKH interoperability issues need further > discussion. That stuff might be pulled out of the GDOI draft; instead > the authors might propose generic payloads that accommodate any > key management algorithm. We would prefer not to pull the LKH text out of the draft since we think it provides a substantial benefit of allowing group membership changes in the rekey message. However, we do indeed mean to accommodate other key management algorithms, not just LKH. > Besides, Sun has a PATENT on LKH. Of course, LKH is also published > as an RFC by another group. I am not a lawyer, so I don't understand > how that can be resolved. I wasn't aware that anyone claimed IP on key hierarchies. LKH is certainly defined in RFC2627 though, and I have seen companies claim that they use the algorithm in their systems. So it seems safe to declare how it would be used in GDOI since it isn't intended to be a required feature. > Proposal: Make GDOI LKH independent. There's (at least) two facets to independence. A. Making sure LKH isn't a required feature for an implementation. This will be clarified in the draft. B. Making sure that other key management algorithms can be used. The attribute list in section 5.5 lists possible key download types. There are two KEK related types: KEK (which defines a single key for the group), and LKH (which defines an LKH structure of keys). The list also has RESERVED and PRIVATE USE namespaces which were intended to be used for defining new key management types, as necessary. In particular, whatever type of key management policy becomes defined the MSEC GKMARCH document should be allocated from the RESERVED list at a later time via the standard IANA namespace allocation process. > 1) The PUSH message: For scalable and reliable transport of batch > rekey messages, it may be appropriate to have two types of PUSH > messages. > > Briefly, for group initialization and batch rekeying, the rekey/PUSH > message can get too long (initialization of a logical hierarchy with > n=2^16 members requires sending 2^16 KP payloads = ~2845 packets; note > that each member needs only logn = 16 KP payloads = ~1 packet. There > are proposals in the literature for various groupings of keys for > efficient transport). > > Proposal: Allow splitting PUSH messages. Actually I thought splitting the messages could be achieved with what's in the draft now, at least with respect to dealing with large LKH updates. There is a single LKH attribute in the KD payload. That LKH attribute is defined in section 5.5.3 as a list of attributes. Each KEK_LKH attribute is specific to one leaf (i.e., user). If multiple leafs need to be rekeyed by a group membership change, then multiple KEK_LKH attributes should be included. But nothing says that all of the leafs for a particular change need to be in a single rekey packet. It should be feasible to split up the attributes into multiple messages. It would be necessary for each message to be a full rekey message including the SA payload as well, since the SA payload defines the policy for the KD payload. Does that seem sufficient to you? Thanks, Brian --- 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 Thu Jan 31 18:28:45 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15514 for ; Thu, 31 Jan 2002 18:28:44 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 791345368E; Thu, 31 Jan 2002 18:28:00 -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 C116D54048 for ; Thu, 31 Jan 2002 18:25:43 -0500 (EST) Received: (qmail 43668 invoked by uid 3269); 31 Jan 2002 23:25:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 43664 invoked from network); 31 Jan 2002 23:25:42 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 31 Jan 2002 23:25:42 -0000 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0VNOmc18910; Thu, 31 Jan 2002 17:24:48 -0600 (CST) Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) by zsc4c000.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D2484RNX; Thu, 31 Jan 2002 15:24:46 -0800 Received: from nortelnetworks.com (dhcp225-242.engeast.baynetworks.com [192.32.225.242]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XRHA1R49; Thu, 31 Jan 2002 18:24:44 -0500 Message-ID: <3C59D393.6233BCA0@nortelnetworks.com> From: Lakshminath Dondeti X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Brian Weis Cc: Ran Canetti , msec@securemulticast.org, jis@mit.edu, "Marcus Leech" , thardjono@verisign.com Subject: Re: [MSEC] GDOI: Last call for proposed standard References: <200201181726.MAA25550@ornavella.watson.ibm.com> <3C58299C.E7B44B93@nortelnetworks.com> <3C589DDE.8A20A2CF@cisco.com> Content-Type: text/plain; charset=us-ascii 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: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 31 Jan 2002 18:30:27 -0500 Content-Transfer-Encoding: 7bit Brian, Many thanks for the reply. Please see inline. Brian Weis wrote: > > Hi Lakshminath, > > As always, thanks for your comments. I'm going to deal with the issues > in reverse order: > > > 2) LKH definitions: LKH interoperability issues need further > > discussion. That stuff might be pulled out of the GDOI draft; instead > > the authors might propose generic payloads that accommodate any > > key management algorithm. > > We would prefer not to pull the LKH text out of the draft since we think > it provides a substantial benefit of allowing group membership changes > in the rekey message. However, we do indeed mean to accommodate other > key management algorithms, not just LKH. > > > Besides, Sun has a PATENT on LKH. Of course, LKH is also published > > as an RFC by another group. I am not a lawyer, so I don't understand > > how that can be resolved. > > I wasn't aware that anyone claimed IP on key hierarchies. LKH is > certainly defined in RFC2627 though, and I have seen companies claim > that they use the algorithm in their systems. So it seems safe to > declare how it would be used in GDOI since it isn't intended to be a > required feature. > > > Proposal: Make GDOI LKH independent. > > There's (at least) two facets to independence. > > A. Making sure LKH isn't a required feature for an implementation. This > will be clarified in the draft. > > B. Making sure that other key management algorithms can be used. The > attribute list in section 5.5 lists possible key download types. There > are two KEK related types: KEK (which defines a single key for the > group), and LKH (which defines an LKH structure of keys). The list also > has RESERVED and PRIVATE USE namespaces which were intended to be used > for defining new key management types, as necessary. In particular, > whatever type of key management policy becomes defined the MSEC GKMARCH > document should be allocated from the RESERVED list at a later time via > the standard IANA namespace allocation process. Thanks. I noticed that -02- has references to OFT, but -03- did not. It may be because you did not want to have references to I-Ds. But, in its current state, it appears from Section 5.3.2 that LKH is the only choice (especially to someone not familiar with research in this area) for a KEK_MANAGEMENT_ALGORITHM. > > > 1) The PUSH message: For scalable and reliable transport of batch > > rekey messages, it may be appropriate to have two types of PUSH > > messages. > > > > Briefly, for group initialization and batch rekeying, the rekey/PUSH > > message can get too long (initialization of a logical hierarchy with > > n=2^16 members requires sending 2^16 KP payloads = ~2845 packets; note > > that each member needs only logn = 16 KP payloads = ~1 packet. There > > are proposals in the literature for various groupings of keys for > > efficient transport). > > > > Proposal: Allow splitting PUSH messages. > > Actually I thought splitting the messages could be achieved with what's > in the draft now, at least with respect to dealing with large LKH > updates. There is a single LKH attribute in the KD payload. That LKH > attribute is defined in section 5.5.3 as a list of attributes. Each > KEK_LKH attribute is specific to one leaf (i.e., user). If multiple > leafs need to be rekeyed by a group membership change, then multiple > KEK_LKH attributes should be included. But nothing says that all of the > leafs for a particular change need to be in a single rekey packet. It > should be feasible to split up the attributes into multiple messages. > > It would be necessary for each message to be a full rekey message > including the SA payload as well, since the SA payload defines the > policy for the KD payload. Splitting the rekey message would have some overhead. But including the SA payload with each message (within a rekeying instance, i.e., same SPI) would make it even worse. Consider that we may end up sending hundreds of these messages per rekey instance. In any event, I wanted to bring this discussion to the mailing list. Looks like no one else is interested in it anyway :-). Furthermore, there are some advantages to including the SA payload with each message. It would be good if you could add some text reflecting this discussion in the I-D (soon to be RFC). Many thanks. best regards, Lakshminath > > Does that seem sufficient to you? > > Thanks, > Brian > > --- > 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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec