From wwwrun@rfc-editor.org Tue Apr 6 15:13:11 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 C09BA3A69E5; Tue, 6 Apr 2010 15:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 0VVpc7Xlj0kJ; Tue, 6 Apr 2010 15:13:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id D24D13A6933; Tue, 6 Apr 2010 15:13:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D6863E07AC; Tue, 6 Apr 2010 15:13:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100406221302.D6863E07AC@rfc-editor.org> Date: Tue, 6 Apr 2010 15:13:02 -0700 (PDT) Cc: msec@ietf.org, rfc-editor@rfc-editor.org Subject: [MSEC] RFC 5776 on Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols 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: Tue, 06 Apr 2010 22:13:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5776 Title: Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols Author: V. Roca, A. Francillon, S. Faurite Status: Experimental Stream: IETF Date: April 2010 Mailbox: vincent.roca@inria.fr, aurelien.francillon@inria.fr, faurite@lcpc.fr Pages: 58 Characters: 135605 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-msec-tesla-for-alc-norm-10.txt URL: http://www.rfc-editor.org/rfc/rfc5776.txt This document details the Timed Efficient Stream %Loss-Tolerant Authentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. This document defines an Experimental Protocol for the Internet community. This document is a product of the Multicast Security Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From ynir@checkpoint.com Thu Apr 8 04:35:35 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 4EF4A3A6A48 for ; Thu, 8 Apr 2010 04:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9xAfHK0GeU5 for ; Thu, 8 Apr 2010 04:35:34 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id D52053A6882 for ; Thu, 8 Apr 2010 04:35:28 -0700 (PDT) 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 o38BZJPq005242 for ; Thu, 8 Apr 2010 14:35:19 +0300 (IDT) X-CheckPoint: {4BBDCD6A-0-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 8 Apr 2010 14:35:40 +0300 From: Yoav Nir To: "msec@ietf.org" Date: Thu, 8 Apr 2010 14:35:19 +0300 Thread-Topic: GDOI Update draft Thread-Index: AcrXD51FGrPU4+WUSVup1dU1lXQUzA== Message-ID: <0D25F037-3741-4C0F-902B-7D829393C633@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0D25F03737414C0F902B7D829393C633checkpointcom_" MIME-Version: 1.0 Subject: [MSEC] GDOI Update draft X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 11:35:35 -0000 --_000_0D25F03737414C0F902B7D829393C633checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi. As I promised at the meeting, I will review this draft thoroughly, but I al= ready have two comments 1. It was said in the meeting (although it's not written in the draft) th= at none of the known implementations have implemented the PFS extension, an= d so it is dropped. This is incorrect. I have checked Check Point's impleme= ntation, and it does, in fact, implement the PFS feature. What the draft sa= ys, in appendix B, is that it provides negligible value, and that the speci= fication is faulty. These statements are true. Much as I'd hate to deprecate running code from my own company, I agree wit= h the reasoning in appendix B, so I'm fine with it being deprecated. 2. The document is missing a conformance requirements section. Although t= here is some conformance language in the various sections, like DES is SHOU= LD NOT, and AES-CBC-128 is MUST, the document is missing a centralized list= of what is required, as opposed to optional, or not recommended. I would = suggest the following: KEK_MANAGEMENT_ALGORITHM * LKH - MUST (?) KEK_ALGORITHM * DES - SHOULD NOT * 3DES - SHOULD * AES - MUST SIG_HASH_ALGORITHM * MD5 - MUST NOT * SHA1 - SHOULD NOT * SHA256 - MUST (BTW: why do you have to specify this at all? With RSA, you're using the P= KCS#1.5 format that encodes the hash algorithm anyways, so why negotiate it= ?) SIG_ALGORITHM * RSA - MUST protocol * ESP - MUST * AH - MAY Key download type * are all three types mandatory? And so on. Anyway, I do promise to read this throughly soon. Yoav --_000_0D25F03737414C0F902B7D829393C633checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi.

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

  1. It was said in the meeting (although it's not written in the draft) th= at none of the known implementations have implemented the PFS extension, an= d so it is dropped. This is incorrect. I have checked Check Point's impleme= ntation, and it does, in fact, implement the PFS feature. What the draft sa= ys, in appendix B, is that it provides negligible value, and that the speci= fication is faulty. These statements are true.  
    Much as= I'd hate to deprecate running code from my own company, I agree with the r= easoning in appendix B, so I'm fine with it being deprecated.

  2. The document is missing a conformance requirements= section. Although there is some conformance language in the various sectio= ns, like DES is SHOULD NOT, and AES-CBC-128 is MUST, the document is missin= g a centralized list of what is required, as opposed to optional, or not re= commended.  I would suggest the following:
KEK_MANAGEMENT_ALGORITHM
  • LKH - MUST  (?)

=
KEK_ALGORITHM
  • DES - SHOU= LD NOT
  • 3DES - SHOULD
  • AES - MUST

SIG_HASH_ALGORITHM
  • MD5 - MUST NOT=
  • SHA1 - SHOULD NOT
  • SHA256 - MUST
(BTW: why do= you have to specify this at all?  With RSA, you're using the PKCS#1.5= format that encodes the hash algorithm anyways, so why negotiate it?)

SIG_ALGORITHM
  • = RSA - MUST

protocol
  • ESP - MUST
  • AH - MAY

Key = download type
  • are all three types m= andatory?

And so on.

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

= Yoav



= --_000_0D25F03737414C0F902B7D829393C633checkpointcom_-- From john.mattsson@ericsson.com Thu Apr 8 14:55:08 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 C19F23A6897 for ; Thu, 8 Apr 2010 14:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 l11vu7CIwkye for ; Thu, 8 Apr 2010 14:55:08 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3FA5F3A698E for ; Thu, 8 Apr 2010 14:55:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-00-4bbe50b55f96 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id CD.3B.23532.5B05EBB4; Thu, 8 Apr 2010 23:55:01 +0200 (CEST) Received: from ESESSCMS0357.eemea.ericsson.se ([169.254.1.187]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 8 Apr 2010 23:55:02 +0200 From: John Mattsson To: "msec@ietf.org" Date: Thu, 8 Apr 2010 23:55:01 +0200 Thread-Topic: Draft update: draft-mattsson-mikey-ticket-03 Thread-Index: AQHK12Yj/rt35BMSbEquveHxEIaxdg== Message-ID: 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 X-Brightmail-Tracker: AAAAAA== Subject: [MSEC] Draft update: draft-mattsson-mikey-ticket-03 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: Thu, 08 Apr 2010 21:55:08 -0000 Dear all, We have submitted an updated version of the draft "MIKEY-TICKET: An Additio= nal Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)". This n= ew version is updated based on the comments received during the IETF last c= all. http://www.ietf.org/id/draft-mattsson-mikey-ticket-03.txt Best regards, John Mattsson From wwwrun@rfc-editor.org Fri Apr 9 04:49:45 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 E87C13A6998 for ; Fri, 9 Apr 2010 04:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 GgEwrGZ7HUVM for ; Fri, 9 Apr 2010 04:49:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 22C103A6990 for ; Fri, 9 Apr 2010 04:49:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C89E7E0717; Fri, 9 Apr 2010 04:49:41 -0700 (PDT) To: vincent.roca@inria.fr, aurelien.francillon@inria.fr, faurite@lcpc.fr, turners@ieca.com, tim.polk@nist.gov, bew@cisco.com, vincent.roca@inria.fr From: RFC Errata System Message-Id: <20100409114941.C89E7E0717@rfc-editor.org> Date: Fri, 9 Apr 2010 04:49:41 -0700 (PDT) Cc: msec@ietf.org, ah@TR-Sys.de, rfc-editor@rfc-editor.org Subject: [MSEC] [Technical Errata Reported] RFC5776 (2155) 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: Fri, 09 Apr 2010 11:49:46 -0000 The following errata report has been submitted for RFC5776, "Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5776&eid=2155 -------------------------------------- Type: Technical Reported by: ALfred Hoenes Section: 6.2.1,pg.52 Original Text ------------- | o direct time synchronization response: Upon receiving a response, a receiver who has no pending request MUST immediately drop the packet. If this receiver has previously issued a request, he | first checks the Group MAC (if applicable), then the "t_r" field, | to be sure it is a response to his request, and finally the digital signature. A replayed packet will be dropped during these verifications, without compromising the TESLA component. Corrected Text -------------- | o Direct time synchronization response: Upon receiving a response, a receiver who has no pending request MUST immediately drop the packet. If this receiver has previously issued a request, he | first checks the "t_r" field, to be sure it is a response to his | request, then the Group MAC (if applicable), and finally the digital signature. A replayed packet will be dropped during these verifications, without compromising the TESLA component. Notes ----- Rationale: a) [supplemental, editorial] capitalization after preceding full stop; b) conflict with reasonable specification in section 4.2.2.1: the "t_r" field match with an 'open' request is a very lightweight operation, and an attacker needs to be on-path and fast or *very* lucky to happen to pass this check; so performing the more costly Group MAC verification operation _only_ if the packet "t_r" matches an open request significantly reduces the workload an attacker can impose on the receiver; thus, the order of operations specified in Section 4.2.2.1 is an important detail of the overall anti-DoS strategy and should not be contradicted by the Security Considerations section. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5776 (draft-ietf-msec-tesla-for-alc-norm-10) -------------------------------------- Title : Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols Publication Date : April 2010 Author(s) : V. Roca, A. Francillon, S. Faurite Category : EXPERIMENTAL Source : Multicast Security Area : Security Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Apr 9 05:26:38 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 E22B53A6A49 for ; Fri, 9 Apr 2010 05:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 T6gyP6IgwVA7 for ; Fri, 9 Apr 2010 05:26:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 32B863A6A48 for ; Fri, 9 Apr 2010 05:26:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B77E5E0717; Fri, 9 Apr 2010 05:26:34 -0700 (PDT) To: vincent.roca@inria.fr, aurelien.francillon@inria.fr, faurite@lcpc.fr, turners@ieca.com, tim.polk@nist.gov, bew@cisco.com, vincent.roca@inria.fr From: RFC Errata System Message-Id: <20100409122634.B77E5E0717@rfc-editor.org> Date: Fri, 9 Apr 2010 05:26:34 -0700 (PDT) Cc: msec@ietf.org, ah@TR-Sys.de, rfc-editor@rfc-editor.org Subject: [MSEC] [Editorial Errata Reported] RFC5776 (2156) 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: Fri, 09 Apr 2010 12:26:39 -0000 The following errata report has been submitted for RFC5776, "Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5776&eid=2156 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 3.3.2 Original Text ------------- [[ first paragraph ]] The bootstrap information message (with the in-band bootstrap scheme) | and direct time synchronization response message (with the indirect time synchronization scheme) both need to be signed by the sender. [...] Corrected Text -------------- The bootstrap information message (with the in-band bootstrap scheme) | and direct time synchronization response message (with the direct time synchronization scheme) both need to be signed by the sender. [...] Notes ----- Rationale: most likely a typo, but confusing: why would the _indirect_ schem use the _direct_ scheme's messages? Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5776 (draft-ietf-msec-tesla-for-alc-norm-10) -------------------------------------- Title : Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols Publication Date : April 2010 Author(s) : V. Roca, A. Francillon, S. Faurite Category : EXPERIMENTAL Source : Multicast Security Area : Security Stream : IETF Verifying Party : IESG From cyyeung@cisco.com Wed Apr 21 15:01:27 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 ECD603A6782 for ; Wed, 21 Apr 2010 15:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.602 X-Spam-Level: X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 qlkkRhM5CmgV for ; Wed, 21 Apr 2010 15:01:22 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 91DD13A6452 for ; Wed, 21 Apr 2010 15:01:22 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkHAPUSz0urR7H+/2dsb2JhbACBP5oJVGsGo1+aOoUOBIM0 X-IronPort-AV: E=Sophos;i="4.52,252,1270425600"; d="scan'208,217";a="219899039" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2010 22:01:13 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3LM1DqG014761 for ; Wed, 21 Apr 2010 22:01:13 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 15:01:13 -0700 Received: from 10.21.93.218 ([10.21.93.218]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Apr 2010 22:01:12 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 21 Apr 2010 15:01:11 -0700 From: Aldous Yeung To: "msec@ietf.org" Message-ID: Thread-Index: AcrhnicR6vd2rAeqok25QG9eKAnSGw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3354706871_4315687" X-OriginalArrivalTime: 21 Apr 2010 22:01:13.0197 (UTC) FILETIME=[286069D0:01CAE19E] Cc: Paulina Tran via prrq Subject: [MSEC] 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: Wed, 21 Apr 2010 22:01:27 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3354706871_4315687 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, The following are the answer to the questions asked during G-IKEv2 draft presentation: 1. Why do we define the GSA payload and not just use the IKEv2 SA payload? Answer: i. There is overhead in the IKEv2 SA payload structure that we don=B9t need. In G-IKEv2, the KS does not negotiate the group policies with the GM, but pushes the group policies to the GM. So, the whole proposal sub-structure is not needed. ii. Since the mechanism of G-IKEv2 is very similar to GDOI, the format of GSA payload is matched with the SA payload of GDOI. 2. Why do we redefine the SIG payload but not reuse AUTH payload in IKEv2 since the formats are the same? Answer: Good point, I am going to incorporate it in the next draft update, here wil= l be the changes: i. Section 4.11 will be replaced with description of the use of AUTH payload, instead of creating the new one. ii. Section 4.4.6, the name of the SIG_HASH_ALGORITHM will be changed to AUTH_HASH_ALGORITHM. iii. Section 4.4.7 to 4.4.8 will be removed as these will be covered by the IKEv2 registry. iv. All the references to the SIG payload will be replaced by AUTH payload. Feel free to let us know for more questions or feedback on the draft. Thanks, Aldous --B_3354706871_4315687 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi,

The following are the answer to the questions asked during G-IKEv2 draft pr= esentation:

1. Why do we define the GSA payload and not just use the IKEv2 SA payload?<= BR> Answer:
 i. There is overhead in the IKEv2 SA payload structure that we don= 217;t need.  In G-IKEv2, the KS does not negotiate the group policies w= ith the GM, but pushes the group policies to the GM.  So, the whole pro= posal sub-structure is not needed.
ii. Since the mechanism of G-IKEv2 is very similar to GDOI, the format of G= SA payload is matched with the SA payload of GDOI.

2. Why do we redefine the SIG payload but not reuse AUTH payload in IKEv2 s= ince the formats are the same?
Answer:
Good point, I am going to incorporate it in the next draft update, here wil= l be the changes:
i. Section 4.11 will be replaced with description of the use of AUTH payloa= d, instead of creating the new one.
ii. Section 4.4.6, the name of the SIG_HASH_ALGORITHM will be changed to AU= TH_HASH_ALGORITHM.
iii. Section 4.4.7 to 4.4.8 will be removed as these will be covered by the= IKEv2 registry.
iv. All the references to the SIG payload will be replaced by AUTH payload.=

Feel free to let us know for more questions or feedback on the draft.

Thanks,
Aldous --B_3354706871_4315687-- From bew@cisco.com Fri Apr 23 12:46:12 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 E9CE73A6A94 for ; Fri, 23 Apr 2010 12:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 5A78FkBSgA2s for ; Fri, 23 Apr 2010 12:46:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3C3253A6ACF for ; Fri, 23 Apr 2010 12:46:09 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkFAE6W0UurR7Hu/2dsb2JhbACQLowAcaRkmjOCcYIaBIM3 X-IronPort-AV: E=Sophos;i="4.52,263,1270425600"; d="scan'208";a="519712261" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 23 Apr 2010 19:45:53 +0000 Received: from dhcp-128-107-163-49.cisco.com (dhcp-128-107-163-49.cisco.com [128.107.163.49]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3NJjrSi015245 for ; Fri, 23 Apr 2010 19:45:53 GMT Message-Id: <09FC3E55-8022-4D42-83B0-42E338610DC5@cisco.com> From: Brian Weis To: msec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Apr 2010 12:45:50 -0700 X-Mailer: Apple Mail (2.936) Subject: [MSEC] Anaheim Minutes 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: Fri, 23 Apr 2010 19:46:12 -0000 Greetings, Minutes from the Anaheim meeting are now available: . Please send comments or corrections to the chairs: msec-chairs@tools.ietf.org . Thanks, Brian -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com