From sheela@cisco.com Fri May 7 17:22:02 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B663A67BD for ; Fri, 7 May 2010 17:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVcgHvUOlWOr for ; Fri, 7 May 2010 17:21:56 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 45CDB3A677E for ; Fri, 7 May 2010 17:21:56 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FAA5L5EurR7Hu/2dsb2JhbACBPpxdcaUfmTeFFQSDQg X-IronPort-AV: E=Sophos;i="4.52,351,1270425600"; d="scan'208,217";a="194390629" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 08 May 2010 00:21:44 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o480Lisn029809; Sat, 8 May 2010 00:21:44 GMT Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 May 2010 17:21:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAEE44.6FE1D261" Date: Fri, 7 May 2010 17:21:43 -0700 Message-ID: <6B9C4B97B82F924485E26968EB05A6EE09765215@xmb-sjc-224.amer.cisco.com> In-Reply-To: <0D25F037-3741-4C0F-902B-7D829393C633@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] GDOI Update draft Thread-Index: AcrXD51FGrPU4+WUSVup1dU1lXQUzAXMExeQ References: <0D25F037-3741-4C0F-902B-7D829393C633@checkpoint.com> From: "Sheela Rowles (sheela)" To: "Yoav Nir" , X-OriginalArrivalTime: 08 May 2010 00:21:43.0978 (UTC) FILETIME=[701F80A0:01CAEE44] Subject: Re: [MSEC] GDOI Update draft X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 00:22:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAEE44.6FE1D261 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Really sorry for the late response.=20 =20 See inline SR:=20 =20 =20 From: msec-bounces@ietf.org [mailto:msec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Thursday, April 08, 2010 4:35 AM To: msec@ietf.org Subject: [MSEC] GDOI Update draft =20 Hi. =20 As I promised at the meeting, I will review this draft thoroughly, but I already have two comments =20 1. It was said in the meeting (although it's not written in the draft) that none of the known implementations have implemented the PFS extension, and so it is dropped. This is incorrect. I have checked Check Point's implementation, and it does, in fact, implement the PFS feature. What the draft says, in appendix B, is that it provides negligible value, and that the specification is faulty. These statements are true. Much as I'd hate to deprecate running code from my own company, I agree with the reasoning in appendix B, so I'm fine with it being deprecated. 2. The document is missing a conformance requirements section. Although there is some conformance language in the various sections, like DES is SHOULD NOT, and AES-CBC-128 is MUST, the document is missing a centralized list of what is required, as opposed to optional, or not recommended. I would suggest the following: SR:=20 =20 =20 I like the idea of doing a conformance requirements section especially if it helps to clarify the SHOULDs and MUSTs. Is there an example RFC or draft where this is done that I can take a look at? =20 =20 KEK_MANAGEMENT_ALGORITHM * LKH - MUST (?) SR: "Implementation of the LKH algorithm is OPTIONAL." =20 KEK_ALGORITHM * DES - SHOULD NOT * 3DES - SHOULD * AES - MUST =20 SIG_HASH_ALGORITHM * MD5 - MUST NOT * SHA1 - SHOULD NOT * SHA256 - MUST (BTW: why do you have to specify this at all? With RSA, you're using the PKCS#1.5 format that encodes the hash algorithm anyways, so why negotiate it?) =20 SR: By having the information in the SA payload during registration, the GM has the opportunity to determine whether it can support the requested algorithm and react appropriately if it doesn't support it. Otherwise, the GM will only recognize it can't support the requested algorithm upon receiving the first rekey.=20 =20 SIG_ALGORITHM * RSA - MUST =20 protocol * ESP - MUST * AH - MAY =20 Key download type * are all three types mandatory? SR: No. The draft does not mandate that all three types are present. LKH is optional.=20 Section 5.2.1:=20 There may be zero or one SAK Payloads, zero or more GAP Payloads, and zero or more SAT Payloads, where either one SAK or SAT payload MUST be present. =20 =20 And so on. =20 Anyway, I do promise to read this throughly soon. =20 Yoav =20 =20 =20 SR: Looking forward to your full review.=20 =20 Thanks,=20 Sheela ------_=_NextPart_001_01CAEE44.6FE1D261 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Really sorry for the late response. =

 

See inline SR:

 

 

From:= msec-bounces@ietf.org [mailto:msec-bounces@ietf.org] On Behalf Of = Yoav Nir
Sent: Thursday, April 08, 2010 4:35 AM
To: msec@ietf.org
Subject: [MSEC] GDOI Update draft

 

Hi.

 

