From turners@ieca.com Sat Apr 2 10:08:21 2011 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 1349728C103 for ; Sat, 2 Apr 2011 10:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] 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 mOwwd1A4Wvbn for ; Sat, 2 Apr 2011 10:08:19 -0700 (PDT) Received: from nm6-vm0.bullet.mail.sp2.yahoo.com (nm6-vm0.bullet.mail.sp2.yahoo.com [98.139.91.206]) by core3.amsl.com (Postfix) with SMTP id A46373A686C for ; Sat, 2 Apr 2011 10:08:19 -0700 (PDT) Received: from [98.139.91.64] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 02 Apr 2011 17:10:01 -0000 Received: from [98.139.91.3] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 02 Apr 2011 17:10:01 -0000 Received: from [127.0.0.1] by omp1003.mail.sp2.yahoo.com with NNFMP; 02 Apr 2011 17:10:01 -0000 X-Yahoo-Newman-Id: 104382.68146.bm@omp1003.mail.sp2.yahoo.com Received: (qmail 67453 invoked from network); 2 Apr 2011 17:10:00 -0000 Received: from thunderfish.local (turners@198.180.150.234 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 02 Apr 2011 10:09:59 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 2TV4kfEVM1lw_AQlqRtpNRn.xPSdyCc2UyKOHruJYtvwCBy ALSr6iHKEX.du1M5az01i5YDDXjcGogWvX7xvf607NJBMVnBJnLJwSWBrTUZ x7c370151x6AgrnnodKx5iWMlAuCU2F6Zj4fO50dpvweC_Ka9No.Ud.pMxi3 62NM4cVWTV0oA6ygWpY69kZli7u9qQ3F7Y5wRGpG7TgypM93IyMHGXM1Vtnw tELFa_OPEl_xnDbHEKh_Y7AQDefPvU3mb8yOc9rWpAbnYU4sC8leh1gIACsL GZg6_sYPhF.jvVFiy8nZW3eQCmuOvGQ4x8CqvLViG0Dkq2mIIQ1gxDmW_Yxy UZrhORJgaQVHDMI3jBIcoArEqdmH7hkmUxTN1YxP7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D975866.9070102@ieca.com> Date: Sat, 02 Apr 2011 19:09:58 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: msec@ietf.org References: <4D94540D.1060605@inrialpes.fr> In-Reply-To: <4D94540D.1060605@inrialpes.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MSEC] WGLC on draft-ietf-msec-gdoi-update-08 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, 02 Apr 2011 17:08:21 -0000 #1) Add "updates: 3547 (once approved)" to the header. This will make it match the intro/abstract. I can almost guarantee a discuss from somebody on this. #2) ISAKMP Phase 1 is described in Section 2.1 as "one such mechanism". This isn't a MUST support. As far as I can tell there isn't a MUST implement Phase 1 protocol (the protocols in Appendix A are also just examples). But, to implement this document you've got to do things as described in RFC 2407-2409. It seems like this doc and IKEv1 are pretty well intertwined. And, the g-ikev2 draft doesn't use these formats it uses something else...Let's be clear about what it's being used with. It seems like this section ought to be changed as follows: OLD: The following sections describe one such "phase 1" protocol. Other protocols which may be potential "phase 1" protocols are described in Appendix A. However, the use of the protocols listed there are not considered part of this document. 2.1. ISAKMP Phase 1 protocol This document defines how the ISAKMP phase 1 exchanges as defined in [RFC2409] can be used a "phase 1" protocol for GDOI. The following sections define characteristics of the ISAKMP phase 1 protocols that are unique for these exchanges when used for GDOI. Section 7.1 describes how the ISAKMP Phase 1 protocols meet the requirements of a GDOI "phase 1" protocol. NEW: This document defines how the ISAKMP phase 1 exchanges as defined in [RFC2409] can be used a "phase 1" protocol for GDOI. The following sections define characteristics of the ISAKMP phase 1 protocols that are unique for these exchanges when used for GDOI. Section 7.1 describes how the ISAKMP Phase 1 protocols meet the requirements of a GDOI "phase 1" protocol. Delete the 2.1 header and renumber 2.1.1 and 2.1.2 to 2.1 and 2.2, respectively. I would also delete Appendix A. The currently proposed IKEv2 mechanism isn't reusing these fields and the KINK option never got defined. #3) Sec 3.2: r/Hashes are computed in the manner described within RFC 2409./Hashes are computed in the manner described within [RFC2409]. #4) Sec 3.2: expand prf on first use. #5) Sec 3.3: 2 lower case "must" should they be "MUST"? 1 lower case "should" should it be "SHOULD"? #6) Sec 4.2: Something is wrong with this: Flags MUST have the Encryption bit set according to [RFC2008, Section 3.1]. Maybe it should be: Flags MUST have the Encryption bit set according to Section 3.1 of [RFC2408]. #7) Sec 5: r/in accordance with RFC 2408./in accordance with [RFC2408]. #8) Sec 5.1, 5.2: r/defined in RFC 2408./defined in [RFC2408]. #9) Sec 5.2: This is difficult to parse: The next payload MUST NOT be a SAK Payload or SAT Payload type, but the next non-Security Association type payload. Maybe it's supposed to be: The next payload MUST NOT be a SAK Payload or SAT Payload type; it MUST be the next non-Security Association type payload. #9) Sec 5.2: r/Must/MUST X4 #10) Sec 5.2.1: r/SA Attributes payloads must be/SA Attributes payloads MUST be #11) Sec 5.3: r/Must/MUST X2 r/should/SHOULD r/must/MUST #12) Sec 5.3: What is the conformance requirement for the following: Any or all attributes may be optional, depending on the group policy. #13) Sec 5.3.1: r/ attributes may be present / attributes MAY be present or change to say they are OPTIONAL. r/attributes must/attributes MUST #14) Sec 5.3.1: The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a GROUPKEY-PULL message. What happens if it's included in the PUSH message? #15) Just noted to instances of GROUPKEY_. Aren't they supposed to be GROUPKEY-*? #16) Sec 5.3.3.3: r/as recommended in/as defined in #17) Sec 5.3.6: Any reason not to point to FIPS 180-3? #18) Sec 5.3.6: r/and SIG_HASH_ALGORITHM is not required to be present in a SAK Payload/and SIG_HASH_ALGORITHM is OPTIONAL in a SAK Payload #19) Sec 5.3.7: Does anybody really want RSA-PSS? #20) Sec 5.4: r/Must/MUST r/Section 3.3 of RFC 2408./Section 3.3 of [RFC2408]. #21) Sec 5.4.1: r/ Section 4.2.1 of RFC 5374/Section 4.2.1 of [RFC5374] r/should/SHOULD X2 ?? #22) Sec 5.5: r/Must/MUST #23) Sec 5.5.1: Protocol, SEC ID Port, DST ID Prot, DST ID Port bullets r/should/SHOULD ? #24) Sec 5.5.1: r/from RFC 2407/from [RFC2407] r/[RFC2407],/[RFC2407]), r/ESP must also/ESP MUST also #25) Sec 1.3: Add GSPD #26) Sec 5.5.1.1.1: r/ RFC 5374/[RFC5374] #27) Sec 5.5.1.1.1: r/must/MUST ? #28) Sec 5.5.1.1.1: In the following, is 2119 language needed: SA TEK payload may be required in one or both directions. #29) Sec 5.5.2: r/All Security Protocols must provide/All Security Protocols MUST provide #30) Sec 5.6.1: r/The attributes must follow/The attributes MUST follow r/At least one TEK must be/At least one TEK MUST be #31) Sec 5.6.1.2: r/to the member./to the GM. #32) Sec 5.6.2 and 5.6.3: r/The attributes must follow/The attributes MUST follow #33) Sec 5.6.3 and 5.6.3.1: r/there must be only/there MUST be only #34) Sec 5.6.3.1 and 5.6.3.2: r/Must/MUST #35) Sec 1.3: add SSIV #36) Sec 5.7: r/Must/MUST r/must/MUST X3 #37) Sec 5.9: r/must be deleted, they must be/are to be deleted, they MUST be #38) Sec 10: References for 2403, 2404, 2407-2409, 3447, 4106, 4543, 4754, 4868, 5903 are normative according to the following: http://www.ietf.org/iesg/statement/normative-informative.html Assuming you delete App A, remove references to 4330 and 5996. Please ensure the classification of the other references are in accordance with the IESG statement. If you've got any questions, let me know. I don't want to find out later that some informative reference to an informative RFC is actually a normative reference and we need to do a 2nd IETF LC to note the DOWNREF. I still need to finish Section 7 and 8. spt On 3/31/11 12:14 PM, Vincent Roca wrote: > Hello everybody, > > As you probably noticed the GDOI draft has been significantly > updated WRT the previous 07 version. For details see: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-msec-gdoi-update-08.txt > > This situation motivates another WGLC. So please review > > draft-ietf-msec-gdoi-update-08 > http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ > > and send comments to the WG mailing list by April 18th. > (NB: if ever this deadline is too close, then tell me...) > > Regards, > > Vincent > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec > From ynir@checkpoint.com Wed Apr 13 14:15:13 2011 Return-Path: X-Original-To: msec@ietfc.amsl.com Delivered-To: msec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0D8D8E081F for ; Wed, 13 Apr 2011 14:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.709 X-Spam-Level: X-Spam-Status: No, score=-7.709 tagged_above=-999 required=5 tests=[AWL=2.890, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBvqL8X3CEA9 for ; Wed, 13 Apr 2011 14:15:12 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfc.amsl.com (Postfix) with ESMTP id 31F52E06EA for ; Wed, 13 Apr 2011 14:15:11 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p3DLFA1Q012920; Thu, 14 Apr 2011 00:15:10 +0300 X-CheckPoint: {4DA62009-6-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 14 Apr 2011 00:15:09 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 13 Apr 2011 23:15:09 +0200 From: Yoav Nir To: Vincent Roca Date: Wed, 13 Apr 2011 23:15:08 +0200 Thread-Topic: [MSEC] WGLC on draft-ietf-msec-gdoi-update-08 Thread-Index: Acv6H95vFgdaO2y6SpCkfGP5uGeX4Q== Message-ID: <0E1D5D72-5EB7-4788-9268-2E885E886742@checkpoint.com> References: <4D94540D.1060605@inrialpes.fr> In-Reply-To: <4D94540D.1060605@inrialpes.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "msec@ietf.org" Subject: Re: [MSEC] WGLC on draft-ietf-msec-gdoi-update-08 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 21:15:13 -0000 It looks ready to me. On Mar 31, 2011, at 12:14 PM, Vincent Roca wrote: > Hello everybody, >=20 > As you probably noticed the GDOI draft has been significantly > updated WRT the previous 07 version. For details see: >=20 > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-msec-gdoi-update-08.txt >=20 > This situation motivates another WGLC. So please review >=20 > draft-ietf-msec-gdoi-update-08 > http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ >=20 > and send comments to the WG mailing list by April 18th. > (NB: if ever this deadline is too close, then tell me...) >=20 > Regards, >=20 > Vincent From bew@cisco.com Mon Apr 18 10:14:08 2011 Return-Path: X-Original-To: msec@ietfc.amsl.com Delivered-To: msec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A76BAE0684 for ; Mon, 18 Apr 2011 10:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srr2TKcyjJMm for ; Mon, 18 Apr 2011 10:14:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 9DBDAE0670 for ; Mon, 18 Apr 2011 10:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=12055; q=dns/txt; s=iport; t=1303146846; x=1304356446; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Vz1NmjtgJw0DP2koVSzyFIDmZDu/EoGDh5glnUAk2AU=; b=NKIZLyR6BMu6OmWQw7f6ZY9bAyf5OQFspJrFutxFwsZSgdgULMM16KAE ROBh35CgTs26Ldpsq3Oe3crLoTfxBCy8rpdh39OqWzIQTAt2Pkwo2S0gE gwrAa4Skv539sWyg8bZ6VvvzgF7J4NiV4HOP0NK36AVICCaMTU6wM8B6W 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEBwrE2rRDoH/2dsb2JhbAClNXeIb557jUWOZYMZglgEhWKIIA X-IronPort-AV: E=Sophos;i="4.64,233,1301875200"; d="scan'208";a="339845192" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 18 Apr 2011 17:14:05 +0000 Received: from dhcp-128-107-151-48.cisco.com (dhcp-128-107-151-48.cisco.com [128.107.151.48]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3IHE2au024461; Mon, 18 Apr 2011 17:14:02 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <4D975866.9070102@ieca.com> Date: Mon, 18 Apr 2011 10:14:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D94540D.1060605@inrialpes.fr> <4D975866.9070102@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1082) Cc: msec@ietf.org Subject: Re: [MSEC] WGLC on draft-ietf-msec-gdoi-update-08 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 17:14:08 -0000 Hi Sean, Thanks for the comprehensive review ... good points, all. I've comments = on a few of them inline below. On Apr 2, 2011, at 10:09 AM, Sean Turner wrote: > #1) Add "updates: 3547 (once approved)" to the header. This will make = it match the intro/abstract. I can almost guarantee a discuss from = somebody on this. >=20 > #2) ISAKMP Phase 1 is described in Section 2.1 as "one such = mechanism". This isn't a MUST support. As far as I can tell there = isn't a MUST implement Phase 1 protocol (the protocols in Appendix A are = also just examples). But, to implement this document you've got to do = things as described in RFC 2407-2409. It seems like this doc and IKEv1 = are pretty well intertwined. And, the g-ikev2 draft doesn't use these = formats it uses something else...Let's be clear about what it's being = used with. It seems like this section ought to be changed as follows: >=20 > OLD: >=20 > The following sections describe one such "phase 1" protocol. Other > protocols which may be potential "phase 1" protocols are described in > Appendix A. However, the use of the protocols listed there are not > considered part of this document. >=20 > 2.1. ISAKMP Phase 1 protocol >=20 > This document defines how the ISAKMP phase 1 exchanges as defined in > [RFC2409] can be used a "phase 1" protocol for GDOI. The following > sections define characteristics of the ISAKMP phase 1 protocols that > are unique for these exchanges when used for GDOI. >=20 > Section 7.1 describes how the ISAKMP Phase 1 protocols meet the > requirements of a GDOI "phase 1" protocol. >=20 > NEW: >=20 > This document defines how the ISAKMP phase 1 exchanges as defined in > [RFC2409] can be used a "phase 1" protocol for GDOI. The following > sections define characteristics of the ISAKMP phase 1 protocols that > are unique for these exchanges when used for GDOI. >=20 > Section 7.1 describes how the ISAKMP Phase 1 protocols meet the > requirements of a GDOI "phase 1" protocol. >=20 >=20 > Delete the 2.1 header and renumber 2.1.1 and 2.1.2 to 2.1 and 2.2, = respectively. >=20 > I would also delete Appendix A. The currently proposed IKEv2 = mechanism isn't reusing these fields and the KINK option never got = defined. Removing this text in Section 2 and Appendix A make a lot of sense. The = concerns that caused them to be added to RFC 3547 have probably = dissolved. >=20 > #3) Sec 3.2: r/Hashes are computed in the manner described within RFC = 2409./Hashes are computed in the manner described within [RFC2409]. >=20 > #4) Sec 3.2: expand prf on first use. >=20 > #5) Sec 3.3: 2 lower case "must" should they be "MUST"? > 1 lower case "should" should it be "SHOULD"? These need to be reworded for clarity. first must: "Before a GM contacts the GCKS, it must determine the group = identifier and acceptable Phase 1 policy via an out-of-band method." = This is less of a requirement than stating a pre-requisite. We propose = replacing "must" with "needs to". second must/should: "If the SEQ payload is present, the sequence number = in the SEQ payload must be checked against any previously received = sequence number for this group. If it is less than the previously = received number, it should be considered stale and ignored." The = requirement is actually this: "If the SEQ payload is present, the = sequence number included in the SEQ payload MUST be greater than any = previously received sequence number. If it is less than the previously = received number, it MUST be considered stale and ignored." >=20 > #6) Sec 4.2: Something is wrong with this: >=20 > Flags MUST have the Encryption bit set according to [RFC2008, Section > 3.1]. >=20 > Maybe it should be: >=20 > Flags MUST have the Encryption bit set according to Section 3.1 of > [RFC2408]. >=20 > #7) Sec 5: r/in accordance with RFC 2408./in accordance with = [RFC2408]. >=20 > #8) Sec 5.1, 5.2: r/defined in RFC 2408./defined in [RFC2408]. >=20 > #9) Sec 5.2: This is difficult to parse: >=20 > The > next payload MUST NOT be a SAK Payload or SAT Payload type, but the > next non-Security Association type payload. >=20 > Maybe it's supposed to be: >=20 > The > next payload MUST NOT be a SAK Payload or SAT Payload type; it MUST > be the > next non-Security Association type payload. >=20 > #9) Sec 5.2: r/Must/MUST X4 >=20 > #10) Sec 5.2.1: r/SA Attributes payloads must be/SA Attributes = payloads MUST be >=20 > #11) Sec 5.3: r/Must/MUST X2 > r/should/SHOULD The "should" ought to be a "MUST" to ensure interoperability. "Value = specifying a port associated with the source Id. A value of zero means = that the SRC ID Port field MUST be ignored." > r/must/MUST >=20 > #12) Sec 5.3: What is the conformance requirement for the following: >=20 > Any or all attributes may be optional, depending on the group policy. >=20 > #13) Sec 5.3.1: >=20 > r/ attributes may be present / attributes MAY be present or change to = say they are OPTIONAL. >=20 > r/attributes must/attributes MUST OK, some cleanup is in order. We propose removing heading 5.3.1 to make = the attribute definition part of 5.3, which is more natural. Then there = needs to be a description of what attributes are required, with the rest = being OPTIONAL (i.e., included if the group policy has included it). How about: o KEK Attributes -- Contains KEK policy attributes associated with the group. The following attributes may be present in a SAK Payload. The attributes must follow the format defined in ISAKMP (Section 3.3 of [RFC2408]). In the table, attributes that are defined as TV are marked as Basic (B); attributes that are defined as TLV are marked as Variable (V). ID Class Value Type -------- ----- ---- RESERVED 0 KEK_MANAGEMENT_ALGORITHM 1 B KEK_ALGORITHM 2 B KEK_KEY_LENGTH 3 B KEK_KEY_LIFETIME 4 V SIG_HASH_ALGORITHM 5 B SIG_ALGORITHM 6 B SIG_KEY_LENGTH 7 B RESERVED 8 B Standards Action 9-127 Private Use 128-255 Unassigned 256-32767 The KEK_ALGORITHM, SIG_ALGORITHM attributes MUST be included; others are OPTIONAL, and included depending on group policy. The KEK_MANAGEMENT_ALGORITHM attribute MUST NOT be included in a GROUPKEY-PULL message, and MUST be ignored if present. >=20 > #14) Sec 5.3.1: >=20 > The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a > GROUPKEY-PULL message. >=20 > What happens if it's included in the PUSH message? See above. >=20 > #15) Just noted to instances of GROUPKEY_. Aren't they supposed to be = GROUPKEY-*? >=20 > #16) Sec 5.3.3.3: r/as recommended in/as defined in >=20 > #17) Sec 5.3.6: Any reason not to point to FIPS 180-3? >=20 > #18) Sec 5.3.6: r/and SIG_HASH_ALGORITHM is not required to be present = in a SAK Payload/and SIG_HASH_ALGORITHM is OPTIONAL in a SAK Payload >=20 > #19) Sec 5.3.7: Does anybody really want RSA-PSS? Not that we know of, but we thought this was esteemed to be better than = PKCS 1.5 and so the protocol should support it. Is that not the current = thinking?a >=20 > #20) Sec 5.4: r/Must/MUST > r/Section 3.3 of RFC 2408./Section 3.3 of [RFC2408]. >=20 > #21) Sec 5.4.1: r/ Section 4.2.1 of RFC 5374/Section 4.2.1 of = [RFC5374] > r/should/SHOULD X2 ?? The second should is advice. How does this sound? "The values of ATD and = DTD are independent. However, the most effective policy will have the = DTD value to be the larger value as this allows new SAs to be activated = before older SAs are deactivated." > #22) Sec 5.5: r/Must/MUST >=20 > #23) Sec 5.5.1: Protocol, SEC ID Port, DST ID Prot, DST ID Port = bullets r/should/SHOULD ? These "should"s ought to be "MUST"s to ensure interoperability. E.g., = "Value specifying a port associated with the source Id. A value of zero = means that the SRC ID Port field MUST be ignored." >=20 > #24) Sec 5.5.1: r/from RFC 2407/from [RFC2407] > r/[RFC2407],/[RFC2407]), > r/ESP must also/ESP MUST also >=20 > #25) Sec 1.3: Add GSPD >=20 > #26) Sec 5.5.1.1.1: r/ RFC 5374/[RFC5374] >=20 > #27) Sec 5.5.1.1.1: r/must/MUST ? This is less of a requirement than an explanation. How about: Applications use the extensions in [RFC5374] to copy the IP addresses into the outer IP header when encapsulating an IP packet as an IPsec tunnel mode packet. This allows an IP multicast packet to continue to be routed as a IP multicast packet. This attribute also provides the necessary policy so that the GDOI group member can appropriately set up the GSPD. >=20 > #28) Sec 5.5.1.1.1: In the following, is 2119 language needed: >=20 > SA TEK payload > may be required in one or both directions. >=20 > #29) Sec 5.5.2: r/All Security Protocols must provide/All Security = Protocols MUST provide >=20 > #30) Sec 5.6.1: r/The attributes must follow/The attributes MUST = follow > r/At least one TEK must be/At least one TEK MUST be >=20 > #31) Sec 5.6.1.2: r/to the member./to the GM. >=20 > #32) Sec 5.6.2 and 5.6.3: r/The attributes must follow/The attributes = MUST follow >=20 > #33) Sec 5.6.3 and 5.6.3.1: r/there must be only/there MUST be only >=20 > #34) Sec 5.6.3.1 and 5.6.3.2: r/Must/MUST >=20 > #35) Sec 1.3: add SSIV >=20 > #36) Sec 5.7: r/Must/MUST > r/must/MUST X3 >=20 > #37) Sec 5.9: r/must be deleted, they must be/are to be deleted, they = MUST be >=20 > #38) Sec 10: References for 2403, 2404, 2407-2409, 3447, 4106, 4543, = 4754, 4868, 5903 are normative according to the following: = http://www.ietf.org/iesg/statement/normative-informative.html Thanks for the pointer to the definitive statement ... I'll re-evaluate = all of the Informative references against it. >=20 > Assuming you delete App A, remove references to 4330 and 5996. >=20 > Please ensure the classification of the other references are in = accordance with the IESG statement. If you've got any questions, let me = know. I don't want to find out later that some informative reference to = an informative RFC is actually a normative reference and we need to do a = 2nd IETF LC to note the DOWNREF. >=20 > I still need to finish Section 7 and 8. Looking forward to this review, thanks. Brian >=20 > spt >=20 >=20 > On 3/31/11 12:14 PM, Vincent Roca wrote: >> Hello everybody, >>=20 >> As you probably noticed the GDOI draft has been significantly >> updated WRT the previous 07 version. For details see: >>=20 >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-msec-gdoi-update-08.txt= >>=20 >> This situation motivates another WGLC. So please review >>=20 >> draft-ietf-msec-gdoi-update-08 >> http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ >>=20 >> and send comments to the WG mailing list by April 18th. >> (NB: if ever this deadline is too close, then tell me...) >>=20 >> Regards, >>=20 >> Vincent >> _______________________________________________ >> MSEC mailing list >> MSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/msec >>=20 > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From turners@ieca.com Mon Apr 18 13:22:49 2011 Return-Path: X-Original-To: msec@ietfc.amsl.com Delivered-To: msec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 33AD3E0822 for ; Mon, 18 Apr 2011 13:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.161 X-Spam-Level: X-Spam-Status: No, score=-102.161 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WojmxkidXlgK for ; Mon, 18 Apr 2011 13:22:47 -0700 (PDT) Received: from nm28.bullet.mail.sp2.yahoo.com (nm28.bullet.mail.sp2.yahoo.com [98.139.91.98]) by ietfc.amsl.com (Postfix) with SMTP id 50F8FE07B2 for ; Mon, 18 Apr 2011 13:22:47 -0700 (PDT) Received: from [98.139.91.64] by nm28.bullet.mail.sp2.yahoo.com with NNFMP; 18 Apr 2011 20:22:46 -0000 Received: from [98.139.91.8] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 18 Apr 2011 20:22:46 -0000 Received: from [127.0.0.1] by omp1008.mail.sp2.yahoo.com with NNFMP; 18 Apr 2011 20:22:46 -0000 X-Yahoo-Newman-Id: 662567.11075.bm@omp1008.mail.sp2.yahoo.com Received: (qmail 64629 invoked from network); 18 Apr 2011 20:22:46 -0000 Received: from thunderfish.local (turners@71.191.4.207 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 18 Apr 2011 13:22:45 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: Zt6UzqsVM1l3tLLNxS3yHOmNChKm6W3yABnbYoiaLhBSxkr t5LJ8BKQx8a10J8fPVkoAbHs1V2W6HIJb0909CbkFGuY8gL.F5t3VPmVmt2Q SU7xlomzhh.bmTNRqlV1YHEKOC2kHpOV8Cd1gp15dOt8Rv5IMiuBQtpKuRUs 26r8xXJ2.rWLL29HuguYZAVfIObOd2eqdkyNvZP_nAttNJmK22GjRxWMLOjk k7D8naDnUEnwEUrAnpn2tCiZFTJB8HyxxMllZsF90Kbxz3TVgqg5RVEaEc5s 5Ou6LUgj86YHZog27W3ZONGxZcSg019Ciwnv37zvHPLu9m0yKtkXOCZST5xy SJSdBXZbjKk3Aj3igqZjMhUrcxFyPX3.Pg_s67Vlq X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DAC9D93.6070508@ieca.com> Date: Mon, 18 Apr 2011 16:22:43 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian Weis References: <4D94540D.1060605@inrialpes.fr> <4D975866.9070102@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@ietf.org Subject: Re: [MSEC] WGLC on draft-ietf-msec-gdoi-update-08 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 20:22:49 -0000 Brian, The changes you suggest look okay to me. As for RSA-PSS, yes the current advice is that it's "better" BUT it requires some interesting things like: - Parameters: With RSA v1.5 the parameters are NULL. With RSA-PSS they're are a bunch things you need to specify: hash algorithm, mask generation algorithm, salt length, and trailer field. - Certificate: Your certificate is going to be different because you need to carry these parameters. Not sure any CA is actually issuing RSA-PSS certificates. I think people are just going to skip it and go straight to ECDSA. I guess it's okay to leave it in there for completeness because there's no requirement to support it. I'll get on to the last sections today. spt On 4/18/11 1:14 PM, Brian Weis wrote: > Hi Sean, > > Thanks for the comprehensive review ... good points, all. I've comments on a few of them inline below. > > On Apr 2, 2011, at 10:09 AM, Sean Turner wrote: > >> #1) Add "updates: 3547 (once approved)" to the header. This will make it match the intro/abstract. I can almost guarantee a discuss from somebody on this. >> >> #2) ISAKMP Phase 1 is described in Section 2.1 as "one such mechanism". This isn't a MUST support. As far as I can tell there isn't a MUST implement Phase 1 protocol (the protocols in Appendix A are also just examples). But, to implement this document you've got to do things as described in RFC 2407-2409. It seems like this doc and IKEv1 are pretty well intertwined. And, the g-ikev2 draft doesn't use these formats it uses something else...Let's be clear about what it's being used with. It seems like this section ought to be changed as follows: >> >> OLD: >> >> The following sections describe one such "phase 1" protocol. Other >> protocols which may be potential "phase 1" protocols are described in >> Appendix A. However, the use of the protocols listed there are not >> considered part of this document. >> >> 2.1. ISAKMP Phase 1 protocol >> >> This document defines how the ISAKMP phase 1 exchanges as defined in >> [RFC2409] can be used a "phase 1" protocol for GDOI. The following >> sections define characteristics of the ISAKMP phase 1 protocols that >> are unique for these exchanges when used for GDOI. >> >> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the >> requirements of a GDOI "phase 1" protocol. >> >> NEW: >> >> This document defines how the ISAKMP phase 1 exchanges as defined in >> [RFC2409] can be used a "phase 1" protocol for GDOI. The following >> sections define characteristics of the ISAKMP phase 1 protocols that >> are unique for these exchanges when used for GDOI. >> >> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the >> requirements of a GDOI "phase 1" protocol. >> >> >> Delete the 2.1 header and renumber 2.1.1 and 2.1.2 to 2.1 and 2.2, respectively. >> >> I would also delete Appendix A. The currently proposed IKEv2 mechanism isn't reusing these fields and the KINK option never got defined. > > Removing this text in Section 2 and Appendix A make a lot of sense. The concerns that caused them to be added to RFC 3547 have probably dissolved. > >> >> #3) Sec 3.2: r/Hashes are computed in the manner described within RFC 2409./Hashes are computed in the manner described within [RFC2409]. >> >> #4) Sec 3.2: expand prf on first use. >> >> #5) Sec 3.3: 2 lower case "must" should they be "MUST"? >> 1 lower case "should" should it be "SHOULD"? > > These need to be reworded for clarity. > > first must: "Before a GM contacts the GCKS, it must determine the group identifier and acceptable Phase 1 policy via an out-of-band method." This is less of a requirement than stating a pre-requisite. We propose replacing "must" with "needs to". > > second must/should: "If the SEQ payload is present, the sequence number in the SEQ payload must be checked against any previously received sequence number for this group. If it is less than the previously received number, it should be considered stale and ignored." The requirement is actually this: "If the SEQ payload is present, the sequence number included in the SEQ payload MUST be greater than any previously received sequence number. If it is less than the previously received number, it MUST be considered stale and ignored." > >> >> #6) Sec 4.2: Something is wrong with this: >> >> Flags MUST have the Encryption bit set according to [RFC2008, Section >> 3.1]. >> >> Maybe it should be: >> >> Flags MUST have the Encryption bit set according to Section 3.1 of >> [RFC2408]. >> >> #7) Sec 5: r/in accordance with RFC 2408./in accordance with [RFC2408]. >> >> #8) Sec 5.1, 5.2: r/defined in RFC 2408./defined in [RFC2408]. >> >> #9) Sec 5.2: This is difficult to parse: >> >> The >> next payload MUST NOT be a SAK Payload or SAT Payload type, but the >> next non-Security Association type payload. >> >> Maybe it's supposed to be: >> >> The >> next payload MUST NOT be a SAK Payload or SAT Payload type; it MUST >> be the >> next non-Security Association type payload. >> >> #9) Sec 5.2: r/Must/MUST X4 >> >> #10) Sec 5.2.1: r/SA Attributes payloads must be/SA Attributes payloads MUST be >> >> #11) Sec 5.3: r/Must/MUST X2 >> r/should/SHOULD > > The "should" ought to be a "MUST" to ensure interoperability. "Value specifying a port associated with the source Id. A value of zero means that the SRC ID Port field MUST be ignored." > >> r/must/MUST >> >> #12) Sec 5.3: What is the conformance requirement for the following: >> >> Any or all attributes may be optional, depending on the group policy. > >> >> #13) Sec 5.3.1: >> >> r/ attributes may be present / attributes MAY be present or change to say they are OPTIONAL. >> >> r/attributes must/attributes MUST > > OK, some cleanup is in order. We propose removing heading 5.3.1 to make the attribute definition part of 5.3, which is more natural. Then there needs to be a description of what attributes are required, with the rest being OPTIONAL (i.e., included if the group policy has included it). > > How about: > > o KEK Attributes -- Contains KEK policy attributes associated with > the group. The following attributes may be present in a SAK Payload. > The attributes must follow the format defined in ISAKMP (Section 3.3 > of [RFC2408]). In the table, attributes that are defined as TV are > marked as Basic (B); attributes that are defined as TLV are marked as > Variable (V). > > > ID Class Value Type > -------- ----- ---- > RESERVED 0 > KEK_MANAGEMENT_ALGORITHM 1 B > KEK_ALGORITHM 2 B > KEK_KEY_LENGTH 3 B > KEK_KEY_LIFETIME 4 V > SIG_HASH_ALGORITHM 5 B > SIG_ALGORITHM 6 B > SIG_KEY_LENGTH 7 B > RESERVED 8 B > Standards Action 9-127 > Private Use 128-255 > Unassigned 256-32767 > > The KEK_ALGORITHM, SIG_ALGORITHM attributes MUST be included; others > are OPTIONAL, and included depending on group policy. The > KEK_MANAGEMENT_ALGORITHM attribute MUST NOT be included in a > GROUPKEY-PULL message, and MUST be ignored if present. > >> >> #14) Sec 5.3.1: >> >> The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a >> GROUPKEY-PULL message. >> >> What happens if it's included in the PUSH message? > > See above. > >> >> #15) Just noted to instances of GROUPKEY_. Aren't they supposed to be GROUPKEY-*? >> >> #16) Sec 5.3.3.3: r/as recommended in/as defined in >> >> #17) Sec 5.3.6: Any reason not to point to FIPS 180-3? >> >> #18) Sec 5.3.6: r/and SIG_HASH_ALGORITHM is not required to be present in a SAK Payload/and SIG_HASH_ALGORITHM is OPTIONAL in a SAK Payload >> >> #19) Sec 5.3.7: Does anybody really want RSA-PSS? > > Not that we know of, but we thought this was esteemed to be better than PKCS 1.5 and so the protocol should support it. Is that not the current thinking?a > >> >> #20) Sec 5.4: r/Must/MUST >> r/Section 3.3 of RFC 2408./Section 3.3 of [RFC2408]. >> >> #21) Sec 5.4.1: r/ Section 4.2.1 of RFC 5374/Section 4.2.1 of [RFC5374] >> r/should/SHOULD X2 ?? > > The second should is advice. How does this sound? "The values of ATD and DTD are independent. However, the most effective policy will have the DTD value to be the larger value as this allows new SAs to be activated before older SAs are deactivated." > >> #22) Sec 5.5: r/Must/MUST >> >> #23) Sec 5.5.1: Protocol, SEC ID Port, DST ID Prot, DST ID Port bullets r/should/SHOULD ? > > These "should"s ought to be "MUST"s to ensure interoperability. E.g., "Value specifying a port associated with the source Id. A value of zero means that the SRC ID Port field MUST be ignored." >> >> #24) Sec 5.5.1: r/from RFC 2407/from [RFC2407] >> r/[RFC2407],/[RFC2407]), >> r/ESP must also/ESP MUST also >> >> #25) Sec 1.3: Add GSPD >> >> #26) Sec 5.5.1.1.1: r/ RFC 5374/[RFC5374] >> >> #27) Sec 5.5.1.1.1: r/must/MUST ? > > This is less of a requirement than an explanation. How about: > > Applications use the extensions in [RFC5374] to copy the IP addresses > into the outer IP header when encapsulating an IP packet as an IPsec > tunnel mode packet. This allows an IP multicast packet to continue > to be routed as a IP multicast packet. This attribute also provides > the necessary policy so that the GDOI group member can appropriately > set up the GSPD. > >> >> #28) Sec 5.5.1.1.1: In the following, is 2119 language needed: >> >> SA TEK payload >> may be required in one or both directions. >> >> #29) Sec 5.5.2: r/All Security Protocols must provide/All Security Protocols MUST provide >> >> #30) Sec 5.6.1: r/The attributes must follow/The attributes MUST follow >> r/At least one TEK must be/At least one TEK MUST be >> >> #31) Sec 5.6.1.2: r/to the member./to the GM. >> >> #32) Sec 5.6.2 and 5.6.3: r/The attributes must follow/The attributes MUST follow >> >> #33) Sec 5.6.3 and 5.6.3.1: r/there must be only/there MUST be only >> >> #34) Sec 5.6.3.1 and 5.6.3.2: r/Must/MUST >> >> #35) Sec 1.3: add SSIV >> >> #36) Sec 5.7: r/Must/MUST >> r/must/MUST X3 >> >> #37) Sec 5.9: r/must be deleted, they must be/are to be deleted, they MUST be >> >> #38) Sec 10: References for 2403, 2404, 2407-2409, 3447, 4106, 4543, 4754, 4868, 5903 are normative according to the following: http://www.ietf.org/iesg/statement/normative-informative.html > > Thanks for the pointer to the definitive statement ... I'll re-evaluate all of the Informative references against it. > >> >> Assuming you delete App A, remove references to 4330 and 5996. >> >> Please ensure the classification of the other references are in accordance with the IESG statement. If you've got any questions, let me know. I don't want to find out later that some informative reference to an informative RFC is actually a normative reference and we need to do a 2nd IETF LC to note the DOWNREF. >> >> I still need to finish Section 7 and 8. > > Looking forward to this review, thanks. > > Brian > >> >> spt >> >> >> On 3/31/11 12:14 PM, Vincent Roca wrote: >>> Hello everybody, >>> >>> As you probably noticed the GDOI draft has been significantly >>> updated WRT the previous 07 version. For details see: >>> >>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-msec-gdoi-update-08.txt >>> >>> This situation motivates another WGLC. So please review >>> >>> draft-ietf-msec-gdoi-update-08 >>> http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ >>> >>> and send comments to the WG mailing list by April 18th. >>> (NB: if ever this deadline is too close, then tell me...) >>> >>> Regards, >>> >>> Vincent >>> _______________________________________________ >>> MSEC mailing list >>> MSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/msec >>> >> _______________________________________________ >> MSEC mailing list >> MSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/msec > > From turners@ieca.com Mon Apr 18 13:55:04 2011 Return-Path: X-Original-To: msec@ietfc.amsl.com Delivered-To: msec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F5B0E0718 for ; Mon, 18 Apr 2011 13:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzUwp5j8rttT for ; Mon, 18 Apr 2011 13:55:03 -0700 (PDT) Received: from nm1.bullet.mail.sp2.yahoo.com (nm1.bullet.mail.sp2.yahoo.com [98.139.91.71]) by ietfc.amsl.com (Postfix) with SMTP id B24A4E0701 for ; Mon, 18 Apr 2011 13:55:02 -0700 (PDT) Received: from [98.139.91.70] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 18 Apr 2011 20:54:59 -0000 Received: from [98.139.91.48] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 18 Apr 2011 20:54:59 -0000 Received: from [127.0.0.1] by omp1048.mail.sp2.yahoo.com with NNFMP; 18 Apr 2011 20:54:59 -0000 X-Yahoo-Newman-Id: 653502.53070.bm@omp1048.mail.sp2.yahoo.com Received: (qmail 68082 invoked from network); 18 Apr 2011 20:54:59 -0000 Received: from thunderfish.local (turners@71.191.4.207 with plain) by smtp115.biz.mail.sp1.yahoo.com with SMTP; 18 Apr 2011 13:54:58 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: Tvg6twAVM1nfPLSujb5u7l3rXrQkoINZepjuQvkxZheJjRA aHHflwY95ISOyeXHiT5JTsSxJVd97AMAfDeDtxNI80j8uvOohkotSHqCIJy3 Ny5A52mC.CscPCgFtdUSPiNRFrX71hjHrAAjzeCWWykVn5C1jFYbHXPFEAZZ R5zziSwFLDqm6XM_s6cjimX69FfothfJsbLfplRfZsXVWW7hpih_hsGb.a48 CGlFEs.hNJk1htmScAAwdZyCaQlUo9icDFsQLQSWW1tX2B9_hAHDwX3Sw5uF i5M7qTMpHo_dHCdY3ymlzQMHvIHgUux1EkhunESeKRdHJsbuUr2X5v5ajpN5 Tmk2UX8OubiryJnYvPRzTCQJ0U6Xvp4VgaNrkTKJv X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DACA51F.5090300@ieca.com> Date: Mon, 18 Apr 2011 16:54:55 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: msec@ietf.org References: <4D94540D.1060605@inrialpes.fr> <4D975866.9070102@ieca.com> In-Reply-To: <4D975866.9070102@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MSEC] WGLC on draft-ietf-msec-gdoi-update-08 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 20:55:04 -0000 Here's the rest of my comments on Sections 7 and 8 (all in 8): Section 5.3.7 shows TBD-6 to 9 but the second paragraph in 8.1 only discussed TBD-6. The others should be added in 8.1. Section 5.6 shows TBD-7 and so does Section 8.1, but there's already a TBD-7 in Section 5.3.7. Maybe renumber the one in Section 5.6 TBD-10? Section 8.2: In the new registries, you need to say what needs to be done to update the registries (e.g., specification required, standards action). spt On 4/2/11 1:09 PM, Sean Turner wrote: > #1) Add "updates: 3547 (once approved)" to the header. This will make it > match the intro/abstract. I can almost guarantee a discuss from somebody > on this. > > #2) ISAKMP Phase 1 is described in Section 2.1 as "one such mechanism". > This isn't a MUST support. As far as I can tell there isn't a MUST > implement Phase 1 protocol (the protocols in Appendix A are also just > examples). But, to implement this document you've got to do things as > described in RFC 2407-2409. It seems like this doc and IKEv1 are pretty > well intertwined. And, the g-ikev2 draft doesn't use these formats it > uses something else...Let's be clear about what it's being used with. It > seems like this section ought to be changed as follows: > > OLD: > > The following sections describe one such "phase 1" protocol. Other > protocols which may be potential "phase 1" protocols are described in > Appendix A. However, the use of the protocols listed there are not > considered part of this document. > > 2.1. ISAKMP Phase 1 protocol > > This document defines how the ISAKMP phase 1 exchanges as defined in > [RFC2409] can be used a "phase 1" protocol for GDOI. The following > sections define characteristics of the ISAKMP phase 1 protocols that > are unique for these exchanges when used for GDOI. > > Section 7.1 describes how the ISAKMP Phase 1 protocols meet the > requirements of a GDOI "phase 1" protocol. > > NEW: > > This document defines how the ISAKMP phase 1 exchanges as defined in > [RFC2409] can be used a "phase 1" protocol for GDOI. The following > sections define characteristics of the ISAKMP phase 1 protocols that > are unique for these exchanges when used for GDOI. > > Section 7.1 describes how the ISAKMP Phase 1 protocols meet the > requirements of a GDOI "phase 1" protocol. > > > Delete the 2.1 header and renumber 2.1.1 and 2.1.2 to 2.1 and 2.2, > respectively. > > I would also delete Appendix A. The currently proposed IKEv2 mechanism > isn't reusing these fields and the KINK option never got defined. > > #3) Sec 3.2: r/Hashes are computed in the manner described within RFC > 2409./Hashes are computed in the manner described within [RFC2409]. > > #4) Sec 3.2: expand prf on first use. > > #5) Sec 3.3: 2 lower case "must" should they be "MUST"? > 1 lower case "should" should it be "SHOULD"? > > #6) Sec 4.2: Something is wrong with this: > > Flags MUST have the Encryption bit set according to [RFC2008, Section > 3.1]. > > Maybe it should be: > > Flags MUST have the Encryption bit set according to Section 3.1 of > [RFC2408]. > > #7) Sec 5: r/in accordance with RFC 2408./in accordance with [RFC2408]. > > #8) Sec 5.1, 5.2: r/defined in RFC 2408./defined in [RFC2408]. > > #9) Sec 5.2: This is difficult to parse: > > The > next payload MUST NOT be a SAK Payload or SAT Payload type, but the > next non-Security Association type payload. > > Maybe it's supposed to be: > > The > next payload MUST NOT be a SAK Payload or SAT Payload type; it MUST > be the > next non-Security Association type payload. > > #9) Sec 5.2: r/Must/MUST X4 > > #10) Sec 5.2.1: r/SA Attributes payloads must be/SA Attributes payloads > MUST be > > #11) Sec 5.3: r/Must/MUST X2 > r/should/SHOULD > r/must/MUST > > #12) Sec 5.3: What is the conformance requirement for the following: > > Any or all attributes may be optional, depending on the group policy. > > #13) Sec 5.3.1: > > r/ attributes may be present / attributes MAY be present or change to > say they are OPTIONAL. > > r/attributes must/attributes MUST > > #14) Sec 5.3.1: > > The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a > GROUPKEY-PULL message. > > What happens if it's included in the PUSH message? > > #15) Just noted to instances of GROUPKEY_. Aren't they supposed to be > GROUPKEY-*? > > #16) Sec 5.3.3.3: r/as recommended in/as defined in > > #17) Sec 5.3.6: Any reason not to point to FIPS 180-3? > > #18) Sec 5.3.6: r/and SIG_HASH_ALGORITHM is not required to be present > in a SAK Payload/and SIG_HASH_ALGORITHM is OPTIONAL in a SAK Payload > > #19) Sec 5.3.7: Does anybody really want RSA-PSS? > > #20) Sec 5.4: r/Must/MUST > r/Section 3.3 of RFC 2408./Section 3.3 of [RFC2408]. > > #21) Sec 5.4.1: r/ Section 4.2.1 of RFC 5374/Section 4.2.1 of [RFC5374] > r/should/SHOULD X2 ?? > > #22) Sec 5.5: r/Must/MUST > > #23) Sec 5.5.1: Protocol, SEC ID Port, DST ID Prot, DST ID Port bullets > r/should/SHOULD ? > > #24) Sec 5.5.1: r/from RFC 2407/from [RFC2407] > r/[RFC2407],/[RFC2407]), > r/ESP must also/ESP MUST also > > #25) Sec 1.3: Add GSPD > > #26) Sec 5.5.1.1.1: r/ RFC 5374/[RFC5374] > > #27) Sec 5.5.1.1.1: r/must/MUST ? > > #28) Sec 5.5.1.1.1: In the following, is 2119 language needed: > > SA TEK payload > may be required in one or both directions. > > #29) Sec 5.5.2: r/All Security Protocols must provide/All Security > Protocols MUST provide > > #30) Sec 5.6.1: r/The attributes must follow/The attributes MUST follow > r/At least one TEK must be/At least one TEK MUST be > > #31) Sec 5.6.1.2: r/to the member./to the GM. > > #32) Sec 5.6.2 and 5.6.3: r/The attributes must follow/The attributes > MUST follow > > #33) Sec 5.6.3 and 5.6.3.1: r/there must be only/there MUST be only > > #34) Sec 5.6.3.1 and 5.6.3.2: r/Must/MUST > > #35) Sec 1.3: add SSIV > > #36) Sec 5.7: r/Must/MUST > r/must/MUST X3 > > #37) Sec 5.9: r/must be deleted, they must be/are to be deleted, they > MUST be > > #38) Sec 10: References for 2403, 2404, 2407-2409, 3447, 4106, 4543, > 4754, 4868, 5903 are normative according to the following: > http://www.ietf.org/iesg/statement/normative-informative.html > > Assuming you delete App A, remove references to 4330 and 5996. > > Please ensure the classification of the other references are in > accordance with the IESG statement. If you've got any questions, let me > know. I don't want to find out later that some informative reference to > an informative RFC is actually a normative reference and we need to do a > 2nd IETF LC to note the DOWNREF. > > I still need to finish Section 7 and 8. > > spt > > > On 3/31/11 12:14 PM, Vincent Roca wrote: >> Hello everybody, >> >> As you probably noticed the GDOI draft has been significantly >> updated WRT the previous 07 version. For details see: >> >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-msec-gdoi-update-08.txt >> >> This situation motivates another WGLC. So please review >> >> draft-ietf-msec-gdoi-update-08 >> http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ >> >> and send comments to the WG mailing list by April 18th. >> (NB: if ever this deadline is too close, then tell me...) >> >> Regards, >> >> Vincent >> _______________________________________________ >> MSEC mailing list >> MSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/msec >> > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec > From turners@ieca.com Mon Apr 18 14:24:57 2011 Return-Path: X-Original-To: msec@ietfc.amsl.com Delivered-To: msec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8A7D8E071C for ; Mon, 18 Apr 2011 14:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNYIrXzxDAsu for ; Mon, 18 Apr 2011 14:24:55 -0700 (PDT) Received: from nm14-vm0.bullet.mail.sp2.yahoo.com (nm14-vm0.bullet.mail.sp2.yahoo.com [98.139.91.246]) by ietfc.amsl.com (Postfix) with SMTP id 8EA99E069A for ; Mon, 18 Apr 2011 14:24:52 -0700 (PDT) Received: from [98.139.91.63] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 18 Apr 2011 21:24:49 -0000 Received: from [98.139.91.59] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 18 Apr 2011 21:24:49 -0000 Received: from [127.0.0.1] by omp1059.mail.sp2.yahoo.com with NNFMP; 18 Apr 2011 21:24:49 -0000 X-Yahoo-Newman-Id: 127864.93037.bm@omp1059.mail.sp2.yahoo.com Received: (qmail 16811 invoked from network); 18 Apr 2011 21:24:49 -0000 Received: from thunderfish.local (turners@71.191.4.207 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 18 Apr 2011 14:24:47 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: E39eAwkVM1kAl3Kl8wbES8T5NolMcCYrKGrhixWdJPrV0A7 fUVF4xSKewlmVX0OOiCxTu4KTRoqJ64gICRdjbkC0F7xb6YY_dqqY0uPBE8s .NZvtRmoGhJ0xFYFxDNXduqMZ4vwGYMOjW6dEXE8tMcc6DNYCOqqqBaEmqgG Xdyyylf1B7bsVj64LqFm2vrBmJ.6ga55ra7oAy2rSK6wZWoSh3gCFsd_Ng0p Dbn0iaDj6XI3SIR_5Lc03I0EFAgwLuThPD9.ZZp.UZpsTw.4oHxbrepQjDOm mzqfjDyfrLK3QVaz2pJAiQ9JDYoR7s0vPStJp6mkB_V09wnEN4Fa15Qc1OwU RaRj8boRhmld42X..lJGNOOuNE3_kKzblsrJ6SN.E X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DACAC1E.2060007@ieca.com> Date: Mon, 18 Apr 2011 17:24:46 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian Weis References: <4D94540D.1060605@inrialpes.fr> <4D975866.9070102@ieca.com> <4DAC9D93.6070508@ieca.com> <55C09EDE-9F52-4F08-9B91-FB0BA5ADA882@cisco.com> In-Reply-To: <55C09EDE-9F52-4F08-9B91-FB0BA5ADA882@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@ietf.org Subject: Re: [MSEC] WGLC on draft-ietf-msec-gdoi-update-08 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 21:24:57 -0000 On 4/18/11 5:09 PM, Brian Weis wrote: > Hi Sean, > > On Apr 18, 2011, at 1:22 PM, Sean Turner wrote: > >> Brian, >> >> The changes you suggest look okay to me. >> >> As for RSA-PSS, yes the current advice is that it's "better" BUT it requires some interesting things like: >> - Parameters: With RSA v1.5 the parameters are NULL. With RSA-PSS they're are a bunch things you need to specify: hash algorithm, mask generation algorithm, salt length, and trailer field. > > Thanks for the clarification. But if there are "a bunch of things you need to specify", then to get an interoperable solution I guess we'd need to specify them. :-) If that's the case, I'd rather take it out (given the lack of current RSS-PSS usage). To be fair there's a set of defaults defined in the standard so if you were going to add RSA-PSS then you'd need to point to those defaults. If nobody is asking for it though .... > Thanks, > Brian > >> - Certificate: Your certificate is going to be different because you need to carry these parameters. Not sure any CA is actually issuing RSA-PSS certificates. >> >> I think people are just going to skip it and go straight to ECDSA. I guess it's okay to leave it in there for completeness because there's no requirement to support it. >> >> I'll get on to the last sections today. >> >> spt >> >> On 4/18/11 1:14 PM, Brian Weis wrote: >>> Hi Sean, >>> >>> Thanks for the comprehensive review ... good points, all. I've comments on a few of them inline below. >>> >>> On Apr 2, 2011, at 10:09 AM, Sean Turner wrote: >>> >>>> #1) Add "updates: 3547 (once approved)" to the header. This will make it match the intro/abstract. I can almost guarantee a discuss from somebody on this. >>>> >>>> #2) ISAKMP Phase 1 is described in Section 2.1 as "one such mechanism". This isn't a MUST support. As far as I can tell there isn't a MUST implement Phase 1 protocol (the protocols in Appendix A are also just examples). But, to implement this document you've got to do things as described in RFC 2407-2409. It seems like this doc and IKEv1 are pretty well intertwined. And, the g-ikev2 draft doesn't use these formats it uses something else...Let's be clear about what it's being used with. It seems like this section ought to be changed as follows: >>>> >>>> OLD: >>>> >>>> The following sections describe one such "phase 1" protocol. Other >>>> protocols which may be potential "phase 1" protocols are described in >>>> Appendix A. However, the use of the protocols listed there are not >>>> considered part of this document. >>>> >>>> 2.1. ISAKMP Phase 1 protocol >>>> >>>> This document defines how the ISAKMP phase 1 exchanges as defined in >>>> [RFC2409] can be used a "phase 1" protocol for GDOI. The following >>>> sections define characteristics of the ISAKMP phase 1 protocols that >>>> are unique for these exchanges when used for GDOI. >>>> >>>> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the >>>> requirements of a GDOI "phase 1" protocol. >>>> >>>> NEW: >>>> >>>> This document defines how the ISAKMP phase 1 exchanges as defined in >>>> [RFC2409] can be used a "phase 1" protocol for GDOI. The following >>>> sections define characteristics of the ISAKMP phase 1 protocols that >>>> are unique for these exchanges when used for GDOI. >>>> >>>> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the >>>> requirements of a GDOI "phase 1" protocol. >>>> >>>> >>>> Delete the 2.1 header and renumber 2.1.1 and 2.1.2 to 2.1 and 2.2, respectively. >>>> >>>> I would also delete Appendix A. The currently proposed IKEv2 mechanism isn't reusing these fields and the KINK option never got defined. >>> >>> Removing this text in Section 2 and Appendix A make a lot of sense. The concerns that caused them to be added to RFC 3547 have probably dissolved. >>> >>>> >>>> #3) Sec 3.2: r/Hashes are computed in the manner described within RFC 2409./Hashes are computed in the manner described within [RFC2409]. >>>> >>>> #4) Sec 3.2: expand prf on first use. >>>> >>>> #5) Sec 3.3: 2 lower case "must" should they be "MUST"? >>>> 1 lower case "should" should it be "SHOULD"? >>> >>> These need to be reworded for clarity. >>> >>> first must: "Before a GM contacts the GCKS, it must determine the group identifier and acceptable Phase 1 policy via an out-of-band method." This is less of a requirement than stating a pre-requisite. We propose replacing "must" with "needs to". >>> >>> second must/should: "If the SEQ payload is present, the sequence number in the SEQ payload must be checked against any previously received sequence number for this group. If it is less than the previously received number, it should be considered stale and ignored." The requirement is actually this: "If the SEQ payload is present, the sequence number included in the SEQ payload MUST be greater than any previously received sequence number. If it is less than the previously received number, it MUST be considered stale and ignored." >>> >>>> >>>> #6) Sec 4.2: Something is wrong with this: >>>> >>>> Flags MUST have the Encryption bit set according to [RFC2008, Section >>>> 3.1]. >>>> >>>> Maybe it should be: >>>> >>>> Flags MUST have the Encryption bit set according to Section 3.1 of >>>> [RFC2408]. >>>> >>>> #7) Sec 5: r/in accordance with RFC 2408./in accordance with [RFC2408]. >>>> >>>> #8) Sec 5.1, 5.2: r/defined in RFC 2408./defined in [RFC2408]. >>>> >>>> #9) Sec 5.2: This is difficult to parse: >>>> >>>> The >>>> next payload MUST NOT be a SAK Payload or SAT Payload type, but the >>>> next non-Security Association type payload. >>>> >>>> Maybe it's supposed to be: >>>> >>>> The >>>> next payload MUST NOT be a SAK Payload or SAT Payload type; it MUST >>>> be the >>>> next non-Security Association type payload. >>>> >>>> #9) Sec 5.2: r/Must/MUST X4 >>>> >>>> #10) Sec 5.2.1: r/SA Attributes payloads must be/SA Attributes payloads MUST be >>>> >>>> #11) Sec 5.3: r/Must/MUST X2 >>>> r/should/SHOULD >>> >>> The "should" ought to be a "MUST" to ensure interoperability. "Value specifying a port associated with the source Id. A value of zero means that the SRC ID Port field MUST be ignored." >>> >>>> r/must/MUST >>>> >>>> #12) Sec 5.3: What is the conformance requirement for the following: >>>> >>>> Any or all attributes may be optional, depending on the group policy. >>> >>>> >>>> #13) Sec 5.3.1: >>>> >>>> r/ attributes may be present / attributes MAY be present or change to say they are OPTIONAL. >>>> >>>> r/attributes must/attributes MUST >>> >>> OK, some cleanup is in order. We propose removing heading 5.3.1 to make the attribute definition part of 5.3, which is more natural. Then there needs to be a description of what attributes are required, with the rest being OPTIONAL (i.e., included if the group policy has included it). >>> >>> How about: >>> >>> o KEK Attributes -- Contains KEK policy attributes associated with >>> the group. The following attributes may be present in a SAK Payload. >>> The attributes must follow the format defined in ISAKMP (Section 3.3 >>> of [RFC2408]). In the table, attributes that are defined as TV are >>> marked as Basic (B); attributes that are defined as TLV are marked as >>> Variable (V). >>> >>> >>> ID Class Value Type >>> -------- ----- ---- >>> RESERVED 0 >>> KEK_MANAGEMENT_ALGORITHM 1 B >>> KEK_ALGORITHM 2 B >>> KEK_KEY_LENGTH 3 B >>> KEK_KEY_LIFETIME 4 V >>> SIG_HASH_ALGORITHM 5 B >>> SIG_ALGORITHM 6 B >>> SIG_KEY_LENGTH 7 B >>> RESERVED 8 B >>> Standards Action 9-127 >>> Private Use 128-255 >>> Unassigned 256-32767 >>> >>> The KEK_ALGORITHM, SIG_ALGORITHM attributes MUST be included; others >>> are OPTIONAL, and included depending on group policy. The >>> KEK_MANAGEMENT_ALGORITHM attribute MUST NOT be included in a >>> GROUPKEY-PULL message, and MUST be ignored if present. >>> >>>> >>>> #14) Sec 5.3.1: >>>> >>>> The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a >>>> GROUPKEY-PULL message. >>>> >>>> What happens if it's included in the PUSH message? >>> >>> See above. >>> >>>> >>>> #15) Just noted to instances of GROUPKEY_. Aren't they supposed to be GROUPKEY-*? >>>> >>>> #16) Sec 5.3.3.3: r/as recommended in/as defined in >>>> >>>> #17) Sec 5.3.6: Any reason not to point to FIPS 180-3? >>>> >>>> #18) Sec 5.3.6: r/and SIG_HASH_ALGORITHM is not required to be present in a SAK Payload/and SIG_HASH_ALGORITHM is OPTIONAL in a SAK Payload >>>> >>>> #19) Sec 5.3.7: Does anybody really want RSA-PSS? >>> >>> Not that we know of, but we thought this was esteemed to be better than PKCS 1.5 and so the protocol should support it. Is that not the current thinking?a >>> >>>> >>>> #20) Sec 5.4: r/Must/MUST >>>> r/Section 3.3 of RFC 2408./Section 3.3 of [RFC2408]. >>>> >>>> #21) Sec 5.4.1: r/ Section 4.2.1 of RFC 5374/Section 4.2.1 of [RFC5374] >>>> r/should/SHOULD X2 ?? >>> >>> The second should is advice. How does this sound? "The values of ATD and DTD are independent. However, the most effective policy will have the DTD value to be the larger value as this allows new SAs to be activated before older SAs are deactivated." >>> >>>> #22) Sec 5.5: r/Must/MUST >>>> >>>> #23) Sec 5.5.1: Protocol, SEC ID Port, DST ID Prot, DST ID Port bullets r/should/SHOULD ? >>> >>> These "should"s ought to be "MUST"s to ensure interoperability. E.g., "Value specifying a port associated with the source Id. A value of zero means that the SRC ID Port field MUST be ignored." >>>> >>>> #24) Sec 5.5.1: r/from RFC 2407/from [RFC2407] >>>> r/[RFC2407],/[RFC2407]), >>>> r/ESP must also/ESP MUST also >>>> >>>> #25) Sec 1.3: Add GSPD >>>> >>>> #26) Sec 5.5.1.1.1: r/ RFC 5374/[RFC5374] >>>> >>>> #27) Sec 5.5.1.1.1: r/must/MUST ? >>> >>> This is less of a requirement than an explanation. How about: >>> >>> Applications use the extensions in [RFC5374] to copy the IP addresses >>> into the outer IP header when encapsulating an IP packet as an IPsec >>> tunnel mode packet. This allows an IP multicast packet to continue >>> to be routed as a IP multicast packet. This attribute also provides >>> the necessary policy so that the GDOI group member can appropriately >>> set up the GSPD. >>> >>>> >>>> #28) Sec 5.5.1.1.1: In the following, is 2119 language needed: >>>> >>>> SA TEK payload >>>> may be required in one or both directions. >>>> >>>> #29) Sec 5.5.2: r/All Security Protocols must provide/All Security Protocols MUST provide >>>> >>>> #30) Sec 5.6.1: r/The attributes must follow/The attributes MUST follow >>>> r/At least one TEK must be/At least one TEK MUST be >>>> >>>> #31) Sec 5.6.1.2: r/to the member./to the GM. >>>> >>>> #32) Sec 5.6.2 and 5.6.3: r/The attributes must follow/The attributes MUST follow >>>> >>>> #33) Sec 5.6.3 and 5.6.3.1: r/there must be only/there MUST be only >>>> >>>> #34) Sec 5.6.3.1 and 5.6.3.2: r/Must/MUST >>>> >>>> #35) Sec 1.3: add SSIV >>>> >>>> #36) Sec 5.7: r/Must/MUST >>>> r/must/MUST X3 >>>> >>>> #37) Sec 5.9: r/must be deleted, they must be/are to be deleted, they MUST be >>>> >>>> #38) Sec 10: References for 2403, 2404, 2407-2409, 3447, 4106, 4543, 4754, 4868, 5903 are normative according to the following: http://www.ietf.org/iesg/statement/normative-informative.html >>> >>> Thanks for the pointer to the definitive statement ... I'll re-evaluate all of the Informative references against it. >>> >>>> >>>> Assuming you delete App A, remove references to 4330 and 5996. >>>> >>>> Please ensure the classification of the other references are in accordance with the IESG statement. If you've got any questions, let me know. I don't want to find out later that some informative reference to an informative RFC is actually a normative reference and we need to do a 2nd IETF LC to note the DOWNREF. >>>> >>>> I still need to finish Section 7 and 8. >>> >>> Looking forward to this review, thanks. >>> >>> Brian >>> >>>> >>>> spt >>>> >>>> >>>> On 3/31/11 12:14 PM, Vincent Roca wrote: >>>>> Hello everybody, >>>>> >>>>> As you probably noticed the GDOI draft has been significantly >>>>> updated WRT the previous 07 version. For details see: >>>>> >>>>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-msec-gdoi-update-08.txt >>>>> >>>>> This situation motivates another WGLC. So please review >>>>> >>>>> draft-ietf-msec-gdoi-update-08 >>>>> http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ >>>>> >>>>> and send comments to the WG mailing list by April 18th. >>>>> (NB: if ever this deadline is too close, then tell me...) >>>>> >>>>> Regards, >>>>> >>>>> Vincent >>>>> _______________________________________________ >>>>> MSEC mailing list >>>>> MSEC@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/msec >>>>> >>>> _______________________________________________ >>>> MSEC mailing list >>>> MSEC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/msec >>> >>> > > From bew@cisco.com Mon Apr 18 14:31:30 2011 Return-Path: X-Original-To: msec@ietfc.amsl.com Delivered-To: msec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 94FB5E0786 for ; Mon, 18 Apr 2011 14:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.199 X-Spam-Level: X-Spam-Status: No, score=-110.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gVw2+OrTkcF for ; Mon, 18 Apr 2011 14:31:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id D7993E06E1 for ; Mon, 18 Apr 2011 14:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=14008; q=dns/txt; s=iport; t=1303162287; x=1304371887; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uYHMu/AZV2IX0jVlc+PkBDuoUJPJLAbrO3sesZdA1Ps=; b=DRGlZN7OCSLyyGCEN6DOiLLiQhClkswsT5c6zbzGPYXXymi38NgOl5ct BQXF7WC9PLQiEX6llL9GpL/dYbmLHSXp0rVaeUrWPMnsbuUnibaGVpRfO YPdJQNnCkffMdN5I/9dpEI4hR+LTSpRC8FyaV/UQJRZb65LFMl5DyhKHQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAuorE2rRDoJ/2dsb2JhbAClQXeIb6BOjUWPDIMZglgEhWKIHg X-IronPort-AV: E=Sophos;i="4.64,235,1301875200"; d="scan'208";a="683454813" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 18 Apr 2011 21:09:20 +0000 Received: from dhcp-128-107-151-48.cisco.com (dhcp-128-107-151-48.cisco.com [128.107.151.48]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3IL9KE4002855; Mon, 18 Apr 2011 21:09:20 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <4DAC9D93.6070508@ieca.com> Date: Mon, 18 Apr 2011 14:09:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <55C09EDE-9F52-4F08-9B91-FB0BA5ADA882@cisco.com> References: <4D94540D.1060605@inrialpes.fr> <4D975866.9070102@ieca.com> <4DAC9D93.6070508@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1082) Cc: msec@ietf.org Subject: Re: [MSEC] WGLC on draft-ietf-msec-gdoi-update-08 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 21:31:30 -0000 Hi Sean, On Apr 18, 2011, at 1:22 PM, Sean Turner wrote: > Brian, >=20 > The changes you suggest look okay to me. >=20 > As for RSA-PSS, yes the current advice is that it's "better" BUT it = requires some interesting things like: > - Parameters: With RSA v1.5 the parameters are NULL. With RSA-PSS = they're are a bunch things you need to specify: hash algorithm, mask = generation algorithm, salt length, and trailer field. Thanks for the clarification. But if there are "a bunch of things you = need to specify", then to get an interoperable solution I guess we'd = need to specify them. :-) If that's the case, I'd rather take it out = (given the lack of current RSS-PSS usage). Thanks, Brian > - Certificate: Your certificate is going to be different because you = need to carry these parameters. Not sure any CA is actually issuing = RSA-PSS certificates. >=20 > I think people are just going to skip it and go straight to ECDSA. I = guess it's okay to leave it in there for completeness because there's no = requirement to support it. >=20 > I'll get on to the last sections today. >=20 > spt >=20 > On 4/18/11 1:14 PM, Brian Weis wrote: >> Hi Sean, >>=20 >> Thanks for the comprehensive review ... good points, all. I've = comments on a few of them inline below. >>=20 >> On Apr 2, 2011, at 10:09 AM, Sean Turner wrote: >>=20 >>> #1) Add "updates: 3547 (once approved)" to the header. This will = make it match the intro/abstract. I can almost guarantee a discuss from = somebody on this. >>>=20 >>> #2) ISAKMP Phase 1 is described in Section 2.1 as "one such = mechanism". This isn't a MUST support. As far as I can tell there = isn't a MUST implement Phase 1 protocol (the protocols in Appendix A are = also just examples). But, to implement this document you've got to do = things as described in RFC 2407-2409. It seems like this doc and IKEv1 = are pretty well intertwined. And, the g-ikev2 draft doesn't use these = formats it uses something else...Let's be clear about what it's being = used with. It seems like this section ought to be changed as follows: >>>=20 >>> OLD: >>>=20 >>> The following sections describe one such "phase 1" protocol. Other >>> protocols which may be potential "phase 1" protocols are described = in >>> Appendix A. However, the use of the protocols listed there are not >>> considered part of this document. >>>=20 >>> 2.1. ISAKMP Phase 1 protocol >>>=20 >>> This document defines how the ISAKMP phase 1 exchanges as defined = in >>> [RFC2409] can be used a "phase 1" protocol for GDOI. The following >>> sections define characteristics of the ISAKMP phase 1 protocols = that >>> are unique for these exchanges when used for GDOI. >>>=20 >>> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the >>> requirements of a GDOI "phase 1" protocol. >>>=20 >>> NEW: >>>=20 >>> This document defines how the ISAKMP phase 1 exchanges as defined = in >>> [RFC2409] can be used a "phase 1" protocol for GDOI. The following >>> sections define characteristics of the ISAKMP phase 1 protocols = that >>> are unique for these exchanges when used for GDOI. >>>=20 >>> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the >>> requirements of a GDOI "phase 1" protocol. >>>=20 >>>=20 >>> Delete the 2.1 header and renumber 2.1.1 and 2.1.2 to 2.1 and 2.2, = respectively. >>>=20 >>> I would also delete Appendix A. The currently proposed IKEv2 = mechanism isn't reusing these fields and the KINK option never got = defined. >>=20 >> Removing this text in Section 2 and Appendix A make a lot of sense. = The concerns that caused them to be added to RFC 3547 have probably = dissolved. >>=20 >>>=20 >>> #3) Sec 3.2: r/Hashes are computed in the manner described within = RFC 2409./Hashes are computed in the manner described within [RFC2409]. >>>=20 >>> #4) Sec 3.2: expand prf on first use. >>>=20 >>> #5) Sec 3.3: 2 lower case "must" should they be "MUST"? >>> 1 lower case "should" should it be "SHOULD"? >>=20 >> These need to be reworded for clarity. >>=20 >> first must: "Before a GM contacts the GCKS, it must determine the = group identifier and acceptable Phase 1 policy via an out-of-band = method." This is less of a requirement than stating a pre-requisite. We = propose replacing "must" with "needs to". >>=20 >> second must/should: "If the SEQ payload is present, the sequence = number in the SEQ payload must be checked against any previously = received sequence number for this group. If it is less than the = previously received number, it should be considered stale and ignored." = The requirement is actually this: "If the SEQ payload is present, the = sequence number included in the SEQ payload MUST be greater than any = previously received sequence number. If it is less than the previously = received number, it MUST be considered stale and ignored." >>=20 >>>=20 >>> #6) Sec 4.2: Something is wrong with this: >>>=20 >>> Flags MUST have the Encryption bit set according to [RFC2008, = Section >>> 3.1]. >>>=20 >>> Maybe it should be: >>>=20 >>> Flags MUST have the Encryption bit set according to Section 3.1 of >>> [RFC2408]. >>>=20 >>> #7) Sec 5: r/in accordance with RFC 2408./in accordance with = [RFC2408]. >>>=20 >>> #8) Sec 5.1, 5.2: r/defined in RFC 2408./defined in [RFC2408]. >>>=20 >>> #9) Sec 5.2: This is difficult to parse: >>>=20 >>> The >>> next payload MUST NOT be a SAK Payload or SAT Payload type, but = the >>> next non-Security Association type payload. >>>=20 >>> Maybe it's supposed to be: >>>=20 >>> The >>> next payload MUST NOT be a SAK Payload or SAT Payload type; it = MUST >>> be the >>> next non-Security Association type payload. >>>=20 >>> #9) Sec 5.2: r/Must/MUST X4 >>>=20 >>> #10) Sec 5.2.1: r/SA Attributes payloads must be/SA Attributes = payloads MUST be >>>=20 >>> #11) Sec 5.3: r/Must/MUST X2 >>> r/should/SHOULD >>=20 >> The "should" ought to be a "MUST" to ensure interoperability. "Value = specifying a port associated with the source Id. A value of zero means = that the SRC ID Port field MUST be ignored." >>=20 >>> r/must/MUST >>>=20 >>> #12) Sec 5.3: What is the conformance requirement for the following: >>>=20 >>> Any or all attributes may be optional, depending on the group = policy. >>=20 >>>=20 >>> #13) Sec 5.3.1: >>>=20 >>> r/ attributes may be present / attributes MAY be present or change = to say they are OPTIONAL. >>>=20 >>> r/attributes must/attributes MUST >>=20 >> OK, some cleanup is in order. We propose removing heading 5.3.1 to = make the attribute definition part of 5.3, which is more natural. Then = there needs to be a description of what attributes are required, with = the rest being OPTIONAL (i.e., included if the group policy has included = it). >>=20 >> How about: >>=20 >> o KEK Attributes -- Contains KEK policy attributes associated with >> the group. The following attributes may be present in a SAK = Payload. >> The attributes must follow the format defined in ISAKMP (Section = 3.3 >> of [RFC2408]). In the table, attributes that are defined as TV = are >> marked as Basic (B); attributes that are defined as TLV are marked = as >> Variable (V). >>=20 >>=20 >> ID Class Value Type >> -------- ----- ---- >> RESERVED 0 >> KEK_MANAGEMENT_ALGORITHM 1 B >> KEK_ALGORITHM 2 B >> KEK_KEY_LENGTH 3 B >> KEK_KEY_LIFETIME 4 V >> SIG_HASH_ALGORITHM 5 B >> SIG_ALGORITHM 6 B >> SIG_KEY_LENGTH 7 B >> RESERVED 8 B >> Standards Action 9-127 >> Private Use 128-255 >> Unassigned 256-32767 >>=20 >> The KEK_ALGORITHM, SIG_ALGORITHM attributes MUST be included; = others >> are OPTIONAL, and included depending on group policy. The >> KEK_MANAGEMENT_ALGORITHM attribute MUST NOT be included in a >> GROUPKEY-PULL message, and MUST be ignored if present. >>=20 >>>=20 >>> #14) Sec 5.3.1: >>>=20 >>> The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a >>> GROUPKEY-PULL message. >>>=20 >>> What happens if it's included in the PUSH message? >>=20 >> See above. >>=20 >>>=20 >>> #15) Just noted to instances of GROUPKEY_. Aren't they supposed to = be GROUPKEY-*? >>>=20 >>> #16) Sec 5.3.3.3: r/as recommended in/as defined in >>>=20 >>> #17) Sec 5.3.6: Any reason not to point to FIPS 180-3? >>>=20 >>> #18) Sec 5.3.6: r/and SIG_HASH_ALGORITHM is not required to be = present in a SAK Payload/and SIG_HASH_ALGORITHM is OPTIONAL in a SAK = Payload >>>=20 >>> #19) Sec 5.3.7: Does anybody really want RSA-PSS? >>=20 >> Not that we know of, but we thought this was esteemed to be better = than PKCS 1.5 and so the protocol should support it. Is that not the = current thinking?a >>=20 >>>=20 >>> #20) Sec 5.4: r/Must/MUST >>> r/Section 3.3 of RFC 2408./Section 3.3 of [RFC2408]. >>>=20 >>> #21) Sec 5.4.1: r/ Section 4.2.1 of RFC 5374/Section 4.2.1 of = [RFC5374] >>> r/should/SHOULD X2 ?? >>=20 >> The second should is advice. How does this sound? "The values of ATD = and DTD are independent. However, the most effective policy will have = the DTD value to be the larger value as this allows new SAs to be = activated before older SAs are deactivated." >>=20 >>> #22) Sec 5.5: r/Must/MUST >>>=20 >>> #23) Sec 5.5.1: Protocol, SEC ID Port, DST ID Prot, DST ID Port = bullets r/should/SHOULD ? >>=20 >> These "should"s ought to be "MUST"s to ensure interoperability. E.g., = "Value specifying a port associated with the source Id. A value of zero = means that the SRC ID Port field MUST be ignored." >>>=20 >>> #24) Sec 5.5.1: r/from RFC 2407/from [RFC2407] >>> r/[RFC2407],/[RFC2407]), >>> r/ESP must also/ESP MUST also >>>=20 >>> #25) Sec 1.3: Add GSPD >>>=20 >>> #26) Sec 5.5.1.1.1: r/ RFC 5374/[RFC5374] >>>=20 >>> #27) Sec 5.5.1.1.1: r/must/MUST ? >>=20 >> This is less of a requirement than an explanation. How about: >>=20 >> Applications use the extensions in [RFC5374] to copy the IP = addresses >> into the outer IP header when encapsulating an IP packet as an = IPsec >> tunnel mode packet. This allows an IP multicast packet to = continue >> to be routed as a IP multicast packet. This attribute also = provides >> the necessary policy so that the GDOI group member can = appropriately >> set up the GSPD. >>=20 >>>=20 >>> #28) Sec 5.5.1.1.1: In the following, is 2119 language needed: >>>=20 >>> SA TEK payload >>> may be required in one or both directions. >>>=20 >>> #29) Sec 5.5.2: r/All Security Protocols must provide/All Security = Protocols MUST provide >>>=20 >>> #30) Sec 5.6.1: r/The attributes must follow/The attributes MUST = follow >>> r/At least one TEK must be/At least one TEK MUST be >>>=20 >>> #31) Sec 5.6.1.2: r/to the member./to the GM. >>>=20 >>> #32) Sec 5.6.2 and 5.6.3: r/The attributes must follow/The = attributes MUST follow >>>=20 >>> #33) Sec 5.6.3 and 5.6.3.1: r/there must be only/there MUST be only >>>=20 >>> #34) Sec 5.6.3.1 and 5.6.3.2: r/Must/MUST >>>=20 >>> #35) Sec 1.3: add SSIV >>>=20 >>> #36) Sec 5.7: r/Must/MUST >>> r/must/MUST X3 >>>=20 >>> #37) Sec 5.9: r/must be deleted, they must be/are to be deleted, = they MUST be >>>=20 >>> #38) Sec 10: References for 2403, 2404, 2407-2409, 3447, 4106, 4543, = 4754, 4868, 5903 are normative according to the following: = http://www.ietf.org/iesg/statement/normative-informative.html >>=20 >> Thanks for the pointer to the definitive statement ... I'll = re-evaluate all of the Informative references against it. >>=20 >>>=20 >>> Assuming you delete App A, remove references to 4330 and 5996. >>>=20 >>> Please ensure the classification of the other references are in = accordance with the IESG statement. If you've got any questions, let me = know. I don't want to find out later that some informative reference to = an informative RFC is actually a normative reference and we need to do a = 2nd IETF LC to note the DOWNREF. >>>=20 >>> I still need to finish Section 7 and 8. >>=20 >> Looking forward to this review, thanks. >>=20 >> Brian >>=20 >>>=20 >>> spt >>>=20 >>>=20 >>> On 3/31/11 12:14 PM, Vincent Roca wrote: >>>> Hello everybody, >>>>=20 >>>> As you probably noticed the GDOI draft has been significantly >>>> updated WRT the previous 07 version. For details see: >>>>=20 >>>> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-msec-gdoi-update-08.txt >>>>=20 >>>> This situation motivates another WGLC. So please review >>>>=20 >>>> draft-ietf-msec-gdoi-update-08 >>>> http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ >>>>=20 >>>> and send comments to the WG mailing list by April 18th. >>>> (NB: if ever this deadline is too close, then tell me...) >>>>=20 >>>> Regards, >>>>=20 >>>> Vincent >>>> _______________________________________________ >>>> MSEC mailing list >>>> MSEC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/msec >>>>=20 >>> _______________________________________________ >>> MSEC mailing list >>> MSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/msec >>=20 >>=20 --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From bew@cisco.com Mon Apr 18 14:49:07 2011 Return-Path: X-Original-To: msec@ietfc.amsl.com Delivered-To: msec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 02BC0E067C for ; Mon, 18 Apr 2011 14:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G14-Q24ERcck for ; Mon, 18 Apr 2011 14:49:05 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id DB367E066F for ; Mon, 18 Apr 2011 14:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=15102; q=dns/txt; s=iport; t=1303163344; x=1304372944; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=pEJJr5q17PLioAGcP4xzCL4mQZxqZEnqtj1XFEIA3BU=; b=HcZHh0dR4P/YixfCGoM9grtXpw0UMmXEsMXupA6XNuPoK/nEvOHoz426 w/PQJ2Zry9/2NGR/KTMiy+A6+PTsgXa6QoFIEcc/ibj1wz/gCOPeYbpTt WeJKEVQG9GPQOeQAG6QIdM9F0eIAYBRBbHEc3E4MVvt1npb8NdDn4fySI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALGwrE2rRDoH/2dsb2JhbAClQXeIb6ECjUWPEYMZglgEhWKIHg X-IronPort-AV: E=Sophos;i="4.64,235,1301875200"; d="scan'208";a="340027196" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 18 Apr 2011 21:49:04 +0000 Received: from dhcp-128-107-151-48.cisco.com (dhcp-128-107-151-48.cisco.com [128.107.151.48]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3ILn341023655; Mon, 18 Apr 2011 21:49:04 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <4DACAC1E.2060007@ieca.com> Date: Mon, 18 Apr 2011 14:49:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <43744E87-1B86-4A4C-A940-84613709CBE3@cisco.com> References: <4D94540D.1060605@inrialpes.fr> <4D975866.9070102@ieca.com> <4DAC9D93.6070508@ieca.com> <55C09EDE-9F52-4F08-9B91-FB0BA5ADA882@cisco.com> <4DACAC1E.2060007@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1082) Cc: msec@ietf.org Subject: Re: [MSEC] WGLC on draft-ietf-msec-gdoi-update-08 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 21:49:07 -0000 On Apr 18, 2011, at 2:24 PM, Sean Turner wrote: > On 4/18/11 5:09 PM, Brian Weis wrote: >> Hi Sean, >>=20 >> On Apr 18, 2011, at 1:22 PM, Sean Turner wrote: >>=20 >>> Brian, >>>=20 >>> The changes you suggest look okay to me. >>>=20 >>> As for RSA-PSS, yes the current advice is that it's "better" BUT it = requires some interesting things like: >>> - Parameters: With RSA v1.5 the parameters are NULL. With RSA-PSS = they're are a bunch things you need to specify: hash algorithm, mask = generation algorithm, salt length, and trailer field. >>=20 >> Thanks for the clarification. But if there are "a bunch of things you = need to specify", then to get an interoperable solution I guess we'd = need to specify them. :-) If that's the case, I'd rather take it out = (given the lack of current RSS-PSS usage). >=20 > To be fair there's a set of defaults defined in the standard so if you = were going to add RSA-PSS then you'd need to point to those defaults. If = nobody is asking for it though .... OK ... sounds like more work than its worth, and as no one is asking for = it I propose to remove it as you originally suggested. Thanks, Brian >=20 >> Thanks, >> Brian >>=20 >>> - Certificate: Your certificate is going to be different because you = need to carry these parameters. Not sure any CA is actually issuing = RSA-PSS certificates. >>>=20 >>> I think people are just going to skip it and go straight to ECDSA. = I guess it's okay to leave it in there for completeness because there's = no requirement to support it. >>>=20 >>> I'll get on to the last sections today. >>>=20 >>> spt >>>=20 >>> On 4/18/11 1:14 PM, Brian Weis wrote: >>>> Hi Sean, >>>>=20 >>>> Thanks for the comprehensive review ... good points, all. I've = comments on a few of them inline below. >>>>=20 >>>> On Apr 2, 2011, at 10:09 AM, Sean Turner wrote: >>>>=20 >>>>> #1) Add "updates: 3547 (once approved)" to the header. This will = make it match the intro/abstract. I can almost guarantee a discuss from = somebody on this. >>>>>=20 >>>>> #2) ISAKMP Phase 1 is described in Section 2.1 as "one such = mechanism". This isn't a MUST support. As far as I can tell there = isn't a MUST implement Phase 1 protocol (the protocols in Appendix A are = also just examples). But, to implement this document you've got to do = things as described in RFC 2407-2409. It seems like this doc and IKEv1 = are pretty well intertwined. And, the g-ikev2 draft doesn't use these = formats it uses something else...Let's be clear about what it's being = used with. It seems like this section ought to be changed as follows: >>>>>=20 >>>>> OLD: >>>>>=20 >>>>> The following sections describe one such "phase 1" protocol. = Other >>>>> protocols which may be potential "phase 1" protocols are = described in >>>>> Appendix A. However, the use of the protocols listed there are = not >>>>> considered part of this document. >>>>>=20 >>>>> 2.1. ISAKMP Phase 1 protocol >>>>>=20 >>>>> This document defines how the ISAKMP phase 1 exchanges as defined = in >>>>> [RFC2409] can be used a "phase 1" protocol for GDOI. The = following >>>>> sections define characteristics of the ISAKMP phase 1 protocols = that >>>>> are unique for these exchanges when used for GDOI. >>>>>=20 >>>>> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the >>>>> requirements of a GDOI "phase 1" protocol. >>>>>=20 >>>>> NEW: >>>>>=20 >>>>> This document defines how the ISAKMP phase 1 exchanges as defined = in >>>>> [RFC2409] can be used a "phase 1" protocol for GDOI. The = following >>>>> sections define characteristics of the ISAKMP phase 1 protocols = that >>>>> are unique for these exchanges when used for GDOI. >>>>>=20 >>>>> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the >>>>> requirements of a GDOI "phase 1" protocol. >>>>>=20 >>>>>=20 >>>>> Delete the 2.1 header and renumber 2.1.1 and 2.1.2 to 2.1 and 2.2, = respectively. >>>>>=20 >>>>> I would also delete Appendix A. The currently proposed IKEv2 = mechanism isn't reusing these fields and the KINK option never got = defined. >>>>=20 >>>> Removing this text in Section 2 and Appendix A make a lot of sense. = The concerns that caused them to be added to RFC 3547 have probably = dissolved. >>>>=20 >>>>>=20 >>>>> #3) Sec 3.2: r/Hashes are computed in the manner described within = RFC 2409./Hashes are computed in the manner described within [RFC2409]. >>>>>=20 >>>>> #4) Sec 3.2: expand prf on first use. >>>>>=20 >>>>> #5) Sec 3.3: 2 lower case "must" should they be "MUST"? >>>>> 1 lower case "should" should it be "SHOULD"? >>>>=20 >>>> These need to be reworded for clarity. >>>>=20 >>>> first must: "Before a GM contacts the GCKS, it must determine the = group identifier and acceptable Phase 1 policy via an out-of-band = method." This is less of a requirement than stating a pre-requisite. We = propose replacing "must" with "needs to". >>>>=20 >>>> second must/should: "If the SEQ payload is present, the sequence = number in the SEQ payload must be checked against any previously = received sequence number for this group. If it is less than the = previously received number, it should be considered stale and ignored." = The requirement is actually this: "If the SEQ payload is present, the = sequence number included in the SEQ payload MUST be greater than any = previously received sequence number. If it is less than the previously = received number, it MUST be considered stale and ignored." >>>>=20 >>>>>=20 >>>>> #6) Sec 4.2: Something is wrong with this: >>>>>=20 >>>>> Flags MUST have the Encryption bit set according to [RFC2008, = Section >>>>> 3.1]. >>>>>=20 >>>>> Maybe it should be: >>>>>=20 >>>>> Flags MUST have the Encryption bit set according to Section 3.1 = of >>>>> [RFC2408]. >>>>>=20 >>>>> #7) Sec 5: r/in accordance with RFC 2408./in accordance with = [RFC2408]. >>>>>=20 >>>>> #8) Sec 5.1, 5.2: r/defined in RFC 2408./defined in [RFC2408]. >>>>>=20 >>>>> #9) Sec 5.2: This is difficult to parse: >>>>>=20 >>>>> The >>>>> next payload MUST NOT be a SAK Payload or SAT Payload type, but = the >>>>> next non-Security Association type payload. >>>>>=20 >>>>> Maybe it's supposed to be: >>>>>=20 >>>>> The >>>>> next payload MUST NOT be a SAK Payload or SAT Payload type; it = MUST >>>>> be the >>>>> next non-Security Association type payload. >>>>>=20 >>>>> #9) Sec 5.2: r/Must/MUST X4 >>>>>=20 >>>>> #10) Sec 5.2.1: r/SA Attributes payloads must be/SA Attributes = payloads MUST be >>>>>=20 >>>>> #11) Sec 5.3: r/Must/MUST X2 >>>>> r/should/SHOULD >>>>=20 >>>> The "should" ought to be a "MUST" to ensure interoperability. = "Value specifying a port associated with the source Id. A value of zero = means that the SRC ID Port field MUST be ignored." >>>>=20 >>>>> r/must/MUST >>>>>=20 >>>>> #12) Sec 5.3: What is the conformance requirement for the = following: >>>>>=20 >>>>> Any or all attributes may be optional, depending on the group = policy. >>>>=20 >>>>>=20 >>>>> #13) Sec 5.3.1: >>>>>=20 >>>>> r/ attributes may be present / attributes MAY be present or = change to say they are OPTIONAL. >>>>>=20 >>>>> r/attributes must/attributes MUST >>>>=20 >>>> OK, some cleanup is in order. We propose removing heading 5.3.1 to = make the attribute definition part of 5.3, which is more natural. Then = there needs to be a description of what attributes are required, with = the rest being OPTIONAL (i.e., included if the group policy has included = it). >>>>=20 >>>> How about: >>>>=20 >>>> o KEK Attributes -- Contains KEK policy attributes associated = with >>>> the group. The following attributes may be present in a SAK = Payload. >>>> The attributes must follow the format defined in ISAKMP (Section = 3.3 >>>> of [RFC2408]). In the table, attributes that are defined as TV = are >>>> marked as Basic (B); attributes that are defined as TLV are = marked as >>>> Variable (V). >>>>=20 >>>>=20 >>>> ID Class Value Type >>>> -------- ----- ---- >>>> RESERVED 0 >>>> KEK_MANAGEMENT_ALGORITHM 1 B >>>> KEK_ALGORITHM 2 B >>>> KEK_KEY_LENGTH 3 B >>>> KEK_KEY_LIFETIME 4 V >>>> SIG_HASH_ALGORITHM 5 B >>>> SIG_ALGORITHM 6 B >>>> SIG_KEY_LENGTH 7 B >>>> RESERVED 8 B >>>> Standards Action 9-127 >>>> Private Use 128-255 >>>> Unassigned 256-32767 >>>>=20 >>>> The KEK_ALGORITHM, SIG_ALGORITHM attributes MUST be included; = others >>>> are OPTIONAL, and included depending on group policy. The >>>> KEK_MANAGEMENT_ALGORITHM attribute MUST NOT be included in a >>>> GROUPKEY-PULL message, and MUST be ignored if present. >>>>=20 >>>>>=20 >>>>> #14) Sec 5.3.1: >>>>>=20 >>>>> The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a >>>>> GROUPKEY-PULL message. >>>>>=20 >>>>> What happens if it's included in the PUSH message? >>>>=20 >>>> See above. >>>>=20 >>>>>=20 >>>>> #15) Just noted to instances of GROUPKEY_. Aren't they supposed = to be GROUPKEY-*? >>>>>=20 >>>>> #16) Sec 5.3.3.3: r/as recommended in/as defined in >>>>>=20 >>>>> #17) Sec 5.3.6: Any reason not to point to FIPS 180-3? >>>>>=20 >>>>> #18) Sec 5.3.6: r/and SIG_HASH_ALGORITHM is not required to be = present in a SAK Payload/and SIG_HASH_ALGORITHM is OPTIONAL in a SAK = Payload >>>>>=20 >>>>> #19) Sec 5.3.7: Does anybody really want RSA-PSS? >>>>=20 >>>> Not that we know of, but we thought this was esteemed to be better = than PKCS 1.5 and so the protocol should support it. Is that not the = current thinking?a >>>>=20 >>>>>=20 >>>>> #20) Sec 5.4: r/Must/MUST >>>>> r/Section 3.3 of RFC 2408./Section 3.3 of [RFC2408]. >>>>>=20 >>>>> #21) Sec 5.4.1: r/ Section 4.2.1 of RFC 5374/Section 4.2.1 of = [RFC5374] >>>>> r/should/SHOULD X2 ?? >>>>=20 >>>> The second should is advice. How does this sound? "The values of = ATD and DTD are independent. However, the most effective policy will = have the DTD value to be the larger value as this allows new SAs to be = activated before older SAs are deactivated." >>>>=20 >>>>> #22) Sec 5.5: r/Must/MUST >>>>>=20 >>>>> #23) Sec 5.5.1: Protocol, SEC ID Port, DST ID Prot, DST ID Port = bullets r/should/SHOULD ? >>>>=20 >>>> These "should"s ought to be "MUST"s to ensure interoperability. = E.g., "Value specifying a port associated with the source Id. A value of = zero means that the SRC ID Port field MUST be ignored." >>>>>=20 >>>>> #24) Sec 5.5.1: r/from RFC 2407/from [RFC2407] >>>>> r/[RFC2407],/[RFC2407]), >>>>> r/ESP must also/ESP MUST also >>>>>=20 >>>>> #25) Sec 1.3: Add GSPD >>>>>=20 >>>>> #26) Sec 5.5.1.1.1: r/ RFC 5374/[RFC5374] >>>>>=20 >>>>> #27) Sec 5.5.1.1.1: r/must/MUST ? >>>>=20 >>>> This is less of a requirement than an explanation. How about: >>>>=20 >>>> Applications use the extensions in [RFC5374] to copy the IP = addresses >>>> into the outer IP header when encapsulating an IP packet as an = IPsec >>>> tunnel mode packet. This allows an IP multicast packet to = continue >>>> to be routed as a IP multicast packet. This attribute also = provides >>>> the necessary policy so that the GDOI group member can = appropriately >>>> set up the GSPD. >>>>=20 >>>>>=20 >>>>> #28) Sec 5.5.1.1.1: In the following, is 2119 language needed: >>>>>=20 >>>>> SA TEK payload >>>>> may be required in one or both directions. >>>>>=20 >>>>> #29) Sec 5.5.2: r/All Security Protocols must provide/All Security = Protocols MUST provide >>>>>=20 >>>>> #30) Sec 5.6.1: r/The attributes must follow/The attributes MUST = follow >>>>> r/At least one TEK must be/At least one TEK MUST be >>>>>=20 >>>>> #31) Sec 5.6.1.2: r/to the member./to the GM. >>>>>=20 >>>>> #32) Sec 5.6.2 and 5.6.3: r/The attributes must follow/The = attributes MUST follow >>>>>=20 >>>>> #33) Sec 5.6.3 and 5.6.3.1: r/there must be only/there MUST be = only >>>>>=20 >>>>> #34) Sec 5.6.3.1 and 5.6.3.2: r/Must/MUST >>>>>=20 >>>>> #35) Sec 1.3: add SSIV >>>>>=20 >>>>> #36) Sec 5.7: r/Must/MUST >>>>> r/must/MUST X3 >>>>>=20 >>>>> #37) Sec 5.9: r/must be deleted, they must be/are to be deleted, = they MUST be >>>>>=20 >>>>> #38) Sec 10: References for 2403, 2404, 2407-2409, 3447, 4106, = 4543, 4754, 4868, 5903 are normative according to the following: = http://www.ietf.org/iesg/statement/normative-informative.html >>>>=20 >>>> Thanks for the pointer to the definitive statement ... I'll = re-evaluate all of the Informative references against it. >>>>=20 >>>>>=20 >>>>> Assuming you delete App A, remove references to 4330 and 5996. >>>>>=20 >>>>> Please ensure the classification of the other references are in = accordance with the IESG statement. If you've got any questions, let me = know. I don't want to find out later that some informative reference to = an informative RFC is actually a normative reference and we need to do a = 2nd IETF LC to note the DOWNREF. >>>>>=20 >>>>> I still need to finish Section 7 and 8. >>>>=20 >>>> Looking forward to this review, thanks. >>>>=20 >>>> Brian >>>>=20 >>>>>=20 >>>>> spt >>>>>=20 >>>>>=20 >>>>> On 3/31/11 12:14 PM, Vincent Roca wrote: >>>>>> Hello everybody, >>>>>>=20 >>>>>> As you probably noticed the GDOI draft has been significantly >>>>>> updated WRT the previous 07 version. For details see: >>>>>>=20 >>>>>> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-msec-gdoi-update-08.txt >>>>>>=20 >>>>>> This situation motivates another WGLC. So please review >>>>>>=20 >>>>>> draft-ietf-msec-gdoi-update-08 >>>>>> http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ >>>>>>=20 >>>>>> and send comments to the WG mailing list by April 18th. >>>>>> (NB: if ever this deadline is too close, then tell me...) >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Vincent >>>>>> _______________________________________________ >>>>>> MSEC mailing list >>>>>> MSEC@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/msec >>>>>>=20 >>>>> _______________________________________________ >>>>> MSEC mailing list >>>>> MSEC@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/msec >>>>=20 >>>>=20 >>=20 >>=20 --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From bew@cisco.com Mon Apr 18 15:12:24 2011 Return-Path: X-Original-To: msec@ietfc.amsl.com Delivered-To: msec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7E904E06A4 for ; Mon, 18 Apr 2011 15:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.419 X-Spam-Level: X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+Vf4OBk6taO for ; Mon, 18 Apr 2011 15:12:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id AB690E0660 for ; Mon, 18 Apr 2011 15:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=9316; q=dns/txt; s=iport; t=1303164742; x=1304374342; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=MP04wg8ugs3IQ4hzhcbDWvrDclFej3BINecMz22Wp3c=; b=ia5+tJ09jj5VIQ3pSmbUrqOv1NERKMBlnFPN0nDXxOepEEi2gLkcM9gD ngSQc8clW8bVS2KcjJsCl0gvZhuUCtUmxUo/89P6AjRoJHOKxGQ/cirw/ zYT2GAu+qOKwn+qGJ6HSS71X0vdqgDZqfd9tfaAbep3dIsKNdIBJhKfg3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABq2rE2rRDoI/2dsb2JhbAClQHeIb6EAnFiDGYJYBIViiB4 X-IronPort-AV: E=Sophos;i="4.64,235,1301875200"; d="scan'208";a="683486525" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 18 Apr 2011 22:12:21 +0000 Received: from dhcp-128-107-151-48.cisco.com (dhcp-128-107-151-48.cisco.com [128.107.151.48]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3IMCLUu027904; Mon, 18 Apr 2011 22:12:21 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Weis In-Reply-To: <4DACA51F.5090300@ieca.com> Date: Mon, 18 Apr 2011 15:12:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D94540D.1060605@inrialpes.fr> <4D975866.9070102@ieca.com> <4DACA51F.5090300@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1082) Cc: msec@ietf.org Subject: Re: [MSEC] WGLC on draft-ietf-msec-gdoi-update-08 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 22:12:24 -0000 Hi Sean, On Apr 18, 2011, at 1:54 PM, Sean Turner wrote: > Here's the rest of my comments on Sections 7 and 8 (all in 8): >=20 > Section 5.3.7 shows TBD-6 to 9 but the second paragraph in 8.1 only = discussed TBD-6. The others should be added in 8.1. >=20 > Section 5.6 shows TBD-7 and so does Section 8.1, but there's already a = TBD-7 in Section 5.3.7. Maybe renumber the one in Section 5.6 TBD-10? I also noticed these issues when removing RSA-PSS. The TBD-7 in Section = 5.3.7 became TBD-6, and the rest retain their original numbering. = Section 8.1 was also brought up to date. > Section 8.2: In the new registries, you need to say what needs to be = done to update the registries (e.g., specification required, standards = action). Vincent also has pointed this out. But Section 8 that says: "When the new registries are added, the following terms are to be applied as described in the Guidelines for Writing an IANA Considerations Section in RFCs [RFC5226]: Standards Action, and Private Use." =46rom RFC 5226: Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG. Private Use: Private use only (not assigned), as described in = Section 4.1. I'm not sure how to be state this more clearly, but it seems as if = that's needed. Suggestions are welcome. Thanks, Brian >=20 > spt >=20 > On 4/2/11 1:09 PM, Sean Turner wrote: >> #1) Add "updates: 3547 (once approved)" to the header. This will make = it >> match the intro/abstract. I can almost guarantee a discuss from = somebody >> on this. >>=20 >> #2) ISAKMP Phase 1 is described in Section 2.1 as "one such = mechanism". >> This isn't a MUST support. As far as I can tell there isn't a MUST >> implement Phase 1 protocol (the protocols in Appendix A are also just >> examples). But, to implement this document you've got to do things as >> described in RFC 2407-2409. It seems like this doc and IKEv1 are = pretty >> well intertwined. And, the g-ikev2 draft doesn't use these formats it >> uses something else...Let's be clear about what it's being used with. = It >> seems like this section ought to be changed as follows: >>=20 >> OLD: >>=20 >> The following sections describe one such "phase 1" protocol. Other >> protocols which may be potential "phase 1" protocols are described in >> Appendix A. However, the use of the protocols listed there are not >> considered part of this document. >>=20 >> 2.1. ISAKMP Phase 1 protocol >>=20 >> This document defines how the ISAKMP phase 1 exchanges as defined in >> [RFC2409] can be used a "phase 1" protocol for GDOI. The following >> sections define characteristics of the ISAKMP phase 1 protocols that >> are unique for these exchanges when used for GDOI. >>=20 >> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the >> requirements of a GDOI "phase 1" protocol. >>=20 >> NEW: >>=20 >> This document defines how the ISAKMP phase 1 exchanges as defined in >> [RFC2409] can be used a "phase 1" protocol for GDOI. The following >> sections define characteristics of the ISAKMP phase 1 protocols that >> are unique for these exchanges when used for GDOI. >>=20 >> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the >> requirements of a GDOI "phase 1" protocol. >>=20 >>=20 >> Delete the 2.1 header and renumber 2.1.1 and 2.1.2 to 2.1 and 2.2, >> respectively. >>=20 >> I would also delete Appendix A. The currently proposed IKEv2 = mechanism >> isn't reusing these fields and the KINK option never got defined. >>=20 >> #3) Sec 3.2: r/Hashes are computed in the manner described within RFC >> 2409./Hashes are computed in the manner described within [RFC2409]. >>=20 >> #4) Sec 3.2: expand prf on first use. >>=20 >> #5) Sec 3.3: 2 lower case "must" should they be "MUST"? >> 1 lower case "should" should it be "SHOULD"? >>=20 >> #6) Sec 4.2: Something is wrong with this: >>=20 >> Flags MUST have the Encryption bit set according to [RFC2008, Section >> 3.1]. >>=20 >> Maybe it should be: >>=20 >> Flags MUST have the Encryption bit set according to Section 3.1 of >> [RFC2408]. >>=20 >> #7) Sec 5: r/in accordance with RFC 2408./in accordance with = [RFC2408]. >>=20 >> #8) Sec 5.1, 5.2: r/defined in RFC 2408./defined in [RFC2408]. >>=20 >> #9) Sec 5.2: This is difficult to parse: >>=20 >> The >> next payload MUST NOT be a SAK Payload or SAT Payload type, but the >> next non-Security Association type payload. >>=20 >> Maybe it's supposed to be: >>=20 >> The >> next payload MUST NOT be a SAK Payload or SAT Payload type; it MUST >> be the >> next non-Security Association type payload. >>=20 >> #9) Sec 5.2: r/Must/MUST X4 >>=20 >> #10) Sec 5.2.1: r/SA Attributes payloads must be/SA Attributes = payloads >> MUST be >>=20 >> #11) Sec 5.3: r/Must/MUST X2 >> r/should/SHOULD >> r/must/MUST >>=20 >> #12) Sec 5.3: What is the conformance requirement for the following: >>=20 >> Any or all attributes may be optional, depending on the group policy. >>=20 >> #13) Sec 5.3.1: >>=20 >> r/ attributes may be present / attributes MAY be present or change to >> say they are OPTIONAL. >>=20 >> r/attributes must/attributes MUST >>=20 >> #14) Sec 5.3.1: >>=20 >> The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a >> GROUPKEY-PULL message. >>=20 >> What happens if it's included in the PUSH message? >>=20 >> #15) Just noted to instances of GROUPKEY_. Aren't they supposed to be >> GROUPKEY-*? >>=20 >> #16) Sec 5.3.3.3: r/as recommended in/as defined in >>=20 >> #17) Sec 5.3.6: Any reason not to point to FIPS 180-3? >>=20 >> #18) Sec 5.3.6: r/and SIG_HASH_ALGORITHM is not required to be = present >> in a SAK Payload/and SIG_HASH_ALGORITHM is OPTIONAL in a SAK Payload >>=20 >> #19) Sec 5.3.7: Does anybody really want RSA-PSS? >>=20 >> #20) Sec 5.4: r/Must/MUST >> r/Section 3.3 of RFC 2408./Section 3.3 of [RFC2408]. >>=20 >> #21) Sec 5.4.1: r/ Section 4.2.1 of RFC 5374/Section 4.2.1 of = [RFC5374] >> r/should/SHOULD X2 ?? >>=20 >> #22) Sec 5.5: r/Must/MUST >>=20 >> #23) Sec 5.5.1: Protocol, SEC ID Port, DST ID Prot, DST ID Port = bullets >> r/should/SHOULD ? >>=20 >> #24) Sec 5.5.1: r/from RFC 2407/from [RFC2407] >> r/[RFC2407],/[RFC2407]), >> r/ESP must also/ESP MUST also >>=20 >> #25) Sec 1.3: Add GSPD >>=20 >> #26) Sec 5.5.1.1.1: r/ RFC 5374/[RFC5374] >>=20 >> #27) Sec 5.5.1.1.1: r/must/MUST ? >>=20 >> #28) Sec 5.5.1.1.1: In the following, is 2119 language needed: >>=20 >> SA TEK payload >> may be required in one or both directions. >>=20 >> #29) Sec 5.5.2: r/All Security Protocols must provide/All Security >> Protocols MUST provide >>=20 >> #30) Sec 5.6.1: r/The attributes must follow/The attributes MUST = follow >> r/At least one TEK must be/At least one TEK MUST be >>=20 >> #31) Sec 5.6.1.2: r/to the member./to the GM. >>=20 >> #32) Sec 5.6.2 and 5.6.3: r/The attributes must follow/The attributes >> MUST follow >>=20 >> #33) Sec 5.6.3 and 5.6.3.1: r/there must be only/there MUST be only >>=20 >> #34) Sec 5.6.3.1 and 5.6.3.2: r/Must/MUST >>=20 >> #35) Sec 1.3: add SSIV >>=20 >> #36) Sec 5.7: r/Must/MUST >> r/must/MUST X3 >>=20 >> #37) Sec 5.9: r/must be deleted, they must be/are to be deleted, they >> MUST be >>=20 >> #38) Sec 10: References for 2403, 2404, 2407-2409, 3447, 4106, 4543, >> 4754, 4868, 5903 are normative according to the following: >> http://www.ietf.org/iesg/statement/normative-informative.html >>=20 >> Assuming you delete App A, remove references to 4330 and 5996. >>=20 >> Please ensure the classification of the other references are in >> accordance with the IESG statement. If you've got any questions, let = me >> know. I don't want to find out later that some informative reference = to >> an informative RFC is actually a normative reference and we need to = do a >> 2nd IETF LC to note the DOWNREF. >>=20 >> I still need to finish Section 7 and 8. >>=20 >> spt >>=20 >>=20 >> On 3/31/11 12:14 PM, Vincent Roca wrote: >>> Hello everybody, >>>=20 >>> As you probably noticed the GDOI draft has been significantly >>> updated WRT the previous 07 version. For details see: >>>=20 >>> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-msec-gdoi-update-08.txt >>>=20 >>> This situation motivates another WGLC. So please review >>>=20 >>> draft-ietf-msec-gdoi-update-08 >>> http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ >>>=20 >>> and send comments to the WG mailing list by April 18th. >>> (NB: if ever this deadline is too close, then tell me...) >>>=20 >>> Regards, >>>=20 >>> Vincent >>> _______________________________________________ >>> MSEC mailing list >>> MSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/msec >>>=20 >> _______________________________________________ >> MSEC mailing list >> MSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/msec >>=20 > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From turners@ieca.com Tue Apr 19 05:43:04 2011 Return-Path: X-Original-To: msec@ietfc.amsl.com Delivered-To: msec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5FE31E0663 for ; Tue, 19 Apr 2011 05:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Is3lsGcAGnBW for ; Tue, 19 Apr 2011 05:43:02 -0700 (PDT) Received: from nm12.bullet.mail.ac4.yahoo.com (nm12.bullet.mail.ac4.yahoo.com [98.139.52.209]) by ietfc.amsl.com (Postfix) with SMTP id C38D6E0691 for ; Tue, 19 Apr 2011 05:43:02 -0700 (PDT) Received: from [98.139.52.193] by nm12.bullet.mail.ac4.yahoo.com with NNFMP; 19 Apr 2011 12:43:00 -0000 Received: from [98.139.52.146] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 19 Apr 2011 12:43:00 -0000 Received: from [127.0.0.1] by omp1029.mail.ac4.yahoo.com with NNFMP; 19 Apr 2011 12:43:00 -0000 X-Yahoo-Newman-Id: 43295.14492.bm@omp1029.mail.ac4.yahoo.com Received: (qmail 45693 invoked from network); 19 Apr 2011 12:43:00 -0000 Received: from thunderfish.local (turners@96.231.127.8 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 19 Apr 2011 05:42:57 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: d6VkIjsVM1lfq_bI6eEuNeZFoZ.jMwUa9GW5F06kDL7ISnQ tHbP1Fd9ld_Jbks5RniOZE0bLol61JuAjTeYgD6guvQ0GhNzSe4Y0t.Q2AEw H6iHznRQpopxNupewmGl_fOJh09V7WmYqSwQ9lqsPgCzVoXjcqtPFXIiMdB9 Dh_OX7WUrM8LXLszYSSNEhQTKHb.QN5hdvvajMu_affEc80V0tVFpS..nixI uL19vmHyVdzY_MGoWaKdyY7wxbFDrQ.z.JJ32iH5awXQlnBWjJ.rucbv8UG3 g5sFMbNY3ISK8bT.RJ8s_aKY6agb.BKDMdsb.sSnvhzmmPqLH1afMjGFWS0O Hmrww6otXIFUo X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DAD8351.4090303@ieca.com> Date: Tue, 19 Apr 2011 08:42:57 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian Weis References: <4D94540D.1060605@inrialpes.fr> <4D975866.9070102@ieca.com> <4DACA51F.5090300@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@ietf.org Subject: Re: [MSEC] WGLC on draft-ietf-msec-gdoi-update-08 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 12:43:04 -0000 On 4/18/11 6:12 PM, Brian Weis wrote: > Hi Sean, > > On Apr 18, 2011, at 1:54 PM, Sean Turner wrote: > >> Here's the rest of my comments on Sections 7 and 8 (all in 8): >> >> Section 5.3.7 shows TBD-6 to 9 but the second paragraph in 8.1 only discussed TBD-6. The others should be added in 8.1. >> >> Section 5.6 shows TBD-7 and so does Section 8.1, but there's already a TBD-7 in Section 5.3.7. Maybe renumber the one in Section 5.6 TBD-10? > > I also noticed these issues when removing RSA-PSS. The TBD-7 in Section 5.3.7 became TBD-6, and the rest retain their original numbering. Section 8.1 was also brought up to date. > >> Section 8.2: In the new registries, you need to say what needs to be done to update the registries (e.g., specification required, standards action). > > Vincent also has pointed this out. But Section 8 that says: > > "When the new > registries are added, the following terms are to be applied as > described in the Guidelines for Writing an IANA Considerations > Section in RFCs [RFC5226]: Standards Action, and Private Use." > > From RFC 5226: > > Standards Action - Values are assigned only for Standards Track > RFCs approved by the IESG. > Private Use: Private use only (not assigned), as described in Section 4.1. > > I'm not sure how to be state this more clearly, but it seems as if that's needed. Suggestions are welcome. Brian, The only thing I can think to do is to move the text from 8 to 8.2 and repeat it for each of the new registries. spt >> spt >> >> On 4/2/11 1:09 PM, Sean Turner wrote: >>> #1) Add "updates: 3547 (once approved)" to the header. This will make it >>> match the intro/abstract. I can almost guarantee a discuss from somebody >>> on this. >>> >>> #2) ISAKMP Phase 1 is described in Section 2.1 as "one such mechanism". >>> This isn't a MUST support. As far as I can tell there isn't a MUST >>> implement Phase 1 protocol (the protocols in Appendix A are also just >>> examples). But, to implement this document you've got to do things as >>> described in RFC 2407-2409. It seems like this doc and IKEv1 are pretty >>> well intertwined. And, the g-ikev2 draft doesn't use these formats it >>> uses something else...Let's be clear about what it's being used with. It >>> seems like this section ought to be changed as follows: >>> >>> OLD: >>> >>> The following sections describe one such "phase 1" protocol. Other >>> protocols which may be potential "phase 1" protocols are described in >>> Appendix A. However, the use of the protocols listed there are not >>> considered part of this document. >>> >>> 2.1. ISAKMP Phase 1 protocol >>> >>> This document defines how the ISAKMP phase 1 exchanges as defined in >>> [RFC2409] can be used a "phase 1" protocol for GDOI. The following >>> sections define characteristics of the ISAKMP phase 1 protocols that >>> are unique for these exchanges when used for GDOI. >>> >>> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the >>> requirements of a GDOI "phase 1" protocol. >>> >>> NEW: >>> >>> This document defines how the ISAKMP phase 1 exchanges as defined in >>> [RFC2409] can be used a "phase 1" protocol for GDOI. The following >>> sections define characteristics of the ISAKMP phase 1 protocols that >>> are unique for these exchanges when used for GDOI. >>> >>> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the >>> requirements of a GDOI "phase 1" protocol. >>> >>> >>> Delete the 2.1 header and renumber 2.1.1 and 2.1.2 to 2.1 and 2.2, >>> respectively. >>> >>> I would also delete Appendix A. The currently proposed IKEv2 mechanism >>> isn't reusing these fields and the KINK option never got defined. >>> >>> #3) Sec 3.2: r/Hashes are computed in the manner described within RFC >>> 2409./Hashes are computed in the manner described within [RFC2409]. >>> >>> #4) Sec 3.2: expand prf on first use. >>> >>> #5) Sec 3.3: 2 lower case "must" should they be "MUST"? >>> 1 lower case "should" should it be "SHOULD"? >>> >>> #6) Sec 4.2: Something is wrong with this: >>> >>> Flags MUST have the Encryption bit set according to [RFC2008, Section >>> 3.1]. >>> >>> Maybe it should be: >>> >>> Flags MUST have the Encryption bit set according to Section 3.1 of >>> [RFC2408]. >>> >>> #7) Sec 5: r/in accordance with RFC 2408./in accordance with [RFC2408]. >>> >>> #8) Sec 5.1, 5.2: r/defined in RFC 2408./defined in [RFC2408]. >>> >>> #9) Sec 5.2: This is difficult to parse: >>> >>> The >>> next payload MUST NOT be a SAK Payload or SAT Payload type, but the >>> next non-Security Association type payload. >>> >>> Maybe it's supposed to be: >>> >>> The >>> next payload MUST NOT be a SAK Payload or SAT Payload type; it MUST >>> be the >>> next non-Security Association type payload. >>> >>> #9) Sec 5.2: r/Must/MUST X4 >>> >>> #10) Sec 5.2.1: r/SA Attributes payloads must be/SA Attributes payloads >>> MUST be >>> >>> #11) Sec 5.3: r/Must/MUST X2 >>> r/should/SHOULD >>> r/must/MUST >>> >>> #12) Sec 5.3: What is the conformance requirement for the following: >>> >>> Any or all attributes may be optional, depending on the group policy. >>> >>> #13) Sec 5.3.1: >>> >>> r/ attributes may be present / attributes MAY be present or change to >>> say they are OPTIONAL. >>> >>> r/attributes must/attributes MUST >>> >>> #14) Sec 5.3.1: >>> >>> The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a >>> GROUPKEY-PULL message. >>> >>> What happens if it's included in the PUSH message? >>> >>> #15) Just noted to instances of GROUPKEY_. Aren't they supposed to be >>> GROUPKEY-*? >>> >>> #16) Sec 5.3.3.3: r/as recommended in/as defined in >>> >>> #17) Sec 5.3.6: Any reason not to point to FIPS 180-3? >>> >>> #18) Sec 5.3.6: r/and SIG_HASH_ALGORITHM is not required to be present >>> in a SAK Payload/and SIG_HASH_ALGORITHM is OPTIONAL in a SAK Payload >>> >>> #19) Sec 5.3.7: Does anybody really want RSA-PSS? >>> >>> #20) Sec 5.4: r/Must/MUST >>> r/Section 3.3 of RFC 2408./Section 3.3 of [RFC2408]. >>> >>> #21) Sec 5.4.1: r/ Section 4.2.1 of RFC 5374/Section 4.2.1 of [RFC5374] >>> r/should/SHOULD X2 ?? >>> >>> #22) Sec 5.5: r/Must/MUST >>> >>> #23) Sec 5.5.1: Protocol, SEC ID Port, DST ID Prot, DST ID Port bullets >>> r/should/SHOULD ? >>> >>> #24) Sec 5.5.1: r/from RFC 2407/from [RFC2407] >>> r/[RFC2407],/[RFC2407]), >>> r/ESP must also/ESP MUST also >>> >>> #25) Sec 1.3: Add GSPD >>> >>> #26) Sec 5.5.1.1.1: r/ RFC 5374/[RFC5374] >>> >>> #27) Sec 5.5.1.1.1: r/must/MUST ? >>> >>> #28) Sec 5.5.1.1.1: In the following, is 2119 language needed: >>> >>> SA TEK payload >>> may be required in one or both directions. >>> >>> #29) Sec 5.5.2: r/All Security Protocols must provide/All Security >>> Protocols MUST provide >>> >>> #30) Sec 5.6.1: r/The attributes must follow/The attributes MUST follow >>> r/At least one TEK must be/At least one TEK MUST be >>> >>> #31) Sec 5.6.1.2: r/to the member./to the GM. >>> >>> #32) Sec 5.6.2 and 5.6.3: r/The attributes must follow/The attributes >>> MUST follow >>> >>> #33) Sec 5.6.3 and 5.6.3.1: r/there must be only/there MUST be only >>> >>> #34) Sec 5.6.3.1 and 5.6.3.2: r/Must/MUST >>> >>> #35) Sec 1.3: add SSIV >>> >>> #36) Sec 5.7: r/Must/MUST >>> r/must/MUST X3 >>> >>> #37) Sec 5.9: r/must be deleted, they must be/are to be deleted, they >>> MUST be >>> >>> #38) Sec 10: References for 2403, 2404, 2407-2409, 3447, 4106, 4543, >>> 4754, 4868, 5903 are normative according to the following: >>> http://www.ietf.org/iesg/statement/normative-informative.html >>> >>> Assuming you delete App A, remove references to 4330 and 5996. >>> >>> Please ensure the classification of the other references are in >>> accordance with the IESG statement. If you've got any questions, let me >>> know. I don't want to find out later that some informative reference to >>> an informative RFC is actually a normative reference and we need to do a >>> 2nd IETF LC to note the DOWNREF. >>> >>> I still need to finish Section 7 and 8. >>> >>> spt >>> >>> >>> On 3/31/11 12:14 PM, Vincent Roca wrote: >>>> Hello everybody, >>>> >>>> As you probably noticed the GDOI draft has been significantly >>>> updated WRT the previous 07 version. For details see: >>>> >>>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-msec-gdoi-update-08.txt >>>> >>>> This situation motivates another WGLC. So please review >>>> >>>> draft-ietf-msec-gdoi-update-08 >>>> http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ >>>> >>>> and send comments to the WG mailing list by April 18th. >>>> (NB: if ever this deadline is too close, then tell me...) >>>> >>>> Regards, >>>> >>>> Vincent >>>> _______________________________________________ >>>> MSEC mailing list >>>> MSEC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/msec >>>> >>> _______________________________________________ >>> MSEC mailing list >>> MSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/msec >>> >> _______________________________________________ >> MSEC mailing list >> MSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/msec > > From lewisc@cisco.com Fri Apr 22 10:26:11 2011 Return-Path: X-Original-To: msec@ietfc.amsl.com Delivered-To: msec@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C742CE06E9 for ; Fri, 22 Apr 2011 10:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcVhClnFKSec for ; Fri, 22 Apr 2011 10:26:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 84291E065A for ; Fri, 22 Apr 2011 10:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lewisc@cisco.com; l=9064; q=dns/txt; s=iport; t=1303493169; x=1304702769; h=mime-version:subject:date:message-id:from:to; bh=1UGnKjfcKgrRGn/5DSylmO8OrO5lsZrL1mBhH1ie4Uo=; b=DAWMe/HdZpCMpRE8upRmtvQfeuIDSFoYTh3hj7HStgUEMkh4RqJQlbXy cuGboPS3q5OfykiY6hqfBqlM9pWOUtdtfT8vAP5N9iberuflGdxrV/HYi ms+AjWXKyqAB1x6tJITUN9aBMjhpCk+zbTgq2Xw254EuezfIKBFF3s4KP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcIAGG5sU2rRDoJ/2dsb2JhbACCYpUvhgwBhz93qHScTYV2BIV0jEc X-IronPort-AV: E=Sophos;i="4.64,254,1301875200"; d="scan'208,217";a="434969689" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 22 Apr 2011 17:26:07 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3MHQ7ZA006521 for ; Fri, 22 Apr 2011 17:26:07 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 10:26:07 -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_01CC0112.5D31211C" Date: Fri, 22 Apr 2011 10:26:05 -0700 Message-ID: <4BC25C77619B1F4C870E08C2D78B475B0D3467E8@xmb-sjc-234.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regarding GDOI GM rekey "receive window" Thread-Index: AcwBElwY472FEFlKSYG1+JzM0DDOrg== From: "Lewis Chen (lewisc)" To: X-OriginalArrivalTime: 22 Apr 2011 17:26:07.0449 (UTC) FILETIME=[5D5FA490:01CC0112] Subject: [MSEC] Regarding GDOI GM rekey "receive window" X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 17:26:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0112.5D31211C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/html/draft-ietf-msec-gdoi-update-08 =20 In Section 5.7 (Sequence Number Payload), it mentions the following: "The current value of the sequence number must be transmitted to group members as a part of the Registration SA payload. A group member must keep a sliding receive window. The window must be treated as in the ESP protocol [RFC4303 ] Section =20 3.4.3 ." =20 =20 In GDOI, implementing a sliding receive window for group member (GM) is risky because the rekey message contains relative SA lifetimes in it. Thus, GM accepting old rekey (due to the sliding receive window) may install SAs that are no longer part of the group policy, or will be used by the group member after the group policy changes. Therefore, group member should only accept a rekey message with a sequence number value larger than any previously received sequence number. =20 =20 In fact, in Section 7.3.4(Replay/Reflection Attack Protection), it describe the correct rekey acceptance criteria as below. =20 =20 " The GROUPKEY-PUSH message includes a monotonically increasing sequence number to protect against replay and reflection attacks. A group member will discard sequence numbers associated with the current KEK SPI that have the same or lower value as the most recently received replay number." =20 =20 =20 Thanks, Lewis =20 =20 =20 ------_=_NextPart_001_01CC0112.5D31211C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http:/= /tools.ietf.org/html/draft-ietf-msec-gdoi-update-08=

 

