Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Mar 3, 2014, at 12:02 PM, Valery Smyslov sva...@gmail.com wrote: The draft lists the following trasforms based on AES cipher: AES-GCM AES-CCM AES-CTR AES-128-CBC AES-GMAC AES-XCBC-MAC-96 All these transforms, except for AES-XCBC-MAC-96, allows to be used with different key lengths - 128, 192 and 256 bits. It looks strange to me that, unlike the others, AES-128-CBC has key length explicitely specified in the draft. Why it differs in this respect from the others? What about AES-192-CBC and AES-256-CBC - are they also MUST or MAY? Or even MUST NOT? :-) I think the draft should either: - remove explicit key length from AES-128-CBC and make it just AES-CBC - add explicit key length to all other AES-based transforms (except for AES-XCBC-MAC-96) - leave things as is, but explain why AES-CBC differs in this respect from the others The next draft changes AES-128-CBC to AES-CBC, and says: In the following sections, all AES modes are for 128-bit AES. 192-bit AES MAY be supported for those modes, but the requirements here are for 128-bit AES. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Hi Paul, The draft lists the following trasforms based on AES cipher: AES-GCM AES-CCM AES-CTR AES-128-CBC AES-GMAC AES-XCBC-MAC-96 All these transforms, except for AES-XCBC-MAC-96, allows to be used with different key lengths - 128, 192 and 256 bits. It looks strange to me that, unlike the others, AES-128-CBC has key length explicitely specified in the draft. Why it differs in this respect from the others? What about AES-192-CBC and AES-256-CBC - are they also MUST or MAY? Or even MUST NOT? :-) I think the draft should either: - remove explicit key length from AES-128-CBC and make it just AES-CBC - add explicit key length to all other AES-based transforms (except for AES-XCBC-MAC-96) - leave things as is, but explain why AES-CBC differs in this respect from the others The next draft changes AES-128-CBC to AES-CBC, and says: In the following sections, all AES modes are for 128-bit AES. 192-bit AES MAY be supported for those modes, but the requirements here are for 128-bit AES. And please, add the same words for 256-bit AES as for 192-bits AES. Regards, Valery. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On 03 Mar 2014, at 17:53 , Paul Wouters wrote: On Mon, 3 Mar 2014, RJ Atkinson wrote: ESP-NULL offers the same protection as AH, ... This sentence above is not true. ESP-NULL and AH provide different security properties to the IP-layer. AH protects all IP options, whereas ESP cannot protect any IP options that appear prior to the ESP header -- the location in the packet where those IP options are seen *and acted upon* by routers/firewalls/etc. What meaning has protecting those bits? Endpoint A and B protect something by cryptography, but any router in the middle can't trust those signatures anyway. So I don't see how AH is different from ESPinUDP where you set those options in the UDP header. These are not protected but the router can't verify the crypto anyway. At least some deployed routers in the middle in some deployments ARE able to validate and therefore trust the AH values (and trust that the IP options present were placed there by the sender). This was ALWAYS something that was designed-in to AH (RFC-1826, Section 1.1). Some other kinds of middleboxes (e.g. some firewalls) also can do this. Some AH implementations that support asymmetric keying go back at least 15 years, although those were not standardised back in 1995 -- primarily due to IPR considerations on intermediate authentication (which IPR I believe either has expired or expires very soon). Similarly, AH protects many IP header fields from in-transit modification, whereas ESP encapsulation provides no protection for the 1st (outer) IP header (i.e., that appears before the ESP header). So I don't buy that. The IP header is not protecting the packet from a router, which cannot confirm the crypto of that protection. Some deployed IPv4 routers can confirm the AH authentication information in some deployments. This has been true for years. Note that RFC-1826, Section 1.1, contains explicit discussion of the applicability of AH with asymmetric algorithms to enable intermediate authentication. What this is really about is exposing things like QoS bits, No. IETF standards say that the IP ToS/DiffServ bits are allowed to be modified in-transit. For example see Section 7.2 of RFC-2474 also page 10 of RFC-2402. but those devices acting on those are not verifying any protection. They are blindly using the exposed options. So ESPinUDP works equally well here. No. As a prior discussion has noted, AH can and is used to provide cryptographic protection to some security-critical IP options (e.g. sensitivity labels). ESP-NULL is not capable of protecting those options. I'm not sure what you are referring to here. Not labeled IPsec I take it? And again, how does this protection work? How do the routers verify this protection when only the endpoints know the crypto keys used to protect the header and payload? As an example, one can have (and real deployments exist) where an IPv4 sensitivity label (e.g. FIPS-188) in an IPv4 packet is protected by AH, using asymmetric cryptography, where both end systems and also intermediate label-policing IP routers can validate the digital signatures carried by AH to validate that the sensitivity label has not been tampered with since it was placed in the packet by the sender. Not all deployments where FIPS-188 is in use also use/deploy AH for protection, but some FIPS-188 deployments definitely do. - ESP-in-UDP can NOT do this. - ESP-NULL can NOT do this in any other way either. Can you explain how this protection works? If an AH packet flies by, and I change the QoS option from off to on to give my packet preference in the network, how will the next router notice this and ignore this QoS option? As noted above, the IP ToS/DiffServ byte explicitly is excluded from AH protection, originally because some deployed routers were known to change the field in-transit (RFC-2402) and later (after RFC-2474) because IETF standards explicitly say that modifying that field in-transit is allowed. Some deployments definitely do care. Other deployments do not. By understanding was always that people didn't like options getting lost or hidde within the ESP payload, and not getting set on the outer packet. While some people might have that view, that never has been a universal view. Broadly speaking, the primary case against using any IP option is that *historically* the presence of an IP option in an IP packet caused that packet to be forwarded on the slow path of many commercial IP routers. That is not necessarily the case today, although it reportedly still is the case for some products. A commercial router vendor that I worked a decade ago for shipped silicon that could fast-path, at wire-speed, for then high-speed interfaces (i.e., 10 Gbps) packets containing options -- simply because the silicon included logic to parse around the option to locate the start of the upper-layer header and apply any needed
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Tue, 4 Mar 2014, RJ Atkinson wrote: What meaning has protecting those bits? Endpoint A and B protect something by cryptography, but any router in the middle can't trust those signatures anyway. So I don't see how AH is different from ESPinUDP where you set those options in the UDP header. These are not protected but the router can't verify the crypto anyway. At least some deployed routers in the middle in some deployments ARE able to validate and therefore trust the AH values (and trust that the IP options present were placed there by the sender). This was ALWAYS something that was designed-in to AH (RFC-1826, Section 1.1). Some other kinds of middleboxes (e.g. some firewalls) also can do this. I was not aware of such deployments. Thanks for the information. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Hi, I have mostly no problem with the document. However I have one small concern. The draft lists the following trasforms based on AES cipher: AES-GCM AES-CCM AES-CTR AES-128-CBC AES-GMAC AES-XCBC-MAC-96 All these transforms, except for AES-XCBC-MAC-96, allows to be used with different key lengths - 128, 192 and 256 bits. It looks strange to me that, unlike the others, AES-128-CBC has key length explicitely specified in the draft. Why it differs in this respect from the others? What about AES-192-CBC and AES-256-CBC - are they also MUST or MAY? Or even MUST NOT? :-) I think the draft should either: - remove explicit key length from AES-128-CBC and make it just AES-CBC - add explicit key length to all other AES-based transforms (except for AES-XCBC-MAC-96) - leave things as is, but explain why AES-CBC differs in this respect from the others Regards, Valery Smyslov. - Original Message - From: Yaron Sheffer yaronf.i...@gmail.com To: ipsec ipsec@ietf.org Sent: Tuesday, February 25, 2014 10:48 PM Subject: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts Hi, this is to start a 2-week working group last call on the revised Algorithm Implementation Requirements document, ending March 11. The draft is at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should have last called the draft a while ago, and I apologize for the delay. The changes from the existing requirements are listed in Sec. 2.5 of the draft, but most of this (rather short) document is new and describes the rationale for the choice of algorithms and requirement levels. Please read this draft and send any comments to the WG mailing list, even if the comments are I see no problems. Comments such as I do not understand this part or this part could be explained better in this way are particularly useful at this point. Thanks, Yaron ___ 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
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Valery Smyslov writes: The draft lists the following trasforms based on AES cipher: AES-GCM AES-CCM AES-CTR AES-128-CBC AES-GMAC AES-XCBC-MAC-96 All these transforms, except for AES-XCBC-MAC-96, allows to be used with different key lengths - 128, 192 and 256 bits. It looks strange to me that, unlike the others, AES-128-CBC has key length explicitely specified in the draft. Why it differs in this respect from the others? What about AES-192-CBC and AES-256-CBC - are they also MUST or MAY? Or even MUST NOT? :-) Hmm... actually we should most like use the same names we use in the IANA registry. For example we have 3 different types of AES-GCM: 18 AES-GCM with a 8 octet ICV[RFC4106] [RFC5282] 19 AES-GCM with a 12 octet ICV [RFC4106] [RFC5282] 20 AES-GCM with a 16 octet ICV [RFC4106] [RFC5282] Which one of those is the one that is moved to SHOULD+? Should we just pick one of them, and say that it is the one we prefer, or should all implementations implement all of them? AES-CCM has similar thing, but as they are moving to MAY it does not really matter. And yes, I agree the AES-128-CBC should be changed to AES-CBC. In the RFC4305 and RFC4835 we had text like AES-CBC with 128-bit keys, but as we now have more AES modes, we should probably just add text saying that for 128-bit keys for AES is MUST. Also for AES-GMAC we need to decide which of the ones we are saying is SHOULD+: 9 AUTH_AES_128_GMAC [RFC4543] 10 AUTH_AES_192_GMAC [RFC4543] 11 AUTH_AES_256_GMAC [RFC4543] I think the draft should either: - remove explicit key length from AES-128-CBC and make it just AES-CBC - add explicit key length to all other AES-based transforms (except for AES-XCBC-MAC-96) AES-XCBC-MAC-96 is always defined to be have 128-bit key. The key length cannot be negotiated when using the authentication algorithm, it can only be negotiated for the encryption keys. Thats why the AUTH_AES_*_GMAC authentication algorithms are defined as 3 different algorithms. - leave things as is, but explain why AES-CBC differs in this respect from the others I think that is bad idea. I think the best is to say that in general with AES encryption (GCM, CBC, CCM etc) we assume the key length is 128-bits. (i.e. the MUST for AES-CBC is for 128-bit keys, and the SHOULD+ for AES-GCM is also for 128-bit keys with x octect ICV). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Mon, 3 Mar 2014, Tero Kivinen wrote: Hmm... actually we should most like use the same names we use in the IANA registry. For example we have 3 different types of AES-GCM: 18 AES-GCM with a 8 octet ICV[RFC4106] [RFC5282] 19 AES-GCM with a 12 octet ICV [RFC4106] [RFC5282] 20 AES-GCM with a 16 octet ICV [RFC4106] [RFC5282] Which one of those is the one that is moved to SHOULD+? Should we just pick one of them, and say that it is the one we prefer, or should all implementations implement all of them? AES-CCM has similar thing, but as they are moving to MAY it does not really matter. Actually yes. I talked to one of the authors of RFC 4106, John Viega, a while ago and he said: Some people seemed to think embedded devices would want to use truncated tags. in this day in age, I would recommend AGAINST tag truncation So I would be happy to only move ID 20 to SHOULD+ and actually demote 18 and 19. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Mon, 3 Mar 2014, RJ Atkinson wrote: ESP-NULL offers the same protection as AH, ... This sentence above is not true. ESP-NULL and AH provide different security properties to the IP-layer. AH protects all IP options, whereas ESP cannot protect any IP options that appear prior to the ESP header -- the location in the packet where those IP options are seen *and acted upon* by routers/firewalls/etc. What meaning has protecting those bits? Endpoint A and B protect something by cryptography, but any router in the middle can't trust those signatures anyway. So I don't see how AH is different from ESPinUDP where you set those options in the UDP header. These are not protected but the router can't verify the crypto anyway. Similarly, AH protects many IP header fields from in-transit modification, whereas ESP encapsulation provides no protection for the 1st (outer) IP header (i.e., that appears before the ESP header). So I don't buy that. The IP header is not protecting the packet from a router, which cannot confirm the crypto of that protection. What this is really about is exposing things like QoS bits, but those devices acting on those are not verifying any protection. They are blindly using the exposed options. So ESPinUDP works equally well here. As a prior discussion has noted, AH can and is used to provide cryptographic protection to some security-critical IP options (e.g. sensitivity labels). ESP-NULL is not capable of protecting those options. I'm not sure what you are referring to here. Not labeled IPsec I take it? And again, how does this protection work? How do the routers verify this protection when only the endpoints know the crypto keys used to protect the header and payload? The reason AH is MAY is that not all deployments care about protecting the (outer) IP header and (visible to the forwarding plane) IP options. Can you explain how this protection works? If an AH packet flies by, and I change the QoS option from off to on to give my packet preference in the network, how will the next router notice this and ignore this QoS option? Some deployments definitely do care. Other deployments do not. By understanding was always that people didn't like options getting lost or hidde within the ESP payload, and not getting set on the outer packet. In fact, with KLIPS we had an option that could copy some of the header bits into the outer IP header. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
HI Tero, Hmm... actually we should most like use the same names we use in the IANA registry. Agree, this would make things more clear. I think the best is to say that in general with AES encryption (GCM, CBC, CCM etc) we assume the key length is 128-bits. (i.e. the And don't forget about GMAC. MUST for AES-CBC is for 128-bit keys, and the SHOULD+ for AES-GCM is also for 128-bit keys with x octect ICV). I also think this is the best way. I listed the other two just for completeness. Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Yaron Sheffer writes: +1 on making single-DES CBC a MUST NOT. Agree on that. (And I still need to read the whole document, I am way too much behind with my IPsecME WG draft reading). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
(Hats off) +1 on making single-DES CBC a MUST NOT. Yaron Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane modern IKE daemon that allows 1DES (or modp768) The WG has never voiced a MUST NOT for this before. I'm fine with making that change if no one objects. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Wed, 26 Feb 2014, Valery Smyslov wrote: It is for systems that don't implement AH. We should probably say this explicitly in section 3. I don't think it is limited for those systems only. You may implement AH, but yon cannot use it everywhere, as it is not compatible with NATs. And ESP-NULL with Auth is the only substitute there. So, it must be MUST for any system. Why did we not kill AH all together when Schneier and Ferguson told us so? :P But you are right. Perhaps some text along the line of: ESP-NULL offers the same protection as AH, but is more widely accepted and functional compared to AH. AH does not work through NATs and is not implemented in every IPsec stack. AH requires firewall rules different from ESP causing it to get accidentally filtered. ESP-NULL is also used in performance testing as a benchmark against ESP encryption algorithms. ESP-NULL should never be automatically selected as part of IKE unless explicitely configured as the only ESP encryption algorithm. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Paul, On Feb 25, 2014, at 8:48 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: Hi, this is to start a 2-week working group last call on the revised Algorithm Implementation Requirements document, ending March 11. The draft is at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should have last called the draft a while ago, and I apologize for the delay. Section 2.2: It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old crypto export restrictions? While I think NULL ESP is a good debugging tool, and a good replacement for AH in general, I don't think this is really a MUST item (unless you would actually advise people to migrate from AH to ESP NULL, in which case I'll cheer on this MUST) I think we do want folks to migrate from AH to ESP/NULL. That's why we made support for AH a MAY a while ago. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Paul, On Wed, 26 Feb 2014, Valery Smyslov wrote: It is for systems that don't implement AH. We should probably say this explicitly in section 3. I don't think it is limited for those systems only. You may implement AH, but yon cannot use it everywhere, as it is not compatible with NATs. And ESP-NULL with Auth is the only substitute there. So, it must be MUST for any system. Why did we not kill AH all together when Schneier and Ferguson told us so? :P But you are right. Perhaps some text along the line of: perhaps because they were wrong. ESP-NULL offers better performance than AH and so it is desirable in most cases. But, AH has been specified by some protocols and we don't want to undermine their choice by killing it. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Hi, this is to start a 2-week working group last call on the revised Algorithm Implementation Requirements document, ending March 11. The draft is at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should have last called the draft a while ago, and I apologize for the delay. The changes from the existing requirements are listed in Sec. 2.5 of the draft, but most of this (rather short) document is new and describes the rationale for the choice of algorithms and requirement levels. Please read this draft and send any comments to the WG mailing list, even if the comments are I see no problems. Comments such as I do not understand this part or this part could be explained better in this way are particularly useful at this point. Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Feb 25, 2014, at 8:48 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: Hi, this is to start a 2-week working group last call on the revised Algorithm Implementation Requirements document, ending March 11. The draft is at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should have last called the draft a while ago, and I apologize for the delay. Section 2.2: It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old crypto export restrictions? While I think NULL ESP is a good debugging tool, and a good replacement for AH in general, I don't think this is really a MUST item (unless you would actually advise people to migrate from AH to ESP NULL, in which case I'll cheer on this MUST) Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane modern IKE daemon that allows 1DES (or modp768) Section 2.3: This does not list anything with md5. Is there another RFC that already discourages this use for IPsec? If so, can it be references in this document. If not, shouldn't we talk about an HMAC-MD5 downgrade to SHOULD NOT+ ? [ Turns out that document is RFC 4835, but only mentioned at the end. Should this document not Obsolete: 4835? ] Why is ESP auth NULL a MAY instead of a MUST NOT? The only reason I can think of for this is when we use a combined mode algorithm like AES-GCM. But in that case if AES-GCM is SHOULD+ it requires ESP auth null to be SHOULD+ as well? Section 2.5: I would put 2.5 as the introduction paragraph to 2.1. I'm also confused why the entries in 2.2 and 2.3 do not appear in the 2.5 summary. Should they be added with - in the Old Requirement, and their listing in the New Requirement? Section 3 states: If authentication on the IP header is needed in conjunction with confidentiality of higher-layer data, then AH SHOULD be used in addition to the transforms recommended above. How does AH protect the confidentiality of higher-layer data ? Seciont 4: The text about The Triple Data Encryption Standard (TDES) is obsolete appears twice and could be consolidated? Section 4.3: This section is the only section that mentions MD5 and SHA1. Perhaps it should summarize or refer to RFC 4835? Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Feb 25, 2014, at 3:09 PM, Paul Wouters p...@cypherpunks.ca wrote: On Feb 25, 2014, at 8:48 PM, Yaron Sheffer yaronf.i...@gmail.com wrote: Hi, this is to start a 2-week working group last call on the revised Algorithm Implementation Requirements document, ending March 11. The draft is at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should have last called the draft a while ago, and I apologize for the delay. Section 2.2: It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old crypto export restrictions? While I think NULL ESP is a good debugging tool, and a good replacement for AH in general, I don't think this is really a MUST item (unless you would actually advise people to migrate from AH to ESP NULL, in which case I'll cheer on this MUST) It is for systems that don't implement AH. We should probably say this explicitly in section 3. Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane modern IKE daemon that allows 1DES (or modp768) The WG has never voiced a MUST NOT for this before. I'm fine with making that change if no one objects. Section 2.3: This does not list anything with md5. Is there another RFC that already discourages this use for IPsec? If so, can it be references in this document. If not, shouldn't we talk about an HMAC-MD5 downgrade to SHOULD NOT+ ? HMAC-MD5 still gives 128 bits of strength, which in fact is more than the MUST-level HMAC-SHA1-96. It was a MAY in 4835; by not listing it here, it is still MAY. [ Turns out that document is RFC 4835, but only mentioned at the end. Should this document not Obsolete: 4835? ] This document should indeed obsolete 4835. Good catch. Why is ESP auth NULL a MAY instead of a MUST NOT? The only reason I can think of for this is when we use a combined mode algorithm like AES-GCM. But in that case if AES-GCM is SHOULD+ it requires ESP auth null to be SHOULD+ as well? That's covered in Section 3. The tables are the raw list of requirements; their use is covered in Section 3. Section 2.5: I would put 2.5 as the introduction paragraph to 2.1. Bike shed. I'm also confused why the entries in 2.2 and 2.3 do not appear in the 2.5 summary. I just checked, and I think the table of changes is correct. Which do you think is missing? Should they be added with - in the Old Requirement, and their listing in the New Requirement? No, this is a table of differences. Section 3 states: If authentication on the IP header is needed in conjunction with confidentiality of higher-layer data, then AH SHOULD be used in addition to the transforms recommended above. How does AH protect the confidentiality of higher-layer data ? It does not, of course. I think this sentence was trying to be about if the higher-layer data already has its own confidentiality, then you can add AH. I think the sentence should be removed because it assumes that the device adding authentication knows whether or not the higher-layer service is using confidentiality correctly, and it can't know this. Seciont 4: The text about The Triple Data Encryption Standard (TDES) is obsolete appears twice and could be consolidated? The second one is about DES. :-) Section 4.3: This section is the only section that mentions MD5 and SHA1. Perhaps it should summarize or refer to RFC 4835? I think it is better to make this document obsolete 4835 and keep the negative text. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Hi Paul, It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old crypto export restrictions? While I think NULL ESP is a good debugging tool, and a good replacement for AH in general, I don't think this is really a MUST item (unless you would actually advise people to migrate from AH to ESP NULL, in which case I'll cheer on this MUST) It is for systems that don't implement AH. We should probably say this explicitly in section 3. I don't think it is limited for those systems only. You may implement AH, but yon cannot use it everywhere, as it is not compatible with NATs. And ESP-NULL with Auth is the only substitute there. So, it must be MUST for any system. Regards, Valery Smyslov. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