As I promised at the meeting, I will review this = draft thoroughly, but I already have two comments

 

  1. It was said in the meeting (although it's = not written in the draft) that none of the known implementations have implemented the PFS extension, and so it is dropped. This is = incorrect. I have checked Check Point's implementation, and it does, in fact, = implement the PFS feature. What the draft says, in appendix B, is that it = provides negligible value, and that the specification is faulty. These = statements are true.  
    Much as I'd hate to deprecate running code from my own company, I = agree with the reasoning in appendix B, so I'm fine with it being = deprecated.
  2. The document is missing a conformance requirements section. Although there is some conformance language = in the various sections, like DES is SHOULD NOT, and AES-CBC-128 is MUST, = the document is missing a centralized list of what is required, as = opposed to optional, or not recommended.  I would suggest the = following:

SR: =

 

 

I like the idea of doing a conformance requirements = section especially if it helps to clarify the SHOULDs and MUSTs.   Is = there an example RFC or draft where this is done that I can take a look = at?

 

 

KEK_MANAGEMENT_ALGORITHM

  • LKH - MUST  (?)

SR: = “Implementation of the LKH algorithm is = OPTIONAL.”

 

KEK_ALGORITHM

  • DES - SHOULD NOT
  • 3DES - SHOULD
  • AES - MUST

 

SIG_HASH_ALGORITHM

  • MD5 - MUST NOT
  • SHA1 - SHOULD NOT
  • SHA256 - MUST

(BTW: why do you have to specify this at all? =  With RSA, you're using the PKCS#1.5 format that encodes the hash algorithm = anyways, so why negotiate it?)

 

SR: By having the = information in the SA payload during registration, the GM has the opportunity to = determine whether it can support the requested algorithm and react appropriately = if it doesn’t support it.   Otherwise, the GM will only = recognize it can’t support the requested algorithm upon receiving the first = rekey.

 

SIG_ALGORITHM

  • RSA - MUST

 

protocol

  • ESP - MUST
  • AH - MAY

 

Key download type

  • are all three types = mandatory?

SR: No.  The = draft does not mandate that all three types are present.  LKH is optional. = 

Section 5.2.1: =

   There may be zero or one SAK Payloads, zero or more GAP =
Payloads, and zero or

   more SAT Payloads, where either one = SAK or SAT payload MUST be

   present.

 

 

And so on.

 

Anyway, I do promise to read this throughly = soon.

 

Yoav

 

 

 

SR: Looking forward = to your full review.

 

Thanks,

Sheela

------_=_NextPart_001_01CAEE44.6FE1D261-- From ynir@checkpoint.com Sat May 8 23:27:02 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F73E3A67B7 for ; Sat, 8 May 2010 23:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.574 X-Spam-Level: X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shERxbhbFsrB for ; Sat, 8 May 2010 23:27:00 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 07E323A67A5 for ; Sat, 8 May 2010 23:26:58 -0700 (PDT) X-CheckPoint: {4BE662D1-0-1B201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o496Qipp003500; Sun, 9 May 2010 09:26:44 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 9 May 2010 09:27:14 +0300 From: Yoav Nir To: "Sheela Rowles (sheela)" Date: Sun, 9 May 2010 09:26:46 +0300 Thread-Topic: [MSEC] GDOI Update draft Thread-Index: AcrvQKni4/FDTQqqTUuIKfX/g8qN5A== Message-ID: <123E6503-8035-4DAD-9019-E0A40EABD1FE@checkpoint.com> References: <0D25F037-3741-4C0F-902B-7D829393C633@checkpoint.com> <6B9C4B97B82F924485E26968EB05A6EE09765215@xmb-sjc-224.amer.cisco.com> In-Reply-To: <6B9C4B97B82F924485E26968EB05A6EE09765215@xmb-sjc-224.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_123E650380354DAD9019E0A40EABD1FEcheckpointcom_" MIME-Version: 1.0 Cc: "msec@ietf.org" Subject: Re: [MSEC] GDOI Update draft X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 06:27:02 -0000 --_000_123E650380354DAD9019E0A40EABD1FEcheckpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On May 8, 2010, at 3:21 AM, Sheela Rowles (sheela) wrote: Really sorry for the late response. See inline SR: From: msec-bounces@ietf.org [mailto:msec-boun= ces@ietf.org] On Behalf Of Yoav Nir Sent: Thursday, April 08, 2010 4:35 AM To: msec@ietf.org Subject: [MSEC] GDOI Update draft Hi. As I promised at the meeting, I will review this draft thoroughly, but I al= ready have two comments 1. It was said in the meeting (although it's not written in the draft) th= at none of the known implementations have implemented the PFS extension, an= d so it is dropped. This is incorrect. I have checked Check Point's impleme= ntation, and it does, in fact, implement the PFS feature. What the draft sa= ys, in appendix B, is that it provides negligible value, and that the speci= fication is faulty. These statements are true. Much as I'd hate to deprecate running code from my own company, I agree wit= h the reasoning in appendix B, so I'm fine with it being deprecated. 2. The document is missing a conformance requirements section. Although t= here is some conformance language in the various sections, like DES is SHOU= LD NOT, and AES-CBC-128 is MUST, the document is missing a centralized list= of what is required, as opposed to optional, or not recommended. I would = suggest the following: SR: I like the idea of doing a conformance requirements section especially if i= t helps to clarify the SHOULDs and MUSTs. Is there an example RFC or draf= t where this is done that I can take a look at? [YN] There's section 9 in RFC 5246 (TLS 1.2), but that is rather sparse. And the= re's RFC 4307 for IKE/IPsec. KEK_MANAGEMENT_ALGORITHM * LKH - MUST (?) SR: =93Implementation of the LKH algorithm is OPTIONAL.=94 KEK_ALGORITHM * DES - SHOULD NOT * 3DES - SHOULD * AES - MUST SIG_HASH_ALGORITHM * MD5 - MUST NOT * SHA1 - SHOULD NOT * SHA256 - MUST (BTW: why do you have to specify this at all? With RSA, you're using the P= KCS#1.5 format that encodes the hash algorithm anyways, so why negotiate it= ?) SR: By having the information in the SA payload during registration, the GM= has the opportunity to determine whether it can support the requested algo= rithm and react appropriately if it doesn=92t support it. Otherwise, the = GM will only recognize it can=92t support the requested algorithm upon rece= iving the first rekey. SIG_ALGORITHM * RSA - MUST protocol * ESP - MUST * AH - MAY Key download type * are all three types mandatory? SR: No. The draft does not mandate that all three types are present. LKH = is optional. Section 5.2.1: There may be zero or one SAK Payloads, zero or more GAP Payloads, and ze= ro or more SAT Payloads, where either one SAK or SAT payload MUST be present. And so on. Anyway, I do promise to read this throughly soon. Yoav SR: Looking forward to your full review. Thanks, Sheela --_000_123E650380354DAD9019E0A40EABD1FEcheckpointcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
On May 8, 2010, at 3:21 AM, Sheela Rowles (sheela) wrote:
=
Really sorry for the late response.
 
See = inline SR:
 
 
From:<= /b> msec-bounce= s@ietf.org [mailto:ms= ec-bounces@ietf.org] O= n Behalf Of Yoav Nir<= br>Sent: Thursday,= April 08, 2010 4:35 AM
To:=  msec@ietf.org
Subject: [MSEC] GDOI Update draft
 
Hi.
 
As I promised at the meeting, I will review = this draft thoroughly, but I already have two comments
 
  1. It was said in the meeting (altho= ugh it's not written in the draft) that none of the known implementations h= ave implemented the PFS extension, and so it is dropped. This is incorrect.= I have checked Check Point's implementation, and it does, in fact, impleme= nt the PFS feature. What the draft says, in appendix B, is that it provides= negligible value, and that the specification is faulty. These statements a= re true.  
    Much as I'd hate to deprecate running code from my own c= ompany, I agree with the reasoning in appendix B, so I'm fine with it being= deprecated.
  2. The document is missing a c= onformance requirements section. Although there is some conformance languag= e in the various sections, like DES is SHOULD NOT, and AES-CBC-128 is MUST,= the document is missing a centralized list of what is required, as opposed= to optional, or not recommended.  I would suggest the following:=
SR:
 
 
I like the idea o= f doing a conformance requirements section especially if it helps to clarif= y the SHOULDs and MUSTs.   Is there an example RFC or draft where= this is done that I can take a look at?

[YN]
There's section 9 = in RFC 5246 (TLS 1.2), but that is rather sparse. And there's RFC 4307 for = IKE/IPsec.

 
 
KEK_MANAGEME= NT_ALGORITHM
  • LKH - MUST  (?)
=
SR: =93Implementation of the LKH algorith= m is OPTIONAL.=94

 
KEK_ALGORITHM
  • DES - SHOULD NOT
  • 3DES - SHOULD
  • AES= - MUST
 
SIG_HA= SH_ALGORITHM
  • MD5 - MUST NOT
  • SHA1 - SHOULD NOT
  • SHA256 - = MUST
(BTW: why do you have to specify this at all= ?  With RSA, you're using the PKCS#1.5 format that encodes the hash al= gorithm anyways, so why negotiate it?)
 
SR: By having the information in the SA pa= yload during registration, the GM has the opportunity to determine whether = it can support the requested algorithm and react appropriately if it doesn= =92t support it.   Otherwise, the GM will only recognize it can= =92t support the requested algorithm upon receiving the first rekey.
 
  • RSA - MUST
    • <= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m= argin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">=  
    protocol
    • ESP - MUS= T
    • AH - MAY
     
    Key download type
    • are = all three types mandatory?
    SR: No.  The draft does not mandate that all three= types are present.  LKH is optional.
    Section 5.2.1: 
       There may be zero or one SAK Payloads, zero or more GAP Payloa=
ds, and zero or
       more SAT Payloa= ds, where either one SAK or SAT payload MUST be
       present.
     = ;
     
    =
    And so on.
     
    <= div>
    Anyway, I do promise to read this throughly soon.
     
    Yoav
    =
     
     
     
    SR: Looking forward to your full review.
    <= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m= argin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">=  
    Thanks,
    Sheela

    = --_000_123E650380354DAD9019E0A40EABD1FEcheckpointcom_--