In Section 5.7 (Sequence Number Payload), it mentions the = following:

“The current value of the =
sequence number
   must be transmitted to =
group members as a part of the Registration =
SA
   payload.  A group member must =
keep a sliding receive window.  =
The
   window must be treated as in the =
ESP protocol [RFC4303] Section
   3.4.3.”
 
 

In = GDOI, implementing a sliding receive window for group member (GM) =  is risky because the rekey message contains relative SA lifetimes = in it. Thus, GM accepting old rekey (due to the sliding receive window) = may install SAs that are no longer part of the group policy, or will be = used by the group member after the group policy changes.  Therefore,  group member = should only accept a rekey message with a sequence number value larger = than any previously received sequence number.

 

 

In = fact, in Section 7.3.4(Replay/Reflection Attack = Protection), it describe the correct rekey acceptance criteria as = below.

 
 <=
/o:p>
  “ The GROUPKEY-PUSH message includes a =
monotonically increasing
   sequence =
number to protect against replay and reflection attacks.  =
A
   group member will discard sequence =
numbers associated with the
   current =
KEK SPI that have the same or lower value as the =
most
   recently received replay =
number.”
 
&nbs=
p;
 
Thanks,
Lewis

 

 

 

------_=_NextPart_001_01CC0112.5D31211C-- From bew@cisco.com Wed Apr 27 11:36:26 2011 Return-Path: X-Original-To: msec@ietfa.amsl.com Delivered-To: msec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085E9E07C9 for ; Wed, 27 Apr 2011 11:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFtJON96-sWI for ; Wed, 27 Apr 2011 11:36:25 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBBEE076A for ; Wed, 27 Apr 2011 11:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=14107; q=dns/txt; s=iport; t=1303929384; x=1305138984; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=U85bHKAmw80teFg+iRlcNZDgJO2J4hwuGC7I0qKkNUc=; b=idWc8COW9rrUcPsPMKJAO7Vc9mGjWhBexOySEXoVnswgwTsGFBg7XKTd 8GlxjSoXq0ZM0RrfbPUGW5x8+p9Q4+KaF+6GfUlbf3phx5sAELl+fVeVK yLXEirY1pps70iDBmYpwq6fv3pGVGvWq8fQ2pOT9XWIRECq2+GK9wlgYV k=; X-IronPort-AV: E=Sophos;i="4.64,275,1301875200"; d="scan'208,217";a="688194258" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 27 Apr 2011 18:36:24 +0000 Received: from npanitch-w2k.cisco.com (npanitch-w2k.cisco.com [128.107.147.73]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RIaO0F017434; Wed, 27 Apr 2011 18:36:24 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6--795329397 From: Brian Weis In-Reply-To: <4BC25C77619B1F4C870E08C2D78B475B0D3467E8@xmb-sjc-234.amer.cisco.com> Date: Wed, 27 Apr 2011 11:36:24 -0700 Message-Id: References: <4BC25C77619B1F4C870E08C2D78B475B0D3467E8@xmb-sjc-234.amer.cisco.com> To: Lewis Chen (lewisc) X-Mailer: Apple Mail (2.1084) Cc: msec@ietf.org Subject: Re: [MSEC] Regarding GDOI GM rekey "receive window" X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 18:36:26 -0000 --Apple-Mail-6--795329397 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Lewis, Thanks for pointing this out ... in the absence of any objections we'll = plan to fix this in the next version of the I-D. Brian On Apr 22, 2011, at 10:26 AM, Lewis Chen (lewisc) wrote: > http://tools.ietf.org/html/draft-ietf-msec-gdoi-update-08 > =20 > In Section 5.7 (Sequence Number Payload), it mentions the following: >=20 > =93The current value of the sequence number > must be transmitted to group members as a part of the Registration = SA > payload. A group member must keep a sliding receive window. The > window must be treated as in the ESP protocol [RFC4303] Section > 3.4.3.=94 > =20 > =20 > In GDOI, implementing a sliding receive window for group member (GM) = is risky because the rekey message contains relative SA lifetimes in it. = Thus, GM accepting old rekey (due to the sliding receive window) may = install SAs that are no longer part of the group policy, or will be used = by the group member after the group policy changes. Therefore, group = member should only accept a rekey message with a sequence number value = larger than any previously received sequence number. > =20 > =20 > In fact, in Section 7.3.4(Replay/Reflection Attack Protection), it = describe the correct rekey acceptance criteria as below. > =20 > =20 > =93 The GROUPKEY-PUSH message includes a monotonically increasing > sequence number to protect against replay and reflection attacks. = A > group member will discard sequence numbers associated with the > current KEK SPI that have the same or lower value as the most > recently received replay number.=94 > =20 > =20 > =20 > Thanks, > Lewis > =20 >=20 > =20 > =20 > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --Apple-Mail-6--795329397 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Lewis,

Thanks for pointing = this out ... in the absence of any objections we'll plan to fix this in = the next version of the = I-D.

Brian

On Apr = 22, 2011, at 10:26 AM, Lewis Chen (lewisc) wrote:

In = Section 5.7 (Sequence Number Payload), = it mentions the following:

=93The current value of =
the sequence number
   must be transmitted to =
group members as a part of the Registration SA
   window must be treated =
as in the ESP protocol [RFC4303]     
In GDOI, implementing a =
sliding receive window for group member (GM)  is risky because the =
rekey message contains relative SA lifetimes in it. Thus, GM accepting =
old rekey (due to the sliding receive window) may install SAs that are =
no longer part of the group policy, or will be used by the group member =
after the group policy changes.  Therefore, =
 group member should only accept a rekey message with a sequence =
number value larger than any previously received sequence =
number.
In fact, in = Section 7.3.4(Replay/Reflection Attack = Protection), it describe the correct rekey acceptance criteria as = below.
 
  =93 The GROUPKEY-PUSH message =
includes a monotonically increasing
   group member will =
discard sequence numbers associated with the
   recently received replay =
number.=94
 
 
Lewis

 

bew@cisco.com





= --Apple-Mail-6--795329397--