From ynir@checkpoint.com Mon Jun 7 09:41:26 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FC53A6BDB for ; Mon, 7 Jun 2010 09:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2] 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 70eKVDuALGj8 for ; Mon, 7 Jun 2010 09:41:24 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 4D48428CC77 for ; Mon, 7 Jun 2010 06:29:22 -0700 (PDT) X-CheckPoint: {4C0D0222-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o57DTMU8016763 for ; Mon, 7 Jun 2010 16:29:22 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 7 Jun 2010 16:29:50 +0300 From: Yoav Nir To: "msec@ietf.org" Date: Mon, 7 Jun 2010 16:29:48 +0300 Thread-Topic: Review of GDOI Update Thread-Index: AQHLBkWAE5iGuc1MY0Sx0dUr6uKczA== Message-ID: <006FEB08D9C6444AB014105C9AEB133FB49CC941E3@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MSEC] Review of GDOI Update 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: Mon, 07 Jun 2010 16:41:26 -0000 Hi all As I promised in Anaheim, I have reviewed the GDOI update draft.=20 The draft has most everything you need to implement GDOI, but I think the s= tructure of the document could be improved. The Introduction starts off wit= h a list of 5 new payloads. I believe that this could wait until section 5,= or at least 3 & 4. Also, that introduction uses terminology without having= defined it. For example: The new Phase 2 exchange, called "GROUPKEY-PULL," downloads keys for a group's "Re-key" SA and/or "Data-security" SA.=20 This is before anyone has defined what a "Re-key" SA is, or what a "Data-se= curity" SA is. Perhaps a terminology section would help here. Section 2 says that GDOI is a phase 2 protocol, which MUST be protected by = a phase 1 protocol. I think it should mention that only PULL exchanges are = actually protected by the phase 1. The push messages are protected by other= means. Section 2.1.2 says that port 848 has been assigned for GDOI. It doesn't say= if port 848 is used for PUSH, PULL, both, or also the phase 1. It also doe= sn't say why they didn't just re-use ports 500 and 4500 already assigned to= IKE. Section 3 says that a GROUPKEY-PULL exchange downloads TEK and/or KEK. What= 's missing at this point is a discussion about why we would download a TEK,= why a KEK, or why both. IOW it doesn't say what it means if the GROUPKEY-P= ULL contains one, the other, or both. Only in the middle of section 3.4 do = we first read the bracketed explanation below, and still there's not equiva= lent bracketed remark to tell us when a TEK will not be present: The GCKS constructs the second GDOI message, including a nonce Nr, and the policy for the group in an SA payload, followed by SA TEK payloads for traffic SAs, and SA KEK policy (if the group controller will be sending Re-key messages to the group). Section 3.2.1 says this: Cookies are used in the ISAKMP header as a weak form of denial of service protection. =20 Cookies are not any form of DoS protection. They're merely identifiers for = separating two IKE SAs, and that is why IKEv2 renamed them to "IKE SPIs". S= tateless cookies are a weak form of DoS protection, as described in section= 6.1.5. Section 3.4 says that KEK policy is included only if the GKCS will be sendi= ng Re-key messages to the group. It doesn't say what the alternative is. Is= it that only PULL messages will ever be used? Section 4.3 says that the GKCS SHOULD NOT use the same key to sign the SIG = payload in the PUSH as was used for authentication in the PULL. Why? Also, = section 4 doesn't specify what key is used to create the SIG payload. Secti= on 4.6 says "A CERT payload is added if the initiator needs to provide its = certificate." and section 4.7 says "The signature of the decrypted message = is then validated, possibly using the CERT payload if it is included." From= this I can infer that in a CERT payload is included we use the private key= associated with the public key in the certificate. But CERT is optional. W= hat do we use if it's not included? And when does the initiator need to pro= vide its certificate? The document is missing requirement levels, as in what algorithms MAY, SHOU= LD, or MUST be implemented. One way to add this, is to add a requirement le= vel column to the tables in section 5, kind of like those in RFC 4305. Section 5.3.6 says that SIG_HASH_MD5 and SIG_HASH_SHA1 SHOULD NOT be used. = IANAC but this seems wrong to me. The signature algorithms are used here to= sign messages created by the GKCS. The attack we're defending against is t= hat the attacker generate a rogue message with the same hash as a valid me= ssage, so that the signature on one is also appropriate for the other. But = this would require a 2nd pre-image attack on the hash function, and current= ly no such attacks exist for either MD5 or SHA1. This is different from the= case of certificates, where the same attacker generates both the valid and= rogue messages, so only a collision attack needs to be done. Also, the same section says that SIG_ALG_DSS and SIG_ALG_ECDSS imply SIG_HA= SH_SHA1. Why is this true? It's not any property of the algorithm that for= ces this. As an example, in RFC 4754 ECDSA signatures are defined to use a = hash function according to their key size, so ECDSA with the 256-bit random= ECP group uses SHA-256. Section 5.3.7.3 is about using ECDSA for digital signatures. It doesn't say= what curve to use. This may be redundant, because if the public key in inc= luded in a certificate, the certificate already tells you what curve is in = use. LKH: The introduction points to RFC 2627 for a definition of LKH. However, = that RFC does not contain either the LKH acronym or the name "Logical Key H= ierarchy". Also, I believe the use of LKH is under-specified. For example, = in section 5.6.3.1 in the description of the LKH key structure, we have "LK= H ID" which is supposed to be the "position" of this key in the binary tre= e structure. How is this position determined? Is it just some random ident= ifier like the letters in RFC 2627?. Also there's a "Key Handle", which is = randomly generated, and is used to "uniquely identify a key within an LKH I= D." When do we have more than one key in an LKH ID? When we rekey? And how= does a group member learn the LKH IDs of the nodes between it and the GKCS= ? Is it from the array in the PULL?=20 Minor nits: - In the introduction, we have "a Data-security SA includes a data encrypti= on key, or TEK". You probably want to say "traffic encryption key" - In section 3.2 (page 11 after the hash calculation) it says: "Note that n= onces are included in the first two exchanges, with the GCKS=85" This is a = mistake. The nonces are included in the first two *messages* of a single ex= change. - Section 5.6.3 says this: "The LKH key packet is comprised of attributes r= epresenting different leaves in the LKH key tree." I think you meant "nodes= " rather than "leaves" Yoav= From sheela@cisco.com Mon Jun 7 10:37:43 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7F928C264 for ; Mon, 7 Jun 2010 10:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.599 X-Spam-Level: X-Spam-Status: No, score=-12.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kcgE3KiDZh2 for ; Mon, 7 Jun 2010 10:37:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id AB13F3A6C64 for ; Mon, 7 Jun 2010 09:43:45 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADa+DEyrRN+J/2dsb2JhbACeJHGmQpoagliCPwSDSg X-IronPort-AV: E=Sophos;i="4.53,379,1272844800"; d="scan'208";a="260246306" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2010 16:43:46 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o57Ghjpv013193; Mon, 7 Jun 2010 16:43:46 GMT Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jun 2010 09:43:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jun 2010 09:43:43 -0700 Message-ID: <6B9C4B97B82F924485E26968EB05A6EE09AA64D1@xmb-sjc-224.amer.cisco.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB49CC941E3@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] Review of GDOI Update Thread-Index: AQHLBkWAE5iGuc1MY0Sx0dUr6uKczJJ2tHqQ References: <006FEB08D9C6444AB014105C9AEB133FB49CC941E3@il-ex01.ad.checkpoint.com> From: "Sheela Rowles (sheela)" To: "Yoav Nir" , X-OriginalArrivalTime: 07 Jun 2010 16:43:45.0080 (UTC) FILETIME=[983AAB80:01CB0660] Subject: Re: [MSEC] Review of GDOI Update 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: Mon, 07 Jun 2010 17:37:43 -0000 Thanks Yoav! I'll look through your comments and get back to you as soon as I can.=20 Thanks, Sheela -----Original Message----- From: msec-bounces@ietf.org [mailto:msec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Monday, June 07, 2010 6:30 AM To: msec@ietf.org Subject: [MSEC] Review of GDOI Update Hi all As I promised in Anaheim, I have reviewed the GDOI update draft.=20 The draft has most everything you need to implement GDOI, but I think the structure of the document could be improved. The Introduction starts off with a list of 5 new payloads. I believe that this could wait until section 5, or at least 3 & 4. Also, that introduction uses terminology without having defined it. For example: The new Phase 2 exchange, called "GROUPKEY-PULL," downloads keys for a group's "Re-key" SA and/or "Data-security" SA.=20 This is before anyone has defined what a "Re-key" SA is, or what a "Data-security" SA is. Perhaps a terminology section would help here. Section 2 says that GDOI is a phase 2 protocol, which MUST be protected by a phase 1 protocol. I think it should mention that only PULL exchanges are actually protected by the phase 1. The push messages are protected by other means. Section 2.1.2 says that port 848 has been assigned for GDOI. It doesn't say if port 848 is used for PUSH, PULL, both, or also the phase 1. It also doesn't say why they didn't just re-use ports 500 and 4500 already assigned to IKE. Section 3 says that a GROUPKEY-PULL exchange downloads TEK and/or KEK. What's missing at this point is a discussion about why we would download a TEK, why a KEK, or why both. IOW it doesn't say what it means if the GROUPKEY-PULL contains one, the other, or both. Only in the middle of section 3.4 do we first read the bracketed explanation below, and still there's not equivalent bracketed remark to tell us when a TEK will not be present: The GCKS constructs the second GDOI message, including a nonce Nr, and the policy for the group in an SA payload, followed by SA TEK payloads for traffic SAs, and SA KEK policy (if the group controller will be sending Re-key messages to the group). Section 3.2.1 says this: Cookies are used in the ISAKMP header as a weak form of denial of service protection. =20 Cookies are not any form of DoS protection. They're merely identifiers for separating two IKE SAs, and that is why IKEv2 renamed them to "IKE SPIs". Stateless cookies are a weak form of DoS protection, as described in section 6.1.5. Section 3.4 says that KEK policy is included only if the GKCS will be sending Re-key messages to the group. It doesn't say what the alternative is. Is it that only PULL messages will ever be used? Section 4.3 says that the GKCS SHOULD NOT use the same key to sign the SIG payload in the PUSH as was used for authentication in the PULL. Why? Also, section 4 doesn't specify what key is used to create the SIG payload. Section 4.6 says "A CERT payload is added if the initiator needs to provide its certificate." and section 4.7 says "The signature of the decrypted message is then validated, possibly using the CERT payload if it is included." From this I can infer that in a CERT payload is included we use the private key associated with the public key in the certificate. But CERT is optional. What do we use if it's not included? And when does the initiator need to provide its certificate? The document is missing requirement levels, as in what algorithms MAY, SHOULD, or MUST be implemented. One way to add this, is to add a requirement level column to the tables in section 5, kind of like those in RFC 4305. Section 5.3.6 says that SIG_HASH_MD5 and SIG_HASH_SHA1 SHOULD NOT be used. IANAC but this seems wrong to me. The signature algorithms are used here to sign messages created by the GKCS. The attack we're defending against is that the attacker generate a rogue message with the same hash as a valid message, so that the signature on one is also appropriate for the other. But this would require a 2nd pre-image attack on the hash function, and currently no such attacks exist for either MD5 or SHA1. This is different from the case of certificates, where the same attacker generates both the valid and rogue messages, so only a collision attack needs to be done. Also, the same section says that SIG_ALG_DSS and SIG_ALG_ECDSS imply SIG_HASH_SHA1. Why is this true? It's not any property of the algorithm that forces this. As an example, in RFC 4754 ECDSA signatures are defined to use a hash function according to their key size, so ECDSA with the 256-bit random ECP group uses SHA-256. Section 5.3.7.3 is about using ECDSA for digital signatures. It doesn't say what curve to use. This may be redundant, because if the public key in included in a certificate, the certificate already tells you what curve is in use. LKH: The introduction points to RFC 2627 for a definition of LKH. However, that RFC does not contain either the LKH acronym or the name "Logical Key Hierarchy". Also, I believe the use of LKH is under-specified. For example, in section 5.6.3.1 in the description of the LKH key structure, we have "LKH ID" which is supposed to be the "position" of this key in the binary tree structure. How is this position determined? Is it just some random identifier like the letters in RFC 2627?. Also there's a "Key Handle", which is randomly generated, and is used to "uniquely identify a key within an LKH ID." When do we have more than one key in an LKH ID? When we rekey? And how does a group member learn the LKH IDs of the nodes between it and the GKCS? Is it from the array in the PULL?=20 Minor nits: - In the introduction, we have "a Data-security SA includes a data encryption key, or TEK". You probably want to say "traffic encryption key" - In section 3.2 (page 11 after the hash calculation) it says: "Note that nonces are included in the first two exchanges, with the GCKS..." This is a mistake. The nonces are included in the first two *messages* of a single exchange. - Section 5.6.3 says this: "The LKH key packet is comprised of attributes representing different leaves in the LKH key tree." I think you meant "nodes" rather than "leaves" Yoav _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec