From msec-admin@securemulticast.org Mon Sep 1 12:10:22 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08920 for ; Mon, 1 Sep 2003 12:10:22 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EE1A05369C; Mon, 1 Sep 2003 12:08:29 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C48AC53991 for ; Mon, 1 Sep 2003 12:06:14 -0400 (EDT) Received: (qmail 7278 invoked by uid 3269); 1 Sep 2003 16:06:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7275 invoked from network); 1 Sep 2003 16:06:14 -0000 Received: from avocet.mail.pas.earthlink.net (207.217.120.50) by klesh.pair.com with SMTP; 1 Sep 2003 16:06:14 -0000 Received: from user-uiveqb5.dsl.mindspring.com ([165.247.105.101] helo=stealth) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19trBx-0004fK-00; Mon, 01 Sep 2003 09:06:10 -0700 Message-ID: <000601c370a2$f21fa980$9865fea9@stealth> From: "Andrea Colegrove" To: "George Gross" Cc: "George Gross" , References: Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 1 Sep 2003 12:06:01 -0400 Content-Transfer-Encoding: 7bit George, > Hi, > I note with interest that you snipped out those portions of my > e-mail that spoke to multi-vendor interoperability. IMHO, GSAKMP will not > advance unless there is flexibility shown, modifying the specification to > meet match such requirements. more below. > I did snip some sections out of previous emails as it seemed inconsiderate to the list to ask them to repeatedly download and parse long messages. I have snipped older or redundant portions of messages previous to this one as well. Multivendor interoperability is shown though implementation of a mandatory "MUST" implement suite of algorithms, as is true of any security protocol. > > The RTJ itself has security requirements on it. A GCKS should not even > > attempt to process something that is not of sufficient caliber. > > That assertion is just a particular group policy decision. Other policies > would say: I accept X and Y but not Z. The model you are assuming does not > reflect this reality: Service Providers will operate groups that are > hetrogenous both in vendor implementation and protocol version. They > also expect to have flexible configuration of group policy to allow > multiple flavors of valid RTJ because the group is hetrogenous. > Perhaps I have not been stating this clearly: Whatever the policy for RTJ is, it must be specified. This is true whether the policy is "accept Z only" or "X and Y but not Z". The protocol is not tied to what a particular group's policy is. > > So even > > before RTJ, the potential member must have some knowledge of the group. If > > we look at Tunnelled GSAKMP, we see add some negotiation capability before > > Key Download, but even so, the member still needs to know what the group is > > about: address, application, etc. This is done through web interfaces, > > SAP, etc. > > > > Whether the key download is not interpretable by the potential member or > > whether the GCKS NACKs the member is irrelevant from the perspective of the > > new member. The bottom line for the GCKS: The policy of a group is not > > negotiable > > again, this is being over restrictive and hardwiring a particular view of > what is group policy. the reality is that groups formed from multiple > vendors and multiple admin domains and multiple protocol versions force > negotiation on a per endpoint basis. the group announcement could say: the > GCKS accepts profile X or profile Y. The group member says in the RTJ: I > support profile X. That is a minimum form of negotiation that GSAKMP must > support to straddle such hetrogenous endpoints. > The policy token would state acceptable mechanisms. > I think this discussion illuminates a subtle but essential issue not > previously recognized: > > There can be a secure multicast group deployment where the multicasted > data originating from a speaker is encrypted/multicasted once, but it must > be received by two different subgroups who support profile X and profile Y > respectively. So long as the GCKS enforces that data SA parameters are > common across both subgroups, it is feasible to operate a single group > data SA even though the registration SA parameters vary between the > subgroups. A very promient example of this is a group formed from both The concept of equivalent, but heterogenous protection mechanisms of group data generally requires cryptographic gateways that can interpret the data in one and reencrypt. These ideas have been around for a while, but are complex. If we think that source authentication is difficult in homogenous multicast group, consider heterogenous ones! Anyway, interesting problem, but back to your example of same data SA, different registration: > GSAKMP and GDOI endpoints. Here's a simple example: > > |GDOI_endpoint A w/ profile X |<==GDOI=====>|GDOI/GSAKMP | > |bi-lingual GCKS| > |GSAKMP_endpoint B w/ profile X|<==GSAKMP===>| | > | | > |GSAKMP_endpoint C w/ profile Y|<==GSAKMP===>| | > > The above endpoints (A+B) and C may be in a different admin domain with a > different group registration policy expressed in a profile. Yet the data > SA for the group remains homogenous even though the registration SA is > not. Yes, a group should be allowed to use two different registration mechanisms simultaneously. Once again, it would be group policy that decides. This is different than the protocol specification. An implementation of a protocol can support many more mechanisms than the initial set -- ala a separate doc specifying a suite 2, a private suite understood by the community, or by registering separate new algorithms through IANA using the "future use" ranges. I do agree that the group policy may allow multiple registration mechanisms. This is a flexibility that should be considered when specifying the group policy token -- I hope that you will champion this cause. > > > Yes, but the above information about the group member's choice has to be > conveyed to the GCKS in the RTJ. It is not realistic to expect only one > set of registration SA parameters across all endpoints that is dictated by > the group announcement. > Yes, if multiple choices for RTJ are supported in the announcement, then the candidate member must signal what algorithms are chosen. For example, signature choice is indicated through the signature type field. (BTW, I just noted a typo on the table names. Table 15 should refer to ID types.) Perhaps the situation may occur where multiple key download types are available according to group policy? Generally, though, key download is related to rekey downloads, which must be uniform across a domain (if allowing for crypto gateways). Because of this, it is questionable whether it would be useful to have a candidate member indicate which encryption algorithm should be used. Does the msec working group have particular views on the ability for a group to use (and a candidate member to specify) multiple key download/rekey SA types? Does GDOI have a way for the candidate to say what encryption algorithms in rekey it desires? I am not trying to be contentious here, only ask if the use of cryptographic gateways (multiple broadcasts in different algorithms) should be assumed to be a requirement. The candidate can indicate what choices of mechanisms are used using payload fields. The candidate cannot negotiate a different set of algorithms, however. > > > > > > Knowledge of the existence of a group and its "address" is obtained > > in > > > > some sort of group announcement. > > > > > > The "some sort of group announcement" is an example of unspecified > > > information that will cripple inter-operability. Every vendor who > > > implements GSAKMP is gonna roll their own "group announcement" mechanism? > > > > > Someone advertising a group will indicate what the group is about, where it > > is to be found (addresses, applications, etc.), what security management > > (and parameter choices), etc. Security management is only a part of the > > group application problem. See SIP, SAP, etc for more info here. > > > > > > > The above response still does not answer how does GSAKMP support the > multiple vendor configuration: > > 1) a group announcement by vendor A who openly publishes their spec, > > 2) group member using GSAKMP from vendor B, that understands vendor A's > group announcement, > > 3) and GCKS using GSAKMP from vendor C that doesn't implement vendor A's > spec for group announcments. > > They should all be able to work together. The network operator should not > have to deploy vendor C's group announcement mechanism, nor should they > expect all group members to be from vendor C. They just need to be able to > configure the GCKS so that its view of the group announcement matches what > vendor A advertises even if the GCKS couldn't understand the bits on the > wire of that vendor A advertisement's encoding. And the GCKS must be able > to inter-operate with vendor B endpoints, and vendor A's, and vendor > D's.... > > Note that in such a group formed from multiple vendor implementations > there could be a mixture of legitimate profiles announced by Vendor A's > group announcement that the GCKS should accept. The set of profiles > offered gets narrowed down to one choice by each group member, and sent in > the RTJ. The GCKS needs to have a UI that allows the explicit > configuration of multiple acceptable profiles. This way we can support > large-scale and flexible GSAKMP deployments. If we are careful about how > we do this, we can even allow GDOI and GSAKMP endpoints in the same group. Yes, I think that in principle I agree if I am reading you correctly. The security portion of a group announcement should be a subset of the group security policy token. The security portion should also be a subset of the larger general group announcement. It is also generally accepted that group announcements should be small. A standardized generic announcement with security hooks sounds like very interesting work -- some of which has already been done. It affects a much larger group of folks than the security ones. It is not part of the GSAKMP protocol, though. The protocol should provide the framework for registration, maintenance including rekey, and perhaps even optionally, the controversial de-registration ;-). Implementations by different vendors can distinguish themselves by indicating the mechanisms (algorithms, PKI type, token type, etc.) that they support. If a vendor wishes to deploy a multi-protocol GCKS (say GDOI and GSAKMP) -- then the differentiation between "products" becomes even greater, and the user interface becomes even more complex. From a systems perspective, I believe that we agree what standards work that needs to be done. It does, however, need to be done in a modular manner. The GSAKMP protocol should not specify all these things. --- Andrea _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Sep 2 10:52:15 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03028 for ; Tue, 2 Sep 2003 10:52:15 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5A08253788; Tue, 2 Sep 2003 10:51:42 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 47B095375E for ; Tue, 2 Sep 2003 10:49:28 -0400 (EDT) Received: (qmail 47496 invoked by uid 3269); 2 Sep 2003 14:49:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 47487 invoked from network); 2 Sep 2003 14:49:28 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 2 Sep 2003 14:49:28 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h82EnQJD019297; Tue, 2 Sep 2003 09:49:26 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h82EnPYB022198; Tue, 2 Sep 2003 09:49:25 -0500 Received: from sparta.com (dhcp-15.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id KAA18118; Tue, 2 Sep 2003 10:49:23 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: George Gross From: Hugh Harney In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 2 Sep 2003 10:49:22 -0400 Content-Transfer-Encoding: 7bit George, Sorry for the delay. We do plan on answering all your points. Our clock just has a slower rate than yours. There has been a lot of travel this summer. > > GSAKMP issue 24 > > Section and relevant text passage: > > Section 4.2.1.2, the spec says: > > "The Policy Token and Key Download payloads are sent encrypted in the > KEK > generated by the Key Creation payload information using the mechanisms > defined in the group announcment." > > Comment/issue description: > > However, the group announcement is done out of band and it is not > defined > within this specification. Yet here it directly impacts what algorithms > and key lengths one would expect to encounter in the Key Download > message. > This seems to imply you can't connect to the group unless a candidate > member is privy to some non-standard pre-arranged convention, which is > overly restrictive and non-interoperable. The purpose of the announcement was to provide a means for someone to specify a security suite other than the security suite 1. This is to say that a vendor could define GSAKMP to operate on another set of security protocols as long as that vendor specific suite was announced or understood. Since security suite 1 is a MUST in the GSAKMP spec (at least for version 1), I see no issues with non-interoperability or over restriction. The generic GSAKMP header has the version number of the GSAKMP spec. If and when someone writes a version 2 GSAKMP spec, then the version 2 GSAKMP will know that the member sending the RTJ is sending it in conformance with the version 1 spec. If your objecting to our suggestion of using an announcement to allow people to define the use of vendor specific security suites, then we could take that out of the spec. > > Suggested issue resolution: > > I think that the "mechanisms defined in the group announcement" should > also be > copied as a new set of fields in the Request To Join message. That > way, the GCKS > can accept group members who did not hear the group announcement, or > may have heard an > older version of the group announcement that specified a different KEK > algorithm, > mode, and key length than a more recent version of that announcement. > > Further, the protocol spec should mandate at least one algorithm, > mode, and key > length that both GCKS and group members are both required to implement > for the KEK. > > This seems to be a place where you would say something like: > > "...using the mechanisms defined in the group announcement, which are > required to be identical to the set defined for IKEv2, or the IANA > registry's current set of algorithms. This includes the same MUST > implement requirements as IKEv2" > > or some words to that effect (wordsmithing TBD). Are you suggesting negotiable security parameters for the GSAKMP protocol on a member by member basis? Or are you just saying that we should specify the security suite the member is using to send the RTJ? Hugh _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Sep 2 13:44:52 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20712 for ; Tue, 2 Sep 2003 13:44:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 09A85537E3; Tue, 2 Sep 2003 13:44:22 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 77DE8537BA for ; Tue, 2 Sep 2003 13:42:22 -0400 (EDT) Received: (qmail 79547 invoked by uid 3269); 2 Sep 2003 17:42:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 79544 invoked from network); 2 Sep 2003 17:42:22 -0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by klesh.pair.com with SMTP; 2 Sep 2003 17:42:22 -0000 Received: from cscoamera13263.cisco.com (rtp-vpn1-411.cisco.com [10.82.225.155]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h82HfkJn018729; Tue, 2 Sep 2003 13:41:47 -0400 (EDT) Message-Id: <5.1.1.5.2.20030902103456.0563c3b8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Haitham Cruickshank From: Mark Baugher Subject: Re: [MSEC] Generic Policy Token issues Cc: hugh harney , msec@securemulticast.org In-Reply-To: <3F44AE98.EE458412@eim.surrey.ac.uk> References: <07a401c36748$74dc3280$0150b99d@DGKFL721> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_584610024==.ALT" 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 02 Sep 2003 10:41:25 -0700 --=====================_584610024==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed hi Haitham, At 12:35 PM 8/21/2003 +0100, Haitham Cruickshank wrote: >Hi All, > >I have one comment about Diameter usage for the security policy >distribution in relation to GSAKMP protocol: One important property of >GSAKMP, that I like, is >that it is SELF CONTAINED, and does not depend on any other protocols. I see both an advantage and a disadvantage to this design approach. The advantage is in having a single and complete system - it's specification is compact and self contained; this also makes security analysis much simpler. The disadvantage is that one might want to use a different announcement protocol, a different authorization mechanism, etc. This diversity is intrinsic to IP networks. >So, why we should rely on Diameter within a GSAKMP managed group, this >adds more interworking complications. May be, Diameter is useful for >interworking between GSAKMP and others such as MIKEY and future versions of >GDOI (GDOI with policy). > >My suggestion is that for the generic Policy Token (PT), there should be >an option to carry the PT within the protocol itself in order to reduce >the dependency on Diameter, if it is not available. I agree. I think the best solution would be a generic, or a Diameter-specific, definition that can be re-written in TLV, SDP, or practically any other syntax. It should be able to be carried in the key management protocol or in some other protocol (with the caveat that careful security analysis is needed for a particular implementation - and that's practically always the case anyway). Mark >Any comments are welcome. >Haitham > >hugh harney wrote: >>All, Several side exchanges have gone between George and I concerning the >>Generic Policy Token. Mostly, we were trying to understand each others >>issues and concerns. As is the nature of these exchanges, some technical >>suggestions have been made and we wanted to put these suggestions in >>front to the MSEC group for consideration. >>In a side exchange George Gross suggested the following: >> >>"1. We borrow the Diameter protocol base specification's Attribute >>Value-Pair (AVP) syntax and framework for encoding the policy token. See >>attached e-mail wrt/ to Diameter status, it is in the RFC editors queue. >>Diameter offers a comprehensive encoding scheme for all types of data, and >>includes mechanisms for digital signature and encryption based on CMS. >> >>2. We do not require implementation of the Diameter base protocol >>specification, we simply reserve from IANA a set of AVP codes for MSEC >>usage, the first set of which are allocated for the GSAKMP policy token >>related AVP. >> >>3. For each parameter in the current GSAKMP policy token, we do a one for >>one mapping of the fields into a corresponding "group AVP" as >>characterized in section 4.4 of the Diameter specification. We define a >>syntax for the mandatory and optional AVP for each group AVP." My >>questions to the group and to George are: >>If we (the Generic Policy Token work) focus on the core aspects of the >>policy token for version 1 of the Generic Policy Token, how long would it >>take to get this written? >> >>This is assuming that the Diameter framework is universally acceptable. >>Is this true? >> >>Hugh >> > >-- >Dr. Haitham S. Cruickshank > >Senior Research Fellow in Communications >Centre for Communication Systems Research (CCSR) >School of Electronics, Computing and Mathematics >University of Surrey >Guildford, Surrey GU2 7XH, UK > >Tel: +44 1483 686007 (indirect 689844) >Fax: +44 1483 686011 >e-mail: H.Cruickshank@surrey.ac.uk >http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > --=====================_584610024==.ALT Content-Type: text/html; charset="us-ascii" hi Haitham,

At 12:35 PM 8/21/2003 +0100, Haitham Cruickshank wrote:
Hi All,

I have one comment about Diameter usage for the security policy distribution in relation to GSAKMP protocol: One important property of GSAKMP, that I like, is
that it is SELF CONTAINED, and does not depend on any other protocols.

I see both an advantage and a disadvantage to this design approach.  The advantage is in having a single and complete system - it's specification is compact and self contained; this also makes security analysis much simpler.  The disadvantage is that one might want to use a different announcement protocol, a different authorization mechanism, etc.  This diversity is intrinsic to IP networks.

So, why we should rely on Diameter within a GSAKMP managed group, this
adds more interworking complications.  May be, Diameter is useful for interworking between GSAKMP and others such as MIKEY and future versions of
GDOI (GDOI with policy).

My suggestion is that for the generic Policy Token (PT), there should be an option to carry the PT within the protocol itself in order to reduce the dependency on Diameter, if it is not available.

I agree.  I think the best solution would be a generic, or a Diameter-specific, definition that can be re-written in TLV, SDP, or practically any other syntax.  It should be able to be carried in the key management protocol or in some other protocol (with the caveat that careful security analysis is needed for a particular implementation - and that's practically always the case anyway).

Mark


Any comments are welcome.
Haitham

hugh harney wrote:
All, Several side exchanges have gone between George and I concerning the Generic Policy Token. Mostly, we were trying to understand each others issues and concerns. As is the nature of these exchanges, some technical suggestions have been made and we wanted to put these suggestions in front to the MSEC group for consideration. 
In a side exchange George Gross suggested the following:

"1. We borrow the Diameter protocol base specification's Attribute
Value-Pair (AVP) syntax and framework for encoding the policy token. See
attached e-mail wrt/ to Diameter status, it is in the RFC editors queue.
Diameter offers a comprehensive encoding scheme for all types of data, and
includes mechanisms for digital signature and encryption based on CMS.

2. We do not require implementation of the Diameter base protocol
specification, we simply reserve from IANA a set of AVP codes for MSEC
usage, the first set of which are allocated for the GSAKMP policy token
related AVP.

3. For each parameter in the current GSAKMP policy token, we do a one for
one mapping of the fields into a corresponding "group AVP" as
characterized in section 4.4 of the Diameter specification. We define a
syntax for the mandatory and optional AVP for each group AVP." My questions to the group and to George are: 
If we (the Generic Policy Token work) focus on the core aspects of the policy token for version 1 of the Generic Policy Token, how long would it take to get this written?

This is assuming that the Diameter framework is universally acceptable. Is this true?

Hugh
 

--
Dr. Haitham S. Cruickshank

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

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

--=====================_584610024==.ALT-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 3 11:10:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13890 for ; Wed, 3 Sep 2003 11:10:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1B373536BC; Wed, 3 Sep 2003 11:10:06 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1A776536BC for ; Wed, 3 Sep 2003 11:06:26 -0400 (EDT) Received: (qmail 25723 invoked by uid 3269); 3 Sep 2003 15:06:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25720 invoked from network); 3 Sep 2003 15:06:25 -0000 Received: from prue.eim.surrey.ac.uk (131.227.76.5) by klesh.pair.com with SMTP; 3 Sep 2003 15:06:25 -0000 Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19uZCd-0006GE-00; Wed, 03 Sep 2003 16:05:47 +0100 Message-ID: <3F560347.CB81A9B6@eim.surrey.ac.uk> From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Generic Policy Token issues References: <07a401c36748$74dc3280$0150b99d@DGKFL721> <5.1.1.5.2.20030902103456.0563c3b8@mira-sjc5-6.cisco.com> Content-Type: multipart/alternative; boundary="------------D29943883344117C1F160DFA" X-Spam-Status: No, hits=-99.7 required=5.5 tests=EMAIL_ATTRIBUTION,HTML_10_20,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_XM,USER_IN_WHITELIST version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19uZCd-0006GE-00*ZAR6Wda4ndI* (SECM, UniS) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 03 Sep 2003 16:05:44 +0100 --------------D29943883344117C1F160DFA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Mark, I completely agree with your both comments about carrying PT and its encoding, where having various choices and options is good. So that service providers can pick what suits them best. Haitham Mark Baugher wrote: > hi Haitham, > > At 12:35 PM 8/21/2003 +0100, Haitham Cruickshank wrote: > >> Hi All, >> >> I have one comment about Diameter usage for the security policy >> distribution in relation to GSAKMP protocol: One important property >> of GSAKMP, that I like, is >> that it is SELF CONTAINED, and does not depend on any other >> protocols. > > > I see both an advantage and a disadvantage to this design approach. > The advantage is in having a single and complete system - it's > specification is compact and self contained; this also makes security > analysis much simpler. The disadvantage is that one might want to use > a different announcement protocol, a different authorization > mechanism, etc. This diversity is intrinsic to IP networks. > > >> So, why we should rely on Diameter within a GSAKMP managed group, >> this >> adds more interworking complications. May be, Diameter is useful >> for interworking between GSAKMP and others such as MIKEY and future >> versions of >> GDOI (GDOI with policy). >> >> My suggestion is that for the generic Policy Token (PT), there >> should be an option to carry the PT within the protocol itself in >> order to reduce the dependency on Diameter, if it is not available. > > > I agree. I think the best solution would be a generic, or a > Diameter-specific, definition that can be re-written in TLV, SDP, or > practically any other syntax. It should be able to be carried in the > key management protocol or in some other protocol (with the caveat > that careful security analysis is needed for a particular > implementation - and that's practically always the case anyway). > > Mark > > > >> Any comments are welcome. >> Haitham >> >> hugh harney wrote: >> >> > All,Several side exchanges have gone between George and I >> > concerning the Generic Policy Token. Mostly, we were trying to >> > understand each others issues and concerns. As is the nature of >> > these exchanges, some technical suggestions have been made and we >> > wanted to put these suggestions in front to the MSEC group for >> > consideration. >> > In a side exchange George Gross suggested the following: >> > >> > "1. We borrow the Diameter protocol base specification's Attribute >> > Value-Pair (AVP) syntax and framework for encoding the policy >> > token. See >> > attached e-mail wrt/ to Diameter status, it is in the RFC editors >> > queue. >> > Diameter offers a comprehensive encoding scheme for all types of >> > data, and >> > includes mechanisms for digital signature and encryption based on >> > CMS. >> > >> > 2. We do not require implementation of the Diameter base protocol >> > specification, we simply reserve from IANA a set of AVP codes for >> > MSEC >> > usage, the first set of which are allocated for the GSAKMP policy >> > token >> > related AVP. >> > >> > 3. For each parameter in the current GSAKMP policy token, we do a >> > one for >> > one mapping of the fields into a corresponding "group AVP" as >> > characterized in section 4.4 of the Diameter specification. We >> > define a >> > syntax for the mandatory and optional AVP for each group AVP." My >> > questions to the group and to George are: >> > If we (the Generic Policy Token work) focus on the core aspects of >> > the policy token for version 1 of the Generic Policy Token, how >> > long would it take to get this written? >> > >> > This is assuming that the Diameter framework is universally >> > acceptable. Is this true? >> > >> > Hugh >> >> >> -- >> Dr. Haitham S. Cruickshank >> >> Senior Research Fellow in Communications >> Centre for Communication Systems Research (CCSR) >> School of Electronics, Computing and Mathematics >> University of Surrey >> Guildford, Surrey GU2 7XH, UK >> >> Tel: +44 1483 686007 (indirect 689844) >> Fax: +44 1483 686011 >> e-mail: H.Cruickshank@surrey.ac.uk >> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ >> > -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ --------------D29943883344117C1F160DFA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Mark,

I completely agree with your both comments about carrying PT and its encoding, where having various choices and options is good. So that service providers can pick what suits them best.

Haitham

Mark Baugher wrote:

 hi Haitham,

At 12:35 PM 8/21/2003 +0100, Haitham Cruickshank wrote:

Hi All,

I have one comment about Diameter usage for the security policy distribution in relation to GSAKMP protocol: One important property of GSAKMP, that I like, is
that it is SELF CONTAINED, and does not depend on any other protocols.


I see both an advantage and a disadvantage to this design approach.  The advantage is in having a single and complete system - it's specification is compact and self contained; this also makes security analysis much simpler.  The disadvantage is that one might want to use a different announcement protocol, a different authorization mechanism, etc.  This diversity is intrinsic to IP networks.
 

So, why we should rely on Diameter within a GSAKMP managed group, this
adds more interworking complications.  May be, Diameter is useful for interworking between GSAKMP and others such as MIKEY and future versions of
GDOI (GDOI with policy).

My suggestion is that for the generic Policy Token (PT), there should be an option to carry the PT within the protocol itself in order to reduce the dependency on Diameter, if it is not available.


I agree.  I think the best solution would be a generic, or a Diameter-specific, definition that can be re-written in TLV, SDP, or practically any other syntax.  It should be able to be carried in the key management protocol or in some other protocol (with the caveat that careful security analysis is needed for a particular implementation - and that's practically always the case anyway).

Mark
 
 

Any comments are welcome.
Haitham

hugh harney wrote:

All,Several side exchanges have gone between George and I concerning the Generic Policy Token. Mostly, we were trying to understand each others issues and concerns. As is the nature of these exchanges, some technical suggestions have been made and we wanted to put these suggestions in front to the MSEC group for consideration.
In a side exchange George Gross suggested the following:

"1. We borrow the Diameter protocol base specification's Attribute
Value-Pair (AVP) syntax and framework for encoding the policy token. See
attached e-mail wrt/ to Diameter status, it is in the RFC editors queue.
Diameter offers a comprehensive encoding scheme for all types of data, and
includes mechanisms for digital signature and encryption based on CMS.

2. We do not require implementation of the Diameter base protocol
specification, we simply reserve from IANA a set of AVP codes for MSEC
usage, the first set of which are allocated for the GSAKMP policy token
related AVP.

3. For each parameter in the current GSAKMP policy token, we do a one for
one mapping of the fields into a corresponding "group AVP" as
characterized in section 4.4 of the Diameter specification. We define a
syntax for the mandatory and optional AVP for each group AVP." My questions to the group and to George are:
If we (the Generic Policy Token work) focus on the core aspects of the policy token for version 1 of the Generic Policy Token, how long would it take to get this written?

This is assuming that the Diameter framework is universally acceptable. Is this true?

Hugh


--
Dr. Haitham S. Cruickshank

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

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

--
Dr. Haitham S. Cruickshank

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

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank@surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
  --------------D29943883344117C1F160DFA-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 3 11:45:38 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17080 for ; Wed, 3 Sep 2003 11:45:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E5C59539C0; Wed, 3 Sep 2003 11:44:52 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id EDFE15399A for ; Wed, 3 Sep 2003 11:42:44 -0400 (EDT) Received: (qmail 32828 invoked by uid 3269); 3 Sep 2003 15:42:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32825 invoked from network); 3 Sep 2003 15:42:44 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 3 Sep 2003 15:42:44 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h83FgRJD004645; Wed, 3 Sep 2003 10:42:27 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h83FgQeI026480; Wed, 3 Sep 2003 10:42:26 -0500 Received: from columbia.sparta.com (everest.columbia.sparta.com [157.185.80.33]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id LAA06960; Wed, 3 Sep 2003 11:42:21 -0400 (EDT) Message-ID: <3F560B65.90604@columbia.sparta.com> From: Andrea Colegrove User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Haitham Cruickshank Cc: Mark Baugher , msec@securemulticast.org Subject: Re: [MSEC] Generic Policy Token issues References: <07a401c36748$74dc3280$0150b99d@DGKFL721> <5.1.1.5.2.20030902103456.0563c3b8@mira-sjc5-6.cisco.com> <3F560347.CB81A9B6@eim.surrey.ac.uk> Content-Type: multipart/alternative; boundary="------------090909060107040808020809" 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 03 Sep 2003 11:40:21 -0400 --------------090909060107040808020809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please excuse my ignorance, but would it be possible to DER encode an AVP specified policy? It would be nice to tie this to the X.509 infrastructure support. --- Andrea Haitham Cruickshank wrote: > Hi Mark, > > I completely agree with your both comments about carrying PT and its > encoding, where having various choices and options is good. So that > service providers can pick what suits them best. > > Haitham > > Mark Baugher wrote: > >> hi Haitham, >> >> At 12:35 PM 8/21/2003 +0100, Haitham Cruickshank wrote: >> >>> Hi All, >>> >>> I have one comment about Diameter usage for the security policy >>> distribution in relation to GSAKMP protocol: One important property >>> of GSAKMP, that I like, is >>> that it is SELF CONTAINED, and does not depend on any other protocols. >>> >> >> I see both an advantage and a disadvantage to this design approach. >> The advantage is in having a single and complete system - it's >> specification is compact and self contained; this also makes security >> analysis much simpler. The disadvantage is that one might want to >> use a different announcement protocol, a different authorization >> mechanism, etc. This diversity is intrinsic to IP networks. >> >> >>> So, why we should rely on Diameter within a GSAKMP managed group, this >>> adds more interworking complications. May be, Diameter is useful >>> for interworking between GSAKMP and others such as MIKEY and future >>> versions of >>> GDOI (GDOI with policy). >>> >>> My suggestion is that for the generic Policy Token (PT), there >>> should be an option to carry the PT within the protocol itself in >>> order to reduce the dependency on Diameter, if it is not available. >>> >> >> I agree. I think the best solution would be a generic, or a >> Diameter-specific, definition that can be re-written in TLV, SDP, or >> practically any other syntax. It should be able to be carried in the >> key management protocol or in some other protocol (with the caveat >> that careful security analysis is needed for a particular >> implementation - and that's practically always the case anyway). >> >> Mark >> >> >> >>> Any comments are welcome. >>> Haitham >>> >>> hugh harney wrote: >>> >>>> All,Several side exchanges have gone between George and I >>>> concerning the Generic Policy Token. Mostly, we were trying to >>>> understand each others issues and concerns. As is the nature of >>>> these exchanges, some technical suggestions have been made and we >>>> wanted to put these suggestions in front to the MSEC group for >>>> consideration. >>>> In a side exchange George Gross suggested the following: >>>> >>>> "1. We borrow the Diameter protocol base specification's Attribute >>>> Value-Pair (AVP) syntax and framework for encoding the policy >>>> token. See >>>> attached e-mail wrt/ to Diameter status, it is in the RFC editors >>>> queue. >>>> Diameter offers a comprehensive encoding scheme for all types of >>>> data, and >>>> includes mechanisms for digital signature and encryption based on CMS. >>>> >>>> 2. We do not require implementation of the Diameter base protocol >>>> specification, we simply reserve from IANA a set of AVP codes for MSEC >>>> usage, the first set of which are allocated for the GSAKMP policy >>>> token >>>> related AVP. >>>> >>>> 3. For each parameter in the current GSAKMP policy token, we do a >>>> one for >>>> one mapping of the fields into a corresponding "group AVP" as >>>> characterized in section 4.4 of the Diameter specification. We >>>> define a >>>> syntax for the mandatory and optional AVP for each group AVP." My >>>> questions to the group and to George are: >>>> If we (the Generic Policy Token work) focus on the core aspects of >>>> the policy token for version 1 of the Generic Policy Token, how >>>> long would it take to get this written? >>>> >>>> This is assuming that the Diameter framework is universally >>>> acceptable. Is this true? >>>> >>>> Hugh >>>> >>> >>> -- >>> Dr. Haitham S. Cruickshank >>> >>> Senior Research Fellow in Communications >>> Centre for Communication Systems Research (CCSR) >>> School of Electronics, Computing and Mathematics >>> University of Surrey >>> Guildford, Surrey GU2 7XH, UK >>> >>> Tel: +44 1483 686007 (indirect 689844) >>> Fax: +44 1483 686011 >>> e-mail: H.Cruickshank@surrey.ac.uk >>> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ >>> >>> > -- > Dr. Haitham S. Cruickshank > > Senior Research Fellow in Communications > Centre for Communication Systems Research (CCSR) > School of Electronics, Computing and Mathematics > University of Surrey > Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > Fax: +44 1483 686011 > e-mail: H.Cruickshank@surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > --------------090909060107040808020809 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit     Please excuse my ignorance, but would it be possible to DER encode an AVP specified policy?  It would be nice to tie this to the X.509 infrastructure support.

--- Andrea


Haitham Cruickshank wrote:

Hi Mark,

I completely agree with your both comments about carrying PT and its encoding, where having various choices and options is good. So that service providers can pick what suits them best.

Haitham

Mark Baugher wrote:

 hi Haitham,

At 12:35 PM 8/21/2003 +0100, Haitham Cruickshank wrote:

Hi All,

I have one comment about Diameter usage for the security policy distribution in relation to GSAKMP protocol: One important property of GSAKMP, that I like, is
that it is SELF CONTAINED, and does not depend on any other protocols.


I see both an advantage and a disadvantage to this design approach.  The advantage is in having a single and complete system - it's specification is compact and self contained; this also makes security analysis much simpler.  The disadvantage is that one might want to use a different announcement protocol, a different authorization mechanism, etc.  This diversity is intrinsic to IP networks.
 

So, why we should rely on Diameter within a GSAKMP managed group, this
adds more interworking complications.  May be, Diameter is useful for interworking between GSAKMP and others such as MIKEY and future versions of
GDOI (GDOI with policy).

My suggestion is that for the generic Policy Token (PT), there should be an option to carry the PT within the protocol itself in order to reduce the dependency on Diameter, if it is not available.


