From paul.hoffman@vpnc.org Thu Oct 1 11:18:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158043A6ACF for ; Thu, 1 Oct 2009 11:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.186 X-Spam-Level: X-Spam-Status: No, score=-5.186 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Y+5pvC-T+xs7 for ; Thu, 1 Oct 2009 11:18:24 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 789A03A6ACC for ; Thu, 1 Oct 2009 11:18:24 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n91IJmnj097957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Oct 2009 11:19:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 1 Oct 2009 11:19:47 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Proposed minutes of the virtual meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 18:18:26 -0000 Sorry about the delay in getting these out. Please send any changes to the list. If you want to talk about a particular item that we discussed, **change the subject line to be something appropriate to the topic**. --Paul Hoffman IPsecME WG Interim Meeting 2009-09-22, across many different timezones Using TeamSpeak for voice Co-chaired by Yaron Sheffer and Paul Hoffman Minutes by Paul Hoffman Slides and agenda are at http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/Interim20090922 These minutes only cover things not in those slides Recording is at http://www.vpnc.org/IPsecMEinterim-2009-09.mp3 Attendees (virtual bluesheet): Dave Wierbowski Dragan Grebovich Gabriel Montenegro Guy Snyder Hannes Tschofenig Jean-Michel Combes Jouni Korhonen Julien Laganier Kalyani Garigipati Ken Grewal Michael Richardson Paul Hoffman Peny Yang Raj Richard Graveman Scott Moonen Sheila Frankel Tero Kivinen Yaron Sheffer Yoav Nir Agenda bash, document status Yaron and Paul This is an official interim, we follow the same rules as a regular f2f meeting Start with short reports on current documents, minus AES-CTR No changes or additions from the room draft-ietf-ipsecme-ikev2-redirect has been approved for RFC production draft-ietf-ipsecme-ikev2-ipv6-config is in AD review AES-CTR draft-ietf-ipsecme-aes-ctr-ikev2 Discussion by Yaron Is in WG Last Call Need more comments ESP-null heuristics draft-ietf-ipsecme-esp-null-heuristics Discussion by Tero There are a few more comments, there will be a revision Roadmap draft-ietf-ipsecme-roadmap Discussion by Sheila Combined algorithms for IKEv1 and IPsec-v2 Scott: thinks it's fine to do in IKEv1 Sheila: We can assume that we are using IKEv1 with the new IPsec Tero: Should be able to used. Sheila will add wording to make using IKEv1 less murky Does IKEv2 truncate its ICV? Scott: Some IKEv2 transforms are defined for both truncated and non-truncated forms Sheila: Can you negotiate either form? Scott: Yes Tero: Non-truncated version is mostly used only for FibreChannel Do whatever the negotiated algorith says Sheila: Should we put something in the doc about the two forms? Paul: Yes, add a clarification, and we should add that clarification in IKEv2bis Paul: Keep moving, don't wait for IKEv2bis Use of AES-XCBC in IKE Paul: It sounds like RFC 4109 needs to be revised Yaron: Roadmap should say that it is currently undefined Say that it is a bug in the spec Internet Drafts included in roadmap BEET has encountered resistance in the IETF, and it might be abandoned What about expired drafts that will never become RFCs Some were not progressed because of security concerns Tero: If you implement road warrior with IKEv1, you have to support both drafts Most support some version of the drafts Hannes: Maybe this means this should be an Informational RFC Tero: But there are serious security problems If people move to IKEv2 we don't need these Adding some pointer to the drafts, but think hard before implementing them Say "there is a good reason why they are expired" Paul: Not true that everyone needs to implement them. VPNC sees only about half the vendors have implemented them. Worse, people have implemented them incorrectly for what they indicate they are doing There were other ways of doing XAUTH that did get into implementations Say "There have been various ways of doing configuration and extended auth" But don't list any drafts Michael: We have to mention them and say that they were bad, the ideas are in IKEv2 Would like th see the two drafts put somewhere and listed as "do not implmement" Yaron: Supports Tero's position, do need to metion them by name Tero: Wants a big warning that they are not safe to implement Sheila: Will add text to mention the problems in the IKEv1 description Paul: We will need a second WGLC on these issues anyway Camellia for IKEv2 :undefined (no RFC) Tero: We use the same IANA numbers for IPsec and IKEv2 You get the IKEv2 number automatically Hopes that the combined mode doc for ESP can be used in IKEv2 IKEv2 tells how to use CBC, and the same for combined mode Wanted this for the AES-CTR Paul: Concern for making CTR generic is that we can only do it for what we know today People can write short documents if they want a CTR mode for a function Tero: The Camellia people failed to make their document specific enough for IKEv2 Wants to limit the number of RFCs for cipher Paul: Agree that we don't want separate drafts for ESP and IKEv2 Disagree about wanting to limit the number of RFCs Yaron: Are there others? Tero: No Yaron: Then let's leave the AES-CTR alone and let the Camellia people do their own thing We need to open each of these issues in the issue tracker No formal WGLC again, but need to close out the new issues Then have a new document and go to AD Will reformat the document to help make following specific documents easier Session resumption draft-ietf-ipsecme-ikev2-resumption Discussion by Yaron Peny: Understands that resumption detection is out of scope Maybe we can have more text to discuss the risks of not detecting resumption Paul: Wants specific wording sent to the list so we can decide if it should remain out of scope Yaron: It needs to remain out of scope There are already two drafts on how to do quick, secure detection Doesn't want the proposed new text to be so specific that it would show preference towards one over the other Paul: Maybe have the issue brought up in the Security Considerations Yaron: There is a new section in -08 that may already cover this sufficiently Paul: If Peny has specific issues with that new text, please bring it to the list. Peny: Wants to know the rationale for 4.3.4 for silently deleting old SA Maybe the gateway can just reject the resumptions request Yaron: This is an anomalous case where the client detects a failure but the gateway is not sync'd It does not mean that the client is mailicious There is nothing you can do with the old stuff, so you just delete it Peny: The client might have been deceived The gateway should not have to delete it because there is more work for the gateway Paul: Disagrees that we need to worry about how much work the gateway has to do Tero: From the client's point of view, it has lost its SA, and that's why it is resuming The gateway should assume the same thing, namely that the client has lost its SA There is no reason to send a delete on the old SA because it is dead Also: the client is asking for conflicting traffic selectors, so get rid of the old ones first Peny: Disagrees that the client would only do resumption when it has lost the SA Might do it when it detects the failure of the gateway Tero: If the gateway has failed, it has no SAs up Paul: Please take this to the list Peny: Brings up old topic Paul: This is not a good place to be discussing this WG chairs are tasked with deciding consensus If you disagree with a consensus call, take it to the AD WESP draft-ietf-ipsecme-traffic-visibility Discussion by Ken and Gabriel One proposal is to have flexible padding length Pad lengths can be extended in the future We know we need pad of four bytes for IPv6 Tero: How are you planning to handle for the IANA registry? IANA registry will have bit numbers, but not the pictures Gabriel: The whole field is called the Flags field Lots to discuss on the list Yaron: Padding options looks too complex, would prefer one bit that means "extra four bytes" Tero: Agree Possible recharter items IPsec/IKE High Availability (draft-nir-ipsecme-ipsecha) Discussion by Yoav Tero: Doesn't think that the IKEv2 state needs any help from the other end Sync channel will not be problem for IKEv2 messages, but will be for ESP Yaron: The proposal is not to have just a problem statement like this document We want to have a solution as a WG item Tero: Doesn't think this a problem big enough for a WG item Kalyani: Thinks that this is a big enough problem in many scenarios Tero: The sync channel has not been a big issues for my customers Doesn't need protocol help Raj: May need protocol help Yoav: If there is a failure, it is much harder to sync the HA Need some help here IKEv2 message ID and HA Discussion by Kalyani Yaron: Please use the standard Internet Draft format in the next draft Raj: If we implement this solution but not in a cluster, it looks like session resumption Kalyani: This could also be used for resyncing peers (gives scenarios) Paul: We need a draft in front of us in order to continue the discussion IKEv2bis open issues draft-ietf-ipsecme-ikev2bis Skipped the presentation because we only have ten minutes left Certificate issues came up in issue #107 Presentation by Yaron Yoav and Yaron came up with a list of possible issues Tero: Maybe allow hash-and-URL along with bundles Need to consider what will make things simpler We will have a bunch of new certificate issues on the list A new draft of IKEv2bis will be out early the week of 2009-10-05 We know that some issues will be re-opened We are slipping from when we wanted WG LC, but the reasons are good, namely that we are hearing good implementer comments Finished in two hours From sheila.frankel@nist.gov Thu Oct 1 17:56:05 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7FC3A6837 for ; Thu, 1 Oct 2009 17:56:05 -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 q6mwgkknYEbe for ; Thu, 1 Oct 2009 17:56:02 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 8C82A3A6999 for ; Thu, 1 Oct 2009 17:56:02 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n920vF5o021789; Thu, 1 Oct 2009 20:57:15 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Thu, 1 Oct 2009 20:57:15 -0400 From: "Frankel, Sheila E." To: "ipsec@ietf.org" Date: Thu, 1 Oct 2009 20:54:08 -0400 Thread-Topic: New version of the IPsec Roadmap Internet Draft Thread-Index: AQHKQvsoPMan9FZqO0StKbqTOefRfw== 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-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: Paul Hoffman , "suresh.krishnan@ericsson.com" Subject: [IPsec] New version of the IPsec Roadmap Internet Draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 00:56:05 -0000 We just submitted an updated (version 04) roadmap draft. We would like to t= hank everyone who took the time to read the doc and submit comments. This email contains comments that led to changes in the doc, along with the= changed text. It also mentions suggested changes with which we disagreed. = Some minor editorial changes are not listed. 5 issues arose and were discussed at last week's interim meeting. They will= be entered on the tracker and circulated to the list. Sheila and Suresh ---------------------------------------------------------------- General comment: It would be much easier to read the document if each document would be easier to detect from each other. Now when moving from one document to next is indicated by even more indented bulletpoint text than the actual text it does not provide good visual feedback to search documents. It might be better to change all document headers to sections. RESPONSE: DONE One slight anomaly - the RFCs are not listed individually in the Ta= ble of Contents. That means that, e.g., an RFC whose section is numbered x.= x.x is not listed in the TOC, while a non-RFC section (e.g. 4.2.1 Peer Auth= entication Methods) is in the TOC. ---------------------------------------------------------------- Section 1. In fact, it would be nice if Sec. 3 mentioned that IPsec and IKE apply equa= lly to IPv4 and IPv6. It may be trivial to IPsec folks, but it isn't really= . RESPONSE: Added the following text to Introduction: IPsec and IKE can be used in conjunction with both IPv4 and IPv6. ---------------------------------------------------------------- Section 2.1, in both the text and the diagram, refers to combined-mode algo= rithms only in relation to ESP. However, RFC 4543 defines the use of AES-G= MAC for both ESP and AH. Same for Section 5.3 RESPONSE: AES-GMAC is only considered a combined mode algorithm in ESP; fo= r AH it is simply an integrity-protection algorithm ---------------------------------------------------------------- Section 2.3.1, second paragraph -- The first sentence refers to two SA pair= s and then the following sentences refer to two SAs. Perhaps we should mak= e this transition less abrupt? I suggest inserting a sentence after the fi= rst to indicate that "SA" can be used to refer not only to the unidirection= al SA but also to the pair. Section 2.3.1, second paragraph -- Is it worth noting that "phase 1 SA" and= "phase 2 SA" are also common names for the IKEv1 SAs? RESPONSE: New wording: Once an IKE negotiation is successfully completed, the peers have established two pairs of one-way (inbound and outbound) SAs. Since IKE always negotiates pairs of SAs, the term "SA" is generally used to refer to a pair of SAs (e.g., an "IKE SA" or an "IPsec SA" is in reality a pair of one-way SAs). The first SA, the IKE SA, is used to protect IKE traffic. The second SA provides IPsec protection to data traffic between the peers and/or other devices for which the peers are authorized to negotiate. It is called the IPsec SA in IKEv1 and, in the IKEv2 RFCs, it is referred to variously as a CHILD_SA, a child SA, and an IPsec SA. This document uses the term "IPsec SA". To further complicate the terminology, since IKEv1 consists of two sequential negotiations, called phases, the IKE SA is also referred to as a phase 1 SA and the IPsec SA is referred to as a phase 2 SA. ---------------------------------------------------------------- Section 3.1: "IPsec protections are provided by two extension headers" - th= is is true for IPv6, I don't think the term is applicable to IPv4. RESPONSE: Added new text: IPsec protections are provided by two special headers: the Encapsulating Security Payload (ESP) Header and the Authentication Header (AH). In IPv4, these headers take the form of protocol headers; in IPv6, they are classified as extension headers. ---------------------------------------------------------------- Section 3.4 RFCs 3947 and 4304 (ESN) are in section 3 (IPsec) but are more appropriate= for section 4 (IKE) RESPONSE: Since these are additions to IPsec that are negotiated by IKE, i= t seemed logical to place them where they are. ---------------------------------------------------------------- Section 3.4 The descriptions of RFC 3947 and RFC 3948 are oddly placed. Both are in sec= tion 3 (IPsec) although 3947 is about IKE, and yet they are separated rathe= r than following one another. I think that either 3947 should be moved to s= ection 4 (IKE) or that they should be moved together. RESPONSE: Moved 3948 right after 3947 ---------------------------------------------------------------- Section 3.4 ESN is mentioned as optional for IKEv1 and included in IKEv2. It is not me= ntioned that this is an optional feature for IPsec (both old and new) RESPONSE: Added Req Levels for IPsec-v2 (optional) and IPsec-v3 (optional) = to RFC4304 and Appendix A ---------------------------------------------------------------- In Section 3.4. "Additions to IPsec", "RFC 4891, Using IPsec to Secure IPv6= -in-IPv4 Tunnels" is marked as optional. I do not understand the significan= ce of marking this as optional because: 1) 4891 is informational and only describes a set of configuration settings= rather than a protocol, and, 2) an IPsec traffic selector can discriminate based on "Next Layer Protocol= " and thus can be used to realize 4891. So I'm thinking 4891 requirement level should be N/A rather than optional. The exact same reasoning seems to apply to "RFC 3884, Use of IPsec Transpor= t Mode for Dynamic Routing" which is also marked as optional. Section 3.5: "Requirements levels for RFC3715" are meaningless - this is a = requirements RESPONSE: Added clarification that "optional" means either protocol impleme= ntation or use of features described in RFC. I think N/A would be confusing= in this context. The new text is: For each core IPsec and IKE RFC, this document will classify its Requirements Level for each protocol (IKEv1, IKEv2, IPsec-v2, IPsec-v3), as either MUST, SHALL or MAY [RFC2119]; optional; undefined; or N/A (not applicable). Optional means that either the RFC describes features that are not required to be implemented or settings or procedures that are recommended but not mandatory. Undefined means that some aspect of the RFC is not fully defined for the specific version of the protocol. N/A means that use of the RFC is inappropriate in the context (e.g., combined mode algorithms, a new feature in IPsec-v3, for use with IPsec-v2). The classification of the cryptographic algorithm RFCs is further explained in Section 5. ---------------------------------------------------------------- Section 3.4 There is nothing that limits the Heuristics draft to ipsec-v3. In facts leg= acy devices are a major reason for publishing these heuristics. RESPONSE: changed IPsec-v2 to optional in the draft desc and Appendix A ---------------------------------------------------------------- Section 4.1.1: if RFC 2409 is N/A for IPsec-v3, how come RFC 4304 defines t= he use of ESN in IKEv1? But you can't expect a Roadmap document to resolve = all issues. RESPONSE: There definitely are murky areas, since some features have been r= etrofitted into IPsec-v2 without changing the RFCs. We've tried to make the= Req Levels jive with both accepted practice and the RFCs as much as possib= le. But we're open to specific comments on what should be changed. ---------------------------------------------------------------- Section 4.1.1: the relation of IKEv1 and Oakley, as described here, is conf= using. Because the Oakley *document* is informational, so you only need to= read the other 3 docs as an implementer. RESPONSE: Added new text: This document provides additional theory and background to explain some of the design decisions and security features of IKE and ISAKMP; it does not include details necessary for the implementation of IKEv1. ---------------------------------------------------------------- Section 4.2.1 describes RFC 4478 (authentication lifetime). It says "This d= ocument defines a new informational message that...". Instead it should say= "This document defines a new status notification, that...". Also, after "u= nless the initiator re-authenticates" I would add "within a specified perio= d of time". RESPONSE: DONE ---------------------------------------------------------------- Section 4.2.3 describes dead peer detection. It should mention that RFC 430= 6 (and the bis) call this feature "liveness check". Section 4.2.3: "dead peer detection (DPD) is an integral part of IKEv2", bu= t now renamed to "liveness test" or "liveness check". RESPONSE: Added new text: This RFC defines an optional extension to IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which refers to this feature as a "liveness check" or "liveness test". ---------------------------------------------------------------- Section 4.2.4: why say that session resumption "requires changes to IKEv2"?= It is an extension like many others. Similarly for the Redirect draft. RESPONSE: This distinguishes these drafts from, e.g. the heuristics draft. ---------------------------------------------------------------- Section 4.2.4 Page 21 -- At the very top, the reference "psecme-2" should read "ipsecme-2= ". Also, I'm curious why this reference is linked and some earlier ones (e= .g., "ipsecme-3") aren't. RESPONSE: Current version corrected so that all references have pointers in= the text ---------------------------------------------------------------- In section 5.2 covering RFC3686 document says: ... AES-CTR is a stream cipher with a 32-bit random nonce (1/SA) and a 64-bit IV, both of which are sent in the packet along with the encrypted data. The description of the random noise and 64-bit IV is correct, but only the = 64-bit IV is sent along the packet. The nonce is provided by the IKE with t= he keying material. RESPONSE: Deleted "both of which ... data" ---------------------------------------------------------------- Section 5.2: please add a reference to the new AES-CTR document (also requi= res to change Table 2). RESPONSE: added draft-ietf-ipsecme-aes-ctr-ikev2 and changed AES-CTR Requi= rements levels Requirements levels for AES-CTR: IKEv1 - undefined (no IANA #) IKEv2 - optional [draft-ietf-ipsecme-aes-ctr-ikev2] ESP-v2 - SHOULD [RFC4835] ESP-v3 - SHOULD [RFC4835] ---------------------------------------------------------------- Section 5.4.1: shouldn't we mention that RFC 5282 is based on a more generi= c AEAD framework (RFC 5116)? RESPONSE: We're trying to limit the number of non-IPsec references in the d= oc. Similarly, for the other algorithms (e.g. HMAC-SHA), we don't mention t= he non-IPsec base docs (RFC2104 - HMAC, or RFC3174 - SHA1). ---------------------------------------------------------------- Section 5.6: please define what is "Suite B" (a newcomer would be confused = by the different uses of the word "suite" here). RESPONSE: Added new Text: [RFC4869] adds 4 pre-defined suites, based upon the United States National Security Agency's "Suite B" specifications, to those specified in [RFC4308]. ---------------------------------------------------------------- Section 5.6 describes cryptographic suites documents (RFC 4308 and 4869), i= ncluding the algorithms these documents specify (encryption, data integrity= and DH group). It does not mention the not-so-obvious fact that RFC 4869 a= lso requires the use of ECDSA for public keys used for authentication (if p= ublic keys are used), whereas 4308 makes no such requirement. RESPONSE: Added new text: While [RFC4308] does not specify a peer authentication method, [RFC4869] mandates pre-shared key authentication for IKEv1; public key authentication using ECDSA is recommended for IKEv1 and required for IKEv2. ---------------------------------------------------------------- Section 7.3: Sec. 1 of RFC 5386 makes it clear that it does *not* apply to = IKEv1, or at least cannot be applied to all implementations. In addition, t= here is great confusion surrounding the term "unauthenticated security asso= ciations" in the BTNS context, but the IPsec Roadmap is not the place to de= al with this issue. RESPONSE: changed "the Internet Key Exchange (IKE) protocols, such as IKEv1= and IKEv2" to "IKEv2" ---------------------------------------------------------------- Section 7.4: I wouldn't say KINK is *another* attempt to provide an alterna= tive, because BTNS is not an alternative, it is just an IKE (and RFC4301) t= weak. RESPONSE: changed "another" to "an" ---------------------------------------------------------------- Section 7.5: I would describe the history differently (I was there...). IPS= RA attempted to tack user authentication onto IKEv1 with no change to IKE. = This indeed proved cumbersome, and the result was the brand new IKEv2, whic= h in fact adopted some of the IPSRA ideas, primarily the use of EAP. RESPONSE: Changed text: IPsec Secure Remote Access (IPSRA) was an attempt to extend IPsec protection to "road warriors," allowing IKE to authenticate not only the user's device but also the user, without changing IKEv1. The working group defined generic requirements of different IPsec remote access scenarios. An attempt was made to define an IKE-like protocol that would use legacy authentication mechanisms to create a temporary or short-lived user credential that could be used for peer authentication within IKE. This protocol proved to be more cumbersome than standard Public Key protocols, and was abandoned. This led to the development of IKEv2, which incorporates the use of EAP for user authentication. ---------------------------------------------------------------- Section 8.2 Is it worth mentioning that OSPF protection in RFC4552 works with manual ke= ying only, and that no key exchange protocols are specified? RESPONSE: Added new text: Since OSPFv3 exchanges multicast packets as well as unicast ones, the use of IKE within OSPFv3 is not appropriate. Therefore, this document mandates the use of manual keys. ---------------------------------------------------------------- Section 8.7 describes RoHC RFCs that relate to IPsec. I think it should als= o mention the soon-to-be-published drafts about compressing IPsec traffic: - draft-ietf-rohc-ipsec-extensions-hcoipsec - draft-ietf-rohc-ikev2-extensions-hcoipsec - draft-ietf-rohc-hcoipsec RESPONSE: Added the 3 rohc Internet Drafts ---------------------------------------------------------------- Section 8.3: this section could be improved by explaining what HIP is. RESPONSE: Changed text: IP addresses perform two distinct functions: host identifier and locator. This document specifies a protocol that allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses. This enables continuity of communications across IP address (locator) changes. It uses public key identifiers from a new Host Identity (HI) namespace for peer authentication. It uses the HMAC-SHA-1-96 and the AES-CBC algorithms with IPsec ESP and AH for protecting its signaling messages. ---------------------------------------------------------------- Nit -- there are a few places that don't hyphenate "combined mode" when use= d as an adjective: "combined mode algorithm[s]" should be "combined-mode al= gorithm[s]". RESPONSE: changed references to "combined mode algorithm," which is how al= l the RFCs do it; only other I-D that uses a hyphen is ikev2bis ---------------------------------------------------------------- Other Accepted Comments: The document capitalizes the name of the WG as IPsecme. I think we like usi= ng IPsecME, no? draft-ietf-ipsecme-ikev2-ipv6-config is no longer on the Standards Track. KINK and BTNS should be all-caps. Similarly MOBIKE. Section 6: typo: "[RFC5197] provides in in-depth". Section 8.3: typo: "for for describing". The description of RFC5206 has mismatched parenthesis. ---------------------------------------------------------------- ---------------------------------------------------------------- Issues that will be entered into the Issue Tracker: Issue #1: Combined algorithms: Can IKEv1 negotiate combined algorithms to be used by = IPsec-v3? ---------------------------------------------------------------- Issue #2: Section 5.3 -- Under RFC 2404, it mentions that SHA-1 ICVs are truncated to= 96 bits for IPsec. We should also mention that this truncation is done fo= r IKEv2 as well. Same for RFC 2403. RESPONSE: It appears that IKEv2 can negotiate the use of either the truncat= ed or non-truncated form of the algorithms. We will propose new text to des= cribe this. ---------------------------------------------------------------- Issue #3: Discussion on use of AES-XCBC in IKE. Currently, the Req levels are SHOULD = for IKEv1 (based on RFC4109) and optional for IKEv2. The Req levels for AES= -XCBC-PRF are SHOULD (based on RFC4109) and SHOULD+ for IKEv2 (RFC4307) This leaves us with 2 questions: 1) If there is no IANA value for AES-XCBC in IKEv1, how can RFC4109 recomme= nd (SHOULD) its use? 2) If AES-XCBC and AES-XCBC-PRF can be used in IKEv1, what should be propos= ed? What should you propose if you want AES-XCBC for both a PRF and an inte= grity-protection algorithm in IKEv1? ---------------------------------------------------------------- Issue #4: BEET and expired drafts: - I would have liked to see ESP BEET mode referenced, since it's more widel= y implemented than other docs that we do mention. But as far as I know it is not on track to becoming an RFC. - I think it might also be good to mention other very widely implemented (expired) drafts which will never come out as RFCs, namely IKEv1 configuration mode (draft-dukes-ike-mode-cfg-02) and IKEv1 xauth (draft-beaulieu-ike-xauth-02). RESPONSE: We will mention the expired drafts in the IKEv1 section of the ro= admap doc, explaining that many implementations implement these 2 drafts to= enable road warrior (user) authentication. The wording will include cautio= ns about their use: security issues, implementation/interoperability proble= ms, etc. ---------------------------------------------------------------- Issue #5: Issue of Camellia req levels for IKEv2 Camellia-CBC: covered by generic CBC requirements in RFC4306? Camellia-CTR: needs its own RFC? Camellia-CCM: covered by RFC 5282? ---------------------------------------------------------------- From root@core3.amsl.com Thu Oct 1 18:00:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 89EBC3A6837; Thu, 1 Oct 2009 18:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091002010001.89EBC3A6837@core3.amsl.com> Date: Thu, 1 Oct 2009 18:00:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-roadmap-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 01:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap Author(s) : S. Frankel, S. Krishnan Filename : draft-ietf-ipsecme-roadmap-04.txt Pages : 65 Date : 2009-10-01 Over the past few years, the number of RFCs that define and use IPsec and IKE has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes the previous IPsec Document Roadmap [RFC2411]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-roadmap-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-roadmap-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-01175156.I-D@ietf.org> --NextPart-- From rgrains@mitre.org Sat Oct 3 08:12:05 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2987B3A6933 for ; Sat, 3 Oct 2009 08:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 V5eTooVj9i+R for ; Sat, 3 Oct 2009 08:12:04 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id CBB223A676A for ; Sat, 3 Oct 2009 08:12:03 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n93FDVSE004634 for ; Sat, 3 Oct 2009 11:13:33 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n93FDV80004631; Sat, 3 Oct 2009 11:13:31 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Sat, 3 Oct 2009 11:13:31 -0400 From: "Rains, Bob" To: "Rains, Bob" Date: Sat, 3 Oct 2009 11:13:29 -0400 Thread-Topic: IPSec Consortium Meeting & Industry Discussion of Security Protocol Interoperability Needs Thread-Index: AcpC4cXjdybarZSuRrqOLGEPYTyl8QAb76PQAAx5wBEALFafAA== Message-ID: <6A913BB6ED2E2C43AC275462A83E68490C0CF2DD23@IMCMBX3.MITRE.ORG> 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-Mailman-Approved-At: Sat, 03 Oct 2009 08:20:13 -0700 Subject: [IPsec] FYI: IPSec Consortium Meeting & Industry Discussion of Security Protocol Interoperability Needs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 15:13:58 -0000 FYI, Please forward to anyone interested in commercial and critical infrastructu= re application of the IP Security protocols. IPSec Consortium Meeting & Discussion of the Interoperability Needs of Indu= stry with Respect to the IP Security Protocols DATE: Nov 2, 3, and 4, 2009=20 LOCATION: Boeing Long Acres facility just south of Seattle, Washington, ne= ar Seatac airport If anyone is interested in this meeting or the IPsec Consortium in general,= contact the Boeing host,=20 Terry L Davis ,=20 or see http://www.icsalabs.com/technology-program/ipsec/ipsec-consortium=20 for more information. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Subject: IPSec Consortium Meeting & Industry Discussion Security Protocol Interoperability Needs (Boeing hosting in Seattle) Date: Thu, 01 Oct 2009 11:02:58 From: Davis, Terry L All Boeing will be hosting the IPSec Consortium Meeting on Monday November 2nd = and Tuesday November 3rd (potentially extensible to the 4th if the agenda d= rives it) at our Long Acres facility just south of Seattle near Seatac airp= ort. The Consortium will have their regular meetings on Monday the 2nd. On Tuesday the 3rd, we will hold discussions on the interoperability needs = of industry with respect to the IP Security protocols. especially). Over the last year the aviation industry, the US Railway Association, sever= al of critical infrastructure sectors, and several others on this list have= also expressed concerns/interest with an interoperability discussion inclu= ding various government agencies. For aviation at least, our global infras= tructure of airlines, aviation services providers, airports, and government= s create probably the most heterogeneous possible environment; our aircraft= will often be in communication with multiple entities using completely dif= ferent infrastructures and "vendors". Having a simple to configure and ea= sy to operate, IP Security infrastructure is of critical interest to us as = I believe it will be to many of the industries and critical infrastructure = sectors. If you are interested in attending the meetings and these discussions, plea= se reply back and I will provide you more details; also indicate if you wou= ld like to make a short presentation on your interoperability needs. Boein= g also intends to make teleconferencing and webex available for those inter= ested but unable to attend in person. Take care Terry L Davis, P.E Boeing Technical Fellow Aircraft Network and Security, Architecture & Strategy Engineering Core - Avionics Boeing Commercial Airplanes Phone: 206-280-3716 Email: Terry.L.Davis@Boeing.com From william.polk@nist.gov Mon Oct 5 04:46:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979BE3A6808 for ; Mon, 5 Oct 2009 04:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 u15K6cV0n7-U for ; Mon, 5 Oct 2009 04:46:07 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id AF8CD3A6892 for ; Mon, 5 Oct 2009 04:46:07 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n95BlYRs008610 for ; Mon, 5 Oct 2009 07:47:34 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Mon, 5 Oct 2009 07:47:34 -0400 From: "Polk, William T." To: "ipsec@ietf.org" Date: Mon, 5 Oct 2009 07:47:32 -0400 Thread-Topic: Confirming response to ietf last call comments on draft-ietf-ipsecme-ikev2-ipv6-config Thread-Index: AcpFsZ9xtnRfYN9m/UunFR7IXRvV6A== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Mailman-Approved-At: Mon, 05 Oct 2009 06:42:56 -0700 Subject: [IPsec] Confirming response to ietf last call comments on draft-ietf-ipsecme-ikev2-ipv6-config X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 11:46:08 -0000 Folks, In response to the Gen-ART review of draft-ietf-ipsecme-ikev2-ipv6-config, Pasi has proposed adding a new, non-normative appendix. I have entered the new text as an RFC Editor Note, but wish to confirm that this text is acceptable to the working group. The note is appended to this message.... Thanks,=20 Tim RFC Editor Note Please add the following as Appendix B: Appendix B. Evaluation (Non-Normative) =20 Section 3 described the goals and requirements for IPv6 configuration in IKEv2. This appendix briefly summarizes how the solution specified in Sections 4 and 5 meets these goals. =20 o (3.1) Assigning addresses from multiple prefixes is supported, without requiring the client to know beforehand how many prefixes are needed. o (3.2) Link-local addresses are assigned, and can be used for protocols between the VPN client and gateway. o (3.3) The entire prefix is assigned to a single client, so the client can freely select any number of interface IDs (which may depend on the prefix). o (3.4) This document does not specify how the VPN client would share the VPN connection with other devices. However, since the entire prefix is assigned to a single client, the client could further assign addresses from it without requiring coordination with the VPN gateway. o (3.5) The solution does not add any new periodic messages over the VPN tunnel. o (3.5) Re-authentication works (see Section 4.2). o (3.5) The solution is compatible with other IPsec uses, since the LINK_ID notification makes it unambiguous which CHILD_SAs are related to the virtual link and which are not (see Sections 4.3 and 5.3). o (3.5) The new mechanisms do not prevent the VPN client and/or gateway from implementing the INTERNAL_IP6_ADDRESS configuration attribute as well; however, the two mechanisms are not intended to be used simultaneously (see Section 4.5). o (3.5) Implementation dependencies are, obviously, implementation dependant (and their cleanliness somewhat subjective). Possible drawbacks of some alternative solutions are discussed in Appendix A.6. o (3.5) The mechanism for configuring the prefixes (configuration payloads) is specific to IKEv2, for reasons described in Appendix A. However, Section 4.1 recommends using DHCPv6 Information-Request message for obtaining other configuration information (such as DNS server addresses). From root@core3.amsl.com Mon Oct 5 14:45:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7FB903A6A3B; Mon, 5 Oct 2009 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091005214501.7FB903A6A3B@core3.amsl.com> Date: Mon, 5 Oct 2009 14:45:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2bis-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 21:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Internet Key Exchange Protocol: IKEv2 Author(s) : C. Kaufman, et al. Filename : draft-ietf-ipsecme-ikev2bis-05.txt Pages : 149 Date : 2009-10-05 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). It replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-05144152.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Oct 7 08:15:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CAF643A6848; Wed, 7 Oct 2009 08:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091007151501.CAF643A6848@core3.amsl.com> Date: Wed, 7 Oct 2009 08:15:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 15:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, et al. Filename : draft-ietf-ipsecme-traffic-visibility-09.txt Pages : 15 Date : 2009-10-07 This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) [RFC4303], and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec ESP standard, there is no way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-traffic-visibility-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-07081221.I-D@ietf.org> --NextPart-- From wierbows@us.ibm.com Wed Oct 7 08:20:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C093A686C for ; Wed, 7 Oct 2009 08:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 W9xtZCw-v0+1 for ; Wed, 7 Oct 2009 08:20:05 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 5E9813A657C for ; Wed, 7 Oct 2009 08:20:05 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n97FKXrT017722 for ; Wed, 7 Oct 2009 11:20:33 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n97FLijH253910 for ; Wed, 7 Oct 2009 11:21:44 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n97FLi63014091 for ; Wed, 7 Oct 2009 11:21:44 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n97FLhIa013954 for ; Wed, 7 Oct 2009 11:21:43 -0400 In-Reply-To: <19139.30218.224175.430768@fireball.kivinen.iki.fi> References: <19127.28334.472030.873072@fireball.kivinen.iki.fi> <19128.47812.239136.479467@fireball.kivinen.iki.fi> <19139.30218.224175.430768@fireball.kivinen.iki.fi> X-KeepSent: EEE95DB8:C0F31717-85257648:0053C0B7; type=4; name=$KeepSent To: IPsecme WG X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Wed, 7 Oct 2009 11:21:41 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 10/07/2009 11:21:43 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCDBDFC046278f9e8a93df938690918c0ABBFCDBDFC04627" Content-Disposition: inline Subject: Re: [IPsec] #22 Simultaneous IKE SA rekey text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 15:20:08 -0000 --0__=0ABBFCDBDFC046278f9e8a93df938690918c0ABBFCDBDFC04627 Content-type: text/plain; charset=US-ASCII >> I agree with what you stated here, but I feel you are addressing something >> that is not limited to a simultaneous rekey of the IKE SA. It deals with >> any >> rekey of an IKE SA. In my opinion the text is misplaced and should be in a >> section that deals with handling of outstanding exchanges when an IKE SA >> is rekeyed. > >True. This wait is not really because of simultaneous rekey, but rekey >in general. The reason I brought this up here, is that I think that >wait is important and the solution for simulatenous rekey should be >one that works with such wait. > >> With that said I'm not sure I agree with how you propose to >> handle the outstanding exchanges. > >I do not think there is any other way than to wait some time to get >them finished (or at least failed and acked). The other end who >started those outstanding exchanges MUST know whether they were >processed or not. If IKE SA is deleted immediately there is no way >other end can know that as after IKE SA is deleted the other end does >not send ACKs back. RFC 4718 states: It seems this situation is tricky to handle correctly. Our proposal is as follows: if a host receives a request to rekey the IKE_SA when it has CHILD_SAs in "half-open" state (currently being created or rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host receives a request to create or rekey a CHILD_SA after it has started rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS. If you have outstanding requests to rekey a CHILD SA when you get a request to rekey the IKE SA you should respond with NO_PROPOSAL_CHOSEN. Given that is seems reasonable that you would not start the rekey of an IKE SA while you have outstanding requests to rekey a child SA, but if you did then it would make sense that you'd delay sending the delete request associated with your own successful rekeying of the IKE SA until those outstanding requests have been responded to. If you follow 4718 the only request you can have outstanding when you send a non-error response to an IKE SA rekey request is your own request to rekey the IKE SA. > >> > I agree it should mark the SA so that it is no longer used for the new >> > SAs initiated from this end, but the other end might have its own >> > exchanges ongoing when the rekey started, and waiting those to finish >> > makes protocol work better. When both end mark the old SA as being >> > "old", meaning no new exchanges are started on it, but old exchanges >> > are allowed to finished then when those old exchanges are finished, >> > then the old IKE SA should be deleted (and all operations done on the >> > old IKE SA should be moved to the winning SA). >> >> This sounds like a good idea, but it's not what 4306 required and is a >> protocol change. > >Not really. The RFC4306 do say that you MUST be able to process >incoming requests while having your own requests out: > >2.3. Window Size for Overlapping Requests >... > .... An > IKE endpoint MUST be prepared to accept and process a request while > it has a request outstanding in order to avoid a deadlock in this > situation. An IKE endpoint SHOULD be prepared to accept and process > multiple requests while it has a request outstanding. > I see nothing in this text that says you must delay deleting the IKE SA or accept new requests on an IKE SA that you've rekeyed. That is what you wish to do and that is a protocol change. >I.e. when you have REKEY started and even when the rekey itself has >finished, and delete request sent out (and even replied), you still >might receive requests from the other end which were started before >the REKEY was started. If RFC 4718 is followed the only outstanding create child request that can be received is a request to rekey the IKE SA. There is little value in waiting for this. When the peer receives the request to delete that IKE SA it will know one of two things happened. The first is the simultaneous rekey was not detected by both peers. The second is the simultaneous rekey was detected by both peers and the peer sending the delete did not have the lowest nonce. These are the only valid reasons for receiving a delete in this case. > >I agree that the behavior how to handle the deleting of IKE SA after >rekey is not described explicitly in RFC4306, but the generic text >that you MUST be able toprocess incoming requests while having your >own requests out is there, and that is regardless what those requests >are. > > >> Based on 4306 I think when an informational exchange request is received >> containing the delete of an IKE_SA that the receiver can conclude that most >> likely any outstanding request will fail once a response to the delete is >> sent. The receiver of the delete request has ways to deal with this. > >The other end cannot know that, and IKEv2 is deterministic protocol, >thus such "most likely" is not enough for it. Here is example to show >the situation: As I said above there are only 2 reasons for getting the delete, so strike the most likely from my original text. If RFC 4718 is followed the receiver of the delete request can deterministically conclude that any outstanding create child requests will fail. In addition, the only outstanding create child request possible in this case is one to rekey the IKE SA. > > Host A Host B > -------- ---------- > <-- sends request > packet is dropped by network it > never reaches the host A > starts rekey --> > <-- replies to rekey If you follow the recommendation in RFC 4718 Host B will reply with NO_PROPOSAL_CHOSEN and HOST A would not delete the IKE SA. > starts IKE SA delete --> > <-- replies to IKE SA delete > >Now Host A will delete all of the state of old IKE SA and cannot then >process the request from Host B even if it ever reaches it. It cannot >even send error back as the crypto keys and so on are already deleted. >Host B does not know whether the request was processed or not, as >situation could have also been this: > > > Host A Host B > -------- ---------- > <-- sends request > processes request and sends reply --> > reply packet is dropped by network it > never reaches the host B > starts rekey --> > <-- replies to rekey Again, if you follow the recommendation in RFC 4718 Host B will reply with NO_PROPOSAL_CHOSEN and HOST A would not delete the IKE SA. > starts IKE SA delete --> > <-- replies to IKE SA delete > >Now Host A thinks that the request host B sent was done and finished >before rekey, but the Host B does not know that. Host A will not >retransmit the reply packet unless host B retransmits its request, but >if the IKE SA is deleted by A before that host B might not have time >to ever send retransmission for its request, thus B does not know >whether its request was processed or not. > >If host A delays deleting of the IKE SA so long that Host B's >retransmissions reach it (i.e. time depending on the retransmission >timers, i.e. for example 31.5 seconds if original retry timer is 500 >ms, and retry timer is doubled after each retry, and retry limit is 6 >packets) then after that time it knows that host B should have been >able to finish ongoing exchanges during that time, thus it is safe to >delete IKE SA after that. > >During that time it can either process the requests or fail them (I.e. >it can fail the CREATE_CHILD_SA exchanges trying to create new Child >SAs, or it can finish them, but if it finishes them, then it should >make sure the Child SAs are moved to new IKE SA before old IKE SA is >deleted. > >> It can delay sending a response until it receives responses to all >> outstanding requests. > >It cannot as that could reach deadlock situation, and would be against >the MUST in RFC4306, which says you MUST be able process a request >while it has a request outstanding. > >> It can send a response immediately and conclude >> that all outstanding requests will fail. In that case it can restart the >> outstanding request on a newer IKE_SA or wait for traffic to require the >> creation of a new SA. > >As the host A might have already processed the outstanding request >before it even started the rekey, but the reply was lost, that would >mean that the host A and B are out of sync. > >> > Sending some more suitable error could most likely also work, but >> > still the IKE SA cannot be deleted immediately. It can only be deleted >> > when ongoing exchanges have been finished. >> > >> > I have not checked out if your suggested version works with all >> > possible combinations of simulatenous rekeys, but from the first look >> > it seems it might also work. >> > >> > On the other hand there is no text indicating such behavior in the >> > IKEv2 document, so it is protocol change compared to the old text >> > which said that simulatenous rekey is processed by checking out the >> > nonces. The rekeys in this case are simulatenous even when Host A >> > didn't initially detect that. >> > >> >> Agreed, so we have two possible protocol changes if we need to mandate one >> or we could allow implementations solve the problem as they see fit. I >> think >> my solution is consistent with what is stated in Section 5.11.4 of RFC >> 4718. >> You are introducing the need to detect a simultaneous rekey after the fact. > >The RFC4306 says what you need to do when you see simultaneous rekey, >and it only gives you one option: Check for the nonces. The rekey is >simultaneous, if either end detects it was simultanoues, it is >completely possible that other end didn't notice it. RFC 4306 does not say that. RFC 4306 never uses the term simultaneous rekey. What it does say is: If redundant SAs are created though such a collision, the SA created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it. If only one host detects the simultaneous rekey then redundant SAs are not created. By adding a timer to delay sending the delete you are going out of the way to try to create redundant SAs. > >Not the that RFC4718 do consider even that case as simultanoues rekey, >as given by the 5.11.3 as last example. It does give the >N(NO_PROPOSAL_CHOSEN) option for handling that instead of checking for >nonces, but I think RFC4718 is in error there, as RFC4306 still says >you should use nonces even there. 5.11.4 says the simultaneous rekey >is detect in the same way as was done in 5.11.3. No, RFC 4306 says if redundant SAs are created use the nonce. If only one side detects a possible simultaneous reky then redundant SAs are not created. > >And I think the 5.11.4 is also quite wrong there. Remember that >RFC4718 is only Information RFC trying to clarify things in the >RFC4306, the RFC4306 is still the standard track document which >specifies how things are supposed to work. I suspect that many vendors did what we did with regards to RFC 4718. We implemented what RFC 4718 suggested. RFC 4718 was the starting point for the IKEv2bis work. I see no reason to reinvent solutions contained in RFC 4718. > >> >> > That delay does not have anything to do with simultaneous rekey, it is >> > needed to allow the ongoing exchanges to finish before old IKE SA is >> > deleted. >> >> As I said earlier I think the ongoing exchange issue should be documented >> separately from the simultaneous rekey case, although I agree there can >> be a tie to it if your solution is agreed to. > >Yes, we need to add text for that in the ikev2bis somewhere. Where do >you think it would be best? I am not sure where it would be best to document how to handle outstanding exchanges, but I think they should be handled as RFC 4718 recommended. > >> > On the other hand RFC4306 specifies exactly ONE way to handle >> > simulatenous rekey and that is by checking the nonces. The rekey is >> > simulatenous even when one host didn't immediately detect it as >> > simulatenous because some packet was lost. >> > >> > I agree now that "MUST NOT immediately delete" was too strong, so >> > "SHOULD NOT immediately delete" is better. If implementation does not >> > implement larger window sizes, and is used in environments where there >> > is very limited number of CHILD SAs per IKE SA, so the probability of >> > getting CREATE_CHILD_SA just when other ends decides to rekey is so >> > small, that it does not matter even if the whole IKE SA gets deleted >> > in that case then it can ignore that SHOULD. >> >> I think "SHOULD NOT immediately delete" is still too strong. I think >> "MAY delay the deletion to allow ongoing exchanges to complete" is >> more appropriate at this point. > >I think we should encourage people to allow ongoing exchanes to >complete in the rekey case, so I think SHOULD is better than MAY. I do not agree that we should encourage people to go out of their way to detect a simultaneous IKE SA rekey. I'm fine with allowing an implementation to do that. I think MAY is the correct way to go. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 --0__=0ABBFCDBDFC046278f9e8a93df938690918c0ABBFCDBDFC04627 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

>> I agree with what you stated here, but I feel you are addressing something
>> that is not limited to a simultaneous rekey of the IKE SA. It deals with
>> any
>> rekey of an IKE SA. In my opinion the text is misplaced and should be in a
>> section that deals with handling of outstanding exchanges when an IKE SA
>> is rekeyed.
>
>True. This wait is not really because of simultaneous rekey, but rekey
>in general. The reason I brought this up here, is that I think that
>wait is important and the solution for simulatenous rekey should be
>one that works with such wait.
>
>> With that said I'm not sure I agree with how you propose to
>> handle the outstanding exchanges.
>
>I do not think there is any other way than to wait some time to get
>them finished (or at least failed and acked). The other end who
>started those outstanding exchanges MUST know whether they were
>processed or not. If IKE SA is deleted immediately there is no way
>other end can know that as after IKE SA is deleted the other end does
>not send ACKs back.

RFC 4718 states:

It seems this situation is tricky to handle correctly. Our proposal
is as follows: if a host receives a request to rekey the IKE_SA when
it has CHILD_SAs in "half-open" state (currently being created or
rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host
receives a request to create or rekey a CHILD_SA after it has started
rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.

If you have outstanding requests to rekey a CHILD SA when you get
a request to rekey the IKE SA you should respond with
NO_PROPOSAL_CHOSEN. Given that is seems reasonable that you would not
start the rekey of an IKE SA while you have outstanding requests to rekey
a child SA, but if you did then it would make sense that you'd delay
sending the delete request associated with your own successful rekeying
of the IKE SA until those outstanding requests have been responded to.

If you follow 4718 the only request you can have outstanding when you
send a non-error response to an IKE SA rekey request is your own request
to rekey the IKE SA.

>
>> > I agree it should mark the SA so that it is no longer used for the new
>> > SAs initiated from this end, but the other end might have its own
>> > exchanges ongoing when the rekey started, and waiting those to finish
>> > makes protocol work better. When both end mark the old SA as being
>> > "old", meaning no new exchanges are started on it, but old exchanges
>> > are allowed to finished then when those old exchanges are finished,
>> > then the old IKE SA should be deleted (and all operations done on the
>> > old IKE SA should be moved to the winning SA).
>>
>> This sounds like a good idea, but it's not what 4306 required and is a
>> protocol change.
>
>Not really. The RFC4306 do say that you MUST be able to process
>incoming requests while having your own requests out:
>
>2.3. Window Size for Overlapping Requests
>...
> .... An
> IKE endpoint MUST be prepared to accept and process a request while
> it has a request outstanding in order to avoid a deadlock in this
> situation. An IKE endpoint SHOULD be prepared to accept and process
> multiple requests while it has a request outstanding.
>
I see nothing in this text that says you must delay deleting the IKE SA
or accept new requests on an IKE SA that you've rekeyed. That is what
you wish to do and that is a protocol change.

>I.e. when you have REKEY started and even when the rekey itself has
>finished, and delete request sent out (and even replied), you still
>might receive requests from the other end which were started before
>the REKEY was started.

If RFC 4718 is followed the only outstanding create child request that
can be received is a request to rekey the IKE SA. There is little
value in waiting for this. When the peer receives the request to
delete that IKE SA it will know one of two things happened.

The first is the simultaneous rekey was not detected by both peers. The
second is the simultaneous rekey was detected by both peers and the peer
sending the delete did not have the lowest nonce. These are the only
valid reasons for receiving a delete in this case.

>
>I agree that the behavior how to handle the deleting of IKE SA after
>rekey is not described explicitly in RFC4306, but the generic text
>that you MUST be able toprocess incoming requests while having your
>own requests out is there, and that is regardless what those requests
>are.
>
>
>> Based on 4306 I think when an informational exchange request is received
>> containing the delete of an IKE_SA that the receiver can conclude that most
>> likely any outstanding request will fail once a response to the delete is
>> sent. The receiver of the delete request has ways to deal with this.
>
>The other end cannot know that, and IKEv2 is deterministic protocol,
>thus such "most likely" is not enough for it. Here is example to show
>the situation:

As I said above there are only 2 reasons for getting the delete, so
strike the most likely from my original text. If RFC 4718 is followed
the receiver of the delete request can deterministically conclude that
any outstanding create child requests will fail. In addition, the only
outstanding create child request possible in this case is one to rekey
the IKE SA.

>
> Host A Host B
> -------- ----------
> <-- sends request
> packet is dropped by network it
> never reaches the host A
> starts rekey -->
> <-- replies to rekey

If you follow the recommendation in RFC 4718 Host B will reply with
NO_PROPOSAL_CHOSEN and HOST A would not delete the IKE SA.

> starts IKE SA delete -->
> <-- replies to IKE SA delete
>
>Now Host A will delete all of the state of old IKE SA and cannot then
>process the request from Host B even if it ever reaches it. It cannot
>even send error back as the crypto keys and so on are already deleted.
>Host B does not know whether the request was processed or not, as
>situation could have also been this:
>
>
> Host A Host B
> -------- ----------
> <-- sends request
> processes request and sends reply -->
> reply packet is dropped by network it
> never reaches the host B
> starts rekey -->
> <-- replies to rekey

Again, if you follow the recommendation in RFC 4718 Host B will reply with
NO_PROPOSAL_CHOSEN and HOST A would not delete the IKE SA.

> starts IKE SA delete -->
> <-- replies to IKE SA delete
>
>Now Host A thinks that the request host B sent was done and finished
>before rekey, but the Host B does not know that. Host A will not
>retransmit the reply packet unless host B retransmits its request, but
>if the IKE SA is deleted by A before that host B might not have time
>to ever send retransmission for its request, thus B does not know
>whether its request was processed or not.
>
>If host A delays deleting of the IKE SA so long that Host B's
>retransmissions reach it (i.e. time depending on the retransmission
>timers, i.e. for example 31.5 seconds if original retry timer is 500
>ms, and retry timer is doubled after each retry, and retry limit is 6
>packets) then after that time it knows that host B should have been
>able to finish ongoing exchanges during that time, thus it is safe to
>delete IKE SA after that.
>
>During that time it can either process the requests or fail them (I.e.
>it can fail the CREATE_CHILD_SA exchanges trying to create new Child
>SAs, or it can finish them, but if it finishes them, then it should
>make sure the Child SAs are moved to new IKE SA before old IKE SA is
>deleted.
>
>> It can delay sending a response until it receives responses to all
>> outstanding requests.
>
>It cannot as that could reach deadlock situation, and would be against
>the MUST in RFC4306, which says you MUST be able process a request
>while it has a request outstanding.
>
>> It can send a response immediately and conclude
>> that all outstanding requests will fail. In that case it can restart the
>> outstanding request on a newer IKE_SA or wait for traffic to require the
>> creation of a new SA.
>
>As the host A might have already processed the outstanding request
>before it even started the rekey, but the reply was lost, that would
>mean that the host A and B are out of sync.
>
>> > Sending some more suitable error could most likely also work, but
>> > still the IKE SA cannot be deleted immediately. It can only be deleted
>> > when ongoing exchanges have been finished.
>> >
>> > I have not checked out if your suggested version works with all
>> > possible combinations of simulatenous rekeys, but from the first look
>> > it seems it might also work.
>> >
>> > On the other hand there is no text indicating such behavior in the
>> > IKEv2 document, so it is protocol change compared to the old text
>> > which said that simulatenous rekey is processed by checking out the
>> > nonces. The rekeys in this case are simulatenous even when Host A
>> > didn't initially detect that.
>> >
>>
>> Agreed, so we have two possible protocol changes if we need to mandate one
>> or we could allow implementations solve the problem as they see fit. I
>> think
>> my solution is consistent with what is stated in Section 5.11.4 of RFC
>> 4718.
>> You are introducing the need to detect a simultaneous rekey after the fact.
>
>The RFC4306 says what you need to do when you see simultaneous rekey,
>and it only gives you one option: Check for the nonces. The rekey is
>simultaneous, if either end detects it was simultanoues, it is
>completely possible that other end didn't notice it.

RFC 4306 does not say that. RFC 4306 never uses the term simultaneous
rekey. What it does say is:

If redundant SAs are created though such a collision, the SA
created with the lowest of the four nonces used in the two exchanges
SHOULD be closed by the endpoint that created it.

If only one host detects the simultaneous rekey then redundant SAs
are not created. By adding a timer to delay sending the delete you
are going out of the way to try to create redundant SAs.

>
>Not the that RFC4718 do consider even that case as simultanoues rekey,
>as given by the 5.11.3 as last example. It does give the
>N(NO_PROPOSAL_CHOSEN) option for handling that instead of checking for
>nonces, but I think RFC4718 is in error there, as RFC4306 still says
>you should use nonces even there. 5.11.4 says the simultaneous rekey
>is detect in the same way as was done in 5.11.3.

No, RFC 4306 says if redundant SAs are created use the nonce. If
only one side detects a possible simultaneous reky then redundant SAs
are not created.

>
>And I think the 5.11.4 is also quite wrong there. Remember that
>RFC4718 is only Information RFC trying to clarify things in the
>RFC4306, the RFC4306 is still the standard track document which
>specifies how things are supposed to work.

I suspect that many vendors did what we did with regards to RFC 4718.
We implemented what RFC 4718 suggested. RFC 4718 was the starting
point for the IKEv2bis work. I see no reason to reinvent solutions
contained in RFC 4718.

>
>>
>> > That delay does not have anything to do with simultaneous rekey, it is
>> > needed to allow the ongoing exchanges to finish before old IKE SA is
>> > deleted.
>>
>> As I said earlier I think the ongoing exchange issue should be documented
>> separately from the simultaneous rekey case, although I agree there can
>> be a tie to it if your solution is agreed to.
>
>Yes, we need to add text for that in the ikev2bis somewhere. Where do
>you think it would be best?

I am not sure where it would be best to document how to handle
outstanding exchanges, but I think they should be handled as RFC 4718
recommended.

>
>> > On the other hand RFC4306 specifies exactly ONE way to handle
>> > simulatenous rekey and that is by checking the nonces. The rekey is
>> > simulatenous even when one host didn't immediately detect it as
>> > simulatenous because some packet was lost.
>> >
>> > I agree now that "MUST NOT immediately delete" was too strong, so
>> > "SHOULD NOT immediately delete" is better. If implementation does not
>> > implement larger window sizes, and is used in environments where there
>> > is very limited number of CHILD SAs per IKE SA, so the probability of
>> > getting CREATE_CHILD_SA just when other ends decides to rekey is so
>> > small, that it does not matter even if the whole IKE SA gets deleted
>> > in that case then it can ignore that SHOULD.
>>
>> I think "SHOULD NOT immediately delete" is still too strong. I think
>> "MAY delay the deletion to allow ongoing exchanges to complete" is
>> more appropriate at this point.
>
>I think we should encourage people to allow ongoing exchanes to
>complete in the rekey case, so I think SHOULD is better than MAY.

I do not agree that we should encourage people to go out of their way
to detect a simultaneous IKE SA rekey. I'm fine with allowing an
implementation to do that. I think MAY is the correct way to go.


Dave Wierbowski


z/OS Comm Server Developer

Phone:
Tie line: 620-4055
External: 607-429-4055 --0__=0ABBFCDBDFC046278f9e8a93df938690918c0ABBFCDBDFC04627-- From kivinen@iki.fi Fri Oct 9 06:01:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45EBA28C0FD for ; Fri, 9 Oct 2009 06:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] 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 dkvDXNM+YCUy for ; Fri, 9 Oct 2009 06:01:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 685F728C143 for ; Fri, 9 Oct 2009 06:01:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n99D32kD003170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Oct 2009 16:03:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n99D30MO000595; Fri, 9 Oct 2009 16:03:00 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19151.13444.894473.883558@fireball.kivinen.iki.fi> Date: Fri, 9 Oct 2009 16:03:00 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <19127.28334.472030.873072@fireball.kivinen.iki.fi> <19128.47812.239136.479467@fireball.kivinen.iki.fi> <19139.30218.224175.430768@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 42 min X-Total-Time: 44 min Cc: IPsecme WG Subject: Re: [IPsec] #22 Simultaneous IKE SA rekey text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 13:01:24 -0000 David Wierbowski writes: > >I do not think there is any other way than to wait some time to get > >them finished (or at least failed and acked). The other end who > >started those outstanding exchanges MUST know whether they were > >processed or not. If IKE SA is deleted immediately there is no way > >other end can know that as after IKE SA is deleted the other end does > >not send ACKs back. > > RFC 4718 states: RFC4718 is informational and tried to clarify things which are not clear in RFC4306. Now we are writing standard track document when revising RFC4306 and in that case we can even change things specified in RFC4306, if needed. In this case I do not think we need to change things from RFC4306, but I think the text in RFC4718 is not correct as it does not consider the case completely. > It seems this situation is tricky to handle correctly. Our proposal > is as follows: if a host receives a request to rekey the IKE_SA when > it has CHILD_SAs in "half-open" state (currently being created or > rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host > receives a request to create or rekey a CHILD_SA after it has started > rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS. This solution might cause peers to stay in live lock state, causing the whole IKE SA to be unusable. I.e. host A starts IKE SA rekey and host B starts Create Child SA. Host B replies NO_PROPOSAL_CHOSEN to host A's IKE SA rekey, and Host A replies NO_ADDITIONAL_SAS to Host B's Create Child SA request. Both ends process replies, and notices they failed, thus both start again, causing both ends to be trying these operations as fast as they can. This situation will stay as it is unless something kicks hosts out of sync. Or returning NO_ADDITIONAL_SAS might cause other end to delete the whole IKE SA and start from scratch. > If you have outstanding requests to rekey a CHILD SA when you get > a request to rekey the IKE SA you should respond with > NO_PROPOSAL_CHOSEN. This is not in RFC4306, this is just one proposal given in RFC4718 which might be used, but as I noted above, it can cause live lock loop, thus it is not really acceptable. > Given that is seems reasonable that you would not > start the rekey of an IKE SA while you have outstanding requests to rekey > a child SA, but if you did then it would make sense that you'd delay > sending the delete request associated with your own successful rekeying > of the IKE SA until those outstanding requests have been responded to. > > If you follow 4718 the only request you can have outstanding when you > send a non-error response to an IKE SA rekey request is your own request > to rekey the IKE SA. The proposed solution in RFC4718 does not really work, so I do not think we should include that to RFC4306 (yes, I know I should have noticed this when RFC4718 was being processed not now, but better now than never). > >Not really. The RFC4306 do say that you MUST be able to process > >incoming requests while having your own requests out: > > > >2.3. Window Size for Overlapping Requests > >... > > .... An > > IKE endpoint MUST be prepared to accept and process a request while > > it has a request outstanding in order to avoid a deadlock in this > > situation. An IKE endpoint SHOULD be prepared to accept and process > > multiple requests while it has a request outstanding. > > > I see nothing in this text that says you must delay deleting the IKE SA > or accept new requests on an IKE SA that you've rekeyed. That is what > you wish to do and that is a protocol change. The text above implies that regardless what you do you should be able to allow other end to start exchanges and process them. I.e. IKEv2 protocol tries to be specified in such way that both ends can start exchanges at any times and expect them to either fail or succeed and get reply back, but not stay in situation where you do not know, whether other end processed your request or not. If you delete the IKE SA immediately that will happen. > >I.e. when you have REKEY started and even when the rekey itself has > >finished, and delete request sent out (and even replied), you still > >might receive requests from the other end which were started before > >the REKEY was started. > > If RFC 4718 is followed the only outstanding create child request that > can be received is a request to rekey the IKE SA. There is little > value in waiting for this. When the peer receives the request to > delete that IKE SA it will know one of two things happened. As the RFC4718 text can make situatuation much worse by causing live lock, I think that solution proposed there isn't usable as is. > As I said above there are only 2 reasons for getting the delete, so > strike the most likely from my original text. If RFC 4718 is followed > the receiver of the delete request can deterministically conclude that > any outstanding create child requests will fail. In addition, the only > outstanding create child request possible in this case is one to rekey > the IKE SA. Informational RFC 4718 proposes much bigger change to the standard track RFC 4306 than what I want to do and also the solution has problems which needs to fixed first before it can be taken to IKEv2bis. I would propose much smaller change to the RFC4306, which says that wait a while before deleting the IKE SA after successful rekey so that exchanges from other end has time to finish before deleting the IKE SA. Those exchanges happening after the IKE SA was rekeyed should either be failed or if they are processed, they should be processed in such way that they are done on the Child SAs which are already moved to new IKE SA (i.e. creating IPsec SAs or rekeying IPsec SAs should be failed, and deleting IPsec SAs should be processed, so that IPsec SAs is deleted from the IKE SA where it was moved to). > >The RFC4306 says what you need to do when you see simultaneous rekey, > >and it only gives you one option: Check for the nonces. The rekey is > >simultaneous, if either end detects it was simultanoues, it is > >completely possible that other end didn't notice it. > > RFC 4306 does not say that. RFC 4306 never uses the term simultaneous > rekey. What it does say is: > > If redundant SAs are created though such a collision, the SA > created with the lowest of the four nonces used in the two exchanges > SHOULD be closed by the endpoint that created it. > > If only one host detects the simultaneous rekey then redundant SAs > are not created. By adding a timer to delay sending the delete you > are going out of the way to try to create redundant SAs. That is not my reading of the text. But I think it is bit pointless to argue about this text as I think we can only agree that it is not clear. There is nothing there in RFC4306 to say that you cannot wait after doing rekey of IKE sa, and as that is only way to properly and cleanly process other ends exchanges to end before deleting the SA, that is what implementation should do. If that cause redundant SAs to be created then then we do have those and we need to check nonces to check which of them should be deleted. The RFC4718 text is NOT in RFC4306, that is one (broken) proposal to try to solve this problem. The text in RFC4718 even says "Our poposal is at follows" which would indicate that it was not really meant to be final protocol for that case. > I suspect that many vendors did what we did with regards to RFC 4718. > We implemented what RFC 4718 suggested. RFC 4718 was the starting > point for the IKEv2bis work. I see no reason to reinvent solutions > contained in RFC 4718. Mostly that is true, but we should not include broken proposals from RFC4718 to IKEv2bis, but instead we should try to find solution that works. > I do not agree that we should encourage people to go out of their way > to detect a simultaneous IKE SA rekey. I'm fine with allowing an > implementation to do that. I think MAY is the correct way to go. Implementation needs to still have the code that detects the simultaneous rekey, and other end might still use this delay, thus you need to be able to cope with the case where this happens. Implementations need to be able to handle both cases regardless whether we use SHOULD or MAY, only thing that is different is whether they allow other end finish exchanges or not. -- kivinen@iki.fi From denghui02@gmail.com Sun Oct 11 00:48:55 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D613A681F for ; Sun, 11 Oct 2009 00:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] 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 uNHfMklguyOC for ; Sun, 11 Oct 2009 00:48:55 -0700 (PDT) Received: from mail-qy0-f188.google.com (mail-qy0-f188.google.com [209.85.221.188]) by core3.amsl.com (Postfix) with ESMTP id D5B593A6811 for ; Sun, 11 Oct 2009 00:48:54 -0700 (PDT) Received: by qyk26 with SMTP id 26so7011117qyk.5 for ; Sun, 11 Oct 2009 00:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=DBO+4fNmplwuMp6o4QPIY9IRoZDDSMn64lbxtFLFOqk=; b=ivX55Pcdup/fiUjBx11/qczFn3Sg33l8lvrqfSszIVFVe3aP0VsC8s4522Fn7QaCby uinG9+uuldc5Quf7BDy3ha3g2LrjBSEWNrPGSZ5SQ6miLyuSVtluQiSO+nRsvsObA2jk FY8qeNrvleZW7EdTl/B2C6djVJd+0zN2dsj8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=paVP9evOWBrYvO+z2+eVBtxeezj3Q3cwW49QxV1yf8EHXPKDKCzR99cpQBAYBMEQ4z ezjiNwqK4TCDnfoaog8AHetR2wCyEt5wJ6jEfpjJH+16dJyg1k5Z70NWDbiS24c5ALmy 1fu6hE090zMOoaMxxTyuLXeHkbohnSxelgd/E= MIME-Version: 1.0 Received: by 10.224.111.198 with SMTP id t6mr3951065qap.324.1255247440879; Sun, 11 Oct 2009 00:50:40 -0700 (PDT) Date: Sun, 11 Oct 2009 15:50:40 +0800 Message-ID: <1d38a3350910110050tecbdb19o49fc38255e7929fc@mail.gmail.com> From: Hui Deng To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [IPsec] Difference between IPv4 and IPv6 IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 07:48:55 -0000 Dear IPsec forks, May I get advice about the differnce between them: 1) IPv4 doesn't mandate the support IPsec, IPv6 also doesn't mandate it based on RFC? 2) Most IPv4 hosts have(Linux, BSD, Windows) by default implemented IPsec(IKE), but don't launch it, need more configuration? Most IPv6 hosts haven't by default implemented IPsec(IKE), it need further download and configuration? 3) IPv4 IPsec need traversal NAT, but IPv6 don't need it, so it could support more about end to end other than site to site. 4) IPv6 IPsec support is based on extension header which is different from IPv4, it may more closer to the kernal level implementation. thanks for the discussion. best regards, -Hui From ynir@checkpoint.com Sun Oct 11 03:13:42 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23BE33A6890 for ; Sun, 11 Oct 2009 03:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] 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 jFg9fiSfSOwp for ; Sun, 11 Oct 2009 03:13:41 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 03F893A681E for ; Sun, 11 Oct 2009 03:13:41 -0700 (PDT) X-CheckPoint: {4AD1AE6F-1-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 5D91929C00C; Sun, 11 Oct 2009 12:15:25 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4754529C005; Sun, 11 Oct 2009 12:15:25 +0200 (IST) X-CheckPoint: {4AD1AE6B-2-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9BAFNSt029230; Sun, 11 Oct 2009 12:15:24 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 11 Oct 2009 12:15:27 +0200 From: Yoav Nir To: Hui Deng Date: Sun, 11 Oct 2009 12:15:21 +0200 Thread-Topic: [IPsec] Difference between IPv4 and IPv6 IPsec Thread-Index: AcpKW8AlQ/AfHGvsQjO2NEZMeuwgOA== Message-ID: <9FBA7378-8B7F-458C-BCDA-A72AC45229B5@checkpoint.com> References: <1d38a3350910110050tecbdb19o49fc38255e7929fc@mail.gmail.com> In-Reply-To: <1d38a3350910110050tecbdb19o49fc38255e7929fc@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-5--76468588"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Difference between IPv4 and IPv6 IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 10:13:42 -0000 --Apple-Mail-5--76468588 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi Hui I think there is very little difference between IPv4 and IPv6 as regards to IPsec. See below On Oct 11, 2009, at 9:50 AM, Hui Deng wrote: > Dear IPsec forks, > > May I get advice about the differnce between them: > 1) IPv4 doesn't mandate the support IPsec, IPv6 also doesn't mandate > it based on RFC? IPv4 does not mandate it, because IPv4 predates IPsec. RFC 4294 says in section 8.1: Security Architecture for the Internet Protocol [RFC-4301] MUST be supported. > 2) Most IPv4 hosts have(Linux, BSD, Windows) by default implemented > IPsec(IKE), but don't launch it, need more configuration? > Most IPv6 hosts haven't by default implemented IPsec(IKE), it need > further download and configuration? IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other OS. With most of them, the latest versions support IPv6 for IKE and IPsec. > 3) IPv4 IPsec need traversal NAT, but IPv6 don't need it, so it could > support more about end to end other than site to site. That is assuming that IPv6 does not have NAT. I don't think we have enough implementation experience to say that for sure. > 4) IPv6 IPsec support is based on extension header which is different > from IPv4, it may more closer to the kernal level implementation. I don't see why this would necessarily be true. > > thanks for the discussion. > best regards, > > -Hui --Apple-Mail-5--76468588 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTAxMTEw MTUyMlowIwYJKoZIhvcNAQkEMRYEFIna9evIIxDKqcaNzH2VfvtnZGQFMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQAkXUvyp3iy R7L/GQVzRjrETWKqMr9UX37OeSgx9nMC1zKtU6VMJFz0GRgCj9hJ3ks2BBSf+xQ48yxki/mnLmtm 9NqThYeIQa3NnRw7b4ffn0tDD0DBVNtRycz4Xg624iJomh/VPBm248Xwftrxt53RnGHmKimgQ8i0 /VaBZJRgA3j7PnpyoL5zs2WHKhdMfzkhgolc5xTeiYRKVcaVBo6S7982r3m0cqCNmJEn80haXQGc 6TNkBChMCzNRTx1yCV0Swokbvy4SY860ZBhYYT7OkmsBwn0lbcqiqRKKE3nVBnwOcVFvkb5F3scT Y8RLbzGbRoU2ApGZXLMQqaLN6e2hAAAAAAAA --Apple-Mail-5--76468588-- From Pasi.Eronen@nokia.com Mon Oct 12 23:46:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11D028C0FE for ; Mon, 12 Oct 2009 23:46:00 -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=[AWL=0.000, 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 5r8bB5AruYJO for ; Mon, 12 Oct 2009 23:46:00 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 9CDCA3A6914 for ; Mon, 12 Oct 2009 23:45:59 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9D6juEC017515 for ; Tue, 13 Oct 2009 09:45:57 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 09:45:20 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 09:45:16 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 13 Oct 2009 08:45:15 +0200 From: To: Date: Tue, 13 Oct 2009 08:45:13 +0200 Thread-Topic: Transform IDs for AES-GMAC in IKEv1 Thread-Index: AcnJdf/ibfpukJqqRGyuUWXawxE4giCWkSdA Message-ID: <808FD6E27AD4884E94820BC333B2DB773C099C1111@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F24D5096@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F24D5096@NOK-EUMSG-01.mgdnok.nokia.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Oct 2009 06:45:16.0174 (UTC) FILETIME=[B8F3B2E0:01CA4BD0] X-Nokia-AV: Clean Subject: Re: [IPsec] Transform IDs for AES-GMAC in IKEv1 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 06:46:01 -0000 This took a bit longer than expected, but the IKEv1 transform IDs have now been allocated by IANA, and they're listed in=20 errata for RFC 4543: http://www.iana.org/assignments/isakmp-registry http://www.rfc-editor.org/errata_search.php?rfc=3D4543&eid=3D1821 (Big thanks to Tero for his help with the details!) Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Eronen Pasi (Nokia-NRC/Helsinki) > Sent: 30 April, 2009 12:28 > To: ipsec@ietf.org > Subject: [IPsec] Transform IDs for AES-GMAC in IKEv1 >=20 > Hi, >=20 > RFC 4543 specifies how to use AES-GMAC mode in AH and ESP and how to > negotiate them in IKEv1 and IKEv2 (see Section 5, 1st paragraph). >=20 > However, as Soo-Fei Chew pointed out, the IANA considerations text in > the final document didn't actually ask IANA to assign the numbers for > IKEv1. >=20 > Here's my proposal for fixing the situation: >=20 > (1) ask IANA to assign the four missing numbers (after IESG approval). >=20 > (2) submit an RFC Editor errata, saying something like this: >=20 > The following text should have been included in Section 9: >=20 > For the negotiation of AES-GMAC in AH with IKEv1, the following > values have been assigned in the IPsec AH Transform Identifiers > registry (in isakmp-registry). Note that IKEv1 and IKEv2 use > different transform identifiers. >=20 > "TBD1" for AH_AES_128_GMAC >=20 > "TBD2" for AH_AES_192_GMAC >=20 > "TBD3" for AH_AES_256_GMAC >=20 > For the negotiation of AES-GMAC in ESP with IKEv1, the following > value has been assigned from the IPsec ESP Transform Identifiers > registry (in isakmp-registry). Note that IKEv1 and IKEv2 use a > different transform identifier. >=20 > "TBD4" for ESP_NULL_AUTH_AES_GMAC >=20 > (where we will in TBD1..4 after we know the numbers) >=20 > (3) ask IANA to include a pointer to this errata in the isakmp-registry > entries. >=20 > Does this sound like a reasonable plan? >=20 > Best regards, > Pasi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf@checkpoint.com Tue Oct 13 10:29:46 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC9893A67A1 for ; Tue, 13 Oct 2009 10:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, 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 7oh704gQ9zpx for ; Tue, 13 Oct 2009 10:29:45 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 6FACD3A6784 for ; Tue, 13 Oct 2009 10:29:44 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9DHTihu004032 for ; Tue, 13 Oct 2009 19:29:44 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 13 Oct 2009 19:29:46 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 13 Oct 2009 19:29:43 +0200 Thread-Topic: WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 Thread-Index: Aco3tm1PwjhKz10dR12UPAjGGViKfwAHoecgBRU7DtA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BD9338E802@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@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-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 17:29:46 -0000 Hi everyone, To date we've had only two last call reviews of this document. Please consi= der this a personal invitation to be the lucky third. We simply cannot adva= nce the document unless we're convinced it's had adequate review. We are hereby extending the WGLC by another 2 weeks, until Oct. 27. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Yaron Sheffer > Sent: Thursday, September 17, 2009 23:28 > To: ipsec@ietf.org > Subject: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 >=20 > This is to begin a 2 week working group last call for draft-ietf-ipsecme- > esp-null-heuristics-01. The target status for this document is > Informational. >=20 > Please send your comments to the ipsec list by Oct. 1, 2009, as follow-up= s > to this message. >=20 > Note that this document has had very little review until now. We will onl= y > progress it as a WG document if we have at least 3 non-editor, non-WG > chair reviewers who have read it and approve of it. And yes, this means > the pseudocode, too. There has been strong support of ESP-null detection, > so this document is likely to be widely implemented. Your review will mea= n > a lot to the technical quality of this document. >=20 > Please clearly indicate the position of any issue in the Internet Draft, > and if possible provide alternative text. Please also indicate the nature > or severity of the error or correction, e.g. major technical, minor > technical, nit, so that we can quickly judge the extent of problems with > the document. >=20 > The document can be accessed here: > http://tools.ietf.org/html/draft-ietf-ipsecme-esp-null-heuristics-01 >=20 > Thanks, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yaron >=20 >=20 > Email secured by Check Point >=20 > Email secured by Check Point > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From Nicolas.Williams@sun.com Tue Oct 13 11:53:16 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F2328C1E1 for ; Tue, 13 Oct 2009 11:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, MANGLED_LIST=2.3, 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 R6U-jJkMiLbi for ; Tue, 13 Oct 2009 11:53:15 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 17C293A6856 for ; Tue, 13 Oct 2009 11:53:15 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9DIrE7U004183 for ; Tue, 13 Oct 2009 18:53:15 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9DIrEES001936 for ; Tue, 13 Oct 2009 12:53:14 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9DIYPuQ008854; Tue, 13 Oct 2009 13:34:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9DIYPxd008853; Tue, 13 Oct 2009 13:34:25 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 13 Oct 2009 13:34:25 -0500 From: Nicolas Williams To: Yaron Sheffer Message-ID: <20091013183424.GH887@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BD9338E802@il-ex01.ad.checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BD9338E802@il-ex01.ad.checkpoint.com> User-Agent: Mutt/1.5.7i Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 18:53:16 -0000 - Section 7, 1st paragraph: MOBIKE is mentioned without a reference. - Section 7, 2nd paragraph: s/avare/aware/ - Section 8.1, next to last sentence: this sentence is grammatically incorrect, I think. How about: If the protocol (also known as the, "next header") of thepacket is one that is not supported by the heuristics, then detecting the IV length is impossible, thus the heuristics cannot finish. - Section 8.2, 2nd paragraph: s/shorted/shortest/ - Section 8.2, 2nd paragraph, 2nd sentence: s/implementation/the implementation/ - Section 8.2, 2nd paragraph, 2nd sentence: s/valid looking/valid-looking/ - Section 8.2, bottom of page 15: s/insure/ensure/ (yes, nowadays your use if 'insure' in this way is quite common) - Section 8.2, next to last paragraph, next to last sentence: I'm not sure what is meant. Can you try to re-write this sentence? How about: By counting how many "unsure" returns obtained via heuristics, and after the receipt of a consistent, but unknown, next-header number in same location (i.e., likely with the same ICV length), the node can conclude that that flow has a high probability of being ESP-NULL (since it's unlikely that so many packets would pass the integrity check at the destination unless they were legitimate). (The key change is the addition of a comma and moving a clause into a parenthetical.) - Section 8.3, 1st paragraph, 2nd sentence: this sentence is grammatically incorrect, and I'm unsure as to what is meant. I think what is meant is that if an intermediate node has seen a stateful ULP flow over an ESP-NULL flow, and later the SA is changed and the new flow looks like ESP-NULL and appears to contain a next protocol header that matches that previously-seentateful ULP flow, then chances are very good that the old ESP-NULL flow is abandoned and replaced by the new one. In such situations the intermediate node can simply change the old ESP-NULL state's lookup key. - Section 8.3.1, 1st paragraph, 1st sentence: s/feed/fed/ - Section 8.3.1, third paragraph: are you suggesting that intermediate nodes drop TCP-looking packets to elicit retransmission? - Section 9, 1st paragraph, 1st sentence, I think you may want to make this change: s/unless that is not/unless that is/ - Section 9, 1st paragraph, 1st sentence: this is an odd sentence construction. How about: Attackers can always bypass ESP-NULL deep packet inspection by using encrypted ESP (or some other encryption or tunneling method) instead, unless the intermediate node's policy requires dropping of packets that it cannot inspect. - Section 9, 1st paragraph, 2nd sentence, rewrite: Ultimately the responsibility for performing deep inspection, or allowing intermediate nodes to perform deep inspection, must rest on the end nodes. - Section 9, 1st paragraph, last sentence: s/but in that/in which/ - Section 10.2, an informative reference to MOBIKE is needed. What about multicast IPsec? Done. Nico -- From Nicolas.Williams@sun.com Tue Oct 13 11:54:12 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C403A6A41 for ; Tue, 13 Oct 2009 11:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.596 X-Spam-Level: X-Spam-Status: No, score=-3.596 tagged_above=-999 required=5 tests=[AWL=2.450, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 2n2+pa1Pk1o6 for ; Tue, 13 Oct 2009 11:54:12 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id E8FB228C242 for ; Tue, 13 Oct 2009 11:54:11 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9DIsCnC017173 for ; Tue, 13 Oct 2009 18:54:12 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9DIsCA8002633 for ; Tue, 13 Oct 2009 12:54:12 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9DIZNDl008866; Tue, 13 Oct 2009 13:35:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9DIZNDu008865; Tue, 13 Oct 2009 13:35:23 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 13 Oct 2009 13:35:23 -0500 From: Nicolas Williams To: Yaron Sheffer Message-ID: <20091013183523.GC8079@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BD9338E802@il-ex01.ad.checkpoint.com> <20091013183424.GH887@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091013183424.GH887@Sun.COM> User-Agent: Mutt/1.5.7i Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 18:54:12 -0000 Note: I did not review the appendix nor its sub-sections. From Nicolas.Williams@sun.com Tue Oct 13 12:13:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91563A67B6 for ; Tue, 13 Oct 2009 12:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.821 X-Spam-Level: X-Spam-Status: No, score=-4.821 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 qznG44haIKek for ; Tue, 13 Oct 2009 12:13:49 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 1D8D73A67F8 for ; Tue, 13 Oct 2009 12:13:49 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9DJDlRO014184 for ; Tue, 13 Oct 2009 19:13:47 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9DJDkWd016579 for ; Tue, 13 Oct 2009 13:13:46 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9DIswgt008887; Tue, 13 Oct 2009 13:54:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9DIswkq008886; Tue, 13 Oct 2009 13:54:58 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 13 Oct 2009 13:54:58 -0500 From: Nicolas Williams To: Yaron Sheffer Message-ID: <20091013185457.GD8079@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BD9338E802@il-ex01.ad.checkpoint.com> <20091013183424.GH887@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091013183424.GH887@Sun.COM> User-Agent: Mutt/1.5.7i Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 19:13:49 -0000 On Tue, Oct 13, 2009 at 01:34:24PM -0500, Nicolas Williams wrote: > Done. One more comment: - State keeping by intermediate nodes is described as an optimization, however: a) I'm not sure that that necessarily follows, since state keeping and cache index lookups are not free, and anyways, b) in some cases, particularly where the next header is TCP or UDP, state keeping appears to be a requirement for establishing confidence in heuristics results. (b) is the key issue. Some advice on state cache sizing may be useful. E.g., if an entry is dropped out of the cache due to cache pressure, how costly will that be in terms of additional inspection effort for future packets for that flow, and in terms of resulting future cache pressure? Nico -- From paul.hoffman@vpnc.org Tue Oct 13 13:06:47 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC6C3A6975 for ; Tue, 13 Oct 2009 13:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, 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 wWEkHbehScCp for ; Tue, 13 Oct 2009 13:06:47 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 22AB93A696B for ; Tue, 13 Oct 2009 13:06:47 -0700 (PDT) Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9DK6l6f083625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Oct 2009 13:06:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20091013183523.GC8079@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BD9338E802@il-ex01.ad.checkpoint.com> <20091013183424.GH887@Sun.COM> <20091013183523.GC8079@Sun.COM> Date: Tue, 13 Oct 2009 13:06:45 -0700 To: Nicolas Williams From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 20:06:47 -0000 Thanks, Nico! However... At 1:35 PM -0500 10/13/09, Nicolas Williams wrote: >Note: I did not review the appendix nor its sub-sections. Please do. :-) Seriously, folks, the appendix is pretty important, inasmuch as some developers will pay more attention to it than they do the main body. It would be really good to have some folks review it to make sure that they proposed checks and actions match those of the main body, and that they seem sane. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue Oct 13 13:12:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED3B3A698F for ; Tue, 13 Oct 2009 13:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.817 X-Spam-Level: X-Spam-Status: No, score=-3.817 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, 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 0cualnfnO35Z for ; Tue, 13 Oct 2009 13:12:34 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 1C89828C0DB for ; Tue, 13 Oct 2009 13:12:34 -0700 (PDT) Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9DKCX1V083959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Oct 2009 13:12:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 13 Oct 2009 13:12:32 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: Ron Bonica Subject: [IPsec] Request for review on two IPsec-related documents X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 20:12:35 -0000 Ron Bonica, one of the IETF's Operations and Management ADs, is asking for reviews of draft-ietf-bmwg-ipsec-term and draft-ietf-bmwg-ipsec-meth. Yaron and I have mentioned them at various meetings. These docs have been wandering forwards in the Benchmarking WG for many (many!) years, and are nearing completion. Having additional eyes on them now would really help BMWG with them. Please send any comments on them to the BMWG mailing list. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue Oct 13 14:05:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7CDA3A67F8 for ; Tue, 13 Oct 2009 14:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.002 X-Spam-Level: X-Spam-Status: No, score=-4.002 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, 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 B6IZax3LQLyH for ; Tue, 13 Oct 2009 14:05:43 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E7C5E3A6933 for ; Tue, 13 Oct 2009 14:05:42 -0700 (PDT) Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9DL5hF2087296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Oct 2009 14:05:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 13 Oct 2009 14:05:41 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Seeking interest in new charter items for the IPsecME WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 21:05:43 -0000 Greetings again. As Yaron and I have said many times in the past, when a few of our WG documents have been completed, we can think about adding additional items to our charter. We think that we will soon be at that point. For new items to be considered in the WG, we need to have an existing, personally-submitted Internet Draft, and four people (other than the authors) who are committed to reviewing the draft as it moves through the WG process. If you have an Internet Draft (or will have one very soon) that you think should be a WG item, please send Yaron and I a message off-list. Note that the cut-off for submitting new -00 drafts is this coming Monday; however, we will accept proposals without an Internet Draft if the author promises to have the draft submitted on Monday, November 9 when they are allowed to turn them in again. We will review the submissions, talk with the proposers a bit, and then have an discussion of the proposals at the Hiroshima face-to-face meeting, followed by more discussion on the mailing list post-Hiroshima. --Paul Hoffman, Director --VPN Consortium From g_e_montenegro@yahoo.com Tue Oct 13 14:07:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170EF3A681A for ; Tue, 13 Oct 2009 14:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 snrQ1trCJrzc for ; Tue, 13 Oct 2009 14:07:07 -0700 (PDT) Received: from web82608.mail.mud.yahoo.com (web82608.mail.mud.yahoo.com [68.142.201.125]) by core3.amsl.com (Postfix) with SMTP id 2F41F3A67F8 for ; Tue, 13 Oct 2009 14:07:07 -0700 (PDT) Received: (qmail 54373 invoked by uid 60001); 13 Oct 2009 21:07:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=J3wY0hQyUjcADUFpCAS+i8iGUBUi0K3hJmXNGV+bWqSHuAWmH5rMZ0gOpwbiTJU3RfVLU3lPv8Hq6NA+0ykMrmXKKg9vnQ2yYZTGRG6uNUqcT+KnacQphel/cvdJ1BOQeeTIoIngmdSvW2EclhiLMMNWj1CuDApTlD1HwuBuBGI=; Message-ID: <569256.53993.qm@web82608.mail.mud.yahoo.com> X-YMail-OSG: gCAphOoVM1k2LgAwarl8D.4H6z8xegFdiOCXbWoO9.r5kTTxToywH1ma1X8wqmrY6g9iE6iGv9KQuIuv5xlZ5idUZvy.8hVUxB4HEMMNAGZIxk5ydbmyq8ihII.c8QmBLwcnffx7QzVc4PEly4wfsMfb8AONzMav9CBJxliLjEhM1shAZQwBbSQZE5tx05JJqj7zhSEviDAiBGvFw50jI80GeYTQSjyXztup7rOsLHxusUkqfLh12LcSAf5FjEmnaOZ6y_1WxzZUYzXG8Ah5a2Xk.mH.a2b.vGhnnqt.jaNZkMpBejdAMpGOI7edih7hy.EwFmzzpVyUBMzNHd_QKn2ITRZPfXXL0WWAsOoiIZqqyoPvCu6vg0PTPpbG7jQtTYNo3vj8Ctn.EXsip0fP3UAljDzeixtElbQ8eykN9mMzDqU- Received: from [131.107.0.75] by web82608.mail.mud.yahoo.com via HTTP; Tue, 13 Oct 2009 14:07:04 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.347.3 References: <808FD6E27AD4884E94820BC333B2DB773C06B22D72@NOK-EUMSG-01.mgdnok.nokia.com> <19127.24553.76610.294336@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328491@il-ex01.ad.checkpoint.com> Date: Tue, 13 Oct 2009 14:07:04 -0700 (PDT) From: gabriel montenegro To: Yaron Sheffer , Tero Kivinen , "Grewal, Ken" In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328491@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 21:07:08 -0000 Just to make sure this does not fall through the cracks: we've submitted re= v 09 last week to address=0Athe AD review comments per discussion on the ma= iling list and at the virtual interim.=0A=0A=0A=0A----- Original Message --= --=0A> From: Yaron Sheffer =0A> To: Tero Kivinen ; "Grewal, Ken" =0A> Cc: "ipsec@ietf.org= " ; "Pasi.Eronen@nokia.com" =0A> Sen= t: Mon, September 21, 2009 5:40:19 AM=0A> Subject: Re: [IPsec] AD review co= mments for draft-ietf-ipsecme-traffic-visibility=0A> =0A> Hi Tero,=0A> =0A>= Given that the existing ESP header is integrity-protected, I don't see the= =0A> downside to adding the same protection for the new header. On the oth= er hand, =0A> this would eliminate a whole class of vulnerabilities. We sti= ll have a few =0A> reserved bits in the WESP header, and you don't want to = find out years down the =0A> road that they cannot be used because they're = not protected in transit.=0A> =0A> Thanks,=0A> =A0=A0=A0 Yaron=0A> =0A> > -= ----Original Message-----=0A> > From: ipsec-bounces@ietf.org [mailto:ipsec-= bounces@ietf.org] On Behalf Of=0A> > Tero Kivinen=0A> > Sent: Monday, Septe= mber 21, 2009 14:14=0A> > To: Grewal, Ken=0A> > Cc: ipsec@ietf.org; Pasi.Er= onen@nokia.com=0A> > Subject: Re: [IPsec] AD review comments for draft-ietf= -ipsecme-traffic-=0A> > visibility=0A> > =0A> > Grewal, Ken writes:=0A> > >= >- A question: did the WG discuss the pros and cons of integrity=0A> > > >= protecting the WESP header? (This does make WESP more complex to=0A> > > >i= mplement, and currently the WESP header does not contain any data=0A> > > >= that would benefit from integrity protection in any way.)=0A> > > [Ken] Thi= s change was the result of a discussion on threats posed by=0A> > > 'malwar= e', which could modify the WESP headers to obfuscate the=0A> > > payload fr= om inspection by intermediate nodes such as IDS/IPS=0A> > > systems.=0A> > = > The issue (ticket #104) was raised and closed some time back after=0A> > = > lengthy discussions on the topic.=0A> > > http://trac.tools.ietf.org/wg/i= psecme/trac/ticket/104=0A> > =0A> > As everything in the WESP header is som= ething that can be verified by=0A> > the recipient node why is the integrit= y protection needed?=0A> > =0A> > I think it would make implementation WESP= much easier if it can be=0A> > done as post processing step after ESP has = been applied, in a similar=0A> > way UDP encapsulation can be done to the E= SP packet.=0A> > --=0A> > kivinen@iki.fi=0A> > ____________________________= ___________________=0A> > IPsec mailing list=0A> > IPsec@ietf.org=0A> > htt= ps://www.ietf.org/mailman/listinfo/ipsec=0A> > =0A> > Scanned by Check Poin= t Total Security Gateway.=0A> =0A> Email secured by Check Point=0A> =0A> Em= ail secured by Check Point=0A> ____________________________________________= ___=0A> IPsec mailing list=0A> IPsec@ietf.org=0A> https://www.ietf.org/mail= man/listinfo/ipsec=0A From Pasi.Eronen@nokia.com Wed Oct 14 02:52:54 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230953A690B for ; Wed, 14 Oct 2009 02:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, 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 eanLgydNFBzL for ; Wed, 14 Oct 2009 02:52:53 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id D15543A6857 for ; Wed, 14 Oct 2009 02:52:52 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9E9qncv006722; Wed, 14 Oct 2009 12:52:50 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:52:47 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:52:47 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:52:42 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 14 Oct 2009 11:52:41 +0200 From: To: , , , Date: Wed, 14 Oct 2009 11:52:40 +0200 Thread-Topic: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility Thread-Index: AcpMSSdhuMAl5VoHTZCd4v1fY8CcZQAarmlQ Message-ID: <808FD6E27AD4884E94820BC333B2DB773C099FDDE3@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773C06B22D72@NOK-EUMSG-01.mgdnok.nokia.com> <19127.24553.76610.294336@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328491@il-ex01.ad.checkpoint.com> <569256.53993.qm@web82608.mail.mud.yahoo.com> In-Reply-To: <569256.53993.qm@web82608.mail.mud.yahoo.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Oct 2009 09:52:42.0353 (UTC) FILETIME=[129C2E10:01CA4CB4] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 09:52:54 -0000 Thanks -- I've asked the secretariat to start the IETF Last Call! Here are the first IETF Last Call comments (none of them major): =20 - The text about 8-octet alignment probably needs some small clarifications. For IPv6, 8-octet alignment is not optional, so "SHOULD" is not really correct. And there's an exception: if you're doing UDP encapsulation, the 0x00000002 SPI/protocol identifier takes four octets, so the IPv6Padding field isn't included in that case. - The bit numbers in Figure 4 aren't aligned. - [RFC3948] and [RFC5226] should be normative references, not informative. Best regards, Pasi > -----Original Message----- > From: ext gabriel montenegro [mailto:g_e_montenegro@yahoo.com] > Sent: 14 October, 2009 00:07 > To: Yaron Sheffer; Tero Kivinen; Grewal, Ken > Cc: ipsec@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) > Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic- > visibility >=20 > Just to make sure this does not fall through the cracks: we've > submitted rev 09 last week to address > the AD review comments per discussion on the mailing list and at the > virtual interim. >=20 >=20 >=20 > ----- Original Message ---- > > From: Yaron Sheffer > > To: Tero Kivinen ; "Grewal, Ken" > > > Cc: "ipsec@ietf.org" ; "Pasi.Eronen@nokia.com" > > > Sent: Mon, September 21, 2009 5:40:19 AM > > Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme- > traffic-visibility > > > > Hi Tero, > > > > Given that the existing ESP header is integrity-protected, I don't > see the > > downside to adding the same protection for the new header. On the > other hand, > > this would eliminate a whole class of vulnerabilities. We still have > a few > > reserved bits in the WESP header, and you don't want to find out > years down the > > road that they cannot be used because they're not protected in > transit. > > > > Thanks, > > =A0=A0=A0 Yaron > > > > > -----Original Message----- > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf Of > > > Tero Kivinen > > > Sent: Monday, September 21, 2009 14:14 > > > To: Grewal, Ken > > > Cc: ipsec@ietf.org; Pasi.Eronen@nokia.com > > > Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme- > traffic- > > > visibility > > > > > > Grewal, Ken writes: > > > > >- A question: did the WG discuss the pros and cons of integrity > > > > >protecting the WESP header? (This does make WESP more complex to > > > > >implement, and currently the WESP header does not contain any > data > > > > >that would benefit from integrity protection in any way.) > > > > [Ken] This change was the result of a discussion on threats posed > by > > > > 'malware', which could modify the WESP headers to obfuscate the > > > > payload from inspection by intermediate nodes such as IDS/IPS > > > > systems. > > > > The issue (ticket #104) was raised and closed some time back > after > > > > lengthy discussions on the topic. > > > > http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104 > > > > > > As everything in the WESP header is something that can be verified > by > > > the recipient node why is the integrity protection needed? > > > > > > I think it would make implementation WESP much easier if it can be > > > done as post processing step after ESP has been applied, in a > similar > > > way UDP encapsulation can be done to the ESP packet. > > > -- > > > kivinen@iki.fi > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > Scanned by Check Point Total Security Gateway. > > > > Email secured by Check Point > > > > Email secured by Check Point > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Wed Oct 14 04:36:29 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BCDD3A6940 for ; Wed, 14 Oct 2009 04:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LIST=2.3] 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 uCEn72nlCgaE for ; Wed, 14 Oct 2009 04:36:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D11993A68F0 for ; Wed, 14 Oct 2009 04:36:27 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9EBaLWb017894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Oct 2009 14:36:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9EBaKfk004131; Wed, 14 Oct 2009 14:36:20 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19157.47028.842967.590918@fireball.kivinen.iki.fi> Date: Wed, 14 Oct 2009 14:36:20 +0300 From: Tero Kivinen To: Nicolas Williams In-Reply-To: <20091013183424.GH887@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BD9338E802@il-ex01.ad.checkpoint.com> <20091013183424.GH887@Sun.COM> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 21 min X-Total-Time: 25 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 11:36:29 -0000 Nicolas Williams writes: > - Section 7, 1st paragraph: MOBIKE is mentioned without a reference. > - Section 7, 2nd paragraph: s/avare/aware/ > - Section 8.1, next to last sentence: this sentence is grammatically > incorrect, I think. How about: > If the protocol (also known as the, "next header") of thepacket is > one that is not supported by the heuristics, then detecting the IV > length is impossible, thus the heuristics cannot finish. > - Section 8.2, 2nd paragraph: s/shorted/shortest/ > - Section 8.2, 2nd paragraph, 2nd sentence: > s/implementation/the implementation/ > - Section 8.2, 2nd paragraph, 2nd sentence: > s/valid looking/valid-looking/ > - Section 8.2, bottom of page 15: s/insure/ensure/ (yes, nowadays your > use if 'insure' in this way is quite common) All fixed. > - Section 8.2, next to last paragraph, next to last sentence: I'm not > sure what is meant. Can you try to re-write this sentence? How > about: > > By counting how many "unsure" returns obtained via heuristics, and > after the receipt of a consistent, but unknown, next-header number > in same location (i.e., likely with the same ICV length), the node > can conclude that that flow has a high probability of being > ESP-NULL (since it's unlikely that so many packets would pass the > integrity check at the destination unless they were legitimate). > > (The key change is the addition of a comma and moving a clause into a > parenthetical.) Changed to: An intermediate node's policy, however, can aid in detecting an ESP-NULL flow even when the protocol is not a common-case one. By counting how many "unsure" returns obtained via heuristics, and after the receipt of a consistent, but unknown, next-header number in same location (i.e. likely with the same ICV length), the node can conclude that the flow has high probability of being ESP-NULL (since it is unlikely that so many packets would pass the integrity check at the destination unless they are legitimate). The flow can be classified as ESP-NULL with a known ICV length, but an unknown IV length. > - Section 8.3, 1st paragraph, 2nd sentence: this sentence is > grammatically incorrect, and I'm unsure as to what is meant. This was commented already by others and was changed to: For example, when many TCP / UDP flows are established over one SA, a rekey produces a new SA which needs heuristics and will benefit from the existing flows. > I think what is meant is that if an intermediate node has seen a > stateful ULP flow over an ESP-NULL flow, and later the SA is changed > and the new flow looks like ESP-NULL and appears to contain a next > protocol header that matches that previously-seentateful ULP flow, > then chances are very good that the old ESP-NULL flow is abandoned > and replaced by the new one. In such situations the intermediate > node can simply change the old ESP-NULL state's lookup key. Yes. That was what I tried to say. Do you think my already changed sentence is ok, or do we need to explain it more. > - Section 8.3.1, 1st paragraph, 1st sentence: s/feed/fed/ Fixed. > - Section 8.3.1, third paragraph: are you suggesting that intermediate > nodes drop TCP-looking packets to elicit retransmission? It says that "if a packets is dropped", i.e. it does not say whether the intermediate node does or does not do it, as that depends on the policy. If the intermediate node's policy is that no packets go through before they can be inspected meaning ESP-NULL detection needs to finish first before they can be inspected, that will cause all packets to be dropped while heuristics is in progress. This will cause next packets to be retransmissions. If the policy is so that packets are passed, even when we cannot yet inspect them, then the next packet still might be to the same flow. > - Section 9, 1st paragraph, 1st sentence, I think you may want to make > this change: > s/unless that is not/unless that is/ Yes. Fixed that. > - Section 9, 1st paragraph, 1st sentence: this is an odd sentence > construction. How about: > Attackers can always bypass ESP-NULL deep packet inspection by > using encrypted ESP (or some other encryption or tunneling method) > instead, unless the intermediate node's policy requires dropping > of packets that it cannot inspect. > - Section 9, 1st paragraph, 2nd sentence, rewrite: > Ultimately the responsibility for performing deep inspection, or > allowing intermediate nodes to perform deep inspection, must rest > on the end nodes. > - Section 9, 1st paragraph, last sentence: s/but in that/in which/ Ok, took all of those in, here is the current version of section 9: Attackers can always bypass ESP-NULL deep packet inspection by using encrypted ESP (or some other encryption or tunneling method) instead, unless the intermediate node's policy requires dropping of packets that it cannot inspect. Ultimately the responsibility for performing deep inspection, or allowing intermediate nodes to perform deep inspection, must rest on the end nodes. I.e. if a server allows encrypted connections also, then attacker who wants to attack the server and wants to bypass deep inspection device in the middle, will use encrypted traffic. This means that the protection of the whole network is only as good as the policy enforcement and protection of the end node. One way to enforce deep inspection for all traffic, is to forbid encrypted ESP completely, in which case ESP-NULL detection is easier, as all packets must be ESP-NULL based on the policy, and further restriction can eliminate ambiguities in ICV and IV sizes. > - Section 10.2, an informative reference to MOBIKE is needed. What > about multicast IPsec? Added reference to MOBIKE. I do not think multicast IPsec requires any special handling as the level what we need for them is already in the RFC4301/RFC4303. We do not really care about the keying protocols, we only care about the ESP packets and we use source address, destination address and SPI to indicate IPsec flow as specified in the RFC4301 and RFC4303. -- kivinen@iki.fi From wwwrun@core3.amsl.com Wed Oct 14 07:03:16 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4BE6A3A6A06; Wed, 14 Oct 2009 07:03:15 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20091014140316.4BE6A3A6A06@core3.amsl.com> Date: Wed, 14 Oct 2009 07:03:16 -0700 (PDT) Cc: ipsec@ietf.org, ipv6@ietf.org Subject: [IPsec] Last Call: draft-ietf-ipsecme-traffic-visibility (Wrapped ESP for Traffic Visibility) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 14:03:16 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Wrapped ESP for Traffic Visibility ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17941&rfc_flag=0 From caozhenpku@gmail.com Wed Oct 14 08:29:19 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D52128C172 for ; Wed, 14 Oct 2009 08:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] 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 eUiqabqHRHW2 for ; Wed, 14 Oct 2009 08:29:17 -0700 (PDT) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id AF2A428C158 for ; Wed, 14 Oct 2009 08:29:17 -0700 (PDT) Received: by pxi42 with SMTP id 42so1235406pxi.5 for ; Wed, 14 Oct 2009 08:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZMcJJiJjmGtL2cyUz2ZsSbaKOtJdErenq2pO/zX84Ao=; b=DhgVlKGl/GytferNiWPGtebxQmMW9BYR9VVw2E8OjF0iftycMuLJ/MsAH5uTfURwmk imSsDB8aqqeO2WetUyGAHTXlttK4RuP6KgEAHxxKmL5qnb5MByQvk2neRk8VzfEyXqqV pEMwVu5MUYIkv5Bo8nIYBtE75CC5h5pNEoiyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SrvOwSpwiKP0frhwVZ5gzjUapyqsxRMXjyzizDwPQOK3hBb+b63+pLPy7Hyz4RN5x+ 64ahLVP0t/33I9RgSazliSF1yDAE/8G8pKTaf3NasxUuHkrSIXpTEbNR5nCIkxD+1KLH WDaLCH4fb9DdyDH1ac1P76ifty1VauSkpNvxo= MIME-Version: 1.0 Received: by 10.143.27.32 with SMTP id e32mr681474wfj.244.1255534157245; Wed, 14 Oct 2009 08:29:17 -0700 (PDT) In-Reply-To: <9FBA7378-8B7F-458C-BCDA-A72AC45229B5@checkpoint.com> References: <1d38a3350910110050tecbdb19o49fc38255e7929fc@mail.gmail.com> <9FBA7378-8B7F-458C-BCDA-A72AC45229B5@checkpoint.com> Date: Wed, 14 Oct 2009 23:29:17 +0800 Message-ID: From: Zhen Cao To: Yoav Nir Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Hui Deng , IPsecme WG Subject: Re: [IPsec] Difference between IPv4 and IPv6 IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 15:29:19 -0000 On Sun, Oct 11, 2009 at 6:15 PM, Yoav Nir wrote: > Hi Hui > > I think there is very little difference between IPv4 and IPv6 as regards = to > IPsec. See below > > On Oct 11, 2009, at 9:50 AM, Hui Deng wrote: > >> Dear IPsec forks, >> >> May I get advice about the differnce between them: >> 1) IPv4 doesn't mandate the support IPsec, IPv6 also doesn't mandate >> it based on RFC? > > IPv4 does not mandate it, because IPv4 predates IPsec. RFC 4294 says in > section 8.1: > > =A0 Security Architecture for the Internet Protocol [RFC-4301] MUST be > =A0 supported. > >> 2) Most IPv4 hosts have(Linux, BSD, Windows) by default implemented >> IPsec(IKE), but don't launch it, need more configuration? >> =A0 Most IPv6 hosts haven't by default implemented IPsec(IKE), it need >> further download and configuration? > > IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other OS. Wi= th > most of them, the latest versions support IPv6 for IKE and IPsec. I guess we do not need tunnel model for IPv6 ipsec? > >> 3) IPv4 IPsec need traversal NAT, but IPv6 don't need it, so it could >> support more about end to end other than site to site. > > That is assuming that IPv6 does not have NAT. I don't think we have enoug= h > implementation experience to say that for sure. Can it be at-least considered one advantage of IPv6 IPSEC? Another point is: "One possible advantage for IPv6 IPsec is that IPv6=92s extension header chaining feature, which is not present in IPv4, could be used to authenticate a secure host-to-host scenario exchange to a third party gateways which would provide authorized access into and out of secure enclaves". -quote from http://www.commandinformation.com/blog/?p=3D98. Is this valid? Thanks for discussion. > >> 4) IPv6 IPsec support is based on extension header which is different >> from IPv4, it may more closer to the kernal level implementation. > > I don't see why this would necessarily be true. > >> >> thanks for the discussion. >> best regards, >> >> -Hui > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > From kent@bbn.com Wed Oct 14 09:48:30 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7089028C1AC for ; Wed, 14 Oct 2009 09:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599] 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 HIZVW7J8Fe2y for ; Wed, 14 Oct 2009 09:48:29 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id CDCE028C191 for ; Wed, 14 Oct 2009 09:48:08 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1My65B-00020Y-Fu; Wed, 14 Oct 2009 11:48:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <1d38a3350910110050tecbdb19o49fc38255e7929fc@mail.gmail.com> <9FBA7378-8B7F-458C-BCDA-A72AC45229B5@checkpoint.com> Date: Wed, 14 Oct 2009 12:48:05 -0400 To: Zhen Cao From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Hui Deng , IPsecme WG , Yoav Nir Subject: Re: [IPsec] Difference between IPv4 and IPv6 IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 16:48:30 -0000 At 11:29 PM +0800 10/14/09, Zhen Cao wrote: >O... > > IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other OS. With > > most of them, the latest versions support IPv6 for IKE and IPsec. > >I guess we do not need tunnel model for IPv6 ipsec? what makes you say that? unnelT mode is still needed for SG-SG SAs, or host-SG SAs. > >> >>> 3) IPv4 IPsec need traversal NAT, but IPv6 don't need it, so it could >>> support more about end to end other than site to site. > > >> That is assuming that IPv6 does not have NAT. I don't think we have enough >> implementation experience to say that for sure. > >Can it be at-least considered one advantage of IPv6 IPSEC? Not really. >Another point is: "One possible advantage for IPv6 IPsec is that >IPv6's extension header chaining feature, which is not present in >IPv4, could be used to authenticate a secure host-to-host scenario >exchange to a third party gateways which would provide authorized >access into and out of secure enclaves". -quote from >http://www.commandinformation.com/blog/?p=98. Is this valid? I think that is an unlikely scenario, if only due to key management issues. Steve From Fayyaz_Khan@mentor.com Wed Oct 14 10:50:04 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0DA3A6966 for ; Wed, 14 Oct 2009 10:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 Cg5k4sXjH85o for ; Wed, 14 Oct 2009 10:50:03 -0700 (PDT) Received: from relay1.mentorg.com (relay1.mentorg.com [192.94.38.131]) by core3.amsl.com (Postfix) with ESMTP id 955563A6802 for ; Wed, 14 Oct 2009 10:50:03 -0700 (PDT) Received: from nat-dem.mentorg.com ([139.181.124.2] helo=eu2-mail.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1My7zB-0005gY-EY from Fayyaz_Khan@mentor.com ; Wed, 14 Oct 2009 10:50:05 -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: Wed, 14 Oct 2009 19:50:02 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Difference between IPv4 and IPv6 IPsec Thread-Index: AcpM7jMc8E3C/dYnTuepUqCooQBthAABFoKg From: "Khan, Fayyaz" To: "Stephen Kent" , "Zhen Cao" Cc: Hui Deng , IPsecme WG , Yoav Nir Subject: Re: [IPsec] Difference between IPv4 and IPv6 IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 17:50:04 -0000 =20 I would also add a few cents. At 11:29 PM +0800 10/14/09, Zhen Cao wrote: >O... > > IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other OS. With > > most of them, the latest versions support IPv6 for IKE and IPsec. > >I guess we do not need tunnel model for IPv6 ipsec? >what makes you say that? unnelT mode is still needed for SG-SG SAs,=20 >or host-SG SAs. Also tunnel mode will still be required for IPv6 to 4 tunnels as long as IPv4 addresses exist and IPv6 nodes need to be interoperable with them. > >> >>> 3) IPv4 IPsec need traversal NAT, but IPv6 don't need it, so it could >>> support more about end to end other than site to site. > > >> That is assuming that IPv6 does not have NAT. I don't think we have enough >> implementation experience to say that for sure. > >Can it be at-least considered one advantage of IPv6 IPSEC? >Not really. Further motivations for NAT in IPv6 includes need for private networks i.e. a company wants to only have one machine to communicate with external world so every computer on that private network goes through that single machine. Also, cost of owning a live ip vs. hosting a private network behind a single live ip would still be attractive, even for security reasons too. >Another point is: "One possible advantage for IPv6 IPsec is that >IPv6's extension header chaining feature, which is not present in >IPv4, could be used to authenticate a secure host-to-host scenario >exchange to a third party gateways which would provide authorized >access into and out of secure enclaves". -quote from >http://www.commandinformation.com/blog/?p=3D98. Is this valid? >I think that is an unlikely scenario, if only due to key management issues. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From Nicolas.Williams@sun.com Wed Oct 14 10:57:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70AF3A6A13 for ; Wed, 14 Oct 2009 10:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[AWL=0.817, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Mwi-Q+h+itUY for ; Wed, 14 Oct 2009 10:57:42 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id C03EE3A6904 for ; Wed, 14 Oct 2009 10:57:42 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9EHvh9m020079 for ; Wed, 14 Oct 2009 17:57:43 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9EHvg4v032243 for ; Wed, 14 Oct 2009 11:57:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9EHcrDw010023; Wed, 14 Oct 2009 12:38:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9EHcqHB010022; Wed, 14 Oct 2009 12:38:52 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 14 Oct 2009 12:38:52 -0500 From: Nicolas Williams To: Tero Kivinen Message-ID: <20091014173852.GO887@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BD9338E802@il-ex01.ad.checkpoint.com> <20091013183424.GH887@Sun.COM> <19157.47028.842967.590918@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19157.47028.842967.590918@fireball.kivinen.iki.fi> User-Agent: Mutt/1.5.7i Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 17:57:44 -0000 On Wed, Oct 14, 2009 at 02:36:20PM +0300, Tero Kivinen wrote: > Nicolas Williams writes: > > - Section 8.3, 1st paragraph, 2nd sentence: this sentence is > > grammatically incorrect, and I'm unsure as to what is meant. > > This was commented already by others and was changed to: > > For example, when many TCP / UDP flows are established over > one SA, a rekey produces a new SA which needs heuristics and will > benefit from the existing flows. > > > I think what is meant is that if an intermediate node has seen a > > stateful ULP flow over an ESP-NULL flow, and later the SA is changed > > and the new flow looks like ESP-NULL and appears to contain a next > > protocol header that matches that previously-seentateful ULP flow, > > then chances are very good that the old ESP-NULL flow is abandoned > > and replaced by the new one. In such situations the intermediate > > node can simply change the old ESP-NULL state's lookup key. > > Yes. That was what I tried to say. Do you think my already changed > sentence is ok, or do we need to explain it more. Well, the heuristics will benefit from the information cached for the TCP/UDP flow over the previous SA. "...benefit from the existing flows" doesn't quite get that point across (though it's the only realistic meaning). > > - Section 8.3.1, third paragraph: are you suggesting that intermediate > > nodes drop TCP-looking packets to elicit retransmission? > > It says that "if a packets is dropped", i.e. it does not say whether > the intermediate node does or does not do it, as that depends on the > policy. If the intermediate node's policy is that no packets go > through before they can be inspected meaning ESP-NULL detection needs > to finish first before they can be inspected, that will cause all > packets to be dropped while heuristics is in progress. This will cause > next packets to be retransmissions. But surely actively trying to elicit retransmissions could be used as a way to get enough information to classify a flow... The retransmissions should have different MACs, thus retransmissions help resolve ambiguities, even if the policy isn't to drop packets that cannot be inspected. > If the policy is so that packets are passed, even when we cannot yet > inspect them, then the next packet still might be to the same flow. I see. Having a policy that says "drop packets that can't be inspected" actually helps resolve ambiguities if the end nodes retransmit. > > - Section 9, 1st paragraph, 1st sentence: this is an odd sentence > > construction. How about: > > Attackers can always bypass ESP-NULL deep packet inspection by > > using encrypted ESP (or some other encryption or tunneling method) > > instead, unless the intermediate node's policy requires dropping > > of packets that it cannot inspect. > > - Section 9, 1st paragraph, 2nd sentence, rewrite: > > Ultimately the responsibility for performing deep inspection, or > > allowing intermediate nodes to perform deep inspection, must rest > > on the end nodes. > > - Section 9, 1st paragraph, last sentence: s/but in that/in which/ > > Ok, took all of those in, here is the current version of section 9: > > Attackers can always bypass ESP-NULL deep packet inspection by > using encrypted ESP (or some other encryption or tunneling method) > instead, unless the intermediate node's policy requires dropping > of packets that it cannot inspect. Ultimately the responsibility > for performing deep inspection, or allowing intermediate nodes to > perform deep inspection, must rest on the end nodes. I.e. if a > server allows encrypted connections also, then attacker who wants > to attack the server and wants to bypass deep inspection device in > the middle, will use encrypted traffic. This means that the > protection of the whole network is only as good as the policy > enforcement and protection of the end node. One way to enforce > deep inspection for all traffic, is to forbid encrypted ESP > completely, in which case ESP-NULL detection is easier, as all > packets must be ESP-NULL based on the policy, and further > restriction can eliminate ambiguities in ICV and IV sizes. ^ s Great! > > - Section 10.2, an informative reference to MOBIKE is needed. What > > about multicast IPsec? > > Added reference to MOBIKE. > > I do not think multicast IPsec requires any special handling as the > level what we need for them is already in the RFC4301/RFC4303. We do > not really care about the keying protocols, we only care about the ESP > packets and we use source address, destination address and SPI to > indicate IPsec flow as specified in the RFC4301 and RFC4303. Thanks. A few more comments: - Should there be an explicit threat model in the document? I think the threat model is this: - End nodes trying to access inappropriate data, end nodes trying sneak confidential data out, but without collusion with other end nodes outside the network. - Malware (since deep inspection could find malware and terminate flows before malware downloads complete). The first one shows how simple it is to defeat deep packet inspection: just find a peer to collude with. - A security considerations note about the security impact of forcing the use of ESP-NULL (and/or WESP) would be nice. Specifically a note about the increased risk of sending confidential information where eavesdroppers can see it. I will review the pseudo-code at some point. I've reviewed the fast path already, and it seemed OK (and it seemed to underscore the point that state is actually needed for reasons other than optimization). The thought occurred that the pseudo-code could be expressed as a BSD Packet Filter program. From what I can tell BPF does not have instructions by which one can implement state caching, but you could still implement, and _test_, large parts of the code in the appendix as BPF programs. I wouldn't demand that -- it's a lot of work for a feature that we all seem to agree is not exactly hot (and it might mean doing implementation work for some vendors for free). Nico -- From Fayyaz_Khan@mentor.com Wed Oct 14 11:09:53 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1FC3A6901 for ; Wed, 14 Oct 2009 11:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 RmbjGn95wLnE for ; Wed, 14 Oct 2009 11:09:52 -0700 (PDT) Received: from relay1.mentorg.com (relay1.mentorg.com [192.94.38.131]) by core3.amsl.com (Postfix) with ESMTP id C584C3A6848 for ; Wed, 14 Oct 2009 11:09:52 -0700 (PDT) Received: from nat-dem.mentorg.com ([139.181.124.2] helo=eu2-mail.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1My8IN-0000Ky-40 from Fayyaz_Khan@mentor.com for ipsec@ietf.org; Wed, 14 Oct 2009 11:09:55 -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: Wed, 14 Oct 2009 20:09:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [IPsec] Difference between IPv4 and IPv6 IPsec Thread-Index: AcpM7jMc8E3C/dYnTuepUqCooQBthAABFoKgAAG34uA= From: "Khan, Fayyaz" To: Subject: Re: [IPsec] Difference between IPv4 and IPv6 IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 18:09:53 -0000 I would also add a few cents. At 11:29 PM +0800 10/14/09, Zhen Cao wrote: >O... > > IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other OS. With > > most of them, the latest versions support IPv6 for IKE and IPsec. > >I guess we do not need tunnel model for IPv6 ipsec? >what makes you say that? unnelT mode is still needed for SG-SG SAs,=20 >or host-SG SAs. Also tunnel mode will still be required for IPv6 to 4 tunnels as long as IPv4 addresses exist and IPv6 nodes need to be interoperable with them. > >> >>> 3) IPv4 IPsec need traversal NAT, but IPv6 don't need it, so it could >>> support more about end to end other than site to site. > > >> That is assuming that IPv6 does not have NAT. I don't think we have enough >> implementation experience to say that for sure. > >Can it be at-least considered one advantage of IPv6 IPSEC? >Not really. Further motivations for NAT in IPv6 includes need for private networks i.e. a company wants to only have one machine to communicate with external world so every computer on that private network goes through that single machine. Also, cost of owning a live ip vs. hosting a private network behind a single live ip would still be attractive, even for security reasons too. >Another point is: "One possible advantage for IPv6 IPsec is that >IPv6's extension header chaining feature, which is not present in >IPv4, could be used to authenticate a secure host-to-host scenario >exchange to a third party gateways which would provide authorized >access into and out of secure enclaves". -quote from >http://www.commandinformation.com/blog/?p=3D98. Is this valid? >I think that is an unlikely scenario, if only due to key management issues. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From wierbows@us.ibm.com Wed Oct 14 13:57:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD943A683E for ; Wed, 14 Oct 2009 13:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 G-J77DO0NbE4 for ; Wed, 14 Oct 2009 13:57:24 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 13DE03A686A for ; Wed, 14 Oct 2009 13:57:23 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9EKnTpB000603 for ; Wed, 14 Oct 2009 16:49:29 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9EKvE4I135532 for ; Wed, 14 Oct 2009 16:57:16 -0400 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9EKv9vC003664 for ; Wed, 14 Oct 2009 14:57:09 -0600 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9EKufRG032540 for ; Wed, 14 Oct 2009 14:56:45 -0600 In-Reply-To: <19151.13444.894473.883558@fireball.kivinen.iki.fi> References: <19127.28334.472030.873072@fireball.kivinen.iki.fi> <19128.47812.239136.479467@fireball.kivinen.iki.fi> <19139.30218.224175.430768@fireball.kivinen.iki.fi> <19151.13444.894473.883558@fireball.kivinen.iki.fi> X-KeepSent: 14973B9B:2C75AAA7-8525764F:0070D3A9; type=4; name=$KeepSent To: IPsecme WG X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Wed, 14 Oct 2009 16:37:07 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 10/14/2009 16:56:45 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCDCDFE355398f9e8a93df938690918c0ABBFCDCDFE35539" Content-Disposition: inline Subject: Re: [IPsec] #22 Simultaneous IKE SA rekey text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 20:57:26 -0000 --0__=0ABBFCDCDFE355398f9e8a93df938690918c0ABBFCDCDFE35539 Content-type: text/plain; charset=US-ASCII Tero Wrote: > RFC4718 is informational and tried to clarify things which are not > clear in RFC4306. Now we are writing standard track document when > revising RFC4306 and in that case we can even change things specified > in RFC4306, if needed. In this case I do not think we need to change > things from RFC4306, but I think the text in RFC4718 is not correct as > it does not consider the case completely. I'm not sure this makes RFC4718 incorrect. It just makes it incomplete. > This solution might cause peers to stay in live lock state, causing > the whole IKE SA to be unusable. I.e. host A starts IKE SA rekey and > host B starts Create Child SA. Host B replies NO_PROPOSAL_CHOSEN to > host A's IKE SA rekey, and Host A replies NO_ADDITIONAL_SAS to Host > B's Create Child SA request. Both ends process replies, and notices > they failed, thus both start again, causing both ends to be trying > these operations as fast as they can. This situation will stay as it > is unless something kicks hosts out of sync. > > Or returning NO_ADDITIONAL_SAS might cause other end to delete the > whole IKE SA and start from scratch. I do not like that RFC 4718 used NO_PROPOSAL_CHOSEN as the indicator that a rekey is being rejected because there are outstanding requests. To me a new notify would have made sense. Given that RFC 4718 did use NO_PROPOSAL_CHOSEN it seems to me that when HOST A is rekeying the IKE_SA it should assume the peer is busy when it receives NO_PROPOSAL_CHOSEN and should continue to attempt to periodically rekey the IKE SA again. I do not agree that when Host B receives NO_ADDITIONAL_SAS that it should retry the operation using the same IKE SA. As such I do not think there is a live lock state. What should be done is up to the implementation. An implementation could assume the other end is in the process of rekeying or deleting the IKE SA and delay taking any action or it could take immendiate action. If it takes immediate action it would need to do so on a new IKE SA. > This is not in RFC4306, this is just one proposal given in RFC4718 > which might be used, but as I noted above, it can cause live lock > loop, thus it is not really acceptable. I think it is appropriate to add this to the new draft. If you are concerned about the lock state then a warning should be added stating that when you receive NO_ADDITIONAL_SAS that you should not attempt to retry that operation on the same IKE SA, although that seems self-evident. > The proposed solution in RFC4718 does not really work, so I do not > think we should include that to RFC4306 (yes, I know I should have > noticed this when RFC4718 was being processed not now, but better now > than never). I'm not convinced it is broken, I'm just convinced that if you attempt to retry an operation on the same IKE SA that you received NO_ADDITIONAL_SAS on that you can get into a lock state. To reduce that concern we can come up with a new REKEYING_IKE_SA notification, but that's likely to cause problems with old implementations, so better to stick with what RFC 4718 proposed. > The text above implies that regardless what you do you should be able > to allow other end to start exchanges and process them. I.e. IKEv2 > protocol tries to be specified in such way that both ends can start > exchanges at any times and expect them to either fail or succeed and > get reply back, but not stay in situation where you do not know, > whether other end processed your request or not. > > If you delete the IKE SA immediately that will happen. You can never guarantee you are going to get a response back to a request. I do not see what makes this situation any different. > As the RFC4718 text can make situatuation much worse by causing live > lock, I think that solution proposed there isn't usable as is. I do not agree. > Informational RFC 4718 proposes much bigger change to the standard > track RFC 4306 than what I want to do and also the solution has > problems which needs to fixed first before it can be taken to > IKEv2bis. I would propose much smaller change to the RFC4306, which > says that wait a while before deleting the IKE SA after successful > rekey so that exchanges from other end has time to finish before > deleting the IKE SA. Those exchanges happening after the IKE SA was > rekeyed should either be failed or if they are processed, they should > be processed in such way that they are done on the Child SAs which are > already moved to new IKE SA (i.e. creating IPsec SAs or rekeying IPsec > SAs should be failed, and deleting IPsec SAs should be processed, so > that IPsec SAs is deleted from the IKE SA where it was moved to). Everything in RFC 4718 is allowable in 4306. Both proposals may require an implementation to change their processing. I do not think these proposals are incompatible. > That is not my reading of the text. But I think it is bit pointless to > argue about this text as I think we can only agree that it is not > clear. Agreed > There is nothing there in RFC4306 to say that you cannot wait after > doing rekey of IKE sa, and as that is only way to properly and cleanly > process other ends exchanges to end before deleting the SA, that is > what implementation should do. I agree that there is nothing that says you cannot wait to delete the IKE SA. I do not agree that it is the only way to handle the situation. I think what is in RFC 4718 can work. > > If that cause redundant SAs to be created then then we do have those > and we need to check nonces to check which of them should be deleted. > > The RFC4718 text is NOT in RFC4306, that is one (broken) proposal to > try to solve this problem. The text in RFC4718 even says "Our poposal > is at follows" which would indicate that it was not really meant to be > final protocol for that case. I understand that RFC 4718 is just one proposal, but it's one that I expect some vendors tried to implement. I doubt there are many that are currently delaying the deletion of the IKE SA. > Mostly that is true, but we should not include broken proposals from > RFC4718 to IKEv2bis, but instead we should try to find solution that > works. I'm not convinced yet that RFC 4718 is broken or at least that it cannot be made to work. > Implementation needs to still have the code that detects the > simultaneous rekey, and other end might still use this delay, thus you > need to be able to cope with the case where this happens. > Implementations need to be able to handle both cases regardless > whether we use SHOULD or MAY, only thing that is different is whether > they allow other end finish exchanges or not. Agreed, but I still think delaying the deletion is at most a MAY. Dave Wierbowski --0__=0ABBFCDCDFE355398f9e8a93df938690918c0ABBFCDCDFE35539 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Tero Wrote:
> RFC4718 is informational and tried to clarify things which are not
> clear in RFC4306. Now we are writing standard track document when
> revising RFC4306 and in that case we can even change things specified
> in RFC4306, if needed. In this case I do not think we need to change
> things from RFC4306, but I think the text in RFC4718 is not correct as
> it does not consider the case completely.

I'm not sure this makes RFC4718 incorrect. It just makes it incomplete.

> This solution might cause peers to stay in live lock state, causing
> the whole IKE SA to be unusable. I.e. host A starts IKE SA rekey and
> host B starts Create Child SA. Host B replies NO_PROPOSAL_CHOSEN to
> host A's IKE SA rekey, and Host A replies NO_ADDITIONAL_SAS to Host
> B's Create Child SA request. Both ends process replies, and notices
> they failed, thus both start again, causing both ends to be trying
> these operations as fast as they can. This situation will stay as it
> is unless something kicks hosts out of sync.
>
> Or returning NO_ADDITIONAL_SAS might cause other end to delete the
> whole IKE SA and start from scratch.

I do not like that RFC 4718 used NO_PROPOSAL_CHOSEN as the indicator that
a rekey is being rejected because there are outstanding requests. To me
a new notify would have made sense. Given that RFC 4718 did use
NO_PROPOSAL_CHOSEN it seems to me that when HOST A is rekeying
the IKE_SA it should assume the peer is busy when it receives
NO_PROPOSAL_CHOSEN and should continue to attempt to periodically rekey
the IKE SA again.

I do not agree that when Host B receives NO_ADDITIONAL_SAS that it
should retry the operation using the same IKE SA. As such I do not think
there is a live lock state. What should be done is up to the
implementation. An implementation could assume the other end is in the
process of rekeying or deleting the IKE SA and delay taking any action
or it could take immendiate action. If it takes immediate action it
would need to do so on a new IKE SA.

> This is not in RFC4306, this is just one proposal given in RFC4718
> which might be used, but as I noted above, it can cause live lock
> loop, thus it is not really acceptable.

I think it is appropriate to add this to the new draft. If you are
concerned about the lock state then a warning should be added stating
that when you receive NO_ADDITIONAL_SAS that you should not attempt to
retry that operation on the same IKE SA, although that seems
self-evident.

> The proposed solution in RFC4718 does not really work, so I do not
> think we should include that to RFC4306 (yes, I know I should have
> noticed this when RFC4718 was being processed not now, but better now
> than never).

I'm not convinced it is broken, I'm just convinced that if you
attempt to retry an operation on the same IKE SA that you received
NO_ADDITIONAL_SAS on that you can get into a lock state. To reduce that
concern we can come up with a new REKEYING_IKE_SA notification, but that's
likely to cause problems with old implementations, so better to stick with
what RFC 4718 proposed.

> The text above implies that regardless what you do you should be able
> to allow other end to start exchanges and process them. I.e. IKEv2
> protocol tries to be specified in such way that both ends can start
> exchanges at any times and expect them to either fail or succeed and
> get reply back, but not stay in situation where you do not know,
> whether other end processed your request or not.
>
> If you delete the IKE SA immediately that will happen.

You can never guarantee you are going to get a response back to a
request. I do not see what makes this situation any different.

> As the RFC4718 text can make situatuation much worse by causing live
> lock, I think that solution proposed there isn't usable as is.

I do not agree.

> Informational RFC 4718 proposes much bigger change to the standard
> track RFC 4306 than what I want to do and also the solution has
> problems which needs to fixed first before it can be taken to
> IKEv2bis. I would propose much smaller change to the RFC4306, which
> says that wait a while before deleting the IKE SA after successful
> rekey so that exchanges from other end has time to finish before
> deleting the IKE SA. Those exchanges happening after the IKE SA was
> rekeyed should either be failed or if they are processed, they should
> be processed in such way that they are done on the Child SAs which are
> already moved to new IKE SA (i.e. creating IPsec SAs or rekeying IPsec
> SAs should be failed, and deleting IPsec SAs should be processed, so
> that IPsec SAs is deleted from the IKE SA where it was moved to).

Everything in RFC 4718 is allowable in 4306. Both proposals may require
an implementation to change their processing. I do not think these
proposals are incompatible.

> That is not my reading of the text. But I think it is bit pointless to
> argue about this text as I think we can only agree that it is not
> clear.

Agreed

> There is nothing there in RFC4306 to say that you cannot wait after
> doing rekey of IKE sa, and as that is only way to properly and cleanly
> process other ends exchanges to end before deleting the SA, that is
> what implementation should do.

I agree that there is nothing that says you cannot wait to delete the
IKE SA. I do not agree that it is the only way to handle the situation.
I think what is in RFC 4718 can work.

>
> If that cause redundant SAs to be created then then we do have those
> and we need to check nonces to check which of them should be deleted.
>
> The RFC4718 text is NOT in RFC4306, that is one (broken) proposal to
> try to solve this problem. The text in RFC4718 even says "Our poposal
> is at follows" which would indicate that it was not really meant to be
> final protocol for that case.

I understand that RFC 4718 is just one proposal, but it's one that I
expect some vendors tried to implement. I doubt there are many that are
currently delaying the deletion of the IKE SA.

> Mostly that is true, but we should not include broken proposals from
> RFC4718 to IKEv2bis, but instead we should try to find solution that
> works.

I'm not convinced yet that RFC 4718 is broken or at least that it cannot
be made to work.


> Implementation needs to still have the code that detects the
> simultaneous rekey, and other end might still use this delay, thus you
> need to be able to cope with the case where this happens.
> Implementations need to be able to handle both cases regardless
> whether we use SHOULD or MAY, only thing that is different is whether
> they allow other end finish exchanges or not.

Agreed, but I still think delaying the deletion is at most a MAY.

Dave Wierbowski
--0__=0ABBFCDCDFE355398f9e8a93df938690918c0ABBFCDCDFE35539-- From caozhenpku@gmail.com Wed Oct 14 19:27:21 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676133A696D for ; Wed, 14 Oct 2009 19:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] 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 XRtYOaBnfWPR for ; Wed, 14 Oct 2009 19:27:20 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id C18E93A696A for ; Wed, 14 Oct 2009 19:27:20 -0700 (PDT) Received: by pzk42 with SMTP id 42so396763pzk.31 for ; Wed, 14 Oct 2009 19:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/0Rm8DiYGjW4fPePChF406G3YQ0IavWa7ejTLzp/eks=; b=q3McPjkqk5wNzoQnL6y8QStWf35mo8xzIn38IQo8y5EoUiduH1/MNC2KKtwB1ZO4Km ltpXkiU2GGqKkACooQtI7tAzbfb7arrZCzH6Y/GAZdywyvKOZVKoMv5WEGM5aEWgEe16 GgoQnPmteLsKzwVGy5utZJ6bITPhaPXiymolQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=k54axzdIZ8C/khfTF5vG4zB5p03I7sty4hGGGjvAdvn1m+TilXOOpHjZ0HNnNRcZVA NkvydCQBQLI28r7N4fHZK9deHCf4KqzRgl3a8xSEVu1GUL5uM0VpQ4swhg8YcyeHt6mQ IHZtBwdehE6OJ5LyQIK2SSkVqM378hZbxdvZ4= MIME-Version: 1.0 Received: by 10.142.248.41 with SMTP id v41mr744578wfh.284.1255573638660; Wed, 14 Oct 2009 19:27:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Oct 2009 10:27:18 +0800 Message-ID: From: Zhen Cao To: "Khan, Fayyaz" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hui Deng , IPsecme WG , Yoav Nir , Stephen Kent Subject: Re: [IPsec] Difference between IPv4 and IPv6 IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 02:27:21 -0000 On Thu, Oct 15, 2009 at 1:50 AM, Khan, Fayyaz wrot= e: > > > > > I would also add a few cents. > > At 11:29 PM +0800 10/14/09, Zhen Cao wrote: >>O... >> =A0> IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other > OS. With >> =A0> most of them, the latest versions support IPv6 for IKE and IPsec. >> >>I guess we do not need tunnel model for IPv6 ipsec? > >>what makes you say that? unnelT mode is still needed for SG-SG SAs, >>or host-SG SAs. > > Also tunnel mode will still be required for IPv6 to 4 tunnels as long as > IPv4 addresses exist and IPv6 nodes need to be interoperable with them. > I thought transport mode is enough for all requirements...I must be wrong. Thanks. From yaronf@checkpoint.com Thu Oct 15 08:30:40 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9039028C103 for ; Thu, 15 Oct 2009 08:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 n-BhtT1gyqBT for ; Thu, 15 Oct 2009 08:30:39 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 01D7228C0FF for ; Thu, 15 Oct 2009 08:30:38 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9FFUehu007840 for ; Thu, 15 Oct 2009 17:30:40 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 15 Oct 2009 17:30:42 +0200 From: Yaron Sheffer To: IPsecme WG Date: Thu, 15 Oct 2009 17:30:40 +0200 Thread-Topic: [IPsec] Seeking interest in new charter items for the IPsecME WG Thread-Index: AcpMSPRdE1dDIYR8QzSHls7oFuL5aABYynTQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BD9338EA13@il-ex01.ad.checkpoint.com> References: In-Reply-To: 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 Subject: Re: [IPsec] Seeking interest in new charter items for the IPsecME WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 15:30:40 -0000 To clarify: even if you presented a draft in Stockholm or at the following = interim meeting, make sure to drop us a note to ensure that we consider you= r work during the rechartering process. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Tuesday, October 13, 2009 23:06 > To: IPsecme WG > Subject: [IPsec] Seeking interest in new charter items for the IPsecME WG >=20 > Greetings again. As Yaron and I have said many times in the past, when a > few of our WG documents have been completed, we can think about adding > additional items to our charter. We think that we will soon be at that > point. >=20 > For new items to be considered in the WG, we need to have an existing, > personally-submitted Internet Draft, and four people (other than the > authors) who are committed to reviewing the draft as it moves through the > WG process. >=20 > If you have an Internet Draft (or will have one very soon) that you think > should be a WG item, please send Yaron and I a message off-list. Note tha= t > the cut-off for submitting new -00 drafts is this coming Monday; however, > we will accept proposals without an Internet Draft if the author promises > to have the draft submitted on Monday, November 9 when they are allowed t= o > turn them in again. >=20 > We will review the submissions, talk with the proposers a bit, and then > have an discussion of the proposals at the Hiroshima face-to-face meeting= , > followed by more discussion on the mailing list post-Hiroshima. >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From A.Hoenes@TR-Sys.de Mon Oct 19 03:40:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5BE828C144 for ; Mon, 19 Oct 2009 03:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.425 X-Spam-Level: *** X-Spam-Status: No, score=3.425 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 Q5M8G4FirvLN for ; Mon, 19 Oct 2009 03:40:34 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 157D03A67A3 for ; Mon, 19 Oct 2009 03:40:32 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA259018780; Mon, 19 Oct 2009 12:39:40 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA07023; Mon, 19 Oct 2009 12:39:39 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910191039.MAA07023@TR-Sys.de> To: ipsec@ietf.org Date: Mon, 19 Oct 2009 12:39:39 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable Cc: draft-kanno-ipsecme-camellia-xcbc@cabernet.tools.IETF.ORG Subject: [IPsec] XCBC MAC / PRF with Camellia proposal necessary? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 10:40:34 -0000 I have performed a detailed editorial review of draft-kanno-ipsecme-camellia-xcbc-01 and sent it off-list to the authors. However, there seems to be a more fundamental strategic question: Per the standardization of CMAC in NIST SP 800-38B, the original XCBC enhancement to CBC-MAC seems to be less interesting from a standardization point of view. (CMAC is a improved refinement of XCBC-MAC, originally published as OMAC / OMAC1 -- see the explanation in the Introduction of NIST SP 800-38B.) For AES as the underlying block cipher, use of CMAC with IPsec and IKE already has been specified (in RFCs 4494 and 4615, respectively), and the promoters of Camellia have a similar draft as well (draft-kato-ipsec-camellia-cmac96and128). For interoperability purposes, it is important to not let the IPsec/IKE algorithm portfolio grow unnecessarily. So I suggest to consider in general whether: a) XCBC should be used in new specifications, and/or b) the existing XCBC specifications for IPsec might be demoted or even deprecated, and/or c) CMAC use should be promoted in its support requirement level. All related RFCs appear in draft-ietf-ipsecme-roadmap, which thus might be affected by the outcome of any new recommendations. Kind regards, Alfred H=CEnes. -- = +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From sean.s.shen@gmail.com Mon Oct 19 01:08:37 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1483A6877 for ; Mon, 19 Oct 2009 01:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 ymZDFZ8j6leJ for ; Mon, 19 Oct 2009 01:08:34 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 604F83A63EB for ; Mon, 19 Oct 2009 01:08:34 -0700 (PDT) Received: by pwi4 with SMTP id 4so532972pwi.29 for ; Mon, 19 Oct 2009 01:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=HF6S1imZeCTLMkbfaMRAHp3d/tP2VFCWALuXXgnvt58=; b=Dqz/SEZ43IYjHDHGoGrcsMhP0MgXG9mXHiB5dl75tlePk0w0+iTlts/e6CjQffsIG/ XeXGxLQDGItB6dhrQYZjeCirahWH16/YMGt/eyAqNbx9iu2ILFl4IcmYEQE/pBfHGage I1yjDuLzMFcw29lZfL5MPu1Yk1KRRLmLF9siA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=leUjw2eI0ODlczqDqOLL7GkeZnu1hlhxqoLL8mPrt8TGpa3B65ljmjs0AC12MItbD0 sWbuTz6a2cRGXTdSNkMl5aUHm1976E7uC1+f0qbMDjnIRqpjK91gDZQhvPCuhy6b0JDp 71EB4smQ8ksmqcodPfahGkNOalD9R+v5kcKaY= MIME-Version: 1.0 Received: by 10.114.250.4 with SMTP id x4mr5619273wah.113.1255939718066; Mon, 19 Oct 2009 01:08:38 -0700 (PDT) In-Reply-To: <200910131509.RAA22549@TR-Sys.de> References: <200910131509.RAA22549@TR-Sys.de> Date: Mon, 19 Oct 2009 16:08:38 +0800 Message-ID: <80b5a9190910190108t46e6c862s9f8c48895e5b3851@mail.gmail.com> From: Shen Sean To: =?ISO-8859-1?Q?Alfred_H=CEnes?= Content-Type: multipart/alternative; boundary=001636d34a3ec1312e0476454064 X-Mailman-Approved-At: Mon, 19 Oct 2009 08:35:39 -0700 Cc: ipsec@ietf.org, draft-ietf-ipsecme-aes-ctr-ikev2@tools.ietf.org Subject: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 08:24:52 -0000 --001636d34a3ec1312e0476454064 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Alfred, Thanks for your detailed review, please see in lines: 2009/10/13 Alfred H=CEnes Hello, I've arrived at completing a review of your I-D, draft-ietf-ipsecme-aes-ctr-ikev2-02, and have a couple of comments. First of all, this draft closes a gap that in the past could only be bridged by extrapolation, incurring a high risk of interoperability problems. As such, this draft is very useful. Yet, I'm not convinced that it is necessary to re-state so much plain knowledge about AES and CTR mode in this memo, and not rarely doing that even up to three times. Therefore, I generally would appreciate an attempt to 'boil down' the volume of this draft, reducing redundancies in the text (that, as experience has shown, generally always also run the risk of inconsistencies as well), and making more use of normative text from existing specifications that can be referenced. [Sean] We did have a concise version ealier, eventually we decided to include the necessary AES and CTR mode description, so that the draft is more complete without dirrecting readers to many other document. We were carefully to only include wide accepted and standard discriptions, therefore, unless there are changes to AES or CTR mode themselfies (in that case, maybe AES/CTR themselves are bigger problems we should worry about , :) ), there won't be a risk of inconsistency. However, I could live with the current structure of the draft if in certain places the focus were be changed from general to the specifics of the application of AES-CTR in IKEv2. [Sean] There are no special specifications when AES-CTR is used in IKEv2, instead, IKEv2 just provide what AES-CTR need, that's what the draft gives in section 3,4,5. Based on this general assumption, a linear walk-through of the draft follows with detailed change recommendations. Short substitutions are shown in POSIX edit style: s/old/new/ . To give more context, sometimes I quote larger blocks of text literally and show the replacement proposed using the shorthand notation: --- I use change bars ('|' in column 1) and occasionally insert up/down pointing marker lines ('^^^'/'vvv') to emphasize the location of textual issues and/or proposed corrections. Modified text has been re-adjusted to match RFC formatting rules, where appropriate. I also try to accomodate published RFC-Ed policy on style and punctuation etc. in my proposals. (1) Section 1, and General -- editorials (1a) In a few instances, text is inadvertantly immediately joined with adjacent parenthetical parts. Please ensure the presence of white space in these places. For instance, in the 3rd para of Section 1, please s/initial exchange(IKE_SA_INIT)/initial exchange (IKE_SA_INIT)/ [Sean] Right, I will check all the parenthesis. ^ (1b) In many places, articles are missing and singular/plural mismatches occur. I've tried to catch these all and address them in the items below. [Sean] Thanks, I will correct them. (1c) The draft inconsistently switches between "AES_CTR" and "AES-CTR". Please use a unique spelling -- preferably with the hypen. This issue is not prosecuted in all details below and left as an exercise. :-) [Sean] I will unify them as AES-CTR. (2) Section 2, last para According to the rationale above, I suggest to apply the following 'facelifting' for the 4th (last) paragraph of Section 1: This document explains how IKEv2 makes use of AES_CTR algorithm for encrypting IKE messages that follow initial exchange: The second pair of messages (IKE_AUTH) in initial exchange, messages in CREATE_CHILD_SA exchange, messages in INFORMATIONAL exchange. --- | This document explains how IKEv2 makes use of the AES-CTR algorithm ^^^^^ ^ | for encrypting IKE messages that follow the initial exchange: The ^^^^^ | second pair of messages (IKE_AUTH) in the initial exchange, messages ^^^^^ | in CREATE_CHILD_SA exchanges, and messages in INFORMATIONAL ^ | exchanges. ^ [Sean] Done. (3) Section 2 (and ff.) It is confusing for protocol designers and implementers to refer to "parameters" of a cryptographic algorithm or building block that in fact have been internal design decisions not exposed to the external interface of the algorithm / building block. Therefore, for the purpose of the application of AES and AES-CTR, neither the number of rounds nor the block size of the AES cipher are subject to higher level parametrization that, for instance, would need to be carried in algorithm negotiation exchanges. It is particularly confusing that the draft pretends Rounds and Block Size were "choices" needing specification in this context. The number of (internal) rounds is totally irrelevant for the application of the AES. Any attempt to mangle with this 'parameter' would raise significant security concerns and conformance issues. I strongly request to elide all mention of "rounds" from the draft. The block size (128 bits) is an invariant of AES and should only be mentioned in contexts where it really matters. [Sean] The intention of such a document is to give what a IKEv2 product MUST/SHOULD/MAY provide. A user may not have "choices" of rounds or size, but a vendor need to know what to provide. The consequences of these recommendations are included in the change recommendations below. The first paragraph of Section 2 essentially says all that's needed to be said, but it might be gradually better to replace "can process" by "processes" -- due to the lack of an alternative: | AES [AES] is a symmetric block cipher that can process data blocks of 128 bits, using cipher keys with lengths of 128, 192, and 256 bits. --- vvvvvvvvv | AES [AES] is a symmetric block cipher that processes data blocks of 128 bits, using cipher keys with lengths of 128, 192, and 256 bits. [Sean] Done. The second paragraph sketches the embedding of the building blocks, and it should refrain from further discussing "choices". Instead, I suggest to outline the role of the following section, as a guide to the reader, and try to better delineate it from the subsequent sections that specify the details for AES-CTR with IKEv2: The use of AES algorithm operations in IKEv2 is the same as what defined in [AES]. The use of Counter Mode is defined the same as how | AES_CTR is used to encrypt ESP payload [RFC3686]. The choices of Key | Size, Rounds and Block Size are defined as following which are | compatible with [RFC3686]. --- The use of AES algorithm operations in IKEv2 is the same as what defined in [AES]. The use of Counter Mode is defined the same as how | AES-CTR is used to encrypt ESP payload [RFC3686]. | | Section 2.1 sketches the operation and properties of counter mode | at a high level and indicates how it is to be used inside IKEv2; | Sections 3 through 6 will give the normative descriptions for the | details of this use case of AES-CTR. (4) Section 2.1 (4a) 1st para -- editorial fixes Please adjust: This section gives description for AES Counter Mode algorithm and cites algorithm description part in section 2.1 of [RFC3686] --- vvv vvvvv | This section gives a description for the AES Counter Mode algorithm | and cites the algorithm description part in Section 2.1 of [RFC3686]. ^^^^^ ^ ^ (4b) 3rd para Please delete te comma in the first sentence; two-handed enumerations with "and"/"or" do not need that: Only AES Counter mode (AES-CTR) is discussed in this specification. | AES-CTR requires the encryptor to generate a unique per-packet value, and communicate this value to the decryptor. [...] --- Only AES Counter mode (AES-CTR) is discussed in this specification. | AES-CTR requires the encryptor to generate a unique per-packet value and communicate this value to the decryptor. [...] [Sean] Done. (4c) 4th para I fear the text copying from RFC 3686 went too far here, without the necessary adoption. This draft addresses IEKv2-inernal use of AES-CTR, and that happens within the *IKE* SA, not in the *IPsec* SAs. So please correct, for the purpose of this memo: This specification calls for the use of a nonce for additional protection against precomputation attacks. The nonce value need not be secret. However, the nonce MUST be unpredictable prior to the | establishment of the IPsec security association that is making use of AES-CTR. --- ^^^^^ This specification calls for the use of a nonce for additional protection against precomputation attacks. The nonce value need not be secret. However, the nonce MUST be unpredictable prior to the | establishment of the IKE security association that is making use of ^^^ AES-CTR. [Sean] Done. (4d) 5th para -- clarifications / textual enhancements I suggest to change: AES-CTR has many properties that make it an attractive encryption | algorithm for in high-speed networking. AES-CTR uses the AES block cipher to create a stream cipher. Data is encrypted and decrypted by XORing with the key stream produced by AES encrypting sequential counter block values. AES-CTR is easy to implement, and AES-CTR can be pipelined and parallelized. AES-CTR also supports key stream precomputation. --- AES-CTR has many properties that make it an attractive encryption | algorithm for use in high-speed networking. AES-CTR uses the AES ^^^^^ block cipher to create a stream cipher. Data is encrypted and | decrypted by XORing with the key stream produced by encrypting ^ | sequential counter block values with AES in ECB mode. AES-CTR is ^^^^^^^^^^^^^^^^^^^^^ easy to implement, and AES-CTR can be pipelined and parallelized. AES-CTR also supports key stream precomputation. [Sean] Modified the "... for use in ...". Wrote the second one as "... values with AES." (4e) 6th para -- typo Please correct: s/AES- CTR/AES-CTR/ . [Sean] Done ^^ ^ (4f) 7th para -- punctuation There should not be a comma in "... one could use ..., to process ..." ^ [Sean] Done. (4g) 9th para -- language improvement Please swap words in the first line to restore correct semantics: vvvvvvvv | AES-CTR uses the only AES encrypt operation (for both encryption and decryption), making AES-CTR implementations smaller than implementations of many other AES modes. --- vvvvvvvv | AES-CTR uses only the AES encrypt operation (for both encryption and decryption), making AES-CTR implementations smaller than implementations of many other AES modes. [Sean] Done (4h) 10th para As in item (4c) above, two last sentences in this paragraph have not been properly transformed into the intended context, inside IKEv2. Please change: [...]. Extraordinary measures would be needed to prevent reuse of an IV value with the static key across power cycles. To be | safe, implementations MUST use fresh keys with AES-CTR. The Internet | Key Exchange [RFC4306] protocol can be used to establish fresh keys. IKE can also provide the nonce value. --- [...]. Extraordinary measures would be needed to prevent reuse of an IV value with the static key across power cycles. To be | safe, implementations MUST use fresh keys with AES-CTR. The initial ^^^^^^^^ | exchange of the IKEv2 protocol [RFC4306] can be used to establish ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | fresh keys for an IKEv2 SA, and it also provides the nonce value. [Sean] Done ^^^^^^^^^^^^^^^^^^^^^^^ ^ (5) Section 2.2 I recommend to drop the entire section. Detailed reasoning: |2.2. Key Sizes and Rounds See the rationale in item (3) above. | AES supports three key sizes: 128 bits, 192 bits, and 256 bits. [...] That already has been stated earlier in the draft and hence is redundant. | [...]. All | IKEv2 implementations that implement AES-CTR MUST support the 128 key | size. An IKEv2 implementation MAY support key sizes of 192 and 256 | bits. That belongs into the normative part of the draft. I suggest putting these two sentences as a new (2nd) paragraph into Section 5. | AES MUST use different rounds for each of the key sizes: | | When a 128-bit key is used, implementations MUST use 10 rounds. | | When a 192-bit key is used, implementations MUST use 12 rounds. | | When a 256-bit key is used, implementations MUST use 14 rounds. As pointed out in item (3) above, that is an internal detail of the AES design and not subject to importance or change by the user of AES. This part definitely does not belong into this document. [Sean] As answered in item (3). (6) Section 2.3 I recommend to drop the entire section. Detailed reasoning: |2.3. Block Size | | The AES algorithm has a block size of 128 bits (16 octets), i.e., AES | generate 128 bits of key stream. [...] This statement is misleading; the correct description can be found earlier, in Section 2.1. | [...]. For encryption or decryption, a | user XOR the key stream with 128 bits of plaintext or ciphertext | blocks. If the generated key stream is longer than the plaintext or | ciphertext, the extra key stream bits are simply discarded. For this | reason, AES-CTR does not require the plaintext to be padded to a | multiple of the block size. This all has been explained at length and in detail in Section 2.1. Why would we want to repeat it again here? [Sean] The point here is plaintext padding. (7) Section 3.1 In the first part of the text here, an article is missing. The second part again rephrases parts of Section 2.1, and it does so in a confusingly general way that does not help the implementor of AES-CTR for use within IKEv2. I request to drop that text. Instead, I suggest to add a pointer to where the IV is used. In total, please change: v | The IV field MUST be eight octets when AES_CTR algorithm is used for encryption. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is NOT used more than once with a given encryption key. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs). --- vvvvv v The IV field MUST be eight octets when the AES-CTR algorithm is used for encryption. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is NOT used more than once with a | given encryption key. See Section 4 for how the IV is used to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | construct counter blocks for AES-CTR use within IKEv2. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [Sean] Done. (8) Section 3.2 Again, a definite article is missing here. Please adjust: s/for Encrypted Payload/for the Encrypted Payload/ ^ ^^^^^ [Sean] Done (9) Section 3.3, 2nd para In two more instances, the definitie article is missing. Please adjust: | It should be noticed that ESP [RFC4303] Encrypted Payload requires | alignment on a 4-byte boundary while IKEv2 [RFC4306] Encrypted Payload does not have such a requirement. --- vvvvv | It should be noticed that the ESP [RFC4303] Encrypted Payload | requires alignment on a 4-byte boundary while the IKEv2 [RFC4306] ^^^^^ Encrypted Payload does not have such a requirement. [Sean] Done. (10) Section 4 Again, please adjust ... (10a) 2nd para The Encrypted Payload is the XOR of the plaintext and key stream. | The key stream is generated by inputing Counter Blocks into AES algorithm. [...] --- The Encrypted Payload is the XOR of the plaintext and key stream. | The key stream is generated by inputing Counter Blocks into the AES algorithm. [...] ^^^^^ [Sean] Done. (10b) last para Section 2 provides references to other documents for implementing | AES_CTR encryption/decryption process. --- Section 2 provides references to other documents for implementing | the AES-CTR encryption/decryption process. ^^^^ ^ (11) Section 5 | This section describes the conventions used by IKEv2 protocol to | generate encryption keys and nonces for use with AES-CTR algorithm in | IKE-SA negotiation. The identifiers and attributes related to AES- | CTR required during IKE-SA and Child-SA negotiation are also defined. Please fix missing articles and a singular/plural issue. [Sean] Done. I'm not sure whether the mention of Child-SA is appropriate here. IMHO, that is covere in RFC 3686, and should not be re-stated here. I propose changed wording below. Please check! [Sean] The words here are not giving description for AES-CTR usage as in RFC3686, it mentions Child-SA because IKEv2 negotiates transformes used for Child-SA. Further, as mentioned in item (5) above, I suggest to move text from the obsolescent Section 2.2 into this section. This results in the following revised text: vvvvv | This section describes the conventions used by the IKEv2 protocol to | generate encryption keys and nonces for use with the AES-CTR v ^^^^^ | algorithm in IKE-SA negotiations. The identifiers and attributes | related to AES-CTR as defined in [RFC3686] are used in the same | manner during IKE-SA negotiation. | | All IKEv2 implementations that implement AES-CTR MUST support the 128 | key size. An IKEv2 implementation MAY support key sizes of 192 and | 256 bits. (12) Section 5.1 (12a) 2nd para Again, an article is missing, and item (1a) applies. After an abbreviation has been introduced, it may be used to streamline the text; therefore I suggest to delete the repeated expansion of "PRF". Hence, please change: IKEv2 negotiates four cryptographic algorithms with its peer using | IKE_SA_INIT exchange. They include an encryption algorithm and a | pseudo-random function(PRF). All the payloads of IKEv2 messages that follow the IKE_SA_INIT exchange are encrypted using the negotiated | encryption algorithm. The pseudo-random function(PRF)is used to generate the keying material required for the encryption algorithm. --- IKEv2 negotiates four cryptographic algorithms with its peer using | the IKE_SA_INIT exchange. They include an encryption algorithm and a ^^^^ v | pseudo-random function (PRF). All the payloads of IKEv2 messages that follow the IKE_SA_INIT exchange are encrypted using the | negotiated encryption algorithm. The PRF is used to generate the ^ ^ keying material required for the encryption algorithm. [Sean] Done. (12b) 3rd para Item (1b) again: | AES_CTR encryption algorithm needs an encryption key and a nonce. [...] ---vvvv | The AES_CTR encryption algorithm needs an encryption key and a nonce. [...] [Sean] Done. (13) Section 5.2 I suggest to insert the word "value" before "of 13", and to avoid the unnecessary repetition of the code point. The above concerns w.r.t. "Child-SA" apply. So please change: | IKEv2 uses the IANA allocated encryption identifier of 13 for | ENCR_AES_CTR with an explicit IV (ENCR_AES_CTR 13) as the transform | ID during IKE-SA and Child-SA negotiation. --- | IKEv2 uses the IANA allocated encryption identifier value of 13 for v ^^^^^^^ vvv | ENCR_AES_CTR with an explicit IV as the transform ID during IKE-SA negotiation. [Sean] Added the "value". (14) Section 6 (14a) 2nd para -- language improvement Please adjust: AES_CTR provides high confidentiality when used properly. However, | as a stream mode cipher, the security of will lose when AES-CTR is misused. --- ^^^^^^^^^^^^ AES_CTR provides high confidentiality when used properly. However, | as a stream mode cipher, the security will be lost when AES-CTR is misused. ^^^^^^^^^^^^ [Sean] Done (14b) 3rd para Following (1b), please correct: Generally, a stream cipher should not use static keys. This is because key streams will be easily canceled when two ciphertext use | the same key stream (check detailed description of this attack in [RFC3686]). Therefore, IKEv2 should avoid an identical key being | used for different IKE SA or a same key stream being used on different blocks of plaintext. [...] --- Generally, a stream cipher should not use static keys. This is because key streams will be easily canceled when two ciphertext use | the same key stream (check the detailed description of this attack in ^^^^^ [RFC3686]). Therefore, IKEv2 should avoid an identical key being | used for different IKE SAs or a same key stream being used on ^ different blocks of plaintext. [...] [Sean] Done. (14c) 4th para -- language improvements v vvvvv | A stream cipher like AES_CTR is also vulnerable under data forgery | attack (check [RFC3686] for a demonstration of this attack). [...] --- v vvvvvvv | A stream cipher like AES-CTR is also vulnerable against data forgery | attacks (check [RFC3686] for a demonstration of this attack). [...] ^ [Sean] Corrected the singular/plural. (14d) 5th para Again, according to (1b) please correct: v | [...]. Since IKEv2 are not likely to carry traffics in such a high quantity, this won't be a big concern here. However, when large amount of traffic appear in the future or under abnormal circumstances, implementations SHOULD generate a fresh key before 2^64 blocks are encrypted with the same key. --- [...]. Since IKEv2 are not likely to carry traffic in such a high quantity, this won't be a big concern here. However, | when a large amount of traffic appears in the future or under ^^^ ^ abnormal circumstances, implementations SHOULD generate a fresh key before 2^64 blocks are encrypted with the same key. [Sean] Done. (15) Section 7 I suggest to more clearly indicate what this draft is expecting IANA to do: adding a reference to this memo for an existing registration. | IANA has assigned 13 as the transform ID for ENCR_AES_CTR encryption | with an explicit IV. This ID is to be used during IKE_SA | negotiation. --- | Per [RFC3686], IANA has assigned 13 as the "IKEv2 Encryption | Transform ID" to the name "ENCR_AES_CTR" for AES-CTR encryption with | an explicit IV, in the IANA "Internet Key Exchange Version 2 (IKEv2) | Parameters" registry. This document specifies how to use this | transform during IKE_SA negotiations. Hence IANA should add to that | entry a reference to this RFC. [Sean] It's a good point, but for IANA's reference to this document, I assume iana will updated their reference (following some rocedure?) when this document is processed. Let me know if we have to request it in the draft. I added the a reference of IANA-Para to the IANA-IKEv2-parameters link. Best, Sean --001636d34a3ec1312e0476454064 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi, Alfred,
Thanks for your detailed review, please see in lines:

2009/10/13 Alfred H=CEnes <ah@tr-sys.= de>


Hello,
I've arrived at completing a review of your I-D,
= =A0draft-ietf-ipsecme-aes-ctr-ikev2-02,
and have a couple of comments.

First of all, this draft closes a gap that in the past could
only be = bridged by extrapolation, incurring a high risk of
interoperability prob= lems.=A0 As such, this draft is very useful.

Yet, I'm not convinced that it is necessary to re-state so much
p= lain knowledge about AES and CTR mode in this memo, and not rarely
doing= that even up to three times.

Therefore, I generally would appreciate an attempt to 'boil down'= ;
the volume of this draft, reducing redundancies in the text (that,
= as experience has shown, generally always also run the risk of
inconsist= encies as well), and making more use of normative text
from existing specifications that can be referenced.

[Sean] We did have a concise version ealier, eventually we decided to in= clude the necessary AES and CTR mode description, so that the draft is more= complete without dirrecting readers to many other document. We were carefu= lly to only include wide accepted and standard discriptions, therefore, unl= ess there are changes to AES or CTR mode themselfies (in that case, maybe A= ES/CTR themselves are bigger problems we should worry about , :) ), there w= on't be a risk of inconsistency.
=A0
=A0
However, I could live with the current structure of the draft=
if in certain places the focus were be changed from general
to the s= pecifics of the application of AES-CTR in IKEv2.

[Sean] There are no special specifications when AES-CTR is used in IKEv2= , instead, IKEv2 just provide what AES-CTR need, that's what the draft = gives in section 3,4,5.
=A0

Based on this general assumption, a linear walk-through of the
draft = follows with detailed change recommendations.


Short substitutions are shown in POSIX edit style:=A0 s/old/new/ .To give more context, sometimes I quote larger blocks of text
literall= y and show the replacement proposed using the shorthand
notation:

=A0 <original draft text>
---
=A0 <modified text>

I use change bars ('|' in column 1) and occasionally insert
u= p/down pointing marker lines ('^^^'/'vvv') to emphasize
= the location of textual issues and/or proposed corrections.
Modified tex= t has been re-adjusted to match RFC formatting
rules, where appropriate.=A0 I also try to accomodate published
RFC-Ed p= olicy on style and punctuation etc. in my proposals.


(1)=A0 Section 1, and General -- editorials

(1a)
In a few instances, text is inadvertantly immediately joined
= with adjacent parenthetical parts.=A0 Please ensure the presence
of whit= e space in these places.
For instance, in the 3rd para of Section 1, ple= ase
=A0=A0 s/initial exchange(IKE_SA_INIT)/initial exchange (IKE_SA_INIT)/
= =A0
[Sean] Right, I will check all the parenthesis.
=A0
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^
(1b)In many places, articles are missing and singular/plural mismatches
occur.=A0 I've tried to catch these all and address them in the itemsbelow.

[Sean] Thanks, I will correct them.
=A0

(1c)
The draft inconsistently switches between "AES_CTR" an= d "AES-CTR".
Please use a unique spelling -- preferably with t= he hypen.
This issue is not prosecuted in all details below and left as = an
exercise. :-)

[Sean] I will unify them as AES-CTR.
=A0


(2)=A0 Section 2, last para

According to the rationale above, I suggest to apply the following
&#= 39;facelifting' for the 4th (last) paragraph of Section 1:

=A0 This document explains how IKEv2 makes use of AES_CTR algorithm for<= br>=A0 encrypting IKE messages that follow initial exchange: The second pai= r
=A0 of messages (IKE_AUTH) in initial exchange, messages in
=A0 CRE= ATE_CHILD_SA exchange, messages in INFORMATIONAL exchange.
---
|=A0 This document explains how IKEv2 makes use of the AES-CTR algor= ithm
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^= ^^^=A0=A0 ^
|=A0 for encrypting IKE messages that follow the initial exc= hange: The
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^
|=A0 second pair of messages (IKE_AUTH) in the initial exchange, messages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^
|=A0 in CREATE_CHILD_SA= exchanges, and messages in INFORMATIONAL
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^
|=A0 exchanges.
=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^
[Sean] Done.

(3)=A0 Section 2 (and ff.)

It is confusing for protocol designers and implementers to refer
to &= quot;parameters" of a cryptographic algorithm or building block
tha= t in fact have been internal design decisions not exposed to
the externa= l interface of the algorithm / building block.

Therefore, for the purpose of the application of AES and AES-CTR,
nei= ther the number of rounds nor the block size of the AES cipher
are subje= ct to higher level parametrization that, for instance,
would need to be = carried in algorithm negotiation exchanges.

It is particularly confusing that the draft pretends Rounds and
Block= Size were "choices" needing specification in this context.

The number of (internal) rounds is totally irrelevant for the
applica= tion of the AES.=A0 Any attempt to mangle with this 'parameter'
= would raise significant security concerns and conformance issues.
I stro= ngly request to elide all mention of "rounds" from the draft.

The block size (128 bits) is an invariant of AES and should only
be m= entioned in contexts where it really matters.

[Sean] The intention of such a document is to give what a IKEv2 product = MUST/SHOULD/MAY provide. A user may not have "choices" of rounds = or size, but a vendor need to know what to provide.

The consequences of these recommendations are included in the change
= recommendations below.

The first paragraph of Section 2 essentially says all that's needed<= br>to be said, but it might be gradually better to replace "can proces= s"
by "processes" -- due to the lack of an alternative:

|=A0 AES [AES] is a symmetric block cipher that can process data blocks = of
=A0 128 bits, using cipher keys with lengths of 128, 192, and 256 bit= s.
---=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vvvvvvvvv
|= =A0 AES [AES] is a symmetric block cipher that processes data blocks of
=A0 128 bits, using cipher keys with lengths of 128, 192, and 256 bits.
= [Sean] Done.

The second paragraph sketches the embedding of the building blocks,
a= nd it should refrain from further discussing "choices".
Instea= d, I suggest to outline the role of the following section,
as a guide to= the reader, and try to better delineate it from the
subsequent sections that specify the details for AES-CTR with IKEv2:

=A0 The use of AES algorithm operations in IKEv2 is the same as what
= =A0 defined in [AES].=A0 The use of Counter Mode is defined the same as how=
|=A0 AES_CTR is used to encrypt ESP payload [RFC3686].=A0 The choices o= f Key
|=A0 Size, Rounds and Block Size are defined as following which are
|=A0= compatible with [RFC3686].
---
=A0 The use of AES algorithm operatio= ns in IKEv2 is the same as what
=A0 defined in [AES].=A0 The use of Coun= ter Mode is defined the same as how
|=A0 AES-CTR is used to encrypt ESP payload [RFC3686].
|
|=A0 Section= 2.1 sketches the operation and properties of counter mode
|=A0 at a hig= h level and indicates how it is to be used inside IKEv2;
|=A0 Sections 3= through 6 will give the normative descriptions for the
|=A0 details of this use case of AES-CTR.


(4)=A0 Section 2.1

(4a)=A0 1st para -- editorial fixes

Please adjust:

=A0 This section gives description for AES Counter Mode algorithm and=A0 cites algorithm description part in section 2.1 of [RFC3686]
---=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vvv=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 vvvvv
|=A0 This section gives a description for th= e AES Counter Mode algorithm
|=A0 and cites the algorithm description part in Section 2.1 of [RFC3686].<= br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^

(4b)=A0 3rd para

Please delete te comma in the first sentence; two-handed enumerationswith "and"/"or" do not need that:

=A0 Only AES Counter mode (AES-CTR) is discussed in this specification.<= br>|=A0 AES-CTR requires the encryptor to generate a unique per-packet valu= e,
=A0 and communicate this value to the decryptor.=A0 [...]
---
= =A0 Only AES Counter mode (AES-CTR) is discussed in this specification.
|=A0 AES-CTR requires the encryptor to generate a unique per-packet value=A0 and communicate this value to the decryptor.=A0 [...]
[Sean] Done.=

(4c)=A0 4th para

I fear the text copying from RFC 3686 went too far here, without the
= necessary adoption.=A0 This draft addresses IEKv2-inernal use of AES-CTR,and that happens within the *IKE* SA, not in the *IPsec* SAs.
So pleas= e correct, for the purpose of this memo:

=A0 This specification calls for the use of a nonce for additional
= =A0 protection against precomputation attacks.=A0 The nonce value need not<= br>=A0 be secret.=A0 However, the nonce MUST be unpredictable prior to the<= br>|=A0 establishment of the IPsec security association that is making use = of
=A0 AES-CTR.
---=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 ^^^^^
=A0 This specification calls for the use of a nonce for add= itional
=A0 protection against precomputation attacks.=A0 The nonce valu= e need not
=A0 be secret.=A0 However, the nonce MUST be unpredictable pr= ior to the
|=A0 establishment of the IKE security association that is making use of=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^
= =A0 AES-CTR.
[Sean] Done.

(4d)=A0 5th para -- clarifications / textual enhancements

I suggest to change:

=A0 AES-CTR has many properties that make it an attractive encryption|=A0 algorithm for in high-speed networking.=A0 AES-CTR uses the AES block=
=A0 cipher to create a stream cipher.=A0 Data is encrypted and decrypte= d by
=A0 XORing with the key stream produced by AES encrypting sequential
=A0= counter block values.=A0 AES-CTR is easy to implement, and AES-CTR can
= =A0 be pipelined and parallelized.=A0 AES-CTR also supports key stream
= =A0 precomputation.
---
=A0 AES-CTR has many properties that make it an attractive encryptio= n
|=A0 algorithm for use in high-speed networking.=A0 AES-CTR uses the A= ES
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^
=A0 block cipher = to create a stream cipher.=A0 Data is encrypted and
|=A0 decrypted by XORing with the key stream produced by encrypting
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 ^
|=A0 sequential counter block values with AES in ECB mode.=A0 AES-= CTR is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^^^^^^^^^^^^^^^^^
=A0 easy to implement, and AES-CTR can be pipelined and parallelized.
= =A0 AES-CTR also supports key stream precomputation.
[Sean]
Modified= the "... for use in ...".
Wrote the second one as "... = values with AES."

(4e)=A0 6th para -- typo

Please correct:=A0 s/AES- CTR/AES-CTR/=A0 .
[Sean] Done

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^=A0=A0=A0= =A0=A0=A0 ^
(4f)=A0 7th para -- punctuation

There should not be a comma in=A0 "... one could use ..., to proces= s ..."
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 ^
[Sean] Done.

(4g)=A0 9th para -- language improvement

Please swap words in the first line to restore correct semantics:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vvvvvvvv
|=A0 AES-CTR uses= the only AES encrypt operation (for both encryption and
=A0 decryption)= , making AES-CTR implementations smaller than
=A0 implementations of man= y other AES modes.
---=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vvvvvvvv
|=A0 AES-CTR uses only the AES encrypt operation (for both encryption and=A0 decryption), making AES-CTR implementations smaller than
=A0 imple= mentations of many other AES modes.
[Sean] Done

(4h)=A0 10th para

As in item (4c) above, two last sentences in this paragraph have not
= been properly transformed into the intended context, inside IKEv2.
Pleas= e change:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [...].=A0 Extraordinary measures wo= uld be needed to prevent
=A0 reuse of an IV value with the static key ac= ross power cycles.=A0 To be
|=A0 safe, implementations MUST use fresh ke= ys with AES-CTR.=A0 The Internet
|=A0 Key Exchange [RFC4306] protocol can be used to establish fresh keys.=A0 IKE can also provide the nonce value.
---
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 [...].=A0 Extraordinary measures would be needed to prevent=
=A0 reuse of an IV value with the static key across power cycles.=A0 To= be
|=A0 safe, implementations MUST use fresh keys with AES-CTR.=A0 The initial=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^^^^
|=A0 exchange of the= IKEv2 protocol [RFC4306] can be used to establish
=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|=A0 fresh keys for an IKEv= 2 SA, and it also provides the nonce value.

[Sean] Done=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^^^^^^^^^^^^^^^^^^^= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^


(5)=A0 Section 2.2

I recommend to drop the entire section.
Detailed reasoning:

|2.2.=A0 Key Sizes and Rounds

See the rationale in item (3) above.

|=A0 AES supports three key sizes: 128 bits, 192 bits, and 256 bits.=A0 = [...]

That already has been stated earlier in the draft and hence is redundant= .

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [...].=A0 All
|=A0 IKEv2 implementations = that implement AES-CTR MUST support the 128 key
|=A0 size.=A0 An IKEv2 i= mplementation MAY support key sizes of 192 and 256
|=A0 bits.

That belongs into the normative part of the draft.
I suggest putting = these two sentences as a new (2nd) paragraph into
Section 5.

|=A0 AES MUST use different rounds for each of the key sizes:
|
|= =A0=A0=A0=A0 When a 128-bit key is used, implementations MUST use 10 rounds= .
|
|=A0=A0=A0=A0 When a 192-bit key is used, implementations MUST us= e 12 rounds.
|
|=A0=A0=A0=A0 When a 256-bit key is used, implementations MUST use 14 = rounds.

As pointed out in item (3) above, that is an internal detail of the
A= ES design and not subject to importance or change by the user of AES.
Th= is part definitely does not belong into this document.
[Sean] As answere= d in item (3).

(6)=A0 Section 2.3

I recommend to drop the entire section.
Detailed reasoning:

|2.3.=A0 Block Size
|
|=A0 The AES algorithm has a block size of 1= 28 bits (16 octets), i.e., AES
|=A0 generate 128 bits of key stream.=A0 = [...]

This statement is misleading; the correct description can be found
ea= rlier, in Section 2.1.

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 [...].=A0 For encryption or decryption, a
|=A0 user XOR the= key stream with 128 bits of plaintext or ciphertext
|=A0 blocks.=A0 If = the generated key stream is longer than the plaintext or
|=A0 ciphertext, the extra key stream bits are simply discarded.=A0 For thi= s
|=A0 reason, AES-CTR does not require the plaintext to be padded to a<= br>|=A0 multiple of the block size.

This all has been explained at length and in detail in Section 2.1.
W= hy would we want to repeat it again here?
[Sean] The point here is plain= text padding.

(7)=A0 Section 3.1

In the first part of the text here, an article is missing.
The second= part again rephrases parts of Section 2.1, and it does so
in a confusin= gly general way that does not help the implementor of
AES-CTR for use wi= thin IKEv2.=A0 I request to drop that text.
Instead, I suggest to add a pointer to where the IV is used.

In total, please change:
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= v
|=A0 The IV field MUST be eight octets when AES_CTR algorithm is used= for
=A0 encryption.=A0 The IV MUST be chosen by the encryptor in a mann= er that
=A0 ensures that the same IV value is NOT used more than once with a
=A0= given encryption key.=A0 The encryptor can generate the IV in any
=A0 m= anner that ensures uniqueness.=A0 Common approaches to IV generation
=A0= include incrementing a counter for each packet and linear feedback
=A0 shift registers (LFSRs).
---=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vv= vvv=A0=A0 v
=A0 The IV field MUST be eight octets when the AES-CTR algor= ithm is used
=A0 for encryption.=A0 The IV MUST be chosen by the encrypt= or in a manner
=A0 that ensures that the same IV value is NOT used more than once with a|=A0 given encryption key.=A0 See Section 4 for how the IV is used to
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^= ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|=A0 construct counter blocks for = AES-CTR use within IKEv2.
=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Sean] Done.<= /p>

(8)=A0 Section 3.2

Again, a definite article is missing here.=A0 Please adjust:

=A0=A0 s/for Encrypted Payload/for the Encrypted Payload/
=A0=A0=A0= =A0=A0=A0=A0 ^=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ^^^^^
[Sean] Done

(9)=A0 Section 3.3, 2nd para

In two more instances, the definitie article is missing.
Please adjus= t:

|=A0 It should be noticed that ESP [RFC4303] Encrypted Payload requires<= br>|=A0 alignment on a 4-byte boundary while IKEv2 [RFC4306] Encrypted
= =A0 Payload does not have such a requirement.
---=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vvvvv
|=A0 It should be noticed that the ESP [RFC4303] Encrypted Payload
|=A0 = requires alignment on a 4-byte boundary while the IKEv2 [RFC4306]
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^
=A0 Encr= ypted Payload does not have such a requirement.

[Sean] Done.

(10)=A0 Section 4

Again, please adjust ...

(10a)=A0 2nd para

=A0 The Encrypted Payload is the XOR of the plaintext and key stream.|=A0 The key stream is generated by inputing Counter Blocks into AES
= =A0 algorithm.=A0 [...]
---
=A0 The Encrypted Payload is the XOR of t= he plaintext and key stream.
|=A0 The key stream is generated by inputing Counter Blocks into the AES=A0 algorithm.=A0 [...]
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^
[Sean= ] Done.

(10b)=A0 last para

=A0 Section 2 provides references to other documents for implementing|=A0 AES_CTR encryption/decryption process.
---
=A0 Section 2 provid= es references to other documents for implementing
|=A0 the AES-CTR encry= ption/decryption process.
=A0 ^^^^=A0=A0 ^

(11)=A0 Section 5

|=A0 This section describes the conventions used by IKEv2 protocol to|=A0 generate encryption keys and nonces for use with AES-CTR algorithm in=
|=A0 IKE-SA negotiation.=A0 The identifiers and attributes related to A= ES-
|=A0 CTR required during IKE-SA and Child-SA negotiation are also defined.<= /p>

Please fix missing articles and a singular/plural issue.
[Sean] Done.=

I'm not sure whether the mention of Child-SA is appropriate here.IMHO, that is covere in RFC 3686, and should not be re-stated here.
I p= ropose changed wording below.=A0 Please check!
[Sean] The words here are= not giving description for AES-CTR usage as in RFC3686, it mentions Child-= SA because IKEv2 negotiates transformes used for Child-SA.

Further, as mentioned in item (5) above, I suggest to move text
from = the obsolescent Section 2.2 into this section.

This results in the following revised text:
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vvvvv
|=A0 This section descr= ibes the conventions used by the IKEv2 protocol to
|=A0 generate encrypt= ion keys and nonces for use with the AES-CTR
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 v=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^<= br>|=A0 algorithm in IKE-SA negotiations.=A0 The identifiers and attributes=
|=A0 related to AES-CTR as defined in [RFC3686] are used in the same|=A0 manner during IKE-SA negotiation.
|
|=A0 All IKEv2 implementations that implement AES-CTR MUST support the= 128
|=A0 key size.=A0 An IKEv2 implementation MAY support key sizes of = 192 and
|=A0 256 bits.


(12)=A0 Section 5.1

(12a)=A0 2nd para

Again, an article is missing, and item (1a) applies.

After an abbreviation has been introduced, it may be used to
streamli= ne the text; therefore I suggest to delete the repeated
expansion of &qu= ot;PRF".

Hence, please change:

=A0 IKEv2 negotiates four cryptographic algorithms with its peer using|=A0 IKE_SA_INIT exchange.=A0 They include an encryption algorithm and a<= br>|=A0 pseudo-random function(PRF).=A0 All the payloads of IKEv2 messages = that
=A0 follow the IKE_SA_INIT exchange are encrypted using the negotiated
|= =A0 encryption algorithm.=A0 The pseudo-random function(PRF)is used to
= =A0 generate the keying material required for the encryption algorithm.
= ---
=A0 IKEv2 negotiates four cryptographic algorithms with its peer using
|= =A0 the IKE_SA_INIT exchange.=A0 They include an encryption algorithm and a=
=A0 ^^^^=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 v
|=A0 p= seudo-random function (PRF).=A0 All the payloads of IKEv2 messages
=A0 that follow the IKE_SA_INIT exchange are encrypted using the
|=A0 ne= gotiated encryption algorithm.=A0 The PRF is used to generate the
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^=A0=A0 ^
=A0 keying material required= for the encryption algorithm.
[Sean] Done.

(12b)=A0 3rd para

Item (1b) again:

|=A0 AES_CTR encryption algorithm needs an encryption key and a nonce.=A0 [...]
---vvvv
|=A0 The AES_CTR encryption algorithm needs an en= cryption key and a nonce.
=A0 [...]
[Sean] Done.


(13)=A0 Section 5.2

I suggest to insert the word "value" before "of 13",= and to avoid
the unnecessary repetition of the code point.
The above= concerns w.r.t. "Child-SA" apply.
So please change:

|=A0 IKEv2 uses the IANA allocated encryption identifier of 13 for
|= =A0 ENCR_AES_CTR with an explicit IV (ENCR_AES_CTR 13) as the transform
= |=A0 ID during IKE-SA and Child-SA negotiation.
---
|=A0 IKEv2 uses t= he IANA allocated encryption identifier value of 13 for
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 v=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 ^^^^^^^=A0=A0=A0=A0=A0=A0=A0 vvv
|=A0 ENCR_AES_CTR with an explicit = IV as the transform ID during IKE-SA
=A0 negotiation.
[Sean] Added th= e "value".

(14)=A0 Section 6

(14a)=A0 2nd para -- language improvement

Please adjust:

=A0 AES_CTR provides high confidentiality when used properly.=A0 However= ,
|=A0 as a stream mode cipher, the security of will lose when AES-CTR i= s
=A0 misused.
---=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^^^^^^^^ =A0 AES_CTR provides high confidentiality when used properly.=A0 However,|=A0 as a stream mode cipher, the security will be lost when AES-CTR is=A0 misused.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^^^^^^^^[Sean] Done

(14b)=A0 3rd para

Following (1b), please correct:

=A0 Generally, a stream cipher should not use static keys.=A0 This is=A0 because key streams will be easily canceled when two ciphertext use|=A0 the same key stream (check detailed description of this attack in
= =A0 [RFC3686]).=A0 Therefore, IKEv2 should avoid an identical key being
|=A0 used for different IKE SA or a same key stream being used on
=A0 di= fferent blocks of plaintext.=A0 [...]
---
=A0 Generally, a stream cip= her should not use static keys.=A0 This is
=A0 because key streams will = be easily canceled when two ciphertext use
|=A0 the same key stream (check the detailed description of this attack in<= br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 ^^^^^
=A0 [RFC3686]).=A0 Therefore, IKEv2 should avoid an iden= tical key being
|=A0 used for different IKE SAs or a same key stream bei= ng used on
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 ^
=A0 different blocks of plaintext.=A0 [...]
[Sean] Done.


(14c)=A0 4th para -- language improvements

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 v=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vvv= vv
|=A0 A stream cipher like AES_CTR is also vulnerable under data forge= ry
|=A0 attack (check [RFC3686] for a demonstration of this attack).=A0 = [...]
---=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 v=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = vvvvvvv
|=A0 A stream cipher like AES-CTR is also vulnerable against data forgery|=A0 attacks (check [RFC3686] for a demonstration of this attack).=A0 [..= .]
=A0=A0=A0=A0=A0=A0=A0 ^
[Sean] Corrected the singular/plural.

(14d)=A0 5th para

Again, according to (1b) please correct:
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 v
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [...].=A0 Sin= ce IKEv2 are not likely to carry traffics in
=A0 such a high quantity, t= his won't be a big concern here.=A0 However,
=A0 when large amount of traffic appear in the future or under abnormal
= =A0 circumstances, implementations SHOULD generate a fresh key before
= =A0 2^64 blocks are encrypted with the same key.
---
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 [...].=A0 Since IKEv2 are not likely to carry traf= fic in
=A0 such a high quantity, this won't be a big concern here.=A0 However,=
|=A0 when a large amount of traffic appears in the future or under
= =A0=A0=A0=A0=A0 ^^^=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^
=A0 abnormal circumstances, implemen= tations SHOULD generate a fresh key
=A0 before 2^64 blocks are encrypted with the same key.
[Sean] Done.

(15)=A0 Section 7

I suggest to more clearly indicate what this draft is expecting IANA
= to do: adding a reference to this memo for an existing registration.

|=A0 IANA has assigned 13 as the transform ID for ENCR_AES_CTR encryptio= n
|=A0 with an explicit IV.=A0 This ID is to be used during IKE_SA
|= =A0 negotiation.
---
|=A0 Per [RFC3686], IANA has assigned 13 as the = "IKEv2 Encryption
|=A0 Transform ID" to the name "ENCR_AES_CTR" for AES-CTR en= cryption with
|=A0 an explicit IV, in the IANA "Internet Key Exchan= ge Version 2 (IKEv2)
|=A0 Parameters" registry.=A0 This document sp= ecifies how to use this
|=A0 transform during IKE_SA negotiations.=A0 Hence IANA should add to that=
|=A0 entry a reference to this RFC.
[Sean] It's a good point, bu= t for IANA's reference to this document, I assume iana will updated the= ir reference (following some rocedure?) when this document is processed. Le= t me know if we have to request it in the draft.
I added the a reference of IANA-Para to the IANA-IKEv2-parameters link.

Best,

Sean

--001636d34a3ec1312e0476454064-- From sheila.frankel@nist.gov Mon Oct 19 09:18:48 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3263A679C; Mon, 19 Oct 2009 09:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 w2PrcDFizkr9; Mon, 19 Oct 2009 09:18:47 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 71DE628C137; Mon, 19 Oct 2009 09:18:05 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9JGIKb8032162; Mon, 19 Oct 2009 12:18:20 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Mon, 19 Oct 2009 12:18:02 -0400 From: "Frankel, Sheila E." To: "ipsec@ietf.org" , "ipv6@ietf.org" Date: Mon, 19 Oct 2009 12:18:03 -0400 Thread-Topic: USGv6 Testing Program to begin Operation November 30th, 2009 Thread-Index: AcpQ0WKNqaX1GulsRe6m1ORb1iki0AABgTMw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_D7A0423E5E193F40BE6E94126930C493078A34A20BMBCLUSTERxcha_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: "Nightingale, J. Stephen" Subject: [IPsec] USGv6 Testing Program to begin Operation November 30th, 2009 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 16:18:48 -0000 --_002_D7A0423E5E193F40BE6E94126930C493078A34A20BMBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following the publication of the USGv6 Profile version 1.0, NIST and its=20 testing partners have been developing the USGv6 Testing Program. Various=20 aspects of the program have been offered for review to various=20 constituencies over the past 18 months or so. The program will begin=20 operations on November 30th 2009, with accredited labs testing IPv6=20 products to USGv6 test suites. The attached announcement offers the=20 public an opportunity to review the operational documents, test suites=20 and website prior to launch. The comment period concludes on November=20 16th to give us time for final emendation. We look forward to your comments. Stephen Nightingale USGv6 Testing Program. --_002_D7A0423E5E193F40BE6E94126930C493078A34A20BMBCLUSTERxcha_ Content-Type: video/x-flv; name="NIST-announce-20091016.pdf" Content-Description: NIST-announce-20091016.pdf Content-Disposition: attachment; filename="NIST-announce-20091016.pdf"; size=23535; creation-date="Mon, 19 Oct 2009 11:32:36 GMT"; modification-date="Mon, 19 Oct 2009 11:32:36 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjEzNiAwIG9iag08PC9MaW5lYXJpemVkIDEvTCAyMzUzNS9PIDEzOC9F IDEwNTk2L04gMi9UIDIwNzY3L0ggWyA4NzIgMjY3XT4+DWVuZG9iag0gICAgICAgICAgICAgICAg DQp4cmVmDQoxMzYgMjgNCjAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMTMxNyAwMDAwMCBuDQow MDAwMDAxNTk1IDAwMDAwIG4NCjAwMDAwMDE4NzIgMDAwMDAgbg0KMDAwMDAwMTkzOSAwMDAwMCBu DQowMDAwMDAyMDk1IDAwMDAwIG4NCjAwMDAwMDIyNTEgMDAwMDAgbg0KMDAwMDAwMjQwNyAwMDAw MCBuDQowMDAwMDAyNTYwIDAwMDAwIG4NCjAwMDAwMDI3MTQgMDAwMDAgbg0KMDAwMDAwMjg2OCAw MDAwMCBuDQowMDAwMDAzMjc5IDAwMDAwIG4NCjAwMDAwMDM4MDEgMDAwMDAgbg0KMDAwMDAwMzgz OCAwMDAwMCBuDQowMDAwMDA0MDgyIDAwMDAwIG4NCjAwMDAwMDQxNjAgMDAwMDAgbg0KMDAwMDAw NjYxMCAwMDAwMCBuDQowMDAwMDA2OTcxIDAwMDAwIG4NCjAwMDAwMDcyMDYgMDAwMDAgbg0KMDAw MDAwOTkwMCAwMDAwMCBuDQowMDAwMDA5OTc3IDAwMDAwIG4NCjAwMDAwMTAwNTAgMDAwMDAgbg0K MDAwMDAxMDEyMyAwMDAwMCBuDQowMDAwMDEwMTk2IDAwMDAwIG4NCjAwMDAwMTAyNjkgMDAwMDAg bg0KMDAwMDAxMDM0NiAwMDAwMCBuDQowMDAwMDAxMTM5IDAwMDAwIG4NCjAwMDAwMDA4NzIgMDAw MDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSAxNjQvUHJldiAyMDc1NS9YUmVmU3RtIDExMzkvUm9vdCAx MzcgMCBSL0luZm8gMTYgMCBSL0lEWzwzNjZCOURDNUQ5MEZBQzcwRDFEMkQxNDc4NjQ2NzFCRj48 NTdEN0I0QzgzMEJCMDI0N0EzRUY3ODVFMEE0Rjg0MzY+XT4+DQpzdGFydHhyZWYNCjANCiUlRU9G DQogICAgICAgICAgICAgDQoxNjMgMCBvYmoNPDwvTGVuZ3RoIDE3My9DIDE3Mi9GaWx0ZXIvRmxh dGVEZWNvZGUvSSAyMDQvTCAxNTYvUyA4ND4+c3RyZWFtDQp42mJgYGBhYGA1YGBlYOBOZOBlQABe oBgrUJZjAcM+BwaGxQzIgFVX59yX784yYA6LR0dHB5BmlOgAqQRJMzAY7wLSEkAsCxZRZeDhZ5Bj LyhnLyhhDygVT3zKwHCeaWauiMOxZQIaTA4qINRwlXFCHrtCMaMB1BoeBga7EiDNBMS2QMzFwGD6 CcLnaALSAgys90wPH7mkc9LxShiYz+D3FeQSIBIGCDAAVMUhWw0KZW5kc3RyZWFtDWVuZG9iag0x NjIgMCBvYmoNPDwvTGVuZ3RoIDI3L0ZpbHRlci9GbGF0ZURlY29kZS9XWzEgMSAxXS9JbmRleFsx NyAxMTldL0RlY29kZVBhcm1zPDwvQ29sdW1ucyAzL1ByZWRpY3RvciAxMj4+L1NpemUgMTM2L1R5 cGUvWFJlZj4+c3RyZWFtDQp42mJi4mJgYmBgHMWDBTPOpZZZAAEGAJBdAg4NCmVuZHN0cmVhbQ1l bmRvYmoNMTM3IDAgb2JqDTw8L01hcmtJbmZvPDwvTGV0dGVyc3BhY2VGbGFncyAwL01hcmtlZCB0 cnVlPj4vTWV0YWRhdGEgMTUgMCBSL1BpZWNlSW5mbzw8L01hcmtlZFBERjw8L0xhc3RNb2RpZmll ZChEOjIwMDkxMDE2MTE1MjE0KT4+Pj4vUGFnZXMgMTQgMCBSL1BhZ2VMYXlvdXQvT25lQ29sdW1u L1N0cnVjdFRyZWVSb290IDE3IDAgUi9UeXBlL0NhdGFsb2cvTGFuZyj+/wBFAE4ALQBVAFMpL0xh c3RNb2RpZmllZChEOjIwMDkxMDE2MTE1MjE0KS9QYWdlTGFiZWxzIDEyIDAgUj4+DWVuZG9iag0x MzggMCBvYmoNPDwvQ3JvcEJveFswIDAgNjEyIDc5Ml0vQW5ub3RzIDEzOSAwIFIvUGFyZW50IDE0 IDAgUi9TdHJ1Y3RQYXJlbnRzIDAvQ29udGVudHMgMTUxIDAgUi9Sb3RhdGUgMC9NZWRpYUJveFsw IDAgNjEyIDc5Ml0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMCAxNDggMCBSPj4vRm9udDw8 L1RUMCAxNDYgMCBSL1RUMSAxNDcgMCBSL1RUMiAxNTIgMCBSPj4vUHJvY1NldFsvUERGL1RleHRd L0V4dEdTdGF0ZTw8L0dTMCAxNTAgMCBSPj4+Pi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMTM5IDAgb2Jq DVsxNDAgMCBSIDE0MSAwIFIgMTQyIDAgUiAxNDMgMCBSIDE0NCAwIFIgMTQ1IDAgUl0NZW5kb2Jq DTE0MCAwIG9iag08PC9SZWN0WzI0Mi45NCAyMzIuNjQ3IDUwMC45NTcgMjQ5LjY5XS9TdWJ0eXBl L0xpbmsvQlM8PC9TL1MvVyAwL1R5cGUvQm9yZGVyPj4vQSAxNjAgMCBSL0YgNC9IL0kvU3RydWN0 UGFyZW50IDEvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90Pj4NZW5kb2JqDTE0MSAwIG9iag08PC9S ZWN0WzI2My42NCAyMTguNDI3IDQ3OS42MDQgMjM1LjQ3XS9TdWJ0eXBlL0xpbmsvQlM8PC9TL1Mv VyAwL1R5cGUvQm9yZGVyPj4vQSAxNTkgMCBSL0YgNC9IL0kvU3RydWN0UGFyZW50IDIvQm9yZGVy WzAgMCAwXS9UeXBlL0Fubm90Pj4NZW5kb2JqDTE0MiAwIG9iag08PC9SZWN0WzQ0Mi45OCAxNzYu NjA2IDQ3OC45NzQgMTkzLjY1XS9TdWJ0eXBlL0xpbmsvQlM8PC9TL1MvVyAwL1R5cGUvQm9yZGVy Pj4vQSAxNTggMCBSL0YgNC9IL0kvU3RydWN0UGFyZW50IDMvQm9yZGVyWzAgMCAwXS9UeXBlL0Fu bm90Pj4NZW5kb2JqDTE0MyAwIG9iag08PC9SZWN0WzkwLjAgMTY1LjI2NiAyNjkuOTcgMTgyLjMx XS9TdWJ0eXBlL0xpbmsvQlM8PC9TL1MvVyAwL1R5cGUvQm9yZGVyPj4vQSAxNTcgMCBSL0YgNC9I L0kvU3RydWN0UGFyZW50IDQvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90Pj4NZW5kb2JqDTE0NCAw IG9iag08PC9SZWN0WzI3MC4wIDE2OC4zOTYgMjczLjAgMTg0LjE2NF0vU3VidHlwZS9MaW5rL0JT PDwvUy9TL1cgMC9UeXBlL0JvcmRlcj4+L0EgMTU2IDAgUi9GIDQvSC9JL1N0cnVjdFBhcmVudCA1 L0JvcmRlclswIDAgMF0vVHlwZS9Bbm5vdD4+DWVuZG9iag0xNDUgMCBvYmoNPDwvUmVjdFs5MC4w IDEwOS43MDcgMzQ3Ljk1NyAxMjYuNzVdL1N1YnR5cGUvTGluay9CUzw8L1MvUy9XIDAvVHlwZS9C b3JkZXI+Pi9BIDE1NSAwIFIvRiA0L0gvSS9TdHJ1Y3RQYXJlbnQgNi9Cb3JkZXJbMCAwIDBdL1R5 cGUvQW5ub3Q+Pg1lbmRvYmoNMTQ2IDAgb2JqDTw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2Ny aXB0b3IgMTYxIDAgUi9MYXN0Q2hhciAxMTkvV2lkdGhzWzI1MCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDI1MCAwIDAgMCAwIDAgMCAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDcyMiAwIDcy MiA3MjIgNjY3IDYxMSA3NzggNzc4IDM4OSAwIDAgNjY3IDk0NCA3MjIgNzc4IDYxMSAwIDcyMiA1 NTYgNjY3IDcyMiAwIDAgMCA3MjIgMCAwIDAgMCAwIDAgMCA1MDAgMCAwIDU1NiA0NDQgMzMzIDUw MCAwIDI3OCAwIDAgMjc4IDgzMyA1NTYgNTAwIDAgMCA0NDQgMzg5IDMzMyAwIDUwMCA3MjJdL0Jh c2VGb250L1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQvRmlyc3RDaGFyIDMyL0VuY29kaW5nL1dpbkFu c2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMTQ3IDAgb2JqDTw8L1N1YnR5cGUvVHJ1ZVR5 cGUvRm9udERlc2NyaXB0b3IgMTQ5IDAgUi9MYXN0Q2hhciAxNDgvV2lkdGhzWzI1MCAwIDAgMCAw IDAgMCAwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgMjc4IDAgMCAwIDAgMCAwIDcyMiAwIDY2NyA3MjIgNjExIDU1NiA3 MjIgMCAzMzMgMzg5IDcyMiA2MTEgODg5IDcyMiA3MjIgNTU2IDAgNjY3IDU1NiA2MTEgNzIyIDcy MiAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4 IDI3OCA1MDAgMjc4IDc3OCA1MDAgNTAwIDUwMCA1MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIg NTAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAz MzMgNDQ0IDQ0NF0vQmFzZUZvbnQvVGltZXNOZXdSb21hblBTTVQvRmlyc3RDaGFyIDMyL0VuY29k aW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMTQ4IDAgb2JqDVsvSUNDQmFz ZWQgMTU0IDAgUl0NZW5kb2JqDTE0OSAwIG9iag08PC9TdGVtViA4Mi9Gb250TmFtZS9UaW1lc05l d1JvbWFuUFNNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDAvRmxhZ3MgMzQvRGVz Y2VudCAtMjE2L0ZvbnRCQm94Wy01NjggLTMwNyAyMDAwIDEwMDddL0FzY2VudCA4OTEvRm9udEZh bWlseShUaW1lcyBOZXcgUm9tYW4pL0NhcEhlaWdodCA2NTYvWEhlaWdodCAtNTQ2L1R5cGUvRm9u dERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMD4+DWVuZG9iag0xNTAgMCBvYmoNPDwvT1BNIDEvT1Ag ZmFsc2Uvb3AgZmFsc2UvVHlwZS9FeHRHU3RhdGUvU0EgZmFsc2UvU00gMC4wMj4+DWVuZG9iag0x NTEgMCBvYmoNPDwvTGVuZ3RoIDIzNzgvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJpFdd b6NIFn23tP+hHvEqECi+TGs0Wrfjns1o40QJvdIouw/Yrtj0YPACdib/fs+tggI7uHt6OpES4lBV 55577rm3Psaj6wf200/Xd7PbG2azn3/+eDNjo+vZk81WFT6gb1at8tH1L/hoU42u49hmDotfRqZt 2bbts3jF2qdX5nC5BL8im4X2xJp4LN6Nno2b+cP0Mb4bm6ExH3NjEbP7T2x2f3c3f5zN2fi/8a+j +R0d3cFxNJw4dtSZtjyNDrKZ6VgONr8ZGWwcf3m3mrerJbiAFkrEPOiW+7T82VgkdVrkScZu82rs G3VaH8aBUQtWvLCnOsnXSbmuGH6zWKy2eZEVmze8MIza1edqrPHfL2D0ehE2rEq0XJM66cAGCuws yTL2UpTsURxT8ToODYlsVux2Iq9ZkStYcrXXRS2T41m+7xOm9ci4zdM6Rcyfn345YmtR1Wm+YQ9l sSmTnUVoh2h3XCsImx0GQ/LbkEw+sTj32zRdej/4KgVdlozpL/PF7LczXPRm2AXpEkTPcl2F8Nn4 wP5Kbq2LyQ3fJ9eU5zU4L0U5eR+l2YEnfUxn8e39YiA8r9WCI3PoWlHkd+E9iv8dkDopCJLAeGJA BZU1DD8agK82/AZ+xz6pJrdB/WyY775A8sCHWpIyr46DQxsVvX8X53fW4ltB8O5N/UpEr7g64fqV 4SCck/BNblvR5JuR8wsCbTkwnj7f3U0fh5TZmY4tTcfvgH5gbHH7FLPXpGJ1Uv0u1uw1rbdsLY4i K2R8erGjjNXyg7Z291SqCau0fvdl8ZJmQsrg9gH1rBlyOwyyOkwntCb9hD+jGBrhp0JVQsKkjpK8 oipJqkpUFZ1YbwVbFfS/vUyo2tbRZqWARhb3WqBZmuQrWWtAuD6sakS7TWq2ypJ0x+oC2+XAvGM6 YiXKZpMuN3iVTm/itBj7tygrFDbYxub0L+VjLRHE6/6wzNJqC2rTnP16yN7w6n/+xji5KoWpOQp0 BLyx62ejFKu2nNbYQaI+whfE2HSMfI2noqzYUrBNehQ5GQb3JG1FXm+rngdHnT21/DhRW8CZSLB3 uhtHhiA6SpGsajx0y8/zF1qR165mKfgs4QBpKSRUiQ2fpU0TMHloOX1zAlFp2eaCZWkuYBXDuv+e PuZ4F5qtwiwJjXWOqNc0jWbsGbuxa0D7aGqAdUzXQmazJ0C8ozUInjdjx9AqdFqFtfrACyWxIJcp pZy1Qw2mWH4RqxrZaxXUw0W7s7SSCkVOatFt4nTBRTKfaHNhq3foihV7kV+xl0z8kS6hxLrprGn+ UiZVXYL4QymUoAaq1IlUAahdu8xlMIYy2aBCsW+74/qADd+YeEEN1VVLgviD9h0uzrAHtqZ5YV+A V8L5uqW62Zdn3iONa2L5k2YRpYgORyrZoUIRKt/SkXQjBz0iEu5bE//Ub4ARCT2gU5SUvIrlAj+r pHzDRxQFlABTqplIOt67Nu/KKkWJoqLT/Ah+Zf00wpf2py0NekjFpXbo+N+jcT2pDDJL6+ItJJMX dQpBlqoxNy60wt80rUnfIWMRFwlD5oO2wNU8R3xVoiaZbg7pWup9XawOJyUvDW3AdFQCTbnriedD 6xWNQikecQSeIEhZh1RcEYrL9IwyrVQ9ytJTA2OqBqnLFgWROdqjkhyLaAQ79emzWkOZsulLTbcD GVGJHtQd4HcH8LaH4YReOK7N1slby7V2bshblGmxvqJmi0k5Ju+QMSIdFNDY5AYiJPKabkFOTjA1 wS25krEhOfKwdx9pbhTVoaE1kVSZ7bFodxWNoDAU32iJbfd0Omtx2p7vhS2Riny5EED2RB0sLqFU qRKk3aTrdSAnXc2ozABiNz3mBK5HhWNQR60YpXeFtnnIqPEV1OS6LYMzjCbHjSA4qe+eOYsaWyzf lC2BxEYDqyQTNLmwN5GUlPuz+bBvr6EVasTTWvnmvkjz+uqynEAISQmED5HrOa2IwhPciBPeXUq1 UjlkKJDVVp2YrNAH1rIGCuox1RXLksGLlkKNUW+iYS8LbFqU7XiFeWFNwwMhTYj2N1C8oZ4NzK9F +Tv5awf89A5nNlv3a7nYCFBBdiqVhpSR74kcsZD8BKGX//UMsU4pJRCnFmYpJXXILt4anIFbT/9m NmyX+spz2VGjC7ci7uhGfTONx6ZvzJ8ksrP5mp/5gnty86PrkKze9UGQjWI0Xgo0SsEWxREuExiU gKUoFdU6tJBuBTa+5YMLfWPi4iHHL0rGrolmEAFuC7QSv1z0vYgzHoSWx+Uqx6+3VzR9RtYgHdwe uJ1hWgyCb91RuHOBSIernWj9RDnT9ObmEWyCU/ljjiod4rZnRermMok6ZqfHJM2SJTSWkYKU7aix S9pRT0VPe0xEGifvIiSYrFrldC7vQ3Z18A7+bviUT9zjMhVuZHmBSsWzsa1rSuX+w/X16+urhXaz tnIMSNamOF4fqs0xuG4mMGtb77IO2jwe6Q0DK2Tcn1hwN5vSVYrRy+hjfMKx28dua+wtZ/Jaq7Pv 27hb4usErGENjUlNg3Y9i6uqnjRl/YDLQUWdH5YhMoxDZZGfNDc58F3k2vsxrgPYOqiBinkre8mm 2bBprpry+scJ5VqeRG+7B9rYBCL9Crn+V8nVs0UzcLmnpeaF0TusVxhOpY2+n7DVctOVzVVWVm8u reVFap9h5GcvxQHUJ7XsM8kSpsFexbKCgV4wSh78BaPk4fviPb9oON1OTRl/un9knz4/whxd45/z R3a7wCd30/j2fsFm94t4OovPqlo5qxQbt7sxAOX8VIv9VuRskW62lFo056se1FNZTX5IVh5V3ATN wW1dUYmqLxv9jk3W556r5hROv4U0GM7PjPAA96ZhaDcy/rx8aV0QWbhtAMrXQLj291gDD0/wDGrC 1YaOdv8t93f5BfdXt4BulOpJ8dl4+vzw8C8a8ed3NHbMFzH9MX38jd3S3wv0Ba2ood7bm8l9menA CrrR8gOLT2YzKsXeeKbHrCQbHKmdSDU/tWdv1FFTubrsXcmRXI1UGzns0N0EDZ5eSKi5yWuH3L83 qGPTkGugCcaBRLWzTKhap9GJ5usvdAOlgsd4hJq/6LSu+0MlQTIDJp83zoWG9qeb2ZlaHdcKA2pk F43W9b5Hqi5s+wQbRvVBBWr7Nrlj+T1T7SkWGP8vwADSqqt3DQplbmRzdHJlYW0NZW5kb2JqDTE1 MiAwIG9iag08PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDE1MyAwIFIvTGFzdENo YXIgMTIxL1dpZHRoc1s2MDAgNjAwIDYwMCAwIDAgMCAwIDAgMCA2MDAgMCAwIDAgNjAwIDAgMCAw IDAgMCA2MDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCA2MDAgNjAwIDYwMCAwIDAgNjAw IDYwMCA2MDAgNjAwIDYwMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAgNjAwXS9CYXNlRm9u dC9Db3VyaWVyTmV3UFNNVC9GaXJzdENoYXIgNDUvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5 cGUvRm9udD4+DWVuZG9iag0xNTMgMCBvYmoNPDwvU3RlbVYgNDIvRm9udE5hbWUvQ291cmllck5l d1BTTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNDAwL0ZsYWdzIDM0L0Rlc2NlbnQg LTMwMC9Gb250QkJveFstMjEgLTY4MCA2MzggMTAyMV0vQXNjZW50IDgzMi9Gb250RmFtaWx5KENv dXJpZXIgTmV3KS9DYXBIZWlnaHQgNTc4L1hIZWlnaHQgLTU3OC9UeXBlL0ZvbnREZXNjcmlwdG9y L0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMTU0IDAgb2JqDTw8L0xlbmd0aCAyNTk4L0ZpbHRlci9G bGF0ZURlY29kZS9OIDMvQWx0ZXJuYXRlL0RldmljZVJHQj4+c3RyZWFtDQpo3pyWd1RU1xaHz713 eqHNMNIZepMuMID0LiAdBFEYZgYYygDDDE1siKhARBERAUWQoIABo6FIrIhiISioYA9IEFBiMIqo qGRG1kp8eXnv5eX3x73f2mfvc/fZe5+1LgAkTx8uLwWWAiCZJ+AHejjTV4VH0LH9AAZ4gAGmADBZ 6am+Qe7BQCQvNxd6usgJ/IveDAFI/L5l6OlPp4P/T9KsVL4AAMhfxOZsTjpLxPkiTsoUpIrtMyKm xiSKGUaJmS9KUMRyYo5b5KWffRbZUczsZB5bxOKcU9nJbDH3iHh7hpAjYsRHxAUZXE6miG+LWDNJ mMwV8VtxbDKHmQ4AiiS2CziseBGbiJjEDw50EfFyAHCkuC845gsWcLIE4kO5pKRm87lx8QK6LkuP bmptzaB7cjKTOAKBoT+Tlcjks+kuKcmpTF42AItn/iwZcW3poiJbmlpbWhqaGZl+Uaj/uvg3Je7t Ir0K+NwziNb3h+2v/FLqAGDMimqz6w9bzH4AOrYCIHf/D5vmIQAkRX1rv/HFeWjieYkXCFJtjI0z MzONuByWkbigv+t/OvwNffE9I/F2v5eH7sqJZQqTBHRx3VgpSSlCPj09lcni0A3/PMT/OPCv81ga yInl8Dk8UUSoaMq4vDhRu3lsroCbwqNzef+pif8w7E9anGuRKPWfADXKCEjdoALk5z6AohABEnlQ 3PXf++aDDwXimxemOrE4958F/fuucIn4kc6N+xznEhhMZwn5GYtr4msJ0IAAJAEVyAMVoAF0gSEw A1bAFjgCN7AC+IFgEA7WAhaIB8mADzJBLtgMCkAR2AX2gkpQA+pBI2gBJ0AHOA0ugMvgOrgJ7oAH YASMg+dgBrwB8xAEYSEyRIHkIVVICzKAzCAGZA+5QT5QIBQORUNxEA8SQrnQFqgIKoUqoVqoEfoW OgVdgK5CA9A9aBSagn6F3sMITIKpsDKsDRvDDNgJ9oaD4TVwHJwG58D58E64Aq6Dj8Ht8AX4OnwH HoGfw7MIQIgIDVFDDBEG4oL4IRFILMJHNiCFSDlSh7QgXUgvcgsZQaaRdygMioKiowxRtihPVAiK hUpDbUAVoypRR1HtqB7ULdQoagb1CU1GK6EN0DZoL/QqdBw6E12ALkc3oNvQl9B30OPoNxgMhobR wVhhPDHhmATMOkwx5gCmFXMeM4AZw8xisVh5rAHWDuuHZWIF2ALsfuwx7DnsIHYc+xZHxKnizHDu uAgcD5eHK8c14c7iBnETuHm8FF4Lb4P3w7Px2fgSfD2+C38DP46fJ0gTdAh2hGBCAmEzoYLQQrhE eEh4RSQS1YnWxAAil7iJWEE8TrxCHCW+I8mQ9EkupEiSkLSTdIR0nnSP9IpMJmuTHckRZAF5J7mR fJH8mPxWgiJhJOElwZbYKFEl0S4xKPFCEi+pJekkuVYyR7Jc8qTkDclpKbyUtpSLFFNqg1SV1Cmp YalZaYq0qbSfdLJ0sXST9FXpSRmsjLaMmwxbJl/msMxFmTEKQtGguFBYlC2UesolyjgVQ9WhelET qEXUb6j91BlZGdllsqGyWbJVsmdkR2gITZvmRUuildBO0IZo75coL3FawlmyY0nLksElc3KKco5y HLlCuVa5O3Lv5enybvKJ8rvlO+QfKaAU9BUCFDIVDipcUphWpCraKrIUCxVPKN5XgpX0lQKV1ikd VupTmlVWUfZQTlXer3xReVqFpuKokqBSpnJWZUqVomqvylUtUz2n+owuS3eiJ9Er6D30GTUlNU81 oVqtWr/avLqOeoh6nnqr+iMNggZDI1ajTKNbY0ZTVdNXM1ezWfO+Fl6LoRWvtU+rV2tOW0c7THub dof2pI6cjpdOjk6zzkNdsq6Dbppune5tPYweQy9R74DeTX1Y30I/Xr9K/4YBbGBpwDU4YDCwFL3U eilvad3SYUOSoZNhhmGz4agRzcjHKM+ow+iFsaZxhPFu417jTyYWJkkm9SYPTGVMV5jmmXaZ/mqm b8YyqzK7bU42dzffaN5p/nKZwTLOsoPL7lpQLHwttll0W3y0tLLkW7ZYTllpWkVbVVsNM6gMf0Yx 44o12trZeqP1aet3NpY2ApsTNr/YGtom2jbZTi7XWc5ZXr98zE7djmlXazdiT7ePtj9kP+Kg5sB0 qHN44qjhyHZscJxw0nNKcDrm9MLZxJnv3OY852Ljst7lvCvi6uFa6NrvJuMW4lbp9thd3T3Ovdl9 xsPCY53HeU+0p7fnbs9hL2Uvllej18wKqxXrV/R4k7yDvCu9n/jo+/B9unxh3xW+e3wfrtRayVvZ 4Qf8vPz2+D3y1/FP8/8+ABPgH1AV8DTQNDA3sDeIEhQV1BT0Jtg5uCT4QYhuiDCkO1QyNDK0MXQu zDWsNGxklfGq9auuhyuEc8M7I7ARoRENEbOr3VbvXT0eaRFZEDm0RmdN1pqraxXWJq09EyUZxYw6 GY2ODotuiv7A9GPWMWdjvGKqY2ZYLqx9rOdsR3YZe4pjxynlTMTaxZbGTsbZxe2Jm4p3iC+Pn+a6 cCu5LxM8E2oS5hL9Eo8kLiSFJbUm45Kjk0/xZHiJvJ4UlZSslIFUg9SC1JE0m7S9aTN8b35DOpS+ Jr1TQBX9TPUJdYVbhaMZ9hlVGW8zQzNPZkln8bL6svWzd2RP5LjnfL0OtY61rjtXLXdz7uh6p/W1 G6ANMRu6N2pszN84vslj09HNhM2Jm3/IM8krzXu9JWxLV75y/qb8sa0eW5sLJAr4BcPbbLfVbEdt 527v32G+Y/+OT4XswmtFJkXlRR+KWcXXvjL9quKrhZ2xO/tLLEsO7sLs4u0a2u2w+2ipdGlO6dge 3z3tZfSywrLXe6P2Xi1fVl6zj7BPuG+kwqeic7/m/l37P1TGV96pcq5qrVaq3lE9d4B9YPCg48GW GuWaopr3h7iH7tZ61LbXadeVH8Yczjj8tD60vvdrxteNDQoNRQ0fj/COjBwNPNrTaNXY2KTUVNIM Nwubp45FHrv5jes3nS2GLbWttNai4+C48Pizb6O/HTrhfaL7JONky3da31W3UdoK26H27PaZjviO kc7wzoFTK051d9l2tX1v9P2R02qnq87Inik5Szibf3bhXM652fOp56cvxF0Y647qfnBx1cXbPQE9 /Ze8L1257H75Yq9T77krdldOX7W5euoa41rHdcvr7X0WfW0/WPzQ1m/Z337D6kbnTeubXQPLB84O OgxeuOV66/Jtr9vX76y8MzAUMnR3OHJ45C777uS9pHsv72fcn3+w6SH6YeEjqUflj5Ue1/2o92Pr iOXImVHX0b4nQU8ejLHGnv+U/tOH8fyn5KflE6oTjZNmk6en3KduPlv9bPx56vP56YKfpX+ufqH7 4rtfHH/pm1k1M/6S/3Lh1+JX8q+OvF72unvWf/bxm+Q383OFb+XfHn3HeNf7Puz9xHzmB+yHio96 H7s+eX96uJC8sPCbAAMA94Tz+woNCmVuZHN0cmVhbQ1lbmRvYmoNMTU1IDAgb2JqDTw8L1VSSSho dHRwOi8vd3d3LmFudGQubmlzdC5nb3YvdXNndjYvdGVzdGluZy5odG1sKS9TL1VSST4+DWVuZG9i ag0xNTYgMCBvYmoNPDwvVVJJKG1haWx0bzpzcDUwMC0yNzMtY29tbWVudHNAYW50ZC5uaXN0Lmdv dikvUy9VUkk+Pg1lbmRvYmoNMTU3IDAgb2JqDTw8L1VSSShtYWlsdG86c3A1MDAtMjczLWNvbW1l bnRzQGFudGQubmlzdC5nb3YpL1MvVVJJPj4NZW5kb2JqDTE1OCAwIG9iag08PC9VUkkobWFpbHRv OnNwNTAwLTI3My1jb21tZW50c0BhbnRkLm5pc3QuZ292KS9TL1VSST4+DWVuZG9iag0xNTkgMCBv YmoNPDwvVVJJKG1haWx0bzpzcDUwMC0yNzMtY29tbWVudHNAYW50ZC5uaXN0LmdvdikvUy9VUkk+ Pg1lbmRvYmoNMTYwIDAgb2JqDTw8L1VSSShodHRwOi8vd3d3LmFudGQubmlzdC5nb3YvdXNndjYv dGVzdGluZy5odG1sKS9TL1VSST4+DWVuZG9iag0xNjEgMCBvYmoNPDwvU3RlbVYgMTM2L0ZvbnRO YW1lL1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQg NzAwL0ZsYWdzIDM0L0Rlc2NlbnQgLTIxNi9Gb250QkJveFstNTU4IC0zMDcgMjAwMCAxMDI2XS9B c2NlbnQgODkxL0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJvbWFuKS9DYXBIZWlnaHQgNjU2L1hIZWln aHQgLTU0Ni9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMSAwIG9i ag08PC9Dcm9wQm94WzAgMCA2MTIgNzkyXS9Bbm5vdHMgMiAwIFIvUGFyZW50IDE0IDAgUi9TdHJ1 Y3RQYXJlbnRzIDcvQ29udGVudHMgMyAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDYxMiA3OTJd L1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzAgMTQ4IDAgUj4+L0ZvbnQ8PC9UVDAgMTQ3IDAg Ui9UVDEgNiAwIFIvVFQyIDE1MiAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwv R1MwIDE1MCAwIFI+Pj4+L1R5cGUvUGFnZT4+DWVuZG9iag0yIDAgb2JqDVs3IDAgUiA4IDAgUl0N ZW5kb2JqDTMgMCBvYmoNPDwvTGVuZ3RoIDIzMjQvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0N CkiJpFddc9s4EnzXr8AjdWXS/BIlpra2zrG9Ke9ecq4TNy/2PUAUJGFNE1qClE7//mYAkCAVKnZ2 K1WJIpHATE9PT8/HbHL9SH766frz7cMd8cnPP3+8uyWT69ulT3IJX+AfIvNycv0JvtrKyXWW+SQg 2Wbie74fwKecuPgxnJPsSIJQvQL/pD6Z+wsvTUj2OnlyMiZrIvcsn84cvpnGDsdPtOailISWa1Iz +D88M/1v9qs627dnB5E6O/D82QxOz9ZwoGQFy83rFSNis2EVW5MdnMKmbuDAdxuhDnPb047Eqci+ WRU8JxU7cHYkqxPhZQ1vyhpenmZ/6Ktje3WC77nmbjfwghne7+xpVXMmr+D1vGjWvNySh8dDQvaV WDd5TdbswAqxZ5XEQ92zhOJUJZR46dwk5FyRgq5ERWtRnQjNc0imCyfqXvQVEnMvTsxrvFYYkpVY q3BqxLm7MlD3uGHsxVE/+u4qeEeh//vyE7nZsjKHLzz1/v1nJIIlR9CSw8dgfBW/1z/THXsr7CiV ZUHLmyhqk1Y3DSnlzyz2+pIg6Yqe7Zhkqt71jqlcJSC94aX+4nW6cBgtsRhigzkdEvcAlSO5wJ/2 08ApOC1z5mmanUcbfZuj+44k4x9P0hIMP55lef8/ljc1XRU6RZ0WcrreibUkjQSq8tKQhEPjdCw3 jZJ4SdqdttaHDEqOJzbw5QpuqGjO1F2281IbnSaQObHD4clZ0fyF1AJgnyYOk9h1F0Cd/TVQkx8H NbFiFH4D6s0G2hzC5RIkAGLuqwB2QMlyJjEPqtTjpH7rIauAANlB/cInQHiuCCXAPVoQieJVI+kU 1hIvgMJIcuRFgSgPhWgArt8icQdRKnWSOygwxrRmkm9LitJEJfL5a+JO3bnzdRo6SGvVABdgn/81 2Bc/BHsPYWdUNdL2OA2iKosb9YLIBKQmOYAGjDblQBi79t6IinxhnRT2Bo5S5iD20thEUB9F9UIe K1HryaAwfHiULL9++O3+EJKH2+XNv+hKaqHv4aIOwaAW6qBnx+ay3NPSiqBvUUUI9GjMslDD0fVg Dk96vpmF6lMa49+zue+pgegcj0eP55JCW0oP5am98D6bmGeTubeICQxQ34tDwGaymXwczOsg6Efj d9H0B7SFazGcz0HqDyJ6cp6nBJpjJwo1zSjij6xGshOYZqUqke53cmTsxeqFyrgVb1WTXuNhOb+I A0PNWUELBkj4iNCa/CJghpasvjLSY2Od6bEVGr4uNFeWTVmeDhSk6vbGI7eirGlek0ulCt9bKj3L zuoV+iB5MZnNEi9aqIptm5Mny9OaVf+8VLjupchL4B548WLpordLF9pBGA5rF8XxMDhAGT2VgAFX gWrUlBeXdCGIR4QhDDyQTNuV4w5gNmhmzS3rrbJ/TJwvD8uMLB/JzPfdcB6R5zCM1Bgmyv99ZmqC fSCfWMkqOtLUgZ75qZe2A8wpyB2TecX3XUt/pQVfK9sD58dkB9q4Yqzs2Z5It7U+xqaF+oLDE+aW tm2sBQtI2kVjDYihM3q/VuRQmMDj4axQ0qTco2uG65nVs9jAEVGrUujvgDdgILnszC+o4LrnP23p /bBthSjtz194nCMCMHzyHctf9DkroCXYG6k7VRsiNc9KugUHkTjGSiROWU8jp1VaSGhbUfzNI2Qp uofa3xVuymp3Pa+dv28K/+QYPEEwPlzgXTLgHbJldAAF87/jprRdHw5+Y5NEJTHRvZAob7WAUPXW gAMIytm5LICmU7bZmbIl3iK0yoaQty5M2/A9qGOl7IEB1HitqRvjclOKmm9OozuOv2idFt5gOata SteBa7qV6iagDFwM3kD7XEjNsk+vYnMPTIsJtQsHFxYiqjV6IYHOBOwG+guhCaPPsvElvSGpzrOB HdlKgse5sC0sBtV+j/MI0r9V+HPHN6j7a2PBV4Aed6AXxhdb3GKDm+93NdamGbgCVQ0dtS7B9jFi vSPFvBQCNvevYRkTW1A8gPrI653Ct+tw61V9vWGGicq11+Jj3l/3NRBB5gKohhsNQ3aYhTFp98EL 4h9a/2Io107c+FuD+OS4Biw0segLgPBlA4pjfNrrNHUYq/lZu/Q3kQ7Hcqv10pJMTYTHTnkArAvK EQY9Ypjx3Tdv/cElRpfQkS10lE7zLnwFh+8t2gSc3qZQMSmKA1O9ODLCtOIDEdrUu/FglB83USP+ l8oUfT9j3wuC2ZtZj6ylY1nbyKPZWdYQu8m17wXlnuUc7Ybag3KKPwDlgHwaEuiVfaUWIqOJlYD1 EslyMd/Zd/PVEb2V7sjC+MaWqDvvLF9VZuNy2WbDc5qfehuJShbmByQFj2zRcOnBCZ8uJDe2iUVn KY2KaLgYGq7OZgdDw3X3n5tfrO1aBGe2C8PFPuu4mtounRu7NV90CFCsFPldsgqOCSX51PA1U0YL tgNKSoBnLfJGNT/sBLb5rRj7ceu/4Ny+aeGdnK1xAQAQD1xvGzCUDqyy65/CvzbRW3+iGpDDWij2 YCA7R2hlWOuOsiSXzI+a8O4cvU4GRd1ifmi/gOvgA4iEXacCkeudOTNzoZV2LmXD0DOSrTKyhbaB EO2VMZYQ9Yfxmqbfb+0YLnmD6ZH/TqafF2TAdArW19pqS/AzwC90bPR9TX5Xx0bvkOVRN93XZQoO +CS5bDMo+Iblp7zQ5YE8rK+36h7q4RR6iw4Ojm8oKw4QmE/acSHR97hoAkyW7Gl/ACnX0eN5K4OK pCucysi6gtenS3BeEvwz4zSO4zuEvueR+ujZ7UeBt2z2+4K3jX/XIWeJBPRF5GCtTTvoWF5Q04tw zq0oYc5jfyF9IGUyZg/CwJwT2HOeneXdv2+fp1fgzkAceK17CeBbo80B62pP6i1Ic22ffOXaLFS5 KPWGpH2H8srwvytV2p04qvOlMcENbIXjRjaajah37L2p3VEycFq9eNOBdlfsz0YxrmcwwCO8orSi uIHzan2je240tHgvvMTaVTAah97aB6LEaaGy3LFiT1gpG7SvXaOPqbeeLq45uEfrngwXtClztLRU oSibHLZOuWkKBTZGLWv6wtA0surS2I9GJiMCMw5oNwyHj9xnk/8LMACjNN9wDQplbmRzdHJlYW0N ZW5kb2JqDTQgMCBvYmoNPDwvU3RlbVYgODgvRm9udE5hbWUvQXJpYWxNVC9Gb250U3RyZXRjaC9O b3JtYWwvRm9udFdlaWdodCA0MDAvRmxhZ3MgMzIvRGVzY2VudCAtMjExL0ZvbnRCQm94Wy02NjUg LTMyNSAyMDAwIDEwMDZdL0FzY2VudCA5MDUvRm9udEZhbWlseShBcmlhbCkvQ2FwSGVpZ2h0IDcx OC9YSGVpZ2h0IDUxNS9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoN NSAwIG9iag08PC9VUkkobWFpbHRvOmd1eS5zbnlkZXJAaWNzYWxhYnMuY29tKS9TL1VSST4+DWVu ZG9iag02IDAgb2JqDTw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgNCAwIFIvTGFz dENoYXIgMzIvV2lkdGhzWzI3OF0vQmFzZUZvbnQvQXJpYWxNVC9GaXJzdENoYXIgMzIvRW5jb2Rp bmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag03IDAgb2JqDTw8L1JlY3RbOTQu MDIgNTYzLjc4NiAxOTAuMDA0IDU4MC44M10vU3VidHlwZS9MaW5rL0JTPDwvUy9TL1cgMC9UeXBl L0JvcmRlcj4+L0EgOSAwIFIvRiA0L0gvSS9TdHJ1Y3RQYXJlbnQgOC9Cb3JkZXJbMCAwIDBdL1R5 cGUvQW5ub3Q+Pg1lbmRvYmoNOCAwIG9iag08PC9SZWN0WzIwNi42NCA1NDkuNTY2IDM0NC42MTcg NTY2LjYxXS9TdWJ0eXBlL0xpbmsvQlM8PC9TL1MvVyAwL1R5cGUvQm9yZGVyPj4vQSA1IDAgUi9G IDQvSC9JL1N0cnVjdFBhcmVudCA5L0JvcmRlclswIDAgMF0vVHlwZS9Bbm5vdD4+DWVuZG9iag05 IDAgb2JqDTw8L1VSSShodHRwOi8vd3d3Lmljc2FsYWJzLmNvbS8pL1MvVVJJPj4NZW5kb2JqDTEw IDAgb2JqDTw8L0ZpcnN0IDgwOC9MZW5ndGggMTc1My9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAxMDAv VHlwZS9PYmpTdG0+PnN0cmVhbQ0KeNrUWN9PG0cQ7p+yUl/ah/b29w8pikRIUCkEUEzUB8SDgQt1 Q2x0mCr89/3mZte+g7ODLSWoDzC3t7PfzHwzu7NnFYQUKgoljVBJWC+FlsKRUCJKLbQWMUAYkZIV 2gqloKedUNpi7IUyHuMglHdBaCAFvNQJMjlhAJ6gbxRkjMIQoNfCGCACxADC0HsHaO+FwVKnrDCA chHrIkxgYMiE0sLCrwB7VsGUVMICLzopLPBixDzwEoxa4CXYsYCUCmNASChbmJIJY3IJAyw1Wnrh FCSMOLgGIOEMXAQDDq6YAELIVQTngGc93gPPAdeR6zDugOeSFuDNeMQFFeODFRRqQNAeeAF2PfAi uPTAI1op5CShTyHCmAdeikFQiBJkwLSV4D0gVAXnsMRq2A0GEk7BBNyCdKAApAcPiUUhgArwGCIk nAzAs4grEjVIdwSeQ/xEGfkdgeeRlAg8j5eAtJTHCLyAoOGSDRgAwkYFCbyIYInKCP8S8BJ4AJRN cC6BEomSwpSTIB+l4CT+JaIayUkBEiAJlGpDtQUJkpQEp8ggHkAyUoIHjQfgUIU6BIMHgDpUqQJx zkUqXsB6S8rADW05AzgAVUkgU4UoylaiulVATiBKKcoXMq8UEqKQJQXGPOoVD0iJbld55A4Yr15V B7RPpPhQnYybejo/beqatkz/zVH9dX5QP8Bu9WF2U78f39J+Ip3Th9u6Gs2b+8tW8cNsNq92b8Z3 d62OIp3Xr8nMGTmGUesXS5uly9JnGbKMWSaWbBFSZZnxdMbTGU9nPJ3xdMbTGU9nPJPxTMYzGU9m fZNxZcY1Wcqiz3YMwyWezUqWbVmeiywcz0W24xnG8ygwmGfNwK4FVgmtynl1IpiaalSN6st5dTie Xv/y7ui3j6Offm1JPrr/cncmRQlc5MjpNGHnRI7dlgdXHuhEYWMi89Eea21kgpk4b23sT28m03r0 9xh535tc3zd19baZ3e6Ob8vw+H5OKtXodjyt/jh9f/izlidN/WnWfBnP5/VVdVKN7i/uLpvJ7ZyV Rve3ddN9cXq8g79d/O21EgU2+VzP7ss0yvHN7Gv1dvJvdUSwN8B8N72azuY1XuDfHupwOfo4vaqb pU9A3SfY/WqvGX+pW5heQDDPCm3EAyEIrr1svIwO989yLeZS5Epk3mD5st75NK8bIX+XbQg7N5Nr BD8fN/PqGNl8oAD/aibzyfT6/eyqrg6b0wte+IZs14uV+whoOm+HCLszasGW4+9m+TcV19o2/gWN 0/SLGXeWjP//Tjsl+2MZ15+G0vXkwsyjQ1LqoUPzPHeE1iaejy/+EcpyRzm5hlZcNpfjN3+ihbSn nyzH3+Fk+rm0FXZ0AaK2A8lnuVzg6MeLFzNm5YwdNmg7BjueLWzrXgDumwGoXgBnuQExfYIJEOy/ YGeFzV2Jo7RcKjZ0O5bpj9zqbubYkGNDjg05021xjpc7NuQY2jGKyw1HDnRBzyieUXzuiYziGcXH bzbKllaOJ7MaFpwOMWrs04pgAvLyuOHyndIRDs5S6aK4n5UtZNo0xrxqsENmUxnNeEbDbiZ7Jq9c trWePh1Wb+vLWTOeT2bT1tml5uLM62vtzm5mzRnOMpH/zovpWExLMq1/oOnCoZAb0QVXoZ9cScrF zeN53e4i+XxAQ4B+NaCl+fR8PEf6YTWep/kNAg6kb1bjRZrXz6+3BfPKblipy5Vu06S1QcvVQag2 SrUBIoUd4xrERAphi+j0piWpqSbjmhRpKsroN0Ckoox2DSLlLroNECllUa1BpBRFuQ1fYds60nFT pimpYc1mNZS7sMFuNZS7sGa7Gspd2MBHQ7kLa3JnKHfBbMGXcdsybfzWK7fOrullt3zKPToMc/ft Eja7eihQLjfafD1g0qjBhkUH2M89nasipzLD9Vrx4RNQ7thcLUOgXV2+rXAdDDqQbzL9aiqhHORb T796O7P5dtzdoQM05NsV71LyIurHNPAxlM+ODLeOhl0sJWSOj8+oIeSuF0wxnz6DXuTbYP8MW0br ClOdM7Mza8psHOLCFi/45sUnfOtFeswFN5yMM0yC7ZHA+kmthMz34n4zW7puQ5k1Q66b7Hq+oqfF Lz/JPnGd85GyJjOezOpATDcQWz735CoLXW/yD0HpObpcVimu9FyUT5zuHajDUEluGtoGdsGuG+Kv XLtxUc0fvMY+67bd+STbaX+UzQcUndRGDt56O0u+y733DJ/yOj3J5zMj8AUkAoQAdHqhKJa/Q5ry Q6R224SUyp2AuqOOPzQc+n09W6dur8NLkLk7yNQzP5B6ZC7v6dsv1dsvNdsu3S2XBP7oGro6lGX/ CTAAj93mLQ0KZW5kc3RyZWFtDWVuZG9iag0xMSAwIG9iag08PC9GaXJzdCAxNDkvTGVuZ3RoIDIx NC9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAxOS9UeXBlL09ialN0bS9FeHRlbmRzIDEwIDAgUj4+c3Ry ZWFtDQp42qSTQYoCMRBFr/LBAyRVlaokIMLsBB1p1AsI47hRBhrvjxVXM5uBdFavO7yXBJIQZUQQ FWh11PcnsQ/l7CSwmJPBVZ0C0caERI2KZOw0aPSWM1SbX2BRnBWmPpdEWPX5hJBTcjJKbBQUa0yo 3KioJWG9Dh/wNSOOYQcNE3xT7ecUtufP/YrjNF+/f+bH5fm8foXp5uVb2Gz+prY8zcvTsjyty1OK Ay0NtPy7PbTi/p8ufXrq07VPtz499+mlTx84fB44fB54JTJwcaTrYb8EGAAWjB0aDQplbmRzdHJl YW0NZW5kb2JqDTEyIDAgb2JqDTw8L051bXNbMCAxMyAwIFJdPj4NZW5kb2JqDTEzIDAgb2JqDTw8 L1MvRD4+DWVuZG9iag0xNCAwIG9iag08PC9Db3VudCAyL1R5cGUvUGFnZXMvS2lkc1sxMzggMCBS IDEgMCBSXT4+DWVuZG9iag0xNSAwIG9iag08PC9TdWJ0eXBlL1hNTC9MZW5ndGggNDAyNi9UeXBl L01ldGFkYXRhPj5zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6 cmVTek5UY3prYzlkIj8+Cjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1w dGs9IkFkb2JlIFhNUCBDb3JlIDQuMC1jMzE2IDQ0LjI1MzkyMSwgU3VuIE9jdCAwMSAyMDA2IDE3 OjE0OjM5Ij4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAy LzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIK ICAgICAgICAgICAgeG1sbnM6cGRmPSJodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvIj4KICAg ICAgICAgPHBkZjpQcm9kdWNlcj5BY3JvYmF0IERpc3RpbGxlciA4LjEuMCAoV2luZG93cyk8L3Bk ZjpQcm9kdWNlcj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRp b24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnBkZng9Imh0dHA6Ly9ucy5hZG9iZS5j b20vcGRmeC8xLjMvIj4KICAgICAgICAgPHBkZng6Q29tcGFueT5OSVNUPC9wZGZ4OkNvbXBhbnk+ CiAgICAgICAgIDxwZGZ4OlNvdXJjZU1vZGlmaWVkPkQ6MjAwOTEwMTYxNTUxNDc8L3BkZng6U291 cmNlTW9kaWZpZWQ+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0 aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5j b20veGFwLzEuMC8iPgogICAgICAgICA8eGFwOkNyZWF0ZURhdGU+MjAwOS0xMC0xNlQxMTo1Mjox MC0wNDowMDwveGFwOkNyZWF0ZURhdGU+CiAgICAgICAgIDx4YXA6Q3JlYXRvclRvb2w+QWNyb2Jh dCBQREZNYWtlciA4LjEgZm9yIFdvcmQ8L3hhcDpDcmVhdG9yVG9vbD4KICAgICAgICAgPHhhcDpN b2RpZnlEYXRlPjIwMDktMTAtMTZUMTE6NTI6MTQtMDQ6MDA8L3hhcDpNb2RpZnlEYXRlPgogICAg ICAgICA8eGFwOk1ldGFkYXRhRGF0ZT4yMDA5LTEwLTE2VDExOjUyOjE0LTA0OjAwPC94YXA6TWV0 YWRhdGFEYXRlPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlv biByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eGFwTU09Imh0dHA6Ly9ucy5hZG9iZS5j b20veGFwLzEuMC9tbS8iPgogICAgICAgICA8eGFwTU06RG9jdW1lbnRJRD51dWlkOjg2MTZiMmE0 LWRjM2ItNDI3Ny04Yjk2LWY1MGNkZDI1ZTFlNzwveGFwTU06RG9jdW1lbnRJRD4KICAgICAgICAg PHhhcE1NOkluc3RhbmNlSUQ+dXVpZDoxMjhkNjZkNC0zM2E2LTQ3ZWYtYTU4Zi1jZWY0ZDMxYmRl MTA8L3hhcE1NOkluc3RhbmNlSUQ+CiAgICAgICAgIDx4YXBNTTpzdWJqZWN0PgogICAgICAgICAg ICA8cmRmOlNlcT4KICAgICAgICAgICAgICAgPHJkZjpsaT40PC9yZGY6bGk+CiAgICAgICAgICAg IDwvcmRmOlNlcT4KICAgICAgICAgPC94YXBNTTpzdWJqZWN0PgogICAgICA8L3JkZjpEZXNjcmlw dGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1s bnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZv cm1hdD5hcHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1hdD4KICAgICAgICAgPGRjOmNyZWF0b3I+CiAg ICAgICAgICAgIDxyZGY6U2VxPgogICAgICAgICAgICAgICA8cmRmOmxpPk5ldyBCdWlsZDwvcmRm OmxpPgogICAgICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAgIDwvZGM6Y3JlYXRvcj4KICAgICAg ICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAgICAgICAgICAgPHJkZjps aSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5JUFY2IE1lZXRpbmcgQW5ub3VuY2VtZW50PC9yZGY6bGk+ CiAgICAgICAgICAgIDwvcmRmOkFsdD4KICAgICAgICAgPC9kYzp0aXRsZT4KICAgICAgPC9yZGY6 RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0idyI/Pg0K ZW5kc3RyZWFtDWVuZG9iag0xNiAwIG9iag08PC9DcmVhdGlvbkRhdGUoRDoyMDA5MTAxNjExNTIx MC0wNCcwMCcpL0F1dGhvcihOZXcgQnVpbGQpL0NyZWF0b3IoQWNyb2JhdCBQREZNYWtlciA4LjEg Zm9yIFdvcmQpL1Byb2R1Y2VyKEFjcm9iYXQgRGlzdGlsbGVyIDguMS4wIFwoV2luZG93c1wpKS9N b2REYXRlKEQ6MjAwOTEwMTYxMTUyMTQtMDQnMDAnKS9Db21wYW55KE5JU1QpL1NvdXJjZU1vZGlm aWVkKEQ6MjAwOTEwMTYxNTUxNDcpL1RpdGxlKElQVjYgTWVldGluZyBBbm5vdW5jZW1lbnQpPj4N ZW5kb2JqDXhyZWYNCjAgMTM2DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMTA1OTYgMDAwMDAg bg0KMDAwMDAxMDg2NSAwMDAwMCBuDQowMDAwMDEwODk0IDAwMDAwIG4NCjAwMDAwMTMyODggMDAw MDAgbg0KMDAwMDAxMzUwOSAwMDAwMCBuDQowMDAwMDEzNTcxIDAwMDAwIG4NCjAwMDAwMTM3MTgg MDAwMDAgbg0KMDAwMDAxMzg2OSAwMDAwMCBuDQowMDAwMDE0MDIxIDAwMDAwIG4NCjAwMDAwMTQw NzcgMDAwMDAgbg0KMDAwMDAxNTkyOSAwMDAwMCBuDQowMDAwMDE2MjU1IDAwMDAwIG4NCjAwMDAw MTYyOTEgMDAwMDAgbg0KMDAwMDAxNjMxNiAwMDAwMCBuDQowMDAwMDE2Mzc2IDAwMDAwIG4NCjAw MDAwMjA0ODAgMDAwMDAgbg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCnRyYWlsZXINCjw8L1NpemUgMTM2Pj4NCnN0YXJ0eHJlZg0KMTE2DQolJUVPRg0K --_002_D7A0423E5E193F40BE6E94126930C493078A34A20BMBCLUSTERxcha_-- From kivinen@iki.fi Tue Oct 20 02:07:15 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E3728C0F4 for ; Tue, 20 Oct 2009 02:07:15 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char CE hex): Cc: Alfred H\316nes ; Tue, 20 Oct 2009 02:07:14 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBA428C0F3 for ; Tue, 20 Oct 2009 02:07:14 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9K97FOD003669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Oct 2009 12:07:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9K97EC5016676; Tue, 20 Oct 2009 12:07:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19165.32194.275245.431639@fireball.kivinen.iki.fi> Date: Tue, 20 Oct 2009 12:07:14 +0300 From: Tero Kivinen To: Shen Sean In-Reply-To: <80b5a9190910190108t46e6c862s9f8c48895e5b3851@mail.gmail.com> References: <200910131509.RAA22549@TR-Sys.de> <80b5a9190910190108t46e6c862s9f8c48895e5b3851@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 9 min Cc: ipsec@ietf.org, Alfred HÎnes , draft-ietf-ipsecme-aes-ctr-ikev2@tools.ietf.org Subject: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 09:07:15 -0000 Shen Sean writes: > (3) Section 2 (and ff.) ... > The number of (internal) rounds is totally irrelevant for the > application of the AES. Any attempt to mangle with this 'parameter' > would raise significant security concerns and conformance issues. > I strongly request to elide all mention of "rounds" from the draft. I agree on that. In most cases the AES is implemented as part of cryptographic library or hardware, and for those you usually just indicate the key length to be used and that automatically selects the number of rounds. > [Sean] The intention of such a document is to give what a IKEv2 product > MUST/SHOULD/MAY provide. A user may not have "choices" of rounds or size, > but a vendor need to know what to provide. Usually even the vendor does not have choice, or even possibility to change the number of rounds, as that is hidden inside cryptographic library. > (15) Section 7 > > I suggest to more clearly indicate what this draft is expecting IANA > to do: adding a reference to this memo for an existing registration. > > | IANA has assigned 13 as the transform ID for ENCR_AES_CTR encryption > | with an explicit IV. This ID is to be used during IKE_SA > | negotiation. > --- > | Per [RFC3686], IANA has assigned 13 as the "IKEv2 Encryption > | Transform ID" to the name "ENCR_AES_CTR" for AES-CTR encryption with > | an explicit IV, in the IANA "Internet Key Exchange Version 2 (IKEv2) > | Parameters" registry. This document specifies how to use this > | transform during IKE_SA negotiations. Hence IANA should add to that > | entry a reference to this RFC. > [Sean] It's a good point, but for IANA's reference to this document, I > assume iana will updated their reference (following some rocedure?) when > this document is processed. Let me know if we have to request it in the > draft. I would not count on that. For example IANA didn't update the ENCR_AES-CCM_* or AES_GCM with a * octect ICV references for the RFC5282 automatically, so better add text there. -- kivinen@iki.fi From kivinen@iki.fi Tue Oct 20 06:41:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CE23A67E4 for ; Tue, 20 Oct 2009 06:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599] 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 GDATMjSa4NFE for ; Tue, 20 Oct 2009 06:40:57 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id F09713A6946 for ; Tue, 20 Oct 2009 06:40:56 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9KDexi0000790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Oct 2009 16:40:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9KDex9F006369; Tue, 20 Oct 2009 16:40:59 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19165.48619.530034.469960@fireball.kivinen.iki.fi> Date: Tue, 20 Oct 2009 16:40:59 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: pasi.eronen@nokia.com, sheila.frankel@nist.gov Subject: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 13:41:01 -0000 I was reading the USGv6 profile, and it complained that RFC4307 and RFC4835 do not agree on status of NULL encryption. RFC4307 says MAY, and RFC4835 says MUST. As far as I have understood the RFC4835 defines algorithm requirements for Child SAs (ESP and AH), and RFC4307 defines algorithm requirements for IKEv2 SAs, i.e. when IKEv2 protects its own traffic. However while the roadmap document agrees on that ("[RFC4307] specifies the encryption and integrity-protection algorithms used by IKEv2 to protect its own traffic") it also final sentence which makes this not so clear: "It also specifies the encryption and integrity-protection algorithms that IKEv2 negotiates for use within IPsec." I.e. that last sentence would indicate that RFC4307 would also define encryption and integrity-protection algorithms for Child SAs. On the other hand it does not list IPsec-v2 nor IPsec-v3 on the requirements level so that would indicate it does not apply to IPsec, only to IKE. In the abstract RFC4307 does not clearly say whether it only covers IKEv2 traffic or if it also covers Child SA (IPsec, ESP/AH) traffic negotiated with IKEv2. But later in the section 3.1.1 it clearly says that "The IKEv2 Encryption Payload requires..." which indicates it only covers IKEv2 SA traffic not anything else. If this is true, then the requirement level for ENCR_NULL is clearly wrong, as RFC4306 says that ENCR_NULL MUST NOT be used when protecting IKEv2 SA traffic (section 5. Security Considerations). So I would suggest we remove the misleading last sentence from the draft-ietf-ipsecme-roadmap-04.txt section 5.1.2, and make an errata for RFC4307 saying that ENCR_NULL is "MUST NOT" instead of "MAY". Also the USGv6 document might also distinguish the fact that RFC4835 and RFC4307 cover different protocols, thus they does not need to agree on the requirement levels, and NULL encryption cannot really be required for IKEv2 as it would go against MUST NOT in RFC4306. -- kivinen@iki.fi From paul.hoffman@vpnc.org Tue Oct 20 09:19:12 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8C528C17B for ; Tue, 20 Oct 2009 09:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.32 X-Spam-Level: X-Spam-Status: No, score=-5.32 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 lrtydQI0lXbv for ; Tue, 20 Oct 2009 09:19:11 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2BB8A28C12B for ; Tue, 20 Oct 2009 09:19:11 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9KGJH5o050457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Oct 2009 09:19:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 20 Oct 2009 09:19:15 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Closing the IKEv2bis open issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 16:19:12 -0000 Greetings again. There are three open issues for IKEv2bis. I would like to close the three of them so we can move forwards with the document. Issue #22, Add section on simultaneous IKE SA rekey There is no consensus on this issue. Tero Kivinen and David Wierbowski have deep differences of opinion, and almost no one else has participated. I have reviewed the discussion, and I think both people have strong merits to their opinion. Therefore, Yaron and I will try to coordinate a design team effort that includes Tero, David, and any others who have thought about this issue in depth. If that fails to come out with an agreed-to solution, we will probably drop back to adding a short, inconclusive, descriptive note in the IKEv2bis document. Issue #25, Choice of the right TS when narrowing This has not been discussed on the list. I have looked at what we say in RFC 4306, and it matches with the proposed text in the open issue. However, RFC 4718 says what we have in the current IKEv2bis draft. I believe that the new wording is in fact a technical change, but it has now been out there for many years. Therefore, I will make the following change: Current ikev2bis wording: When narrowing is done, there may be several subsets that are acceptable but their union is not. In this case, the responder arbitrarily chooses one of them, and MAY include an ADDITIONAL_TS_POSSIBLE notification in the response. Proposed change: When narrowing is done, there may be several subsets that are acceptable but their union is not. In this case, the responder SHOULD select the initiator's first choice (to be interoperable with RFC 4306), but MAY arbitrarily select any of them, and MAY include an ADDITIONAL_TS_POSSIBLE notification in the response. Issue #79, Remove CP from Create_Child_SA ? There is no consensus on this issue. There was lively discussion, but there is wide disagreement on how and when CP payloads should be used in the scenarios given, and what would constitute a change to RFC 4306. Therefore, I am adding the following to section 2.19 of IKEv2bis: "All responses that contain CP(CFG_REPLY) payloads apply to all the IPsec SAs that are set up by the exchange." Comments are welcome if you think they can help bring about rough consensus on these issues. --Paul Hoffman, Director --VPN Consortium From A.Hoenes@TR-Sys.de Tue Oct 20 16:08:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB453A690E for ; Tue, 20 Oct 2009 16:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.23 X-Spam-Level: ** X-Spam-Status: No, score=2.23 tagged_above=-999 required=5 tests=[AWL=0.979, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 xmf65Bu0l8+F for ; Tue, 20 Oct 2009 16:08:10 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 271DA3A681A for ; Tue, 20 Oct 2009 16:08:07 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA268150045; Wed, 21 Oct 2009 01:07:25 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA11677; Wed, 21 Oct 2009 01:07:18 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910202307.BAA11677@TR-Sys.de> To: kato.akihiro@po.ntts.co.jp, kanno.satoru@po.ntts.co.jp, kanda@isl.ntt.co.jp Date: Wed, 21 Oct 2009 01:07:17 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: ipsec@ietf.org Subject: [IPsec] draft-kato-ipsec-camellia-gcm-02 remaining editorials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 23:08:11 -0000 Hello once more, to complete my follow-up work for your Camellia related I-Ds, I also have addressed draft-kato-ipsec-camellia-gcm-02. Generally, the spirit of the reasoning is the same as in my recent editorial reviews for the sibling Camellia I-Ds. Therefore, I now use a more terse style. (Please feel free to ask back if it turns out that I'm not clear enough.) (1) Document Title Since Camellia-GCM as specified in the draft (and btw any instance of GCM in general) withing IPsec only applies to ESP (not to AH) and you do not specify IKEv2-internal use of Camellia-GCM, I suggest to clarify and amend the document title accordingly. Beyond that, "Modes of Operation" and "Modes" are synonym, which allows to simplify the headline. Altogether, I suggest to modify the title as follows: The Use of Galois/Counter Mode (GCM) Modes of Operation for Camellia and Its Use With IPsec --- | The Use of Galois/Counter Mode (GCM) for the Camellia Block Cipher | With IPsec ESP (2) Section 1 (2a) 1st para -- punctuation The commas are not neded: This document describes the use of the Camellia block cipher | algorithm in GCM Mode (Camellia-GCM) , as an IPsec ESP mechanism to | provide confidentiality, and data origin authentication. We refer to this method as Camellia-GCM-ESP. --- This document describes the use of the Camellia block cipher | algorithm in GCM Mode (Camellia-GCM) as an IPsec ESP mechanism to | provide confidentiality and data origin authentication. We refer to this method as Camellia-GCM-ESP. (2b) 2nd para << same as for the sibling drafts! >> (2c) 3rd para I suggest to insert "encryption" for clarity and as a counterpart to "authentication": | GCM mode provides Counter mode (CTR) with data origin authentication. This document does not cover implementation details of GCM. Those details can be found in [1]. --- vvvvvvvvvvvv | GCM mode provides Counter mode (CTR) encryption with data origin authentication. This document does not cover implementation details of GCM. Those details can be found in [1]. (3) Section 2 -- grammar Camellia-GCM comply with [2] on following points: --- vvv vvvvvv Camellia-GCM complies with [2] in the following points: And I would add to the end of this section a short description of what makes the difference (after all these similarities) : | | The only difference is the use of the Camellia block cipher primitive | instead of the AES block cipher primitive. (4) Section 3 -- punctuation The first commas is not neded: This section describes the conventions used to generate keying | material and salt values, for use with Camellia-GCM-ESP, using the Internet Key Exchange (IKE) [4] protocol. [...] --- This section describes the conventions used to generate keying | material and salt values for use with Camellia-GCM-ESP, using the Internet Key Exchange (IKE) [4] protocol. [...] (5) Sections 3.2 and 3.3 -- IKE Terminology The draft uses terminology from the old IKE (v1) : "Phase 1" and "Phase 2". Since you only address IKEv2 [4], that's confusing, and it would be better to switch to IKEv2-specific terms: "Initial Exchange", "CREATE_CHILD_SA Exchange", and "INFORMATIONAL Exchange". (6) Section 4 The abbreviation "TV" for "Test Vector" is not used anywhere else in the draft and hence "(TV)" should be deleted from the first text line in Section 4. (7) Section 5, 1st paragraph Please consult my suggestions for the sibling drafts for possible similar textual improvements. (8) Section 6 For added precision, I recommend to indicate *which* IANA registry shall be updated and in which sub-registry the assignment shall be performed, using the words from the registry file as a precise guide to IANA and prospective readers of your future RFC: | IANA has assigned three ESP Transform Identifiers for Camellia-GCM | with an eight-byte explicit IV: --- | IANA has assigned three Transform Type 1 (Encryption Algorithm) | Identifiers for Camellia-GCM with an eight-byte explicit IV in the | "IKEv2 Parameters" registry: Because of anecdotal evidence of previous trouble, the table should perhaps be amended to show precisely the entries for these transforms you would like to see registered: | for Camellia-GCM with an 8 octet ICV; | for Camellia-GCM with a 12 octet ICV; and | for Camellia-GCM with a 16 octet ICV. --- | Number Name Reference | -------- --------------------------------------- ----------- | Camellia-GCM with an 8 octet ICV [RFCxxxx] | Camellia-GCM with a 12 octet ICV [RFCxxxx] | Camellia-GCM with a 16 octet ICV [RFCxxxx] | | [[ IANA and RFC Editor: please substitute the RFC number assigned | to this document for 'xxxx' above. ]] BTW, IPSECME folks: I would appreciate if IANA could fix the current entry in the above registry for AES-GCM-8 _without_ consuming additional cycles of the IESG, when touching this registry for the memo under review: 18 AES-GCM with a 8 octet ICV [RFC4106] --- v 18 AES-GCM with an 8 octet ICV [RFC4106] :-) Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From ynir@checkpoint.com Wed Oct 21 00:46:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F05F3A67AB for ; Wed, 21 Oct 2009 00:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 5JWMinlihQv2 for ; Wed, 21 Oct 2009 00:46:43 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 017863A683D for ; Wed, 21 Oct 2009 00:46:28 -0700 (PDT) X-CheckPoint: {4ADEBA1D-1-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6868C29C00A; Wed, 21 Oct 2009 09:46:32 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4B48029C002; Wed, 21 Oct 2009 09:46:32 +0200 (IST) X-CheckPoint: {4ADEBA19-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9L7kVhu021133; Wed, 21 Oct 2009 09:46:31 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 21 Oct 2009 09:46:34 +0200 From: Yoav Nir To: Paul Hoffman Date: Wed, 21 Oct 2009 09:46:27 +0200 Thread-Topic: [IPsec] Closing the IKEv2bis open issues Thread-Index: AcpSIpvyBE5/xFaNTsGzXCEQTI/0pQ== Message-ID: <349076FF-487D-4B6C-91EB-1E845B2303F6@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-15-778597419"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Closing the IKEv2bis open issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 07:46:43 -0000 --Apple-Mail-15-778597419 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes A few lines above this section it already says "If the responder's policy allows it to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the initiator's first choices." So there is a MUST requirement to select the initiator's first choice (if possible), so I don't think the SHOULD and MAY are appropriate here. The way I read this section, it only clarifies what to do if the initiator traffic selector (first or not) is too broad. In that case, we shouldn't mention the initiator's choices. On Oct 20, 2009, at 6:19 PM, Paul Hoffman wrote: > Issue #25, Choice of the right TS when narrowing > Proposed change: > When narrowing is done, there may be several subsets that are > acceptable but their union is not. In this case, the responder > SHOULD select the initiator's first choice (to be interoperable > with RFC 4306), but MAY arbitrarily select any of them, > and MAY include an > ADDITIONAL_TS_POSSIBLE notification in the response. --Apple-Mail-15-778597419 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTAyMTA3 NDYyOFowIwYJKoZIhvcNAQkEMRYEFG0cp7n3yEU6ESyDzIWlUbrbjQvIMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQBxKU0Ntnqc fkA1Mch5efDRTQjlIjeTDE9TwvUByqedh8qoz6sx2tU4Z9BTB+st3/npHyf1Sqn/DV0iE64nz6Q0 h8j3Ee+KprjxED9IjWSpNcDILQGk0vlqxpWYNPAOcA7qoYKUT+NTgXQx50D1Qa+gQVFg3luqHQ9v p9rsG9qXSS2qFVApzUG5Dd++27tC3nuNu6/7ej0hrDVQc/SR4m15D3Q48WL/bzRFLu5F1sBIYRcs uoe+WyvfOGsKG+InpJl/Y9Rk2SHobj7tGlnxde7aMs7+A8IGJtzSBcHFa1jAUTsA0uXsDAHM+VAH fV6EtfalCQd7ubj0pOrucO7g2M1LAAAAAAAA --Apple-Mail-15-778597419-- From mglt.ietf@gmail.com Wed Oct 21 01:29:51 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0721B3A657C; Wed, 21 Oct 2009 01:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 BEmED9XS+1Qt; Wed, 21 Oct 2009 01:29:50 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 95D503A6804; Wed, 21 Oct 2009 01:29:46 -0700 (PDT) Received: by fxm18 with SMTP id 18so7443043fxm.37 for ; Wed, 21 Oct 2009 01:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ZV0ctBgXTHjEqGpqYDJJMzGdk0Z25QyOfWSmzGfkbEw=; b=jtToMWyYXSLH7S/JFNklfTwJqiNn+Q/3skUsNEBGaVzf2NXrN0y9Udtk/6q6VmObq8 1q92Nf93471W8afmc860aJoqjeNEr2SWGbN3Z985llEZMTF3S2sDrglcSn/mFUjbHFuQ vmoxWfFjWW/qif9zkwhL8c2AlUG0ISMNWys3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qXe0mz7fzObgmmDoT9v8dP9Bieh+zl81JCtXcxb2tiwXkxxl6AdO5ABI7iEOufq6Mv VgLo2ylSO10jjPTBp1ZaDN+EJzfNPol07muHoa896AwfjT3w/RWBLdLUDn+tDmKtUm/N W1D4N1H4h9ij5mRhpouu2Y8e7f441Yx9HD6ss= MIME-Version: 1.0 Received: by 10.103.7.31 with SMTP id k31mr3356636mui.48.1256113790909; Wed, 21 Oct 2009 01:29:50 -0700 (PDT) Date: Wed, 21 Oct 2009 10:29:50 +0200 Message-ID: <51eafbcb0910210129x60cf00eek4ee53df746e515a8@mail.gmail.com> From: Daniel Migault To: mif@ietf.org, ipsec@ietf.org, multipathtcp@ietf.org Content-Type: multipart/alternative; boundary=0016364174854dfc5004766dc8df Subject: [IPsec] IPsec multihoming and mobility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 08:29:51 -0000 --0016364174854dfc5004766dc8df Content-Type: text/plain; charset=ISO-8859-1 Hi folks, We are currently working on IPsec issues and multihoming. Here are our starting work with a presentation of scenarios and requirements we address, as well as the design of an extension to MOBIKE. Scenarios and Requirements : http://tools.ietf.org/html/draft-mglt-ipsec-mm-requirements-00 Protocol Design : http://tools.ietf.org/html/draft-mglt-ipsec-mm-mobikex-00 We are currently working implementing it, and looking on how other multihoming protocol can benefit from it. Feed backs and comments are really appreciated. Regards, Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --0016364174854dfc5004766dc8df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

We are currently working on IPsec issues and multihoming.= Here are our starting work with a presentation of scenarios and requiremen= ts we address, as well as the design of an extension to MOBIKE.

Scenarios and Requirements :
http://tools.ietf.org/html/draft-mglt-ipsec= -mm-requirements-00

Protocol Design :
http://tools.ietf.org/html/d= raft-mglt-ipsec-mm-mobikex-00

We are currently working implementing it, and looking on how other mult= ihoming protocol can benefit from it.

Feed backs=A0 and comments are= really appreciated.

Regards,

Daniel

<= br> --
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
--0016364174854dfc5004766dc8df-- From kivinen@iki.fi Wed Oct 21 05:37:39 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74653A6935 for ; Wed, 21 Oct 2009 05:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] 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 q-bZLJSP0sUg for ; Wed, 21 Oct 2009 05:37:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id F17563A686C for ; Wed, 21 Oct 2009 05:37:37 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9LCbeSC007733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Oct 2009 15:37:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9LCbcQ9017435; Wed, 21 Oct 2009 15:37:38 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19167.146.789858.880038@fireball.kivinen.iki.fi> Date: Wed, 21 Oct 2009 15:37:38 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <19127.28334.472030.873072@fireball.kivinen.iki.fi> <19128.47812.239136.479467@fireball.kivinen.iki.fi> <19139.30218.224175.430768@fireball.kivinen.iki.fi> <19151.13444.894473.883558@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 35 min X-Total-Time: 40 min Cc: IPsecme WG Subject: Re: [IPsec] #22 Simultaneous IKE SA rekey text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 12:37:39 -0000 David Wierbowski writes: > I'm not sure this makes RFC4718 incorrect. It just makes it incomplete. Ok, but that still means we need to find a way to fix that problem before we can use that solution in IKEv2bis. > > This solution might cause peers to stay in live lock state, causing > > the whole IKE SA to be unusable. I.e. host A starts IKE SA rekey and > > host B starts Create Child SA. Host B replies NO_PROPOSAL_CHOSEN to > > host A's IKE SA rekey, and Host A replies NO_ADDITIONAL_SAS to Host > > B's Create Child SA request. Both ends process replies, and notices > > they failed, thus both start again, causing both ends to be trying > > these operations as fast as they can. This situation will stay as it > > is unless something kicks hosts out of sync. > > > > Or returning NO_ADDITIONAL_SAS might cause other end to delete the > > whole IKE SA and start from scratch. > > I do not like that RFC 4718 used NO_PROPOSAL_CHOSEN as the indicator that > a rekey is being rejected because there are outstanding requests. To me > a new notify would have made sense. True, but as RFC4718 tried to be so it does not modify IKEv2, it could not define new error code. In IKEv2bis we can do this, so I think we should define new error code something like "TEMPORAL_FAILURE" which means there was some kind of temporal error (i.e. the problem will disappear without anybody changing policy) and other end should try again after short timeout. This error code could have uses for other places too. NO_PROPOSAL_CHOSEN has indication that the problem will NOT disappear unless someone changes something (i.e. proposals or policy or traffic selectors etc). So some implementations might (and should) use much larger timeout before trying again with exactly same parameters. > Given that RFC 4718 did use NO_PROPOSAL_CHOSEN it seems to me that > when HOST A is rekeying the IKE_SA it should assume the peer is busy > when it receives NO_PROPOSAL_CHOSEN and should continue to attempt > to periodically rekey the IKE SA again. Yes. > I do not agree that when Host B receives NO_ADDITIONAL_SAS that it > should retry the operation using the same IKE SA. True, if it follows the RFC4306, it should tear down the whole IKE SA, and start from beginning: ---------------------------------------------------------------------- 4. Conformance Requirements ... If the responder rejects the CREATE_CHILD_SA request with a NO_ADDITIONAL_SAS notification, the implementation MUST be capable of instead closing the old SA and creating a new one. ... ---------------------------------------------------------------------- This would be very unfortunate operation to be done in this case, as it would tear down the whole IKE SA, and all the IPsec SAs along with it. I do not think we can use NO_ADDITIONAL_SAS with the current definition anywhere else because of this. If on the other hand the host B which receives NO_ADDITIONAL_SAS does not tear down the whole IKE SA, but decides to keep the existing IKE SA up and running, there is no text anywhere saying it cannot start create child exchange again in future. Most likely it will do that whenever next packet requiring IPsec SA to be created is received, thus if there is constant stream of packets which would require protection it will trigger new create child exchange immediately. If we want that when host B receives NO_ADDITIONAL_SAS or when it rejects the IKE SA rekey with NO_PROPOSAL_CHOSEN (or with new TEMPORAL_FAILURE) then it needs to mark the IKE SA in some kind of on hold state, which means no new exchanges can be started on it, that needs to be explictly mentioned. > As such I do not think there is a live lock state. What should be > done is up to the implementation. An implementation could assume the > other end is in the process of rekeying or deleting the IKE SA and > delay taking any action or it could take immendiate action. If it > takes immediate action it would need to do so on a new IKE SA. How long should it delay those operations? Forever? Does that include DPD? If so how is the other end going to get rid of the IKE SA if Host A crashes and forgets everything about the IKE SA, as there will not be any more exchanges from Host A from that on etc. As the behavior of the nodes affects interoperability we should define what to do in this case. > > This is not in RFC4306, this is just one proposal given in RFC4718 > > which might be used, but as I noted above, it can cause live lock > > loop, thus it is not really acceptable. > > I think it is appropriate to add this to the new draft. If you are > concerned about the lock state then a warning should be added stating > that when you receive NO_ADDITIONAL_SAS that you should not attempt to > retry that operation on the same IKE SA, although that seems > self-evident. Yes, I would want to have some kind of text describing that, and also describing how long does this limit for retry take effect, and I assume that if the other end does not rekey or delete the IKE SA for certain timeout then the other node which received NO_ADDITIONAL_SAS should delete the IKE SA and start over. > I'm not convinced it is broken, I'm just convinced that if you > attempt to retry an operation on the same IKE SA that you received > NO_ADDITIONAL_SAS on that you can get into a lock state. To reduce that > concern we can come up with a new REKEYING_IKE_SA notification, but that's > likely to cause problems with old implementations, so better to stick with > what RFC 4718 proposed. Adding new error notifications cannot be problem for complient implementations as RFC4306 says: ---------------------------------------------------------------------- 3.10.1. Notify Message Types ... Types in the range 0 - 16383 are intended for reporting errors. An implementation receiving a Notify payload with one of these types that it does not recognize in a response MUST assume that the corresponding request has failed entirely. ... ---------------------------------------------------------------------- Thus every complient implementation MUSST assume that corresponding request has failed if they receive unrecognized error notify on response. Thus every implementation should handle new error messages just as we wanted, i.e. assume the IKE SA rekey failed. > > > The text above implies that regardless what you do you should be able > > to allow other end to start exchanges and process them. I.e. IKEv2 > > protocol tries to be specified in such way that both ends can start > > exchanges at any times and expect them to either fail or succeed and > > get reply back, but not stay in situation where you do not know, > > whether other end processed your request or not. > > > > If you delete the IKE SA immediately that will happen. > > You can never guarantee you are going to get a response back to a > request. I do not see what makes this situation any different. If I do not get response back (after dozen retransmissions over a period of at least several minutes) to a request on IKEv2 protocol that means the IKE SA is dead, and I silently discard it (i.e. assume other end is dead). Only case where you might not reply back is if the other end has deleted the IKE SA or if the network is broken. In both cases the correct fix is to remove the IKE SA and start over and it does not matter whether your request got other end or not. But that is not true with rekey case as some of the operations you do on the old IKE SA do affect the state of the new IKE SA, thus you need to know whether other end processed your request or not. > I understand that RFC 4718 is just one proposal, but it's one that I > expect some vendors tried to implement. I doubt there are many that are > currently delaying the deletion of the IKE SA. As our implementation does that, I guess all our customers implementations do it... :-) But I do not think that is an issue here. Simultaneous rekeys are not things that happen that often (if ever outside laboratory tests :-), so even if there are old implementations which do not do what IKEv2bis document will say, that shouldn't really matter. So I think we need to write some text that will work, and not be to concerned about what current implementations are now doing (I am sure all implementations out there are going to need minor modifications anyways when IKEv2bis comes out). > I'm not convinced yet that RFC 4718 is broken or at least that it cannot > be made to work. I think it can be made to work, I do consider it broken or at least underspecified as it is now, as it might lead live locks, but adding text to it might solve the problem (before I see the text and solution I cannot say for sure it will solve the problem). > > Implementation needs to still have the code that detects the > > simultaneous rekey, and other end might still use this delay, thus you > > need to be able to cope with the case where this happens. > > Implementations need to be able to handle both cases regardless > > whether we use SHOULD or MAY, only thing that is different is whether > > they allow other end finish exchanges or not. > > Agreed, but I still think delaying the deletion is at most a MAY. Ok. -- kivinen@iki.fi From sheila.frankel@nist.gov Wed Oct 21 06:28:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C68E3A6977 for ; Wed, 21 Oct 2009 06:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, 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 jyFKCFJi+voY for ; Wed, 21 Oct 2009 06:27:59 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 839AE3A68E0 for ; Wed, 21 Oct 2009 06:27:58 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9LDRxuI015982; Wed, 21 Oct 2009 09:27:59 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Wed, 21 Oct 2009 09:27:59 -0400 From: "Frankel, Sheila E." To: Tero Kivinen , "ipsec@ietf.org" Date: Wed, 21 Oct 2009 09:24:55 -0400 Thread-Topic: RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document Thread-Index: AcpRixH1URqZ8NBXS26V9gcTdg+kFgAxs8mB Message-ID: References: <19165.48619.530034.469960@fireball.kivinen.iki.fi> In-Reply-To: <19165.48619.530034.469960@fireball.kivinen.iki.fi> 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-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: "pasi.eronen@nokia.com" Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 13:28:00 -0000 I interpreted RFC 4307 slightly differently than Tero does, and I stand by = the wording of both the USGv6 Profile and the IPsec Roadmap. Although RFC 4= 307's domain is limited to IKEv2, it clearly specifies both those algorithm= s used within IKEv2 and also those algorithms that IKEv2 negotiates for use= by IPsec. That is why there are 2 separate lists of algorithms: Section 3.= 1.1 (Encrypted Payload Algorithms) specifies those algorithms that are used= BY IKEv2 in its Encrypted Payload. Sections 3.1.3 (IKEv2 Transform Type 1 = Algorithms) and 3.1.5 (IKEv2 Transform Type 3 Algorithms) lists those algor= ithms that IKEv2 should be able to negotiate for use within IPsec/child SAs= . One detail that supports this interpretation is the inclusion of NULL enc= ryption in section 3.1.3 - clearly, this is not appropriate in the IKE Encr= ypted Payload. If the applicability of Sections 3.1.3 and 3.1.5 is limited = to IKEv2 SAs, then there is no need for the more constrained list in Sectio= n 3.1.1, which clearly applies only to IKEv2's payloads. Sheila ________________________________________ From: Tero Kivinen [kivinen@iki.fi] Sent: Tuesday, October 20, 2009 9:40 AM To: ipsec@ietf.org Cc: Frankel, Sheila E.; pasi.eronen@nokia.com Subject: RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document I was reading the USGv6 profile, and it complained that RFC4307 and RFC4835 do not agree on status of NULL encryption. RFC4307 says MAY, and RFC4835 says MUST. As far as I have understood the RFC4835 defines algorithm requirements for Child SAs (ESP and AH), and RFC4307 defines algorithm requirements for IKEv2 SAs, i.e. when IKEv2 protects its own traffic. However while the roadmap document agrees on that ("[RFC4307] specifies the encryption and integrity-protection algorithms used by IKEv2 to protect its own traffic") it also final sentence which makes this not so clear: "It also specifies the encryption and integrity-protection algorithms that IKEv2 negotiates for use within IPsec." I.e. that last sentence would indicate that RFC4307 would also define encryption and integrity-protection algorithms for Child SAs. On the other hand it does not list IPsec-v2 nor IPsec-v3 on the requirements level so that would indicate it does not apply to IPsec, only to IKE. In the abstract RFC4307 does not clearly say whether it only covers IKEv2 traffic or if it also covers Child SA (IPsec, ESP/AH) traffic negotiated with IKEv2. But later in the section 3.1.1 it clearly says that "The IKEv2 Encryption Payload requires..." which indicates it only covers IKEv2 SA traffic not anything else. If this is true, then the requirement level for ENCR_NULL is clearly wrong, as RFC4306 says that ENCR_NULL MUST NOT be used when protecting IKEv2 SA traffic (section 5. Security Considerations). So I would suggest we remove the misleading last sentence from the draft-ietf-ipsecme-roadmap-04.txt section 5.1.2, and make an errata for RFC4307 saying that ENCR_NULL is "MUST NOT" instead of "MAY". Also the USGv6 document might also distinguish the fact that RFC4835 and RFC4307 cover different protocols, thus they does not need to agree on the requirement levels, and NULL encryption cannot really be required for IKEv2 as it would go against MUST NOT in RFC4306. -- kivinen@iki.fi From Michael.Tuexen@lurchi.franken.de Wed Oct 21 07:44:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C3E28C127; Wed, 21 Oct 2009 07:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.188 X-Spam-Level: ** X-Spam-Status: No, score=2.188 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 Ahv9OmtmFWSn; Wed, 21 Oct 2009 07:44:44 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id BA12E28C114; Wed, 21 Oct 2009 07:44:43 -0700 (PDT) Received: from [192.168.1.100] (p508FD714.dip.t-dialin.net [80.143.215.20]) by mail-n.franken.de (Postfix) with ESMTP id AECE91C0B4627; Wed, 21 Oct 2009 16:44:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <51eafbcb0910210129x60cf00eek4ee53df746e515a8@mail.gmail.com> Date: Wed, 21 Oct 2009 16:44:48 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <51eafbcb0910210129x60cf00eek4ee53df746e515a8@mail.gmail.com> To: Daniel Migault X-Mailer: Apple Mail (2.1076) X-Mailman-Approved-At: Wed, 21 Oct 2009 08:28:19 -0700 Cc: ipsec@ietf.org, multipathtcp@ietf.org, mif@ietf.org Subject: Re: [IPsec] [multipathtcp] IPsec multihoming and mobility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 14:44:45 -0000 Hi Daniel, have you looked at http://www.ietf.org/rfc/rfc3554.txt Best regards Michael On Oct 21, 2009, at 10:29 AM, Daniel Migault wrote: > Hi folks, > > We are currently working on IPsec issues and multihoming. Here are > our starting work with a presentation of scenarios and requirements > we address, as well as the design of an extension to MOBIKE. > > Scenarios and Requirements : > http://tools.ietf.org/html/draft-mglt-ipsec-mm-requirements-00 > > Protocol Design : > http://tools.ietf.org/html/draft-mglt-ipsec-mm-mobikex-00 > > We are currently working implementing it, and looking on how other > multihoming protocol can benefit from it. > > Feed backs and comments are really appreciated. > > Regards, > > Daniel > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From root@core3.amsl.com Wed Oct 21 11:00:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B05073A694A; Wed, 21 Oct 2009 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091021180001.B05073A694A@core3.amsl.com> Date: Wed, 21 Oct 2009 11:00:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-resumption-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 18:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IKEv2 Session Resumption Author(s) : Y. Sheffer, H. Tschofenig Filename : draft-ietf-ipsecme-ikev2-resumption-09.txt Pages : 29 Date : 2009-10-21 The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In order to avoid the need to re-run the key exchange protocol from scratch it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re- authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-resumption-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-21105905.I-D@ietf.org> --NextPart-- From paul.hoffman@vpnc.org Wed Oct 21 12:50:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D18B3A694C for ; Wed, 21 Oct 2009 12:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.648 X-Spam-Level: X-Spam-Status: No, score=-4.648 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, 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 bqN42jnZC0yU for ; Wed, 21 Oct 2009 12:49:59 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D80073A693E for ; Wed, 21 Oct 2009 12:49:59 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9LJo6Z7044157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Oct 2009 12:50:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <19165.48619.530034.469960@fireball.kivinen.iki.fi> Date: Wed, 21 Oct 2009 12:50:05 -0700 To: "Frankel, Sheila E." , Tero Kivinen , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 19:50:00 -0000 Looking through the archives for the IPsec WG (the predecessor to this one), Tero's interpretation is probably closer to what happened than Sheila's. It is unfortunately that both Sheila and Tero use the word "clearly" when talking about RFC 4307; the archive would strongly indicate that it is inappropriate to use that word when discussion RFC 4307. We need to remember that the flight of documents coming out of the original WG included both RFC 4305 and RFC 4307. There was some sloppy cross-over of requirements due to a poor split late in the process. However, the WG seems to have wanted to have two different sets of requirements, one for IKEv2 crypto, and one for AH/ESP crypto. This is what makes me think that Tero's interpretation is closer to what happened, regardless of what words were (possibly inappropriately) left in RFC 4307 at the point that the WG became exhausted. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Wed Oct 21 13:06:14 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7EE73A690C for ; Wed, 21 Oct 2009 13:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.384 X-Spam-Level: X-Spam-Status: No, score=-5.384 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 zDcF58K8ntsx for ; Wed, 21 Oct 2009 13:06:14 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E79963A68D0 for ; Wed, 21 Oct 2009 13:06:13 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9LK1IR6044730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Oct 2009 13:01:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <349076FF-487D-4B6C-91EB-1E845B2303F6@checkpoint.com> References: <349076FF-487D-4B6C-91EB-1E845B2303F6@checkpoint.com> Date: Wed, 21 Oct 2009 13:01:17 -0700 To: Yoav Nir From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] Closing the IKEv2bis open issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:06:14 -0000 At 9:46 AM +0200 10/21/09, Yoav Nir wrote: >Content-Language: en-US >Content-Type: multipart/signed; micalg=sha1; > boundary="Apple-Mail-15-778597419"; protocol="application/pkcs7-signature" > >A few lines above this section it already says "If the responder's policy allows it to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the initiator's first choices." > >So there is a MUST requirement to select the initiator's first choice (if possible), so I don't think the SHOULD and MAY are appropriate here. The way I read this section, it only clarifies what to do if the initiator traffic selector (first or not) is too broad. In that case, we shouldn't mention the initiator's choices. Yeeps, good catch. That will teach me not to read above and below far enough. Given this, maybe we need to close out this issue with no change, given the disagreement for other additions to the text. --Paul Hoffman, Director --VPN Consortium From sheila.frankel@nist.gov Wed Oct 21 13:08:39 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AA93A690C for ; Wed, 21 Oct 2009 13:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 cvsWxXSZqAZ8 for ; Wed, 21 Oct 2009 13:08:39 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id B4EFC3A68D0 for ; Wed, 21 Oct 2009 13:08:38 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9LK8BpP024542; Wed, 21 Oct 2009 16:08:13 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Wed, 21 Oct 2009 16:08:12 -0400 From: "Frankel, Sheila E." To: Paul Hoffman , Tero Kivinen , "ipsec@ietf.org" Date: Wed, 21 Oct 2009 16:08:10 -0400 Thread-Topic: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document Thread-Index: AcpSh9E1R5spaP+uSDemfdD8Gxx7nAAAZNyO Message-ID: References: <19165.48619.530034.469960@fireball.kivinen.iki.fi> , In-Reply-To: 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-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:08:39 -0000 If that's the case, we'll remove the offending statements in the roadmap. Just 2 more questions: even if this was a sloppy document, why is there a s= eparate section for IKE Encrypted Payload algorithms, that contains a subse= t of the Transform Type 1 (encryption) algorithms? Also, is sloppiness enou= gh to account for both NULL encryption and AES-CTR being specified for IKEv= 2 - and noone from the WG noticing either? Sheila ________________________________________ From: Paul Hoffman [paul.hoffman@vpnc.org] Sent: Wednesday, October 21, 2009 3:50 PM To: Frankel, Sheila E.; Tero Kivinen; ipsec@ietf.org Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document Looking through the archives for the IPsec WG (the predecessor to this one)= , Tero's interpretation is probably closer to what happened than Sheila's. = It is unfortunately that both Sheila and Tero use the word "clearly" when t= alking about RFC 4307; the archive would strongly indicate that it is inapp= ropriate to use that word when discussion RFC 4307. We need to remember that the flight of documents coming out of the original= WG included both RFC 4305 and RFC 4307. There was some sloppy cross-over o= f requirements due to a poor split late in the process. However, the WG see= ms to have wanted to have two different sets of requirements, one for IKEv2= crypto, and one for AH/ESP crypto. This is what makes me think that Tero's= interpretation is closer to what happened, regardless of what words were (= possibly inappropriately) left in RFC 4307 at the point that the WG became = exhausted. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Wed Oct 21 13:27:30 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC09428C14B for ; Wed, 21 Oct 2009 13:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.439 X-Spam-Level: X-Spam-Status: No, score=-5.439 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 i6YUsHXcIlaq for ; Wed, 21 Oct 2009 13:27:30 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0C26328C141 for ; Wed, 21 Oct 2009 13:27:30 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9LKRaEE046123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Oct 2009 13:27:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <19165.48619.530034.469960@fireball.kivinen.iki.fi> ,

Date: Wed, 21 Oct 2009 13:27:35 -0700 To: "Frankel, Sheila E." , Tero Kivinen , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:27:30 -0000 At 4:08 PM -0400 10/21/09, Frankel, Sheila E. wrote: >If that's the case, we'll remove the offending statements in the roadmap. Assuming others remember it as I do (well, after looking at the archive), that would be great. >Just 2 more questions: even if this was a sloppy document, why is there a separate section for IKE Encrypted Payload algorithms, that contains a subset of the Transform Type 1 (encryption) algorithms? Because the split happened late in the process when many of us were quite burned out; we didn't review carefully. > Also, is sloppiness enough to account for both NULL encryption and AES-CTR being specified for IKEv2 - and noone from the WG noticing either? I think so, unfortunately. --Paul Hoffman, Director --VPN Consortium From sean.s.shen@gmail.com Wed Oct 21 18:22:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BFDD3A68D6 for ; Wed, 21 Oct 2009 18:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599, HTML_MESSAGE=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 swhfBPFK9VFK for ; Wed, 21 Oct 2009 18:22:26 -0700 (PDT) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by core3.amsl.com (Postfix) with ESMTP id 1446A3A68D3 for ; Wed, 21 Oct 2009 18:22:26 -0700 (PDT) Received: by pxi13 with SMTP id 13so5793162pxi.32 for ; Wed, 21 Oct 2009 18:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cU7D/EWKew0mE7eTomM3EDIIGEU9ETsedXGoxpu3cSI=; b=QGHfs0/4lnK2jSkhGCIYDDlLg5Rr4F6y6BrmFs1pKXbR0oNoKyVKcrbK23PByz0mTY +LfsrjUHnwNdbEVt1mmct4CP1RFAMSSV9+4sUcOq3zd1uyHEN/4aF7pvxoOtOf+ms1Cl HgsaIXP9/6KW0vrYoX/j2dpHKp+LhpylqFTTc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HVsroTyMa11AFEP7Ffu2WGWJSVhVtfxXeg5RjsXD6W061AjWZrh+PmN4ytNs46EY/1 i+b/KRL2oM5xRbQcC3NDEqXhGSmpTKeIHo/y3r54b7CYEBkaaE+UeuBllAXc1M7P8vRh Pz95pwNoIpat8f4ZHpRHZuw82x8LJWOmONlwc= MIME-Version: 1.0 Received: by 10.115.39.8 with SMTP id r8mr9306069waj.104.1256174551658; Wed, 21 Oct 2009 18:22:31 -0700 (PDT) In-Reply-To: <19165.32194.275245.431639@fireball.kivinen.iki.fi> References: <200910131509.RAA22549@TR-Sys.de> <80b5a9190910190108t46e6c862s9f8c48895e5b3851@mail.gmail.com> <19165.32194.275245.431639@fireball.kivinen.iki.fi> Date: Thu, 22 Oct 2009 09:22:31 +0800 Message-ID: <80b5a9190910211822j407a58fbo6872025d4f488bc2@mail.gmail.com> From: Shen Sean To: Tero Kivinen Content-Type: multipart/alternative; boundary=0016e64c2652ed70ce04767bed29 Cc: ipsec@ietf.org, =?ISO-8859-1?Q?Alfred_H=CEnes?= , draft-ietf-ipsecme-aes-ctr-ikev2@tools.ietf.org Subject: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 01:22:27 -0000 --0016e64c2652ed70ce04767bed29 Content-Type: text/plain; charset=ISO-8859-1 2009/10/20 Tero Kivinen > Shen Sean writes: > > (3) Section 2 (and ff.) > ... > > The number of (internal) rounds is totally irrelevant for the > > application of the AES. Any attempt to mangle with this 'parameter' > > would raise significant security concerns and conformance issues. > > I strongly request to elide all mention of "rounds" from the draft. > > I agree on that. In most cases the AES is implemented as part of > cryptographic library or hardware, and for those you usually just > indicate the key length to be used and that automatically selects the > number of rounds. > > > [Sean] The intention of such a document is to give what a IKEv2 product > > MUST/SHOULD/MAY provide. A user may not have "choices" of rounds or size, > > but a vendor need to know what to provide. > > Usually even the vendor does not have choice, or even possibility to > change the number of rounds, as that is hidden inside cryptographic > library. [Sean] I have no doubt that most users or vendors won't bother to choose or change what's already in crypto lib. But, a standard related document is responsible to clearly state what are necessary for a product, in this case, the basic characteristics of AES-CTR, even though some of these seems obvious. I remmeber the very early version of this document does not include rounds stuff, but eventually we added it based on reviewers' comments and requests. > > > (15) Section 7 > > > > I suggest to more clearly indicate what this draft is expecting IANA > > to do: adding a reference to this memo for an existing registration. > > > > | IANA has assigned 13 as the transform ID for ENCR_AES_CTR encryption > > | with an explicit IV. This ID is to be used during IKE_SA > > | negotiation. > > --- > > | Per [RFC3686], IANA has assigned 13 as the "IKEv2 Encryption > > | Transform ID" to the name "ENCR_AES_CTR" for AES-CTR encryption with > > | an explicit IV, in the IANA "Internet Key Exchange Version 2 (IKEv2) > > | Parameters" registry. This document specifies how to use this > > | transform during IKE_SA negotiations. Hence IANA should add to that > > | entry a reference to this RFC. > > [Sean] It's a good point, but for IANA's reference to this document, I > > assume iana will updated their reference (following some rocedure?) when > > this document is processed. Let me know if we have to request it in the > > draft. > > I would not count on that. For example IANA didn't update the > ENCR_AES-CCM_* or AES_GCM with a * octect ICV references for the > RFC5282 automatically, so better add text there. [Sean] The last time I check iana's ikev2 parameters, the parameters was "last updated 2009-09-21". Seems they missed what you mentioned above. So I will add a request for reference. Best, Sean --0016e64c2652ed70ce04767bed29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/10/20 Tero Kivinen <kivinen@iki.fi>
Shen Sean writes:
> (3) =A0Section 2 (and ff.)
...
> The number of (internal) rounds is totally irrelevant for the
= > application of the AES. =A0Any attempt to mangle with this 'parame= ter'
> would raise significant security concerns and conformance = issues.
> I strongly request to elide all mention of "rounds" from the= draft.

I agree on that. In most cases the AES is implemented = as part of
cryptographic library or hardware, and for those you usually = just
indicate the key length to be used and that automatically selects the
nu= mber of rounds.

> [Sean] The intention of such a document is to give what a IKE= v2 product
> MUST/SHOULD/MAY provide. A user may not have "choic= es" of rounds or size,
> but a vendor need to know what to provi= de.

Usually even the vendor does not have choice, or even possibility= to
change the number of rounds, as that is hidden inside cryptographic<= br>library.
[Sean] I have no doubt that most users or=A0vendors=A0won't bother= to choose or change=A0what's already in crypto lib.=A0But,=A0a=A0stand= ard related document=A0is responsible to clearly state what are necessary f= or a product, in this case, the basic characteristics of AES-CTR, even thou= gh some of these seems obvious. I remmeber the very early version of this d= ocument does not include rounds stuff, but eventually we=A0added it based o= n reviewers' comments and requests.=A0=A0=A0
=A0

> (15) =A0Section 7
>
> I suggest to more clearly i= ndicate what this draft is expecting IANA
> to do: adding a reference= to this memo for an existing registration.
>
> | =A0IANA has a= ssigned 13 as the transform ID for ENCR_AES_CTR encryption
> | =A0with an explicit IV. =A0This ID is to be used during IKE_SA
&g= t; | =A0negotiation.
> ---
> | =A0Per [RFC3686], IANA has assig= ned 13 as the "IKEv2 Encryption
> | =A0Transform ID" to the= name "ENCR_AES_CTR" for AES-CTR encryption with
> | =A0an explicit IV, in the IANA "Internet Key Exchange Version 2= (IKEv2)
> | =A0Parameters" registry. =A0This document specifies= how to use this
> | =A0transform during IKE_SA negotiations. =A0Henc= e IANA should add to that
> | =A0entry a reference to this RFC.
> [Sean] It's a good poi= nt, but for IANA's reference to this document, I
> assume iana wi= ll updated their reference (following some rocedure?) when
> this doc= ument is processed. Let me know if we have to request it in the
> draft.

I would not count on that. For example IANA didn&#= 39;t update the
ENCR_AES-CCM_* or AES_GCM with a * octect ICV references= for the
RFC5282 automatically, so better add text there.
[Sean] The last time I check iana's ikev2 parameters, the paramete= rs was "last updated 2009-09-21". Seems they missed what you ment= ioned above.=A0So I will add a request for=A0reference.

Best,
=A0
Sean
--0016e64c2652ed70ce04767bed29-- From Paul_Koning@Dell.com Wed Oct 21 18:33:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993CF3A68DA for ; Wed, 21 Oct 2009 18:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 BngkA7ehWG7j for ; Wed, 21 Oct 2009 18:33:54 -0700 (PDT) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id 041483A6876 for ; Wed, 21 Oct 2009 18:33:53 -0700 (PDT) X-Loopcount0: from 12.110.134.31 X-IronPort-AV: E=Sophos;i="4.44,601,1249275600"; d="scan'208,217";a="417624964" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 21 Oct 2009 20:34:02 -0500 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_01CA52B7.BB0FB8D8" Date: Wed, 21 Oct 2009 21:33:59 -0400 Message-ID: In-Reply-To: <80b5a9190910211822j407a58fbo6872025d4f488bc2@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 thread-index: AcpStigGY2GCvqRsQTCvqaVKCK7vUgAAO4OQ References: <200910131509.RAA22549@TR-Sys.de><80b5a9190910190108t46e6c862s9f8c48895e5b3851@mail.gmail.com><19165.32194.275245.431639@fireball.kivinen.iki.fi> <80b5a9190910211822j407a58fbo6872025d4f488bc2@mail.gmail.com> From: "Paul Koning" To: "Shen Sean" , "Tero Kivinen" Cc: ipsec@ietf.org, =?iso-8859-1?Q?Alfred_H=CEnes?= , draft-ietf-ipsecme-aes-ctr-ikev2@tools.ietf.org Subject: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 01:33:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA52B7.BB0FB8D8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AES is an algorithm with one parameter: the key length. Based on that = parameter various things change inside the algorithm. It so happens = that AES has rounds, and the number of rounds is a function of the key = length. But as Tero says, that's irrelevant to users of AES. Any = mention of rounds and other internal stuff belongs in exactly one place, = the AES specification. It does NOT belong in any specs that are merely = users of AES - such as the AES-CTR spec. It isn't a characteristic of = aes-ctr. =20 Are you saying that people were arguing otherwise, that rounds need to = be mentioned in the aes-ctr spec? I strongly disagree; I can't imagine = any reason why that would be a good idea. =20 paul =20 From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Shen Sean Sent: Wednesday, October 21, 2009 9:23 PM To: Tero Kivinen Cc: ipsec@ietf.org; Alfred H=CEnes; = draft-ietf-ipsecme-aes-ctr-ikev2@tools.ietf.org Subject: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 ... [Sean] I have no doubt that most users or vendors won't bother to = choose or change what's already in crypto lib. But, a standard related = document is responsible to clearly state what are necessary for a = product, in this case, the basic characteristics of AES-CTR, even though = some of these seems obvious. I remmeber the very early version of this = document does not include rounds stuff, but eventually we added it based = on reviewers' comments and requests. =20 =20 =20 ------_=_NextPart_001_01CA52B7.BB0FB8D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

AES is an algorithm with one parameter: the key = length.=A0 Based on that parameter various things change inside the algorithm.=A0 It so = happens that AES has rounds, and the number of rounds is a function of the key = length.=A0 But as Tero says, that’s irrelevant to users of AES.=A0 Any = mention of rounds and other internal stuff belongs in exactly one place, the AES specification.=A0 It does NOT belong in any specs that are merely users = of AES – such as the AES-CTR spec.=A0 It isn’t a characteristic of = aes-ctr.

 

Are you saying that people were arguing otherwise, that = rounds need to be mentioned in the aes-ctr spec?=A0 I strongly disagree; I = can’t imagine any reason why that would be a good idea.

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = paul

 

From:= = ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Shen Sean
Sent: Wednesday, October 21, 2009 9:23 PM
To: Tero Kivinen
Cc: ipsec@ietf.org; Alfred H=CEnes; draft-ietf-ipsecme-aes-ctr-ikev2@tools.ietf.org
Subject: Re: [IPsec] review of = draft-ietf-ipsecme-aes-ctr-ikev2-02

…

=A0[Sean] I have no doubt that most users or vendors won't bother to choose or change what's = already in crypto lib. But, a standard related document is = responsible to clearly state what are necessary for a product, in this case, the = basic characteristics of AES-CTR, even though some of these seems obvious. I = remmeber the very early version of this document does not include rounds stuff, = but eventually we added it based on reviewers' comments and requests.   

 

 

------_=_NextPart_001_01CA52B7.BB0FB8D8-- From kivinen@iki.fi Thu Oct 22 01:38:53 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052623A6828 for ; Thu, 22 Oct 2009 01:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] 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 VEXwXNg1QDI3 for ; Thu, 22 Oct 2009 01:38:52 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E062D3A63EC for ; Thu, 22 Oct 2009 01:38:51 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9M8ctA1001844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Oct 2009 11:38:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9M8csoD000488; Thu, 22 Oct 2009 11:38:54 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19168.6686.368531.842814@fireball.kivinen.iki.fi> Date: Thu, 22 Oct 2009 11:38:54 +0300 From: Tero Kivinen To: "Frankel, Sheila E." In-Reply-To: References: <19165.48619.530034.469960@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 31 min Cc: "ipsec@ietf.org" , "pasi.eronen@nokia.com" Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 08:38:53 -0000 Frankel, Sheila E. writes: > I interpreted RFC 4307 slightly differently than Tero does, and I > stand by the wording of both the USGv6 Profile and the IPsec > Roadmap. Although RFC 4307's domain is limited to IKEv2, it clearly > specifies both those algorithms used within IKEv2 and also those > algorithms that IKEv2 negotiates for use by IPsec. That is why there > are 2 separate lists of algorithms: Section 3.1.1 (Encrypted Payload > Algorithms) specifies those algorithms that are used BY IKEv2 in its > Encrypted Payload. Sections 3.1.3 (IKEv2 Transform Type 1 > Algorithms) and 3.1.5 (IKEv2 Transform Type 3 Algorithms) lists > those algorithms that IKEv2 should be able to negotiate for use > within IPsec/child SAs. One detail that supports this interpretation > is the inclusion of NULL encryption in section 3.1.3 - clearly, this > is not appropriate in the IKE Encrypted Payload. If the > applicability of Sections 3.1.3 and 3.1.5 is limited to IKEv2 SAs, > then there is no need for the more constrained list in Section > 3.1.1, which clearly applies only to IKEv2's payloads. Hmm... Yes, it could be interpreted so also, but what is the relationship between RFC4307 and RFC4305/4835 then. Would RFC4305/RFC4835 then cover only manual keying and IKEv1? I always assumed that RFC4307 talks about IKEv2 SAs and RFC4305/4835 talks about ESP and AH (i.e. IPsec SAs aka Child SAs). One reason I think this is the correct interpretation is that RFC4307 section 3.1.4 lists Transform Type 2 Algorithms (Pseudor-random functions, PRFs), and those are applicable ONLY to IKEv2. IPsec SAs/Child SAs/ESP/AH cannot have PRFs. Also section 3.1.5 does not give any status for NONE authentication (as it cannot be used for IKEv2 SAs), but for example RFC4305/RFC4835 both give requirement for it (MUST / MAY). -- kivinen@iki.fi From kivinen@iki.fi Thu Oct 22 01:48:09 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1D03A67FD for ; Thu, 22 Oct 2009 01:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] 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 AdHaPKcne1+I for ; Thu, 22 Oct 2009 01:48:08 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7063B3A63EC for ; Thu, 22 Oct 2009 01:48:08 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9M8mEQo024183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Oct 2009 11:48:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9M8mD56013999; Thu, 22 Oct 2009 11:48:13 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19168.7245.897573.768826@fireball.kivinen.iki.fi> Date: Thu, 22 Oct 2009 11:48:13 +0300 From: Tero Kivinen To: Shen Sean In-Reply-To: <80b5a9190910211822j407a58fbo6872025d4f488bc2@mail.gmail.com> References: <200910131509.RAA22549@TR-Sys.de> <80b5a9190910190108t46e6c862s9f8c48895e5b3851@mail.gmail.com> <19165.32194.275245.431639@fireball.kivinen.iki.fi> <80b5a9190910211822j407a58fbo6872025d4f488bc2@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: ipsec@ietf.org, =?ISO-8859-1?Q?Alfred_H=CEnes?= , draft-ietf-ipsecme-aes-ctr-ikev2@tools.ietf.org Subject: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 08:48:09 -0000 Shen Sean writes: > > I would not count on that. For example IANA didn't update the > > ENCR_AES-CCM_* or AES_GCM with a * octect ICV references for the > > RFC5282 automatically, so better add text there. > > [Sean] The last time I check iana's ikev2 parameters, the parameters was > "last updated 2009-09-21". Seems they missed what you mentioned above. So I > will add a request for reference. I am in the process of doing that already, and splitting the ESP and IKEv2 references also (as in some cases the ESP reference is to different document than the IKEv2 reference). So no need to add request now, I will take care of that. -- kivinen@iki.fi From sean.s.shen@gmail.com Fri Oct 23 04:12:18 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1804D3A68A7 for ; Fri, 23 Oct 2009 04:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, HTML_MESSAGE=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 PBfEoP02RSQk for ; Fri, 23 Oct 2009 04:12:17 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id EA83A3A68A5 for ; Fri, 23 Oct 2009 04:12:16 -0700 (PDT) Received: by pzk6 with SMTP id 6so618207pzk.29 for ; Fri, 23 Oct 2009 04:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QZG65mYK3Bj23K3SjYZ//PMhlUjzwcfDWehuXQZR7Ns=; b=hqyAjse3sAaQ7XJgSJ0doYWkDSKWcJ0tBH5deaw6NughjBchINlgRnlMmDIFOYLxj+ QonthRhucEvm7kbUIE8SMY+aO7jEe9OMPvMTrEWnNRh5VdjVSQgLwoNh00MGjzPMGsq7 XJz/DyxnSvZat675BLQALpLZARsbBPAumEJBM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ehlxp8bjJwVUzobIGuYzKQ6JD4VUzbFfIWQ3YcsUAx2Yl2kgjkkHFH7VHEwcJjC1lU qjgzeSb0DUxM6AsA5DFFouHBafvujcMGqAIgWAEzMbmiMNedTebCWeUO4V+o6nAScNV3 0dYBhB6YqB2Y5pOZb5BOaT2qTMJaBvhFuvPKQ= MIME-Version: 1.0 Received: by 10.115.65.11 with SMTP id s11mr16059662wak.170.1256296342442; Fri, 23 Oct 2009 04:12:22 -0700 (PDT) In-Reply-To: References: <200910131509.RAA22549@TR-Sys.de> <80b5a9190910190108t46e6c862s9f8c48895e5b3851@mail.gmail.com> <19165.32194.275245.431639@fireball.kivinen.iki.fi> <80b5a9190910211822j407a58fbo6872025d4f488bc2@mail.gmail.com> Date: Fri, 23 Oct 2009 19:12:22 +0800 Message-ID: <80b5a9190910230412of646dadx991f3f9cc19b8e84@mail.gmail.com> From: Sean Shen To: Paul Koning Content-Type: multipart/alternative; boundary=0016e64c24a0395362047698493d Cc: ipsec@ietf.org, =?ISO-8859-1?Q?Alfred_H=CEnes?= , Tero Kivinen , draft-ietf-ipsecme-aes-ctr-ikev2@tools.ietf.org Subject: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 11:12:18 -0000 --0016e64c24a0395362047698493d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Section 2.2 says that "AES MUST use different rounds for each of the key sizes: ...". The draft is not trying to say that IKEv2 requires 10/12/14 rounds for 128/192/256 key lengths. The draft is not trying to say that AES-CTR requires 10/12/14 rounds for 128/192/256 key lengths. Sean 2009/10/22 Paul Koning > AES is an algorithm with one parameter: the key length. Based on that > parameter various things change inside the algorithm. It so happens that > AES has rounds, and the number of rounds is a function of the key length. > But as Tero says, that=92s irrelevant to users of AES. Any mention of ro= unds > and other internal stuff belongs in exactly one place, the AES > specification. It does NOT belong in any specs that are merely users of = AES > =96 such as the AES-CTR spec. It isn=92t a characteristic of aes-ctr. > > > > Are you saying that people were arguing otherwise, that rounds need to be > mentioned in the aes-ctr spec? I strongly disagree; I can=92t imagine an= y > reason why that would be a good idea. > > > > paul > > > > *From:* ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] *On Behalf > Of *Shen Sean > *Sent:* Wednesday, October 21, 2009 9:23 PM > *To:* Tero Kivinen > *Cc:* ipsec@ietf.org; Alfred H=CEnes; > draft-ietf-ipsecme-aes-ctr-ikev2@tools.ietf.org > *Subject:* Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 > > =85 > > [Sean] I have no doubt that most users or vendors won't bother to choose > or change what's already in crypto lib. But, a standard related document = is > responsible to clearly state what are necessary for a product, in this ca= se, > the basic characteristics of AES-CTR, even though some of these seems > obvious. I remmeber the very early version of this document does not incl= ude > rounds stuff, but eventually we added it based on reviewers' comments and > requests. > > > > > --0016e64c24a0395362047698493d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Section 2.2 says that "AES MUST use different rounds for each of = the key sizes: ...".
The draft=A0is not trying to say=A0that=A0IKEv2 requires=A010/12/14 ro= unds for 128/192/256 key lengths.=A0The draft is not trying to say that AES= -CTR requires 10/12/14 rounds for 128/192/256 key lengths.
=A0
Sean

=A0
2009/10/22 Paul Koning <Paul_Koning@dell.com= >

AES = is an algorithm with one parameter: the key length.=A0 Based on that parame= ter various things change inside the algorithm.=A0 It so happens that AES h= as rounds, and the number of rounds is a function of the key length.=A0 But= as Tero says, that=92s irrelevant to users of AES.=A0 Any mention of round= s and other internal stuff belongs in exactly one place, the AES specificat= ion.=A0 It does NOT belong in any specs that are merely users of AES =96 su= ch as the AES-CTR spec.=A0 It isn=92t a characteristic of aes-ctr.

=A0<= /span>

Are = you saying that people were arguing otherwise, that rounds need to be menti= oned in the aes-ctr spec?=A0 I strongly disagree; I can=92t imagine any rea= son why that would be a good idea.

=A0<= /span>

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 paul

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Beha= lf Of Shen Sean
Sent: Wednesday, October 21, 2009 9:23 PM
To: Tero Kivinen=
Cc: ipsec@ie= tf.org; Alfred H=CEnes; draft-ietf-ipsecme-aes-ctr-ikev2@tool= s.ietf.org
Subject: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02

=85

=A0[Sean] I have no doubt that most users or=A0vendo= rs=A0won't bother to choose or change=A0what's already in crypto li= b.=A0But,=A0a=A0standard related document=A0is responsible to clearly state= what are necessary for a product, in this case, the basic characteristics = of AES-CTR, even though some of these seems obvious. I remmeber the very ea= rly version of this document does not include rounds stuff, but eventually = we=A0added it based on reviewers' comments and requests.=A0=A0=A0

=A0

=A0


--0016e64c24a0395362047698493d-- From A.Hoenes@TR-Sys.de Fri Oct 23 04:44:54 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14A363A6882 for ; Fri, 23 Oct 2009 04:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.17 X-Spam-Level: ** X-Spam-Status: No, score=2.17 tagged_above=-999 required=5 tests=[AWL=0.919, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 hFDzxueQJsdP for ; Fri, 23 Oct 2009 04:44:53 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 79C8B3A6843 for ; Fri, 23 Oct 2009 04:44:47 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA295128237; Fri, 23 Oct 2009 13:43:57 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA18006; Fri, 23 Oct 2009 13:43:47 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910231143.NAA18006@TR-Sys.de> To: sean.s.shen@gmail.com Date: Fri, 23 Oct 2009 13:43:47 +0200 (MESZ) In-Reply-To: <80b5a9190910230412of646dadx991f3f9cc19b8e84@mail.gmail.com> from Sean Shen at Oct "23, " 2009 "07:12:22" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, Paul_Koning@dell.com, draft-ietf-ipsecme-aes-ctr-ikev2@cabernet.tools.IETF.ORG, kivinen@iki.fi Subject: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 11:44:54 -0000 Sean Shen wrote: > Section 2.2 says that "AES MUST use different rounds for each of the > key sizes: ...". > The draft is not trying to say that IKEv2 requires 10/12/14 rounds for > 128/192/256 key lengths. The draft is not trying to say that AES-CTR > requires 10/12/14 rounds for 128/192/256 key lengths. > > Sean > > ... The "MUST" still makes the difference! That is normative and does NOT belong into this draft. Although that would still be regarded out of scope of your draft, I would be more willing to accept an _informative_ statement like: "Note: AES uses different rounds for each of the key sizes: ...". ^^^^^^ ^^^^ But the most important topic remains: The draft is ill-advised in pretending that the interface of AES -- or, btw, *any* currently sensibly used block cipher primitive of reasonable strength -- had an _external_ parameter "number of rounds" that upper protocol (sub-)layers would need to have to deal with. Otherwise, the "IKEv2 Transform Attribute Types" would have to include an entry for "number of rounds", which it doesn't, and you also do not aim at establishing such entry. For the sake of terminological precision and consistency with existing specifications (and such to avoid confusion), a draft about the usage of a cryptographic primitive in IPsec/IKE should only denote as "algorithm parameter" what indeed has to be expressed as such in SA crypto-algorithm negotiations. Kind regards, Alfred H=CEnes. -- = +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From sean.s.shen@gmail.com Fri Oct 23 05:38:38 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE303A6821 for ; Fri, 23 Oct 2009 05:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 8MH-db1qyxiM for ; Fri, 23 Oct 2009 05:38:37 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 7C59E3A62C1 for ; Fri, 23 Oct 2009 05:38:37 -0700 (PDT) Received: by pzk6 with SMTP id 6so663975pzk.29 for ; Fri, 23 Oct 2009 05:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rZUcUnpu98rVHDhtG+Ry1+f0vaRX6XFmHSbTPwmb1fs=; b=wvsUK9JrRzTqs0STDEL2j7Lf2mnj0kV8UdtyPcN+JzwJ07IMNtIzXwHPN1WzgeLwEz ki6fBbqyYMCi7Ds+JLcpnL3rAtCtLycJGKTH5evc2ISq+xIINmauoD8i6PLiWmlaY6p/ Hg33+pN4WquFGmqZkNVpC0bMPi3zv7ZLIeIFY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mI6G+SeDYgiPF72eRHU0evZvtTQ8/1Ndb5r4RGUbPmD/tM4wjFwD2IzU2aTjF41VOu JbAvxLoE5sdZ1JqJr52w74WMX6vkzEmntyG9CQUtaIfV5s2B9W6FzdJGoOvVGMxJ95t3 OQVMGy+3aAdIHReAidPGHb4h7hlMQGO2BVDbQ= MIME-Version: 1.0 Received: by 10.115.99.4 with SMTP id b4mr16077921wam.88.1256301525568; Fri, 23 Oct 2009 05:38:45 -0700 (PDT) In-Reply-To: <200910231143.NAA18006@TR-Sys.de> References: <80b5a9190910230412of646dadx991f3f9cc19b8e84@mail.gmail.com> <200910231143.NAA18006@TR-Sys.de> Date: Fri, 23 Oct 2009 20:38:45 +0800 Message-ID: <80b5a9190910230538h2a46e6e8i98235ea3529d45de@mail.gmail.com> From: Sean Shen To: =?ISO-8859-1?Q?Alfred_H=CEnes?= Content-Type: multipart/alternative; boundary=0016e648f0ae298e130476997eb9 Cc: ipsec@ietf.org, Paul_Koning@dell.com, draft-ietf-ipsecme-aes-ctr-ikev2@cabernet.tools.ietf.org, kivinen@iki.fi Subject: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 12:38:38 -0000 --0016e648f0ae298e130476997eb9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/10/23 Alfred H=CEnes > Sean Shen wrote: > > > Section 2.2 says that "AES MUST use different rounds for each of the > > key sizes: ...". > > The draft is not trying to say that IKEv2 requires 10/12/14 rounds for > > 128/192/256 key lengths. The draft is not trying to say that AES-CTR > > requires 10/12/14 rounds for 128/192/256 key lengths. > > > > Sean > > > > ... > > The "MUST" still makes the difference! That is normative and does > NOT belong into this draft. Although that would still be regarded > out of scope of your draft, I would be more willing to accept an > _informative_ statement like: > > "Note: AES uses different rounds for each of the key sizes: ...". > ^^^^^^ ^^^^ [Sean] Correct, "MUST" is defined in key words conventions and should not b= e used here. I will dropt it. > But the most important topic remains: The draft is ill-advised in > pretending that the interface of AES -- or, btw, *any* currently > sensibly used block cipher primitive of reasonable strength -- > had an _external_ parameter "number of rounds" that upper protocol > (sub-)layers would need to have to deal with. > Otherwise, the "IKEv2 Transform Attribute Types" would have to > include an entry for "number of rounds", which it doesn't, and > you also do not aim at establishing such entry. > [Sean] The IKEv2 requirement in the draft is only about key lengths. I never pretended that the AES standard allows arbitary conbinations of key lengths and rounds. I checked the document again and noticed that in the second paragraph of section 2: "... The choices of Key Size, Rounds and Block Size are defined as followin= g which are compatible with [RFC3686]." If this sentense misleads readers to think that users can choose all conbinations, I will rewrite it as: "... The choices of Key Size are defined as following which are compatible with [RFC3686]." Best Regards, Sean --0016e648f0ae298e130476997eb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2009/10/23 Alfred H=CEnes <= ah@tr-sys.de>
Sean Shen wrote:

> Section 2.2 says that "= AES MUST use different rounds for each of the
> key sizes: ...".=
> The draft is not trying to say that IKEv2 requires 10/12/14 rounds= for
> 128/192/256 key lengths. The draft is not trying to say that AES-CTR> requires 10/12/14 rounds for 128/192/256 key lengths.
>
>= ; Sean
>
> ...

The "MUST" still makes th= e difference! =A0That is normative and does
NOT belong into this draft. =A0Although that would still be regarded
out= of scope of your draft, I would be more willing to accept an
_informati= ve_ statement like:

=A0 "Note: AES uses different rounds for ea= ch of the key sizes: ...".
=A0 =A0^^^^^^ =A0 =A0^^^^
[Sean] Correct, "MUST" is defined in key words conventions a= nd should not be used here. I will dropt it.
=A0
But the most important topic rem= ains: =A0The draft is ill-advised in
pretending that the interface of AE= S -- or, btw, *any* currently
sensibly used block cipher primitive of reasonable strength --
had an _e= xternal_ parameter "number of rounds" that upper protocol
(sub= -)layers would need to have to deal with.
Otherwise, the "IKEv2 Tra= nsform Attribute Types" would have to
include an entry for "number of rounds", which it doesn't, an= d
you also do not aim at establishing such entry.
[Sean] The IKEv2 requirement=A0in the draft is only about=A0 key lengt= hs. I never pretended that the AES standard allows=A0arbitary conbinations = of key lengths and rounds.
I checked the document again and=A0 noticed that in the second paragra= ph of section 2:
"... The choices of Key Size, Rounds and Block Size are defined a= s following which are compatible with [RFC3686]."
If this=A0sentense misleads readers to think that=A0users can choose a= ll conbinations, I will rewrite it as:
"... The choices of Key Size are defined as following which are c= ompatible with [RFC3686]."
=A0
Best Regards,
=A0
Sean
--0016e648f0ae298e130476997eb9-- From A.Hoenes@TR-Sys.de Fri Oct 23 06:06:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48CA3A68F4 for ; Fri, 23 Oct 2009 06:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.133 X-Spam-Level: ** X-Spam-Status: No, score=2.133 tagged_above=-999 required=5 tests=[AWL=0.882, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 ZdDGsCOSQFII for ; Fri, 23 Oct 2009 06:06:06 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 46ECF3A68EC for ; Fri, 23 Oct 2009 06:06:05 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA295453128; Fri, 23 Oct 2009 15:05:28 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA18127; Fri, 23 Oct 2009 15:05:14 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910231305.PAA18127@TR-Sys.de> To: sean.s.shen@gmail.com Date: Fri, 23 Oct 2009 15:05:14 +0200 (MESZ) In-Reply-To: <80b5a9190910230538h2a46e6e8i98235ea3529d45de@mail.gmail.com> from Sean Shen at Oct "23, " 2009 "08:38:45" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 13:06:07 -0000 Sean Shen wrote: >> ... >> > [Sean] The IKEv2 requirement in the draft is only about key lengths. > I never pretended that the AES standard allows arbitary conbinations > of key lengths and rounds. > I checked the document again and noticed that in the second paragraph > of section 2: > "... The choices of Key Size, Rounds and Block Size are defined as > following which are compatible with [RFC3686]." That was one of my initial complaints ... > If this sentense misleads readers to think that users can choose all > conbinations, I will rewrite it as: > "... The choices of Key Size are defined as following which are > compatible with [RFC3686]." ... and that's essentially what I had proposed for that paragraph. And yes, since that's written in the overview of Section 2, which lays out the skeleton of the remainder of the section, the immediate consequence of this change should be to drop sections 2.2 and 2.3 as well, as explained in my original review. (To recall: The argument presented there was that, after dropping inappropriate text, the remaining text in 2.2 & 2.3 would be a simple -- yet verbose -- restatement of the first paragraph of Section 2, and hence redundant anyway.) Bingo! We are converging. Thanks. > Best Regards, > > Sean Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From sean.s.shen@gmail.com Fri Oct 23 07:06:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F733A6842 for ; Fri, 23 Oct 2009 07:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 Q+NI-7bjPPyS for ; Fri, 23 Oct 2009 07:06:35 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 933C33A683E for ; Fri, 23 Oct 2009 07:06:35 -0700 (PDT) Received: by pwi4 with SMTP id 4so2187942pwi.29 for ; Fri, 23 Oct 2009 07:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=w/gUFjKHX6UwjLlpoHDfNz9pPDR84kmXgENKbIenN6w=; b=WidBmVKMycqQ1rRjkazWK3NPzX8IQ4fHScRNw6POt+4T1S955d/i5mmOOqfDul25oi f6+rMAKU8N/bTd0qOMM2JsxLeSDsvLyQRKULKcav11AUARtDekKiaOOzor+DrSymjShs Pgw5xAlS91mPr4ALjVlAeyGMFy8ilxhAPonx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=POUiiBtmulzzDJhJXkNfPsiKtAhg4vrLzeuUIuQDEFiUuBP0gd4XDq7jcDdG0wmXzn A0xZKjtLv/RgoCnboDgno3HngiO111SltIG34RCbSakA/yZrixsndKC6noFLta0HB0a5 iad/1YS9Mtn8km7CMJ4zCdKJQES7A8wy2KtSM= MIME-Version: 1.0 Received: by 10.115.86.7 with SMTP id o7mr16105239wal.50.1256306803667; Fri, 23 Oct 2009 07:06:43 -0700 (PDT) In-Reply-To: <200910231305.PAA18127@TR-Sys.de> References: <80b5a9190910230538h2a46e6e8i98235ea3529d45de@mail.gmail.com> <200910231305.PAA18127@TR-Sys.de> Date: Fri, 23 Oct 2009 22:06:43 +0800 Message-ID: <80b5a9190910230706ta100ec1j7e52d6160c7960f1@mail.gmail.com> From: Sean Shen To: =?ISO-8859-1?Q?Alfred_H=CEnes?= Content-Type: multipart/alternative; boundary=0016e64b0448c2f39604769ab86e Cc: ipsec@ietf.org Subject: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 14:06:36 -0000 --0016e64b0448c2f39604769ab86e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/10/23 Alfred H=CEnes > Sean Shen wrote: > > >> ... > >> > > [Sean] The IKEv2 requirement in the draft is only about key lengths. > > I never pretended that the AES standard allows arbitary conbinations > > of key lengths and rounds. > > I checked the document again and noticed that in the second paragraph > > of section 2: > > "... The choices of Key Size, Rounds and Block Size are defined as > > following which are compatible with [RFC3686]." > > That was one of my initial complaints ... > > > If this sentense misleads readers to think that users can choose all > > conbinations, I will rewrite it as: > > "... The choices of Key Size are defined as following which are > > compatible with [RFC3686]." > > ... and that's essentially what I had proposed for that paragraph. > > And yes, since that's written in the overview of Section 2, which > lays out the skeleton of the remainder of the section, the immediate > consequence of this change should be to drop sections 2.2 and 2.3 > as well, as explained in my original review. > (To recall: The argument presented there was that, after dropping > inappropriate text, the remaining text in 2.2 & 2.3 would be a > simple -- yet verbose -- restatement of the first paragraph of > Section 2, and hence redundant anyway.) [Sean] Section 2.2 introduces key length of AES, the associated rounds, IKEv2's MUST/MAY requirements of key length. Section 2.3 introduces block size. These are all basic intro of algorithm. The overview of section 2 can be: " The use of AES algorithm operations in IKEv2 is the same as what defined in [AES]. The use of Counter Mode is defined the same as how AES_CTR is used to encrypt ESP payload [RFC3686]. Basic descriptions of AES and CTR mode are given in this section. Also the requirement of Key Size of IKEv2 are discussed as following which are compatible with [RFC3686]." Best, Sean --0016e64b0448c2f39604769ab86e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/10/23 Alfred H=CEnes <= ah@tr-sys.de>
Sean Shen wrote:

>>= ...
>>
> [Sean] The IKEv2 requirement in the draf= t is only about key lengths.
> I never pretended that the AES standar= d allows arbitary conbinations
> of key lengths and rounds.
> I= checked the document again and noticed that in the second paragraph
> of section 2:
> "... The choices of Key Size, Rounds and Bl= ock Size are defined as
> =A0 following which are compatible with [RF= C3686]."

That was one of my initial complaints ...

> If this sentense misleads readers to think that = users can choose all
> conbinations, I will rewrite it as:
> = =A0"... The choices of Key Size are defined as following which are
= > =A0 compatible with [RFC3686]."

... and that's essentially what I had proposed for that parag= raph.

And yes, since that's written in the overview of Section 2= , which
lays out the skeleton of the remainder of the section, the immed= iate
consequence of this change should be to drop sections 2.2 and 2.3
as wel= l, as explained in my original review.
(To recall: The argument presente= d there was that, after dropping
inappropriate text, the remaining text = in 2.2 & 2.3 would be a
simple -- yet verbose -- restatement of the first paragraph of
Section 2= , and hence redundant anyway.)
[Sean] Section 2.2=A0introduces key length of AES, the associated roun= ds, IKEv2's MUST/MAY requirements of key length. Section 2.3 =A0introdu= ces block size. These are all basic intro of algorithm.
The overview of section 2 can be:
"=A0The use of AES algorithm operations in IKEv2 is the same as w= hat defined in [AES].=A0 The use of Counter Mode is defined the same as how= AES_CTR is used to encrypt ESP payload [RFC3686].=A0 Basic descriptions of= AES and CTR mode are given in this section. Also the=A0requirement of=A0Ke= y Size of IKEv2 are discussed as following which are compatible with [RFC36= 86]."
=A0
Best,
=A0
Sean
=A0
=A0
--0016e64b0448c2f39604769ab86e-- From paul.hoffman@vpnc.org Fri Oct 23 07:12:32 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E17A3A6842 for ; Fri, 23 Oct 2009 07:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.742 X-Spam-Level: X-Spam-Status: No, score=-4.742 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, 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 gzcn9q9jKqUo for ; Fri, 23 Oct 2009 07:12:31 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D7DF33A6836 for ; Fri, 23 Oct 2009 07:12:31 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9NECfox081654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Oct 2009 07:12:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 23 Oct 2009 07:12:38 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Seeking interest in new charter items for the IPsecME WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 14:12:32 -0000 We have received a bunch of responses, and some questions. Here is a revised request, now with a firm deadline of October 30. ------------------------------------ Greetings again. As Yaron and I have said many times in the past, when a few of our WG documents have been completed, we can think about adding additional items to our charter. We think that we will soon be at that point. For new items to be considered in the WG, we need to have an existing, personally-submitted Internet Draft, and four people (other than the authors) who are committed to reviewing the draft as it moves through the WG process. If you have an Internet Draft (or will have one very soon) that you think should be a WG item, please send Yaron and I a message off-list before October 30. Note that the cut-off for submitting new -00 drafts has already past; we will accept proposals without an Internet Draft if the author has a draft ready and posted to a personal web site by October 30, *and* promises to have the draft submitted on Monday, November 9 when they are allowed to turn them in again. We will review the submissions, talk with the proposers a bit, and then have an discussion of the proposals at the Hiroshima face-to-face meeting, followed by more discussion on the mailing list post-Hiroshima. --Paul Hoffman, Director --VPN Consortium From A.Hoenes@TR-Sys.de Fri Oct 23 07:59:31 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4EA3A67A8 for ; Fri, 23 Oct 2009 07:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.099 X-Spam-Level: ** X-Spam-Status: No, score=2.099 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 lId8XeE53hdQ for ; Fri, 23 Oct 2009 07:59:29 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 2563B3A6784 for ; Fri, 23 Oct 2009 07:59:25 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA296059924; Fri, 23 Oct 2009 16:58:44 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA18350; Fri, 23 Oct 2009 16:58:38 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910231458.QAA18350@TR-Sys.de> To: sean.s.shen@gmail.com, ipsec@ietf.org Date: Fri, 23 Oct 2009 16:58:38 +0200 (MESZ) In-Reply-To: <80b5a9190910230706ta100ec1j7e52d6160c7960f1@mail.gmail.com> from Sean Shen at Oct "23, " 2009 "10:06:43" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 14:59:31 -0000 Folks, I do not want to re-iterate too frequently, but it has become clear to me that my original review did not make it to the list -- most likely due to a clerical error I had made. Sean had responded to that message in detail on the list, but it might help to have the original at hands for quoting, and so I provide it below. Feel free to skip forward to the "end forwarded message" separator line if you are only interested in the still open issue. -------- begin forwarded message -------- > From: > To: draft-ietf-ipsecme-aes-ctr-ikev2@tools.IETF.ORG > Message-Id: <200910131509.RAA22549@TR-Sys.de> > Date: Tue, 13 Oct 2009 17:09:25 +0200 (MESZ) > Subject: review of draft-ietf-ipsecme-aes-ctr-ikev2-02 Hello, I've arrived at completing a review of your I-D, draft-ietf-ipsecme-aes-ctr-ikev2-02, and have a couple of comments. First of all, this draft closes a gap that in the past could only be bridged by extrapolation, incurring a high risk of interoperability problems. As such, this draft is very useful. Yet, I'm not convinced that it is necessary to re-state so much plain knowledge about AES and CTR mode in this memo, and not rarely doing that even up to three times. Therefore, I generally would appreciate an attempt to 'boil down' the volume of this draft, reducing redundancies in the text (that, as experience has shown, generally always also run the risk of inconsistencies as well), and making more use of normative text from existing specifications that can be referenced. However, I could live with the current structure of the draft if in certain places the focus were be changed from general to the specifics of the application of AES-CTR in IKEv2. Based on this general assumption, a linear walk-through of the draft follows with detailed change recommendations. Short substitutions are shown in POSIX edit style: s/old/new/ . To give more context, sometimes I quote larger blocks of text literally and show the replacement proposed using the shorthand notation: --- I use change bars ('|' in column 1) and occasionally insert up/down pointing marker lines ('^^^'/'vvv') to emphasize the location of textual issues and/or proposed corrections. Modified text has been re-adjusted to match RFC formatting rules, where appropriate. I also try to accomodate published RFC-Ed policy on style and punctuation etc. in my proposals. (1) Section 1, and General -- editorials (1a) In a few instances, text is inadvertantly immediately joined with adjacent parenthetical parts. Please ensure the presence of white space in these places. For instance, in the 3rd para of Section 1, please s/initial exchange(IKE_SA_INIT)/initial exchange (IKE_SA_INIT)/ ^ (1b) In many places, articles are missing and singular/plural mismatches occur. I've tried to catch these all and address them in the items below. (1c) The draft inconsistently switches between "AES_CTR" and "AES-CTR". Please use a unique spelling -- preferably with the hypen. This issue is not prosecuted in all details below and left as an exercise. :-) (2) Section 2, last para According to the rationale above, I suggest to apply the following 'facelifting' for the 4th (last) paragraph of Section 1: This document explains how IKEv2 makes use of AES_CTR algorithm for encrypting IKE messages that follow initial exchange: The second pair of messages (IKE_AUTH) in initial exchange, messages in CREATE_CHILD_SA exchange, messages in INFORMATIONAL exchange. --- | This document explains how IKEv2 makes use of the AES-CTR algorithm ^^^^^ ^ | for encrypting IKE messages that follow the initial exchange: The ^^^^^ | second pair of messages (IKE_AUTH) in the initial exchange, messages ^^^^^ | in CREATE_CHILD_SA exchanges, and messages in INFORMATIONAL ^ | exchanges. ^ (3) Section 2 (and ff.) It is confusing for protocol designers and implementers to refer to "parameters" of a cryptographic algorithm or building block that in fact have been internal design decisions not exposed to the external interface of the algorithm / building block. Therefore, for the purpose of the application of AES and AES-CTR, neither the number of rounds nor the block size of the AES cipher are subject to higher level parametrization that, for instance, would need to be carried in algorithm negotiation exchanges. It is particularly confusing that the draft pretends Rounds and Block Size were "choices" needing specification in this context. The number of (internal) rounds is totally irrelevant for the application of the AES. Any attempt to mangle with this 'parameter' would raise significant security concerns and conformance issues. I strongly request to elide all mention of "rounds" from the draft. The block size (128 bits) is an invariant of AES and should only be mentioned in contexts where it really matters. The consequences of these recommendations are included in the change recommendations below. The first paragraph of Section 2 essentially says all that's needed to be said, but it might be gradually better to replace "can process" by "processes" -- due to the lack of an alternative: | AES [AES] is a symmetric block cipher that can process data blocks of 128 bits, using cipher keys with lengths of 128, 192, and 256 bits. --- vvvvvvvvv | AES [AES] is a symmetric block cipher that processes data blocks of 128 bits, using cipher keys with lengths of 128, 192, and 256 bits. The second paragraph sketches the embedding of the building blocks, and it should refrain from further discussing "choices". Instead, I suggest to outline the role of the following section, as a guide to the reader, and try to better delineate it from the subsequent sections that specify the details for AES-CTR with IKEv2: The use of AES algorithm operations in IKEv2 is the same as what defined in [AES]. The use of Counter Mode is defined the same as how | AES_CTR is used to encrypt ESP payload [RFC3686]. The choices of Key | Size, Rounds and Block Size are defined as following which are | compatible with [RFC3686]. --- The use of AES algorithm operations in IKEv2 is the same as what defined in [AES]. The use of Counter Mode is defined the same as how | AES-CTR is used to encrypt ESP payloads [RFC3686]. | | Section 2.1 sketches the operation and properties of counter mode | at a high level and indicates how it is to be used inside IKEv2; | Sections 3 through 6 will give the normative descriptions for the | details of this use case of AES-CTR. (4) Section 2.1 (4a) 1st para -- editorial fixes Please adjust: This section gives description for AES Counter Mode algorithm and cites algorithm description part in section 2.1 of [RFC3686] --- vvv vvvvv | This section gives a description for the AES Counter Mode algorithm | and cites the algorithm description part in Section 2.1 of [RFC3686]. ^^^^^ ^ ^ (4b) 3rd para Please delete te comma in the first sentence; two-handed enumerations with "and"/"or" do not need that: Only AES Counter mode (AES-CTR) is discussed in this specification. | AES-CTR requires the encryptor to generate a unique per-packet value, and communicate this value to the decryptor. [...] --- Only AES Counter mode (AES-CTR) is discussed in this specification. | AES-CTR requires the encryptor to generate a unique per-packet value and communicate this value to the decryptor. [...] (4c) 4th para I fear the text copying from RFC 3686 went too far here, without the necessary adoption. This draft addresses IEKv2-inernal use of AES-CTR, and that happens within the *IKE* SA, not in the *IPsec* SAs. So please correct, for the purpose of this memo: This specification calls for the use of a nonce for additional protection against precomputation attacks. The nonce value need not be secret. However, the nonce MUST be unpredictable prior to the | establishment of the IPsec security association that is making use of AES-CTR. --- ^^^^^ This specification calls for the use of a nonce for additional protection against precomputation attacks. The nonce value need not be secret. However, the nonce MUST be unpredictable prior to the | establishment of the IKE security association that is making use of ^^^ AES-CTR. (4d) 5th para -- clarifications / textual enhancements I suggest to change: AES-CTR has many properties that make it an attractive encryption | algorithm for in high-speed networking. AES-CTR uses the AES block cipher to create a stream cipher. Data is encrypted and decrypted by XORing with the key stream produced by AES encrypting sequential counter block values. AES-CTR is easy to implement, and AES-CTR can be pipelined and parallelized. AES-CTR also supports key stream precomputation. --- AES-CTR has many properties that make it an attractive encryption | algorithm for use in high-speed networking. AES-CTR uses the AES ^^^^^ block cipher to create a stream cipher. Data is encrypted and | decrypted by XORing with the key stream produced by encrypting ^ | sequential counter block values with AES in ECB mode. AES-CTR is ^^^^^^^^^^^^^^^^^^^^^ easy to implement, and AES-CTR can be pipelined and parallelized. AES-CTR also supports key stream precomputation. (4e) 6th para -- typo Please correct: s/AES- CTR/AES-CTR/ . ^^ ^ (4f) 7th para -- punctuation There should not be a comma in "... one could use ..., to process ..." ^ (4g) 9th para -- language improvement Please swap words in the first line to restore correct semantics: vvvvvvvv | AES-CTR uses the only AES encrypt operation (for both encryption and decryption), making AES-CTR implementations smaller than implementations of many other AES modes. --- vvvvvvvv | AES-CTR uses only the AES encrypt operation (for both encryption and decryption), making AES-CTR implementations smaller than implementations of many other AES modes. (4h) 10th para As in item (4c) above, two last sentences in this paragraph have not been properly transformed into the intended context, inside IKEv2. Please change: [...]. Extraordinary measures would be needed to prevent reuse of an IV value with the static key across power cycles. To be | safe, implementations MUST use fresh keys with AES-CTR. The Internet | Key Exchange [RFC4306] protocol can be used to establish fresh keys. IKE can also provide the nonce value. --- [...]. Extraordinary measures would be needed to prevent reuse of an IV value with the static key across power cycles. To be | safe, implementations MUST use fresh keys with AES-CTR. The initial ^^^^^^^^ | exchange of the IKEv2 protocol [RFC4306] can be used to establish ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | fresh keys for an IKEv2 SA, and it also provides the nonce value. ^^^^^^^^^^^^^^^^^^^^^^^ ^ (5) Section 2.2 I recommend to drop the entire section. Detailed reasoning: |2.2. Key Sizes and Rounds See the rationale in item (3) above. | AES supports three key sizes: 128 bits, 192 bits, and 256 bits. [...] That already has been stated earlier in the draft and hence is redundant. | [...]. All | IKEv2 implementations that implement AES-CTR MUST support the 128 key | size. An IKEv2 implementation MAY support key sizes of 192 and 256 | bits. That belongs into the normative part of the draft. I suggest putting these two sentences as a new (2nd) paragraph into Section 5. | AES MUST use different rounds for each of the key sizes: | | When a 128-bit key is used, implementations MUST use 10 rounds. | | When a 192-bit key is used, implementations MUST use 12 rounds. | | When a 256-bit key is used, implementations MUST use 14 rounds. As pointed out in item (3) above, that is an internal detail of the AES design and not subject to importance or change by the user of AES. This part definitely does not belong into this document. (6) Section 2.3 I recommend to drop the entire section. Detailed reasoning: |2.3. Block Size | | The AES algorithm has a block size of 128 bits (16 octets), i.e., AES | generate 128 bits of key stream. [...] This statement is misleading; the correct description can be found earlier, in Section 2.1. | [...]. For encryption or decryption, a | user XOR the key stream with 128 bits of plaintext or ciphertext | blocks. If the generated key stream is longer than the plaintext or | ciphertext, the extra key stream bits are simply discarded. For this | reason, AES-CTR does not require the plaintext to be padded to a | multiple of the block size. This all has been explained at length and in detail in Section 2.1. Why would we want to repeat it again here? (7) Section 3.1 In the first part of the text here, an article is missing. The second part again rephrases parts of Section 2.1, and it does so in a confusingly general way that does not help the implementor of AES-CTR for use within IKEv2. I request to drop that text. Instead, I suggest to add a pointer to where the IV is used. In total, please change: v | The IV field MUST be eight octets when AES_CTR algorithm is used for encryption. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is NOT used more than once with a given encryption key. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs). --- vvvvv v The IV field MUST be eight octets when the AES-CTR algorithm is used for encryption. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is NOT used more than once with a | given encryption key. See Section 4 for how the IV is used to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | construct counter blocks for AES-CTR use within IKEv2. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (8) Section 3.2 Again, a definite article is missing here. Please adjust: s/for Encrypted Payload/for the Encrypted Payload/ ^ ^^^^^ (9) Section 3.3, 2nd para In two more instances, the definitie article is missing. Please adjust: | It should be noticed that ESP [RFC4303] Encrypted Payload requires | alignment on a 4-byte boundary while IKEv2 [RFC4306] Encrypted Payload does not have such a requirement. --- vvvvv | It should be noticed that the ESP [RFC4303] Encrypted Payload | requires alignment on a 4-byte boundary while the IKEv2 [RFC4306] ^^^^^ Encrypted Payload does not have such a requirement. (10) Section 4 Again, please adjust ... (10a) 2nd para The Encrypted Payload is the XOR of the plaintext and key stream. | The key stream is generated by inputing Counter Blocks into AES algorithm. [...] --- The Encrypted Payload is the XOR of the plaintext and key stream. | The key stream is generated by inputing Counter Blocks into the AES algorithm. [...] ^^^^^ (10b) last para Section 2 provides references to other documents for implementing | AES_CTR encryption/decryption process. --- Section 2 provides references to other documents for implementing | the AES-CTR encryption/decryption process. ^^^^ ^ (11) Section 5 | This section describes the conventions used by IKEv2 protocol to | generate encryption keys and nonces for use with AES-CTR algorithm in | IKE-SA negotiation. The identifiers and attributes related to AES- | CTR required during IKE-SA and Child-SA negotiation are also defined. Please fix missing articles and a singular/plural issue. I'm not sure whether the mention of Child-SA is appropriate here. IMHO, that is covere in RFC 3686, and should not be re-stated here. I propose changed wording below. Please check! Further, as mentioned in item (5) above, I suggest to move text from the obsolescent Section 2.2 into this section. This results in the following revised text: vvvvv | This section describes the conventions used by the IKEv2 protocol to | generate encryption keys and nonces for use with the AES-CTR v ^^^^^ | algorithm in IKE-SA negotiations. The identifiers and attributes | related to AES-CTR as defined in [RFC3686] are used in the same | manner during IKE-SA negotiation. | | All IKEv2 implementations that implement AES-CTR MUST support the 128 | key size. An IKEv2 implementation MAY support key sizes of 192 and | 256 bits. (12) Section 5.1 (12a) 2nd para Again, an article is missing, and item (1a) applies. After an abbreviation has been introduced, it may be used to streamline the text; therefore I suggest to delete the repeated expansion of "PRF". Hence, please change: IKEv2 negotiates four cryptographic algorithms with its peer using | IKE_SA_INIT exchange. They include an encryption algorithm and a | pseudo-random function(PRF). All the payloads of IKEv2 messages that follow the IKE_SA_INIT exchange are encrypted using the negotiated | encryption algorithm. The pseudo-random function(PRF)is used to generate the keying material required for the encryption algorithm. --- IKEv2 negotiates four cryptographic algorithms with its peer using | the IKE_SA_INIT exchange. They include an encryption algorithm and a ^^^^ v | pseudo-random function (PRF). All the payloads of IKEv2 messages that follow the IKE_SA_INIT exchange are encrypted using the | negotiated encryption algorithm. The PRF is used to generate the ^ ^ keying material required for the encryption algorithm. (12b) 3rd para Item (1b) again: | AES_CTR encryption algorithm needs an encryption key and a nonce. [...] ---vvvv | The AES_CTR encryption algorithm needs an encryption key and a nonce. [...] (13) Section 5.2 I suggest to insert the word "value" before "of 13", and to avoid the unnecessary repetition of the code point. The above concerns w.r.t. "Child-SA" apply. So please change: | IKEv2 uses the IANA allocated encryption identifier of 13 for | ENCR_AES_CTR with an explicit IV (ENCR_AES_CTR 13) as the transform | ID during IKE-SA and Child-SA negotiation. --- | IKEv2 uses the IANA allocated encryption identifier value of 13 for v ^^^^^^^ vvv | ENCR_AES_CTR with an explicit IV as the transform ID during IKE-SA negotiation. (14) Section 6 (14a) 2nd para -- language improvement Please adjust: AES_CTR provides high confidentiality when used properly. However, | as a stream mode cipher, the security of will lose when AES-CTR is misused. --- ^^^^^^^^^^^^ AES_CTR provides high confidentiality when used properly. However, | as a stream mode cipher, the security will be lost when AES-CTR is misused. ^^^^^^^^^^^^ (14b) 3rd para Following (1b), please correct: Generally, a stream cipher should not use static keys. This is because key streams will be easily canceled when two ciphertext use | the same key stream (check detailed description of this attack in [RFC3686]). Therefore, IKEv2 should avoid an identical key being | used for different IKE SA or a same key stream being used on different blocks of plaintext. [...] --- Generally, a stream cipher should not use static keys. This is because key streams will be easily canceled when two ciphertext use | the same key stream (check the detailed description of this attack in ^^^^^ [RFC3686]). Therefore, IKEv2 should avoid an identical key being | used for different IKE SAs or a same key stream being used on ^ different blocks of plaintext. [...] (14c) 4th para -- language improvements v vvvvv | A stream cipher like AES_CTR is also vulnerable under data forgery | attack (check [RFC3686] for a demonstration of this attack). [...] --- v vvvvvvv | A stream cipher like AES-CTR is also vulnerable against data forgery | attacks (check [RFC3686] for a demonstration of this attack). [...] ^ (14d) 5th para Again, according to (1b) please correct: v | [...]. Since IKEv2 are not likely to carry traffics in such a high quantity, this won't be a big concern here. However, when large amount of traffic appear in the future or under abnormal circumstances, implementations SHOULD generate a fresh key before 2^64 blocks are encrypted with the same key. --- [...]. Since IKEv2 are not likely to carry traffic in such a high quantity, this won't be a big concern here. However, | when a large amount of traffic appears in the future or under ^^^ ^ abnormal circumstances, implementations SHOULD generate a fresh key before 2^64 blocks are encrypted with the same key. (15) Section 7 I suggest to more clearly indicate what this draft is expecting IANA to do: adding a reference to this memo for an existing registration. | IANA has assigned 13 as the transform ID for ENCR_AES_CTR encryption | with an explicit IV. This ID is to be used during IKE_SA | negotiation. --- | Per [RFC3686], IANA has assigned 13 as the "IKEv2 Encryption | Transform ID" to the name "ENCR_AES_CTR" for AES-CTR encryption with | an explicit IV, in the IANA "Internet Key Exchange Version 2 (IKEv2) | Parameters" registry. This document specifies how to use this | transform during IKE_SA negotiations. Hence IANA should add to that | entry a reference to this RFC. Best regards, Alfred HÎnes. -------- end forwarded message -------- Most of these items are resolved by Sean's comments. The current discussion circles around the issues detailed in items (3), (5), and (6) above. Most recently, Sean Shen wrote: > 2009/10/23 Alfred HÎnes > >> Sean Shen wrote: >> >>>> ... >>>> >>> [Sean] The IKEv2 requirement in the draft is only about key lengths. >>> I never pretended that the AES standard allows arbitary conbinations >>> of key lengths and rounds. >>> I checked the document again and noticed that in the second paragraph >>> of section 2: >>> "... The choices of Key Size, Rounds and Block Size are defined as >>> following which are compatible with [RFC3686]." >> >> That was one of my initial complaints ... >> >>> If this sentense misleads readers to think that users can choose all >>> conbinations, I will rewrite it as: >>> "... The choices of Key Size are defined as following which are >>> compatible with [RFC3686]." >> >> ... and that's essentially what I had proposed for that paragraph. >> >> And yes, since that's written in the overview of Section 2, which >> lays out the skeleton of the remainder of the section, the immediate >> consequence of this change should be to drop sections 2.2 and 2.3 >> as well, as explained in my original review. >> (To recall: The argument presented there was that, after dropping >> inappropriate text, the remaining text in 2.2 & 2.3 would be a >> simple -- yet verbose -- restatement of the first paragraph of >> Section 2, and hence redundant anyway.) > > [Sean] Section 2.2 introduces key length of AES, the associated rounds, > IKEv2's MUST/MAY requirements of key length. Section 2.3 introduces block > size. These are all basic intro of algorithm. ... exactly, that's why Section 2 says the basics (after the editorial fix): | AES [AES] is a symmetric block cipher that processes data blocks of | 128 bits, using cipher keys with lengths of 128, 192, and 256 bits. Regarding the remainder of the 1st para of Section 2.2, I said above in item (5): ! | [...]. All ! | IKEv2 implementations that implement AES-CTR MUST support the 128 key ! | size. An IKEv2 implementation MAY support key sizes of 192 and 256 ! | bits. ! ! That belongs into the normative part of the draft. ! I suggest putting these two sentences as a new (2nd) paragraph into ! Section 5. After striking the out-of-scope text, 2.2 then is empty. That's it. > The overview of section 2 can be: > " The use of AES algorithm operations in IKEv2 is the same as what defined > in [AES]. The use of Counter Mode is defined the same as how AES_CTR is > used to encrypt ESP payload [RFC3686]. Basic descriptions of AES and CTR > mode are given in this section. Also the requirement of Key Size of IKEv2 > are discussed as following which are compatible with [RFC3686]." I restate my suggestion from for that text item (3) above, which seems to be much more clear and helpful for the reader of the document: ! The use of AES algorithm operations in IKEv2 is the same as what ! defined in [AES]. The use of Counter Mode is defined the same as how ! | AES-CTR is used to encrypt ESP payloads [RFC3686]. ! | ! | Section 2.1 sketches the operation and properties of counter mode ! | at a high level and indicates how it is to be used inside IKEv2; ! | Sections 3 through 6 will give the normative descriptions for the ! | details of this use case of AES-CTR. The stripped-down first part says all necessary here. The normative requirements on key size support belong into the section that details all other aspects of interest of IEKv2, Section 5. The second part should serve as a guide for readers. With this statement, it should be clear that 2.1 is an informative sketch of other, referenced specifications; thus avoiding any allusion of possible normative conflict. > > Best, > > Sean Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From hoskuld@hotmail.com Sun Oct 25 14:54:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67C573A68B3 for ; Sun, 25 Oct 2009 14:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=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 PQAuL+7S4iPD for ; Sun, 25 Oct 2009 14:54:57 -0700 (PDT) Received: from snt0-omc2-s14.snt0.hotmail.com (snt0-omc2-s14.snt0.hotmail.com [65.55.90.89]) by core3.amsl.com (Postfix) with ESMTP id 455703A6801 for ; Sun, 25 Oct 2009 14:54:57 -0700 (PDT) Received: from SNT127-W26 ([65.55.90.73]) by snt0-omc2-s14.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 14:55:10 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a6194975-d5dd-43f0-b5ce-32eeaba1d630_" X-Originating-IP: [203.217.95.88] From: Greg Daley To: Date: Mon, 26 Oct 2009 08:55:09 +1100 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 25 Oct 2009 21:55:10.0536 (UTC) FILETIME=[D2AF3C80:01CA55BD] Subject: [IPsec] New draft on MPLS Label Traffic Selectors for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 21:54:58 -0000 --_a6194975-d5dd-43f0-b5ce-32eeaba1d630_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear IPsecME WG=2C A new draft has been submitted which describes the format of a new TS Type for IKEv2. This document makes use of feedback I received here on traffic selector for= mats from the time of last IETF meeting. Your feedback is sought to determine the usefulness of this specification= =2C and its consistency with IPsec architecture. Title: MPLS Label Traffic Selectors for Internet Key Exchange Version 2 Document: draft-daley-mpsec-label-ts-00.txt Abstract: "Existing mechanisms for encapsulating MPLS labels in ESP or AH payloads lack the ability to specify which Labels are to be transported. This document provides new traffic selector format for IKEv2 in which MPLS label fields and parameters can be selected." The document is available at: http://tools.ietf.org/id/draft-daley-mpsec-label-ts-00.txt = =20 Sincerely=2C Greg Daley =20 _________________________________________________________________ Use Messenger in your Hotmail inbox Find out how here http://windowslive.ninemsn.com.au/article.aspx?id=3D823454= --_a6194975-d5dd-43f0-b5ce-32eeaba1d630_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear IPsecME WG=2C

A new draft has been submitted which describes th= e format of a new TS Type
for IKEv2.

This document makes u= se of feedback I received here on traffic selector formats
from the time= of last IETF meeting.

Your feedback is sought to determine the usefulness of this specification= =2C
and its consistency with IPsec architecture.


Title:
MPLS La= bel Traffic Selectors for Internet Key Exchange Version 2

Document:
draft-daley-m= psec-label-ts-00.txt

Abstract:
 "Existing mechanisms for encapsulating MPLS labels in ESP or AH
 payloads lack the ability to specify which Labels are to be
 transported.
This document provides new traffic selector format for IKEv2 in which
 MPLS label fields and parameters can be selected."

The document is available at:

http://tools.ietf.org/id/draft-dal= ey-mpsec-label-ts-00.txt =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =


Sincerely=2C

Greg Daley


F= ind out how here Use Messenger in your Hotmail inbox = --_a6194975-d5dd-43f0-b5ce-32eeaba1d630_-- From hoskuld@hotmail.com Sun Oct 25 15:04:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10CFF3A693C for ; Sun, 25 Oct 2009 15:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=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 oKo2MKPa-kzQ for ; Sun, 25 Oct 2009 15:04:24 -0700 (PDT) Received: from snt0-omc2-s29.snt0.hotmail.com (snt0-omc2-s29.snt0.hotmail.com [65.55.90.104]) by core3.amsl.com (Postfix) with ESMTP id 274FD3A6921 for ; Sun, 25 Oct 2009 15:04:24 -0700 (PDT) Received: from SNT127-W45 ([65.55.90.71]) by snt0-omc2-s29.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 15:04:37 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d165df80-0ab7-4d10-b936-c7919b3ff599_" X-Originating-IP: [203.217.95.88] From: Greg Daley To: Date: Mon, 26 Oct 2009 09:04:37 +1100 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 25 Oct 2009 22:04:37.0440 (UTC) FILETIME=[2495EC00:01CA55BF] Subject: [IPsec] Updated draft on defining traffic selector bindings for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 22:04:25 -0000 --_d165df80-0ab7-4d10-b936-c7919b3ff599_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear IPsecME WG=2C An updated draft is available which discusses new forms of traffic selector= s in IKEv2. This draft received feedback on the around last IETF meeting=2C and has bee= n revised accordingly. notable changes are: A specific focus on providing guidance on traffic selector format issues=2C= without defining formats. Improvements to the example traffic selectors A discussion on challenges in creating decorrelation of traffic selectors f= or various protocols. Your feedback is sought on the current utility and accuracy of this documen= t. Please note that the guidance from this document has been used to generate = one format for traffic selectors now submitted in a separate document. Your assistance is greatly appreciated. Title: Guidelines for Multiprotocol Traffic Selector Bindings in IPsec Document: draft-daley-mpsec-traffic-sel-ps-01.txt Abstract In IPsec=2C secure connectivity is provided for network layer entities. Traffic Selectors which specify interesting traffic for security association encapsulation are identified only by network and transport layer addressing. This document discusses extending traffic selectors to allow more generic definitions of interesting traffic. Sincerely=2C Greg Daley =20 _________________________________________________________________ Use Messenger in your Hotmail inbox Find out how here http://windowslive.ninemsn.com.au/article.aspx?id=3D823454= --_d165df80-0ab7-4d10-b936-c7919b3ff599_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear IPsecME WG=2C

An updated draft is available which discusses new= forms of traffic selectors in IKEv2.

This draft received feedback o= n the around last IETF meeting=2C and has been revised accordingly.

= notable changes are:

A specific focus on providing guidance on traff= ic selector format issues=2C without defining formats.

Improvements = to the example traffic selectors

A discussion on challenges in creat= ing decorrelation of traffic selectors for various protocols.


Yo= ur feedback is sought on the current utility and accuracy of this document.=
Please note that the guidance from this document has been used to gener= ate one format
for traffic selectors now submitted in a separate documen= t.

Your assistance is greatly appreciated.

Title:
Guidelin= es for Multiprotocol Traffic Selector Bindings in IPsec

Document:
draft-daley-mpsec-traffic-sel-ps-01.txt

<=
font style=3D"" face=3D"Verdana">Abstract

In IPsec=2C secure connectivity is provided for netw=
ork layer entities.
Traffic Selectors which specify interesting t=
raffic for security
association encapsulation are identified only=
 by network and
transport layer addressing.

=
This document discusses extending traffic=
 selectors to allow more
generic definitions of interesting traff=
ic.


Sincerely=2C

Greg Daley

=
Find out how here Use Messenger in your Hotmail = inbox = --_d165df80-0ab7-4d10-b936-c7919b3ff599_-- From root@core3.amsl.com Mon Oct 26 14:15:03 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 515DC28C194; Mon, 26 Oct 2009 14:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026211503.515DC28C194@core3.amsl.com> Date: Mon, 26 Oct 2009 14:15:03 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-ipv6-config-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IPv6 Configuration in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-ietf-ipsecme-ikev2-ipv6-config-03.txt Pages : 36 Date : 2009-10-26 When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-ipv6-config-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-ipv6-config-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26140344.I-D@ietf.org> --NextPart-- From sheila.frankel@nist.gov Tue Oct 27 08:43:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE9EC3A6925 for ; Tue, 27 Oct 2009 08:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 OgBarxulEpEy for ; Tue, 27 Oct 2009 08:43:52 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id A2C323A6858 for ; Tue, 27 Oct 2009 08:43:51 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9RFhlS4026105; Tue, 27 Oct 2009 11:43:47 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Tue, 27 Oct 2009 11:43:43 -0400 From: "Frankel, Sheila E." To: "ipsec@ietf.org" Date: Tue, 27 Oct 2009 11:39:17 -0400 Thread-Topic: [ipsecme] #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3? Thread-Index: AcpOvk9aHvjitHGqTBejH4YXV3r4SgIXVU/9 Message-ID: References: <063.764926e4414cb9e492e9c76aed2dcc1d@tools.ietf.org> In-Reply-To: <063.764926e4414cb9e492e9c76aed2dcc1d@tools.ietf.org> 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 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: Tero Kivinen , Paul Hoffman , "suresh.krishnan@ericsson.com" Subject: Re: [IPsec] [ipsecme] #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:43:53 -0000 #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3? Proposed changes to Roadmap doc: 1) Add text to section 5.4 (Combined Mode Algorithms) Current text: IKEv1 and ESP-v2 use separate algorithms to provide encryption and integrity-protection, and IKEv1 can negotiate different combinations of algorithms for different SAs. In ESP-v3, a new class of algorithms was introduced, in which a single algorithm can provide both encryption and integrity-protection. [RFC4306] describes how IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to negotiate and use combined mode algorithms for its own traffic. When properly designed, these algorithms can provide increased efficiency in both implementation and execution. Additional text: Some IKEv1 implementations have added the capability to negotiate=20 combined mode algorithms for use in IPsec SAs; these implementations do not include the capability to use combined mode algorithms to protect IKE SAs. Since combined mode algorithms are not a feature of IPsec-v2,=20 these IKEv1 implementations are used in conjunction with IPsec-v3. IANA numbers for combined mode algorithms have been added to the IKEv1 regist= ry. 2) Change IKEv2 and IPsec-v2 requirement levels Requirements levels for AES-GMAC: old IKEv2 - optional new IKEv2 - optional (integrity-protection algorithm) N/A (combined mode algorithm with NULL encryption) old IPsec-v2 - undefined (no IANA #) new IPsec-v2: AH-v2 - optional (integrity-protection alg) ESP-v2 - N/A (combined mode algorithm with NULL encryption) 3) Move RFC 4543 to section on combined mode algorithms, since it has 2 ver= sions: classic integ prot and also combined mode ________________________________________ From: ipsecme issue tracker [trac@tools.ietf.org] Sent: Friday, October 16, 2009 8:10 PM To: paul.hoffman@vpnc.org; Frankel, Sheila E. Subject: [ipsecme] #111: Can IKEv1 negotiate combined algorithms to be used= by IPsec-v3? #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3? -----------------------------------+---------------------------------------= - Reporter: paul.hoffman@=85 | Owner: sheila.frankel@=85 Type: defect | Status: new Priority: normal | Milestone: Component: roadmap | Severity: - Keywords: | -----------------------------------+---------------------------------------= - Section 5.4 says: IKEv1 and ESP-v2 use separate algorithms to provide encryption and integrity-protection, and IKEv1 can negotiate different combinations of algorithms for different SAs. In ESP-v3, a new class of algorithms was introduced, in which a single algorithm can provide both encryption and integrity-protection. [RFC4306] describes how IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to negotiate and use combined mode algorithms for its own traffic. When properly designed, these algorithms can provide increased efficiency in both implementation and execution. What about IKEv1? Can you use IKEv1 to negotiate a combined algorithm for IPsec-v3? -- Ticket URL: ipsecme From sheila.frankel@nist.gov Tue Oct 27 08:45:55 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5270428C0F0 for ; Tue, 27 Oct 2009 08:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 dR58XB398K8d for ; Tue, 27 Oct 2009 08:45:54 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 0B8C028C0D6 for ; Tue, 27 Oct 2009 08:45:53 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9RFjm5O026636; Tue, 27 Oct 2009 11:45:48 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Tue, 27 Oct 2009 11:45:44 -0400 From: "Frankel, Sheila E." To: "ipsec@ietf.org" Date: Tue, 27 Oct 2009 11:43:56 -0400 Thread-Topic: [ipsecme] #112: Truncation of SHA-1 ICVs Thread-Index: AcpOwGbAVkrZyzZSQZGKZLAJ1o3RqgIW+ROR Message-ID: References: <063.b5b9a33677a51644c2c934555b3fe9c6@tools.ietf.org> In-Reply-To: <063.b5b9a33677a51644c2c934555b3fe9c6@tools.ietf.org> 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 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: Tero Kivinen , Paul Hoffman , "suresh.krishnan@ericsson.com" Subject: Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:45:55 -0000 #112: Truncation of SHA-1 ICVs Proposed change to Roadmap doc: Add text to Section 5.3 (Integrity-Protection Algorithms) Current text: The integrity-protection algorithm RFCs describe how to use these algorithms to authenticate IKE and/or IPsec traffic, providing integrity protection to the traffic. This protection is provided by computing an Integrity Check Value (ICV), which is sent in the packet. The RFCs describe any special constraints, requirements, or changes to packet format appropriate for the specific algorithm. In general, they do not describe the detailed algorithmic computations; the reference section of each RFC includes pointers to documents that define the inner workings of the algorithm. Some of the RFCs include sample test data, to enable implementors to compare their results with standardized output. Additional text: Some of these algorithms generate a fixed-length ICV, which is truncated= =20 when it is included in an IPsec-protected packet. For example, standard= =20 HMAC-SHA-1 generates a 160-bit ICV, which is truncated to 96 bits when i= t=20 is used to provide integrity-protection to an ESP or AH packet. The=20 individual RFC descriptions mention those algorithms that are truncated.= =20 When these algorithms are used to protect IKEv1 SAs, they are not=20 truncated. For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry contains= =20 values for both the truncated version and the standard non-truncated=20 version; thus, IKEv2 has the capability to negotiate either version to=20 protect IKEv2 and/or IPsec-v3 SAs. For the other algorithms (AES-XCBC,= =20 HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD), only the truncated=20 version can be used for both IKEv2 and IPsec-v3 SAs. =20 NOTE to Tero, Paul, Yaron: do we want to expand the IKEv2 IANA registry to = include non-truncated AES-XCBC-MAC, HMAC-SHA-256/384/512, AES-CMAC and HMAC= -RIPEMD? ________________________________________ From: ipsecme issue tracker [trac@tools.ietf.org] Sent: Friday, October 16, 2009 8:25 PM To: paul.hoffman@vpnc.org; Frankel, Sheila E. Subject: [ipsecme] #112: Truncation of SHA-1 ICVs #112: Truncation of SHA-1 ICVs -----------------------------------+---------------------------------------= - Reporter: paul.hoffman@=85 | Owner: sheila.frankel@=85 Type: defect | Status: new Priority: normal | Milestone: Component: roadmap | Severity: - Keywords: | -----------------------------------+---------------------------------------= - In RFC 2404, it mentions that SHA-1 ICVs are truncated to 96 bits for IPsec. We should also mention in Section 5.3 that this truncation is done for IKEv2 as well. Same for RFC 2403. Text is needed. -- Ticket URL: ipsecme From sheila.frankel@nist.gov Tue Oct 27 08:47:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E3DA28C0F2 for ; Tue, 27 Oct 2009 08:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 6MPl6ILqjv0N for ; Tue, 27 Oct 2009 08:47:57 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 6E7BA3A69B2 for ; Tue, 27 Oct 2009 08:47:57 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9RFlsYd007879; Tue, 27 Oct 2009 11:47:54 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Tue, 27 Oct 2009 11:47:54 -0400 From: "Frankel, Sheila E." To: "ipsec@ietf.org" Date: Tue, 27 Oct 2009 11:46:18 -0400 Thread-Topic: [ipsecme] #114: Expired drafts, especially BEET Thread-Index: AcpOwOtzy6aVQoZlRb+/3jJLY2VPMwIW7Qkh Message-ID: References: <063.783474ea3d34b716e39da24271b27cac@tools.ietf.org> In-Reply-To: <063.783474ea3d34b716e39da24271b27cac@tools.ietf.org> 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 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: Tero Kivinen , Paul Hoffman , "suresh.krishnan@ericsson.com" Subject: Re: [IPsec] [ipsecme] #114: Expired drafts, especially BEET X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:47:58 -0000 #114: Expired drafts, especially BEET Proposed changes to Roadmap doc: 1) Sheila and Suresh do not advocate the addition of the BEET Internet Draf= t to this doc, so no change is required for that. 2) Add text to the introductory section for IKEv1, Section 4.1.1: Additional text: IKE is the preferred key management protocol for IPsec. It is used for peer= authentication; to negotiate, modify and delete SAs; and to negotiate aut= henticated keying material for use within those SAs. The standard peer aut= hentication methods used by IKEv1 (pre-shared secret keys and digital certi= ficates) had several shortcomings related to use of IKEv1 to enable remote = user authentication to a corporate VPN: it could not leverage the use of le= gacy authentication systems (e.g. RADIUS databases) to authenticate a remot= e user to a security gateway; and it could not be used to configure remote = users with network addresses or other information needed in order to access= the internal network.=20 Two Internet Drafts were written to address these problems: Extended Authen= tication withn IKE (XAUTH) (draft-beaulieu-ike-xauth) and The ISAKMP Config= uration Method (draft-dukes-ike-mode-cfg). These drafts did not progress t= o RFC status due to security flaws and other problems related to these solu= tions. However, many current IKEv1 implementations incorporate aspects of t= hese solutions to facilitate remote user access to corporate VPNs. Since th= ese solutions were not standardized, there is no assurance that the impleme= ntations adhere fully to the suggested solutions, or that one implementatio= n can interoperate with others that claim to incorporate the same features.= Furthermore, these solutions have know security issues. Thus, use of these= solutions is not recommended, and these Internet Drafts are not specified = in this roadmap. ________________________________________ From: ipsecme issue tracker [trac@tools.ietf.org] Sent: Friday, October 16, 2009 8:29 PM To: paul.hoffman@vpnc.org; Frankel, Sheila E. Subject: [ipsecme] #114: Expired drafts, especially BEET #114: Expired drafts, especially BEET -----------------------------------+---------------------------------------= - Reporter: paul.hoffman@=85 | Owner: sheila.frankel@=85 Type: defect | Status: new Priority: normal | Milestone: Component: roadmap | Severity: - Keywords: | -----------------------------------+---------------------------------------= - Sheila would like to see ESP BEET mode referenced, since it's more widely implemented than other docs that are mentioned. However, it is not on track to becoming an RFC. Also, there are some who want to mention other very widely implemented (expired) drafts which will never come out as RFCs, namely IKEv1 configuration mode (draft-dukes-ike-mode-cfg-02) and IKEv1 xauth (draft- beaulieu-ike-xauth-02). RESPONSE: We will mention the expired drafts in the IKEv1 section of the roadmap doc, explaining that many implementations implement these 2 drafts to enable road warrior (user) authentication. The wording will include cautions about their use: security issues, implementation/interoperability problems, etc. Wording is needed. -- Ticket URL: ipsecme From sheila.frankel@nist.gov Tue Oct 27 08:54:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6409E28C1A7 for ; Tue, 27 Oct 2009 08:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 A-qV5-ohI+Rr for ; Tue, 27 Oct 2009 08:54:43 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 517733A6851 for ; Tue, 27 Oct 2009 08:54:43 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9RFna1A029413; Tue, 27 Oct 2009 11:49:36 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Tue, 27 Oct 2009 11:49:36 -0400 From: "Frankel, Sheila E." To: "ipsec@ietf.org" Date: Tue, 27 Oct 2009 11:48:14 -0400 Thread-Topic: [ipsecme] #115: Camellia req levels for IKEv2 Thread-Index: AcpOwQLkzK3hHndfTiuUUrnMhuDXhAIW+HSl Message-ID: References: <063.06d317c6f664560309ce0afcacc220bc@tools.ietf.org> In-Reply-To: <063.06d317c6f664560309ce0afcacc220bc@tools.ietf.org> 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 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: Tero Kivinen , Paul Hoffman , "suresh.krishnan@ericsson.com" Subject: Re: [IPsec] [ipsecme] #115: Camellia req levels for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:54:44 -0000 #115: Camellia req levels for IKEv2 Proposed changes to Roadmap doc: 1) Change IKEv2 requirement level for Camellia-CBC from undefined (no RFC)= =20 to optional 2) Add text to Section 5.2.6 (RFC 4312, The Camellia Cipher Algorithm and I= ts Use with IPsec) Current text: [RFC5529] describes the use of the Camellia block cipher algorithm in conjunction with several different modes of operation. It describes the use of Camellia in Cipher Block Chaining (CBC) mode and Counter (CTR) mode as an encryption algorithm within ESP. It also describes the use of Camellia in Counter with CBC-MAC (CCM) mode as a combined mode algorithm in ESP. This document defines how to use IKEv2 to generate keying material for a Camellia ESP SA; it does not define how to use Camellia within IKEv2 to protect an IKEv2 SA's traffic. Additional text: However, this RFC, in conjunction with IKEv2's generalized description=20 of block mode encryption, provide enough detail to allow the use of Camellia-CBC algorithms within IKEv2. =20 Current text (continued): All three modes can use keys of length 128-bits, 192-bits or 256-bits. [RFC5529] includes IANA values for use in IKEv2 and IPsec-v3. A single IANA value is defined for each Camellia mode, so IKEv2 negotiations need to specify the keysize. ________________________________________ From: ipsecme issue tracker [trac@tools.ietf.org] Sent: Friday, October 16, 2009 8:29 PM To: paul.hoffman@vpnc.org; Frankel, Sheila E. Subject: [ipsecme] #115: Camellia req levels for IKEv2 #115: Camellia req levels for IKEv2 -----------------------------------+---------------------------------------= - Reporter: paul.hoffman@=85 | Owner: sheila.frankel@=85 Type: defect | Status: new Priority: normal | Milestone: Component: roadmap | Severity: - Keywords: | -----------------------------------+---------------------------------------= - Camellia-CBC: covered by generic CBC requirements in RFC4306? Camellia-CTR: needs its own RFC? Camellia-CCM: covered by RFC 5282? -- Ticket URL: ipsecme From smoonen@us.ibm.com Tue Oct 27 09:17:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CAC53A6A2D; Tue, 27 Oct 2009 09:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kORTEuz1sc5C; Tue, 27 Oct 2009 09:17:25 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id DA9D53A6843; Tue, 27 Oct 2009 09:17:24 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e38.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9RGDCPV018476; Tue, 27 Oct 2009 10:13:12 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9RGHR0t059142; Tue, 27 Oct 2009 10:17:28 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9RGG5rv026417; Tue, 27 Oct 2009 10:16:05 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9RGG4Mm026409; Tue, 27 Oct 2009 10:16:04 -0600 In-Reply-To: References: <063.b5b9a33677a51644c2c934555b3fe9c6@tools.ietf.org> To: "Frankel, Sheila E." MIME-Version: 1.0 X-KeepSent: 45C3484B:96202337-8525765C:00579ABF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 10/27/2009 12:07:27 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 10/27/2009 12:07:27 PM, Serialize complete at 10/27/2009 12:07:27 PM, S/MIME Sign failed at 10/27/2009 12:07:27 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1|September 28, 2009) at 10/27/2009 10:17:27, Serialize complete at 10/27/2009 10:17:27 Message-ID: Date: Tue, 27 Oct 2009 12:17:26 -0400 Content-Type: multipart/alternative; boundary="=_alternative 005892EC8525765C_=" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, Paul Hoffman , Tero Kivinen , "suresh.krishnan@ericsson.com" Subject: Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 16:17:26 -0000 This is a multipart message in MIME format. --=_alternative 005892EC8525765C_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgU2hlaWxhLA0KDQoxKSBJIGRvbid0IHRoaW5rIHdlIGNhbiBleHBhbmQgdGhlIHJlZ2lzdHJ5 IHRvIGluY2x1ZGUgbm9uLXRydW5jYXRlZCANCnZlcnNpb25zIG9mIEhNQUMtU0hBMi0qLiAgUkZD IDQ4Njggc3RpcHVsYXRlcyBmb3IgSUtFIGFuZCBJUHNlYyBpbiBnZW5lcmFsIA0KdGhhdCB0aGUg YXV0aGVudGljYXRvciBsZW5ndGggImlzIGFsd2F5cyBoYWxmIHRoZSBvdXRwdXQgbGVuZ3RoIG9m IHRoZSANCnVuZGVybHlpbmcgaGFzaCBhbGdvcml0aG0uIg0KDQoyKSBSRkNzIDM1NjYsIDQ0OTQg YXJlIHdvcmRlZCBhIGJpdCBtb3JlIHBlcm1pc3NpdmVseSBmb3IgQUVTLVhDQkMgYW5kIA0KQUVT LUNNQUMsIHNvIHBlcmhhcHMgdGhlcmUncyBzb21lIHdpZ2dsZSByb29tIHRoZXJlLg0KDQozKSBJ J20gbm90IHN1cmUgaWYgSE1BQy1SSVBFTUQgaXMgZGVmaW5lZCBmb3IgdXNlIGluIElLRSAodGhl cmUgaXMgbm90IA0KZXZlbiBhbiBhbGdvcml0aG0gaWRlbnRpZmllciBmb3IgSUtFdjIpLCBidXQg aXRzIHVzZSBmb3IgQUggYW5kIEVTUCAoUkZDIA0KMjg1NykgY3VycmVudGx5IG9ubHkgZGVmaW5l cyBhIHRydW5jYXRlZCBmb3JtIG9mIHRoZSBhbGdvcml0aG0uDQoNCg0KU2NvdHQgTW9vbmVuIChz bW9vbmVuQHVzLmlibS5jb20pDQp6L09TIENvbW11bmljYXRpb25zIFNlcnZlciBUQ1AvSVAgRGV2 ZWxvcG1lbnQNCmh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL3Ntb29uZW4NCg0KDQoNCkZyb206 DQoiRnJhbmtlbCwgU2hlaWxhIEUuIiA8c2hlaWxhLmZyYW5rZWxAbmlzdC5nb3Y+DQpUbzoNCiJp cHNlY0BpZXRmLm9yZyIgPGlwc2VjQGlldGYub3JnPg0KQ2M6DQpUZXJvIEtpdmluZW4gPGtpdmlu ZW5AaWtpLmZpPiwgUGF1bCBIb2ZmbWFuIDxwYXVsLmhvZmZtYW5AdnBuYy5vcmc+LCANCiJzdXJl c2gua3Jpc2huYW5AZXJpY3Nzb24uY29tIiA8c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbT4N CkRhdGU6DQoxMC8yNy8yMDA5IDExOjQ2IEFNDQpTdWJqZWN0Og0KUmU6IFtJUHNlY10gW2lwc2Vj bWVdICMxMTI6IFRydW5jYXRpb24gb2YgU0hBLTEgSUNWcw0KDQoNCg0KDQojMTEyOiBUcnVuY2F0 aW9uIG9mIFNIQS0xIElDVnMNCg0KUHJvcG9zZWQgY2hhbmdlIHRvIFJvYWRtYXAgZG9jOg0KDQpB ZGQgdGV4dCB0byBTZWN0aW9uIDUuMyAoSW50ZWdyaXR5LVByb3RlY3Rpb24gQWxnb3JpdGhtcykN Cg0KQ3VycmVudCB0ZXh0Og0KICAgVGhlIGludGVncml0eS1wcm90ZWN0aW9uIGFsZ29yaXRobSBS RkNzIGRlc2NyaWJlIGhvdyB0byB1c2UgdGhlc2UNCiAgIGFsZ29yaXRobXMgdG8gYXV0aGVudGlj YXRlIElLRSBhbmQvb3IgSVBzZWMgdHJhZmZpYywgcHJvdmlkaW5nDQogICBpbnRlZ3JpdHkgcHJv dGVjdGlvbiB0byB0aGUgdHJhZmZpYy4gIFRoaXMgcHJvdGVjdGlvbiBpcyBwcm92aWRlZCBieQ0K ICAgY29tcHV0aW5nIGFuIEludGVncml0eSBDaGVjayBWYWx1ZSAoSUNWKSwgd2hpY2ggaXMgc2Vu dCBpbiB0aGUNCiAgIHBhY2tldC4gIFRoZSBSRkNzIGRlc2NyaWJlIGFueSBzcGVjaWFsIGNvbnN0 cmFpbnRzLCByZXF1aXJlbWVudHMsIG9yDQogICBjaGFuZ2VzIHRvIHBhY2tldCBmb3JtYXQgYXBw cm9wcmlhdGUgZm9yIHRoZSBzcGVjaWZpYyBhbGdvcml0aG0uICBJbg0KICAgZ2VuZXJhbCwgdGhl eSBkbyBub3QgZGVzY3JpYmUgdGhlIGRldGFpbGVkIGFsZ29yaXRobWljIGNvbXB1dGF0aW9uczsN CiAgIHRoZSByZWZlcmVuY2Ugc2VjdGlvbiBvZiBlYWNoIFJGQyBpbmNsdWRlcyBwb2ludGVycyB0 byBkb2N1bWVudHMgdGhhdA0KICAgZGVmaW5lIHRoZSBpbm5lciB3b3JraW5ncyBvZiB0aGUgYWxn b3JpdGhtLiAgU29tZSBvZiB0aGUgUkZDcyBpbmNsdWRlDQogICBzYW1wbGUgdGVzdCBkYXRhLCB0 byBlbmFibGUgaW1wbGVtZW50b3JzIHRvIGNvbXBhcmUgdGhlaXIgcmVzdWx0cw0KICAgd2l0aCBz dGFuZGFyZGl6ZWQgb3V0cHV0Lg0KDQpBZGRpdGlvbmFsIHRleHQ6DQogICBTb21lIG9mIHRoZXNl IGFsZ29yaXRobXMgZ2VuZXJhdGUgYSBmaXhlZC1sZW5ndGggSUNWLCB3aGljaCBpcyANCnRydW5j YXRlZCANCiAgIHdoZW4gaXQgaXMgaW5jbHVkZWQgaW4gYW4gSVBzZWMtcHJvdGVjdGVkIHBhY2tl dC4gRm9yIGV4YW1wbGUsIHN0YW5kYXJkIA0KDQogICBITUFDLVNIQS0xIGdlbmVyYXRlcyBhIDE2 MC1iaXQgSUNWLCB3aGljaCBpcyB0cnVuY2F0ZWQgdG8gOTYgYml0cyB3aGVuIA0KaXQgDQogICBp cyB1c2VkIHRvIHByb3ZpZGUgaW50ZWdyaXR5LXByb3RlY3Rpb24gdG8gYW4gRVNQIG9yIEFIIHBh Y2tldC4gVGhlIA0KICAgaW5kaXZpZHVhbCBSRkMgZGVzY3JpcHRpb25zIG1lbnRpb24gdGhvc2Ug YWxnb3JpdGhtcyB0aGF0IGFyZSANCnRydW5jYXRlZC4gDQogICBXaGVuIHRoZXNlIGFsZ29yaXRo bXMgYXJlIHVzZWQgdG8gcHJvdGVjdCBJS0V2MSBTQXMsIHRoZXkgYXJlIG5vdCANCiAgIHRydW5j YXRlZC4gRm9yIEhNQUMtU0hBLTEgYW5kIEhNQUMtTUQ1LCB0aGUgSUtFdjIgSUFOQSByZWdpc3Ry eSANCmNvbnRhaW5zIA0KICAgdmFsdWVzIGZvciBib3RoIHRoZSB0cnVuY2F0ZWQgdmVyc2lvbiBh bmQgdGhlIHN0YW5kYXJkIG5vbi10cnVuY2F0ZWQgDQogICB2ZXJzaW9uOyB0aHVzLCBJS0V2MiBo YXMgdGhlIGNhcGFiaWxpdHkgdG8gbmVnb3RpYXRlIGVpdGhlciB2ZXJzaW9uIHRvIA0KICAgcHJv dGVjdCBJS0V2MiBhbmQvb3IgSVBzZWMtdjMgU0FzLiAgRm9yIHRoZSBvdGhlciBhbGdvcml0aG1z IChBRVMtWENCQywgDQoNCiAgIEhNQUMtU0hBLTI1Ni8zODQvNTEyLCBBRVMtQ01BQyBhbmQgSE1B Qy1SSVBFTUQpLCBvbmx5IHRoZSB0cnVuY2F0ZWQgDQogICB2ZXJzaW9uIGNhbiBiZSB1c2VkIGZv ciBib3RoIElLRXYyIGFuZCBJUHNlYy12MyBTQXMuDQogDQpOT1RFIHRvIFRlcm8sIFBhdWwsIFlh cm9uOiBkbyB3ZSB3YW50IHRvIGV4cGFuZCB0aGUgSUtFdjIgSUFOQSByZWdpc3RyeSB0byANCmlu Y2x1ZGUgbm9uLXRydW5jYXRlZCBBRVMtWENCQy1NQUMsIEhNQUMtU0hBLTI1Ni8zODQvNTEyLCBB RVMtQ01BQyBhbmQgDQpITUFDLVJJUEVNRD8NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tOiBpcHNlY21lIGlzc3VlIHRyYWNrZXIgW3RyYWNAdG9vbHMu aWV0Zi5vcmddDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMDkgODoyNSBQTQ0KVG86IHBh dWwuaG9mZm1hbkB2cG5jLm9yZzsgRnJhbmtlbCwgU2hlaWxhIEUuDQpTdWJqZWN0OiBbaXBzZWNt ZV0gIzExMjogVHJ1bmNhdGlvbiBvZiBTSEEtMSBJQ1ZzDQoNCiMxMTI6IFRydW5jYXRpb24gb2Yg U0hBLTEgSUNWcw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAgcGF1bC5ob2ZmbWFu QOKApiAgICAgICAgIHwgICAgICAgT3duZXI6ICBzaGVpbGEuZnJhbmtlbEDigKYNCiAgICAgVHlw ZTogIGRlZmVjdCAgICAgICAgICAgICAgICAgfCAgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5 OiAgbm9ybWFsICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOg0KQ29tcG9uZW50OiAgcm9h ZG1hcCAgICAgICAgICAgICAgICB8ICAgIFNldmVyaXR5OiAgLQ0KIEtleXdvcmRzOiAgICAgICAg ICAgICAgICAgICAgICAgICB8DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogSW4gUkZDIDI0MDQsIGl0 IG1lbnRpb25zIHRoYXQgU0hBLTEgSUNWcyBhcmUgdHJ1bmNhdGVkIHRvIDk2IGJpdHMgZm9yDQog SVBzZWMuICBXZSBzaG91bGQgYWxzbyBtZW50aW9uIGluIFNlY3Rpb24gNS4zIHRoYXQgdGhpcyB0 cnVuY2F0aW9uIGlzIA0KZG9uZQ0KIGZvciBJS0V2MiBhcyB3ZWxsLiBTYW1lIGZvciBSRkMgMjQw My4gVGV4dCBpcyBuZWVkZWQuDQoNCi0tDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvd2cvaXBzZWNtZS90cmFjL3RpY2tldC8xMTI+DQppcHNlY21lIDxodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaXBzZWNtZS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpJUHNlYyBtYWlsaW5nIGxpc3QNCklQc2VjQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQoNCg0KDQo= --=_alternative 005892EC8525765C_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFNoZWlsYSw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEpIEkgZG9uJ3QgdGhpbmsg d2UgY2FuIGV4cGFuZCB0aGUgcmVnaXN0cnkNCnRvIGluY2x1ZGUgbm9uLXRydW5jYXRlZCB2ZXJz aW9ucyBvZiBITUFDLVNIQTItKi4gJm5ic3A7UkZDIDQ4Njggc3RpcHVsYXRlcw0KZm9yIElLRSBh bmQgSVBzZWMgaW4gZ2VuZXJhbCB0aGF0IHRoZSBhdXRoZW50aWNhdG9yIGxlbmd0aCAmcXVvdDtp cyBhbHdheXMNCmhhbGYgdGhlIG91dHB1dCBsZW5ndGggb2YgdGhlIHVuZGVybHlpbmcgaGFzaCBh bGdvcml0aG0uJnF1b3Q7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4yKSBSRkNzIDM1NjYsIDQ0OTQgYXJlIHdvcmRlZCBhIGJpdA0KbW9yZSBwZXJtaXNz aXZlbHkgZm9yIEFFUy1YQ0JDIGFuZCBBRVMtQ01BQywgc28gcGVyaGFwcyB0aGVyZSdzIHNvbWUg d2lnZ2xlDQpyb29tIHRoZXJlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+MykgSSdtIG5vdCBzdXJlIGlmIEhNQUMtUklQRU1EIGlzIGRlZmluZWQNCmZv ciB1c2UgaW4gSUtFICh0aGVyZSBpcyBub3QgZXZlbiBhbiBhbGdvcml0aG0gaWRlbnRpZmllciBm b3IgSUtFdjIpLCBidXQNCml0cyB1c2UgZm9yIEFIIGFuZCBFU1AgKFJGQyAyODU3KSBjdXJyZW50 bHkgb25seSBkZWZpbmVzIGEgdHJ1bmNhdGVkIGZvcm0NCm9mIHRoZSBhbGdvcml0aG0uPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpTY290dCBN b29uZW4gKHNtb29uZW5AdXMuaWJtLmNvbSk8YnI+DQp6L09TIENvbW11bmljYXRpb25zIFNlcnZl ciBUQ1AvSVAgRGV2ZWxvcG1lbnQ8YnI+DQo8L2ZvbnQ+PGEgaHJlZj1odHRwOi8vd3d3Lmxpbmtl ZGluLmNvbS9pbi9zbW9vbmVuPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8v d3d3LmxpbmtlZGluLmNvbS9pbi9zbW9vbmVuPC9mb250PjwvYT4NCjxicj4NCjxicj4NCjxicj4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQgc2l6ZT0xIGNv bG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RnJvbTo8L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O0ZyYW5rZWwsIFNoZWlsYSBFLiZxdW90OyAmbHQ7 c2hlaWxhLmZyYW5rZWxAbmlzdC5nb3YmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+VG86PC9mb250Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtpcHNlY0BpZXRmLm9yZyZx dW90OyAmbHQ7aXBzZWNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyPg0KPHRkIHZhbGlnbj10b3A+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+Q2M6PC9mb250Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5UZXJvIEtpdmluZW4gJmx0O2tpdmlu ZW5AaWtpLmZpJmd0OywNClBhdWwgSG9mZm1hbiAmbHQ7cGF1bC5ob2ZmbWFuQHZwbmMub3JnJmd0 OywgJnF1b3Q7c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbSZxdW90Ow0KJmx0O3N1cmVzaC5r cmlzaG5hbkBlcmljc3Nvbi5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PGZv bnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RGF0ZTo8L2ZvbnQ+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjEwLzI3LzIwMDkgMTE6NDYgQU08L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNl PSJzYW5zLXNlcmlmIj5TdWJqZWN0OjwvZm9udD4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+UmU6IFtJUHNlY10gW2lwc2VjbWVdICMxMTI6IFRydW5jYXRpb24NCm9mIFNIQS0x IElDVnM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxociBub3NoYWRlPg0KPGJyPg0KPGJyPg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+PGJyPg0KIzExMjogVHJ1bmNhdGlvbiBvZiBTSEEtMSBJQ1ZzPGJy Pg0KPGJyPg0KUHJvcG9zZWQgY2hhbmdlIHRvIFJvYWRtYXAgZG9jOjxicj4NCjxicj4NCkFkZCB0 ZXh0IHRvIFNlY3Rpb24gNS4zIChJbnRlZ3JpdHktUHJvdGVjdGlvbiBBbGdvcml0aG1zKTxicj4N Cjxicj4NCkN1cnJlbnQgdGV4dDo8YnI+DQogJm5ic3A7IFRoZSBpbnRlZ3JpdHktcHJvdGVjdGlv biBhbGdvcml0aG0gUkZDcyBkZXNjcmliZSBob3cgdG8gdXNlIHRoZXNlPGJyPg0KICZuYnNwOyBh bGdvcml0aG1zIHRvIGF1dGhlbnRpY2F0ZSBJS0UgYW5kL29yIElQc2VjIHRyYWZmaWMsIHByb3Zp ZGluZzxicj4NCiAmbmJzcDsgaW50ZWdyaXR5IHByb3RlY3Rpb24gdG8gdGhlIHRyYWZmaWMuICZu YnNwO1RoaXMgcHJvdGVjdGlvbiBpcyBwcm92aWRlZA0KYnk8YnI+DQogJm5ic3A7IGNvbXB1dGlu ZyBhbiBJbnRlZ3JpdHkgQ2hlY2sgVmFsdWUgKElDViksIHdoaWNoIGlzIHNlbnQgaW4gdGhlPGJy Pg0KICZuYnNwOyBwYWNrZXQuICZuYnNwO1RoZSBSRkNzIGRlc2NyaWJlIGFueSBzcGVjaWFsIGNv bnN0cmFpbnRzLCByZXF1aXJlbWVudHMsDQpvcjxicj4NCiAmbmJzcDsgY2hhbmdlcyB0byBwYWNr ZXQgZm9ybWF0IGFwcHJvcHJpYXRlIGZvciB0aGUgc3BlY2lmaWMgYWxnb3JpdGhtLg0KJm5ic3A7 SW48YnI+DQogJm5ic3A7IGdlbmVyYWwsIHRoZXkgZG8gbm90IGRlc2NyaWJlIHRoZSBkZXRhaWxl ZCBhbGdvcml0aG1pYyBjb21wdXRhdGlvbnM7PGJyPg0KICZuYnNwOyB0aGUgcmVmZXJlbmNlIHNl Y3Rpb24gb2YgZWFjaCBSRkMgaW5jbHVkZXMgcG9pbnRlcnMgdG8gZG9jdW1lbnRzDQp0aGF0PGJy Pg0KICZuYnNwOyBkZWZpbmUgdGhlIGlubmVyIHdvcmtpbmdzIG9mIHRoZSBhbGdvcml0aG0uICZu YnNwO1NvbWUgb2YgdGhlIFJGQ3MNCmluY2x1ZGU8YnI+DQogJm5ic3A7IHNhbXBsZSB0ZXN0IGRh dGEsIHRvIGVuYWJsZSBpbXBsZW1lbnRvcnMgdG8gY29tcGFyZSB0aGVpciByZXN1bHRzPGJyPg0K ICZuYnNwOyB3aXRoIHN0YW5kYXJkaXplZCBvdXRwdXQuPGJyPg0KPGJyPg0KQWRkaXRpb25hbCB0 ZXh0Ojxicj4NCiAmbmJzcDsgU29tZSBvZiB0aGVzZSBhbGdvcml0aG1zIGdlbmVyYXRlIGEgZml4 ZWQtbGVuZ3RoIElDViwgd2hpY2ggaXMNCnRydW5jYXRlZCA8YnI+DQogJm5ic3A7IHdoZW4gaXQg aXMgaW5jbHVkZWQgaW4gYW4gSVBzZWMtcHJvdGVjdGVkIHBhY2tldC4gRm9yIGV4YW1wbGUsDQpz dGFuZGFyZCA8YnI+DQogJm5ic3A7IEhNQUMtU0hBLTEgZ2VuZXJhdGVzIGEgMTYwLWJpdCBJQ1Ys IHdoaWNoIGlzIHRydW5jYXRlZCB0byA5NiBiaXRzDQp3aGVuIGl0IDxicj4NCiAmbmJzcDsgaXMg dXNlZCB0byBwcm92aWRlIGludGVncml0eS1wcm90ZWN0aW9uIHRvIGFuIEVTUCBvciBBSCBwYWNr ZXQuDQpUaGUgPGJyPg0KICZuYnNwOyBpbmRpdmlkdWFsIFJGQyBkZXNjcmlwdGlvbnMgbWVudGlv biB0aG9zZSBhbGdvcml0aG1zIHRoYXQgYXJlIHRydW5jYXRlZC4NCjxicj4NCiAmbmJzcDsgV2hl biB0aGVzZSBhbGdvcml0aG1zIGFyZSB1c2VkIHRvIHByb3RlY3QgSUtFdjEgU0FzLCB0aGV5IGFy ZSBub3QNCjxicj4NCiAmbmJzcDsgdHJ1bmNhdGVkLiBGb3IgSE1BQy1TSEEtMSBhbmQgSE1BQy1N RDUsIHRoZSBJS0V2MiBJQU5BIHJlZ2lzdHJ5DQpjb250YWlucyA8YnI+DQogJm5ic3A7IHZhbHVl cyBmb3IgYm90aCB0aGUgdHJ1bmNhdGVkIHZlcnNpb24gYW5kIHRoZSBzdGFuZGFyZCBub24tdHJ1 bmNhdGVkDQo8YnI+DQogJm5ic3A7IHZlcnNpb247IHRodXMsIElLRXYyIGhhcyB0aGUgY2FwYWJp bGl0eSB0byBuZWdvdGlhdGUgZWl0aGVyIHZlcnNpb24NCnRvIDxicj4NCiAmbmJzcDsgcHJvdGVj dCBJS0V2MiBhbmQvb3IgSVBzZWMtdjMgU0FzLiAmbmJzcDtGb3IgdGhlIG90aGVyIGFsZ29yaXRo bXMNCihBRVMtWENCQywgPGJyPg0KICZuYnNwOyBITUFDLVNIQS0yNTYvMzg0LzUxMiwgQUVTLUNN QUMgYW5kIEhNQUMtUklQRU1EKSwgb25seSB0aGUgdHJ1bmNhdGVkDQo8YnI+DQogJm5ic3A7IHZl cnNpb24gY2FuIGJlIHVzZWQgZm9yIGJvdGggSUtFdjIgYW5kIElQc2VjLXYzIFNBcy48YnI+DQog PGJyPg0KTk9URSB0byBUZXJvLCBQYXVsLCBZYXJvbjogZG8gd2Ugd2FudCB0byBleHBhbmQgdGhl IElLRXYyIElBTkEgcmVnaXN0cnkNCnRvIGluY2x1ZGUgbm9uLXRydW5jYXRlZCBBRVMtWENCQy1N QUMsIEhNQUMtU0hBLTI1Ni8zODQvNTEyLCBBRVMtQ01BQyBhbmQNCkhNQUMtUklQRU1EPzxicj4N Cjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpGcm9tOiBpcHNlY21lIGlzc3VlIHRyYWNrZXIgW3RyYWNAdG9vbHMuaWV0Zi5vcmddPGJyPg0K U2VudDogRnJpZGF5LCBPY3RvYmVyIDE2LCAyMDA5IDg6MjUgUE08YnI+DQpUbzogcGF1bC5ob2Zm bWFuQHZwbmMub3JnOyBGcmFua2VsLCBTaGVpbGEgRS48YnI+DQpTdWJqZWN0OiBbaXBzZWNtZV0g IzExMjogVHJ1bmNhdGlvbiBvZiBTSEEtMSBJQ1ZzPGJyPg0KPGJyPg0KIzExMjogVHJ1bmNhdGlv biBvZiBTSEEtMSBJQ1ZzPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiBSZXBvcnRlcjog Jm5ic3A7cGF1bC5ob2ZmbWFuQOKApiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJz cDsgJm5ic3A7DQombmJzcDsgT3duZXI6ICZuYnNwO3NoZWlsYS5mcmFua2VsQOKApjxicj4NCiAm bmJzcDsgJm5ic3A7IFR5cGU6ICZuYnNwO2RlZmVjdCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7U3Rh dHVzOiAmbmJzcDtuZXc8YnI+DQogUHJpb3JpdHk6ICZuYnNwO25vcm1hbCAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyB8ICZuYnNwOyBNaWxl c3RvbmU6PGJyPg0KQ29tcG9uZW50OiAmbmJzcDtyb2FkbWFwICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7fCAmbmJzcDsgJm5ic3A7U2V2ZXJp dHk6ICZuYnNwOy08YnI+DQogS2V5d29yZHM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyB8 PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiBJbiBSRkMgMjQwNCwgaXQgbWVudGlvbnMg dGhhdCBTSEEtMSBJQ1ZzIGFyZSB0cnVuY2F0ZWQgdG8gOTYgYml0cyBmb3I8YnI+DQogSVBzZWMu ICZuYnNwO1dlIHNob3VsZCBhbHNvIG1lbnRpb24gaW4gU2VjdGlvbiA1LjMgdGhhdCB0aGlzIHRy dW5jYXRpb24NCmlzIGRvbmU8YnI+DQogZm9yIElLRXYyIGFzIHdlbGwuIFNhbWUgZm9yIFJGQyAy NDAzLiBUZXh0IGlzIG5lZWRlZC48YnI+DQo8YnI+DQotLTxicj4NClRpY2tldCBVUkw6ICZsdDs8 L2ZvbnQ+PC90dD48YSBocmVmPWh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2lwc2VjbWUv dHJhYy90aWNrZXQvMTEyPjx0dD48Zm9udCBzaXplPTI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvd2cvaXBzZWNtZS90cmFjL3RpY2tldC8xMTI8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7PGJyPg0KaXBzZWNtZSAmbHQ7PC9mb250PjwvdHQ+PGEgaHJlZj1odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaXBzZWNtZS8+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vdG9vbHMuaWV0Zi5v cmcvaXBzZWNtZS88L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7PGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJ UHNlYyBtYWlsaW5nIGxpc3Q8YnI+DQpJUHNlY0BpZXRmLm9yZzxicj4NCjwvZm9udD48L3R0Pjxh IGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYz48dHQ+PGZv bnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM8L2Zv bnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj4NCg== --=_alternative 005892EC8525765C_=-- From yaronf@checkpoint.com Tue Oct 27 09:19:46 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 784303A6917 for ; Tue, 27 Oct 2009 09:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, 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 pDOes1+r+JIV for ; Tue, 27 Oct 2009 09:19:45 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 112573A6990 for ; Tue, 27 Oct 2009 09:19:24 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9RGA5i4003993; Tue, 27 Oct 2009 18:19:36 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 27 Oct 2009 18:13:49 +0200 From: Yaron Sheffer To: "Frankel, Sheila E." , "ipsec@ietf.org" Date: Tue, 27 Oct 2009 18:13:48 +0200 Thread-Topic: [ipsecme] #114: Expired drafts, especially BEET Thread-Index: AcpOwOtzy6aVQoZlRb+/3jJLY2VPMwIW7QkhAACc0RA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213B2C@il-ex01.ad.checkpoint.com> References: <063.783474ea3d34b716e39da24271b27cac@tools.ietf.org> In-Reply-To: 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: Paul Hoffman , Tero Kivinen , "suresh.krishnan@ericsson.com" Subject: Re: [IPsec] [ipsecme] #114: Expired drafts, especially BEET X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 16:19:46 -0000 I'm OK with this text. Typo: know =3D> known in the last sentence. Yaron > -----Original Message----- > From: Frankel, Sheila E. [mailto:sheila.frankel@nist.gov] > Sent: Tuesday, October 27, 2009 17:46 > To: ipsec@ietf.org > Cc: Paul Hoffman; Yaron Sheffer; suresh.krishnan@ericsson.com; Tero > Kivinen > Subject: RE: [ipsecme] #114: Expired drafts, especially BEET >=20 >=20 > #114: Expired drafts, especially BEET >=20 > Proposed changes to Roadmap doc: >=20 > 1) Sheila and Suresh do not advocate the addition of the BEET Internet > Draft to this doc, so no change is required for that. >=20 > 2) Add text to the introductory section for IKEv1, Section 4.1.1: >=20 > Additional text: >=20 > IKE is the preferred key management protocol for IPsec. It is used for > peer authentication; to negotiate, modify and delete SAs; and to > negotiate authenticated keying material for use within those SAs. The > standard peer authentication methods used by IKEv1 (pre-shared secret key= s > and digital certificates) had several shortcomings related to use of IKEv= 1 > to enable remote user authentication to a corporate VPN: it could not > leverage the use of legacy authentication systems (e.g. RADIUS databases) > to authenticate a remote user to a security gateway; and it could not be > used to configure remote users with network addresses or other informatio= n > needed in order to access the internal network. >=20 > Two Internet Drafts were written to address these problems: Extended > Authentication withn IKE (XAUTH) (draft-beaulieu-ike-xauth) and The ISAKM= P > Configuration Method (draft-dukes-ike-mode-cfg). These drafts did not > progress to RFC status due to security flaws and other problems related t= o > these solutions. However, many current IKEv1 implementations incorporate > aspects of these solutions to facilitate remote user access to corporate > VPNs. Since these solutions were not standardized, there is no assurance > that the implementations adhere fully to the suggested solutions, or that > one implementation can interoperate with others that claim to incorporate > the same features. Furthermore, these solutions have know security issues= . > Thus, use of these solutions is not recommended, and these Internet Draft= s > are not specified in this roadmap. > ________________________________________ > From: ipsecme issue tracker [trac@tools.ietf.org] > Sent: Friday, October 16, 2009 8:29 PM > To: paul.hoffman@vpnc.org; Frankel, Sheila E. > Subject: [ipsecme] #114: Expired drafts, especially BEET >=20 > #114: Expired drafts, especially BEET > -----------------------------------+-------------------------------------= - > -- > Reporter: paul.hoffman@... | Owner: sheila.frankel@... > Type: defect | Status: new > Priority: normal | Milestone: > Component: roadmap | Severity: - > Keywords: | > -----------------------------------+-------------------------------------= - > -- > Sheila would like to see ESP BEET mode referenced, since it's more widel= y > implemented than other docs that are mentioned. However, it is not on > track to becoming an RFC. >=20 > Also, there are some who want to mention other very widely implemented > (expired) drafts which will never come out as RFCs, namely IKEv1 > configuration mode (draft-dukes-ike-mode-cfg-02) and IKEv1 xauth (draft- > beaulieu-ike-xauth-02). >=20 > RESPONSE: We will mention the expired drafts in the IKEv1 section of the > roadmap doc, explaining that many implementations implement these 2 > drafts > to enable road warrior (user) authentication. The wording will include > cautions about their use: security issues, > implementation/interoperability > problems, etc. >=20 > Wording is needed. >=20 > -- > Ticket URL: > ipsecme >=20 >=20 > Scanned by Check Point Total Security Gateway. From sheila.frankel@nist.gov Tue Oct 27 10:30:50 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9E13A683E for ; Tue, 27 Oct 2009 10:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SCFArVBFB1W0 for ; Tue, 27 Oct 2009 10:30:41 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id E43593A672E for ; Tue, 27 Oct 2009 10:30:40 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9RHUkcd018674; Tue, 27 Oct 2009 13:30:46 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Tue, 27 Oct 2009 13:30:42 -0400 From: "Frankel, Sheila E." To: Scott C Moonen , "ipsec@ietf.org" Date: Tue, 27 Oct 2009 13:30:45 -0400 Thread-Topic: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs Thread-Index: AcpXIR1NlLMFSmRQTCaItsJRrvu/0AACRveA Message-ID: References: <063.b5b9a33677a51644c2c934555b3fe9c6@tools.ietf.org> In-Reply-To: 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_D7A0423E5E193F40BE6E94126930C493078A58CC62MBCLUSTERxcha_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Subject: Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 17:30:50 -0000 --_000_D7A0423E5E193F40BE6E94126930C493078A58CC62MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Scott. So is the general consensus that we should just leave HMAC-S= HA-1 and HMAC-MD5 as the only algs for which IKEv2 can negotiate either a t= runcated or non-truncated version? Your comment also reminded me that RFCs 2404 (HMAC-SHA-1) and 2403 (HMAC-MD= 5) require truncated ICVs for IPsec. So I guess I should change the new tex= t to only allow IKEv2 to use both versions for its own SAs, but not for IPs= ec SAs. Sheila ________________________________ From: Scott C Moonen [mailto:smoonen@us.ibm.com] Sent: Tuesday, October 27, 2009 12:17 PM To: Frankel, Sheila E. Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; Tero Kivinen; Paul Hoffman; sur= esh.krishnan@ericsson.com Subject: Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs Hi Sheila, 1) I don't think we can expand the registry to include non-truncated versio= ns of HMAC-SHA2-*. RFC 4868 stipulates for IKE and IPsec in general that t= he authenticator length "is always half the output length of the underlying= hash algorithm." 2) RFCs 3566, 4494 are worded a bit more permissively for AES-XCBC and AES-= CMAC, so perhaps there's some wiggle room there. 3) I'm not sure if HMAC-RIPEMD is defined for use in IKE (there is not even= an algorithm identifier for IKEv2), but its use for AH and ESP (RFC 2857) = currently only defines a truncated form of the algorithm. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: "Frankel, Sheila E." To: "ipsec@ietf.org" Cc: Tero Kivinen , Paul Hoffman , "sures= h.krishnan@ericsson.com" Date: 10/27/2009 11:46 AM Subject: Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs ________________________________ #112: Truncation of SHA-1 ICVs Proposed change to Roadmap doc: Add text to Section 5.3 (Integrity-Protection Algorithms) Current text: The integrity-protection algorithm RFCs describe how to use these algorithms to authenticate IKE and/or IPsec traffic, providing integrity protection to the traffic. This protection is provided by computing an Integrity Check Value (ICV), which is sent in the packet. The RFCs describe any special constraints, requirements, or changes to packet format appropriate for the specific algorithm. In general, they do not describe the detailed algorithmic computations; the reference section of each RFC includes pointers to documents that define the inner workings of the algorithm. Some of the RFCs include sample test data, to enable implementors to compare their results with standardized output. Additional text: Some of these algorithms generate a fixed-length ICV, which is truncated when it is included in an IPsec-protected packet. For example, standard HMAC-SHA-1 generates a 160-bit ICV, which is truncated to 96 bits when it is used to provide integrity-protection to an ESP or AH packet. The individual RFC descriptions mention those algorithms that are truncated. When these algorithms are used to protect IKEv1 SAs, they are not truncated. For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry contains values for both the truncated version and the standard non-truncated version; thus, IKEv2 has the capability to negotiate either version to protect IKEv2 and/or IPsec-v3 SAs. For the other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD), only the truncated version can be used for both IKEv2 and IPsec-v3 SAs. NOTE to Tero, Paul, Yaron: do we want to expand the IKEv2 IANA registry to = include non-truncated AES-XCBC-MAC, HMAC-SHA-256/384/512, AES-CMAC and HMAC= -RIPEMD? ________________________________________ From: ipsecme issue tracker [trac@tools.ietf.org] Sent: Friday, October 16, 2009 8:25 PM To: paul.hoffman@vpnc.org; Frankel, Sheila E. Subject: [ipsecme] #112: Truncation of SHA-1 ICVs #112: Truncation of SHA-1 ICVs -----------------------------------+---------------------------------------= - Reporter: paul.hoffman@... | Owner: sheila.frankel@... Type: defect | Status: new Priority: normal | Milestone: Component: roadmap | Severity: - Keywords: | -----------------------------------+---------------------------------------= - In RFC 2404, it mentions that SHA-1 ICVs are truncated to 96 bits for IPsec. We should also mention in Section 5.3 that this truncation is done for IKEv2 as well. Same for RFC 2403. Text is needed. -- Ticket URL: ipsecme _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_D7A0423E5E193F40BE6E94126930C493078A58CC62MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Scott. So is the general conse= nsus that we should just leave HMAC-SHA-1 and HMAC-MD5 as the only algs for whic= h IKEv2 can negotiate either a truncated or non-truncated version?=

 

Your comment also reminded me that RFC= s 2404 (HMAC-SHA-1) and 2403 (HMAC-MD5) require truncated ICVs for IPsec. So = I guess I should change the new text to only allow IKEv2 to use both versions= for its own SAs, but not for IPsec SAs.

 

Sheila

 

From: Scott C = Moonen [mailto:smoonen@us.ibm.com]
Sent: Tuesday, October 27, 2= 009 12:17 PM
To: Frankel, Sheila E.
Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; Tero Kivinen; Paul Hoffman; suresh.krishnan@ericsso= n.com
Subject: Re: [IPsec] [ipsecm= e] #112: Truncation of SHA-1 ICVs

 


Hi Sheila,

1) I don't think we can expand the registry to include non-truncated versions = of HMAC-SHA2-*.  RFC 4868 stipulates for IKE and IPsec in general that th= e authenticator length "is always half the output length of the underlyi= ng hash algorithm."

2) RFCs 3566, 4494 are worded a bit more permissively for AES-XCBC and AES-CMA= C, so perhaps there's some wiggle room there.

3) I'm not sure if HMAC-RIPEMD is defined for use in IKE (there is not even an algorithm identifier for IKEv2), but its use for AH and ESP (RFC 2857) currently only defines a truncated form of the algorithm.

Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
h= ttp://www.linkedin.com/in/smoonen

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>From:

"Frankel, Sheila E." <sheila.frankel@nist.gov>

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>To:=

"ipsec@ietf.org" <ipsec@ietf.org>=

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>Cc:=

Tero Kivinen <kivinen@iki.fi>, Paul Hoffman <paul.hoffman@vpnc.org>, "suresh.krishnan@ericsson.com" <suresh.krishnan@ericsson.com>

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>Date:

10/27/2009 11:46 AM

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>Subject:

Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 I= CVs

 





#112: Truncation of SHA-1 ICVs
Proposed change to Roadmap doc:<= br>
Add text to Section 5.3 (Integrity-Protectio= n Algorithms)

Current text:
  The integrity-protection algorithm RF= Cs describe how to use these
  algorithms to authenticate IKE and/or= IPsec traffic, providing
  integrity protection to the traffic.  This protection is provided by
  computing an Integrity Check Value (I= CV), which is sent in the
  packet.  The RFCs describe any s= pecial constraints, requirements, or
  changes to packet format appropriate = for the specific algorithm.  In
  general, they do not describe the det= ailed algorithmic computations;
  the reference section of each RFC inc= ludes pointers to documents that
  define the inner workings of the algo= rithm.  Some of the RFCs include
  sample test data, to enable implement= ors to compare their results
  with standardized output.=

Additional text:
  Some of these algorithms generate a fixed-length ICV, which is truncated
  when it is included in an IPsec-prote= cted packet. For example, standard
  HMAC-SHA-1 generates a 160-bit ICV, w= hich is truncated to 96 bits when it
  is used to provide integrity-protecti= on to an ESP or AH packet. The
  individual RFC descriptions mention t= hose algorithms that are truncated.
  When these algorithms are used to pro= tect IKEv1 SAs, they are not
  truncated. For HMAC-SHA-1 and HMAC-MD= 5, the IKEv2 IANA registry contains
  values for both the truncated version= and the standard non-truncated
  version; thus, IKEv2 has the capabili= ty to negotiate either version to
  protect IKEv2 and/or IPsec-v3 SAs.  For the other algorithms (AES-XCBC,
  HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD), only the truncated
  version can be used for both IKEv2 an= d IPsec-v3 SAs.

NOTE to Tero, Paul, Yaron: do we want to exp= and the IKEv2 IANA registry to include non-truncated AES-XCBC-MAC, HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD?


________________________________________
From: ipsecme issue tracker [trac@tools.ietf= .org]
Sent: Friday, October 16, 2009 8:25 PM
To: paul.hoffman@vpnc.org; Frankel, Sheila E= .
Subject: [ipsecme] #112: Truncation of SHA-1= ICVs

#112: Truncation of SHA-1 ICVs -----------------------------------+--------= --------------------------------
Reporter:  paul.hoffman@…   =       |       Owner:  sheila.frankel@…
    Type:  defect   &nbs= p;             |      Status:  new
Priority:  normal       =           |   Milestone:
Component:  roadmap      = ;          |    Severity:  -
Keywords:                         |
-----------------------------------+--------= --------------------------------
In RFC 2404, it mentions that SHA-1 ICVs are truncated to 96 bits for
IPsec.  We should also mention in Secti= on 5.3 that this truncation is done
for IKEv2 as well. Same for RFC 2403. Text i= s needed.

--
Ticket URL: <http://trac.tools.iet= f.org/wg/ipsecme/trac/ticket/112><= /font>
ipsecme <http://tools.ietf.org/ipsecme/><= /font>

____________________________________________= ___
IPsec mailing list
IPsec@ietf.org
<= font size=3D2 face=3D"Courier New">https://www.= ietf.org/mailman/listinfo/ipsec

--_000_D7A0423E5E193F40BE6E94126930C493078A58CC62MBCLUSTERxcha_-- From paul.hoffman@vpnc.org Tue Oct 27 13:19:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26DE28C106 for ; Tue, 27 Oct 2009 13:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.679 X-Spam-Level: X-Spam-Status: No, score=-5.679 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 ytRl-VgJugdo for ; Tue, 27 Oct 2009 13:19:36 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id BA4E928C170 for ; Tue, 27 Oct 2009 13:19:28 -0700 (PDT) Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9RKJbHa011527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Oct 2009 13:19:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <063.783474ea3d34b716e39da24271b27cac@tools.ietf.org> Date: Tue, 27 Oct 2009 13:19:35 -0700 To: "Frankel, Sheila E." , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "suresh.krishnan@ericsson.com" , Tero Kivinen Subject: Re: [IPsec] [ipsecme] #114: Expired drafts, especially BEET X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 20:19:37 -0000 At 11:46 AM -0400 10/27/09, Frankel, Sheila E. wrote: >Two Internet Drafts were written to address these problems: Extended Authentication withn IKE (XAUTH) (draft-beaulieu-ike-xauth) and The ISAKMP Configuration Method (draft-dukes-ike-mode-cfg). I would prefer: Many Internet Drafts were written to address these problems in different ways. Two that were adopted by many vendors were Extended Authentication withn IKE (XAUTH) (draft-beaulieu-ike-xauth) and The ISAKMP Configuration Method (draft-dukes-ike-mode-cfg). --Paul Hoffman, Director --VPN Consortium From kivinen@iki.fi Wed Oct 28 04:43:21 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161E228C10D for ; Wed, 28 Oct 2009 04:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] 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 8VW7e6eOmTPg for ; Wed, 28 Oct 2009 04:43:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A9DE228C0FE for ; Wed, 28 Oct 2009 04:43:17 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9SBhPRg012902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 13:43:25 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9SBhOY1012066; Wed, 28 Oct 2009 13:43:24 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19176.11868.510064.595988@fireball.kivinen.iki.fi> Date: Wed, 28 Oct 2009 13:43:24 +0200 From: Tero Kivinen To: "Frankel, Sheila E." In-Reply-To: References: <063.b5b9a33677a51644c2c934555b3fe9c6@tools.ietf.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 10 min Cc: "ipsec@ietf.org" , Paul Hoffman , "suresh.krishnan@ericsson.com" Subject: Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 11:43:21 -0000 Frankel, Sheila E. writes: > Additional text: > Some of these algorithms generate a fixed-length ICV, which is truncated > when it is included in an IPsec-protected packet. For example, standard > HMAC-SHA-1 generates a 160-bit ICV, which is truncated to 96 bits when it > is used to provide integrity-protection to an ESP or AH packet. The > individual RFC descriptions mention those algorithms that are truncated. > When these algorithms are used to protect IKEv1 SAs, they are not > truncated. For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry contains > values for both the truncated version and the standard non-truncated > version; thus, IKEv2 has the capability to negotiate either version to > protect IKEv2 and/or IPsec-v3 SAs. This is not completely correct. The non-truncated versions are not meant to be used with normal IPsec-v2/v3. They are meant to be used with Fibre Channel Security (RFC4595). The AUTH_HMAC_MD5_128 and AUTH_HMAC_MSHA1_160 are really only specified when used with Fibre Channel CT_Authentication format instead of ESP format. Even when using fibre channel if ESP format is used then I think you must use the truncated versions. Here is some cut & paste parts of RFC4595 to explain situation: ---------------------------------------------------------------------- 2. Overview Fibre Channel defines two security protocols that provide security services for different portions of Fibre Channel traffic: the ESP_Header defined in [FC-FS] and CT_Authentication defined in [FC-GS-4]. The ESP_Header protocol is a transform applied to FC-2 Fibre Channel frames. It is based on the IP Encapsulation Security Payload [RFC4303] to provide origin authentication, integrity, anti-replay protection, and optional confidentiality to generic fibre channel frames. The CT_Authentication protocol is a transform that provides the same set of security services for Common Transport Information Units, which are used to convey control information. As a result of the separation of Fibre Channel data traffic from control traffic, only one protocol (either ESP_Header or CT_Authentication) is applicable to any FC Security Association (SA). ... Since IP is transported over Fibre Channel [RFC4338] and Fibre Channel/SCSI are transported over IP [RFC3643], [RFC3821] there is the potential for confusion when IKEv2 is used for both IP and FC traffic. This document specifies identifiers for IKEv2 over FC in a fashion that ensures that any mistaken usage of IKEv2/FC over IP will result in a negotiation failure due to the absence of an acceptable proposal (and likewise for IKEv2/IP over FC). This document gives an overview of the security architecture defined by the FC-SP standard, including the security protocols used to protect frames and to negotiate SAs, and it specifies the entities for which new identifiers have been assigned. ... 3.2. CT_Authentication Protocol CT_Authentication is a security protocol for Common Transport FC-4 Information Units that provides origin authentication, integrity, and anti-replay protection. The CT_Authentication protocol is carried in the optional extended CT_IU preamble ... The Authentication Hash Block is computed as an HMAC keyed hash of the CT_IU, as defined in [RFC2104]. The entire output of the HMAC computation is included in the Authentication Hash Block, without any truncation. Two transforms are defined: HMAC-SHA1-160 that is based on the cryptographic hash function SHA1 [NIST.180-1.1995], and HMAC-MD5-128 that is based on the cryptographic hash function MD5 [RFC1321]. ... 4.3. CT_Authentication Protocol Transform Identifiers The CT_Authentication Transform IDs defined for Transform Type 3 (Integrity Algorithm) are: Name Number Defined in ---- ------ ---------- AUTH_HMAC_MD5_128 6 FC-SP AUTH_HMAC_SHA1_160 7 FC-SP These transforms differ from the corresponding _96 transforms used in IPsec solely in the omission of the truncation of the HMAC output to 96 bits; instead, the entire output (128 bits for MD5, 160 bits for SHA-1) is transmitted. MD5 support is required due to existing usage of MD5 in CT_Authentication; SHA-1 is RECOMMENDED in all new implementations. ... ---------------------------------------------------------------------- So AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 cannot be used in IPsec, but they have the numbers in the IKEv2 registry, as they are negotiated for their CT_Authentication use using IKEv2. > For the other algorithms (AES-XCBC, > HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD), only the truncated > version can be used for both IKEv2 and IPsec-v3 SAs. > > NOTE to Tero, Paul, Yaron: do we want to expand the IKEv2 IANA > registry to include non-truncated AES-XCBC-MAC, > HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD? Not for IPsec use. I do not know if the Fibre Channel people want to use non-truncated versions of them in their CT_Authentication format, but for IPsec if you want to have longer MAC, use longer HMAC-SHA-2 variant... -- kivinen@iki.fi From kivinen@iki.fi Wed Oct 28 04:58:29 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660813A6784 for ; Wed, 28 Oct 2009 04:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] 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 xsqjpyO0FjGQ for ; Wed, 28 Oct 2009 04:58:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3891B3A681D for ; Wed, 28 Oct 2009 04:58:28 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9SBwbse014166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 13:58:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9SBwag1013594; Wed, 28 Oct 2009 13:58:36 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19176.12780.93344.730093@fireball.kivinen.iki.fi> Date: Wed, 28 Oct 2009 13:58:36 +0200 From: Tero Kivinen To: "Frankel, Sheila E." In-Reply-To: References: <063.764926e4414cb9e492e9c76aed2dcc1d@tools.ietf.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 14 min Cc: "ipsec@ietf.org" , Paul Hoffman , "suresh.krishnan@ericsson.com" Subject: Re: [IPsec] [ipsecme] #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 11:58:29 -0000 Frankel, Sheila E. writes: > > #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3? > > Proposed changes to Roadmap doc: > > 1) Add text to section 5.4 (Combined Mode Algorithms) ... > Additional text: > Some IKEv1 implementations have added the capability to negotiate > combined mode algorithms for use in IPsec SAs; these implementations > do not include the capability to use combined mode algorithms to protect > IKE SAs. Since combined mode algorithms are not a feature of IPsec-v2, > these IKEv1 implementations are used in conjunction with IPsec-v3. IANA > numbers for combined mode algorithms have been added to the IKEv1 registry. That text seems ok. > 2) Change IKEv2 and IPsec-v2 requirement levels > > Requirements levels for AES-GMAC: > old IKEv2 - optional > new IKEv2 - optional (integrity-protection algorithm) > N/A (combined mode algorithm with NULL encryption) IKEv2 SA cannot be used with NULL encryption, so using AES-GMAC requires some other encryption algorithm when used in IKEv2. AES-GMAC requires IV and some other encryption algorithm used with it also requires IV, which means we require two IVs or they require sharing the IV, which might not be possible as there IV generation rules (and lengths) might be different. I do not think it is possible to use AES-GMAC at all to protect IKEv2 traffic, and also it does not make any sense to use AES-GMAC as it says that it is to be used when no confidentiality is desired, and as in IKEv2 that is required then AES-GCM should be used instead. >From RFC5282: ---------------------------------------------------------------------- 3. The Use of AES-GMAC in ESP ... If confidentiality is desired, then GCM ESP [RFC4106] SHOULD be used instead. ---------------------------------------------------------------------- So I think the correct change is IKEv2 - N/A (IKEv2 requires encryption). -- kivinen@iki.fi From kivinen@iki.fi Wed Oct 28 05:11:07 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83143A6927 for ; Wed, 28 Oct 2009 05:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] 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 wuN6lLVl1Szi for ; Wed, 28 Oct 2009 05:11:06 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8294E3A68C1 for ; Wed, 28 Oct 2009 05:11:06 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9SCBH5i012591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 14:11:17 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9SCBHG3011434; Wed, 28 Oct 2009 14:11:17 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19176.13541.190708.95193@fireball.kivinen.iki.fi> Date: Wed, 28 Oct 2009 14:11:17 +0200 From: Tero Kivinen To: "Frankel, Sheila E." In-Reply-To: References: <063.783474ea3d34b716e39da24271b27cac@tools.ietf.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 11 min Cc: "ipsec@ietf.org" , Paul Hoffman , "suresh.krishnan@ericsson.com" Subject: Re: [IPsec] [ipsecme] #114: Expired drafts, especially BEET X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 12:11:07 -0000 Frankel, Sheila E. writes: > 2) Add text to the introductory section for IKEv1, Section 4.1.1: > > Additional text: ... > Two Internet Drafts were written to address these problems: Extended > Authentication withn IKE (XAUTH) (draft-beaulieu-ike-xauth) and The ^ within > ISAKMP Configuration Method (draft-dukes-ike-mode-cfg). These > drafts did not progress to RFC status due to security flaws and > other problems related to these solutions. However, many current > IKEv1 implementations incorporate aspects of these solutions to > facilitate remote user access to corporate VPNs. Since these > solutions were not standardized, there is no assurance that the > implementations adhere fully to the suggested solutions, or that one > implementation can interoperate with others that claim to > incorporate the same features. Furthermore, these solutions have > know security issues. Thus, use of these solutions is not > recommended, and these Internet Drafts are not specified in this > roadmap. I wonder if we should also say that different implementations took different versions of the drafts (and their predecessors draft-ietf-ipsra-isakmp-xauth and draft-ietf-ipsec-isakmp-mode-cfg) and those different versions are NOT necessarely interoperable which each other. Actually listing also those predecessor drafts might be good idea as implementations done before year 2000 mostly refer to them, and we are talking about old expired drafts to obsoleted protocol, so most likely people using them are not from this centrury :-) -- kivinen@iki.fi From kivinen@iki.fi Wed Oct 28 05:12:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206583A697D for ; Wed, 28 Oct 2009 05:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] 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 XQQ1Ud7oXQ2c for ; Wed, 28 Oct 2009 05:12:09 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4013A696F for ; Wed, 28 Oct 2009 05:12:08 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9SCCEDC013152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 14:12:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9SCCEu5014667; Wed, 28 Oct 2009 14:12:14 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19176.13598.895597.961103@fireball.kivinen.iki.fi> Date: Wed, 28 Oct 2009 14:12:14 +0200 From: Tero Kivinen To: "Frankel, Sheila E." In-Reply-To: References: <063.06d317c6f664560309ce0afcacc220bc@tools.ietf.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: "ipsec@ietf.org" , Paul Hoffman , "suresh.krishnan@ericsson.com" Subject: Re: [IPsec] [ipsecme] #115: Camellia req levels for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 12:12:10 -0000 Frankel, Sheila E. writes: > > #115: Camellia req levels for IKEv2 > > Proposed changes to Roadmap doc: > > 1) Change IKEv2 requirement level for Camellia-CBC from undefined (no RFC) > to optional > > 2) Add text to Section 5.2.6 (RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec) Looks ok for me. -- kivinen@iki.fi From paul.hoffman@vpnc.org Wed Oct 28 08:19:14 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4F128C1A0 for ; Wed, 28 Oct 2009 08:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.694 X-Spam-Level: X-Spam-Status: No, score=-5.694 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 AvpU+7lXk2qa for ; Wed, 28 Oct 2009 08:19:14 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E93F33A69F3 for ; Wed, 28 Oct 2009 08:19:13 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9SFJReW069996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Oct 2009 08:19:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213B71@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213B71@il-ex01.ad.checkpoint.com> Date: Wed, 28 Oct 2009 08:19:24 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Proposed agenda X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 15:19:14 -0000 Here is the proposed agenda for our meeting in Hiroshima in two weeks. Let us know if you have any concerns about it. IPsecME WG 2009-11-12, Thursday, 0900-1130 0900 Agenda bash and start blue sheets and RFID scanning 0905 Brief review of document status 0915 Review of proposed new work items (list of drafts TBD) The format for each proposal will be: - Less than 10 minutes presentation of the draft This will cover both technology and why it should be part of the WG. - Less than 5 minutes mic discussion This will cover *only* whether it should be a WG item, not the technical merits of the draft. 1045 Initial call for volunteers who will review each document. This will help determine which documents have the most interest. 1100 IKEv2bis certificate issues Open issues from the mailing list, plus anything new 1130 Adjourn --Paul Hoffman, Director --VPN Consortium From Black_David@emc.com Wed Oct 28 10:33:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E313A6A20 for ; Wed, 28 Oct 2009 10:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 h8v-82+RtD1c for ; Wed, 28 Oct 2009 10:33:26 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 134083A6A25 for ; Wed, 28 Oct 2009 10:33:25 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id n9SHXeKU012686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 13:33:40 -0400 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 28 Oct 2009 13:33:28 -0400 Received: from corpussmtp1.corp.emc.com (corpussmtp1.corp.emc.com [128.221.166.44]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n9SHXPMI024196; Wed, 28 Oct 2009 13:33:27 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp1.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 13:33:25 -0400 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: Wed, 28 Oct 2009 13:33:25 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A0421E50A@CORPUSMX80A.corp.emc.com> In-Reply-To: <19176.11868.510064.595988@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs Thread-Index: AcpXw+zWtOIPF675SVaJKzIX42VvzQALvU3A References: <063.b5b9a33677a51644c2c934555b3fe9c6@tools.ietf.org> <19176.11868.510064.595988@fireball.kivinen.iki.fi> From: To: , X-OriginalArrivalTime: 28 Oct 2009 17:33:25.0617 (UTC) FILETIME=[C1100610:01CA57F4] X-EMM-EM: Active Cc: ipsec@ietf.org Subject: Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:33:28 -0000 Tero and Sheila, > The AUTH_HMAC_MD5_128 and > AUTH_HMAC_SHA1_160 are really only specified when used with Fibre > Channel CT_Authentication format instead of ESP format. Even when > using fibre channel if ESP format is used then I think you must use > the truncated versions. That is correct for Fibre Channel. If someone wants to use the non-truncated versions of these with conventional IPsec, there's no specification barrier to doing so, but I don't think this has or is likely to be implemented. FWIW, I concur with Tero's suggestion to look to the HMAC-SHA2 family for longer IPsec MACs. > So AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 cannot be used in IPsec, > but they have the numbers in the IKEv2 registry, as they are > negotiated for their CT_Authentication use using IKEv2. I wouldn't say "cannot be used" - "are not used" is more accurate. The potentially related discussion about separate identifiers: > This document specifies identifiers for IKEv2 over FC in a > fashion that ensures that any mistaken usage of IKEv2/FC over IP will > result in a negotiation failure due to the absence of an acceptable > proposal (and likewise for IKEv2/IP over FC). is primarily about the Security Protocol Identifiers and the Traffic Selector Type - RFC 4595 defines FC-only values for these that any IPsec implementation will quickly reject; see the IANA Considerations (Section 6) of RFC 4595. > > NOTE to Tero, Paul, Yaron: do we want to expand the IKEv2 IANA > > registry to include non-truncated AES-XCBC-MAC, > > HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD?=20 > > Not for IPsec use. I do not know if the Fibre Channel people want to > use non-truncated versions of them in their CT_Authentication format, > but for IPsec if you want to have longer MAC, use longer HMAC-SHA-2 > variant...=20 I would expect to see at least a non-truncated versions of HMAC-SHA2-256 show up when the Fibre Channel specifications are updated, but I think we (IETF) can wait for that (i.e., no registry changes needed now). Thanks, --David (RFC 4595 co-author) > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Tero Kivinen > Sent: Wednesday, October 28, 2009 7:43 AM > To: Frankel, Sheila E. > Cc: ipsec@ietf.org; Paul Hoffman; suresh.krishnan@ericsson.com > Subject: Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs >=20 > Frankel, Sheila E. writes: > > Additional text: > > Some of these algorithms generate a fixed-length ICV, which is truncated=20 > > when it is included in an IPsec-protected packet. For example, standard=20 > > HMAC-SHA-1 generates a 160-bit ICV, which is truncated to 96 bits when it=20 > > is used to provide integrity-protection to an ESP or AH packet. The=20 > > individual RFC descriptions mention those algorithms that are truncated.=20 > > When these algorithms are used to protect IKEv1 SAs, they are not > > truncated. For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry contains=20 > > values for both the truncated version and the standard non-truncated=20 > > version; thus, IKEv2 has the capability to negotiate either version to=20 > > protect IKEv2 and/or IPsec-v3 SAs. >=20 > This is not completely correct. The non-truncated versions are not > meant to be used with normal IPsec-v2/v3. They are meant to be used > with Fibre Channel Security (RFC4595). The AUTH_HMAC_MD5_128 and > AUTH_HMAC_MSHA1_160 are really only specified when used with Fibre > Channel CT_Authentication format instead of ESP format. Even when > using fibre channel if ESP format is used then I think you must use > the truncated versions. >=20 > Here is some cut & paste parts of RFC4595 to explain situation: >=20 > ---------------------------------------------------------------------- > 2. Overview >=20 > Fibre Channel defines two security protocols that provide security > services for different portions of Fibre Channel traffic: the > ESP_Header defined in [FC-FS] and CT_Authentication defined in > [FC-GS-4]. >=20 > The ESP_Header protocol is a transform applied to FC-2 Fibre Channel > frames. It is based on the IP Encapsulation Security Payload > [RFC4303] to provide origin authentication, integrity, anti-replay > protection, and optional confidentiality to generic fibre channel > frames. The CT_Authentication protocol is a transform that provides > the same set of security services for Common Transport Information > Units, which are used to convey control information. As a result of > the separation of Fibre Channel data traffic from control traffic, > only one protocol (either ESP_Header or CT_Authentication) is > applicable to any FC Security Association (SA). > ... > Since IP is transported over Fibre Channel [RFC4338] and Fibre > Channel/SCSI are transported over IP [RFC3643], [RFC3821] there is > the potential for confusion when IKEv2 is used for both IP and FC > traffic. This document specifies identifiers for IKEv2 over FC in a > fashion that ensures that any mistaken usage of IKEv2/FC over IP will > result in a negotiation failure due to the absence of an acceptable > proposal (and likewise for IKEv2/IP over FC). This document gives an > overview of the security architecture defined by the FC-SP standard, > including the security protocols used to protect frames and to > negotiate SAs, and it specifies the entities for which new > identifiers have been assigned. > ... > 3.2. CT_Authentication Protocol >=20 >=20 > CT_Authentication is a security protocol for Common Transport FC-4 > Information Units that provides origin authentication, integrity, and > anti-replay protection. The CT_Authentication protocol is carried in > the optional extended CT_IU preamble > ... > The Authentication Hash Block is computed as an HMAC keyed hash of > the CT_IU, as defined in [RFC2104]. The entire output of the HMAC > computation is included in the Authentication Hash Block, without any > truncation. Two transforms are defined: HMAC-SHA1-160 that is based > on the cryptographic hash function SHA1 [NIST.180-1.1995], and > HMAC-MD5-128 that is based on the cryptographic hash function MD5 > [RFC1321]. > ... > 4.3. CT_Authentication Protocol Transform Identifiers >=20 >=20 > The CT_Authentication Transform IDs defined for Transform Type 3 > (Integrity Algorithm) are: >=20 > Name Number Defined in > ---- ------ ---------- > AUTH_HMAC_MD5_128 6 FC-SP >=20 > AUTH_HMAC_SHA1_160 7 FC-SP >=20 > These transforms differ from the corresponding _96 transforms used in > IPsec solely in the omission of the truncation of the HMAC output to > 96 bits; instead, the entire output (128 bits for MD5, 160 bits for > SHA-1) is transmitted. MD5 support is required due to existing usage > of MD5 in CT_Authentication; SHA-1 is RECOMMENDED in all new > implementations. > ... > ---------------------------------------------------------------------- >=20 > So AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 cannot be used in IPsec, > but they have the numbers in the IKEv2 registry, as they are > negotiated for their CT_Authentication use using IKEv2.=20 >=20 > > For the other algorithms (AES-XCBC,=20 > > HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD), only the truncated=20 > > version can be used for both IKEv2 and IPsec-v3 SAs. > > =20 > > NOTE to Tero, Paul, Yaron: do we want to expand the IKEv2 IANA > > registry to include non-truncated AES-XCBC-MAC, > > HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD?=20 >=20 > Not for IPsec use. I do not know if the Fibre Channel people want to > use non-truncated versions of them in their CT_Authentication format, > but for IPsec if you want to have longer MAC, use longer HMAC-SHA-2 > variant...=20 > --=20 > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 From yaronf@checkpoint.com Wed Oct 28 13:28:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BABAD3A68E7 for ; Wed, 28 Oct 2009 13:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 yOdg8uXjcSl0 for ; Wed, 28 Oct 2009 13:28:36 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 8AB8E3A68A6 for ; Wed, 28 Oct 2009 13:28:34 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9SKSihu015442 for ; Wed, 28 Oct 2009 22:28:45 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 28 Oct 2009 22:28:47 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Wed, 28 Oct 2009 22:28:44 +0200 Thread-Topic: [btns] RFC 5660 on IPsec Channels: Connection Latching Thread-Index: AcpYA/tLnWOG/KVUTFOMm5skEcENZwACT0zg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213D12@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] FW: [btns] RFC 5660 on IPsec Channels: Connection Latching X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:28:36 -0000 -----Original Message----- From: btns-bounces@ietf.org [mailto:btns-bounces@ietf.org] On Behalf Of rfc= -editor@rfc-editor.org Sent: Wednesday, October 28, 2009 21:19 To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: btns@ietf.org; rfc-editor@rfc-editor.org Subject: [btns] RFC 5660 on IPsec Channels: Connection Latching A new Request for Comments is now available in online RFC libraries. =20 RFC 5660 Title: IPsec Channels: Connection Latching=20 Author: N. Williams Status: Standards Track Date: October 2009 Mailbox: Nicolas.Williams@sun.com Pages: 31 Characters: 74209 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-btns-connection-latching-11.txt URL: http://www.rfc-editor.org/rfc/rfc5660.txt This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture. Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes. Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. [STANDARDS TRACK] This document is a product of the Better-Than-Nothing Security Working Grou= p of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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 USC/Information Sciences Institute _______________________________________________ btns mailing list btns@ietf.org https://www.ietf.org/mailman/listinfo/btns Scanned by Check Point Total Security Gateway. From yaronf@checkpoint.com Thu Oct 29 16:17:37 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92713A690D for ; Thu, 29 Oct 2009 16:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, 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 atP40mSS4IkS for ; Thu, 29 Oct 2009 16:17:35 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 87C843A6781 for ; Thu, 29 Oct 2009 16:17:34 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9TNHnhu019978 for ; Fri, 30 Oct 2009 01:17:49 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 30 Oct 2009 01:17:51 +0200 From: Yaron Sheffer To: IPsecme WG Date: Fri, 30 Oct 2009 01:17:50 +0200 Thread-Topic: Certificate-related issues Thread-Index: AcpY7GFXOJkiwsjfT7yL/JuU0JiZsg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA7@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: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA7ilex01adche_" MIME-Version: 1.0 Subject: [IPsec] Certificate-related issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 23:17:37 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA7ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I will follow this message with 5 IKEv2-bis issues, all related to certific= ate handling in IKEv2. Note that these are not "PKIX issues", none of them = has anything to do with the internal format of the certificate. They all ha= ve to do with the somewhat underspecified interaction of IKEv2 with certifi= cates. We will present these issues in Hiroshima. I am posting the issues here to = encourage on-list discussion before (and after) the meeting. Thanks, Yaron --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA7ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I will follow this message with 5 IKEv2-bis issues, all related to certificate handling in IKEv2. Note that these are not “PK= IX issues”, none of them has anything to do with the internal format of the certificate= . They all have to do with the somewhat underspecified interaction of IKEv2 w= ith certificates.

 

We will present these issues in Hiroshima. I am posting the issues here= to encourage on-list discussion before (and after) the meeting.

 

Thanks,

         &n= bsp;  Yaron

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA7ilex01adche_-- From yaronf@checkpoint.com Thu Oct 29 16:17:51 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA323A697F for ; Thu, 29 Oct 2009 16:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.686 X-Spam-Level: X-Spam-Status: No, score=-3.686 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, 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 M1J8XlQmT2PN for ; Thu, 29 Oct 2009 16:17:50 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 21E4B3A699C for ; Thu, 29 Oct 2009 16:17:49 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9TNI5hu020024 for ; Fri, 30 Oct 2009 01:18:05 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 30 Oct 2009 01:18:07 +0200 From: Yaron Sheffer To: IPsecme WG Date: Fri, 30 Oct 2009 01:18:07 +0200 Thread-Topic: #116: The AUTH payload signature Thread-Index: AcpY7JIWsaUaiVnDRVWi32jyvGpWeA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA8@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: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA8ilex01adche_" MIME-Version: 1.0 Subject: [IPsec] #116: The AUTH payload signature X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 23:17:51 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA8ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The definition of the payload (sec. 3.8) should mention explicitly that the= payload hash algorithm is unrelated to the one used in the certificate, or= the algorithm used to sign the IKE Encrypted Payload. Moreover, the words "by default" are confusing and should be deleted. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA8ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The definition of the payload (sec. 3.8) should mention explic= itly that the payload hash algorithm is unrelated to the one used in the certificate, or the algorithm used to sign the IKE Encrypted Payload.<= /o:p>

Moreover, the words "by default" are confusing and should be deleted.

 

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA8ilex01adche_-- From yaronf@checkpoint.com Thu Oct 29 16:17:56 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE67B3A69AC for ; Thu, 29 Oct 2009 16:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.676 X-Spam-Level: X-Spam-Status: No, score=-3.676 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, 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 IVexQxDFGqsJ for ; Thu, 29 Oct 2009 16:17:56 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 2C9283A69BC for ; Thu, 29 Oct 2009 16:17:53 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9TNI9hu020037 for ; Fri, 30 Oct 2009 01:18:09 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 30 Oct 2009 01:18:11 +0200 From: Yaron Sheffer To: IPsecme WG Date: Fri, 30 Oct 2009 01:18:10 +0200 Thread-Topic: #117: Hash and URL interop Thread-Index: AcpY7LaHo4XNYlksQG2848du6xjjCQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9@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: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9ilex01adche_" MIME-Version: 1.0 Subject: [IPsec] #117: Hash and URL interop X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 23:17:56 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To improve interoperability, allow only the "http" URL method. The current = text (end of sec. 3.6) implies that any method is allowed, although HTTP MU= ST be supported. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To im= prove interoperability, allow only the "http" URL method. The current t= ext (end of sec. 3.6) implies that any method is allowed, although HTTP MUST be supported.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9ilex01adche_-- From yaronf@checkpoint.com Thu Oct 29 16:18:04 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BFC43A6A0B for ; Thu, 29 Oct 2009 16:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.668 X-Spam-Level: X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, 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 pIqUgFl3CYnv for ; Thu, 29 Oct 2009 16:18:03 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 3492B3A69C7 for ; Thu, 29 Oct 2009 16:18:02 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9TNIIhu020060 for ; Fri, 30 Oct 2009 01:18:18 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 30 Oct 2009 01:18:20 +0200 From: Yaron Sheffer To: IPsecme WG Date: Fri, 30 Oct 2009 01:18:20 +0200 Thread-Topic: #118: Reference for PKCS #7 Thread-Index: AcpY7OK6EkCI/g2jQAC0C8W6KdSE8A== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAA@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: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAAilex01adche_" MIME-Version: 1.0 Subject: [IPsec] #118: Reference for PKCS #7 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 23:18:04 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAAilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PKCS#7 should reference RFC 2315. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAAilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

PKCS#= 7  should reference RFC 2315.=

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAAilex01adche_-- From yaronf@checkpoint.com Thu Oct 29 16:38:18 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550CC28C0D8 for ; Thu, 29 Oct 2009 16:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.662 X-Spam-Level: X-Spam-Status: No, score=-3.662 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, 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 pRpo-VNDqZgJ for ; Thu, 29 Oct 2009 16:38:17 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 420FE28C0CF for ; Thu, 29 Oct 2009 16:38:17 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9TNINhu020085 for ; Fri, 30 Oct 2009 01:18:23 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 30 Oct 2009 01:18:25 +0200 From: Yaron Sheffer To: IPsecme WG Date: Fri, 30 Oct 2009 01:18:24 +0200 Thread-Topic: #119: Which certificate types can be mixed in one exchange? Thread-Index: AcpY7RujsaPOPWKnQK+8SRjY4rhHTg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAB@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: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EABilex01adche_" MIME-Version: 1.0 Subject: [IPsec] #119: Which certificate types can be mixed in one exchange? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 23:38:18 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EABilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Should be added to Sec. 3.6, probably as a new subsection. One Hash & URL (H&U) bundle only. Or... One Raw RSA key, or... One or more cert payloads of either type 4 or H&U (type 12) Can have one or more CRLs and/or OCSP content (RFC 4806) added to any of the above, except for Raw RSA. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EABilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Should be added to Sec. 3.6, probably as a new subsection.

One Hash & URL (H&U) bundle only. Or...

One Raw RSA key, or...

One or more cert payloads of either type 4 or H&U (type 12= )

Can have one or more CRLs and/or OCSP content (RFC 4806) added to any of the above, except for Raw RSA.=

 

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EABilex01adche_-- From yaronf@checkpoint.com Thu Oct 29 16:38:19 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832FA28C110 for ; Thu, 29 Oct 2009 16:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.657 X-Spam-Level: X-Spam-Status: No, score=-3.657 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, 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 fHBdSnoKs-KN for ; Thu, 29 Oct 2009 16:38:18 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 5ABF728C0CF for ; Thu, 29 Oct 2009 16:38:18 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9TNIShu020107 for ; Fri, 30 Oct 2009 01:18:28 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 30 Oct 2009 01:18:30 +0200 From: Yaron Sheffer To: IPsecme WG Date: Fri, 30 Oct 2009 01:14:56 +0200 Thread-Topic: #120: CA indication with cert req - allowed types Thread-Index: AcpY7aER8O2EnOH0ScGN8V+2YUNFTg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAC@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: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EACilex01adche_" MIME-Version: 1.0 Subject: [IPsec] #120: CA indication with cert req - allowed types X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 23:38:19 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EACilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sec. 3.7 has: The contents of the "Certification Authority" field are defined only for X.= 509 certificates, which are types 4, 10, 12, and 13. Other values SHOULD NO= T be used until standards-track specifications that specify their use are p= ublished. This excludes certificate requests of type 7, i.e. for CRLs. For requesting= a specific CRL type 7 would make sense, in particular in chain situations.= Should we add it to the list of allowed types here? OTOH, this allows type 10, which is unspecified and should be removed. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EACilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sec. 3.7 has:

The contents of the "Certificat= ion Authority" field are defined only for X.509 certificates, which are ty= pes 4, 10, 12, and 13. Other values SHOULD NOT be used until standards-track specifications that specify their use are published.

This excludes certificate requests of type 7, i.e. for CRLs. F= or requesting a specific CRL type 7 would make sense, in particular in chain situations. Should we add it to the list of allowed types here?<= /span>

OTOH, this allows type 10, which is unspecified and should be removed.

 

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EACilex01adche_-- From svanru@gmail.com Thu Oct 29 23:58:31 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22D43A63D3 for ; Thu, 29 Oct 2009 23:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_I_LETTER=-2, J_CHICKENPOX_36=0.6, XMAILER_MIMEOLE_OL_7533E=0.513] 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 GMwkncGk72gP for ; Thu, 29 Oct 2009 23:58:30 -0700 (PDT) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by core3.amsl.com (Postfix) with ESMTP id 5CA573A6821 for ; Thu, 29 Oct 2009 23:58:30 -0700 (PDT) Received: by ewy5 with SMTP id 5so742789ewy.37 for ; Thu, 29 Oct 2009 23:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=RP9TOIOZaEdGiwwqR6A6jNnR/WNFaMWnS4HP0Jiwx/c=; b=eUqwxchpC223+0jsbAC2D8S6Xhj7mt7uoRgbmTpVruDd8XjdgKT+ntx8dh5OCFBU2v NN+x0YUxcQw0Zb48VWDiQ0YZ3y3b22/tLWwhWMTc7OQlBuyMKaBeRPeT94ksyrL8iSaR +lHS8xcAWqra+oi157hRWue2mhBAWgxcdNvW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; b=x1+k2IStVgb9mv5ocHoTtYKOs5X4HwrVR7kOgkN71jgTYZ+0+p3vPFRyX1JqIbeqi1 UpwYvVTavtaxMV+0sbCGiDRPwxMAAZQWFUZg1l0UjklBL26nWMf1N16u5uCRS+0lWHsv dCh0d+P7cfMVFBVEzvaMGZJ45DW6pq8pQ3N1k= Received: by 10.210.7.23 with SMTP id 23mr3789934ebg.38.1256885922951; Thu, 29 Oct 2009 23:58:42 -0700 (PDT) Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 28sm7941027eyg.22.2009.10.29.23.58.40 (version=SSLv3 cipher=RC4-MD5); Thu, 29 Oct 2009 23:58:41 -0700 (PDT) Message-ID: <82DFB96E88E54DE98E9B6B5F766C3EB8@trustworks.com> From: "Valery Smyslov" To: Date: Fri, 30 Oct 2009 09:58:44 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 Subject: [IPsec] Fw: Preshared key authentication in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 06:58:31 -0000 Hi all, I'd like to reiterate my early message, which I haven't got answer to. My concerns are: 1. How padding pre-sahred key with string "Key Pad for IKEv2" could help to avoid storing pre-shared key in IKE implementation if prf is not known untill IKE_SA_INIT exchange is finished? 2. It is a bit unclear whether EAP generated key should also be padded before use in IKE, or used directly. Thanks, Valery Smyslov. ----- Original Message ----- From: "Valery Smyslov" To: Subject: [IPsec] Preshared key authentication in IKEv2 > Hi all, > > I found text describing preshared key authentication in IKEv2 a bit confusing. > > First, in section 2.15 four different terms are used: "shared secret", > "Shared Secret" (with capital letters), "shared key" and "pre-shared key". > This is a bit confusing, especially taking into consideration that terms > "shared keys" and "shared secret" are also used in the draft for SK_* and > result of ephemeral Diffie-Hellman exchange. I'd propose to use > only one term, "pre-shared key". > > Then, in section 2.15 the very first sentence states: > > When not using extensible authentication (see Section 2.16), the > peers are authenticated by having each sign (or MAC using a shared > secret as the key) a block of data. > > But in the last paragraph of this section it is shown, that not sole "shared > secret" > is used as the key, but the following construction: > > prf( Shared Secret,"Key Pad for IKEv2") > > So, the first sentence of 2.15 is misleading. > > Then, the following rationale for padding shared key is given: > > The pad string is added so that if the shared secret is derived from a > password, the IKE implementation need not store the password in > cleartext, but rather can store the value prf(Shared Secret,"Key Pad > for IKEv2"), which could not be used as a password equivalent for > protocols other than IKEv2. > > I found this rationale a bit strange, because which prf should be used cannot > be known at the time of providing pre-shared key by user - it becomes known > only after IKE_SA_INIT exchange is finished. It is possible to compute values > for all possible prfs, but this doesn't work in all cases - for example > in case of pluggable crypto. So, I think, in general, storing of "Shared > Secret"/password in unavoidable. > > And last, but not least. The following section 2.16, describing > authentication with EAP, states: > > For EAP methods that create a shared key as a side effect of > authentication, that shared key MUST be used by both the initiator > and responder to generate AUTH payloads in messages 7 and 8 using the > syntax for shared secrets specified in Section 2.15. > > and later: > > If EAP methods that do not generate a > shared key are used, the AUTH payloads in messages 7 and 8 MUST be > generated using SK_pi and SK_pr, respectively. > > It is a bit unclear, whether these shared secrets (EAP generated or SK_p*) > must be used as key "as is", or as prf( SK_p*, "Key Pad for > IKEv2"). > I suspect that the latter is right answer, but this probably must be written > excplicitly. > > Regards, > Valery Smyslov. > > From Pasi.Eronen@nokia.com Fri Oct 30 01:53:59 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B0C3A69A6 for ; Fri, 30 Oct 2009 01:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 FqfUieqlRmPo for ; Fri, 30 Oct 2009 01:53:58 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 66CE73A67C1 for ; Fri, 30 Oct 2009 01:53:58 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9U8s8Uu030745; Fri, 30 Oct 2009 03:54:14 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 10:54:09 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 10:54:09 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 10:54:03 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 30 Oct 2009 09:54:02 +0100 From: To: , Date: Fri, 30 Oct 2009 09:54:01 +0100 Thread-Topic: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document Thread-Index: AcpS8yoVaeLJy/jhTiaJzP8hPhTkLAGSylbA Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F6F461F@NOK-EUMSG-01.mgdnok.nokia.com> References: <19165.48619.530034.469960@fireball.kivinen.iki.fi> <19168.6686.368531.842814@fireball.kivinen.iki.fi> In-Reply-To: <19168.6686.368531.842814@fireball.kivinen.iki.fi> 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-OriginalArrivalTime: 30 Oct 2009 08:54:03.0806 (UTC) FILETIME=[880083E0:01CA593E] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 08:53:59 -0000 Tero: I think you're correct that RFC 4307 has a bug: ENCR_NULL should be MUST NOT, instead of MAY (note that ENCR_NULL in 4305/4835 is MUST). Go ahead and submit an errata about this! Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of ext Tero Kivinen > Sent: 22 October, 2009 11:39 > To: Frankel, Sheila E. > Cc: ipsec@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki) > Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap > document >=20 > Frankel, Sheila E. writes: > > I interpreted RFC 4307 slightly differently than Tero does, and I > > stand by the wording of both the USGv6 Profile and the IPsec > > Roadmap. Although RFC 4307's domain is limited to IKEv2, it clearly > > specifies both those algorithms used within IKEv2 and also those > > algorithms that IKEv2 negotiates for use by IPsec. That is why there > > are 2 separate lists of algorithms: Section 3.1.1 (Encrypted Payload > > Algorithms) specifies those algorithms that are used BY IKEv2 in its > > Encrypted Payload. Sections 3.1.3 (IKEv2 Transform Type 1 > > Algorithms) and 3.1.5 (IKEv2 Transform Type 3 Algorithms) lists > > those algorithms that IKEv2 should be able to negotiate for use > > within IPsec/child SAs. One detail that supports this interpretation > > is the inclusion of NULL encryption in section 3.1.3 - clearly, this > > is not appropriate in the IKE Encrypted Payload. If the > > applicability of Sections 3.1.3 and 3.1.5 is limited to IKEv2 SAs, > > then there is no need for the more constrained list in Section > > 3.1.1, which clearly applies only to IKEv2's payloads. >=20 > Hmm... Yes, it could be interpreted so also, but what is the > relationship between RFC4307 and RFC4305/4835 then. Would > RFC4305/RFC4835 then cover only manual keying and IKEv1? I always > assumed that RFC4307 talks about IKEv2 SAs and RFC4305/4835 talks > about ESP and AH (i.e. IPsec SAs aka Child SAs). >=20 > One reason I think this is the correct interpretation is that RFC4307 > section 3.1.4 lists Transform Type 2 Algorithms (Pseudor-random > functions, PRFs), and those are applicable ONLY to IKEv2. IPsec > SAs/Child SAs/ESP/AH cannot have PRFs. >=20 > Also section 3.1.5 does not give any status for NONE authentication > (as it cannot be used for IKEv2 SAs), but for example RFC4305/RFC4835 > both give requirement for it (MUST / MAY). > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Fri Oct 30 05:03:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA673A6A8E for ; Fri, 30 Oct 2009 05:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] 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 M0KO4h5atK8F for ; Fri, 30 Oct 2009 05:03:57 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 510DE3A68B4 for ; Fri, 30 Oct 2009 05:03:56 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9UC45hN007693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 14:04:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9UC45EY024336; Fri, 30 Oct 2009 14:04:05 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19178.54837.91281.118148@fireball.kivinen.iki.fi> Date: Fri, 30 Oct 2009 14:04:05 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA8@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA8@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: IPsecme WG Subject: [IPsec] #116: The AUTH payload signature X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 12:03:58 -0000 Yaron Sheffer writes: > The definition of the payload (sec. 3.8) should mention explicitly > that the payload hash algorithm is unrelated to the one used in the > certificate, or the algorithm used to sign the IKE Encrypted > Payload. What is the exact wording you are plannig to add there. As in some cases the hash functions are related to the keys used (for example hash must be SHA if DSS digital Signatures are used) the exact wording is important. Also it is very good idea to see that if other end used certificates using SHA-2 as their hash algorithm for certificates, then he most likely do support SHA-2 as auth method hash algorithm too, so using it to hash the RSA keys might be good idea. This means that hash algorithm used here and the hash algorithm used in the certificate are related, altought that does not mean they need to be same. > Moreover, the words "by default" are confusing and should be > deleted. I cannot find words "by default" from rfc4306 nor from draft-ietf-ipsecme-ikev2bis-05.txt. Are you refering this text: ... To promote interoperability, implementations that support this type SHOULD support signatures that use SHA-1 as the hash function and SHOULD use SHA-1 as the default hash function when generating signatures. -- kivinen@iki.fi From kivinen@iki.fi Fri Oct 30 06:55:16 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531153A67B6 for ; Fri, 30 Oct 2009 06:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] 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 I7LnMBSL1se7 for ; Fri, 30 Oct 2009 06:55:15 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 319513A68D6 for ; Fri, 30 Oct 2009 06:55:14 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9UDtM7d011106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 15:55:22 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9UDtL9F007786; Fri, 30 Oct 2009 15:55:21 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19178.61513.606708.918055@fireball.kivinen.iki.fi> Date: Fri, 30 Oct 2009 15:55:21 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 110 min Cc: IPsecme WG Subject: [IPsec] #117: Hash and URL interop X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 13:55:16 -0000 Yaron Sheffer writes: > To improve interoperability, allow only the "http" URL method. The > current text (end of sec. 3.6) implies that any method is allowed, > although HTTP MUST be supported. If that means adding MUST NOT for other URL methods, I do not think we want to do it. We alrady have one mandatory to implement URL method (http) and that should be enough to provide interoperability. If someone wants to create implementation which uses some other format in addition to http method for their own use, I do not see any reason why they should be forbidded to do so. Note, that HASH and URL formats are not limited to exactly one URL format for each hash. Implementation would are allowed to send multiple cert payloads, each having same HASH but different URLs having different methods. If implementation does not support certain URL method it just ignores the cert payload, and as multiple methods point to same certificate each of them have same hash, thus it does not matter which one of them the implementation uses to fetch the certificate. -- kivinen@iki.fi From wwwrun@core3.amsl.com Fri Oct 30 07:00:18 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 1C2593A67DB; Fri, 30 Oct 2009 07:00:17 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091030140018.1C2593A67DB@core3.amsl.com> Date: Fri, 30 Oct 2009 07:00:18 -0700 (PDT) Cc: ipsecme mailing list , ipsecme chair , Internet Architecture Board , RFC Editor Subject: [IPsec] Protocol Action: 'IKEv2 Session Resumption' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 14:00:18 -0000 The IESG has approved the following document: - 'IKEv2 Session Resumption ' as a Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-09.txt Technical Summary This document describes an efficient way to resume an IKEv2 session after it has failed. This avoids having to re-run the key exchange protocol from scratch, which can be onerous if EAP authentication is involved. The protocol uses an opaque ticket that can be stored by the client or in a centralized storage location. Working Group Summary The document has rough consensus of the IPsecME WG. Document Quality There was interest in this protocol from many vendors, but none have come forward to say that they have implemented it. Personnel The document shepherd is Paul Hoffman; the responsible area director is Pasi Eronen. From kivinen@iki.fi Fri Oct 30 07:11:33 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199FC3A696F for ; Fri, 30 Oct 2009 07:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] 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 7mUFNmyCSk1S for ; Fri, 30 Oct 2009 07:11:32 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B8F563A67E9 for ; Fri, 30 Oct 2009 07:11:31 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9UE6h7d007615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 16:06:43 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9UE6hk3008115; Fri, 30 Oct 2009 16:06:43 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19178.62195.841240.79258@fireball.kivinen.iki.fi> Date: Fri, 30 Oct 2009 16:06:43 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAB@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAB@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 10 min Cc: IPsecme WG Subject: [IPsec] #119: Which certificate types can be mixed in one exchange? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 14:11:33 -0000 Yaron Sheffer writes: > Should be added to Sec. 3.6, probably as a new subsection. > > One Hash & URL (H&U) bundle only. Or... > > One Raw RSA key, or... > > One or more cert payloads of either type 4 or H&U (type 12) > > Can have one or more CRLs and/or OCSP content (RFC > 4806) added to any of the above, > except for Raw RSA. I think the answer to question which types can be mixed in one exchange is: Any. As recipient should be able to ignore the formats it does not support easily, and if that results to case where recipient does not have enough information to validate the certificate then the authentication cannot succeed. The sender should include certificates in the format that they were requested by certificate request payload, but if it cannot, then it might as well include the certificate in some other format, just in case that will help the recipient. If that does not help the recipient, then those two peers cannot authenticate each other. I do not see any problem when some implementation which needs to present certificate for peer, which didn't send any certificate request payload, decides to send same certiface using format 11 and 4 and also provides intermediate certificates for the X.509 certificate as hash and url of X.509 certificates and even includes CRL in format 7 if all that can be fit to the packet without causing fragmentation (i.e. if all that fits to packet less than 1280 bytes, then there is no reason not to include all that helpful information if that was readily available). Then if the initiator was very limited IPsec garage door remote controller implementation which required public key as raw rsa key (format 11), it can take it from there, and ignore rest, and if it happened to be real VPN client using preper CA, it can then verify the certificates and CRLs etc. Limiting the number of certificate types which can be mixed in one exchange will limit the scenarios we can use with IPsec. I.e. if we limit there can be only one type then we need to add more configuration to the recipient, i.e. it needs to know from somewhere that this incoming connection is now from this limited IPsec garage door remote controller so only raw RSA key is presented, and if it is this VPN client (laptop) then it need to give certificates etc. I do not think this really affects interoperability as we already have fixed list of mandatory to implement methods, this mostly affect how much configuration each implementation needs to fill in, compared to using more optimistic approach that fill in everything we have and hope the other end has enough data to finish the authentication (if we really gave everything we had, and that was not enough for the other end, then we clearly cannot communicate regardless what format we would have used). -- kivinen@iki.fi From kivinen@iki.fi Fri Oct 30 07:32:56 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 113F53A69B9 for ; Fri, 30 Oct 2009 07:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] 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 mUkLTjHPsLqH for ; Fri, 30 Oct 2009 07:32:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D2E283A67B6 for ; Fri, 30 Oct 2009 07:32:54 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9UEX5S7009401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 16:33:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9UEX5WJ008973; Fri, 30 Oct 2009 16:33:05 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19178.63776.974040.367597@fireball.kivinen.iki.fi> Date: Fri, 30 Oct 2009 16:33:04 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAC@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAC@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 25 min Cc: IPsecme WG Subject: [IPsec] #120: CA indication with cert req - allowed types X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 14:32:56 -0000 Yaron Sheffer writes: > Sec. 3.7 has: > > The contents of the "Certification Authority" field are defined only > for X.509 certificates, which are types 4, 10, 12, and 13. Other > values SHOULD NOT be used until standards-track specifications that > specify their use are published. This is clearly wrong and is not present in the RFC4306. There is two meanings for the certificate request payload, one is to specify preferred format in which certificates are requested and another is to tell which authority the certificate is wanted from. So if someone wants to have certificate payloads in raw rsa format, he should be able to give certificate request with encoding of type 11 and with empty authority field (as for raw rsa keys there is no authority field). Also as the certificate request is just hint the contents of the authority field is not that important, it is there just in case the other end happens to have MULTIPLE "certificates" it could use and needs to decide which of them to use. If it has only one of the requested format then it should send it regardless what the authority field said. So the text most likely should say that "For other values the certificate authority field contents is not defined, and can be anything (or empty) until specifications that specify their contents is published." > This excludes certificate requests of type 7, i.e. for CRLs. For > requesting a specific CRL type 7 would make sense, in particular in > chain situations. Should we add it to the list of allowed types > here? Giving certificate authorities for the CRLs is usually no operation as it will be the same as the ones for X.509 certificates (usually hosts do trust same CAs for certificates and CRLs, they do not have separate sets of authorities for those two uses). So in most cases certificate request of type 7 is just indicating that other end would like to have CRLs inline also if possible in addition to certificates, and the authority field could be empty there. This kind of telling only the format not the exact authority is inherited from the IKEv1 and is specified for example in the RFC4945 section 3.2.7.2. I think we had discussion about this when we were specifying IKEv2 as some people wanted to disallow it but I think we decided to allow it (at least I couldn't find text in the RFC4306 which would disallow it). > OTOH, this allows type 10, which is unspecified and should be > removed. Most likely. -- kivinen@iki.fi From pete.mccann@motorola.com Thu Oct 29 11:53:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12D73A6A13; Thu, 29 Oct 2009 11:53:25 -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 GBdvugWOUpwZ; Thu, 29 Oct 2009 11:53:24 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 5C9E03A6A09; Thu, 29 Oct 2009 11:53:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1256842418!37217972!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 27605 invoked from network); 29 Oct 2009 18:53:39 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (136.182.1.13) by server-10.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Oct 2009 18:53:39 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate3.mot.com (8.14.3/8.14.3) with ESMTP id n9TIrXrp023526; Thu, 29 Oct 2009 11:53:38 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n9TIrX9d015784; Thu, 29 Oct 2009 13:53:33 -0500 (CDT) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n9TIrXiu015778; Thu, 29 Oct 2009 13:53:33 -0500 (CDT) 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: Thu, 29 Oct 2009 14:53:10 -0400 Message-ID: <274D46DDEB9F2244B2F1EA66B3FF54BC05C581C6@de01exm70.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-ipsecme-traffic-visibility-09 thread-index: AcpYyQ9lC3cgrSnQQZ2X8GGVnooQjg== From: "McCann Peter-A001034" To: , X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 30 Oct 2009 09:25:35 -0700 Cc: ipsec@ietf.org Subject: [IPsec] Gen-ART review of draft-ietf-ipsecme-traffic-visibility-09 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 18:53:25 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).=20 Please resolve these comments along with any other Last Call comments you may receive.=20 Document: draft-ietf-ipsecme-traffic-visibility-09 Reviewer: Pete McCann Review Date: 2009-10-29 IETF LC End Date: 2009-10-28 IESG Telechat date: unknown=20 Summary: One minor issue to discuss Major issues: none Minor issues:=20 Section 2: As can be seen, the WESP format extends the standard ESP header by the first 4 octets for IPv4 and by 8 octets for IPv6. The WESP header is integrity protected, along with all the fields specified for ESP in RFC 4303. Normally ESP wouldn't need to process encapsulation headers that appear prior to the SPI. Won't this require modification of the=20 ESP implementation, possibly breaking its modularity? Would it be problematic for certain algorithms to include this data? It might be good to state that. Nits/editorial comments: none From housley@vigilsec.com Fri Oct 30 09:43:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24AA43A684E for ; Fri, 30 Oct 2009 09:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.53 X-Spam-Level: X-Spam-Status: No, score=-101.53 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 b+U6MLZgiHe5 for ; Fri, 30 Oct 2009 09:43:50 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id D6BA13A682B for ; Fri, 30 Oct 2009 09:43:50 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id A9BD79A476D; Fri, 30 Oct 2009 12:44:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id MN0dUj8CbYZ5; Fri, 30 Oct 2009 12:44:06 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-173-66-67-45.washdc.fios.verizon.net [173.66.67.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 912A19A4736; Fri, 30 Oct 2009 12:44:23 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 30 Oct 2009 12:22:04 -0400 To: Yaron Sheffer ,IPsecme WG From: Russ Housley In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAA@il-ex01.ad.ch eckpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAA@il-ex01.ad.checkpoint.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Message-Id: <20091030164423.912A19A4736@odin.smetech.net> Subject: Re: [IPsec] #118: Reference for PKCS #7 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 16:43:52 -0000 It depends what you are actually doing.  PKCS#7 was the specification developed by RSA Labs.  They turned over change control to the IETF.  The IETF produced RFCs 2630, 3369, 3852, and 5652, all of which are backward compatible with RFC 2315 for the normal use cases.  I believe that all exceptions are addressed in the document.

Russ

At 07:18 PM 10/29/2009, Yaron Sheffer wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
         boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAAilex01adche_"

PKCS#7  should reference RFC 2315.
From paul.hoffman@vpnc.org Fri Oct 30 10:04:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E63A3A6A5C for ; Fri, 30 Oct 2009 10:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.742 X-Spam-Level: X-Spam-Status: No, score=-5.742 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 h67pFJA11Z-Z for ; Fri, 30 Oct 2009 10:04:42 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id A18323A69CA for ; Fri, 30 Oct 2009 10:04:42 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9UH4uvK032505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 10:04:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <82DFB96E88E54DE98E9B6B5F766C3EB8@trustworks.com> References: <82DFB96E88E54DE98E9B6B5F766C3EB8@trustworks.com> Date: Fri, 30 Oct 2009 10:04:55 -0700 To: "Valery Smyslov" , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Fw: Preshared key authentication in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 17:04:43 -0000 At 9:58 AM +0300 10/30/09, Valery Smyslov wrote: >Hi all, > >I'd like to reiterate my early message, which I haven't got answer to. >My concerns are: > >1. How padding pre-sahred key with string "Key Pad for IKEv2" > could help to avoid storing pre-shared key in IKE implementation > if prf is not known untill IKE_SA_INIT exchange is finished? The PRF (or set of PRFs) is known by the receiving party. If the two parties always only use one PRF, it is known. The padding is not a universal solution for the reasons you give, but it works in the common case of peers who know each other's crypto choices. >2. It is a bit unclear whether EAP generated key should also > be padded before use in IKE, or used directly. I'm pretty sure the key is used in its PRF form, not in its "as is" form, but I would want to hear from one or two implementers on that. --Paul Hoffman, Director --VPN Consortium From wierbows@us.ibm.com Fri Oct 30 14:56:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66BDF3A6A20 for ; Fri, 30 Oct 2009 14:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.854 X-Spam-Level: X-Spam-Status: No, score=-3.854 tagged_above=-999 required=5 tests=[AWL=-1.256, BAYES_00=-2.599, HTML_MESSAGE=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 OS9CiUak0rSV for ; Fri, 30 Oct 2009 14:56:09 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 68C573A6A13 for ; Fri, 30 Oct 2009 14:56:09 -0700 (PDT) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9ULqoKl029927 for ; Fri, 30 Oct 2009 17:52:50 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9ULuH8t1527994 for ; Fri, 30 Oct 2009 17:56:19 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9UHrnuw021453 for ; Fri, 30 Oct 2009 13:53:49 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9UHrnI5021450 for ; Fri, 30 Oct 2009 13:53:49 -0400 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAC@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAC@il-ex01.ad.checkpoint.com> X-KeepSent: 9CA175E0:D4783FD4-8525765F:0076DA73; type=4; name=$KeepSent To: IPsecme WG X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Fri, 30 Oct 2009 17:56:15 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 10/30/2009 17:56:16 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCCCDFE55CE38f9e8a93df938690918c0ABBFCCCDFE55CE3" Content-Disposition: inline Subject: Re: [IPsec] #120: CA indication with cert req - allowed types X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 21:56:10 -0000 --0__=0ABBFCCCDFE55CE38f9e8a93df938690918c0ABBFCCCDFE55CE3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable > Sec. 3.7 has: > The contents of the "Certification Authority" field are defined= only for X.509 certificates, which are types 4, 10, 12, and 13. >= Other values SHOULD NOT be used until standards-track specificati= ons that specify their use are published. > This excludes certificate requests of type 7, i.e. for CRLs. For requesting a specific CRL type 7 would make sense, in particular in > c= hain situations. Should we add it to the list of allowed types here? RFC 4945 states that implementations SHOULD NOT send CERTREQs for types= 7 and 8. If they are sent then an implementation MUST NOT require the recipient to respond and the recipient MAY ignore the request. Given t= hat I don't expect that it is common that implementations send CERTREQs wit= h type 7 or 8 to begin with. If they do I agree with Tero that an empty certificate authority field is probably sufficient. OTOH, I would not be opposed to adding RFC 4945's "SHOULD NOT send CERT= REQs for type 7 and 8" statement here. > OTOH, this allows type 10, which is unspecified and should be removed= . Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 = --0__=0ABBFCCCDFE55CE38f9e8a93df938690918c0ABBFCCCDFE55CE3 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

> Sec. 3.7 has:

      > The contents of the = "Certification Authority" field are defined only for X.509 ce= rtificates, which are types 4, 10, 12, and 13. > Other values SHOULD= NOT be used until standards-track specifications that specify their us= e are published.
> This excludes certificat= e requests of type 7, i.e. for CRLs. For requesting a specific CRL type= 7 would make sense, in particular in > chain situations. Should we = add it to the list of allowed types here?

RFC 4945 states that imple= mentations SHOULD NOT send CERTREQs for types 7 and 8. If they are sen= t then an implementation MUST NOT require the recipient to respond and = the recipient MAY ignore the request. Given that I don't expect that i= t is common that implementations send CERTREQs with type 7 or 8 to begi= n with. If they do I agree with Tero that an empty certificate authori= ty field is probably sufficient.

OTOH, I would not be oppos= ed to adding RFC 4945's "SHOULD NOT send CERTREQs for type 7 and 8= " statement here.

> OTOH, this allows typ= e 10, which is unspecified and should be removed.



Dave Wierbowski


z/OS Comm Server Developer

Phone:
Tie line: 620-4055
External: 607-429-4055

= --0__=0ABBFCCCDFE55CE38f9e8a93df938690918c0ABBFCCCDFE55CE3-- From wierbows@us.ibm.com Fri Oct 30 15:24:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196473A6A57 for ; Fri, 30 Oct 2009 15:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.926 X-Spam-Level: X-Spam-Status: No, score=-4.926 tagged_above=-999 required=5 tests=[AWL=1.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, 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 pDl-fO5r7OI3 for ; Fri, 30 Oct 2009 15:24:07 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 2ED913A6A36 for ; Fri, 30 Oct 2009 15:24:07 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9UMGndt003600 for ; Fri, 30 Oct 2009 18:16:49 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9UMOKPs108012 for ; Fri, 30 Oct 2009 18:24:24 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9UMOKWA028147 for ; Fri, 30 Oct 2009 18:24:20 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9UMOKSn028141 for ; Fri, 30 Oct 2009 18:24:20 -0400 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAB@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAB@il-ex01.ad.checkpoint.com> X-KeepSent: FDC7DB5B:2E4486DD-8525765F:00791E79; type=4; name=$KeepSent To: IPsecme WG X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Fri, 30 Oct 2009 18:24:18 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 10/30/2009 18:24:20 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCCCDFEA98E98f9e8a93df938690918c0ABBFCCCDFEA98E9" Content-Disposition: inline Subject: Re: [IPsec] #119: Which certificate types can be mixed in one exchange? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 22:24:08 -0000 --0__=0ABBFCCCDFEA98E98f9e8a93df938690918c0ABBFCCCDFEA98E9 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable > Should be added to Sec. 3.6, probably as a new subsection. > One Hash & URL (H&U) bundle only. Or... > One Raw RSA key, or... > One or more cert payloads of either type 4 or H&U (type 12) I think there are cases where it makes sense to send any combination of= types 7, 12, and 13. I do not think we should restrict which of those certificate types can be mixed in one exchange. >Can have one or more CRLs and/or OCSP content (RFC 4806) added to any = of the above, except for Raw RSA. I thought sending CRLs inline.was strongly discouraged, but I agree th= at if an implementation sends them that it would be logical to include one= or more CRLs. Are we planning on updating the list of certificate encoding types to include type 14 (OSCP content)? If yes then I do not see that in the current bis draft. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 = --0__=0ABBFCCCDFEA98E98f9e8a93df938690918c0ABBFCCCDFEA98E9 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

> Should be added to Se= c. 3.6, probably as a new subsection.

> One Hash & URL (H= &U) bundle only. Or...

> One Raw RSA key, or..= .

> One or more cert payl= oads of either type 4 or H&U (type 12)

I think there are cases wh= ere it makes sense to send any combination of types 7, 12, and 13. I d= o not think we should restrict which of those certificate types can be = mixed in one exchange.

>Can have one or more C= RLs and/or OCSP content (= RFC 4806) adde= d to any of the above, except for Raw RSA.
I thought sending CRLs inline.was strongly discouraged, but I agree th= at if an implementation sends them that it would be logical to include = one or more CRLs.

Are we planning on updating the list of certificate encoding types to i= nclude type 14 (OSCP content)? If yes then I do not see that in the cu= rrent bis draft.

Dave Wierbowski


z/OS Comm Server Developer

Phone:
Tie line: 620-4055
External: 607-429-4055


= --0__=0ABBFCCCDFEA98E98f9e8a93df938690918c0ABBFCCCDFEA98E9-- From wierbows@us.ibm.com Fri Oct 30 15:34:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B273A688C for ; Fri, 30 Oct 2009 15:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.583 X-Spam-Level: X-Spam-Status: No, score=-5.583 tagged_above=-999 required=5 tests=[AWL=1.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 08Jv55cLw-+N for ; Fri, 30 Oct 2009 15:34:07 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id 9FE7C3A6800 for ; Fri, 30 Oct 2009 15:34:07 -0700 (PDT) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e8.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9UIRGpc014462 for ; Fri, 30 Oct 2009 14:27:16 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9UMUih0099714 for ; Fri, 30 Oct 2009 18:30:44 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9UMUiul032324 for ; Fri, 30 Oct 2009 18:30:44 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9UMUibW032316 for ; Fri, 30 Oct 2009 18:30:44 -0400 In-Reply-To: <19178.63776.974040.367597@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAC@il-ex01.ad.checkpoint.com> <19178.63776.974040.367597@fireball.kivinen.iki.fi> X-KeepSent: C3B20FF4:BF2F748A-8525765F:007B7318; type=4; name=$KeepSent To: IPsecme WG X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Fri, 30 Oct 2009 18:30:42 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 10/30/2009 18:30:44 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCCCDFE8F5888f9e8a93df938690918c0ABBFCCCDFE8F588" Content-Disposition: inline Subject: Re: [IPsec] #120: CA indication with cert req - allowed types X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 22:34:08 -0000 --0__=0ABBFCCCDFE8F5888f9e8a93df938690918c0ABBFCCCDFE8F588 Content-type: text/plain; charset=US-ASCII > So the text most likely should say that "For other values the > certificate authority field contents is not defined, and can be > anything (or empty) until specifications that specify their contents > is published." I do not think they can be anything. I think they need to be empty until specifications that specify their contents are published. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 --0__=0ABBFCCCDFE8F5888f9e8a93df938690918c0ABBFCCCDFE8F588 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> So the text most likely should say that "For other values the
> certificate authority field contents is not defined, and can be
> anything (or empty) until specifications that specify their contents
> is published."
I do not think they can be anything. I think they need to be empty until specifications that specify their contents are published.

Dave Wierbowski


z/OS Comm Server Developer

Phone:
Tie line: 620-4055
External: 607-429-4055


--0__=0ABBFCCCDFE8F5888f9e8a93df938690918c0ABBFCCCDFE8F588-- From paul.hoffman@vpnc.org Sat Oct 31 16:41:50 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0375E3A6843 for ; Sat, 31 Oct 2009 16:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.759 X-Spam-Level: X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 zwkCQyH5D6Ao for ; Sat, 31 Oct 2009 16:41:48 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D9DE13A62C1 for ; Sat, 31 Oct 2009 16:41:48 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9VNg56d015888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Oct 2009 16:42:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sat, 31 Oct 2009 16:34:19 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Rechartering discussion in Hiroshima X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 23:41:50 -0000 Greetings again. As Yaron and I have mentioned on the mailing list in the past few weeks, one of the next big tasks for the WG is to decide if we want to ask the IESG if we can add new items to the WG charter. To that end, we asked for proposals for which there were already Internet Drafts, or for which there would be Internet Drafts soon. As you can see at , we got seven such proposals. Our next task is to start discussing whether or not the WG as a whole would want to include these in our charter. We will have the first discussion of that at the IETF meeting in Hiroshima. The tenor of the discussion will be whether or not the WG wants to take on the work, not the technical specifics of the drafts listed. It is important to remember a few things about rechartering a WG: - If we want to amend our charter, we do so in a request to the IESG and the IAB. As RFC 2418 explains: Rechartering (other than revising milestones) a working group follows the same procedures that the initial chartering does (see section 2). The revised charter must be submitted to the IESG and IAB for approval. As with the initial chartering, the IESG may approve new charter as-is, it may request that changes be made in the new charter (including having the Working Group continue to use the old charter), or it may decline to approve the rechartered working group. In the latter case, the working group is disbanded. - A request to recharter contains a text description of the intended work, not just the name of an Internet Draft that the WG wants to use as the basis for work. - Our current charter () says: The WG shall not consider adding new work items until one or more of its documents progress to IESG evaluation. At that time, the WG can propose rechartering. We have indeed progressed many documents to IESG evaluation, and a few beyond. Yaron and I intend to keep the total of WG items to six, as in our current charter. - There needs to be sufficient interest in a proposed item before we put it in the charter. We thought we had such interest for the original set of work items, but Yaron and I have had to do a bit of public grovelling to get sufficient reviews for some of them. We will attempt to avoid that for any new charter items, meaning that we will be strict about promises for review. Given this, please start to take a look at the items at . We will have presentations on them in Hiroshima, and more discussion on the list after that. We will then poll about the items, and Yaron and I will propose a way forwards based on the results of the poll. --Paul Hoffman, Director --VPN Consortium