[IPsec] New version of the IPsec Roadmap Internet Draft
We just submitted an updated (version 04) roadmap draft. We would like to thank 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 Table 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 Authentication Methods) is in the TOC. Section 1. In fact, it would be nice if Sec. 3 mentioned that IPsec and IKE apply equally 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 algorithms only in relation to ESP. However, RFC 4543 defines the use of AES-GMAC for both ESP and AH. Same for Section 5.3 RESPONSE: AES-GMAC is only considered a combined mode algorithm in ESP; for AH it is simply an integrity-protection algorithm Section 2.3.1, second paragraph -- The first sentence refers to two SA pairs and then the following sentences refer to two SAs. Perhaps we should make this transition less abrupt? I suggest inserting a sentence after the first to indicate that "SA" can be used to refer not only to the unidirectional 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" - this 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, it 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 section 3 (IPsec) although 3947 is about IKE, and yet they are separated rather than following one another. I think that either 3947 should be moved to section 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 mentioned 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 --
[IPsec] USGv6 Testing Program to begin Operation November 30th, 2009
Following the publication of the USGv6 Profile version 1.0, NIST and its testing partners have been developing the USGv6 Testing Program. Various aspects of the program have been offered for review to various constituencies over the past 18 months or so. The program will begin operations on November 30th 2009, with accredited labs testing IPv6 products to USGv6 test suites. The attached announcement offers the public an opportunity to review the operational documents, test suites and website prior to launch. The comment period concludes on November 16th to give us time for final emendation. We look forward to your comments. Stephen Nightingale USGv6 Testing Program. NIST-announce-20091016.pdf Description: NIST-announce-20091016.pdf ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document
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.
Sheila
From: Tero Kivinen [kivi...@iki.fi]
Sent: Tuesday, October 20, 2009 9:40 AM
To: ipsec@ietf.org
Cc: Frankel, Sheila E.; pasi.ero...@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.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document
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 separate section for IKE Encrypted Payload algorithms, that contains a subset of the Transform Type 1 (encryption) algorithms? Also, is sloppiness enough to account for both NULL encryption and AES-CTR being specified for IKEv2 - and noone from the WG noticing either? Sheila From: Paul Hoffman [paul.hoff...@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 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [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? 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 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. 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 versions: classic integ prot and also combined mode From: ipsecme issue tracker [t...@tools.ietf.org] Sent: Friday, October 16, 2009 8:10 PM To: paul.hoff...@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.hoff...@… | Owner: sheila.fran...@… 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: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/111> ipsecme <http://tools.ietf.org/ipsecme/> ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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 [t...@tools.ietf.org] Sent: Friday, October 16, 2009 8:25 PM To: paul.hoff...@vpnc.org; Frankel, Sheila E. Subject: [ipsecme] #112: Truncation of SHA-1 ICVs #112: Truncation of SHA-1 ICVs ---+ Reporter: paul.hoff...@… | Owner: sheila.fran...@… 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: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/112> ipsecme <http://tools.ietf.org/ipsecme/> ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #114: Expired drafts, especially BEET
#114: Expired drafts, especially BEET Proposed changes to Roadmap doc: 1) Sheila and Suresh do not advocate the addition of the BEET Internet Draft 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 authenticated keying material for use within those SAs. The standard peer authentication methods used by IKEv1 (pre-shared secret keys and digital certificates) had several shortcomings related to use of IKEv1 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 information needed in order to access the internal network. 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). 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. From: ipsecme issue tracker [t...@tools.ietf.org] Sent: Friday, October 16, 2009 8:29 PM To: paul.hoff...@vpnc.org; Frankel, Sheila E. Subject: [ipsecme] #114: Expired drafts, especially BEET #114: Expired drafts, especially BEET ---+ Reporter: paul.hoff...@… | Owner: sheila.fran...@… 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: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/114> ipsecme <http://tools.ietf.org/ipsecme/> ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #115: Camellia req levels for IKEv2
#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) 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 of block mode encryption, provide enough detail to allow the use of Camellia-CBC algorithms within IKEv2. 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 [t...@tools.ietf.org] Sent: Friday, October 16, 2009 8:29 PM To: paul.hoff...@vpnc.org; Frankel, Sheila E. Subject: [ipsecme] #115: Camellia req levels for IKEv2 #115: Camellia req levels for IKEv2 ---+ Reporter: paul.hoff...@… | Owner: sheila.fran...@… 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: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/115> ipsecme <http://tools.ietf.org/ipsecme/> ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs
Thanks, Scott. So is the general consensus that we should just leave HMAC-SHA-1 and HMAC-MD5 as the only algs for which IKEv2 can negotiate either a truncated or non-truncated version? Your comment also reminded me that RFCs 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:smoo...@us.ibm.com] Sent: Tuesday, October 27, 2009 12:17 PM To: Frankel, Sheila E. Cc: ipsec@ietf.org; ipsec-boun...@ietf.org; Tero Kivinen; Paul Hoffman; suresh.krish...@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 versions of HMAC-SHA2-*. RFC 4868 stipulates for IKE and IPsec in general that the 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 (smoo...@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 , "suresh.krish...@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 [t...@tools.ietf.org] Sent: Friday, October 16, 2009 8:25 PM To: paul.hoff...@vpnc.org; Frankel, Sheila E. Subject: [ipsecme] #112: Truncation of SHA-1 ICVs #112: Truncation of SHA-1 ICVs ---+ Reporter: paul.hoff...@... | Owner: sheila.fran...@... 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: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/112> ipsecme <http://tools.ietf.org/ipsecme/> ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Resolving Roadmap Issue #111
If there are no further comments, this issue will be closed. Issue #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3? ==> As a result of Tero's comments, added #2 below and revised #3. #1 and #4 remain unchanged from the previous email sent to the list. Proposed changes to Roadmap doc: 1) Add text to section 5.4 (Combined Mode Algorithms) Additional text (unchanged from previous email): 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. 2) Add text to section 5.3.4 (RFC 4543, The use of GMAC in IPsec ESP and AH): (added since previous email) AES-GMAC cannot be used by IKEv2 to protect its own SAs, since IKEv2 traffic requires encryption. 3) Change IKEv2 requirements level Requirements levels for AES-GMAC: old IKEv2 - optional new IKEv2 - N/A 4) Move RFC 4543 to section on combined mode algorithms, since it has 2 versions: classic integ prot and also combined mode ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Resolving Roadmap Issue #112
If there are no further comments, this issue will be closed. Issue #112: Truncation of SHA-1 ICVs ==> Several people commented that the non-truncated versions of HMAC-SHA-1 and HMAC-MD5 are only intended to be used for Fibre Channel traffic. Thus, IKEv2 can only negotiate these versions for that use, but not for IKEv2 or IPsec-v3 SAs. The revised text (below) reflects these comments. Proposed change to Roadmap doc: Add text to Section 5.3 (Integrity-Protection Algorithms) Additional text (revised since previous email): 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 IKEv2 SAs, they are also truncated. For IKEv1, HMAC-SHA-1 and HMAC-MD5 are negotiated by requesting the hash algorithms SHA-1 and MD5, respectively; these algorithms are not truncated when used to protect an IKEv1 SA. 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 of the algorithm. However, only the truncated version is used for IKEv2 SAs and for IPsec SAs. The non-truncated version is reserved for use by the Fibre Channel protocol [RFC4595]. 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Resolving Roadmap Issue #114
Issue #114: Expired drafts, especially BEET ==> Tero and Yaron suggested wording changes. The 2nd paragraph below contains those changes. #114: Expired drafts, especially BEET Proposed changes to Roadmap doc: Add text to the introductory section for IKEv1, Section 4.1.1: Additional text (revised since last email): 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 keys and digital certificates) had several shortcomings related to use of IKEv1 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 information needed in order to access the internal network. Several Internet Drafts were written to address these problems: Extended Authentication withn IKE (XAUTH) (draft-beaulieu-ike-xauth and its predecessor draft-ietf-ipsra-isakmp-xauth) and The ISAKMP Configuration Method (draft-dukes-ike-mode-cfg and its predecessor draft-ietf-ipsec-isakmp- 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. These solutions were not standardized, and different implementations implemented different versions. Thus, 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 known security issues. Thus, use of these solutions is not recommended. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Resolving Roadmap Issue #115
If there are no further comments, this issue will be closed. Issue #115: Camellia req levels for IKEv2 ==> Tero commented that this was fine with him. 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) 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 of block mode encryption, provide enough detail to allow the use of Camellia-CBC algorithms within IKEv2. 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Suggested solution to Roadmap Issue #113: Use of AES-XCBC in IKE
This is an initial attempt to resolve Issue #113. We would appreciate comments/suggestions/alternate approaches. #113: 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 recommend (SHOULD) its use? 2) If AES-XCBC and AES-XCBC-PRF can be used in IKEv1, what should be proposed? What should you propose if you want AES-XCBC for both a PRF and an integrity-protection algorithm in IKEv1? Proposed change to Roadmap doc: Add text to Section 5.5 - Pseudo-Random Functions (PRFs): For each IKEv2 SA, the peers negotiate both a PRF algorithm and an integrity-protection algorithm; the former is used to generate keying material and other values, and the latter is used to provide protection to the IKE SA's traffic. IKEv1's approach is more complicated. IKEv1 [RFC2409] does not specify any PRF algorithms. For each IKEv1 SA, the peers agree on an unkeyed hash function (e.g., SHA-1). IKEv1 uses the HMAC version of this function to generate keying material and to provide integrity protection for the IKE SA. If the peers want to use a PRF that is not an HMAC variant (e.g., AES-XCBC-PRF-128), they must negotiate both a PRF and a hash function. If AES-XCBC-PRF-128 is the negotiated PRF, then IKEv1 would use AES-XCBC-PRF-128 (not truncated) as a PRF and AES-XCBC-MAC-96 (truncated) for integrity-protection. The negotiated hash algorithm would be used for example when generating the NAT-D [RFC3947] payloads. If an IKEv1 proposal includes a PRF algorithm but not a hash, it must be rejected, as specified in [RFC2409]. NOTE: This solution would require adding an IANA value to the iana-ipsec-registry for AES-XCBC-PRF-128 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Response to Pasi's AD comments on the roadmap draft
Here are our responses to Pasi's AD comments on the roadmap doc. We have indicated which changes we plan to make, and which ones we would prefer to handle somewhat differently. We would appreciate hearing from the list, both those who agree and those who don't. We will send a separate email listing those RFCs that Pasi wants us to delete from the roadmap and those he would like us to add. Sheila and Suresh > - I'm not very happy about the use of MUST, SHOULD, etc. in this > document. This is supposed to be a purely informational guide to other > documents, not something that sets requirements (of any level) for > anyone. The only places these words are used is in re-phrasing requirements specified in RFCs. So it doesn't set any requirements, just re-states them. > > For cryptographic algorithms, we already have separate documents that > specify the requirement levels. IMHO repeating them here just means > the two places will soon be inconsistent (which is not helpful for the > audience here). If the WG has considered this and decided the > repeating them here is useful, I would strongly suggest just having > the tables in Appendix B (with explicit note that they're probably out > of date by the time the reader finds them), and removing them from > Section 5.x. There is a lot of confusion in the vendor and user community about this issue, and that is why we felt it would help to have a central repository with this information. Obviously, any docs that come after the roadmap could change things, but even knowing that this is a snapshot as of a specific date is helpful - then you just have to examine docs that come after this to see what has changed. We feel that it is useful to state the requirements together with the relevant RFCs, along with explanations (e.g. no RFC, no IANA #) for those that are undefined. In addition, if new RFCs and/or IANA #'s come along, it will be clear what is responsible for a potential change in that algorithm's applicability. We think that the summary table is a useful reference tool, but it's hard to read without being able to check back to the relevant RFC requirements. It does make sense to state, in the 2 places that we describe these requirement levels, that this is a snapshot as of March 2010 (or a later publication date) and is subject to change in future. > > For things other than cryptographic algorithms, I'm not sure if > talking about "requirements levels" even makes that much > sense. Consider, for example, Section 4.2.4.2 (IKEv2 redirect): > > Requirements levels for RFC5685: > IKEv1 - N/A > IKEv2 - optional > > This is not really specifying any requirement level; a phrasing > like "This extension applies only to IKEv2, not IKEv1" would IMHO > be more accurate. Text in most other sections (than crypto algs) > could be rephrased similarly. > Originally, we just had req levels for algs - someone in the WG requested that we extend it to include all of the basic IKE and IPsec docs, the WG chairs concurred, and we added them. We would like to see the req levels remain for the algs, but we don't feel equally strongly about the other docs. Adding text to the RFC descriptions would be fine. Do you have any objection to the summary table for these docs? > - Appendix B: I'm trying to match table B against RFC 4307/4835 and > I can't quite get them to match. For example, RFC 4307 lists > AUTH_AES_XCBC_96 as "SHOULD+", while the column "IKEv2" here says > "optional". This suggests that perhaps even including this table > isn't such a good idea... > RFC 4307 is a very problematic RFC. There are 2 lists of required algorithms for IKEv2. Section 3.1.1 (Encrypted Payload Algorithms) has 1 list, which specifies the MUST and SHOULD algs for encryption and integrity, but does not mention AES-XCBC. Then there are different lists in section 3.1.3 (encryption) and 3.1.5 (integrity). I (Sheila) had originally assumed that section 3.1.1 pertained to IKEv2 payloads and the other sections pertained to algorithms that IKEv2 negotiated for IPsec. The WG chairs and others disagreed, feeling that this RFC was hastily written and contradictory. We took section 3.1.1 to be definitive. I guess we should explain this in the roadmap. But it's problems like this that led us to include the requirements levels in the roadmap. > - Section 5.4: "Since combined mode algorithms are not a feature > of IPsec-v2, these IKEv1 implementations are used in conjunction with > IPsec-v3." I'm not sure if this is really a good way to describe > the situation; after all, GCM-for-ESP (RFC 4106) predates IPsec-v3... > > I'd suggest something like "Although IPsec-v2 ESP [RFC2406] did not > originally include combined mode algorithms, some IKEv1 > implementations have added the capability to negotiate combined mode > algorithms for use in IPsec SAs; these implementations do not include > the capability
[IPsec] Pasi's AD comments on roadmap doc - RFCs to add/delete
Here are the RFCs that Pasi suggested adding/removing from the roadmap doc. If anyone has any strong opinions either pro or con, now's the time to speak up. Sheila and Suresh several groups of RFCs that Pasi wants us to remove: 1) RFCs that define how to configure IPsec for use in other protocols, but don't modify/extend how IPsec works (We would prefer to keep these in the roadmap): 8.1.1. RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways 8.1.2. RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways 8.1.5. RFC 5213, Proxy Mobile IPv6 8.1.6. RFC 5268, Mobile IPv6 Fast Handovers 8.1.7. RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management 8.2.1. RFC 4552, Authentication/Confidentiality for OSPFv3 2) MIKEY: creates security associations for SRTP, not IPsec -- so it's not really relevant for this document 6.7. RFC 3830, MIKEY: Multimedia Internet KEYing 6.8. RFC 4738, MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) 6.9. RFC 5197, On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions 6.10. RFC 4563, The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY) 6.12. RFC 4650, HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY) 6.13. RFC 5410, Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0 3) I'm not sure what 4534/4535 have to do with IPsec; it doesn't look like it supports creating IPsec SAs, for example. 6.5. RFC 4535, GSAKMP: Group Secure Association Key Management Protocol 6.6. RFC 4534, Group Security Policy Token v1 4) not about IPsec, but non-IPsec approaches to securing multicast; so they don't really belong here. 6.14. RFC 4082, Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction 6.15. RFC 4442, Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA) 6.16. RFC 4383, The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol RFCs that Pasi suggests adding: RFC 2521, ICMP Security Failures Messages (E, Mar 1999) RFC 2709, Security Model with Tunnel-mode IPsec for NAT domains (I, Oct 1999) RFC 3329, Security Mechanism Agreement for the Session Initiation Protocol (SIP) (S, Jan 2003) RFC 4322, Opportunistic Encryption using the Internet Key Exchange (IKE) (I, Dec 2005) RFC 4705, GigaBeam High-Speed Radio Link Encryption (I, Oct 2006) RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario (S, Oct 2007) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Announcing the USGv6 Testing Meeting at NIST
Announcing the USGv6 Testing Meeting at NIST. To be held on Thursday May 20th 2010 in the AML Conference Room, Building 215 Room C103, from 9am till 5pm. Following publication of the USG Profile NIST has established a testing program to determine products' compliance to USGv6 capabilities. There are at present 2 accreditors and 2 accredited test laboratories enrolled in the program, with more test laboratories in consideration. July 2010 marks the date when USG Federal Agencies begin to make IT acquisitions using the USGv6 profile version 1.0. We wanted to host a public meeting to give: - a review of how the testing program is operating. - an opportunity for feedback from Stakeholders, including test laboratories, product vendors and USG Agencies. Accordingly we seek discussion inputs to include: - statements from accredited and prospective test laboratories. - statements/questions and issues from Agencies and users. - statements, questions and issues from USGv6 product vendors. Issues are expected to include: - testing operations and interlaboratory comparisons. - USGv6 capabilities and requirements. - Suppliers Declaration of Conformity. There will also be some discussion of the forthcoming USGv6 profile version 2. A full Agenda will be posted to signed up attendees closer to the day of the meeting. Due to room size limitations there can be a maximum of about 70 participants at this meeting, and attendance from any one company may need to be limited. Reply to usgv6-proj...@antd.nist.gov if you wish to participate, giving full name, company affiliation, title, contact details and whether you are a U.S. citizen. Please also let us know if you have issues you wish to present, with a maximum of 2 or 3 slides, and speaking time limited depending on the response. For further information, please contact Stephen Nightingale (ni...@nist.gov) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Roadmap -07: two minor and one major comments
We just submitted version -08 of the Roadmap doc. As Yaron requested, we changed the reference in section 5.2.4 and eliminated Appendix A. We left RFC 4359 in the doc, since some (but not all) of the msec RFCs were deleted, but we felt this one should remain. (It's not one of the RFCs that Pasi wanted deleted.) Sheila and Suresh From: ipsec-boun...@ietf.org [ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer [yaronf.i...@gmail.com] Sent: Sunday, June 27, 2010 2:38 AM To: IPsecme WG Subject: [IPsec] Roadmap -07: two minor and one major comments 5.2.4: [draft-ietf-ipsecme-aes-ctr-ikev2] is used as a reference, instead of [ipsecme-2]. 6.5 (rfc 4359 on using RSA with ESP/AH): if all of msec goes away, I don't see a reason to leave this one in. There's absolutely no reason to implement it other than multicast. Also, per my comment to -06, I still think that Appendix A (req levels for RFCs that are *not* algorithms) needs to go: - It mostly consists of empty space, "optional" and "N/A". - It adds normative weight to an informative document. - It is of little use to implementers. People will be reading the roadmap doc itself to decide what RFCs they need in their product, based on market needs. Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Roadmap doc updated in response to Gen-ART Review
An updated IPsec/IKE roadmap (version 09) was submitted in response to the Gen-ART review. Here are the changes that were made in response to that review: > I found one open issue - Sections 5.4.1 and 5.4.2 mis-state the applicability > of combined mode algorithms to IPsec-v2. All of the other comments in this > review are minor. See below. > Section 2.2 lists the RFC # range for IPsec-v1. Please also list the RFC > # ranges for IPsec-v2 and IPsec-v3. The v1 RFCs are mentioned here for completeness, since they are not included elsewhere. For v2 and v3, added the phrase "see Section 3.1.x for the RFC descriptions." > ** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined mode > algorithms are "not a feature of IPsec-v2" and hence lists them as N/A. > That's not correct. The correct situation is: > - Combined mode algorithms for ESP can be negotiated as encryption > algorithms (the integrity protection algorithm would typically > be omitted proposals that do this). > - Combined mode algorithms cannot be used with IKEv1, as they're > incompatible with its design (see the Introduction section of > RFC 5282 for a more detailed explanation). > Hence the N/A entries for IKEv1 are correct, but both AES-CCM and AES-GCM > should be "optional" for ESPv2 (and the NOTE should be revised accordingly). The roadmap already includes the following statement in Section 5.4: Although ESP-v2 did not originally include combined mode algorithms, 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. Added the following to the NOTEs for the combined mode algorithms: Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. > Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC 5116. RFC 5116 described the underlying framework, but does not mention IKE or IPsec. Just as this doc does not include the RFCs that define the SHA-1 algorithm or the HMAC algorithm, it does not include this framework RFC. > Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3. If that > is correct, it should be stated. Added "This document applies only to IKEv1 and IPsec-v2; it does not apply to IKEv2 and IPsec-v3." > Section 8.8.1 also appears to be IPsec-v2 only, and in addition to stating > that should comment that this was not widely adopted, and NAT traversal > is the commonly used mechanism to deal with NATs. Added "Although the model presented here uses terminology from IKEv1, it can be deployed within IKEv1, IKEv2, IPsec-v2 and IPsec-v3. > In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel". If you want > to cite the RFCs involved, IP over FC is RFC 4338 and FC over IP is RFC 3821. Deleted "/SCSI" In general, the roadmap only cites IKE/IPsec-related RFCs, but not the RFCs that define the non-IKE/IPsec underlying protocols. Although RFC 3821 mentions the use of IKE/IPsec for Fibre Channel, unlike RFC 4595, it does not alter IKE/IPsec in any way. > idnits 2.12.04 found some minor nits: > ** There are 4 instances of too long lines in the document, the longest one > being 3 characters in excess of 72. Fixed this. Sheila and Suresh ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] COMMENT:
We just submitted an updated version (-10) of the IPsec/IKE Roadmap doc. In accordance with Sean's recommendations, we addressed Tim Polk's comments as follows: > Comment: > (1) I understand that this is a forklift upgrade for RFC 2411, so the usual > "Changes Since ..." section would not be helpful. However, this document > has a very similar title and does obsolete 2411 if approved. Perhaps a few > sentences in the intro to describe that relationship would be useful! The original intro includes: 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]. Added the following: The obsoleted IPsec roadmap [RFC2411] briefly described the interrelationship of the various classes of base IPsec documents. The major focus of [RFC2411] was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. > (2) RFC 5282 should be added to the list of base documents in section > 4.1.2, IKEv2. As noted in section 5.4, 5282 added the capability to negotiate > combined mode algorithms to IKEv2. IKEv2 already has the capability to negotiate combined mode algs for use in ESP/AH. RFC 5282 adds the capability to use combined mode algs for IKEv2's own traffic. This is one of a number of add-ons; it is not part of the base IKEv2. > (3) Section 5.4.3 is misplaced. GMAC is an Integrity protection algorithm > and should appear in section 5.3. This will necessitate forward pointers > to section 5.4, since it is based on a combined mode algorithm, but it does > not fit with the other algorithms in 5.4 which are providing both encryption > and integrity-protection. As stated in Section 5.4.3, GMAC has 2 versions: an integrity protection alg for AH, and a combined mode alg with null enc for ESP. We chose to place it with the combined mode algs, but mentioned it in Section 5.3 (the intro section for integrity protection algs). > (4) In section 5.2.1, last sentence of the first paragraph: > > This number (the value 11 for ESP_NULL) is found on the IANA registries > for both IKEv1 and IKEv2, but it is not mentioned in this RFC. > > "this RFC" is ambiguous - I gather the authors meant RFC 2410 (since the > value is clearly mentioned in *this* RFC). I suggest: > > s/this RFC/[RFC2410]/ DONE Sheila and Suresh From: Sean Turner [turn...@ieca.com] Sent: Thursday, August 12, 2010 12:15 PM To: draft-ietf-ipsecme-road...@tools.ietf.org Cc: ipsecme-cha...@tools.ietf.org Subject: Re: COMMENT: The state of this document is now "Approved: point raised - write up needed". I'd like the authors to generate a new version that address #1 and #4. I don't think we should do #2 or #3. They are comments not discusses so we don't have to get him to agree to us not doing them. I'll be watching for the new version. spt ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Updated ESP/AH algorithm I-D
Hi David and Wajdi, Your updated ESP/AH algorithm doc looks great, and is very much needed. I just have one comment. You speak of the 2 services provided by ESP and AH as confidentiality and "data origin authentication." As I'm sure you know, authentication is used in different ways by different communities. I believe that in most of the IPsec docs the 1st service is referred to interchangeably as encryption and confidentiality; the 2nd service is interchangeably referred to as authentication and integrity protection. However, in RFC 4303 (ESP) it states: "Data origin authentication and connectionless integrity are joint services, hereafter referred to jointly as "integrity"." In your doc, the integrity-protection aspect is not mentioned at all, and I believe that is a critical oversight. Sheila Frankel ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Updated ESP/AH algorithm I-D
Steve, Perhaps I wasn't clear in the main thrust of my message. I'm not quibbling about terminology; I'm concerned that the I-D is lacking some vital information. The I-D discusses 2 services provided by ESP and AH: confidentiality and data origin authentication. My point was that the 2nd service includes connectionless integrity protection as well - which is not identical to data origin authentication - and therefore integrity protection should be mentioned in the I-D. Sheila From: Stephen Kent [k...@bbn.com] Sent: Tuesday, March 12, 2013 11:09 AM To: ipsec@ietf.org; Frankel, Sheila E. Subject: Re: [IPsec] Updated ESP/AH algorithm I-D Sheila, I did a quick check of 4301, and it uses the term "confidentiality" consistently when referring to the service, and uses "encryption" to refer to the mechanism. They are not used interchangeably. The same seems to apply to use of terminology re data origin authentication, integrity, etc. Steve On 3/12/13 10:01 AM, Frankel, Sheila E. wrote: > Hi David and Wajdi, > > Your updated ESP/AH algorithm doc looks great, and is very much needed. I > just have one comment. You speak of the 2 services provided by ESP and AH as > confidentiality and "data origin authentication." As I'm sure you know, > authentication is used in different ways by different communities. I believe > that in most of the IPsec docs the 1st service is referred to interchangeably > as encryption and confidentiality; the 2nd service is interchangeably > referred to as authentication and integrity protection. However, in RFC 4303 > (ESP) it states: "Data origin authentication and connectionless integrity are > joint services, hereafter referred to jointly as "integrity"." In your doc, > the integrity-protection aspect is not mentioned at all, and I believe that > is a critical oversight. > > Sheila Frankel ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Updated ESP/AH algorithm I-D
Steve, I certainly didn't intend any insults, and I wouldn't characterize the wording in the RFC's as sloppy. It's very common to use these terms somewhat interchangeably. Sorry if my wording could be construed as a criticism. That's the last thing I'd want, considering the tremendous amount of hard work that went into the RFCs. Regards, Sheila From: Stephen Kent [k...@bbn.com] Sent: Tuesday, March 12, 2013 1:05 PM To: ipsec@ietf.org; Frankel, Sheila E. Subject: Re: [IPsec] Updated ESP/AH algorithm I-D Sheila, I understood your point. I objected to your statement that other IPsec RFC were sloppy in the use of security service/mechanism terminology. Steve > Steve, > > Perhaps I wasn't clear in the main thrust of my message. I'm not quibbling > about terminology; I'm concerned that the I-D is lacking some vital > information. The I-D discusses 2 services provided by ESP and AH: > confidentiality and data origin authentication. My point was that the 2nd > service includes connectionless integrity protection as well - which is not > identical to data origin authentication - and therefore integrity protection > should be mentioned in the I-D. > > Sheila > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)
Hi Dave, I don't have any strong feelings about MUST NOT vs. SHOULD NOT, but I wonder if it would help to clarify the reasoning behind it. For these algorithms, RFC6071 (IPsec/IKE Roadmap) says: - Reuse of the IV with the same key compromises the data's security; thus, AES-GCM should not be used with manual keying. - Reuse of the IV with the same key and nonce compromises the data's security; thus, AES-CTR should not be used with manual keying. - Reuse of the IV with the same key compromises the data's security; thus, AES-CCM should not be used with manual keying. - Reuse of the salt value with the same key compromises the data's security; thus, AES-GMAC should not be used with manual keying. Instead of just saying "these algorithms require IKE", could we give a slightly more detailed explanation? something like: "These algorithms require the use of an automated key negotiation protocol (e.g. IKE) to avoid reuse of important parameters, whose reuse compromises the algorithm's security." (Not the best wording, but you get the idea!) But if you don't add this, I wouldn't object to publication of the RFC. Sheila Frankel From: IPsec on behalf of Waltermire, David A. (Fed) Sent: Thursday, March 16, 2017 1:14:33 PM To: ipsec@ietf.org Cc: draft-ietf-ipsecme-rfc7321...@ietf.org; Ben Campbell; ipsecme-cha...@ietf.org; p...@nohats.ca; The IESG Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) Comments below. > -Original Message- > From: Paul Wouters [mailto:p...@nohats.ca] > Sent: Thursday, March 16, 2017 1:08 PM > To: Ben Campbell > Cc: The IESG ; draft-ietf-ipsecme-rfc7321...@ietf.org; > ipsec@ietf.org; ipsecme-cha...@ietf.org; Waltermire, David A. (Fed) > > Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: > (with COMMENT) > > On Wed, 15 Mar 2017, Ben Campbell wrote: > > > -3: I wonder why "... is not to be used..." is not "... MUST NOT be > > used...". But the section goes on to say if you do it anyway, you MUST > > NOT use certain cryptosuites. So, does "... is not to be used..." mean > > "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU > WILL" > > sort of requirements? > > It is indeed. I think a SHOULD NOT would actually be appropriate ? Anyone in the WG have an opinion about making this change to SHOULD NOT? Please comment soon if you do. Thanks, Dave ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