I agree.  I think the best solution would be a generic, or a Diameter-specific, definition that can be re-written in TLV, SDP, or practically any other syntax.  It should be able to be carried in the key management protocol or in some other protocol (with the caveat that careful security analysis is needed for a particular implementation - and that's practically always the case anyway).

Mark
 
 

Any comments are welcome.
Haitham

hugh harney wrote:

All,Several side exchanges have gone between George and I concerning the Generic Policy Token. Mostly, we were trying to understand each others issues and concerns. As is the nature of these exchanges, some technical suggestions have been made and we wanted to put these suggestions in front to the MSEC group for consideration.
In a side exchange George Gross suggested the following:

"1. We borrow the Diameter protocol base specification's Attribute
Value-Pair (AVP) syntax and framework for encoding the policy token. See
attached e-mail wrt/ to Diameter status, it is in the RFC editors queue.
Diameter offers a comprehensive encoding scheme for all types of data, and
includes mechanisms for digital signature and encryption based on CMS.

2. We do not require implementation of the Diameter base protocol
specification, we simply reserve from IANA a set of AVP codes for MSEC
usage, the first set of which are allocated for the GSAKMP policy token
related AVP.

3. For each parameter in the current GSAKMP policy token, we do a one for
one mapping of the fields into a corresponding "group AVP" as
characterized in section 4.4 of the Diameter specification. We define a
syntax for the mandatory and optional AVP for each group AVP." My questions to the group and to George are:
If we (the Generic Policy Token work) focus on the core aspects of the policy token for version 1 of the Generic Policy Token, how long would it take to get this written?

This is assuming that the Diameter framework is universally acceptable. Is this true?

Hugh


--
Dr. Haitham S. Cruickshank

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

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

--
Dr. Haitham S. Cruickshank

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

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


--------------090909060107040808020809-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 3 12:52:40 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21164 for ; Wed, 3 Sep 2003 12:52:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 891AF539D4; Wed, 3 Sep 2003 12:52:11 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 31C33539AF for ; Wed, 3 Sep 2003 12:51:14 -0400 (EDT) Received: (qmail 44482 invoked by uid 3269); 3 Sep 2003 16:51:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 44479 invoked from network); 3 Sep 2003 16:51:14 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 3 Sep 2003 16:51:14 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h83Gp6JD006085; Wed, 3 Sep 2003 11:51:06 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h83Gp5eI029446; Wed, 3 Sep 2003 11:51:06 -0500 Received: from sparta.com (dhcp-15.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA08061; Wed, 3 Sep 2003 12:50:56 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: msec@securemulticast.org, acc@columbia.sparta.com To: George Gross From: Hugh Harney Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 3 Sep 2003 12:50:47 -0400 Content-Transfer-Encoding: 7bit George, WRT the policy choices for registration (keeping other issues separate for the time being), we need to clarify two issues: 1. How does a candidate member determine what acceptable mechanisms to use? 2. How does a candidate member communicate what mechanisms were chosen when multiple ones are acceptable? The first issue leads us to an announcement about the group as part of multicast group set up. This agreement can be via other means than the network (e.g., a particular community uses an agreed upon set of algorithms, a web page has this info posted, or the parameters are sent over the wire (along with the multicast address) in something like SAP. The means this information is sent to the group in question is out of scope for this protocol. What is in scope for this protocol is to define a data field that specifies how this data is communicated, which should tie this specification into the IANA process. As an algorithm is allocated an IANA number, that number should be used in specifying it to the group. For the second issue, if multiple key download/encryption types are indeed to be supported, we would then need to add a notification of the candidates choice of policy-approved key exchange type and encryption algorithm. Once again, this should be a short payload using IANA numbers. --- Hugh and Andrea Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Sep 4 17:01:51 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22193 for ; Thu, 4 Sep 2003 17:01:50 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A1F9E53965; Thu, 4 Sep 2003 16:55:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id AD80653794 for ; Thu, 4 Sep 2003 15:53:54 -0400 (EDT) Received: (qmail 55972 invoked by uid 3269); 4 Sep 2003 19:53:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55969 invoked from network); 4 Sep 2003 19:53:54 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 4 Sep 2003 19:53:54 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h84JrmJD026819; Thu, 4 Sep 2003 14:53:48 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h84JrleI005578; Thu, 4 Sep 2003 14:53:47 -0500 Received: from sparta.com (ssh.columbia.sparta.com [157.185.80.253]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA24948; Thu, 4 Sep 2003 15:53:44 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: , To: George Gross From: Hugh Harney In-Reply-To: Message-Id: <7D53E7F8-DF11-11D7-AE3D-000A956E63C6@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 4 Sep 2003 15:53:44 -0400 Content-Transfer-Encoding: 7bit George, comments in-line On Thursday, Sep 4, 2003, at 13:17 US/Eastern, George Gross wrote: > Hi Hugh & Andrea, > > On Wed, 3 Sep 2003, Hugh Harney wrote: > >> George, >> >> WRT the policy choices for registration (keeping other issues >> separate for the time being), we need to clarify two issues: >> 1. How does a candidate member determine what acceptable >> mechanisms to use? >> 2. How does a candidate member communicate what mechanisms >> were >> chosen when multiple ones are acceptable? >> >> The first issue leads us to an announcement about the group as >> part >> of multicast group set up. This agreement can be via other means than >> the network (e.g., a particular community uses an agreed upon set of >> algorithms, a web page has this info posted, or the parameters are >> sent >> over the wire (along with the multicast address) in something like >> SAP. >> The means this information is sent to the group in question is out of >> scope for this protocol. > > How you encode that info in *some* cases may be out of scope of GSAKMP, > but the semantics that the policy token announcement specifies are very > much part of GSAKMP processing and therefore part of the GSAKMP > protocol specification. > > Let's take an example that makes this discussion more concrete. In the > GSAKMP policy token today, there are a set of group membership > authorization rules encoded in an X.509-centric DN pattern matching > scheme. However, in the commercial world, it is common practice to use > a > Network Access Identifier (NAI, RFC2486) as the handle by which a > roaming > user and his mobile computing systems are authenticated/authorized. > > It stands to reason that the generic policy token expressing the > authorized group membership may want to specify a NAI-centric group > membership authorization list as an alternative to the X.509 DN > pattern rules approach. > > The NAI may not be in the user's Subject field of his/her Public Key > Certificate. For example, it might be in the subjectAltName field > instead. > So when that user presents a RTJ with his/her signature to the GSAKMP > GCKS, the GCKS must understand that for this user, the identity > asserted > matches a NAI in the subjectAltName field rather than the subjectName > field. > > By adding the new "registration profile identifier" AVP to the Request > To > Join message, the GCKS will have the additional information it needs to > know when it must look for and validate a NAI against the group > membership > authorization rules. However, as illustrated by this example, the GCKS > processing is clearly not independent of the policy token. > Consequently, > this processing is part of the GSAKMP specification even though the > policy > token/announcement originated from the Group Owner. > > BTW: the placement of NAI in altSubjectName field is meant to be an > example, and may not match practice in a particular CA deployment. > > Still another example: you could imagine the use of an attribute > certificate as described in RFC3281 as another alternative group > membership authorization technique. This would allow dynamic group > memberships rather than the fixed structure implied by a set of > published > rules that might become out of date. Again, if you went in this > direction > for registration, then the GCKS must be able to parse, validate, and > finally accept an Attribute Certificate presented in the RTJ with what > ever is the defined convention for interpreting the "group" attibute > and > others. That convention is in the GSAKMP specification. > > ANother area for the generic policy token to specify information that > impacts the GSAKMP GCKS processing is the list of trusted root CA that > are > accepted for certificates from the various parties. Again, you can not > escape the configuration in the policy token having to match the GCKS > configuration for processing this information, even if the announcement > does not present it in a standardized format/mechanism. The GSAKMP > protocol specification must include this processing in its semantics. The mode of distributing this data structure is out of scope for GSAKMP. It can be preloaded during software configuration or sent via an announcement, placed on a web site ...... > >> What is in scope for this protocol is to >> define a data field that specifies how this data is communicated, >> which >> should tie this specification into the IANA process. As an algorithm >> is >> allocated an IANA number, that number should be used in specifying it >> to the group. > > Okay, I'm fine with this approach, provided it also meets several other > requirements that bear mentioning: > > 1. it should be encoded as a variable length group AVP, perhaps > allowing > optional nested AVP to accomodate multiple parameters being selected by > the candidate member. It is a data field that will be specified in GSAKMP. I'm not viewing this an an extension of the Diameter-AVP effort. > > 2. it should have the ability to specify vendor-specific suites > instead of > IANA registered ones. In the Diameter-AVP, this is "V" flag capability. Again I don't think this needs to be as flexible as you seem to think. > 3. I would like to see this value be a direct clone of a > Diameter-encoded > AVP(s) from the generic policy token. Of course, the announcement may > have > transcribed it to another format altogether, but clearly we do not want > every announcement format flavor in the RTJ, the policy choice should > be > normalized into a well-known AVP encoding. If the MSEC generic PT wants to adopt this field that is fine. I don't think the decision has been made to make the MSEC PT conform to the Diameter standards. I think a strong argument can be made for ASN, just like the certificates. hugh _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Sep 7 12:28:17 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15613 for ; Sun, 7 Sep 2003 12:28:16 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 35C245374B; Sun, 7 Sep 2003 12:27:51 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1209C5368E for ; Sun, 7 Sep 2003 12:21:43 -0400 (EDT) Received: (qmail 55150 invoked by uid 3269); 7 Sep 2003 16:21:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55147 invoked from network); 7 Sep 2003 16:21:43 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 7 Sep 2003 16:21:43 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h87GLhJD029528 for ; Sun, 7 Sep 2003 11:21:43 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h87GLheI031566 for ; Sun, 7 Sep 2003 11:21:43 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA29339 for ; Sun, 7 Sep 2003 12:21:42 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h87GLWd02373 for msec@securemulticast.org; Sun, 7 Sep 2003 12:21:32 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations Message-ID: <20030907122132.A2359@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sun, 7 Sep 2003 12:21:32 -0400 Reposting, as my first attempts did not seem to make it to the list. Sorry for jumping into these discussions so late, but I just getting caught up after being away for over 3 weeks. George, From what you write that the spec points to IKE as a template, I think you meant to say ISAKMP. GSAKMP is similar to ISAKMP in that is uses the same payload chaining concept as GSAKMP mentions in section 3.2.1. GSAKMP does not use IKE as a template. WRT registering values with IANA, we will be looking into this, good catch. We will follow examples from other specs to fill this need. UM On Sat, Aug 09, 2003 at 08:23:53AM -0400, George Gross wrote: > GSAKMP issue 00 > > Section and relevant text passage: > > The document as a whole is missing a comprehensive IANA considerations > section. Also the relationship of GSAKMP identifiers to similar ones > found in IKE is unspecified. > > Comment/issue description: > > This is similar to the stuff found in IKE-v2 section 6, where there > are numerous payload identifiers and crypto algorithms/suites > referenced that need IANA to maintain the registry. WHile the spec > points to IKE as its template, it is not clear whether you expect > to coordinate the GSAKMP payload identifier space (or any of the > other identifier spaces, see below) with IKE. Where feasible, it > would make sense to either converge to a common set with the IKE-v2 > set of identifiers or else use an non-colliding set of GSAKMP > reserved identifiers within the IKE-v2 space. > > Suggested issue resolution: > > 1. Every one of the various tables in the GSAKMP protocol specification > that define identifiers should be discussed in the IANA > considerations section: > - table 6 group identification types > - table 7 payload types, coordinate with IKE-v2 section 3.2 > - table 8 exchange types, coordinate with IKE-v2 > - table 9 policy token types > - table 10 key download data types > - table 11 rekey event types > - table 12 identification payload types, coordinate with IKE-v2 section 3.5 > - table 13 certificate payload types, coordinate with IKE-v2 section 3.6 > - table 14 signature types > - table 15 signature ID types > - table 16 authorization types > - table 17 Notify payload types, coordinate with IKE-v2 section 3.10.1 > - table 18 Notify status types, coordinate with IKE-v2 section 3.10.1 > - table 19 acknowledgement types > - table 20 key creation type > - table 21 nonce type > > 2. The section 1.2 "Protocol Considerations" belongs as sub-section in > the IANA section. This section should specify that GSAKMP is in a > UDP payload. > > 3. The generic header payload encoding should be aligned with IKE-v2 > section 3.2, and it should include the "critical" bit semantics. The > GSAKMP mandated payloads should have this bit clear, as explained by > the rationale in IKE-v2. > > 4. All of the above identifier/type tables in GSAKMP should have a > portion of their identifier space reserved for private/experimental > use between consenting parties -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Sep 7 12:52:02 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16769 for ; Sun, 7 Sep 2003 12:52:02 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 52B0253710; Sun, 7 Sep 2003 12:25:11 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2E0C7535F9 for ; Sun, 7 Sep 2003 12:22:42 -0400 (EDT) Received: (qmail 55249 invoked by uid 3269); 7 Sep 2003 16:22:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55246 invoked from network); 7 Sep 2003 16:22:42 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 7 Sep 2003 16:22:42 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h87GMfJD029532 for ; Sun, 7 Sep 2003 11:22:41 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h87GMfeI031569 for ; Sun, 7 Sep 2003 11:22:42 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA29346 for ; Sun, 7 Sep 2003 12:22:40 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h87GMdI02381 for msec@securemulticast.org; Sun, 7 Sep 2003 12:22:39 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 03: recipient ID Message-ID: <20030907122239.B2359@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sun, 7 Sep 2003 12:22:39 -0400 Reposting, as my first attempts did not appear to make it to the list. Based on this lack of definition of the term "recipient ID", we propose the following wording for this paragraph in section 4.2.1. (NOTE: I am putting the whole paragraph here, including the lead in sentances that were not in the original post.) Standard design principles for secure protocols mandate the use of explicit identification of senders and recipients of messages. The signature payload of each message identifies the signer of the message and therefore satisfies the sender requirement. Within the GSAKMP header is a group ID. Because the member may be served by any Key Server within a group, this group ID provides sufficient granularity to identify the intended recipient of the Request To Join message. Other messages sent by the potential member will contain the identification of the GCKS serving that member contained within the Identification payload. UM On Fri, Aug 08, 2003 at 03:25:49PM -0400, George Gross wrote: > > GSAKMP issue 03 > > Section and relevant text passage: > > section 4.2.1: "Within the GSAKMP header is a group ID. Because > the member may be served by any Key Server within a group, this ID provides > sufficient granularity for the recipient ID for the Request to Join message. > Other messages sent by the potential member will contain the recipient ID > for the GCKS serving that member." > > Comment/issue description: > > The term "recipient ID" is not previously defined, and it is not explicitly > mentioned anywhere else > in the document. In what namespace is the "recipient ID" allocated? > > Suggested issue resolution: > > Add an example of a "recipient ID", e.g. is it an IP-v4 address in the > globally routable Internet? an X.509 D.N? point to a table defining the > possible namespaces. > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Sep 8 01:14:47 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08718 for ; Mon, 8 Sep 2003 01:14:47 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4703B535A7; Mon, 8 Sep 2003 01:14:11 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9312653568 for ; Mon, 8 Sep 2003 01:12:59 -0400 (EDT) Received: (qmail 11843 invoked by uid 3269); 8 Sep 2003 05:12:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 11840 invoked from network); 8 Sep 2003 05:12:59 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 8 Sep 2003 05:12:59 -0000 Received: (qmail 37876 invoked by uid 1000); 8 Sep 2003 05:12:59 -0000 Received: from gmgross@nac.net by smtp-out2.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.0224259999999999 secs); 08 Sep 2003 05:12:59 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out2.oct.nac.net with SMTP; 8 Sep 2003 05:12:58 -0000 Received: (qmail 63033 invoked from network); 8 Sep 2003 05:12:58 -0000 Received: from unknown (HELO nsx.garage) (gmgross@64.21.175.223) by smtp-auth.nac.net with SMTP; 8 Sep 2003 05:12:58 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h8834ZH03618; Sun, 7 Sep 2003 23:04:35 -0400 From: George Gross To: Uri Meth Cc: , Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations In-Reply-To: <20030907122132.A2359@charlie.columbia.sparta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sun, 7 Sep 2003 23:04:35 -0400 (EDT) Hi Uri, On Sun, 7 Sep 2003, Uri Meth wrote: > Reposting, as my first attempts did not seem to make it to the list. have had trouble myself, let's hope the list will stabilize... > > Sorry for jumping into these discussions so late, but I just getting > caught up after being away for over 3 weeks. > > George, > > >From what you write that the spec points to IKE as a template, I think > you meant to say ISAKMP. I think it would be good to start by making sure we're on the same page. I was referring to IKE-v2, which consolidates ISAKMP and IKE into a single document. In particular, I am referring to http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-10.txt which the Internet Draft that is moving towards last call as the successor to ISAKMP/IKE-v1. Please re-review my original e-mail with this in mind, as it shifts the focus to a different set of requirements/capabilities. >GSAKMP is similar to ISAKMP in that is uses > the same payload chaining concept as GSAKMP mentions in section 3.2.1. > GSAKMP does not use IKE as a template. The IKE-v2 generic payload definition is found in section 3.2. I am indicating that GSAKMP payloads should be directly compatible with the current IKE-v2 spec semantics/syntax, not the ISAKMP/IKE-v1 specs that were written 6 years ago. Nor should GSAKMP roll its own payload type that differs from IKE-v2. In particular, GSAKMP should have the same concept of a "critical" bit as defined by IKE-v2 in section 3.2 and a set of Payload Type Values that match those that are already defined by IKE-v2 where they are duplicates in meaning. The following payload types should be used "as is" from IKE-v2 by GSAKMP: Certificate Notify Delete Key Exchange Vendor ID Nonce Traffic Selector IDi for the initiator's identity in the RTJ a set of payload types reserved for private use For only those Payload Type Values that are unique to GSAKMP, then there should be a set of Payload Type Values allocated by IANA that are distinct from those in use by IKE-v2 but allocated from the same payload type namespace. > > WRT registering values with IANA, we will be looking into this, good > catch. We will follow examples from other specs to fill this need. Again, let's be careful to work from the same pages. The relevant Internet Drafts to synchronize with are: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-03.txt and section 6 of ipsec-ikev2-10.txt These IANA related things will be easy to edit into GSAKMP. There was one other issue mentioned in my original e-mail that I am not clear on your position, please also reply directly to this issue: > 4. All of the above identifier/type tables in GSAKMP should have a > portion of their identifier space reserved for private/experimental > use between consenting parties The private/experimental usage should be feasible for all GSAKMP identifiers, not just its payload type. br, George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Sep 8 10:02:39 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20880 for ; Mon, 8 Sep 2003 10:02:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 376DE53702; Mon, 8 Sep 2003 10:02:11 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2C9FD535E5 for ; Mon, 8 Sep 2003 10:00:45 -0400 (EDT) Received: (qmail 11205 invoked by uid 3269); 8 Sep 2003 14:00:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 11202 invoked from network); 8 Sep 2003 14:00:45 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 8 Sep 2003 14:00:45 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h88E0fJD005195; Mon, 8 Sep 2003 09:00:41 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h88E0deI013922; Mon, 8 Sep 2003 09:00:39 -0500 Received: from sparta.com (dhcp-15.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id KAA10247; Mon, 8 Sep 2003 10:00:37 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Uri Meth , To: George Gross From: Hugh Harney In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 8 Sep 2003 10:00:38 -0400 Content-Transfer-Encoding: 7bit George, > The IKE-v2 generic payload definition is found in section 3.2. I am > indicating that GSAKMP payloads should be directly compatible with the > current IKE-v2 spec semantics/syntax, not the ISAKMP/IKE-v1 specs that > were written 6 years ago. Nor should GSAKMP roll its own payload type > that differs from IKE-v2. In particular, GSAKMP should have the same > concept of a "critical" bit as defined by IKE-v2 in section 3.2 and a > set > of Payload Type Values that match those that are already defined by > IKE-v2 > where they are duplicates in meaning. The following payload types > should > be used "as is" from IKE-v2 by GSAKMP: WRT, the issue of how GSAKMP and the GSAKMP PT should format information you have made some broad statements that sound like requirements. You state here that GSAKMP should mirror IKEv2 in payload structure. Earlier you've stated that the Policy Token work should mirror the work done in the AAA working group. I understand your concerns about interoperability, but these types of statements really are changes to the MSEC charter. I don't believe interoperability with IKEv2 or AAA is in the MSEC Charter. If you really feel that the MSEC charter needs to change I'd suggest you bring that up with the chairs. I think the best path forward is to focus on those issues that flow from the MSEC Charter. Hugh _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Sep 8 15:12:50 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15717 for ; Mon, 8 Sep 2003 15:12:50 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 92FB8536BA; Mon, 8 Sep 2003 15:12:25 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 683CB5354E for ; Mon, 8 Sep 2003 15:10:14 -0400 (EDT) Received: (qmail 67373 invoked by uid 3269); 8 Sep 2003 19:10:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67370 invoked from network); 8 Sep 2003 19:10:14 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 8 Sep 2003 19:10:14 -0000 Received: (qmail 64966 invoked by uid 1000); 8 Sep 2003 19:10:13 -0000 Received: from gmgross@nac.net by smtp-out2.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.062576 secs); 08 Sep 2003 19:10:13 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out2.oct.nac.net with SMTP; 8 Sep 2003 19:10:13 -0000 Received: (qmail 1493 invoked from network); 8 Sep 2003 19:10:11 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.177) by smtp-auth.nac.net with SMTP; 8 Sep 2003 19:10:11 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h88H1bA04933; Mon, 8 Sep 2003 13:01:37 -0400 From: George Gross To: Hugh Harney Cc: George Gross , Uri Meth , Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 8 Sep 2003 13:01:37 -0400 (EDT) Hi Hugh, inline below... On Mon, 8 Sep 2003, Hugh Harney wrote: > George, > > > The IKE-v2 generic payload definition is found in section 3.2. I am > > indicating that GSAKMP payloads should be directly compatible with the > > current IKE-v2 spec semantics/syntax, not the ISAKMP/IKE-v1 specs that > > were written 6 years ago. Nor should GSAKMP roll its own payload type > > that differs from IKE-v2. In particular, GSAKMP should have the same > > concept of a "critical" bit as defined by IKE-v2 in section 3.2 and a > > set > > of Payload Type Values that match those that are already defined by > > IKE-v2 > > where they are duplicates in meaning. The following payload types > > should > > be used "as is" from IKE-v2 by GSAKMP: > > > WRT, the issue of how GSAKMP and the GSAKMP PT should format > information you have made some broad statements that sound like > requirements. You state here that GSAKMP should mirror IKEv2 in payload > structure. Earlier you've stated that the Policy Token work should > mirror the work done in the AAA working group. > > I understand your concerns about interoperability, but these types of > statements really are changes to the MSEC charter. I don't believe > interoperability with IKEv2 or AAA is in the MSEC Charter. If you > really feel that the MSEC charter needs to change I'd suggest you bring > that up with the chairs. In most any other IETF working group, you normally would see a chorus of voices expressing similar views as I've expressed, and they would not have to cite the charter to have the standards track draft change to reflect good engineering principals. The MSEC list may be silent, but that does not change the process. Making GSAKMP integral to other facets of the Internet architecture is something you design in to minimize re-inventing the wheel, to make implementations less buggy, and to reduce the need for various protocols conversion gateways. In the context of making GSAKMP compatible with IKE-v2, this would allow an IKE-v2 implementation to extend to handle GSAKMP with fewer bugs, less redundant coding, and potentially reduce the difficulty of handling GDOI endpoints with that same implementation. Given these benefits, the burden of explaining why GSAKMP should not be IKE-v2 compatible as outlined above falls on the GSAKMP protocol designers, not the MSEC charter. As a prospective GSAKMP/GDOI implementor, I am not pleased with the artifical division that has lead to GDOI and GSAKMP occupying the same Internet. It is incorrect to say "they are different market requirements" and therefore can proceed independently in parallel. In fact, as a vendor who bids for business in both the defence and commercial sector, we fully expect to see secure multicast group deployments formed from mixtures of GSAKMP and GDOI endpoints. E.g. a DoD agency and an DoD contractor doing a teleconference. Minimizing the design distance between them will reduce the effort it takes to realize such applications. To that end, designing GSAKMP with IKE-v2, GDOI, and AAA considerations is common sense. In fact, I'd like to see if the differences between GDOI and GSAKMP can be narrowed to the only the registration SA, and with common logic and protocol for the rekey, policy token, and TLV encoding aspects. You've decided to put GSAKMP on standards track, and in this arena until now, you may not have had the benefit of other parties looking at the GSAKMP proposed design as vigorously as I have. GSAKMP is not a fait acomplii. It has the obligation to be a *mallable* design that accepts feedback, that includes other's requirements besides the co-author's design decisions. IMHO, there is nothing sacred in its currently drafted bits on the wire format or its semantics. You don't need a MSEC charter change to do this. Only then does GSAKMP have the potential become a proposed standard. And to date, in my view, the evidence is weighing very mixed wrt/ that outcome. George > > I think the best path forward is to focus on those issues that flow > from the MSEC Charter. > > Hugh > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Sep 9 09:30:58 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06029 for ; Tue, 9 Sep 2003 09:30:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2A666536BD; Tue, 9 Sep 2003 09:30:10 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id CC791536BD for ; Tue, 9 Sep 2003 09:28:15 -0400 (EDT) Received: (qmail 99486 invoked by uid 3269); 9 Sep 2003 13:28:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 99481 invoked from network); 9 Sep 2003 13:28:15 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 9 Sep 2003 13:28:15 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h89DRhJD021402; Tue, 9 Sep 2003 08:27:44 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h89DRgeI015827; Tue, 9 Sep 2003 08:27:43 -0500 Received: from sparta.com (dhcp-15.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id JAA25664; Tue, 9 Sep 2003 09:27:34 -0400 (EDT) Subject: Re: [MSEC] msec spec language ASN issues Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Brian Weis , "msec@securemulticast.org" To: George Gross From: Hugh Harney In-Reply-To: Message-Id: <5DDEEA06-E2C9-11D7-9FE3-000A956E63C6@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 9 Sep 2003 09:27:32 -0400 Content-Transfer-Encoding: 7bit George, I'm open to using Diameter as the specification language, if it is possible to construct a high assurance policy engine based on X.509 certificates. A big hurdle to constructing a high assurance policy engine between two specification languages is the need to have high assurance translation software. How does the AAA specification language relate to ASN? If Diameter can encapsulate a standard ASN.1 DER encoded structure, then it could be used to tie all the security policy specification together - S-Mime uses ASN and the certificates are in ASN. I'm only stuck on ASN because the certificates use ASN. The authorization and access control policies will have to relate to the ASN.1 DER encoded certificates as mechanisms for enforcement. I'm particularly concerned with the need to validate rules written in Diameter (or anything else) using data that is defined in ASN.1 DER encoding. I'm leery of translation code if it must either change the parameters that come from the certificates or change the rules that come from the policy tokens. On way around this is if Diameter can specify a subset of rules in ASN.1 DER encoding. Then there is a 1-1 mapping of security mechanisms to security policy. I then can see how a high assurance policy engine can be constructed. Hugh _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Sep 9 09:56:47 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08255 for ; Tue, 9 Sep 2003 09:56:46 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6252753834; Tue, 9 Sep 2003 09:52:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0D530537DF for ; Tue, 9 Sep 2003 09:51:06 -0400 (EDT) Received: (qmail 3267 invoked by uid 3269); 9 Sep 2003 13:51:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 3264 invoked from network); 9 Sep 2003 13:51:05 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 9 Sep 2003 13:51:05 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07499; Tue, 9 Sep 2003 09:50:56 -0400 (EDT) Message-Id: <200309091350.JAA07499@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-gkmarch-06.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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 09 Sep 2003 09:50:56 -0400 --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 : MSEC Group Key Management Architecture Author(s) : M. Baugher et al. Filename : draft-ietf-msec-gkmarch-06.txt Pages : 36 Date : 2003-9-9 This document defines the common architecture for Multicast Security (MSEC) key management protocols that support a variety of application, transport, and network layer security protocols. It also defines the group SA (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document allow for a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. Comments on this document should be sent to msec@securemulticast.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-06.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-gkmarch-06.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-gkmarch-06.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: <2003-9-9092230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gkmarch-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gkmarch-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-9092230.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Sep 9 11:18:58 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16658 for ; Tue, 9 Sep 2003 11:18:58 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5A8B35391B; Tue, 9 Sep 2003 11:16:10 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DDF9B5390B for ; Tue, 9 Sep 2003 11:15:36 -0400 (EDT) Received: (qmail 19592 invoked by uid 3269); 9 Sep 2003 15:15:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19589 invoked from network); 9 Sep 2003 15:15:36 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 9 Sep 2003 15:15:36 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h89FFZJD023323 for ; Tue, 9 Sep 2003 10:15:35 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h89FFYeI019827 for ; Tue, 9 Sep 2003 10:15:34 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id LAA27784 for ; Tue, 9 Sep 2003 11:15:32 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h89FFWu13669 for msec@securemulticast.org; Tue, 9 Sep 2003 11:15:32 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 02: security assumptions discussion Message-ID: <20030909111531.A13594@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gmgross@nac.net on Fri, Aug 08, 2003 at 03:24:39PM -0400 Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 9 Sep 2003 11:15:32 -0400 See inline comments. On Fri, Aug 08, 2003 at 03:24:39PM -0400, George Gross wrote: > > GSAKMP issue 02 > > Section and relevant text passage: > > section 3 "Security Assumptions" > > Comment/issue description: > > This section needs to add some text explaining its assumption wrt/ the > multicast routing protocols, We make no assumption wrt multicast routing issues. What you you mean, wrt security? This point appears to be an infrastucture issue. > NAT, As I understand it, NAT is a sender network issue, again not a security issue. If a site is using NAT, by the time it hits the outside world and the GCKS, it is working with a real IP address, and that is what we deal with, we don't even know NATting is going on (just like no one else will). Please explain your thoughts here wrt security. > GSAKMP protocol version mismatch between GCKS and GM, This point will affect the specification in sections 4.2.1.1 through 4.2.1.3. We will scrub these sections wrt error handling and state specifically the error handling for each processed error, including protocol number mismatch. > and the reliable multicast transport protocols. Again, we assume that no Reliable Multicast Protocol (RMP) is available. Since by definition UDP is unreliable, the protocol allows for multiple send of rekey message in the absence of a reliable network to increase the chances that all members receive this message. But again, I fail to see what this has to do wrt the security of the protocol? I must be missing something here, please expound. > It also should make an explicit statement about whether the trust model > for "Security Suite 1" assumes > that active attackers might compromise a Group Member(s) and whether > the group can recover from such a compromise. I don't follow what you are getting at here. Everyone knows the configuration of Security Suite 1 (SS1), it is published in the standard. So what is there to compromise? What SS1 provides is a capability for the GM and GCKS to converse using a short lived D-H exchange. Are you asking that this short lived exchange is compromised and what happens in that instance, or are you asking something else in a broader context? Please clarify. > > Suggested issue resolution: > > The above topics each deserve their own sub-section 3.x. > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec UM -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Sep 9 16:30:05 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03399 for ; Tue, 9 Sep 2003 16:30:04 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 10C8153940; Tue, 9 Sep 2003 16:28:30 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 19CA05392B for ; Tue, 9 Sep 2003 16:26:14 -0400 (EDT) Received: (qmail 81220 invoked by uid 3269); 9 Sep 2003 20:26:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81217 invoked from network); 9 Sep 2003 20:26:14 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 9 Sep 2003 20:26:14 -0000 Received: (qmail 83398 invoked by uid 1000); 9 Sep 2003 20:26:13 -0000 Received: from gmgross@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.033399 secs); 09 Sep 2003 20:26:13 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out1.oct.nac.net with SMTP; 9 Sep 2003 20:26:13 -0000 Received: (qmail 2282 invoked from network); 9 Sep 2003 20:26:12 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.167) by smtp-auth.nac.net with SMTP; 9 Sep 2003 20:26:12 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h89IHXc30963; Tue, 9 Sep 2003 14:17:33 -0400 From: George Gross To: Uri Meth Cc: , Subject: Re: [MSEC] GSAKMP issue 02: security assumptions discussion In-Reply-To: <20030909111531.A13594@charlie.columbia.sparta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 9 Sep 2003 14:17:33 -0400 (EDT) Hi Uri, On Tue, 9 Sep 2003, Uri Meth wrote: > See inline comments. > > On Fri, Aug 08, 2003 at 03:24:39PM -0400, George Gross wrote: > > > > GSAKMP issue 02 > > > > Section and relevant text passage: > > > > section 3 "Security Assumptions" > > > > Comment/issue description: > > > > This section needs to add some text explaining its assumption wrt/ the > > multicast routing protocols, > > We make no assumption wrt multicast routing issues. > What you you mean, wrt security? This point appears to be an > infrastucture issue. This comment reflects discussion on this list in June of this year, wrt/ the MSEC architecture doc and whether the IGMP/MLD messages sent to multicast routers should have some form of membership authentication and authorization mechanisms. The conclusion was that is not a current IETF work item, but that a discussion of the potential DoS attack should be included in the respective MSEC key management protocol specs in the security consideration sections. See Brian's post for a good summary: http://www.pairlist.net/pipermail/msec/2003-June/000793.html > > > NAT, > > As I understand it, NAT is a sender network issue, again not a security > issue. If a site is using NAT, by the time it hits the outside world > and the GCKS, it is working with a real IP address, and that is what we > deal with, we don't even know NATting is going on (just like no one else will). > > Please explain your thoughts here wrt security. there are several issues here: 1. The GSAKMP policy token embeds IP-v4 addresses within the Security Association payload within section 2.4.1.3.1.2. 2. The group identifier in GSAKMP policy token section 2.1.1.4 is an IP-v4 address. 3. The GSAKMP header defined in section 6.1 of the GSAKMP protocol spec uses a group ID that is an IP-v4 address. In each of these cases, when the GSAKMP message traverses NAT, the IP-v4 addresses may be encrypted and/or authenticated and can not be altered by NAT. The GSAKMP specification has to discuss a solution for detecting the presense of NAT, and how NAT gateways can (or can not) alter the GSAKMP packet. For an example of how the protocol designers decided to handle NAT wrt/ IKE-v2, see section 2.23 in the draft ipsec-ikev2-10.txt. Bottom line: to traverse NAT, GSAKMP will require the specification of a negotiation of UDP encapsulation similar as has been defined for IKE-v2. It also will need to decide how embedded IP addresses within GSAKMP are handled by NAT. BTW, there may be IPR on the ESP over UDP negotiation, so I would advise taking a look at the IPR notices to the IETF. Much as one might like, we can not ignore interactions with NAT :o( Q: when an IP address is being used as the GSAKMP Group ID, is it a multicast address? or an anycast address? or a vanilla unicast address? Please specify in the document. > > > GSAKMP protocol version mismatch between GCKS and GM, > > This point will affect the specification in sections 4.2.1.1 through > 4.2.1.3. We will scrub these sections wrt error handling and state > specifically the error handling for each processed error, including > protocol number mismatch. Okay. > > > and the reliable multicast transport protocols. > > Again, we assume that no Reliable Multicast Protocol (RMP) is available. > Since by definition UDP is unreliable, the protocol allows for multiple send > of rekey message in the absence of a reliable network to increase the > chances that all members receive this message. > > But again, I fail to see what this has to do wrt the security of the > protocol? I must be missing something here, please expound. An active attacker could intercept and drop a rekey event multicast message, and trigger a DoS attack. A RMP would detect the dropped delivery. Since you don't mandate a RMP, you need to specify the detection and recovery mechanism. i.e. timers and maximum number of retries for the various GSAKMP messages as part of the policy token and the specification. It should say when to give up and do a re-registration. Discussion on this list (most recently in mid-August) has also mentioned other error recovery strategies, such as explicit request for resend from the GCKS, and posting the rekey message in a well known directory/web site. Since GSAKMP embodies a concept of multiple GCKS, that redundancy could be used in the recovery process, if only it was specified. > > > It also should make an explicit statement about whether the trust model > > for "Security Suite 1" assumes > > that active attackers might compromise a Group Member(s) and whether > > the group can recover from such a compromise. > > I don't follow what you are getting at here. Everyone knows the > configuration of Security Suite 1 (SS1), it is published in the standard. So > what is there to compromise? What SS1 provides is a capability for the > GM and GCKS to converse using a short lived D-H exchange. Are you > asking that this short lived exchange is compromised and what happens in > that instance, or are you asking something else in a broader context? > Please clarify. There are a variety of things that merit discussion: 1) This section should say something about GSAKMP being secure against passive adversaries outside of the group membership, but it is vulnerable to active attacks if a GM is compromised by an adversary. In other words, since GSAKMP does not mandate a multicast source authentication mechanism, a compromised GM could impersonate a peer. The compromised GM could not impersonate a GCKS rekey because such messages are signed. You should indicate the benefit of forward secrecy using LKH or other algorithm to recover from this situation. 2) The GSAKMP protocol assumes that all GM and GCKS belong to a common PKI or else have a certificate path to a common root CA. The spec should indicate that the GO, GCKS, and GM all use a common configuration mechanisms to setup their one or more trusted root CA keys. This mechanism should be specified at a level that avoids inter-operability issues between vendors. 3) The GSAKMP header contains a sequence number that is assumed to be stored in non-volatile memory across GCKS reboots (or is it?, section 6.1 should discuss this). 4) If GSAKMP has any kind of dependency on timestamps or synchronization of time across its endpoints, that should be stated (or if it does not, say that). discuss "rollover" time during rekey. 5) You are not defining the use of TESLA or any other multicast source authentication, correct? this section needs to say that. 6) Does the GSAKMP protocol assume that the data SA has only a single multicast speaker? If not, then you should indicate that the receivers need to keep per multicast source SA state for sequence numbers and SA lifetime calculation. 7) what is the sliding window for acceptable sequence numbers in a rekey message? George > > > > > Suggested issue resolution: > > > > The above topics each deserve their own sub-section 3.x. > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > UM > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Sep 9 18:13:23 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08672 for ; Tue, 9 Sep 2003 18:13:22 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3720353778; Tue, 9 Sep 2003 18:08:20 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3FFBD538B9 for ; Tue, 9 Sep 2003 18:06:25 -0400 (EDT) Received: (qmail 96767 invoked by uid 3269); 9 Sep 2003 22:06:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96764 invoked from network); 9 Sep 2003 22:06:25 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 9 Sep 2003 22:06:25 -0000 Received: (qmail 29296 invoked by uid 1000); 9 Sep 2003 22:06:24 -0000 Received: from gmgross@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.035943 secs); 09 Sep 2003 22:06:24 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out1.oct.nac.net with SMTP; 9 Sep 2003 22:06:24 -0000 Received: (qmail 97077 invoked from network); 9 Sep 2003 22:06:17 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.167) by smtp-auth.nac.net with SMTP; 9 Sep 2003 22:06:17 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h89Jvbw31082; Tue, 9 Sep 2003 15:57:37 -0400 From: George Gross To: Uri Meth Cc: Subject: Re: [MSEC] GSAKMP issue 03: recipient ID In-Reply-To: <20030907122239.B2359@charlie.columbia.sparta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 9 Sep 2003 15:57:37 -0400 (EDT) Hi Uri, On Sun, 7 Sep 2003, Uri Meth wrote: > Reposting, as my first attempts did not appear to make it to the list. > > Based on this lack of definition of the term "recipient ID", > we propose the following wording for this paragraph in > section 4.2.1. (NOTE: I am putting the whole paragraph here, including > the lead in sentances that were not in the original post.) > > Standard design principles for secure protocols mandate the use of > explicit identification of senders and recipients of messages. > The signature payload of each message identifies the signer of > the message and therefore satisfies the sender requirement. Within > the GSAKMP header is a group ID. Because the member may be served by any > Key Server within a group, this group ID provides sufficient granularity > to identify the intended recipient of the Request To Join message. > Other messages sent by the potential member will contain the > identification of the GCKS serving that member contained within the > Identification payload. thank you, the above text is clearer, but does still have some ambiguity. A follow up question: is the Group ID a multicast IP address? or an anycast IP address? In other words, when a group member sends the RTJ, does the IP header's destination IP address match the Group ID's IP address or the IP address of a particular GCKS? The spec should explicitly call this out (particularly relevant for IP-v6). thx, George > > UM > > On Fri, Aug 08, 2003 at 03:25:49PM -0400, George Gross wrote: > > > > GSAKMP issue 03 > > > > Section and relevant text passage: > > > > section 4.2.1: "Within the GSAKMP header is a group ID. Because > > the member may be served by any Key Server within a group, this ID provides > > sufficient granularity for the recipient ID for the Request to Join message. > > Other messages sent by the potential member will contain the recipient ID > > for the GCKS serving that member." > > > > Comment/issue description: > > > > The term "recipient ID" is not previously defined, and it is not explicitly > > mentioned anywhere else > > in the document. In what namespace is the "recipient ID" allocated? > > > > Suggested issue resolution: > > > > Add an example of a "recipient ID", e.g. is it an IP-v4 address in the > > globally routable Internet? an X.509 D.N? point to a table defining the > > possible namespaces. > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Sep 9 23:59:58 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19553 for ; Tue, 9 Sep 2003 23:59:57 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5E1FF53673; Tue, 9 Sep 2003 23:59:10 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 37A5A536EE for ; Tue, 9 Sep 2003 23:57:56 -0400 (EDT) Received: (qmail 57058 invoked by uid 3269); 10 Sep 2003 03:57:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57055 invoked from network); 10 Sep 2003 03:57:56 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 10 Sep 2003 03:57:56 -0000 Received: (qmail 18157 invoked by uid 1000); 10 Sep 2003 03:57:55 -0000 Received: from gmgross@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.046901 secs); 10 Sep 2003 03:57:55 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out1.oct.nac.net with SMTP; 10 Sep 2003 03:57:54 -0000 Received: (qmail 18468 invoked from network); 10 Sep 2003 03:57:54 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.191) by smtp-auth.nac.net with SMTP; 10 Sep 2003 03:57:54 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h8A1mq931399; Tue, 9 Sep 2003 21:48:52 -0400 From: George Gross To: Cc: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] MSEC policy token and AAA 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 9 Sep 2003 21:48:52 -0400 (EDT) Hi, In previous e-mails, I've suggested that there is a fairly strong coupling between Diameter-based AAA and the MSEC generic policy token. This e-mail opens the discussion on that topic, with a few sample use cases setting the context. The goal is to build a set of requirements and a framework that allows: 1) the large-scale commercial deployment of a secure multicast group spanning multiple administrative domains, 2) has the future potential to work as an extension within the Diameter AAA framework that does group membership authentication, authorization, and accounting. where feasible, it should be possible to selectively reuse existing AVP syntax and semantics from the network access, EAP, and accounting applications. 3) the policy token can express numerous group related attributes, both security related and still others that are not security related. Examples of the latter include: rekey reliable multicast transport parameters, constraints on time and pricing, QoS parameters, group owner contact info... 4) allows Enterprises to continue to use their existing employee authentication methods, and allows gradual migration to PKI based authentication. In particular, this requirement includes the ability to use the NAI as an end user identifier. 5) The policy token must be extensible to assure that new attributes can be introduced without breaking an embedded base of MSEC endpoints that understand only earlier versions of the policy token. 6) allows a group membership comprised of a mixture of GSAKMP and GDOI endpoints, i.e. the registration protocol selected by each endpoint may be different, but the data SA and its keying material is homogenous across the group's endpoints. BTW, I don't rule out having MIKE endpoints in the group too, but that seems like a stretch goal. 7) able to express multiple alternative policy profiles, any one of which is acceptable in a Request To Join sent to the GCKS. 8) can support roaming/mobile users as a natural consequence of the design (i.e. roaming is when the end user visits a foreign admin domain/ISP). 9) has some limited form of backward compatibility with some portions of the GSAKMP policy token encoding found in msec-tokenspec-sec-00.txt and the policy related aspects of GDOI RFC3547. 10) easily able to translate group policy into other representations suitable for use in a group announcement. 11) minimizes the use of embedded IP-v4 addresses within the policy token that would need translation at NAT gateways. 12) able to acommodate the "pull", "push", and "agent" authorization models. Folks on this list are welcome to chime in with additional requirements, just keep in mind the spirit of the main requirement: large-scale commercial secure multicast group AAA across multiple administrative domains. While designing a Diameter application extension for secure multicast service remains on the horizon, it still helps to keep that in mind when organizing the policy token's design. So what does the Diameter oriented architecture look like? Here's a representative diagram of a MSEC/AAA architecture composed of: - three administrative domains: ISP[x], ISP[y], and home admin domain A - three Diameter servers: X, Y, and A with peer-to-peer Diameter connections - Group owner server for the Group "Z" - Group "Z" group security association stradding the three admin domains - Home administrative domain's Authentication Server A, speaking EAP - GDOI GCKS in ISP[x] domain - GSAKMP GCKS in ISP[y] domain - bi-lingual GCKS in home domain A - six Group Members (GM) belonging to group "Z", distributed across the three domains - registration Security Associations (SA) coupling the GM to their GCKS - Diameter client/server sessions between each GCKS and the domain's Diameter server | | | ISP[x] admin domain | ISP[y] admin domain | Home[a] admin domain | | | | +----------+ | +-----------+ | +----------+ +---------+ | | Diameter | | | Diameter | | | Diameter <####>Group "Z"| | | AAA <=========> AAA <=======> AAA | | Owner | | | server X | | | server Y | | | server A <*** | Server | | +----/\----+ | +----/\-----+ | +----/\----+ ** +---------+ | ||Diameter | ||Diameter | || EAP | +----\/----+ | +----\/-----+ | +----\/----+ ** +---------+ | | GDOI GCKS| | |GSAKMP GCKS| | |G-wiz GCKS| ** |Authntctn| | | Diameter | | | Diameter | | | Diameter | ***> server A| | | client X | | | client Y | | | client A | | | | +-A------A-+ | +-A-------A-+ | +-A------A-+ +---------+ | | | | | | | | | | registration SA | registration SA | registration SA | | | | | | | | | | +-V-+ +-V-+ | +-V-+ +-V-+ | +-V-+ +-V-+ | |GM1| |GM2| | |GM3| |GM4| | |GM5| |GM6| | +-A-+ +-A-+ | +-A-+ +-A-+ | +-A-+ +-A-+ | | | | | | | | | | +-V------V-------|-----V-------V-------|---V------V-+ | | Group "Z" group security association | | +----------------|---------------------|------------+ | | | | So, on the one hand, I freely acknowledge that portions of the above architecture are out of scope of the MSEC charter. that said, I think it is reasonable to size up the surrounding network operational model in which the group policy token gets processed and circulated between components. That way, we can clarify which components should be allowed to see which portions of the token because they have a need to know. Usually in architectures like the above, there are contractual relationships between the various domains, spelling out what each is trusted to do with priviledged information. It is my intention to put the above diagram and some explainatory text into section 5 of the Generic Policy Token spec. kinda ran out of gas for the moment, will continue this later... George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 10 11:35:11 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04670 for ; Wed, 10 Sep 2003 11:35:10 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 66F225382A; Wed, 10 Sep 2003 11:34:43 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E45C8536F9 for ; Wed, 10 Sep 2003 11:33:13 -0400 (EDT) Received: (qmail 10953 invoked by uid 3269); 10 Sep 2003 15:33:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10950 invoked from network); 10 Sep 2003 15:33:13 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 10 Sep 2003 15:33:13 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8AFX4JD007754; Wed, 10 Sep 2003 10:33:04 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8AFWxeI020236; Wed, 10 Sep 2003 10:32:59 -0500 Received: from sparta.com (dhcp-15.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id LAA15085; Wed, 10 Sep 2003 11:32:57 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 02: security assumptions discussion Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Uri Meth , To: George Gross From: Hugh Harney In-Reply-To: Message-Id: <0CFE5DC1-E3A4-11D7-8926-000A956E63C6@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 11:32:56 -0400 Content-Transfer-Encoding: 7bit George, I see your issue with our use of IPv4 as a group ID field. I think it best to remove the IPv4 reference in the Group ID field altogether. This is particularly true because we have seen that most groups do not have a tight coupling with an IP address anyway. This will be corrected in future PT releases. The group ID must uniquely identify the cryptographic group, but it does not need to identify the IP address of the data stream. >>> and the reliable multicast transport protocols. >> >> Again, we assume that no Reliable Multicast Protocol (RMP) is >> available. >> Since by definition UDP is unreliable, the protocol allows for >> multiple send >> of rekey message in the absence of a reliable network to increase the >> chances that all members receive this message. >> >> But again, I fail to see what this has to do wrt the security of the >> protocol? I must be missing something here, please expound. > > An active attacker could intercept and drop a rekey event multicast > message, and trigger a DoS attack. A RMP would detect the dropped > delivery. Since you don't mandate a RMP, you need to specify the > detection > and recovery mechanism. i.e. timers and maximum number of retries for > the > various GSAKMP messages as part of the policy token and the > specification. > It should say when to give up and do a re-registration. Discussion on > this list (most recently in mid-August) has also mentioned other error > recovery strategies, such as explicit request for resend from the GCKS, > and posting the rekey message in a well known directory/web site. Since > GSAKMP embodies a concept of multiple GCKS, that redundancy could be > used > in the recovery process, if only it was specified. I'm not sure I agree here. The key management protocol has to remain in a secure state. I think this is divorced from the reliable transport mechanism. I agree that the km protocol has to specify detection and recovery mechanisms. I think this is best done wrt the keys and the successful rekey events. I think the keys must have a lifespan, and there has to be a local definition of mandatory rekey periods. Both of these events are within the domain of key management. I'm uneasy specifying security functionallity to non-security protocols. I agree that we need to include mention of redundant error recovery strategies in the spec. I think these things help system architects use GSAKMP in a system, but the security mechanisms that can be relied on are the timers inside of GSAKMP. >>> It also should make an explicit statement about whether the trust >>> model >>> for "Security Suite 1" assumes >>> that active attackers might compromise a Group Member(s) and whether >>> the group can recover from such a compromise. >> >> I don't follow what you are getting at here. Everyone knows the >> configuration of Security Suite 1 (SS1), it is published in the >> standard. So >> what is there to compromise? What SS1 provides is a capability for >> the >> GM and GCKS to converse using a short lived D-H exchange. Are you >> asking that this short lived exchange is compromised and what happens >> in >> that instance, or are you asking something else in a broader context? >> Please clarify. > > There are a variety of things that merit discussion: > > 1) This section should say something about GSAKMP being secure against > passive adversaries outside of the group membership, but it is > vulnerable > to active attacks if a GM is compromised by an adversary. In other > words, > since GSAKMP does not mandate a multicast source authentication > mechanism, > a compromised GM could impersonate a peer. The compromised GM could not > impersonate a GCKS rekey because such messages are signed. You should > indicate the benefit of forward secrecy using LKH or other algorithm to > recover from this situation. Yes this should be explained. > > 2) The GSAKMP protocol assumes that all GM and GCKS belong to a common > PKI > or else have a certificate path to a common root CA. The spec should > indicate that the GO, GCKS, and GM all use a common configuration > mechanisms to setup their one or more trusted root CA keys. This > mechanism > should be specified at a level that avoids inter-operability issues > between vendors. We did not assume this. The access control and authorisation rules have two parts. Rule and verification mechanism. The rule is specifically designed to match a particular verification mechanism. So rule 1 can be for PKI 1, rule 2 can be for PKI 2, rule 3 can relate to some database someone has. > > 3) The GSAKMP header contains a sequence number that is assumed to be > stored in non-volatile memory across GCKS reboots (or is it?, section > 6.1 > should discuss this). OK > > 4) If GSAKMP has any kind of dependency on timestamps or > synchronization > of time across its endpoints, that should be stated (or if it does not, > say that). discuss "rollover" time during rekey. So your saying it is unclear if there is a dependancy in our timers? We should state when the timer only need to reference the local clock. > > 5) You are not defining the use of TESLA or any other multicast source > authentication, correct? this section needs to say that. OK > > 6) Does the GSAKMP protocol assume that the data SA has only a single > multicast speaker? If not, then you should indicate that the receivers > need to keep per multicast source SA state for sequence numbers and SA > lifetime calculation. Actually, GSAKMP makes no assumptions about the data layer security protocols. I think this is an issue for multicast IPSec. If the GSAKMP PT is supporting multicast IPSec then this is a field that can be added, but GSAKMP will not be a consumer of this field. It will be passed through GSAKMP to the IPSec application. > > 7) what is the sliding window for acceptable sequence numbers in a > rekey > message? This can be an added field to help specify the rekey mechanisms in the PT. Is this adiquate? >>> Suggested issue resolution: >>> >>> The above topics each deserve their own sub-section 3.x. In some cases the topic is best included to clarify existing text. Hugh _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 10 13:40:42 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09873 for ; Wed, 10 Sep 2003 13:40:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 295BC53611; Wed, 10 Sep 2003 13:40:10 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1E6A353779 for ; Wed, 10 Sep 2003 13:38:28 -0400 (EDT) Received: (qmail 35105 invoked by uid 3269); 10 Sep 2003 17:38:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35100 invoked from network); 10 Sep 2003 17:38:27 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 10 Sep 2003 17:38:27 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8AHbhf15027; Wed, 10 Sep 2003 12:37:43 -0500 (CDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SC65G102; Wed, 10 Sep 2003 10:37:44 -0700 Received: from americasm06.nt.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SQRYKK13; Wed, 10 Sep 2003 13:37:42 -0400 Message-ID: <3F5F6166.3020402@americasm06.nt.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Cc: Hugh Harney , Uri Meth , msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 13:37:42 -0400 Content-Transfer-Encoding: 7bit I am trying to understand this. Geroge, are you saying that GSAKMP should be re-designed so that it becomes GDOIv2 effectively, or, that the current messages are ok (viz., RTJ, KD, Notify:ACK/Fail), but the payloads should be same as in IKEv2? Either option would be a serious design change; for example, GSAKMP header is quite different from an IKEv2 header. But, the only rationale I heard was that GSAKMP re-design (from tunneled GSAKMP) predates IKEv2 design. As an implementor of GDOI and IKEv2, I would like to see the packet headers and even messages of IKEv2 re-used in GSAKMP, however. cheers, Lakshminath George Gross wrote: >Hi Hugh, > >inline below... > >On Mon, 8 Sep 2003, Hugh Harney wrote: > > > >>George, >> >> >> >>>The IKE-v2 generic payload definition is found in section 3.2. I am >>>indicating that GSAKMP payloads should be directly compatible with the >>>current IKE-v2 spec semantics/syntax, not the ISAKMP/IKE-v1 specs that >>>were written 6 years ago. Nor should GSAKMP roll its own payload type >>>that differs from IKE-v2. In particular, GSAKMP should have the same >>>concept of a "critical" bit as defined by IKE-v2 in section 3.2 and a >>>set >>>of Payload Type Values that match those that are already defined by >>>IKE-v2 >>>where they are duplicates in meaning. The following payload types >>>should >>>be used "as is" from IKE-v2 by GSAKMP: >>> >>> >>WRT, the issue of how GSAKMP and the GSAKMP PT should format >>information you have made some broad statements that sound like >>requirements. You state here that GSAKMP should mirror IKEv2 in payload >>structure. Earlier you've stated that the Policy Token work should >>mirror the work done in the AAA working group. >> >>I understand your concerns about interoperability, but these types of >>statements really are changes to the MSEC charter. I don't believe >>interoperability with IKEv2 or AAA is in the MSEC Charter. If you >>really feel that the MSEC charter needs to change I'd suggest you bring >>that up with the chairs. >> >> > >In most any other IETF working group, you normally would see a chorus of >voices expressing similar views as I've expressed, and they would not have >to cite the charter to have the standards track draft change to reflect >good engineering principals. The MSEC list may be silent, but that does >not change the process. Making GSAKMP integral to other facets of the >Internet architecture is something you design in to minimize re-inventing >the wheel, to make implementations less buggy, and to reduce the need for >various protocols conversion gateways. In the context of making GSAKMP >compatible with IKE-v2, this would allow an IKE-v2 implementation to >extend to handle GSAKMP with fewer bugs, less redundant coding, and >potentially reduce the difficulty of handling GDOI endpoints with that >same implementation. Given these benefits, the burden of explaining why >GSAKMP should not be IKE-v2 compatible as outlined above falls on the >GSAKMP protocol designers, not the MSEC charter. > >As a prospective GSAKMP/GDOI implementor, I am not pleased with the >artifical division that has lead to GDOI and GSAKMP occupying the same >Internet. It is incorrect to say "they are different market requirements" >and therefore can proceed independently in parallel. In fact, as a vendor >who bids for business in both the defence and commercial sector, we fully >expect to see secure multicast group deployments formed from mixtures of >GSAKMP and GDOI endpoints. E.g. a DoD agency and an DoD contractor doing a >teleconference. Minimizing the design distance between them will reduce >the effort it takes to realize such applications. To that end, designing >GSAKMP with IKE-v2, GDOI, and AAA considerations is common sense. In fact, >I'd like to see if the differences between GDOI and GSAKMP can be narrowed >to the only the registration SA, and with common logic and protocol for >the rekey, policy token, and TLV encoding aspects. > >You've decided to put GSAKMP on standards track, and in this arena until >now, you may not have had the benefit of other parties looking at the >GSAKMP proposed design as vigorously as I have. GSAKMP is not a fait >acomplii. It has the obligation to be a *mallable* design that accepts >feedback, that includes other's requirements besides the co-author's >design decisions. IMHO, there is nothing sacred in its currently drafted >bits on the wire format or its semantics. You don't need a MSEC charter >change to do this. > >Only then does GSAKMP have the potential become a proposed standard. And >to date, in my view, the evidence is weighing very mixed wrt/ that >outcome. > > George > > > > > >>I think the best path forward is to focus on those issues that flow >>from the MSEC Charter. >> >>Hugh >> >> >> >> > > >_______________________________________________ >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 Sep 10 14:52:33 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12512 for ; Wed, 10 Sep 2003 14:52:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2DF875384A; Wed, 10 Sep 2003 14:52:06 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4C13853853 for ; Wed, 10 Sep 2003 14:50:19 -0400 (EDT) Received: (qmail 46797 invoked by uid 3269); 10 Sep 2003 18:50:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46794 invoked from network); 10 Sep 2003 18:50:19 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 10 Sep 2003 18:50:19 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8AInrJD011239; Wed, 10 Sep 2003 13:49:54 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8AInmeI027399; Wed, 10 Sep 2003 13:49:49 -0500 Received: from sparta.com (dhcp-15.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id OAA18152; Wed, 10 Sep 2003 14:49:46 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: George Gross , Uri Meth , msec@securemulticast.org To: "Lakshminath Dondeti" From: Hugh Harney In-Reply-To: <3F5F6166.3020402@americasm06.nt.com> Message-Id: <8CEC63EA-E3BF-11D7-8926-000A956E63C6@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 14:49:47 -0400 Content-Transfer-Encoding: 7bit Lakshminath, On Wednesday, Sep 10, 2003, at 13:37 US/Eastern, Lakshminath Dondeti wrote: > I am trying to understand this. > Geroge, are you saying that GSAKMP should be re-designed so that it > becomes GDOIv2 effectively, or, that the current messages are ok > (viz., RTJ, KD, Notify:ACK/Fail), but the payloads should be same as > in IKEv2? Either option would be a serious design change; for > example, GSAKMP header is quite different from an IKEv2 header. But, > the only rationale I heard was that GSAKMP re-design (from tunneled > GSAKMP) predates IKEv2 design. > As an implementor of GDOI and IKEv2, I would like to see the packet > headers and even messages of IKEv2 re-used in GSAKMP, however. > I actually didn't get to this thread yet. GSAKMP uses the message structure of ISAKMP, Ref. RFC 2408, Category: Standards Track. IKE is a DOI under ISAKMP. Yes, I know people are working on IKEv2, but the standard that GSAKMP is written to reference is RFC 2408. I don't believe IKEv2 is intended to replace ISAKMP. It is meant to replace IKEv1. Hugh _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 10 15:08:52 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13444 for ; Wed, 10 Sep 2003 15:08:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9E088536BE; Wed, 10 Sep 2003 15:08:11 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9E88C536C1 for ; Wed, 10 Sep 2003 15:06:12 -0400 (EDT) Received: (qmail 49463 invoked by uid 3269); 10 Sep 2003 19:06:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49460 invoked from network); 10 Sep 2003 19:06:12 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 10 Sep 2003 19:06:12 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8AJ63JD011672; Wed, 10 Sep 2003 14:06:03 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8AJ60eI028130; Wed, 10 Sep 2003 14:06:01 -0500 Received: from sparta.com (dhcp-15.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA18445; Wed, 10 Sep 2003 15:05:59 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations part 2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: George Gross , Uri Meth , msec@securemulticast.org To: "Lakshminath Dondeti" From: Hugh Harney In-Reply-To: <3F5F6166.3020402@americasm06.nt.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 15:05:59 -0400 Content-Transfer-Encoding: 7bit Lakshminath, On the subject of GDOI, IKEv2 and GSAKMP. GSAKMP was never intended to be integrated with IKE. It was intended to be a stand alone key management protocol that supported distributed key delivery. There is market demand for such a protocol. Several companies see this demand and are willing to put money into developing GSAKMP. I see that there is also a demand for an all encompassing key management protocol suite that encompasses the functions of IKEv2 and group key management. I've even heard people call this GDOI. Some people have even suggested borrowing the security policy piece of GSAKMP and incorporating this into GDOI. This was suggested to be named GDOIv2. To date GDOIv2 is vapor I-D. I support peoples efforts to create this Grand Unifying Key Management Suite. However, I, and several others, believe that there is still a need for a stand alone key management protocol that provides security for cryptographic groups, divorced from IKE and IKE like protocols. Hugh On Wednesday, Sep 10, 2003, at 13:37 US/Eastern, Lakshminath Dondeti wrote: > I am trying to understand this. > Geroge, are you saying that GSAKMP should be re-designed so that it > becomes GDOIv2 effectively, or, that the current messages are ok > (viz., RTJ, KD, Notify:ACK/Fail), but the payloads should be same as > in IKEv2? Either option would be a serious design change; for > example, GSAKMP header is quite different from an IKEv2 header. But, > the only rationale I heard was that GSAKMP re-design (from tunneled > GSAKMP) predates IKEv2 design. > As an implementor of GDOI and IKEv2, I would like to see the packet > headers and even messages of IKEv2 re-used in GSAKMP, however. > > cheers, > Lakshminath > > George Gross wrote: > >> Hi Hugh, >> >> inline below... >> >> On Mon, 8 Sep 2003, Hugh Harney wrote: >> >> >>> George, >>> >>> >>>> The IKE-v2 generic payload definition is found in section 3.2. I am >>>> indicating that GSAKMP payloads should be directly compatible with >>>> the >>>> current IKE-v2 spec semantics/syntax, not the ISAKMP/IKE-v1 specs >>>> that >>>> were written 6 years ago. Nor should GSAKMP roll its own payload >>>> type >>>> that differs from IKE-v2. In particular, GSAKMP should have the same >>>> concept of a "critical" bit as defined by IKE-v2 in section 3.2 and >>>> a >>>> set >>>> of Payload Type Values that match those that are already defined by >>>> IKE-v2 >>>> where they are duplicates in meaning. The following payload types >>>> should >>>> be used "as is" from IKE-v2 by GSAKMP: >>>> >>> WRT, the issue of how GSAKMP and the GSAKMP PT should format >>> information you have made some broad statements that sound like >>> requirements. You state here that GSAKMP should mirror IKEv2 in >>> payload >>> structure. Earlier you've stated that the Policy Token work should >>> mirror the work done in the AAA working group. >>> >>> I understand your concerns about interoperability, but these types of >>> statements really are changes to the MSEC charter. I don't believe >>> interoperability with IKEv2 or AAA is in the MSEC Charter. If you >>> really feel that the MSEC charter needs to change I'd suggest you >>> bring >>> that up with the chairs. >>> >> >> In most any other IETF working group, you normally would see a chorus >> of >> voices expressing similar views as I've expressed, and they would not >> have >> to cite the charter to have the standards track draft change to >> reflect >> good engineering principals. The MSEC list may be silent, but that >> does >> not change the process. Making GSAKMP integral to other facets of the >> Internet architecture is something you design in to minimize >> re-inventing >> the wheel, to make implementations less buggy, and to reduce the need >> for >> various protocols conversion gateways. In the context of making GSAKMP >> compatible with IKE-v2, this would allow an IKE-v2 implementation to >> extend to handle GSAKMP with fewer bugs, less redundant coding, and >> potentially reduce the difficulty of handling GDOI endpoints with that >> same implementation. Given these benefits, the burden of explaining >> why >> GSAKMP should not be IKE-v2 compatible as outlined above falls on the >> GSAKMP protocol designers, not the MSEC charter. >> >> As a prospective GSAKMP/GDOI implementor, I am not pleased with the >> artifical division that has lead to GDOI and GSAKMP occupying the same >> Internet. It is incorrect to say "they are different market >> requirements" >> and therefore can proceed independently in parallel. In fact, as a >> vendor >> who bids for business in both the defence and commercial sector, we >> fully >> expect to see secure multicast group deployments formed from mixtures >> of >> GSAKMP and GDOI endpoints. E.g. a DoD agency and an DoD contractor >> doing a >> teleconference. Minimizing the design distance between them will >> reduce >> the effort it takes to realize such applications. To that end, >> designing >> GSAKMP with IKE-v2, GDOI, and AAA considerations is common sense. In >> fact, >> I'd like to see if the differences between GDOI and GSAKMP can be >> narrowed >> to the only the registration SA, and with common logic and protocol >> for >> the rekey, policy token, and TLV encoding aspects. >> >> You've decided to put GSAKMP on standards track, and in this arena >> until >> now, you may not have had the benefit of other parties looking at the >> GSAKMP proposed design as vigorously as I have. GSAKMP is not a fait >> acomplii. It has the obligation to be a *mallable* design that accepts >> feedback, that includes other's requirements besides the co-author's >> design decisions. IMHO, there is nothing sacred in its currently >> drafted >> bits on the wire format or its semantics. You don't need a MSEC >> charter >> change to do this. >> >> Only then does GSAKMP have the potential become a proposed standard. >> And >> to date, in my view, the evidence is weighing very mixed wrt/ that >> outcome. >> >> George >> >> > >> >>> I think the best path forward is to focus on those issues that flow >>> from the MSEC Charter. >>> >>> Hugh >>> >>> >>> >> >> >> _______________________________________________ >> 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 > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 10 15:15:36 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14182 for ; Wed, 10 Sep 2003 15:15:35 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D002653794; Wed, 10 Sep 2003 15:14:49 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 070C053844 for ; Wed, 10 Sep 2003 15:12:43 -0400 (EDT) Received: (qmail 50693 invoked by uid 3269); 10 Sep 2003 19:12:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 50690 invoked from network); 10 Sep 2003 19:12:43 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 10 Sep 2003 19:12:43 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8AJC3f16608; Wed, 10 Sep 2003 14:12:03 -0500 (CDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SC65GMH9; Wed, 10 Sep 2003 12:12:03 -0700 Received: from americasm06.nt.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SQRYKK2A; Wed, 10 Sep 2003 15:12:01 -0400 Message-ID: <3F5F777C.1070306@americasm06.nt.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hugh Harney Cc: George Gross , Uri Meth , msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations References: <8CEC63EA-E3BF-11D7-8926-000A956E63C6@sparta.com> In-Reply-To: <8CEC63EA-E3BF-11D7-8926-000A956E63C6@sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 15:11:56 -0400 Content-Transfer-Encoding: 7bit Please scroll to the end. Hugh Harney wrote: > Lakshminath, > > > On Wednesday, Sep 10, 2003, at 13:37 US/Eastern, Lakshminath Dondeti > wrote: > >> I am trying to understand this. >> Geroge, are you saying that GSAKMP should be re-designed so that it >> becomes GDOIv2 effectively, or, that the current messages are ok >> (viz., RTJ, KD, Notify:ACK/Fail), but the payloads should be same as >> in IKEv2? Either option would be a serious design change; for >> example, GSAKMP header is quite different from an IKEv2 header. But, >> the only rationale I heard was that GSAKMP re-design (from tunneled >> GSAKMP) predates IKEv2 design. >> As an implementor of GDOI and IKEv2, I would like to see the packet >> headers and even messages of IKEv2 re-used in GSAKMP, however. >> > > I actually didn't get to this thread yet. I saw one of your responses to this thread ;-)! > > > GSAKMP uses the message structure of ISAKMP, Ref. RFC 2408, Category: > Standards Track. IKE is a DOI under ISAKMP. Yes, I know people are > working on IKEv2, but the standard that GSAKMP is written to reference > is RFC 2408. > > I don't believe IKEv2 is intended to replace ISAKMP. It is meant to > replace IKEv1. > > Hugh > But, you do agree that GSAKMP header is completely different from ISAKMP header (included below for quick reference), right? There are two issues: payload formats and message formats. The ISAKMP model is to establish a point-to-point tunnel first, and then negotiate a CHILD SA within the tunnel. Thus, GSAKMP message structure is quite different from that in RFC 2408. GSAKMP seems to use the "piggyback" technique that IKEv2 uses; thus the comparison to IKEv2. As George correctly alluded to, product groups want to be able to re-use code where possible. That's the motivation behind my message. regards, Lakshminath ISAKMP header: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Initiator ! ! Cookie ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Responder ! ! Cookie ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Message ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GSAKMP header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! !Group ID Type ! Group ID Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ ! Next Payload ! Version ! Exchange Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Sequence ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 10 15:22:46 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14570 for ; Wed, 10 Sep 2003 15:22:45 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4DDA153614; Wed, 10 Sep 2003 15:22:11 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DFD8B53614 for ; Wed, 10 Sep 2003 15:21:16 -0400 (EDT) Received: (qmail 53354 invoked by uid 3269); 10 Sep 2003 19:21:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53351 invoked from network); 10 Sep 2003 19:21:16 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 10 Sep 2003 19:21:16 -0000 Received: (qmail 88404 invoked by uid 1000); 10 Sep 2003 19:21:15 -0000 Received: from gmgross@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.071913 secs); 10 Sep 2003 19:21:15 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out1.oct.nac.net with SMTP; 10 Sep 2003 19:21:15 -0000 Received: (qmail 16625 invoked from network); 10 Sep 2003 19:21:09 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.166) by smtp-auth.nac.net with SMTP; 10 Sep 2003 19:21:09 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h8AHCK632182; Wed, 10 Sep 2003 13:12:20 -0400 From: George Gross To: Hugh Harney Cc: George Gross , Uri Meth , Subject: Re: [MSEC] GSAKMP issue 02: security assumptions discussion In-Reply-To: <0CFE5DC1-E3A4-11D7-8926-000A956E63C6@sparta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 13:12:20 -0400 (EDT) Hugh, Your reply dropped the following text from my e-mail and you did not respond to it: > Bottom line: to traverse NAT, GSAKMP will require the specification of a > negotiation of UDP encapsulation similar as has been defined for IKE-v2. > It also will need to decide how embedded IP addresses within GSAKMP are > handled by NAT. BTW, there may be IPR on the ESP over UDP negotiation, > so I would advise taking a look at the IPR notices to the IETF. Much as > one might like, we can not ignore interactions with NAT :o( Please indicate how you are handling NAT detection and negotiation of ESP over UDP. other comments inline... On Wed, 10 Sep 2003, Hugh Harney wrote: > George, > > I see your issue with our use of IPv4 as a group ID field. > > I think it best to remove the IPv4 reference in the Group ID field > altogether. This is particularly true because we have seen that most > groups do not have a tight coupling with an IP address anyway. This > will be corrected in future PT releases. > > The group ID must uniquely identify the cryptographic group, but it > does not need to identify the IP address of the data stream. Ok, so then the IP address of the data stream get specified in the policy token, right? I think this needs to be an authenticated quantity specified by the GO. OTOH, this gets clobbered by NAT ;o( sigh. perhaps a domain name for the group? > > > >>> and the reliable multicast transport protocols. > >> > >> Again, we assume that no Reliable Multicast Protocol (RMP) is > >> available. > >> Since by definition UDP is unreliable, the protocol allows for > >> multiple send > >> of rekey message in the absence of a reliable network to increase the > >> chances that all members receive this message. > >> > >> But again, I fail to see what this has to do wrt the security of the > >> protocol? I must be missing something here, please expound. > > > > An active attacker could intercept and drop a rekey event multicast > > message, and trigger a DoS attack. A RMP would detect the dropped > > delivery. Since you don't mandate a RMP, you need to specify the > > detection > > and recovery mechanism. i.e. timers and maximum number of retries for > > the > > various GSAKMP messages as part of the policy token and the > > specification. > > It should say when to give up and do a re-registration. Discussion on > > this list (most recently in mid-August) has also mentioned other error > > recovery strategies, such as explicit request for resend from the GCKS, > > and posting the rekey message in a well known directory/web site. Since > > GSAKMP embodies a concept of multiple GCKS, that redundancy could be > > used > > in the recovery process, if only it was specified. > > I'm not sure I agree here. The key management protocol has to remain in > a secure state. I think this is divorced from the reliable transport > mechanism. So do I hear you saying that even though GSAKMP may have multiple GCKS, there is no mechanism specified to recover from a lost rekey other than re-registration? e.g. the existing registration SA is not used to recover? > > I agree that the km protocol has to specify detection and recovery > mechanisms. I think this is best done wrt the keys and the successful > rekey events. I think the keys must have a lifespan, and there has to > be a local definition of mandatory rekey periods. Both of these events > are within the domain of key management. I'm uneasy specifying security > functionallity to non-security protocols. > > I agree that we need to include mention of redundant error recovery > strategies in the spec. I think these things help system architects use > GSAKMP in a system, but the security mechanisms that can be relied on > are the timers inside of GSAKMP. The GSAKMP spec and/or PT will need to specify minimum, maximum, and default values for these timers to assure inter-operability. > > > >>> It also should make an explicit statement about whether the trust > >>> model > >>> for "Security Suite 1" assumes > >>> that active attackers might compromise a Group Member(s) and whether > >>> the group can recover from such a compromise. > >> > >> I don't follow what you are getting at here. Everyone knows the > >> configuration of Security Suite 1 (SS1), it is published in the > >> standard. So > >> what is there to compromise? What SS1 provides is a capability for > >> the > >> GM and GCKS to converse using a short lived D-H exchange. Are you > >> asking that this short lived exchange is compromised and what happens > >> in > >> that instance, or are you asking something else in a broader context? > >> Please clarify. > > > > There are a variety of things that merit discussion: > > > > 1) This section should say something about GSAKMP being secure against > > passive adversaries outside of the group membership, but it is > > vulnerable > > to active attacks if a GM is compromised by an adversary. In other > > words, > > since GSAKMP does not mandate a multicast source authentication > > mechanism, > > a compromised GM could impersonate a peer. The compromised GM could not > > impersonate a GCKS rekey because such messages are signed. You should > > indicate the benefit of forward secrecy using LKH or other algorithm to > > recover from this situation. > > Yes this should be explained. > > > > 2) The GSAKMP protocol assumes that all GM and GCKS belong to a common > > PKI > > or else have a certificate path to a common root CA. The spec should > > indicate that the GO, GCKS, and GM all use a common configuration > > mechanisms to setup their one or more trusted root CA keys. This > > mechanism > > should be specified at a level that avoids inter-operability issues > > between vendors. > > We did not assume this. The access control and authorisation rules have > two parts. Rule and verification mechanism. The rule is specifically > designed to match a particular verification mechanism. So rule 1 can be > for PKI 1, rule 2 can be for PKI 2, rule 3 can relate to some database > someone has. Ok, then please clarify the text to explain this usage, perhaps an example would help. The GSAKMP spec or the PT spec should indicate the minimum number of PKI that an implementation must support. I infer that a value of 1, while valid, misses the point that any realistic deployment will need the ability to handle multiple PKI. > > > > 3) The GSAKMP header contains a sequence number that is assumed to be > > stored in non-volatile memory across GCKS reboots (or is it?, section > > 6.1 > > should discuss this). > OK > > > > 4) If GSAKMP has any kind of dependency on timestamps or > > synchronization > > of time across its endpoints, that should be stated (or if it does not, > > say that). discuss "rollover" time during rekey. > > So your saying it is unclear if there is a dependancy in our timers? We > should state when the timer only need to reference the local clock. Yes, the use of a local clock should be highlighted. Now that I'm looking at it, I am also wondering if the local key lifetime clock gets "restarted" at the arrival time of a rekey event message, and whether one partition of the group may get "out of sync" with another partition of the group if each successive rekey message to the first group partition got delayed by an adversary. The cumulative clock skew, when viewed across the whole group, may exceed the rollover time. In that scenario, could a group partition get stranded from the rest of the group because it is using an obsolete (i.e. expired) group key? just wondering out loud.... BTW, is the purpose of the PT "time issued" field defined in section 2.1.1.2 used to specify an expiration interval? if not, should not such a mechanism get added? would this be best expressed as an authenticated timestamp issued by a timestamp notary? > > > > 5) You are not defining the use of TESLA or any other multicast source > > authentication, correct? this section needs to say that. > OK > > > > 6) Does the GSAKMP protocol assume that the data SA has only a single > > multicast speaker? If not, then you should indicate that the receivers > > need to keep per multicast source SA state for sequence numbers and SA > > lifetime calculation. > > Actually, GSAKMP makes no assumptions about the data layer security > protocols. I think this is an issue for multicast IPSec. If the GSAKMP > PT is supporting multicast IPSec then this is a field that can be > added, but GSAKMP will not be a consumer of this field. It will be > passed through GSAKMP to the IPSec application. So you will be modifying the text in section 2.4.1.3.1 to indicate that multiple multicast speakers can be declared and how to do that? i.e. separate SPI per speaker. Q: Is there a separate group key per speaker? the text should say that Q: how does the "SA lifetime" expressed in traffic volume units interact with the "key lifetime" found in section 2.4.1.1? > > > > 7) what is the sliding window for acceptable sequence numbers in a > > rekey > > message? > > This can be an added field to help specify the rekey mechanisms in the > PT. Is this adiquate? Yes. > > > >>> Suggested issue resolution: > >>> > >>> The above topics each deserve their own sub-section 3.x. > > In some cases the topic is best included to clarify existing text. No doubt, the next rev of GSAKMP will have oodles of changes, perhaps an appendix annotating the changes would be a good idea? George > > Hugh > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 10 15:24:00 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14627 for ; Wed, 10 Sep 2003 15:23:59 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0E09E53783; Wed, 10 Sep 2003 15:22:18 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4F9AF53554 for ; Wed, 10 Sep 2003 15:21:52 -0400 (EDT) Received: (qmail 53524 invoked by uid 3269); 10 Sep 2003 19:21:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53521 invoked from network); 10 Sep 2003 19:21:52 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 10 Sep 2003 19:21:52 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8AJLaJD012026; Wed, 10 Sep 2003 14:21:36 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8AJLMeI028713; Wed, 10 Sep 2003 14:21:22 -0500 Received: from sparta.com (dhcp-15.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA18761; Wed, 10 Sep 2003 15:21:18 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: George Gross , Uri Meth , msec@securemulticast.org To: "Lakshminath Dondeti" From: Hugh Harney In-Reply-To: <3F5F777C.1070306@americasm06.nt.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 15:21:17 -0400 Content-Transfer-Encoding: 7bit Lakshminath, > But, you do agree that GSAKMP header is completely different from > ISAKMP header (included below for quick reference), right? GSAKMP uses the payload structures in ISAKMP. > There are two issues: payload formats and message formats. The ISAKMP > model is to establish a point-to-point tunnel first, and then > negotiate a CHILD SA within the tunnel. Thus, GSAKMP message > structure is quite different from that in RFC 2408. GSAKMP seems to > use the "piggyback" technique that IKEv2 uses; thus the comparison to > IKEv2. Piggyback? I'm not sure of the reference. We used the payload formats in ISAKMP. Yes, IKE also used many of the payloads of ISAKMP. I'm pointing out that we copied from the parent not the child. > As George correctly alluded to, product groups want to be able to > re-use code where possible. That's the motivation behind my message. So your saying that there is no room a GSAKMP standard unless it conforms to IKEv2? _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 10 15:30:37 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14830 for ; Wed, 10 Sep 2003 15:30:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3A147537F8; Wed, 10 Sep 2003 15:30:08 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7D29E53614 for ; Wed, 10 Sep 2003 15:29:15 -0400 (EDT) Received: (qmail 55085 invoked by uid 3269); 10 Sep 2003 19:29:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55082 invoked from network); 10 Sep 2003 19:29:15 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 10 Sep 2003 19:29:15 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8AJSaZ08632; Wed, 10 Sep 2003 15:28:37 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q0DAS7WV; Wed, 10 Sep 2003 15:28:35 -0400 Received: from americasm06.nt.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SQRYKK2X; Wed, 10 Sep 2003 15:28:36 -0400 Message-ID: <3F5F7B63.2000302@americasm06.nt.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hugh Harney Cc: George Gross , Uri Meth , msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations part 2 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 15:28:35 -0400 Content-Transfer-Encoding: 7bit Yes. I understand this (as it was explained to me before :-) ). However, when I saw George's message about modeling GSAKMP payloads after IKEv2 payloads, I was not sure whether there was a change in plans. Apparently not! I do have a comment on GSAKMP and its applicability as you explain below. It appears that GSAKMP connects to points at the top and the bottom of the ISAKMP family, i.e., GSAKMP's relationship with ISAKMP and IPsec. That probably is the cause for the repeated confusion on the design of GSAKMP. Once the relationship to IPsec is found as a common point, one can imagine (as George did) a scenario where there may be a GCKS that supports both GSAKMP and GDOI registration protocols, that share a common GSA. The questions about (or requests for accommodating) code re-use etc., follow from that. best regards, Lakshminath PS: GDOIv2 efforts - I have some interest in that TBD protocol - would be premature until IKEv2 goes through IESG last call. Once that is complete, I am sure we will see an I-D. Hugh Harney wrote: > Lakshminath, > > On the subject of GDOI, IKEv2 and GSAKMP. > > GSAKMP was never intended to be integrated with IKE. It was intended > to be a stand alone key management protocol that supported distributed > key delivery. There is market demand for such a protocol. Several > companies see this demand and are willing to put money into developing > GSAKMP. > > I see that there is also a demand for an all encompassing key > management protocol suite that encompasses the functions of IKEv2 and > group key management. I've even heard people call this GDOI. Some > people have even suggested borrowing the security policy piece of > GSAKMP and incorporating this into GDOI. This was suggested to be > named GDOIv2. To date GDOIv2 is vapor I-D. I support peoples efforts > to create this Grand Unifying Key Management Suite. However, I, and > several others, believe that there is still a need for a stand alone > key management protocol that provides security for cryptographic > groups, divorced from IKE and IKE like protocols. > > Hugh > > > > > > On Wednesday, Sep 10, 2003, at 13:37 US/Eastern, Lakshminath Dondeti > wrote: > >> I am trying to understand this. >> Geroge, are you saying that GSAKMP should be re-designed so that it >> becomes GDOIv2 effectively, or, that the current messages are ok >> (viz., RTJ, KD, Notify:ACK/Fail), but the payloads should be same as >> in IKEv2? Either option would be a serious design change; for >> example, GSAKMP header is quite different from an IKEv2 header. But, >> the only rationale I heard was that GSAKMP re-design (from tunneled >> GSAKMP) predates IKEv2 design. >> As an implementor of GDOI and IKEv2, I would like to see the packet >> headers and even messages of IKEv2 re-used in GSAKMP, however. >> >> cheers, >> Lakshminath >> >> George Gross wrote: >> >>> Hi Hugh, >>> >>> inline below... >>> >>> On Mon, 8 Sep 2003, Hugh Harney wrote: >>> >>> >>>> George, >>>> >>>> >>>>> The IKE-v2 generic payload definition is found in section 3.2. I am >>>>> indicating that GSAKMP payloads should be directly compatible with >>>>> the >>>>> current IKE-v2 spec semantics/syntax, not the ISAKMP/IKE-v1 specs >>>>> that >>>>> were written 6 years ago. Nor should GSAKMP roll its own payload >>>>> type >>>>> that differs from IKE-v2. In particular, GSAKMP should have the same >>>>> concept of a "critical" bit as defined by IKE-v2 in section 3.2 and a >>>>> set >>>>> of Payload Type Values that match those that are already defined by >>>>> IKE-v2 >>>>> where they are duplicates in meaning. The following payload types >>>>> should >>>>> be used "as is" from IKE-v2 by GSAKMP: >>>>> >>>> WRT, the issue of how GSAKMP and the GSAKMP PT should format >>>> information you have made some broad statements that sound like >>>> requirements. You state here that GSAKMP should mirror IKEv2 in >>>> payload >>>> structure. Earlier you've stated that the Policy Token work should >>>> mirror the work done in the AAA working group. >>>> >>>> I understand your concerns about interoperability, but these types of >>>> statements really are changes to the MSEC charter. I don't believe >>>> interoperability with IKEv2 or AAA is in the MSEC Charter. If you >>>> really feel that the MSEC charter needs to change I'd suggest you >>>> bring >>>> that up with the chairs. >>>> >>> >>> In most any other IETF working group, you normally would see a >>> chorus of >>> voices expressing similar views as I've expressed, and they would >>> not have >>> to cite the charter to have the standards track draft change to reflect >>> good engineering principals. The MSEC list may be silent, but that does >>> not change the process. Making GSAKMP integral to other facets of the >>> Internet architecture is something you design in to minimize >>> re-inventing >>> the wheel, to make implementations less buggy, and to reduce the >>> need for >>> various protocols conversion gateways. In the context of making GSAKMP >>> compatible with IKE-v2, this would allow an IKE-v2 implementation to >>> extend to handle GSAKMP with fewer bugs, less redundant coding, and >>> potentially reduce the difficulty of handling GDOI endpoints with that >>> same implementation. Given these benefits, the burden of explaining why >>> GSAKMP should not be IKE-v2 compatible as outlined above falls on the >>> GSAKMP protocol designers, not the MSEC charter. >>> >>> As a prospective GSAKMP/GDOI implementor, I am not pleased with the >>> artifical division that has lead to GDOI and GSAKMP occupying the same >>> Internet. It is incorrect to say "they are different market >>> requirements" >>> and therefore can proceed independently in parallel. In fact, as a >>> vendor >>> who bids for business in both the defence and commercial sector, we >>> fully >>> expect to see secure multicast group deployments formed from >>> mixtures of >>> GSAKMP and GDOI endpoints. E.g. a DoD agency and an DoD contractor >>> doing a >>> teleconference. Minimizing the design distance between them will reduce >>> the effort it takes to realize such applications. To that end, >>> designing >>> GSAKMP with IKE-v2, GDOI, and AAA considerations is common sense. In >>> fact, >>> I'd like to see if the differences between GDOI and GSAKMP can be >>> narrowed >>> to the only the registration SA, and with common logic and protocol for >>> the rekey, policy token, and TLV encoding aspects. >>> >>> You've decided to put GSAKMP on standards track, and in this arena >>> until >>> now, you may not have had the benefit of other parties looking at the >>> GSAKMP proposed design as vigorously as I have. GSAKMP is not a fait >>> acomplii. It has the obligation to be a *mallable* design that accepts >>> feedback, that includes other's requirements besides the co-author's >>> design decisions. IMHO, there is nothing sacred in its currently >>> drafted >>> bits on the wire format or its semantics. You don't need a MSEC charter >>> change to do this. >>> >>> Only then does GSAKMP have the potential become a proposed standard. >>> And >>> to date, in my view, the evidence is weighing very mixed wrt/ that >>> outcome. >>> >>> George >>> >>> > >>> >>>> I think the best path forward is to focus on those issues that flow >>>> from the MSEC Charter. >>>> >>>> Hugh >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > Hugh Harney Sparta, Inc. > hh@sparta.com 7075 Samuel Morse Drive > (410) 872-1515 x203 Columbia, MD, 21046 > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 10 15:42:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15548 for ; Wed, 10 Sep 2003 15:42:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 49DE153897; Wed, 10 Sep 2003 15:42:04 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DE5AD535A8 for ; Wed, 10 Sep 2003 15:40:02 -0400 (EDT) Received: (qmail 56757 invoked by uid 3269); 10 Sep 2003 19:40:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56754 invoked from network); 10 Sep 2003 19:40:02 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 10 Sep 2003 19:40:02 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8AJdKf20903; Wed, 10 Sep 2003 14:39:21 -0500 (CDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SC65G325; Wed, 10 Sep 2003 12:39:20 -0700 Received: from americasm06.nt.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SQRYKKJG; Wed, 10 Sep 2003 15:39:19 -0400 Message-ID: <3F5F7DE6.7030809@americasm06.nt.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hugh Harney Cc: George Gross , Uri Meth , msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 15:39:18 -0400 Content-Transfer-Encoding: 7bit Hugh Harney wrote: > Lakshminath, > >> But, you do agree that GSAKMP header is completely different from >> ISAKMP header (included below for quick reference), right? > > GSAKMP uses the payload structures in ISAKMP. I agree that some of the payloads and the generic header are reused and I appreciate that. But, the main header is different. > >> There are two issues: payload formats and message formats. The >> ISAKMP model is to establish a point-to-point tunnel first, and then >> negotiate a CHILD SA within the tunnel. Thus, GSAKMP message >> structure is quite different from that in RFC 2408. GSAKMP seems to >> use the "piggyback" technique that IKEv2 uses; thus the comparison to >> IKEv2. > > > Piggyback? I'm not sure of the reference. We used the payload formats > in ISAKMP. Yes, IKE also used many of the payloads of ISAKMP. I'm > pointing out that we copied from the parent not the child. Piggybacking is an IKEv2 reference (Sec 2.17 of -10-). Please see my other email addressing your other comments. > >> As George correctly alluded to, product groups want to be able to >> re-use code where possible. That's the motivation behind my message. > > > So your saying that there is no room a GSAKMP standard unless it > conforms to IKEv2? No, I am not saying that. Although I don't like the three message version (I explained why and Andrea and I exchanged some emails on that CC'ed to the list, a while ago), if there is a need for the GSAKMP design (to me it is distributed group management, PT etc.), great. But, I just hope that IKEv2 payloads and if possible messages (does the DoS protection stuff already do this?), and other techniques (e.g., NAT traversal that George pointed to) can be used intact. best regards, Lakshminath > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 10 16:00:35 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16112 for ; Wed, 10 Sep 2003 16:00:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 78AF553650; Wed, 10 Sep 2003 16:00:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9D7955372E for ; Wed, 10 Sep 2003 15:58:10 -0400 (EDT) Received: (qmail 59865 invoked by uid 3269); 10 Sep 2003 19:58:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59862 invoked from network); 10 Sep 2003 19:58:10 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 10 Sep 2003 19:58:10 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8AJvwJD012785; Wed, 10 Sep 2003 14:57:58 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8AJvreI030163; Wed, 10 Sep 2003 14:57:54 -0500 Received: from sparta.com (dhcp-15.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA19322; Wed, 10 Sep 2003 15:57:51 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: George Gross , Uri Meth , msec@securemulticast.org To: "Lakshminath Dondeti" From: Hugh Harney In-Reply-To: <3F5F7DE6.7030809@americasm06.nt.com> Message-Id: <0E8893BD-E3C9-11D7-8926-000A956E63C6@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 15:57:50 -0400 Content-Transfer-Encoding: 7bit Lakshminath, > if there is a need for the GSAKMP design (to me it is distributed > group management, PT etc.), great. That was the intent. > But, I just hope that IKEv2 payloads and if possible messages (does > the DoS protection stuff already do this?), and other techniques > (e.g., NAT traversal that George pointed to) can be used intact. > We adopted the IKEv2 cookie concepts. I'm still trying to see the requirement for inclusion of IKEv2 NAT transversal in a group context. The whole concept of negotiation of group secure data delivery parameters is a bit strange to me. If there is negotiation, I think it is needed prior to the GO creating a policy token. My issue with this is that the group should provide a common level of service for group data delivery. To allow the negotiation of different levels of service means that the level of data protection drops to the lowest level of negotiation, for the entire group. This bothers me. Hugh _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 10 16:55:17 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18050 for ; Wed, 10 Sep 2003 16:55:17 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2447F538B8; Wed, 10 Sep 2003 16:34:52 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A9E5553610 for ; Wed, 10 Sep 2003 16:33:12 -0400 (EDT) Received: (qmail 66422 invoked by uid 3269); 10 Sep 2003 20:33:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66419 invoked from network); 10 Sep 2003 20:33:12 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 10 Sep 2003 20:33:12 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8AKWUZ21203; Wed, 10 Sep 2003 16:32:30 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q0DAS8M2; Wed, 10 Sep 2003 16:32:29 -0400 Received: from americasm06.nt.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SQRYKKNJ; Wed, 10 Sep 2003 16:32:30 -0400 Message-ID: <3F5F8A5D.6060409@americasm06.nt.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hugh Harney Cc: George Gross , Uri Meth , msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations References: <0E8893BD-E3C9-11D7-8926-000A956E63C6@sparta.com> In-Reply-To: <0E8893BD-E3C9-11D7-8926-000A956E63C6@sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 16:32:29 -0400 Content-Transfer-Encoding: 7bit Hugh, Just to clarify, I don't mean that any thing should be negotiated in the group context; thus, all group security parameters are downloaded. Within the context of the point-to-point connection established for the download process, NAT traversal etc., needs to be addressed. Lakshminath Hugh Harney wrote: > Lakshminath, > >> if there is a need for the GSAKMP design (to me it is distributed >> group management, PT etc.), great. > > > That was the intent. > >> But, I just hope that IKEv2 payloads and if possible messages (does >> the DoS protection stuff already do this?), and other techniques >> (e.g., NAT traversal that George pointed to) can be used intact. >> > > We adopted the IKEv2 cookie concepts. I'm still trying to see the > requirement for inclusion of IKEv2 NAT transversal in a group context. > The whole concept of negotiation of group secure data delivery > parameters is a bit strange to me. If there is negotiation, I think it > is needed prior to the GO creating a policy token. My issue with this > is that the group should provide a common level of service for group > data delivery. To allow the negotiation of different levels of service > means that the level of data protection drops to the lowest level of > negotiation, for the entire group. This bothers me. > > Hugh > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 10 16:59:39 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18176 for ; Wed, 10 Sep 2003 16:59:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id AD36A5379E; Wed, 10 Sep 2003 16:58:43 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id BF2EF536C0 for ; Wed, 10 Sep 2003 16:56:48 -0400 (EDT) Received: (qmail 70063 invoked by uid 3269); 10 Sep 2003 20:56:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 70060 invoked from network); 10 Sep 2003 20:56:48 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 10 Sep 2003 20:56:48 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8AKueJD013879; Wed, 10 Sep 2003 15:56:40 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8AKubeI032363; Wed, 10 Sep 2003 15:56:37 -0500 Received: from sparta.com (dhcp-15.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id QAA20253; Wed, 10 Sep 2003 16:56:35 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: George Gross , Uri Meth , msec@securemulticast.org To: "Lakshminath Dondeti" From: Hugh Harney In-Reply-To: <3F5F8A5D.6060409@americasm06.nt.com> Message-Id: <42D2C435-E3D1-11D7-8926-000A956E63C6@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 16:56:33 -0400 Content-Transfer-Encoding: 7bit On Wednesday, Sep 10, 2003, at 16:32 US/Eastern, Lakshminath Dondeti wrote: > Hugh, > > Just to clarify, I don't mean that any thing should be negotiated in > the group context; thus, all group security parameters are downloaded. > Within the context of the point-to-point connection established for > the download process, NAT traversal etc., needs to be addressed. I guess I'm a bit lost here. I assume we can get communication between the GM and GC/KS. Remember the GM is initiating the contact. GSAKMP doesn't use the IP address for identification of the endpoint, so do I care that it is changed by a NAT? I agree that it may be difficult to tell the data layer security service that the key is for the broadcast on IP address x.y.p. However, we can tell the GM that the key is for group ID 123, where 123 is unique. The mapping of group ID to multicast traffic can be handled in many ways - announcements, web pages, registration sites... I'm missing the issue here. Please help me out. Hugh _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 10 21:02:03 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25560 for ; Wed, 10 Sep 2003 21:02:02 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 00A185368D; Wed, 10 Sep 2003 21:00:30 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1390E53665 for ; Wed, 10 Sep 2003 20:58:44 -0400 (EDT) Received: (qmail 4855 invoked by uid 3269); 11 Sep 2003 00:58:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 4852 invoked from network); 11 Sep 2003 00:58:44 -0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by klesh.pair.com with SMTP; 11 Sep 2003 00:58:44 -0000 Received: from cscoamera13263.cisco.com (rtp-vpn2-557.cisco.com [10.82.242.45]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8B0wAGN020844; Wed, 10 Sep 2003 20:58:11 -0400 (EDT) Message-Id: <5.1.1.5.2.20030910175728.0243da18@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Hugh Harney From: Mark Baugher Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations Cc: "Lakshminath Dondeti" , George Gross , Uri Meth , msec@securemulticast.org In-Reply-To: <8CEC63EA-E3BF-11D7-8926-000A956E63C6@sparta.com> References: <3F5F6166.3020402@americasm06.nt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 17:58:08 -0700 Hugh I don't see how GSAKMP can be said to reference RFC 2408 when the header of GSAKMP messages is incompatible with 2408. Mark At 02:49 PM 9/10/2003 -0400, Hugh Harney wrote: >Lakshminath, > > >On Wednesday, Sep 10, 2003, at 13:37 US/Eastern, Lakshminath Dondeti wrote: > >>I am trying to understand this. >>Geroge, are you saying that GSAKMP should be re-designed so that it >>becomes GDOIv2 effectively, or, that the current messages are ok (viz., >>RTJ, KD, Notify:ACK/Fail), but the payloads should be same as in >>IKEv2? Either option would be a serious design change; for example, >>GSAKMP header is quite different from an IKEv2 header. But, the only >>rationale I heard was that GSAKMP re-design (from tunneled GSAKMP) >>predates IKEv2 design. >>As an implementor of GDOI and IKEv2, I would like to see the packet >>headers and even messages of IKEv2 re-used in GSAKMP, however. > >I actually didn't get to this thread yet. > >GSAKMP uses the message structure of ISAKMP, Ref. RFC 2408, Category: >Standards Track. IKE is a DOI under ISAKMP. Yes, I know people are working >on IKEv2, but the standard that GSAKMP is written to reference is RFC 2408. > >I don't believe IKEv2 is intended to replace ISAKMP. It is meant to >replace IKEv1. > >Hugh > > > >_______________________________________________ >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 Sep 10 21:02:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25584 for ; Wed, 10 Sep 2003 21:02:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0BCFC538C2; Wed, 10 Sep 2003 21:02:06 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 82C2253885 for ; Wed, 10 Sep 2003 21:00:36 -0400 (EDT) Received: (qmail 5091 invoked by uid 3269); 11 Sep 2003 01:00:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 5088 invoked from network); 11 Sep 2003 01:00:36 -0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by klesh.pair.com with SMTP; 11 Sep 2003 01:00:36 -0000 Received: from cscoamera13263.cisco.com (rtp-vpn2-557.cisco.com [10.82.242.45]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8B0xvGN021044; Wed, 10 Sep 2003 20:59:57 -0400 (EDT) Message-Id: <5.1.1.5.2.20030910175904.0243a958@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Hugh Harney From: Mark Baugher Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations Cc: "Lakshminath Dondeti" , George Gross , Uri Meth , msec@securemulticast.org In-Reply-To: References: <3F5F777C.1070306@americasm06.nt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 17:59:55 -0700 Hugh I don't think that compatibility with RFC 2408 is on the report card for GSAKMP. It is inspired by ISAKMP and the names look similar. Beyond that, it is pretty different. Mark At 03:21 PM 9/10/2003 -0400, Hugh Harney wrote: >Lakshminath, > > >>But, you do agree that GSAKMP header is completely different from ISAKMP >>header (included below for quick reference), right? > >GSAKMP uses the payload structures in ISAKMP. > > >>There are two issues: payload formats and message formats. The ISAKMP >>model is to establish a point-to-point tunnel first, and then negotiate a >>CHILD SA within the tunnel. Thus, GSAKMP message structure is quite >>different from that in RFC 2408. GSAKMP seems to use the "piggyback" >>technique that IKEv2 uses; thus the comparison to IKEv2. > >Piggyback? I'm not sure of the reference. We used the payload formats in >ISAKMP. Yes, IKE also used many of the payloads of ISAKMP. I'm pointing >out that we copied from the parent not the child. > >>As George correctly alluded to, product groups want to be able to re-use >>code where possible. That's the motivation behind my message. > >So your saying that there is no room a GSAKMP standard unless it conforms >to IKEv2? > > >_______________________________________________ >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 Thu Sep 11 09:53:35 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22766 for ; Thu, 11 Sep 2003 09:53:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 874ED53949; Thu, 11 Sep 2003 09:50:05 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A6E1F5392F for ; Thu, 11 Sep 2003 09:48:13 -0400 (EDT) Received: (qmail 67106 invoked by uid 3269); 11 Sep 2003 13:48:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67103 invoked from network); 11 Sep 2003 13:48:13 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 11 Sep 2003 13:48:13 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8BDlxJD020770; Thu, 11 Sep 2003 08:47:59 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8BDlreI013390; Thu, 11 Sep 2003 08:47:53 -0500 Received: from sparta.com (dhcp-15.columbia.sparta.com [157.185.80.26]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id JAA27426; Thu, 11 Sep 2003 09:47:50 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Lakshminath Dondeti" , George Gross , Uri Meth , msec@securemulticast.org To: Mark Baugher From: Hugh Harney In-Reply-To: <5.1.1.5.2.20030910175904.0243a958@mira-sjc5-6.cisco.com> Message-Id: <89349125-E45E-11D7-8926-000A956E63C6@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 11 Sep 2003 09:47:51 -0400 Content-Transfer-Encoding: 7bit Mark, I like the idea of a report card. : ) It brings to mind an IETF school. We took as much of the payload formats as we could, but your right it is not fully compliant. The topic of payload formats was brought up by someone. hugh On Wednesday, Sep 10, 2003, at 20:59 US/Eastern, Mark Baugher wrote: > Hugh > I don't think that compatibility with RFC 2408 is on the report card > for GSAKMP. It is inspired by ISAKMP and the names look similar. > Beyond that, it is pretty different. > > Mark > At 03:21 PM 9/10/2003 -0400, Hugh Harney wrote: >> Lakshminath, >> >> >>> But, you do agree that GSAKMP header is completely different from >>> ISAKMP header (included below for quick reference), right? >> >> GSAKMP uses the payload structures in ISAKMP. >> >> >>> There are two issues: payload formats and message formats. The >>> ISAKMP model is to establish a point-to-point tunnel first, and then >>> negotiate a CHILD SA within the tunnel. Thus, GSAKMP message >>> structure is quite different from that in RFC 2408. GSAKMP seems to >>> use the "piggyback" technique that IKEv2 uses; thus the comparison >>> to IKEv2. >> >> Piggyback? I'm not sure of the reference. We used the payload formats >> in ISAKMP. Yes, IKE also used many of the payloads of ISAKMP. I'm >> pointing out that we copied from the parent not the child. >> >>> As George correctly alluded to, product groups want to be able to >>> re-use code where possible. That's the motivation behind my >>> message. >> >> So your saying that there is no room a GSAKMP standard unless it >> conforms to IKEv2? >> >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://www.pairlist.net/mailman/listinfo/msec > > > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Sep 11 12:53:06 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01048 for ; Thu, 11 Sep 2003 12:53:06 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DB4C35382C; Thu, 11 Sep 2003 12:52:38 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 36DEE53720 for ; Thu, 11 Sep 2003 12:51:14 -0400 (EDT) Received: (qmail 774 invoked by uid 3269); 11 Sep 2003 16:51:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 771 invoked from network); 11 Sep 2003 16:51:13 -0000 Received: from prue.eim.surrey.ac.uk (131.227.76.5) by klesh.pair.com with SMTP; 11 Sep 2003 16:51:13 -0000 Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19xUeh-0001Qu-00; Thu, 11 Sep 2003 17:50:51 +0100 Message-ID: <3F60A7E9.49741888@eim.surrey.ac.uk> From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hugh Harney Cc: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations part 2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.6 required=5.5 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_XM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19xUeh-0001Qu-00*uZpq2vZ2Bww* (SECM, UniS) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 11 Sep 2003 17:50:50 +0100 Content-Transfer-Encoding: 7bit Hi Hugh, I completely agree with you on the need for a stand alone key management protocol that support distributed key delivery like GSAKMP. Having one of msec protocols (like GSAKMP) completely divorced :) from IKE is a good idea. Yesterday we had IKE-v1, today we have IKE-v2, who knows about tomorrow. In addition, we still have problems with IPSEC regarding multicast. So an independent protocol is good and safe. Haitham Hugh Harney wrote: > Lakshminath, > > On the subject of GDOI, IKEv2 and GSAKMP. > > GSAKMP was never intended to be integrated with IKE. It was intended to > be a stand alone key management protocol that supported distributed key > delivery. There is market demand for such a protocol. Several companies > see this demand and are willing to put money into developing GSAKMP. > > I see that there is also a demand for an all encompassing key > management protocol suite that encompasses the functions of IKEv2 and > group key management. I've even heard people call this GDOI. Some > people have even suggested borrowing the security policy piece of > GSAKMP and incorporating this into GDOI. This was suggested to be named > GDOIv2. To date GDOIv2 is vapor I-D. I support peoples efforts to > create this Grand Unifying Key Management Suite. However, I, and > several others, believe that there is still a need for a stand alone > key management protocol that provides security for cryptographic > groups, divorced from IKE and IKE like protocols. > > Hugh > > On Wednesday, Sep 10, 2003, at 13:37 US/Eastern, Lakshminath Dondeti > wrote: > > > I am trying to understand this. > > Geroge, are you saying that GSAKMP should be re-designed so that it > > becomes GDOIv2 effectively, or, that the current messages are ok > > (viz., RTJ, KD, Notify:ACK/Fail), but the payloads should be same as > > in IKEv2? Either option would be a serious design change; for > > example, GSAKMP header is quite different from an IKEv2 header. But, > > the only rationale I heard was that GSAKMP re-design (from tunneled > > GSAKMP) predates IKEv2 design. > > As an implementor of GDOI and IKEv2, I would like to see the packet > > headers and even messages of IKEv2 re-used in GSAKMP, however. > > > > cheers, > > Lakshminath > > > > George Gross wrote: > > > >> Hi Hugh, > >> > >> inline below... > >> > >> On Mon, 8 Sep 2003, Hugh Harney wrote: > >> > >> > >>> George, > >>> > >>> > >>>> The IKE-v2 generic payload definition is found in section 3.2. I am > >>>> indicating that GSAKMP payloads should be directly compatible with > >>>> the > >>>> current IKE-v2 spec semantics/syntax, not the ISAKMP/IKE-v1 specs > >>>> that > >>>> were written 6 years ago. Nor should GSAKMP roll its own payload > >>>> type > >>>> that differs from IKE-v2. In particular, GSAKMP should have the same > >>>> concept of a "critical" bit as defined by IKE-v2 in section 3.2 and > >>>> a > >>>> set > >>>> of Payload Type Values that match those that are already defined by > >>>> IKE-v2 > >>>> where they are duplicates in meaning. The following payload types > >>>> should > >>>> be used "as is" from IKE-v2 by GSAKMP: > >>>> > >>> WRT, the issue of how GSAKMP and the GSAKMP PT should format > >>> information you have made some broad statements that sound like > >>> requirements. You state here that GSAKMP should mirror IKEv2 in > >>> payload > >>> structure. Earlier you've stated that the Policy Token work should > >>> mirror the work done in the AAA working group. > >>> > >>> I understand your concerns about interoperability, but these types of > >>> statements really are changes to the MSEC charter. I don't believe > >>> interoperability with IKEv2 or AAA is in the MSEC Charter. If you > >>> really feel that the MSEC charter needs to change I'd suggest you > >>> bring > >>> that up with the chairs. > >>> > >> > >> In most any other IETF working group, you normally would see a chorus > >> of > >> voices expressing similar views as I've expressed, and they would not > >> have > >> to cite the charter to have the standards track draft change to > >> reflect > >> good engineering principals. The MSEC list may be silent, but that > >> does > >> not change the process. Making GSAKMP integral to other facets of the > >> Internet architecture is something you design in to minimize > >> re-inventing > >> the wheel, to make implementations less buggy, and to reduce the need > >> for > >> various protocols conversion gateways. In the context of making GSAKMP > >> compatible with IKE-v2, this would allow an IKE-v2 implementation to > >> extend to handle GSAKMP with fewer bugs, less redundant coding, and > >> potentially reduce the difficulty of handling GDOI endpoints with that > >> same implementation. Given these benefits, the burden of explaining > >> why > >> GSAKMP should not be IKE-v2 compatible as outlined above falls on the > >> GSAKMP protocol designers, not the MSEC charter. > >> > >> As a prospective GSAKMP/GDOI implementor, I am not pleased with the > >> artifical division that has lead to GDOI and GSAKMP occupying the same > >> Internet. It is incorrect to say "they are different market > >> requirements" > >> and therefore can proceed independently in parallel. In fact, as a > >> vendor > >> who bids for business in both the defence and commercial sector, we > >> fully > >> expect to see secure multicast group deployments formed from mixtures > >> of > >> GSAKMP and GDOI endpoints. E.g. a DoD agency and an DoD contractor > >> doing a > >> teleconference. Minimizing the design distance between them will > >> reduce > >> the effort it takes to realize such applications. To that end, > >> designing > >> GSAKMP with IKE-v2, GDOI, and AAA considerations is common sense. In > >> fact, > >> I'd like to see if the differences between GDOI and GSAKMP can be > >> narrowed > >> to the only the registration SA, and with common logic and protocol > >> for > >> the rekey, policy token, and TLV encoding aspects. > >> > >> You've decided to put GSAKMP on standards track, and in this arena > >> until > >> now, you may not have had the benefit of other parties looking at the > >> GSAKMP proposed design as vigorously as I have. GSAKMP is not a fait > >> acomplii. It has the obligation to be a *mallable* design that accepts > >> feedback, that includes other's requirements besides the co-author's > >> design decisions. IMHO, there is nothing sacred in its currently > >> drafted > >> bits on the wire format or its semantics. You don't need a MSEC > >> charter > >> change to do this. > >> > >> Only then does GSAKMP have the potential become a proposed standard. > >> And > >> to date, in my view, the evidence is weighing very mixed wrt/ that > >> outcome. > >> > >> George > >> > >> > > >> > >>> I think the best path forward is to focus on those issues that flow > >>> from the MSEC Charter. > >>> > >>> Hugh > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> 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 > > > > > Hugh Harney Sparta, Inc. > hh@sparta.com 7075 Samuel Morse Drive > (410) 872-1515 x203 Columbia, MD, 21046 > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Sep 11 13:47:33 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02896 for ; Thu, 11 Sep 2003 13:47:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id F288D53701; Thu, 11 Sep 2003 13:45:33 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7676C5366E for ; Thu, 11 Sep 2003 13:42:12 -0400 (EDT) Received: (qmail 9408 invoked by uid 3269); 11 Sep 2003 17:42:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 9405 invoked from network); 11 Sep 2003 17:42:12 -0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by klesh.pair.com with SMTP; 11 Sep 2003 17:42:12 -0000 Received: from cscoamera13263.cisco.com (rtp-vpn1-272.cisco.com [10.82.225.16]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8BHfWGN010847; Thu, 11 Sep 2003 13:41:34 -0400 (EDT) Message-Id: <5.1.1.5.2.20030911104108.04dbdeb0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Haitham Cruickshank From: Mark Baugher Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations part 2 Cc: Hugh Harney , msec@securemulticast.org In-Reply-To: <3F60A7E9.49741888@eim.surrey.ac.uk> References: 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 11 Sep 2003 10:41:31 -0700 Haitham, At 05:50 PM 9/11/2003 +0100, Haitham Cruickshank wrote: >Hi Hugh, > >I completely agree with you on the need for a stand alone key management >protocol >that support distributed key delivery like GSAKMP. Having one of msec >protocols >(like GSAKMP) completely divorced :) from IKE is a good idea. Yesterday >we had >IKE-v1, today we have IKE-v2, who knows about tomorrow. In addition, we >still have >problems with IPSEC regarding multicast. Which problems are you referring to here? thanks, Mark >So an independent protocol is good and >safe. > >Haitham > >Hugh Harney wrote: > > > Lakshminath, > > > > On the subject of GDOI, IKEv2 and GSAKMP. > > > > GSAKMP was never intended to be integrated with IKE. It was intended to > > be a stand alone key management protocol that supported distributed key > > delivery. There is market demand for such a protocol. Several companies > > see this demand and are willing to put money into developing GSAKMP. > > > > I see that there is also a demand for an all encompassing key > > management protocol suite that encompasses the functions of IKEv2 and > > group key management. I've even heard people call this GDOI. Some > > people have even suggested borrowing the security policy piece of > > GSAKMP and incorporating this into GDOI. This was suggested to be named > > GDOIv2. To date GDOIv2 is vapor I-D. I support peoples efforts to > > create this Grand Unifying Key Management Suite. However, I, and > > several others, believe that there is still a need for a stand alone > > key management protocol that provides security for cryptographic > > groups, divorced from IKE and IKE like protocols. > > > > Hugh > > > > On Wednesday, Sep 10, 2003, at 13:37 US/Eastern, Lakshminath Dondeti > > wrote: > > > > > I am trying to understand this. > > > Geroge, are you saying that GSAKMP should be re-designed so that it > > > becomes GDOIv2 effectively, or, that the current messages are ok > > > (viz., RTJ, KD, Notify:ACK/Fail), but the payloads should be same as > > > in IKEv2? Either option would be a serious design change; for > > > example, GSAKMP header is quite different from an IKEv2 header. But, > > > the only rationale I heard was that GSAKMP re-design (from tunneled > > > GSAKMP) predates IKEv2 design. > > > As an implementor of GDOI and IKEv2, I would like to see the packet > > > headers and even messages of IKEv2 re-used in GSAKMP, however. > > > > > > cheers, > > > Lakshminath > > > > > > George Gross wrote: > > > > > >> Hi Hugh, > > >> > > >> inline below... > > >> > > >> On Mon, 8 Sep 2003, Hugh Harney wrote: > > >> > > >> > > >>> George, > > >>> > > >>> > > >>>> The IKE-v2 generic payload definition is found in section 3.2. I am > > >>>> indicating that GSAKMP payloads should be directly compatible with > > >>>> the > > >>>> current IKE-v2 spec semantics/syntax, not the ISAKMP/IKE-v1 specs > > >>>> that > > >>>> were written 6 years ago. Nor should GSAKMP roll its own payload > > >>>> type > > >>>> that differs from IKE-v2. In particular, GSAKMP should have the same > > >>>> concept of a "critical" bit as defined by IKE-v2 in section 3.2 and > > >>>> a > > >>>> set > > >>>> of Payload Type Values that match those that are already defined by > > >>>> IKE-v2 > > >>>> where they are duplicates in meaning. The following payload types > > >>>> should > > >>>> be used "as is" from IKE-v2 by GSAKMP: > > >>>> > > >>> WRT, the issue of how GSAKMP and the GSAKMP PT should format > > >>> information you have made some broad statements that sound like > > >>> requirements. You state here that GSAKMP should mirror IKEv2 in > > >>> payload > > >>> structure. Earlier you've stated that the Policy Token work should > > >>> mirror the work done in the AAA working group. > > >>> > > >>> I understand your concerns about interoperability, but these types of > > >>> statements really are changes to the MSEC charter. I don't believe > > >>> interoperability with IKEv2 or AAA is in the MSEC Charter. If you > > >>> really feel that the MSEC charter needs to change I'd suggest you > > >>> bring > > >>> that up with the chairs. > > >>> > > >> > > >> In most any other IETF working group, you normally would see a chorus > > >> of > > >> voices expressing similar views as I've expressed, and they would not > > >> have > > >> to cite the charter to have the standards track draft change to > > >> reflect > > >> good engineering principals. The MSEC list may be silent, but that > > >> does > > >> not change the process. Making GSAKMP integral to other facets of the > > >> Internet architecture is something you design in to minimize > > >> re-inventing > > >> the wheel, to make implementations less buggy, and to reduce the need > > >> for > > >> various protocols conversion gateways. In the context of making GSAKMP > > >> compatible with IKE-v2, this would allow an IKE-v2 implementation to > > >> extend to handle GSAKMP with fewer bugs, less redundant coding, and > > >> potentially reduce the difficulty of handling GDOI endpoints with that > > >> same implementation. Given these benefits, the burden of explaining > > >> why > > >> GSAKMP should not be IKE-v2 compatible as outlined above falls on the > > >> GSAKMP protocol designers, not the MSEC charter. > > >> > > >> As a prospective GSAKMP/GDOI implementor, I am not pleased with the > > >> artifical division that has lead to GDOI and GSAKMP occupying the same > > >> Internet. It is incorrect to say "they are different market > > >> requirements" > > >> and therefore can proceed independently in parallel. In fact, as a > > >> vendor > > >> who bids for business in both the defence and commercial sector, we > > >> fully > > >> expect to see secure multicast group deployments formed from mixtures > > >> of > > >> GSAKMP and GDOI endpoints. E.g. a DoD agency and an DoD contractor > > >> doing a > > >> teleconference. Minimizing the design distance between them will > > >> reduce > > >> the effort it takes to realize such applications. To that end, > > >> designing > > >> GSAKMP with IKE-v2, GDOI, and AAA considerations is common sense. In > > >> fact, > > >> I'd like to see if the differences between GDOI and GSAKMP can be > > >> narrowed > > >> to the only the registration SA, and with common logic and protocol > > >> for > > >> the rekey, policy token, and TLV encoding aspects. > > >> > > >> You've decided to put GSAKMP on standards track, and in this arena > > >> until > > >> now, you may not have had the benefit of other parties looking at the > > >> GSAKMP proposed design as vigorously as I have. GSAKMP is not a fait > > >> acomplii. It has the obligation to be a *mallable* design that accepts > > >> feedback, that includes other's requirements besides the co-author's > > >> design decisions. IMHO, there is nothing sacred in its currently > > >> drafted > > >> bits on the wire format or its semantics. You don't need a MSEC > > >> charter > > >> change to do this. > > >> > > >> Only then does GSAKMP have the potential become a proposed standard. > > >> And > > >> to date, in my view, the evidence is weighing very mixed wrt/ that > > >> outcome. > > >> > > >> George > > >> > > >> > > > >> > > >>> I think the best path forward is to focus on those issues that flow > > >>> from the MSEC Charter. > > >>> > > >>> Hugh > > >>> > > >>> > > >>> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > Hugh Harney Sparta, > Inc. > > hh@sparta.com 7075 Samuel > Morse Drive > > (410) 872-1515 x203 Columbia, MD, 21046 > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > >-- >Dr. Haitham S. Cruickshank > >Senior Research Fellow in Communications >Centre for Communication Systems Research (CCSR) >School of Electronics, Computing and Mathematics >University of Surrey >Guildford, Surrey GU2 7XH, UK > >Tel: +44 1483 686007 (indirect 689844) >Fax: +44 1483 686011 >e-mail: H.Cruickshank@surrey.ac.uk >http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Sep 12 12:04:44 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29514 for ; Fri, 12 Sep 2003 12:04:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E3CF95364C; Fri, 12 Sep 2003 12:04:01 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1236653610 for ; Fri, 12 Sep 2003 12:01:52 -0400 (EDT) Received: (qmail 52657 invoked by uid 3269); 12 Sep 2003 16:01:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52654 invoked from network); 12 Sep 2003 16:01:51 -0000 Received: from prue.eim.surrey.ac.uk (131.227.76.5) by klesh.pair.com with SMTP; 12 Sep 2003 16:01:51 -0000 Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19xqMX-0007C7-00; Fri, 12 Sep 2003 17:01:33 +0100 Message-ID: <3F61EDDD.67440BAB@eim.surrey.ac.uk> From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations part 2 References: <5.1.1.5.2.20030911104108.04dbdeb0@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.6 required=5.5 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_XM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19xqMX-0007C7-00*2QOQtbzED.A* (SECM, UniS) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 12 Sep 2003 17:01:33 +0100 Content-Transfer-Encoding: 7bit Hi Mark, Mark Baugher wrote: > Haitham, > > At 05:50 PM 9/11/2003 +0100, Haitham Cruickshank wrote: > >Hi Hugh, > > > >I completely agree with you on the need for a stand alone key management > >protocol > >that support distributed key delivery like GSAKMP. Having one of msec > >protocols > >(like GSAKMP) completely divorced :) from IKE is a good idea. Yesterday > >we had > >IKE-v1, today we have IKE-v2, who knows about tomorrow. In addition, we > >still have > >problems with IPSEC regarding multicast. I had a quick read through the ESP latest draft (draft-ietf-ipsec-esp-v3-06.txt). It seems that most multicast issues are solved except that there is no anti-replay mechanism for multi-sender SA (Shared SA among multiple senders), which I think is not a big issue. Therefore I am glad that I was wrong and we are inline with IPSEC. > > > Which problems are you referring to here? > > thanks, Mark > > >So an independent protocol is good and > >safe. > > > >Haitham > > > >Hugh Harney wrote: > > > > > Lakshminath, > > > > > > On the subject of GDOI, IKEv2 and GSAKMP. > > > > > > GSAKMP was never intended to be integrated with IKE. It was intended to > > > be a stand alone key management protocol that supported distributed key > > > delivery. There is market demand for such a protocol. Several companies > > > see this demand and are willing to put money into developing GSAKMP. > > > > > > I see that there is also a demand for an all encompassing key > > > management protocol suite that encompasses the functions of IKEv2 and > > > group key management. I've even heard people call this GDOI. Some > > > people have even suggested borrowing the security policy piece of > > > GSAKMP and incorporating this into GDOI. This was suggested to be named > > > GDOIv2. To date GDOIv2 is vapor I-D. I support peoples efforts to > > > create this Grand Unifying Key Management Suite. However, I, and > > > several others, believe that there is still a need for a stand alone > > > key management protocol that provides security for cryptographic > > > groups, divorced from IKE and IKE like protocols. > > > > > > Hugh > > > > > > On Wednesday, Sep 10, 2003, at 13:37 US/Eastern, Lakshminath Dondeti > > > wrote: > > > > > > > I am trying to understand this. > > > > Geroge, are you saying that GSAKMP should be re-designed so that it > > > > becomes GDOIv2 effectively, or, that the current messages are ok > > > > (viz., RTJ, KD, Notify:ACK/Fail), but the payloads should be same as > > > > in IKEv2? Either option would be a serious design change; for > > > > example, GSAKMP header is quite different from an IKEv2 header. But, > > > > the only rationale I heard was that GSAKMP re-design (from tunneled > > > > GSAKMP) predates IKEv2 design. > > > > As an implementor of GDOI and IKEv2, I would like to see the packet > > > > headers and even messages of IKEv2 re-used in GSAKMP, however. > > > > > > > > cheers, > > > > Lakshminath > > > > > > > > George Gross wrote: > > > > > > > >> Hi Hugh, > > > >> > > > >> inline below... > > > >> > > > >> On Mon, 8 Sep 2003, Hugh Harney wrote: > > > >> > > > >> > > > >>> George, > > > >>> > > > >>> > > > >>>> The IKE-v2 generic payload definition is found in section 3.2. I am > > > >>>> indicating that GSAKMP payloads should be directly compatible with > > > >>>> the > > > >>>> current IKE-v2 spec semantics/syntax, not the ISAKMP/IKE-v1 specs > > > >>>> that > > > >>>> were written 6 years ago. Nor should GSAKMP roll its own payload > > > >>>> type > > > >>>> that differs from IKE-v2. In particular, GSAKMP should have the same > > > >>>> concept of a "critical" bit as defined by IKE-v2 in section 3.2 and > > > >>>> a > > > >>>> set > > > >>>> of Payload Type Values that match those that are already defined by > > > >>>> IKE-v2 > > > >>>> where they are duplicates in meaning. The following payload types > > > >>>> should > > > >>>> be used "as is" from IKE-v2 by GSAKMP: > > > >>>> > > > >>> WRT, the issue of how GSAKMP and the GSAKMP PT should format > > > >>> information you have made some broad statements that sound like > > > >>> requirements. You state here that GSAKMP should mirror IKEv2 in > > > >>> payload > > > >>> structure. Earlier you've stated that the Policy Token work should > > > >>> mirror the work done in the AAA working group. > > > >>> > > > >>> I understand your concerns about interoperability, but these types of > > > >>> statements really are changes to the MSEC charter. I don't believe > > > >>> interoperability with IKEv2 or AAA is in the MSEC Charter. If you > > > >>> really feel that the MSEC charter needs to change I'd suggest you > > > >>> bring > > > >>> that up with the chairs. > > > >>> > > > >> > > > >> In most any other IETF working group, you normally would see a chorus > > > >> of > > > >> voices expressing similar views as I've expressed, and they would not > > > >> have > > > >> to cite the charter to have the standards track draft change to > > > >> reflect > > > >> good engineering principals. The MSEC list may be silent, but that > > > >> does > > > >> not change the process. Making GSAKMP integral to other facets of the > > > >> Internet architecture is something you design in to minimize > > > >> re-inventing > > > >> the wheel, to make implementations less buggy, and to reduce the need > > > >> for > > > >> various protocols conversion gateways. In the context of making GSAKMP > > > >> compatible with IKE-v2, this would allow an IKE-v2 implementation to > > > >> extend to handle GSAKMP with fewer bugs, less redundant coding, and > > > >> potentially reduce the difficulty of handling GDOI endpoints with that > > > >> same implementation. Given these benefits, the burden of explaining > > > >> why > > > >> GSAKMP should not be IKE-v2 compatible as outlined above falls on the > > > >> GSAKMP protocol designers, not the MSEC charter. > > > >> > > > >> As a prospective GSAKMP/GDOI implementor, I am not pleased with the > > > >> artifical division that has lead to GDOI and GSAKMP occupying the same > > > >> Internet. It is incorrect to say "they are different market > > > >> requirements" > > > >> and therefore can proceed independently in parallel. In fact, as a > > > >> vendor > > > >> who bids for business in both the defence and commercial sector, we > > > >> fully > > > >> expect to see secure multicast group deployments formed from mixtures > > > >> of > > > >> GSAKMP and GDOI endpoints. E.g. a DoD agency and an DoD contractor > > > >> doing a > > > >> teleconference. Minimizing the design distance between them will > > > >> reduce > > > >> the effort it takes to realize such applications. To that end, > > > >> designing > > > >> GSAKMP with IKE-v2, GDOI, and AAA considerations is common sense. In > > > >> fact, > > > >> I'd like to see if the differences between GDOI and GSAKMP can be > > > >> narrowed > > > >> to the only the registration SA, and with common logic and protocol > > > >> for > > > >> the rekey, policy token, and TLV encoding aspects. > > > >> > > > >> You've decided to put GSAKMP on standards track, and in this arena > > > >> until > > > >> now, you may not have had the benefit of other parties looking at the > > > >> GSAKMP proposed design as vigorously as I have. GSAKMP is not a fait > > > >> acomplii. It has the obligation to be a *mallable* design that accepts > > > >> feedback, that includes other's requirements besides the co-author's > > > >> design decisions. IMHO, there is nothing sacred in its currently > > > >> drafted > > > >> bits on the wire format or its semantics. You don't need a MSEC > > > >> charter > > > >> change to do this. > > > >> > > > >> Only then does GSAKMP have the potential become a proposed standard. > > > >> And > > > >> to date, in my view, the evidence is weighing very mixed wrt/ that > > > >> outcome. > > > >> > > > >> George > > > >> > > > >> > > > > >> > > > >>> I think the best path forward is to focus on those issues that flow > > > >>> from the MSEC Charter. > > > >>> > > > >>> Hugh > > > >>> > > > >>> > > > >>> > > > >> > > > >> > > > >> _______________________________________________ > > > >> 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 > > > > > > > > > > > Hugh Harney Sparta, > > Inc. > > > hh@sparta.com 7075 Samuel > > Morse Drive > > > (410) 872-1515 x203 Columbia, MD, 21046 > > > > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://www.pairlist.net/mailman/listinfo/msec > > > >-- > >Dr. Haitham S. Cruickshank > > > >Senior Research Fellow in Communications > >Centre for Communication Systems Research (CCSR) > >School of Electronics, Computing and Mathematics > >University of Surrey > >Guildford, Surrey GU2 7XH, UK > > > >Tel: +44 1483 686007 (indirect 689844) > >Fax: +44 1483 686011 > >e-mail: H.Cruickshank@surrey.ac.uk > >http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > > > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Sep 18 10:06:51 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12602 for ; Thu, 18 Sep 2003 10:06:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A8B4953705; Thu, 18 Sep 2003 10:06:22 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id BF208535B5 for ; Thu, 18 Sep 2003 10:02:41 -0400 (EDT) Received: (qmail 90634 invoked by uid 3269); 18 Sep 2003 14:02:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90631 invoked from network); 18 Sep 2003 14:02:41 -0000 Received: from mail2.eivd.ch (HELO smtp-relay) (193.134.216.149) by klesh.pair.com with SMTP; 18 Sep 2003 14:02:41 -0000 Received: from FUN ([10.192.73.111]) by smtp-relay (8.12.7/8.12.7/YCOM SA SMTPGateway 1.70) with SMTP id h8IE2aHA023875 for ; Thu, 18 Sep 2003 16:02:38 +0200 From: "schweizer laurent" To: 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Virus-Scanned: Scanned by Amavisd / YCOM SA Subject: [MSEC] MIKEY & SP 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 18 Sep 2003 16:05:15 +0200 Content-Transfer-Encoding: 7bit Hello! I have a question about MIKEY with the pre-shared method I want to know, how the Security Policy (6.10) & SRTP Policy (6.10.1) is negotiated because, I see that the SP payload is only send by the initiator. Laurent _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Sep 18 10:44:40 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15869 for ; Thu, 18 Sep 2003 10:44:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8D2BD5361A; Thu, 18 Sep 2003 10:44:00 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6CD38535C9 for ; Thu, 18 Sep 2003 10:37:14 -0400 (EDT) Received: (qmail 97279 invoked by uid 3269); 18 Sep 2003 14:37:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97276 invoked from network); 18 Sep 2003 14:37:13 -0000 Received: from albatross-ext.wise.edt.ericsson.se (193.180.251.49) by klesh.pair.com with SMTP; 18 Sep 2003 14:37:13 -0000 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8IEb4Av003098; Thu, 18 Sep 2003 16:37:05 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 18 Sep 2003 16:37:27 +0200 Message-ID: <1F55F6582266314A85A55F6241509B6707EF4E67@Esealnt863.al.sw.ericsson.se> From: "Fredrik Lindholm (KI/EAB)" To: "'schweizer laurent'" , msec@securemulticast.org Subject: RE: [MSEC] MIKEY & SP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 18 Sep 2003 16:34:43 +0200 Basically, you don't. If the responder does not support the offer, an error message is sent back (possibly including the supported parameters). See also Section 5.1.1. /Fredrik > -----Original Message----- > From: schweizer laurent [mailto:laurent.schweizer@eivd.ch] > Sent: Thursday, September 18, 2003 16:05 > To: msec@securemulticast.org > Subject: [MSEC] MIKEY & SP > > > Hello! > > I have a question about MIKEY with the pre-shared method > > I want to know, how the Security Policy (6.10) & SRTP Policy > (6.10.1) is > negotiated because, > I see that the SP payload is only send by the initiator. > > Laurent > > > > _______________________________________________ > 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 Sep 22 17:42:59 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12816 for ; Mon, 22 Sep 2003 17:42:58 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8F21F53718; Mon, 22 Sep 2003 17:42:26 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 04A4D5366A for ; Mon, 22 Sep 2003 17:41:23 -0400 (EDT) Received: (qmail 76397 invoked by uid 3269); 22 Sep 2003 21:41:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76393 invoked from network); 22 Sep 2003 21:41:22 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 22 Sep 2003 21:41:22 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8MLfKZ6009336; Mon, 22 Sep 2003 16:41:21 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8MLfJcL026140; Mon, 22 Sep 2003 16:41:19 -0500 Received: from sparta.com (ssh.columbia.sparta.com [157.185.80.253]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id RAA27148; Mon, 22 Sep 2003 17:41:17 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length Content-Type: multipart/alternative; boundary=Apple-Mail-2-60337580 Mime-Version: 1.0 (Apple Message framework v552) Cc: To: George Gross From: Hugh Harney In-Reply-To: Message-Id: <82DA6B96-ED45-11D7-80EA-000A956E63C6@sparta.com> X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 22 Sep 2003 17:41:23 -0400 --Apple-Mail-2-60337580 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit George, Don't worry all questions will be discussed before 04 is released. George, > > GSAKMP issue 24 > > Section and relevant text passage: > > Section 4.2.1.2, the spec says: > > "The Policy Token and Key Download payloads are sent encrypted in the > KEK > generated by the Key Creation payload information using the mechanisms > defined in the group announcement." > > Comment/issue description: > > However, the group announcement is done out of band and it is not > defined > within this specification. Yet here it directly impacts what algorithms > and key lengths one would expect to encounter in the Key Download > message. > This seems to imply you can't connect to the group unless a candidate > member is privy to some non-standard pre-arranged convention, which is > overly restrictive and non-interoperable. > > Suggested issue resolution: > > I think that the "mechanisms defined in the group announcement" should > also be > copied as a new set of fields in the Request To Join message. That > way, the GCKS > can accept group members who did not hear the group announcement, or > may have heard an > older version of the group announcement that specified a different KEK > algorithm, > mode, and key length than a more recent version of that announcement. > > Further, the protocol spec should mandate at least one algorithm, > mode, and key > length that both GCKS and group members are both required to implement > for the KEK. > > This seems to be a place where you would say something like: > > "...using the mechanisms defined in the group announcement, which are > required to be identical to the set defined for IKEv2, or the IANA > registry's current set of algorithms. This includes the same MUST > implement requirements as IKEv2" > > or some words to that effect (wordsmithing TBD). > I think there are two issues being discussed here. First, announcing the security suite for a group. I really don't like the idea of having negotiable security suited for the registration protocol. The level of security algorithms has to be equivalent across the group. (the old your only as secure as your weakest link argument). This problem is exacerbated in creating a group because all communicating entities do not connect to each other while setting up the group key. Second, specifying a must algorithm for key download. I agree that we need to pick a MUST algorithm. However, the choice of MUST is a bit difficult. The cryptographic requirements for key encryption algorithms is a bit different than that required for key creation. If we need to specify a MUST we may want to specify RFC 3394 "Advanced Encryption Standard (AES) Key Wrap Algorithm". I am a bit worried because 3394 is not in a standard crypto toolkit. Hugh --Apple-Mail-2-60337580 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit George, Don't worry all questions will be discussed before 04 is released. George, GSAKMP issue 24 Section and relevant text passage: Section 4.2.1.2, the spec says: "The Policy Token and Key Download payloads are sent encrypted in the KEK generated by the Key Creation payload information using the mechanisms defined in the group announcement." Comment/issue description: However, the group announcement is done out of band and it is not defined within this specification. Yet here it directly impacts what algorithms and key lengths one would expect to encounter in the Key Download message. This seems to imply you can't connect to the group unless a candidate member is privy to some non-standard pre-arranged convention, which is overly restrictive and non-interoperable. Suggested issue resolution: I think that the "mechanisms defined in the group announcement" should also be copied as a new set of fields in the Request To Join message. That way, the GCKS can accept group members who did not hear the group announcement, or may have heard an older version of the group announcement that specified a different KEK algorithm, mode, and key length than a more recent version of that announcement. Further, the protocol spec should mandate at least one algorithm, mode, and key length that both GCKS and group members are both required to implement for the KEK. This seems to be a place where you would say something like: "...using the mechanisms defined in the group announcement, which are required to be identical to the set defined for IKEv2, or the IANA registry's current set of algorithms. This includes the same MUST implement requirements as IKEv2" or some words to that effect (wordsmithing TBD). I think there are two issues being discussed here. First, announcing the security suite for a group. I really don't like the idea of having negotiable security suited for the registration protocol. The level of security algorithms has to be equivalent across the group. (the old your only as secure as your weakest link argument). This problem is exacerbated in creating a group because all communicating entities do not connect to each other while setting up the group key. Second, specifying a must algorithm for key download. I agree that we need to pick a MUST algorithm. However, the choice of MUST is a bit difficult. The cryptographic requirements for key encryption algorithms is a bit different than that required for key creation. If we need to specify a MUST we may want to specify RFC 3394 "TimesAdvanced Encryption Standard (AES) Key Wrap Algorithm". I am a bit worried because 3394 is not in a standard crypto toolkit. Hugh --Apple-Mail-2-60337580-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Sep 22 17:46:27 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12927 for ; Mon, 22 Sep 2003 17:46:26 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C05255366D; Mon, 22 Sep 2003 17:46:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1F87F5366A for ; Mon, 22 Sep 2003 17:44:07 -0400 (EDT) Received: (qmail 76799 invoked by uid 3269); 22 Sep 2003 21:44:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76795 invoked from network); 22 Sep 2003 21:44:06 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 22 Sep 2003 21:44:06 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8MLi5Z6009359; Mon, 22 Sep 2003 16:44:05 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8MLi4cL026233; Mon, 22 Sep 2003 16:44:04 -0500 Received: from sparta.com (ssh.columbia.sparta.com [157.185.80.253]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id RAA27188; Mon, 22 Sep 2003 17:44:02 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: George Gross From: Hugh Harney In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 22 Sep 2003 17:44:08 -0400 Content-Transfer-Encoding: 7bit George, I just noticed that there is an RFC for using 3DES for key wrapping. Hugh _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Sep 22 23:37:38 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06676 for ; Mon, 22 Sep 2003 23:37:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A6FFC53644; Mon, 22 Sep 2003 23:37:07 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 63919535F8 for ; Mon, 22 Sep 2003 23:35:06 -0400 (EDT) Received: (qmail 40066 invoked by uid 3269); 23 Sep 2003 03:35:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40063 invoked from network); 23 Sep 2003 03:35:05 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 23 Sep 2003 03:35:05 -0000 Received: (qmail 27188 invoked by uid 1000); 23 Sep 2003 03:33:13 -0000 Received: from gmgross@nac.net by smtp-out2.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 1.984328 secs); 23 Sep 2003 03:33:13 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out2.oct.nac.net with SMTP; 23 Sep 2003 03:33:10 -0000 Received: (qmail 68967 invoked from network); 23 Sep 2003 03:32:18 -0000 Received: from unknown (HELO nsx.garage) (gmgross@64.21.175.11) by smtp-auth.nac.net with SMTP; 23 Sep 2003 03:32:18 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h8N1LT801162; Mon, 22 Sep 2003 21:21:29 -0400 From: George Gross To: Hugh Harney Cc: George Gross , Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length In-Reply-To: <82DA6B96-ED45-11D7-80EA-000A956E63C6@sparta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 22 Sep 2003 21:21:29 -0400 (EDT) Hi Hugh, On Mon, 22 Sep 2003, Hugh Harney wrote: > George, > > Don't worry all questions will be discussed before 04 is released. looking forward to it, albeit I'll be saturated this week, so my responses will be congestion controlled.... > > George, > > > > > GSAKMP issue 24 > > > > Section and relevant text passage: > > > > Section 4.2.1.2, the spec says: > > > > "The Policy Token and Key Download payloads are sent encrypted in the > > KEK > > generated by the Key Creation payload information using the mechanisms > > defined in the group announcement." > > > > Comment/issue description: > > > > However, the group announcement is done out of band and it is not > > defined > > within this specification. Yet here it directly impacts what algorithms > > and key lengths one would expect to encounter in the Key Download > > message. > > This seems to imply you can't connect to the group unless a candidate > > member is privy to some non-standard pre-arranged convention, which is > > overly restrictive and non-interoperable. > > > > Suggested issue resolution: > > > > I think that the "mechanisms defined in the group announcement" should > > also be > > copied as a new set of fields in the Request To Join message. That > > way, the GCKS > > can accept group members who did not hear the group announcement, or > > may have heard an > > older version of the group announcement that specified a different KEK > > algorithm, > > mode, and key length than a more recent version of that announcement. > > > > Further, the protocol spec should mandate at least one algorithm, > > mode, and key > > length that both GCKS and group members are both required to implement > > for the KEK. > > > > This seems to be a place where you would say something like: > > > > "...using the mechanisms defined in the group announcement, which are > > required to be identical to the set defined for IKEv2, or the IANA > > registry's current set of algorithms. This includes the same MUST > > implement requirements as IKEv2" > > > > or some words to that effect (wordsmithing TBD). > > > I think there are two issues being discussed here. > > First, announcing the security suite for a group. > > I really don't like the idea of having negotiable security suited for > the registration protocol. The level of security algorithms has to be > equivalent across the group. (the old your only as secure as your > weakest link argument). This problem is exacerbated in creating a group > because all communicating entities do not connect to each other while > setting up the group key. Let see if I hear your point of view correctly: are you saying that the selection of a "weak" registration SA encryption protocol could potentially weaken the integrity of group SA? or a weak group encryption algorithm for the group SA is the problem you are worried about? However, I'm concerned about this being too brittle an approach once deployed into field practice. I'm too tired at the moment to try to sketch out a scenario where this would occur, but I'm thinking along the lines of my earlier e-mails that had heterogenous endpoints (multi-vendor, multi-version, and GDOI/GSAKMP). It seems hard operationally to make a large-scale multicast group all in lockstep synchronize and sing one tune...even if it reduces to the "weakest link security" that might be "good enough" for local group policy if the alternative is incomplete group connectivity and stranded endpoints. > > Second, specifying a must algorithm for key download. I infer by context that you are referring to how to key wrap encrypt the Key Download payload within a Re-key Event Message (e.g. for GTEK or LKH). Yes, this needs to be nailed down. See observation/comment below about AES vs. DES. OTOH, the registration SA could be protected in another method than key wrap/encryption. The whole Key Download Message (including the Key Download payload within that message) could be completely encrypted by an encryption key derived from the Diffie-Hellman secret key material SKEYSEED, ala IKE-v2 section 2.14. Is there any reason why one could not do key derivation here for the GSAKMP registration SA? that would also require a PRF algorithm spec too... I notice that the current GSAKMP policy token draft table 6 only specifies "preplaced key" for key creation, which I assume means a "pre-shared secret key" between GCKS and GM, right? Q: what is the lifetime of the GSAKMP registration SA? > > I agree that we need to pick a MUST algorithm. However, the choice of > MUST is a bit difficult. The cryptographic requirements for key > encryption algorithms is a bit different than that required for key > creation. If we need to specify a MUST we may want to specify RFC 3394 > "Advanced Encryption Standard (AES) Key Wrap Algorithm". > > I am a bit worried because 3394 is not in a standard crypto toolkit. As you indicated in a subsequent e-mail, informational RFC3217 specifies triple-DES key wrap. While I'm partial to AES, triple-DES is today's norm, so I suppose we should point to RFC3217 as the MUST, and RFC3394 as the SHOULD+. that said, I've noticed that IKE-v2 section 3.3.4 talks about mandatory algorithm IDs, and basically says that the management interface must be flexible enough to configure anything: Diffie-Hellman parameters, key lengths, various flavors of crypto-suites. Perhaps clone a page from the IKE-v2 book about how to generally handle this topic in GSAKMP? br, George > > Hugh > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Sep 23 00:18:50 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08383 for ; Tue, 23 Sep 2003 00:18:50 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A88AA53782; Tue, 23 Sep 2003 00:16:20 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5E77353618 for ; Tue, 23 Sep 2003 00:14:18 -0400 (EDT) Received: (qmail 74872 invoked by uid 3269); 23 Sep 2003 04:14:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74869 invoked from network); 23 Sep 2003 04:14:18 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 23 Sep 2003 04:14:18 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8N4EHZ6011784; Mon, 22 Sep 2003 23:14:17 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8N4EHcL032103; Mon, 22 Sep 2003 23:14:17 -0500 Received: from sparta.com (ssh.columbia.sparta.com [157.185.80.253]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id AAA00574; Tue, 23 Sep 2003 00:14:15 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: George Gross , To: George Gross From: Hugh Harney In-Reply-To: Message-Id: <688BBA21-ED7C-11D7-B54E-000A956E63C6@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 23 Sep 2003 00:14:21 -0400 Content-Transfer-Encoding: 7bit Hi George, comments in-line, sorry if it is getting to be a large e-mail. On Monday, Sep 22, 2003, at 21:21 US/Eastern, George Gross wrote: > Hi Hugh, > > On Mon, 22 Sep 2003, Hugh Harney wrote: > >> George, >> >> Don't worry all questions will be discussed before 04 is released. > > looking forward to it, albeit I'll be saturated this week, so my > responses > will be congestion controlled.... I've got more than a couple of pans on the stove myself. > >> >> George, >> >>> >>> GSAKMP issue 24 >>> >>> Section and relevant text passage: >>> >>> Section 4.2.1.2, the spec says: >>> >>> "The Policy Token and Key Download payloads are sent encrypted in the >>> KEK >>> generated by the Key Creation payload information using the >>> mechanisms >>> defined in the group announcement." >>> >>> Comment/issue description: >>> >>> However, the group announcement is done out of band and it is not >>> defined >>> within this specification. Yet here it directly impacts what >>> algorithms >>> and key lengths one would expect to encounter in the Key Download >>> message. >>> This seems to imply you can't connect to the group unless a candidate >>> member is privy to some non-standard pre-arranged convention, which >>> is >>> overly restrictive and non-interoperable. >>> >>> Suggested issue resolution: >>> >>> I think that the "mechanisms defined in the group announcement" >>> should >>> also be >>> copied as a new set of fields in the Request To Join message. That >>> way, the GCKS >>> can accept group members who did not hear the group announcement, or >>> may have heard an >>> older version of the group announcement that specified a different >>> KEK >>> algorithm, >>> mode, and key length than a more recent version of that announcement. >>> >>> Further, the protocol spec should mandate at least one algorithm, >>> mode, and key >>> length that both GCKS and group members are both required to >>> implement >>> for the KEK. >>> >>> This seems to be a place where you would say something like: >>> >>> "...using the mechanisms defined in the group announcement, which are >>> required to be identical to the set defined for IKEv2, or the IANA >>> registry's current set of algorithms. This includes the same MUST >>> implement requirements as IKEv2" >>> >>> or some words to that effect (wordsmithing TBD). >>> >> I think there are two issues being discussed here. >> >> First, announcing the security suite for a group. >> >> I really don't like the idea of having negotiable security suited for >> the registration protocol. The level of security algorithms has to be >> equivalent across the group. (the old your only as secure as your >> weakest link argument). This problem is exacerbated in creating a >> group >> because all communicating entities do not connect to each other while >> setting up the group key. > > Let see if I hear your point of view correctly: are you saying that the > selection of a "weak" registration SA encryption protocol could > potentially weaken the integrity of group SA? or a weak group > encryption > algorithm for the group SA is the problem you are worried about? In order for the group SA to be meaningful, everyone in the group must be able to trust that the mechanisms used to set-up and protect the group SA. This means that the algorithms used to register the GMs have to be equivalent from a security perspective. Let's take an extreme example: Let's assume that the GO decides that the data being protected by the group SA is of highest priority. The GO specifies that Security Suite 1 is necessary to join that group. Next, If GM A only supports the top tier algorithms for registration, because only those algorithms are adiquate, then GM A will use those algorithms to connect with the GC/KS. However, GM B doesn't have top tier algorithms. GM B negotiates the use of something less than the top tier to join the group that GM A is a member of. Then GM B gets access to the group SA keys using less than the top tier. That means that an adversary would only have to defete the non-top tier algorithms used by GM B to get access to the key that GM A is using. Hence, GM A's top tier algorithms do not protect it. The security of the group SA keys is limited to the protection of the weakest algorithms used. > > However, I'm concerned about this being too brittle an approach once > deployed into field practice. I'm too tired at the moment to try to > sketch > out a scenario where this would occur, but I'm thinking along the > lines of > my earlier e-mails that had heterogenous endpoints (multi-vendor, > multi-version, and GDOI/GSAKMP). It seems hard operationally to make a > large-scale multicast group all in lockstep synchronize and sing one > tune...even if it reduces to the "weakest link security" that might be > "good enough" for local group policy if the alternative is incomplete > group connectivity and stranded endpoints. I think this is taken care of if we allow a security suite to specify a set of equivalent algorithms. Only those algorithms in the security suite are acceptable, but any of them are acceptable. Also, you have to remember that the GO sets the security suite and creates the PT based on the data protection requirements of the group. There may be cases where people can't join a group. That is a feature not a problem. Not everyone should always be allowed to join a group. A simple example: I don't want my bank to lock my money up using a cardboard box just because that's all they have. My money needs to be protected by steel. If the bank can't meet that protection requirement then I don't want them protecting my money. > >> >> Second, specifying a must algorithm for key download. > > I infer by context that you are referring to how to key wrap encrypt > the > Key Download payload within a Re-key Event Message (e.g. for GTEK or > LKH). > Yes, this needs to be nailed down. See observation/comment below about > AES > vs. DES. > > OTOH, the registration SA could be protected in another method than key > wrap/encryption. The whole Key Download Message (including the Key > Download payload within that message) could be completely encrypted by > an > encryption key derived from the Diffie-Hellman secret key material > SKEYSEED, ala IKE-v2 section 2.14. Is there any reason why one could > not > do key derivation here for the GSAKMP registration SA? that would also > require a PRF algorithm spec too... I notice that the current GSAKMP > policy token draft table 6 only specifies "preplaced key" for key > creation, which I assume means a "pre-shared secret key" between GCKS > and > GM, right? I expect that D-H (or something similar) will be used to create the download key. I was pointing out that IKEv2 doesn't do key wrapping. We have to make sure we meet the key wrapping requirements. We use D-H to create the key download keys in GSAKMP. If the PT only states pre-placed that needs to be expanded. We do need to support pre-placed, but not be limited to only PP. > > Q: what is the lifetime of the GSAKMP registration SA? I think this is open right now. My thoughts have been to limit the lifespan. > >> >> I agree that we need to pick a MUST algorithm. However, the choice of >> MUST is a bit difficult. The cryptographic requirements for key >> encryption algorithms is a bit different than that required for key >> creation. If we need to specify a MUST we may want to specify RFC 3394 >> "Advanced Encryption Standard (AES) Key Wrap Algorithm". >> >> I am a bit worried because 3394 is not in a standard crypto toolkit. > > As you indicated in a subsequent e-mail, informational RFC3217 > specifies > triple-DES key wrap. While I'm partial to AES, triple-DES is today's > norm, > so I suppose we should point to RFC3217 as the MUST, and RFC3394 as the > SHOULD+. I need to perk on this. I think I tend to agree. However, 3217 isn't in standard toolkits right now. I don't think. > > that said, I've noticed that IKE-v2 section 3.3.4 talks about mandatory > algorithm IDs, and basically says that the management interface must be > flexible enough to configure anything: Diffie-Hellman parameters, key > lengths, various flavors of crypto-suites. Perhaps clone a page from > the > IKE-v2 book about how to generally handle this topic in GSAKMP? I'll borrow anything that I can. > > br, > George > >> >> Hugh >> >> >> > > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Sep 23 08:22:27 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09354 for ; Tue, 23 Sep 2003 08:22:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BBD7F535EF; Tue, 23 Sep 2003 08:22:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 284F1535DE for ; Tue, 23 Sep 2003 08:21:15 -0400 (EDT) Received: (qmail 57489 invoked by uid 3269); 23 Sep 2003 12:21:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57486 invoked from network); 23 Sep 2003 12:21:15 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 23 Sep 2003 12:21:15 -0000 Received: (qmail 690 invoked by uid 1000); 23 Sep 2003 12:21:14 -0000 Received: from gmgross@nac.net by smtp-out2.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.025419 secs); 23 Sep 2003 12:21:14 -0000 Received: from unknown (HELO mercury.nac.net) (64.21.52.92) by smtp-out2.oct.nac.net with SMTP; 23 Sep 2003 12:21:14 -0000 Received: (qmail 68910 invoked from network); 23 Sep 2003 12:20:32 -0000 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.163) by smtp-auth.nac.net with SMTP; 23 Sep 2003 12:20:32 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h8NA9cn01753; Tue, 23 Sep 2003 06:09:38 -0400 From: George Gross To: Hugh Harney Cc: George Gross , Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length In-Reply-To: <688BBA21-ED7C-11D7-B54E-000A956E63C6@sparta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 23 Sep 2003 06:09:38 -0400 (EDT) Hi Hugh, okay, to re-cap what we've discussed/agreed: 1. The RTJ will have a mechanism to select one of a set of proposal choices offered by the GO in the PT. these would be a set of equivalent algorithms from the local security policy's point of view. next step would be to flesh out the details of the proposal parameters choices for the 3 SA types. 2. The Re-key Event message's Key Download payload needs to refer to a standard key wrap algorithm, at the moment RFC3217 is nominated, though it is informational not PS. This is sorta still an open issue. 3. The Diffie-Hellman secret computed during registration SA set up will go through a key derivation to form the encryption key and an authentication key used on the Key Download message. 4. the registration SA will have a lifetime. no doubt spec'd by the PT? optionally time based? note that the registration SA would be useful to leave around for a leave group request from the GM... 5. if using pre-shared keys for the registration SA or rekey SA's key encryption key applied to the key download, then it would be a good thing to borrow IKE-v2 verbage (see section 2.15) about picking shared keys with enough entropy (especially if passwords are being used as the function's input). 6. There needs to be verbage, akin to what is said in IKE-v2 section 3.3.4, about the GSAKMP management interface should be highly configurable to specify DH parameters, key lengths, algorithms, etc. did I leave anything out? br, George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Sep 23 12:13:50 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22163 for ; Tue, 23 Sep 2003 12:13:50 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3E61253746; Tue, 23 Sep 2003 12:13:18 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3977F53533 for ; Tue, 23 Sep 2003 12:10:57 -0400 (EDT) Received: (qmail 98626 invoked by uid 3269); 23 Sep 2003 16:10:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98615 invoked from network); 23 Sep 2003 16:10:56 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 23 Sep 2003 16:10:56 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8NGAED09320; Tue, 23 Sep 2003 12:10:14 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZWAMG7G; Tue, 23 Sep 2003 12:10:13 -0400 Received: from americasm06.nt.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZWA2C6A; Tue, 23 Sep 2003 12:10:13 -0400 Message-ID: <3F707065.7030104@americasm06.nt.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross , Hugh Harney Cc: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 23 Sep 2003 12:10:13 -0400 Content-Transfer-Encoding: 7bit Does GSAKMP support PSKs (topic of item 5 below)? Lakshminath George Gross wrote: >Hi Hugh, > > okay, to re-cap what we've discussed/agreed: > >1. The RTJ will have a mechanism to select one of a set of proposal >choices offered by the GO in the PT. these would be a set of equivalent >algorithms from the local security policy's point of view. next step would >be to flesh out the details of the proposal parameters choices for the 3 >SA types. > >2. The Re-key Event message's Key Download payload needs to refer to a >standard key wrap algorithm, at the moment RFC3217 is nominated, though it >is informational not PS. This is sorta still an open issue. > >3. The Diffie-Hellman secret computed during registration SA set up will >go through a key derivation to form the encryption key and an >authentication key used on the Key Download message. > >4. the registration SA will have a lifetime. no doubt spec'd by the PT? >optionally time based? note that the registration SA would be useful to >leave around for a leave group request from the GM... > >5. if using pre-shared keys for the registration SA or rekey SA's key >encryption key applied to the key download, then it would be a good thing >to borrow IKE-v2 verbage (see section 2.15) about picking shared keys with >enough entropy (especially if passwords are being used as the function's >input). > >6. There needs to be verbage, akin to what is said in IKE-v2 section >3.3.4, about the GSAKMP management interface should be highly configurable >to specify DH parameters, key lengths, algorithms, etc. > >did I leave anything out? > >br, > George > > >_______________________________________________ >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 Sep 24 09:08:53 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12230 for ; Wed, 24 Sep 2003 09:08:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CFFA553811; Wed, 24 Sep 2003 09:08:08 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 22A8853696 for ; Wed, 24 Sep 2003 09:07:32 -0400 (EDT) Received: (qmail 53692 invoked by uid 3269); 24 Sep 2003 13:07:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53689 invoked from network); 24 Sep 2003 13:07:31 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 24 Sep 2003 13:07:31 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8OD7OZ6031618; Wed, 24 Sep 2003 08:07:24 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8OD7NC0023567; Wed, 24 Sep 2003 08:07:24 -0500 Received: from sparta.com (ssh.columbia.sparta.com [157.185.80.253]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id JAA22221; Wed, 24 Sep 2003 09:07:21 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: George Gross , msec@securemulticast.org To: "Lakshminath Dondeti" From: Hugh Harney In-Reply-To: <3F707065.7030104@americasm06.nt.com> Message-Id: <0C04DF42-EE90-11D7-9846-000A956E63C6@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 24 Sep 2003 09:07:27 -0400 Content-Transfer-Encoding: 7bit Lakshminath, While it hurts to stretch my mind to envision GSAKMP in a pre-placed key mode, I can see the protocol being used to send the PT around along with the rekey messages. Hugh On Tuesday, Sep 23, 2003, at 12:10 US/Eastern, Lakshminath Dondeti wrote: > Does GSAKMP support PSKs (topic of item 5 below)? > > Lakshminath > > George Gross wrote: > >> Hi Hugh, >> >> okay, to re-cap what we've discussed/agreed: >> >> 1. The RTJ will have a mechanism to select one of a set of proposal >> choices offered by the GO in the PT. these would be a set of >> equivalent >> algorithms from the local security policy's point of view. next step >> would >> be to flesh out the details of the proposal parameters choices for >> the 3 >> SA types. >> >> 2. The Re-key Event message's Key Download payload needs to refer to a >> standard key wrap algorithm, at the moment RFC3217 is nominated, >> though it >> is informational not PS. This is sorta still an open issue. >> >> 3. The Diffie-Hellman secret computed during registration SA set up >> will >> go through a key derivation to form the encryption key and an >> authentication key used on the Key Download message. >> >> 4. the registration SA will have a lifetime. no doubt spec'd by the >> PT? >> optionally time based? note that the registration SA would be useful >> to >> leave around for a leave group request from the GM... >> >> 5. if using pre-shared keys for the registration SA or rekey SA's key >> encryption key applied to the key download, then it would be a good >> thing >> to borrow IKE-v2 verbage (see section 2.15) about picking shared keys >> with >> enough entropy (especially if passwords are being used as the >> function's >> input). >> >> 6. There needs to be verbage, akin to what is said in IKE-v2 section >> 3.3.4, about the GSAKMP management interface should be highly >> configurable >> to specify DH parameters, key lengths, algorithms, etc. >> >> did I leave anything out? >> >> br, >> George >> >> >> _______________________________________________ >> 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 > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 24 09:26:38 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13283 for ; Wed, 24 Sep 2003 09:26:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9058E53811; Wed, 24 Sep 2003 09:26:10 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2E71753574 for ; Wed, 24 Sep 2003 09:25:55 -0400 (EDT) Received: (qmail 57892 invoked by uid 3269); 24 Sep 2003 13:25:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57889 invoked from network); 24 Sep 2003 13:25:55 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 24 Sep 2003 13:25:55 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8ODPsZ6031953; Wed, 24 Sep 2003 08:25:54 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8ODPsC0024171; Wed, 24 Sep 2003 08:25:54 -0500 Received: from sparta.com (ssh.columbia.sparta.com [157.185.80.253]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id JAA22506; Wed, 24 Sep 2003 09:25:52 -0400 (EDT) Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: George Gross From: Hugh Harney In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 24 Sep 2003 09:25:58 -0400 Content-Transfer-Encoding: 7bit George, Here is a quick response. I'm stuck in all day meetings today and tomorrow. On Tuesday, Sep 23, 2003, at 06:09 US/Eastern, George Gross wrote: > Hi Hugh, > > okay, to re-cap what we've discussed/agreed: > > 1. The RTJ will have a mechanism to select one of a set of proposal > choices offered by the GO in the PT. these would be a set of equivalent > algorithms from the local security policy's point of view. next step > would > be to flesh out the details of the proposal parameters choices for the > 3 > SA types. OK, I can see a mechanism field. I'm not sure there is a set of proposal parameters for the 3 SAs. Once the PT is delivered the specifications of the SAs are set. I'm very concerned about making the total group SA balanced. > > 2. The Re-key Event message's Key Download payload needs to refer to a > standard key wrap algorithm, at the moment RFC3217 is nominated, > though it > is informational not PS. This is sorta still an open issue. I agree > > 3. The Diffie-Hellman secret computed during registration SA set up > will > go through a key derivation to form the encryption key and an > authentication key used on the Key Download message. I agree > > 4. the registration SA will have a lifetime. no doubt spec'd by the PT? > optionally time based? note that the registration SA would be useful to > leave around for a leave group request from the GM... I'm not sure of this. The registration SA is primarily a key download SA. We also have to discuss the "flavors" of group leaves. Management messages may not go to the key management system. Events generated by management messages we may have to respond to -- loss of trust in a group member is one. > > 5. if using pre-shared keys for the registration SA or rekey SA's key > encryption key applied to the key download, then it would be a good > thing > to borrow IKE-v2 verbage (see section 2.15) about picking shared keys > with > enough entropy (especially if passwords are being used as the > function's > input). I can see using GSAKMP to support the passing of PTs, and rekey messages. If we use pre-placed KEKs to protect key downloads then I can see borrowing IKEv2 prose. I'm struggling with implementing a ton of optional modes in the spec, because I believe we then have to implement them all. I'd rather keep it as simple as possible. > > 6. There needs to be verbage, akin to what is said in IKE-v2 section > 3.3.4, about the GSAKMP management interface should be highly > configurable > to specify DH parameters, key lengths, algorithms, etc. Is this really the GO management interface that specifies the content in a PT? > > did I leave anything out? I hope not!! I'm going to be out of pocket for a couple of days, so e-mail will be sparse at best. cheers Hugh > > br, > George > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Sep 24 14:32:51 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00278 for ; Wed, 24 Sep 2003 14:32:49 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D55C95358E; Wed, 24 Sep 2003 14:32:23 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8BDEA5358E for ; Wed, 24 Sep 2003 14:31:55 -0400 (EDT) Received: (qmail 25763 invoked by uid 3269); 24 Sep 2003 18:31:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25760 invoked from network); 24 Sep 2003 18:31:55 -0000 Received: from h65s138a81n47.user.nortelnetworks.com (HELO zsc3s004.nortelnetworks.com) (47.81.138.65) by klesh.pair.com with SMTP; 24 Sep 2003 18:31:55 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8OIV8n11250; Wed, 24 Sep 2003 11:31:08 -0700 (PDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S5BD14XV; Wed, 24 Sep 2003 11:31:08 -0700 Received: from americasm06.nt.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TRQTA6YD; Wed, 24 Sep 2003 14:31:06 -0400 Message-ID: <3F71E2EA.1060409@americasm06.nt.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lakshminath Dondeti" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hugh Harney Cc: George Gross , msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length References: <0C04DF42-EE90-11D7-9846-000A956E63C6@sparta.com> In-Reply-To: <0C04DF42-EE90-11D7-9846-000A956E63C6@sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 24 Sep 2003 14:31:06 -0400 Content-Transfer-Encoding: 7bit My reference to PSKs is in the context of host authentication; I don't mean that we download the registration SA a priori via other means. Lakshminath Hugh Harney wrote: > Lakshminath, > > While it hurts to stretch my mind to envision GSAKMP in a pre-placed > key mode, I can see the protocol being used to send the PT around > along with the rekey messages. > > Hugh > > > On Tuesday, Sep 23, 2003, at 12:10 US/Eastern, Lakshminath Dondeti wrote: > >> Does GSAKMP support PSKs (topic of item 5 below)? >> >> Lakshminath >> >> George Gross wrote: >> >>> Hi Hugh, >>> >>> okay, to re-cap what we've discussed/agreed: >>> >>> 1. The RTJ will have a mechanism to select one of a set of proposal >>> choices offered by the GO in the PT. these would be a set of equivalent >>> algorithms from the local security policy's point of view. next step >>> would >>> be to flesh out the details of the proposal parameters choices for >>> the 3 >>> SA types. >>> >>> 2. The Re-key Event message's Key Download payload needs to refer to a >>> standard key wrap algorithm, at the moment RFC3217 is nominated, >>> though it >>> is informational not PS. This is sorta still an open issue. >>> >>> 3. The Diffie-Hellman secret computed during registration SA set up >>> will >>> go through a key derivation to form the encryption key and an >>> authentication key used on the Key Download message. >>> >>> 4. the registration SA will have a lifetime. no doubt spec'd by the PT? >>> optionally time based? note that the registration SA would be useful to >>> leave around for a leave group request from the GM... >>> >>> 5. if using pre-shared keys for the registration SA or rekey SA's key >>> encryption key applied to the key download, then it would be a good >>> thing >>> to borrow IKE-v2 verbage (see section 2.15) about picking shared >>> keys with >>> enough entropy (especially if passwords are being used as the >>> function's >>> input). >>> >>> 6. There needs to be verbage, akin to what is said in IKE-v2 section >>> 3.3.4, about the GSAKMP management interface should be highly >>> configurable >>> to specify DH parameters, key lengths, algorithms, etc. >>> >>> did I leave anything out? >>> >>> br, >>> George >>> >>> >>> _______________________________________________ >>> 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 >> >> > Hugh Harney Sparta, Inc. > hh@sparta.com 7075 Samuel Morse Drive > (410) 872-1515 x203 Columbia, MD, 21046 > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Sep 25 15:26:43 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17177 for ; Thu, 25 Sep 2003 15:26:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 085B35381E; Thu, 25 Sep 2003 15:26:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3375C536A3 for ; Thu, 25 Sep 2003 15:24:48 -0400 (EDT) Received: (qmail 13243 invoked by uid 3269); 25 Sep 2003 19:24:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 13240 invoked from network); 25 Sep 2003 19:24:48 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 25 Sep 2003 19:24:48 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8PJOlZ6021718 for ; Thu, 25 Sep 2003 14:24:47 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8PJOlRQ016101 for ; Thu, 25 Sep 2003 14:24:47 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA16472 for ; Thu, 25 Sep 2003 15:24:43 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h8PJOMk14632 for msec@securemulticast.org; Thu, 25 Sep 2003 15:24:22 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 09: Rekey "Sequence ID" rollover semantics Message-ID: <20030925152421.A14621@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gmgross@nac.net on Fri, Aug 08, 2003 at 03:32:31PM -0400 Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 25 Sep 2003 15:24:22 -0400 We agree that we need to mitigate this problem. We will investigate appropriate methods and disperse solution(s) to authors group for concensus. Stay tuned. UM On Fri, Aug 08, 2003 at 03:32:31PM -0400, George Gross wrote: > > GSAKMP issue 09 > > Section and relevant text passage: > > 6.1 GSAKMP Header, Sequence ID text: > > "GCKS/SGCKS MUST also garantee that this value does not > suffer from rollover problems..." > > Comment/issue description: > > s/garantee/guarantee/ > > Granted, this is a corner case, but the text does seem vague here. If the GCKS had > the misfortune to generate an initial random Sequence ID that was close to 2^32 > AND then the group was long-lived AND it had lots of rekey events, then one > might have to deal with this. So what do you do? > > Suggested issue resolution: > > The text should specify that rollover is allowed, and indicate an algorithm > in an appendix that would gracefully accept wrap around. > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Sep 25 15:29:01 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17411 for ; Thu, 25 Sep 2003 15:29:00 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D415C538CB; Thu, 25 Sep 2003 15:28:32 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0B77D53788 for ; Thu, 25 Sep 2003 15:27:37 -0400 (EDT) Received: (qmail 13675 invoked by uid 3269); 25 Sep 2003 19:27:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 13672 invoked from network); 25 Sep 2003 19:27:36 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 25 Sep 2003 19:27:36 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8PJRaZ6021772 for ; Thu, 25 Sep 2003 14:27:36 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8PJRaRQ016206 for ; Thu, 25 Sep 2003 14:27:36 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA16562 for ; Thu, 25 Sep 2003 15:27:29 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h8PJR7b14648 for msec@securemulticast.org; Thu, 25 Sep 2003 15:27:07 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 10: GSAKMP payload header should align with IKE-v2 Message-ID: <20030925152705.B14621@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gmgross@nac.net on Fri, Aug 08, 2003 at 03:33:42PM -0400 Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 25 Sep 2003 15:27:07 -0400 With this post I am only answering part of your questoin wrt Network Byte ordering. Please stay tuned for a later post wrt to the other issues in your post. All fields in all payloads that are more than one byte long that are integer values must be sent in Network Byte Order. UM On Fri, Aug 08, 2003 at 03:33:42PM -0400, George Gross wrote: > > GSAKMP issue 10 > > Section and relevant text passage: > > 6.2 Generic Payload Header > > Comment/issue description: > > The payload header should be aligned with the IKE-v2 payload header syntax and > critical bit semantics. > > The text should indicate it follows the IKE-v2 policy with respect to padding. > I would assume that GSAKMP currently does not attempt to do modulo-4 payload header > alignment? (Neither does IKE-v2, but then other protocols do e.g. Diameter) > > The text does not say so, but I would have to guess the Payload length is in > network byte order. > > Suggested issue resolution: > > The text should explicitly define the syntax and semantics wrt/ the above to match IKE-v2. > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Sep 25 15:34:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17652 for ; Thu, 25 Sep 2003 15:34:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 65EA2538F5; Thu, 25 Sep 2003 15:34:05 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6A189538DF for ; Thu, 25 Sep 2003 15:33:50 -0400 (EDT) Received: (qmail 14798 invoked by uid 3269); 25 Sep 2003 19:33:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 14793 invoked from network); 25 Sep 2003 19:33:50 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 25 Sep 2003 19:33:50 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h8PJXnZ6021951 for ; Thu, 25 Sep 2003 14:33:49 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h8PJXnRQ016420 for ; Thu, 25 Sep 2003 14:33:50 -0500 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA16641 for ; Thu, 25 Sep 2003 15:33:47 -0400 (EDT) Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id h8PJXR114676 for msec@securemulticast.org; Thu, 25 Sep 2003 15:33:27 -0400 From: Uri Meth To: msec@securemulticast.org Subject: Re: [MSEC] GSAKMP issue 05: Key Download processing needs clarification Message-ID: <20030925153327.A14657@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gmgross@nac.net on Fri, Aug 08, 2003 at 03:27:55PM -0400 Organization: SPARTA Inc. (Information Systems Security Operation) USMail: 7075 Samuel Morse Drive, Columbia MD 21046 Phone: (410) 872-1515 x233 Fax: (410) 872-8079 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 25 Sep 2003 15:33:27 -0400 See inline, Also a general note wrt section 4 of the spec. This section will undergo a major rewrite to make it more verbose to address a lot of the issues that George has brought up. As these sections become available, they will be distributed to the authors group for concensus review. On Fri, Aug 08, 2003 at 03:27:55PM -0400, George Gross wrote: > > GSAKMP issue 05 > > Section and relevant text passage: > > section 4.2.1.2 Key Download > > also, the text that says: "GSAKMP sends a properly authenticated message with a > Notification Payload of type NACK to indicate termination." > > is ambiguous, as it is not clear whether "GSAKMP" in this context refers to the > GCKS or the GM. GM > > Comment/issue description: > > The Key Download verification processing is under specified. > Yes it is underspecified, and will be fixed. > Suggested issue resolution: > > Similar to what was indicated for the comment wrt/ Request To Join processing, > the set of error response should be listed in a table. The nonce related > verification should be described. The number of Key Download retries and timeouts > should be specified. > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Uri Meth (410) 872 - 1515 x233 (voice) SPARTA, Inc. (410) 872 - 8079 (fax) 7075 Samuel Morse Drive umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec