Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)
Paul, It's been over 8 years since this RFC was published, and I have not looked at it since then. My recollection is that we wrote 5114 because an IPsec developer approached me and said that he wanted to support these groups in a product. He said that he wanted test vectors for the groups, consistent with what we have done for many other algs. I persuaded Matt to generate the RFC because it was a relatively easy task a good way for Matt to get acquainted with the RFC process. As to your question, I have no info about how the NIST DH values were generated. However, I do agree with Yoav and Tero that it seems unduly prejudicial to declare these to be a MUST NOT. The fact that one can generate trap-doored DH values that cannot be detected is not the same as having proof that a given set of values have been generated in that fashion. Moreover, if one interprets a MUST NOT in this context to mean that an implementation supporting any of these groups is non-compliant, then that unfairly penalizes existing implementations, as Tero noted. Moreover, if the concern raised by the paper (which I have read) is with MODP groups of size 1024 (or smaller), only 1 of the groups in 5114 fits that criteria (section 2.1). I have not tracked the status of these NIST groups re evaluation criteria like FIPS 140-2. If these groups are approved for use in products evaluated under that FIPS (I don't know if they are), deprecating them creates a possible conundrum for vendors who want to comply with RFCs and with FIPS evaluation criteria. Thus I suggest a less dramatic response than declaring all of the groups in 5114 to be MUST NOT. I'm not a vendor of any crypto products (these days), and I've never been a crypto mathematician. So my views are based only on what I recall about the creation of 5114 and about IETF crytpo standards practices in general. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P-256 speed
Yoav, Is this code available anywhere? If not, it makes it hard to reproduce their results. There is a paper on the code design, and I anticipate the code will become available, as the work was sponsored by NIST. It’s too bad they don’t submit this to bench.cr.yp.to so we could have an apples-to-apples comparison with other implementations. I suspect they will do so. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] mot sure if this posted before, so resending
Yoav, I think it’s risky to base decisions on our attempts to divine future NIST decisions, but I agree that out best option now is to leave the 64-bit IV (or nonce) explicit for now and perhaps later add an IKE extension that allows you to “compress” the IV as long as it’s equal to the packet counter. That allows the ESP implementation to compress the ESP packet as long as the encryption module keeps generating payloads that have an IV exactly the same as the packet counter. works for me. I’ve recently had the dubious pleasure of going over some NIST document ([1]). Appendix A.5 is about Key/IV pair uniqueness in AES-GCM, but I guess (divining again…) that if they ever accept ChaCha20, they might ask for similar things. So what does it say about IV generation? There are several ways to generate the IV. One is to generate the IV in compliance with the TLS 1.2 GCM Cipher Suites for TLS, as described in the corresponding IETF RFC 5116 and 5288. Alternatively, the IV may be generated randomly or set deterministically, possibly by being incremented by 1 every time a new value is needed. That sounds good, because “deterministically… by being incremented by 1 every time” is exactly what we’re looking for, right? seems reasonable to me. The document goes on to say that the method in RFC 5288 is allowed only for TLS 1.2, and “in all other cases the following requirements shall be satisfied” If the GCM Key is generated either internally or externally and the IV is generated internally deterministically then the requirement of SP 800-38D quoted in the Background section above will be modified. Instead of requiring that the probability of any (key, IV) collision anywhere in the Universe at all times did not exceed 2^-32, it will only be required that for a given key distributed to one or more cryptographic modules, the (key, IV) collision probability would not exceed 2^-32. This is equivalent to the requirement that for any key distributed to one or more modules the probability of a collision between the deterministically-generated IVs is no greater than 2^-32. That is still fine, because a 64-bit counter has a zero chance of repeating, and 0 2^-32. But then the document goes on to “specify what the module has to do to meet this requirement”. Each deterministically established IV shall include an encoding of the module’s name and the name shall be long enough to allow for at least 2^32 different names. For example, if the module’s name is such that it consists of at least 8 hexadecimal characters then this condition is satisfied, since 16^8 is no smaller than (indeed, equal to) 2^32 . Alternatively, if the name consists of at least 6 alphanumerical characters, each having at least 62 values, then this is also sufficient. Even though not all possible names are equally likely to be used, just the fact that the modules can possibly have at least 232 different names will be sufficient to meet this requirement. So now we’re supposed to dedicate 32 bits of the available 64 to encoding the module name??? That leaves 32 bits per key for packet counter. That also means that ESN is a superfluous feature, because if you go above 2^32 packets per SA, the pigeonhole principle applies. Does anyone know the method behind this madness? I think the module name requirement is intended to accommodate multi-sender, same key, scenarios, but you should direct the question to NIST, e.g., lily.c...@nist.gov. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] mot sure if this posted before, so resending
Yoav, Hi, There is two questions I would like guidance from the group about. First is the nonce/IV question: In the current draft, there is a 64-bit IV with guidance not to repeat them (so use a counter or LFSR). The function itself accepts a 96-bit input nonce, so the nonce is constructed from the 64-bit IV and 32 zero bits. The reason for doing this is so the algorithm could be used in a multi-sender case such as GDOI, where the 32-bit zero can be replaced by a sender ID. Alternatively, we could generate a 32-bit salt value from the key material, but I don’t see a reason why we’d want that. Another thing we could do is what some people are advocating for TLS: Since a counter is a fine IV (no need for secrecy), we don’t need a 64-bit IV that has the exact same value as the replay counter. We might as well save 8 bytes per packet and just feed the replay counter to the function. The argument against this is that some crypto modules may have the API set up in such a way that the IVs are generated within the module and could be something other than a counter (like an LFSR). The proposal will break such APIs. agreed. The other, related issue, is that if one wants to achieve FIPS certification for an alg like this, the nonce/IV needs to be within the eval boundary for the alg certification. I realize that ChaCha is not a FIPS alg, but I recall someone asking NIST if it might be willing to evaluate ChaCha. If the goal is (eventual) FIPS evaluation, then it makes sense to consider the implications of trying to reuse the ESP sequence counter as an input to the IV/nonce in this context. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.txt
As the primary author of 4301, and the creator of the PAD, I believe this work does update that section of 4301. I agree with Kathleen that this doc needs to say precisely what parts of 4301 are being updated, perhaps using a before/after approach. Steve On Apr 1, 2015, at 6:57 PM, Kathleen Moriarty kathleen.moriarty.i...@gmail.com wrote: I went back to the email thread as I wanted to look at the consensus and don't see it the way Paul does. Here is the end of the thread: http://www.ietf.org/mail-archive/web/ipsec/current/msg09668.html It reads as confusion with the term updates and most being ok with going in either direction, Paul against and Yaron more in favor. Yes, exactly. So, it sounds like you see the consensus (and confusion) the way I do. Updates can update very specific text in a draft. Since this just applies in this special case, the updates text needs to be clearly worded to reflect that or you copy in all the text that applies from the other draft. Sounds fine. Who do you want to make that decision? --Paul Hoffman ___ 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] WG Last Call on The NULL Authentication Method in IKEv2 Protocol
Paul, Other authentication methods defined for IKE perform authentication, so there was no need to express anything special in the SPD or PAD. NULL is obviously very different. The text you cited from 4727, with the edit you proposed would be a big improvement. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Diet-ESP
Daniel, Thanks for the explanation. ... The draft does not specify how matching between IV_i and packet i is performed. - 1) you may use the SN as the packet counter. Of course it is easier if the SN increments for each packet. However SN are not part of the IV generation. which SN? the one from ESP? Doesn't Diet-ESP significantly reduce the sequence number space? if the SN space is small, then there may be ambiguity at the receiver. - 2) you may use the least significant bytes to determine which IV may match. This way of doing so differs in the current way of sending the IV as we do not have the IV from the packet. In our case, the IV is not derived from the packet, we need to generate a few number of IV in advance, and find out which is the one matching a particular packet. This sentence suggests that the least significant bytes above are from the compressed IV. Is that right? If the IV is pseudorandom, and it's compressed representation is small, e.g., 2 bytes, what is the likelihood that two IVs will have the same representation, within a receive window of, say 32 packets? (This is a drawing balls from an urn with replacement problem, I think). This might result in a frequency of collision that may be an issue, causing the receiver to have to do crypto processing on colliding packets. Motivation for doing so is that sending a byte in 6lo cost more than doing a few thousand operations. In that sense, we are ready to implement some more complex IV-to-i function. Isn't the lo in 6lo, low power? Is it clear that the cycles vs. bandwidth tradeoff is always a win? Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Diet-ESP
Daniel, I read the very brief IV-generation I-D and I didn't see an explanation of how to perform IV compression. As someone else already noted on the list, an IV is carried with each packet to enable decryption of packets that may arrive out of order. Thus it's not enough to have each peer use the same PRF and seed to generate IVs which are not explicitly transported, because of this requirement. Also, if the IV is required to be pesudorandom, there is likely no opportunity for compression in the usual sense. Finally, note that the specs for algorithm modes like GCM treat the IV as a security critical piece of info, for good reason. Thus if one tries to re-use a value such as an ESP sequence number as an IV, all of the ESP sequence number generation/management code becomes security critical wrt algorithm mode evaluation. This topic was discussed in London in the TLS WG meeting, when considering use of Cha-Cha. I can forward the relevant messages and my slides if you wish. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts
Paul On Mar 8, 2014, at 8:08 AM, Black, David david.bl...@emc.com wrote: 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. What about 256-bit AES keys? They should also be a MAY. Why not “SHOULD” for 192 and 256 bit keys? paul It's good to remember the reason that 256-bits keys for AES were specified, i.e., as a hedge against someone building a quantum computer. So, unless the data being encrypted is expected to have a lifetime far enough into the future as to merit protection against that concern, the extra time needed to perform AES-256 vs. AES-128 does not seem justified. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts
Paul, ... It's good to remember the reason that 256-bits keys for AES were specified, i.e., as a hedge against someone building a quantum computer. So, unless the data being encrypted is expected to have a lifetime far enough into the future as to merit protection against that concern, the extra time needed to perform AES-256 vs. AES-128 does not seem justified. Steve That’s a good argument for a user choosing to use AES-128 rather than AES-256. But it doesn’t really address why “SHOULD implement” isn’t justified — the implementation cost is trivial and if it isn’t used it has no performance impact. paul I have been told by some commercial security consultants that their customers believe that bigger is more secure, and thus they should mandate use of longer key lengths if they are available. If that report is accurate, then making AES-256 a SHOULD (vs. a MAY) creates a situation where the performance penalty will be incurred, for no good reason. But, I'm not going to fall on my sword for this. 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 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] 4301 questionnaire
For progress to Internet Standard, we need to verify the status of implementations relative to the RFCs. Rather than Going through an exhaustive list of MUST and SHOULD compliance, let's start with a simpler list, suggested by Sean. I request that each implementer complete the following form: *- Which of following databases does your implementation support: - SPD (Security Policy Database) - SAD (Security Association Database) - PAD (Peer Authorization Database) - Which of the processing semantics does your implementation support: - IP Traffic: - ICMP: - Fragment: - Path MTU/DF The following questions document whether interoperability has been achieved as well as other intangibles the IESG will be interested: - What evidence do you have that your implementation can interoperate with other implementations?** ** ** - In your opinion, are there unused features in the RFC that greatly increase implementation complexity?** ** ** - Errata was filed against RFC 4301 and has been incorporated in**https://datatracker.ietf.org/doc/draft-kent-ipsecme-saforip-rfc4301bis/**; are any of the incorporated errata problematic for your implementation?** ** **- Does your implementation support the updates documented in RFC 6401? Additional information (optional):* Thanks, Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Fwd: I-D ACTION:draft-kent-ipsecme-ah-rfc4302bis-00.txt
updated versions of RFC 4301, 4302, and 4303 have been posted: Title : IP Authentication Header (AH) Author(s) : S. Kent Filename : draft-kent-ipsecme-ah-rfc4302bis Pages : 35 Date : Nov. 19, 2013 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 4302. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kent-ipsecme-ah-rfc4302bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Title : Security Architecture for the Internet Protocol Author(s) : S. Kent Filename : draft-kent-ipsecme-saforip-rfc4301bis Pages : 104 Date : Nov. 19, 2013 This document describes an updated version of the quot;Security Architecture for IPquot;, which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 4301 and 6040. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kent-ipsecme-saforip-rfc4301bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent Filename : draft-kent-ipsecme-esp-rfc4303bis Pages : 46 Date : Nov. 19, 2013 This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 4303. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kent-ipsecme-esp-rfc4303bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D ACTION:draft-kent-ipsecme-ah-rfc4302bis-00.txt
Yaron, I think we should progress it to FS only if there are other protocols that make use of it, and which are really in use in a non-trivial fashion. I think Sean said that he identified some such protocols when he was exploring this topic, so we should ask Sean for details. Steve On 11/19/2013 11:06 PM, Stephen Kent wrote: updated versions of RFC 4301, 4302, and 4303 have been posted: Thank you Steve for working on these drafts. These drafts are targeted at republication as Internet Standards. As promised in Vancouver, I would like to open the question of whether we should be republishing RFC 4302 - AH. My personal opinion is that we should not. We have downgraded AH and consistently discouraged its use, replacing it by ESP-null. People are obviously free to implement it even if it remains Proposed Standard, but why give the wrong message by promoting it to IS? Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AD VPN: discussion kick off
Mike, Thanks for the responses to my comments, including ones from yesterday's meeting. Steve, Sorry, I wasn't clear on our use of IPsec. We definitely use both the authentication and encryption capabilities of IPsec. We do the following when bringing up a new tunnel. 1. Trigger ISAKMP/IKEv2/IPsec with an SPD of (LocalPeer IP, RemotePeer IP, GRE). 2. ISAKMP/IKEv2 authenticates the peers, creates the IKE SAs and the IPsec/Child encryption SAs. 3. IPsec signals it has authenticated and encryption is ready, the GRE tunnel is activated. 4. NHRP registration (for spoke-hub) or resolution reply (for final phase of spoke-spoke) are sent over the tunnel. 5. Routing is brought up over the spoke-hub tunnels. If a shortcut between two spokes is available, as advised by a hub, that requires an SDP entry. Did that entry preexist in the spoke, or was it provisioned by a hub in some fashion? If it existed in the spoke, initially, normal IPsec operation would cause traffic to that spoke to trigger formation of an SA to that destination. Can you clarify? As for scaling, we already have DMVPN networks of 1+ nodes and looking at building networks of 4+ nodes. In many cases customers have multiple subnets behind each node, therefore with just IPsec I would need to have multiple SAs/encryption between the same two nodes, even if you are only doing subnet to subnet SPDs. Take the case of two nodes that each have 4 subnets. I could need as many as 16 SAs to cover all cases. Or even a simpler case between a host (1 local address) and a node at a data center (say 20 subnets), I would need up to 20 SAs to cover this. In many of our networks we are asked to support at least 5 (sometimes 10) subnets per spoke location. That's a helpful clarification. It does not appear to be the sort of environment that initially seemed to be the focus of this work, e.g., road warriors calling home or home/satellite offices for a moderate size enterprise. As far as IPv4 and IPv6 support, you are correct it would only double the number of SAs needed, assuming that there are the same number of subnets for IPv4 and IPv6. From what I have seen IPv6 tends to increase the number of subnets. I'm glad we're on the same page here. For end-to-end encryption, take the case where a spoke node is a host. Then initially the spoke/host will connect to one or more hubs (we recommend at least 2 for redundancy). Communication between two such connected hosts would be through the hub and would be two hops (Host1 encrypt-decrypt Hub encrypt-decrypt Host2). Once the shortcut tunnel is setup then communication would be direct between the hosts (Host1 encrypt-decrypt Host2). see my question re the shortcut SPD entries. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AD VPN: discussion kick off
Manish, Hi Stephen, Thanks for your inputs vis-a-vis 4301/2/3. I concur that IPSec is not just about encryption but don't quite buy into what somebody spelled out during the meeting as 'IPSec is an access control mechanism that also provides other security services'; IMO, strict access control is more a firewall functionality. RFC 4301 spells out the access control rationale as IPsec includes a specification for minimal firewall functionality, since that is an essential aspect of access control at the IP layer... The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection. You cited one of several sentences that mention access control in 4301, in Section 2.1. Other quotes, very close to the one you chose, make a stronger case for access control as an important element of IPsec: The set of security services offered includes access control, connectionless integrity, data origin authentication, detection and rejection of replays (a form of partial sequence integrity), confidentiality (via encryption), and limited traffic flow confidentiality. and The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection. This second quote notes that a separate firewall, operating at the Internet layer, is NOT as secure as the one integrated into IPsec. I know that we might have ruffled a few feathers wrt making the SPD relatively trivial but let's get down to some details as far as the comparison goes. The first ADVPN proposal does talk about the shortcut suggester possibly including traffic selectors in the shortcut exchange. While this seems to give the notion of the ability to provide SA granularity, the source of such information is a third party (even though both peers have an active connection with this third party) and doesn't quite stand up to the very reason of including access control in IPSec (The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection.) - this is a case of the information not even privy to the same device, leave alone the same layer in the same device. OK, this paragraph shows that you do understand the importance of the internal firewall in an IPsec implementation. I'm not asserting that ADVPN is better or worse in this regard. I just happened to be alerted to the issue by the DMVPN message from Mike. I'm equally disappointed with any proposal that essentially eliminates the access control feature ;-) . Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AD VPN: discussion kick off
Manish, Steve, To answer your question, the SPD entries are not already there, they are created as the result of a message exchange between the two spokes; it's the spokes that choose the policy, not the hub. If the SPDs were already there, every IPSec node in the network would need to know about all the networks in the overall topology apriori -- to solve this is one of the main drivers of the whole exercise. This becomes even more complex if the hosts (not necessarily an IPSec node) acquire address dynamically and/or are mobile. So the spokes, while connected through the hub, exchange messages to cause SPD entries to be created. What protocol is used to do this? Steve p.s. please use the correct (vs.the Cisco-preferred?) spelling, i.e., IPsec, vs. IPSec. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AD VPN: discussion kick off
Mike, A couple of your comments caught my attention, as an author of 4301, 02, and 03. I admit to not having read the DMVPN proposal, so my comments are based only on your message, which argues why DMVPN is the preferred solution. IPsec encryption layer. In this layer ISAKMP/IKEv2/IPsec is the correct standard protocol to use. This is what IPsec does really well, encrypt traffic. The layers above greatly simplifies IPsec's job by presenting to it the tunnel to encrypt instead of all of the individual protocols/subnets/flows that are within the tunnel. The IPsec selectors are now for the tunnel, which makes path redundancy and load-balancing doable. IPsec doesn't deal well with the same set of selectors to encrypt traffic to more than one peer. With DMVPN this is handled at the routing/forwarding and GRE tunnel layers. IPsec is not just about encryption, although the DMVPN proposal may relegate it to that. IPsec provides access control, and, typically, authentication. Does DMVPN preserve the access control features of IPsec, or are users now relying on a hub to do this, or what? ... With 10s of thousands of nodes and perhaps 100s of thousands of network/subnets reachable via the VPN the number of IPsec selectors across the VPN would get completely out of hand, especially if each different pair of subnets (selector) requires a separate encryption, between the same two nodes. More properly, a separate SA, and only if the folks who manage policies at each end of the SA decide to provide fine-grained access control for the traffic flows. It was not clear to me that the problem statement for this work envisioned VPNs of the scale you mention. Also, the comments above are a bit confusing. Both end points and security gateways are nodes wrt IPsec, in the general sense. I can create a selector that secures traffic from my node (and point of subnet) to all hosts on a subnet, irrespective of how many are present there. This doesn't even count the fact that in order to run IPv4 and IPv6 between the same two nodes you have to use at least double the number of selectors. At least? Under what circumstances would the number grow by more than a factor of two? Routing protocols are already designed to scale to 100s of thousands and even millions of routes. So with DMVPN the forwarding and GRE tunneling of both IPv4 and IPv6 is handled within a single GRE tunnel and IPsec selector. So, the proposal simplifies use of IPsec by limiting the granularity at which SAs may be created? Does it also cause each SA to terminate at a hub, so that the security services are no longer e-t-e? In the context of the perpass discussions, this seems like a questionable design decision. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange
On 1/4/13 3:23 PM, Andrey Jivsov wrote: ... Point compression is more beneficial for storage security for reasons of performance and storage efficiency. For storage efficiency side: when there are multiple recipients per message, each associated with one ECDH-related field, it's possible for ECDH-specific payload to get arbitrary large for a fixed short message. For the performance argument: if the message was encrypted to N recipients, to decode it only one recipient will be used, and thus the calculation of 'y' is done once but the space is saved for N. Are you confident that this attempt at space efficiency is consistent with S/MIME processing rules? Or are you suggesting that S/MIME and other secure email standards become alg-specific to take advantage of this optimization? Even for certificates that have one public key there is some benefit, given that the certificates are pre-precessed for chain validation and are often cached. Most IETF security protocols make use of X.509 (PKIX) certs. X.509 certs always contain just one key. So I'm puzzled by the phrase Even for certificates that have one public key ... Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt
Dan, My recollection is that the agreement at the SECDIR meeting was that a waring of the form not for use with IKEv1 was part pf the deal. I still believe this is a very questionable way to accommodate the IEEE's unwillingness to maintain their own registry, and their slow doc rev cycle time that is causing us to do a silly (at best) thing. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] FW: New Version Notification for draft-zhang-ipsecme-multi-path-ipsec-01.txt
I provided a number of comments in response to the -00 version back in April. According to the diff tool in data tacker, the -01 version is identical, except that the author list and dates have changed. So it's not clear that comments really are appreciated.;-) Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
At 10:11 PM + 4/9/12, Xiangyang zhang wrote: Steve Even though TCP or IP does not envision it, the ordered processing is very common now. In an intermediary node, IP reassembly and TCP reorder must be done some time. In flow-based technology (for example, stateful firewall), without IP reassembly, it could not work. You know flow is based on 5 tuples, non-first fragments has no TCP or UDP port information in it. Without IP reassembly, the only way is to drop the packet. No customer will accept this kind of network product. and yet there are adverse affects ... In NAT device, no matter it is large scale (LSN) or others, it could break some application like FTP, VOIP etc. TCP payload must be extracted. If TCP segments do not arrive in order, it must wait for it. In our GGSN product, there are also some cases where TCP reorder must be done. you're giving examples of intermediate nodes doing things that can cause problems. Just like TCP/IP, the ordered arrival is not a requirement. This is similar to IPsec. IPsec does not intrinsically reorder packets. At worst is may discard packets that arrived very much out of order, a situation where TCP probably would have requested retransmission anyway. Please check my comments inline starting with victor. ... The TCP and IP specs do not envision an intermediary trying to put packets back in order or performing reassembly. When middle bioxes do this performance often suffers. Victor Current network is much more complicated than old one. It could not be avoided in some situation even though you do not want to do that. You're creating new opportunities to make the problem worse. ... note that 4301 removed the requirement to support SA bundles, so the comparison seems out of place. Victor I note that too. If we do not compare SA bundle and cluster, we can just compare SA and SA cluster. The later is an option to enhance the security. You say that, but you have failed to provide any analysis to support this claim. ... as I noted in prior messages, this seems awfully complex and has the potential to degrade performance, so a very string secruity argument needs to be made to justify considering this proposal. I have not seen that argument. Victor I do not want to deny that it has the potential to degrade the performance. But I want to say it also has the potential to improve the performance, for example, when congestion happens. This is why multi-path TCP comes into picture. pick an argument and stick with it :-). when this began you didn't seem to know about multi-path TCP, so your proposal can't be assuming its use. SA cluster should not be awfully complex. If there are two SA, it just group them together. I implemented one IPsec stack before. If I update the code, it does not need much change at both sending side and receiving side. If you see it is awfully complex, how do you come to that conclusion? I have watched a number of vendors produce non-compliant IPsec implementations since I wrote 2301. That perspective provides me with a basis for arguing that this proposal adds complexity for questionable benefit. I use SA bundle as an example, just want to say that it is simpler than SA bundle. And the performance should be better in most cases. SA bundles were removed because most vendors felt they were too complex and did not offer enough benefits. So, saying that this proposal is simpler than SA bundles does not make it simple :-). Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
At 4:50 PM + 4/6/12, Xiangyang zhang wrote: Stephen, You understand this method very well. The disadvantage is the possible severity of out of order delivery. Even with single SA, it can also cause the out of order problem. As for re-order, just like TCP reorder or IP reassembly, it can be done at intermediate node or end host. The TCP and IP specs do not envision an intermediary trying to put packets back in order or performing reassembly. When middle bioxes do this performance often suffers. If it is done at SGW, RFC 6471 may help to mitigate the issue. In your previous mail, this is potentially very complex feature. As a matter of fact, it is simpler comparing with SA bundle in implementation. For SA bundle with two SAs, it must go through the processing two times. For SA cluster, packet just needs to be processed one time. Here I do not intend to deny the out of order claim. note that 4301 removed the requirement to support SA bundles, so the comparison seems out of place. This is another option comparing with SA or SA cluster. The product developers can choose what method they need, or it can be configurable. I submitted the draft to see if it exhibits some benefit. It does not intend to be necessarily absolute better or replace the existing method. as I noted in prior messages, this seems awfully complex and has the potential to degrade performance, so a very string secruity argument needs to be made to justify considering this proposal. I have not seen that argument. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
At 9:49 AM -0500 4/9/12, paul_kon...@dell.com wrote: At 4:50 PM + 4/6/12, Xiangyang zhang wrote: Stephen, You understand this method very well. The disadvantage is the possible severity of out of order delivery. Even with single SA, it can also cause the out of order problem. As for re-order, just like TCP reorder or IP reassembly, it can be done at intermediate node or end host. The TCP and IP specs do not envision an intermediary trying to put packets back in order or performing reassembly. When middle bioxes do this performance often suffers. In fact, reassembly at intermediate nodes is not possible at all, because IP can route packets on several routes. The full stream of packets is only available at the end points, so that is the only place where reassembly can be done. paul Paul, I agree in general, but I was considering the case where the intermediate node is very enough to the destination. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
At 4:44 AM + 4/6/12, Xiangyang zhang wrote: Steve, Your understanding is partially right. Only that anti-replay window could possibly be bigger if two paths go along the different routes. If two paths go along the same route, it is no difference from the traditional single SA. But the attacker does not know two paths carry the same flow of traffic. when you take a sequence of packets and spread them over multiple SAs, you create new opportunities for the packets to arrive out of order at the destination. They have to be merged at the destination, either at the host or at an SG. If they are merged at an SG, new functionality is required to buffer the packets and re-order them. If not, then variances in traffic handling at each end creates new opportunities for reordering or traffic, and/or added jitter. OOO arrival is not good for TCP connections, irrespective of the IPsec anti-replay window. Jitter is also not great, especially for some realtime apps that run over UDP. For security consideration, could you point out what is in error? your text refers to multiple paths, when you mean multiple SAs. Thanks, Victor ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
At 1:12 AM + 4/3/12, Xiangyang zhang wrote: A new version of I-D, draft-zhang-ipsecme-multi-path-ipsec-00.txt has been successfully submitted by Xiangyang Zhang and posted to the IETF repository. Filename:draft-zhang-ipsecme-multi-path-ipsec Revision:00 Title:Multiple Path IP Security Creation date:2012-04-02 WG ID:Individual Submission Number of pages: 7 Abstract: This document presents one approach to enhance data protection when transmitting IPsec datagrams across the insecure networks. The method affords the stronger protection to the traffic by splitting it among a set of sub-tunnels. All the Security Associations (SAs) are set up independently for all sub-tunnels. Both the sending and receiving entity combine all the sub-tunnels to one clustered tunnel. As different sub-tunnel uses different crypto key materials and processing parameters, it may achieve the stronger protection of the traffic across the insecure networks. In addition, it could possibly bring more benefits in terms of the network control. This seems like a potentially very complex feature that creates added opportunities for packet arrival reordering (of added jitter) without a good analysis of the security rationale. Also, as others have noted, this is not a multi-path feature, but a multi=-tunnel feature, so the doc name is inappropriate. The comment on multiple paths in the secruity considerations section is also in error. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt
At 4:39 PM +0800 1/29/12, zong.zaif...@zte.com.cn wrote: Hi Stephen, Tricci: Sorry that I didn't respond this email on time due to the chinese spring festival. I would like to thank Stephen first for reviewing the draft and giving me your suggestions. no problem. Happy New Year. From reading Stephen's email, if my understanding is correct, you assumed that SeGW will pass some information to the core network in order that the core network can verify the notarized FAP information? And you think that the information exchange betwen SeGW and the core network is a big change to IKE, is this correct understanding of your email? not quite. I was wrong to suggest that the SecGW sent the signed data directly to the core network. The data that the SecGW signs is presented by the FAP to the core network. My principle concern is that it is inappropriate to use an IKE payload to transport data to be signed, and then the signed data, when the consumer of this data is not IPsec. IKE payloads are used to convey data needed to create and manage SAs, including key material, data for authentication, etc. This signed data appears to be for authorization decisions effected by some element of the core network, outside of the IPsec SA itself. I understand that this configuration based assumption may have some limits, I think that to generate a cert by the SeGW and send it to the FAP and then from the FAP to the core network is a good implementation option. Perhaps I should make the CP flexible enough to adapt to all the implementation options. If you have any good idea on how the CP should be designed, could you kindly give me your suggestion? I don't want to suggest design options for you, as I am not familiar with the environment in which you are working. Also, lots of flexibility may not be a good ideas in a secruity context. I'm merely suggesting that using IKE payloads seems inappropriate for what I believe you are trying to do, based on reading one very brief document. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt
At 2:40 PM +0800 1/20/12, zong.zaif...@zte.com.cn wrote: Hi Folks: There is a new draft available that some of you may be interested in looking at. The draft is available via the following link: http://www.ietf.org/id/draft-zong-ipsecme-ikev2-cpext4femto-00.txt Please send your comments to the list. Thanks! BR Zaifeng Lookig very briefly at your doc, it seems that there might be a cleaner way to provide this capability, one that is more consistent with IETF standards. The term notarization seems a bit out of place here. The term certifies makes more sense, and suggests an alternative solution approach. Also, IKE is used to convey info between IPsec (note correct spelling) entities for use in key management and SA management,including access control. Having IKEv2 carry opaque info for use by an entity other than the IPsec implementation seems inappropriate. The doc suggests that the proposed new payload has minimal impact on IPsec/IKE. One must look not only at the bits on the wire, but also the IKEv2 communication paths at the endpoints. Carrying this data in IKEv2, for use by the core network also seems to require that IKEv2 pass the date on to external entities outside of the IPsec environment. That is a non-trivial change to what IKE does. In this case both the FAP and the SecGW are extracting signed data from IKE and passing it on to the core network, to authenticate the identify of the FAP and related FAP attributes. The SecGW is digitally signing an attestation about capabilities (including the identity) of the FAP. In PKI standards, this sort of info is usually expressed via an attribute cert. I doubt that many IKE implementations would know what to do with an attribute cert, but that's irrelevant here because IKE is not really consuming the signed data. The SecGW would seem to be acting as a CA or an AA. Why not have the SecGW issue a cert (or an attribute cert) to the FAP? Then have that cert be passed by the FAP to whatever really needs to consume it, along with signed data that establishes that the FAP is bound to the cert. That way the SecGW would not have to pass on data to the core network. One might also consider other, IETF standard mechanisms for passing around authentication and authorization data that is to be consumed by a 3rd party. Thsi sort of function is not what IKE is intended to perform. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Add new protocols that require AH?
At 4:54 AM +0530 11/23/11, Jack Kohn wrote: As per RFC 4301 implementing AH is a MAY and ESP a MUST. Given that most of what is achieved by AH can be easily achieved by ESP-NULL, is there a possibility that AH may get deprecated in the future. Should new protocols or mechanisms be defined in IETF that depend solely upon AH to be supported? Jack I concur with your observations. I recommend against new (or revised) protocols mandating use of AH. ESP NULL makes more sense in evey case that I have seen. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Does ESP provide all functionality offered by AH?
At 1:56 AM -0500 11/15/11, Steven Bellovin wrote: On Nov 13, 2011, at 4:30 PM, Vilhelm Jutvik wrote: De... The notion of discarding AH entirely has been discussed for many years. I've long been in favor of it, though I can't find a copy of anything old I had posted in my mail archives at the moment. The counter-argument -- and again, it's been presented many times over many years -- is that AH protects some IP options. That's useless in IPv4; the assertion is that it's important in IPv6. 4301 deprecates AH, by making support for it a MAY, vs. a MUST for ESP, as part of a compliant IPsec implementation. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Does ESP provide all functionality offered by AH?
In most contexts, there is no real benefit to using two SAs (AH + ESP) as you describe. I agree that, in almost every case, just using ESP will suffice. Using ESP in tunnel mode is certainly good enough, and less expensive than 2 SAs. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)
At 8:15 PM -0600 10/19/11, Kevin Gross wrote: We don't need decrypt and encrypt to take the same amount of time. We need encrypt+decrypt from master to slave to take the same time as encrypt+decrypt from slave to master. That further reduces the likely variance that is algorithm or mode specific, but it does increase the potential for variance due to differences in the processing capabilities of masters and slaves. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Perfect Forward secrecy
At 11:24 AM +0530 8/29/11, Naveen B N (nbn) wrote: Hi Scott, Even with the Pre-shared secret, the protocol can't keep up the property of perfect Forward secrecy. I have assumed the both the server and client use pre-shared secret, same below methods applies to Certificate based Authentication has well. Below steps show why. PFS refers to the ability of an adversary to recover the symmetric key(s) used to encrypt traffic. The analysis you provided does not address that concern. IKE's use of ephemeral DH provides PFS. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Security consideration for DTLS: Adversarial packet loss/reordering
At 11:05 PM +0200 2/11/11, Yaron Sheffer wrote: Hi Steve, [Cross-posted to ipsecme] I have always wondered about these sequence numbers, and the concept of anti-replay in IPsec. - IPsec is architecturally a plug-in replacement for IP. And IP allows for arbitrary packet deletion, duplication and reordering. - Anti-replay counters are giving us no end of trouble in clustered environments (e.g. http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ipsecha-protocol/). - IPsec (unfortunately) does not have an application API, at least in most implementations. Such an API might indeed have put this feature to good use. - And lastly, IPsec anti-replay is optional, which signifies to me that it's always been an iffy feature. I have looked at RFC 4301 again (the IPsec architecture), and it provides only weak justification for this feature. Can you please point me to a more convincing reasoning? Thanks, Yaron Can any Steve reply? While IP allows arbitrary packet arrival, IPsec allows a receiver to limit the extent of such OOO arrival, to enable it to detect and reject replay attacks. That is the rationale for AR and it is just as applicable in a clustered receiver context as in a single receiver context. The fact that it is optional to use (not to implement) is NOT an indication that it is iffy. It is an indication that not all apps might require its use, and some might find it in conflict with the app. That is a app-specific decision, not a decision to be made by an IPsec vendor. Use of this feature is declared via the SAD, so an administrative interface is one way to specify use of this feature based on the protocol and port #'s. I'm sorry that AR is causing problems in clustered contexts, but that is not a justification to not support it. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Clarification regarding AH Header Length
At 10:40 AM +0530 11/23/10, Anil Maguluri wrote: Content-Language: en-US Content-Type: multipart/alternative; boundary=_000_903D13EA90218E43BA0881BC8B569C7D0F8B8FB7B1BLRINMSMBX01b_ Hi All, Please clarify me the below query. è When AH Header Length becomes zero (in which scenario)? è If the length is zero, means no SN and AH Data wont be available in the packet. Regards, Anil Kumar Maguluri If AH is present, it will not have a 0 length. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Ticket #195 - Protection against SPI enumeration
At 4:37 PM +0200 10/20/10, Yoav Nir wrote: Yaron: 10.3: of course, it is possible that *both* implementations generate predictable/short SPI values Hi all. I think this one was solved together with ticket #191 (The danger of predictable SPIs), but requiring that the token maker randomize IKE SPIs. Unless somebody (like Yaron) objects within the next few days, I will close this issue as well. And yes, Yaron, I have made the language about the PRNG less wimpy. Yoav Why not allow either peer (or both) to add a sizeable nonce as a separate source of unpredictable data? Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE6 Negitaion when Peer Address ND not yet started.
Yoav, I did not mean to suggest that the SPD UI has to be a low level interface that makes it difficult for users to achieve their secruity goals. On the other hand, I would be surprised if any vendor's UI really accepted English (or another human communication language). So, despite the fact that policies are written in a human communication language, those policies need to be entered into a UI via a language that is more rigorous. I don't think we're saying anything different; we both agreed that a UI can provide simple ways for users to enable the needed bypass entries. RFC 4301, in Figure 1 and Figure 3 shows where IKE lives relative to the IPsec boundary, and that implies the need for the sort of SPD entries you cited in your message I do think that Syed was saying something different, i.e., that the IPsec architecture document should explicitly say what SPD entries must be created to enable bypass of this sort of traffic. That would be a bad idea, as it would require revisions to the architecture every time some new example of such bypassed traffic arises. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE6 Negitaion when Peer Address ND not yet started.
At 10:00 AM +0530 2/19/10, Syed Ajim Hussain wrote: Hi Yoav Nir All Group Member Thanks for your quick response. I think, instead of user takes special care by adding extra Rule to allow un-encrypted ND traffic(unicast) , There should be some RFC guidelines, such that IPSEC/IKE protocol itself can take care. It will be problem in Interop also. Below guidelines can be used. 1. if packet is of IPv6 NS/NA types , IPSEC Policy matches , but Security Association(SA ) not yet established , then send can send Un- encrypted packets. Also Receiver should accept an un-encrypted packet for NS/NA when IPsec policy matches But No Security Association(SA) presents. With Regards Syed Ajim Syed, We don't generally provide exceptions for control traffic to cross the IPsec boundary. Note the extensive discussion in 4301 on ICMP traffic. What you described above is a policy decision and it needs to be explicitly stated in the SPD. At most we might remind folks to configure such SPD entries in an IPv6 environment. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: Issue : Regarding EAP identity
At 12:14 PM +0200 2/10/10, Alper Yegin wrote: Dan, Hi Alper, In that case there is no standard way for the AAA server to inform the IKEv2 responder of this policy that it needs to enforce. So that sounds unworkable. I guess it can be specified. The IKEv2 responder already has the mechanisms in place to enforce a policy based on the authenticated identity of the IKEv2 initiator. So if EAP is being used then all we need is a way to get that authenticated identity from the AAA server to the IKEv2 responder. Isn't IDi what IKE deals with? not always. See the discussion in 4301 re the PAD. I'm not aware of a document to allows a AAA server to export the authenticated identity to the AAA client (maybe such an attribute already exists, I just don't know) I'm not aware, either. In other uses of AAA (such as with WiFi, WiMAX, 3GPP2, etc.) I know that the subscriber ID is hidden from the NAS. There are even specific methods deployed for that purpose. So, disclosing that ID would not be acceptable there. I'm just not sure if the same privacy concerns apply to the VPN deployments. There is a difference here in that the IPsec device normally performs peer auth and access control, independent of an AAA server. but surely it would be easier to define that then to define a standard way to send some policy from AAA server to IKEv2 responder. Right? If you don't do that, then you have to maintain per subscriber policy on each one of the VPN gateways. Now that starts defeating some of the purpose that AAA was offloaded to a centralized/dedicated server. Maybe. I thought the principle argument for AAA (really RADIUS) use here was that enterprise IT folks already managed user authentication via these servers and wanted to use that aspect of their investment in the IPsec context. If one wants to rely on these servers for more than just user authentication, a more complex solution is needed. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: Issue : Regarding EAP identity
At 11:41 AM +0200 2/8/10, Alper Yegin wrote: Yoav, When the IKEv2 responder offloads the Authentication, Authorization, and Accounting (AAA) responsibilities to a centralized AAA server, it is no longer in the business of figuring out who the peer is, if the peer is really who it claims it is, what policies to apply to the peer. These are the things handled by the AAA server, and communicated to the IKEv2 responder. Policy needs to be enforced by the IKEv2 responder, but the policy is determined by and communicated to the responder by the AAA server. Alper AN IPsec implementation enforces access controls based on SPD entries, creating SAD entries for approved traffic flows. I can imagine that an AAA server may authenticate a user and advise the IKE component of that action. But, there needs to be a way for IKE to know what ID is being asserted and to use that in the SPD lookup. The PAD normally governs such actions, so maybe the AAA server is off loading part of that processing. It that clearly defined anywhere? Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
At 3:02 PM +0530 1/11/10, Bhatia, Manav (Manav) wrote: Dan, You trust the end nodes to negotiate WESP and encapsulate their ESP packets in WESP but you don't trust the content they put into those packets. Is that the trust model you're operating on? No. We trust the end nodes to put the right information in the WESP header. But, we don't trust the intermediaries, that could have mangled the packet so that it goes through the firewall/deep inspection device. If that happens, then the packet should not be consumed, which would make the attack by a malicious middle box worthless. Hope this helps. Manav I don' know about anyone else, but it didn't clarify the threat model for me :-). In some messages the phrase trusted intermediaries is used, which does not seem to fit your text above. If you are alluding to a MITM, say so. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
At 5:13 PM + 1/7/10, Brian Swander wrote: In this scenario, the sum of functionality is greater than the parts - end hosts and intermediaries working together can achieve better overall security than either working in isolation and in complete distrust of the other. It'll be up to the individual customer on where to dial the knobs, and we should enable the options and make them as deployable as possible. I.e. if customers really want to manage full IP address policies for who can do encrypted ESP, than that option should be available. If they want good intermediary audit trails with a simpler intermediary config, that option needs to be available. If they want best effort load balancing/WAN optimization, that option needs to be available. This is no longer an either-or adversarial situation between end systems and intermediaries, and the intermediaries in play are not relegated to security intermediaries - although clearly security intermediaries are important here, too. bs Brian, I was really hoping for a simple answer to the questions I posed in my message. Instead IO got a message with words like holistic and phrases like the sum of functionality is greater than the parts which is a bit too new age for me :. I'm guessing that hints to the answer I was looking for are lurking in your second paragraph: It'll be up to the individual customer on where to dial the knobs, and we should enable the options and make them as deployable as possible. I.e. if customers really want to manage full IP address policies for who can do encrypted ESP, than that option should be available. If they want good intermediary audit trails with a simpler intermediary config, that option needs to be available. If they want best effort load balancing/WAN optimization, that option needs to be available. In interpret this to mean that yes, you realize that an intermediate system that wants to enforce the sort of policies you previously described would, in fact, have to be configured with IP address info (or its moral equivalent) in order to enforce such policies. In this case your argument against my suggested approach to dealing with incremental deployment of WESP disappears (which may be why you chose to not make this statement directly :)). You seem to offer an alternative, i.e., to give customers the ability to have intermediaries inspect or not inspect traffic based solely on what the traffic labels indicate. This amounts trusting the hosts to label traffic properly, which is the alternative answer I postulated and criticized. Again, you chose not to answer this directly, but instead alluded (in your last paragraph) to the need to think of end systems and intermediaries as no longer operating in an adversarial environment. Historically, the principle motivations for security intermediaries include countering (security relevant) misconfiguration of hosts, an inability to manage the (security relevant) configurations of hosts, dealing with compromise of hosts, etc. These are all instances where the intermediaries do not trust the end systems. Please elaborate on why you believe that these are now outmoded reasons for how security intermediaries should relate to hosts. You describe allowing intermediaries to generate audit trails (presumably capturing some info about the encrypted traffic that they were unable to inspect, but you didn't say specifically) as an alternative to policy enforcement. There may be some merit to this in some contexts, but I think the WG needs to have a clear picture of what is being proposed and the associated rationale. I searched the IPSECME archives and found only one set of messages inn 2009 that include the word audit in the context of this discussion. These messages were a thread involving Ken and Tero, and appeared in the 2/4-11 timeframe. The messages focused on the performance and cost issues associated with implementing stateful vs. stateless intermediaries, as part of the larger debate on heuristics vs. explicit packet labeling. This thread did not raise the issue you did above, i.e., that a major motivation for WESP is to enable users to audit encrypted traffic flows as an alternative to using access control info to permit/deny such flows. I don't think the WG should make major design decisions without a clear picture of the various use cases that are being cited, but which lack detailed descriptions and thoroughly-articulated assumptions. I think the WG needs such descriptions and associated analysis to guide its decisions. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
At 11:14 AM -0700 1/5/10, Grewal, Ken wrote: Yes to both, based on arguments already discussed numerous times in the WG via presentations, 12 iterations of the draft and multiple WG last calls + AD reviews! The main motivation for extending the ICV was to counter some of the issues originally raised by Steve Kent - malicious entities modifying portions of the WESP header to bypass legitimate parsing of the packet by Trusted Intermediary (TI) devices such as IDS/IPS/etc. This can be addressed by the recipient explicitly validating the WESP header before accepting the packet or implicitly by including the WESP header as part of the ICV check. My recollection is that I identified a vulnerability that arose because of the potential for a mismatch between what a TI checked and what the receiver acted upon, irrespective of how that mismatch arose. I think I suggested that this vulnerability might be remedied by requiring the receiver to verify that the WESP header info was consistent with what the receiver was acting upon, as part of WESP processing. The current I-D calls for this check to be performed by the recipient. Above you state that: This can be addressed by the recipient explicitly validating the WESP header before accepting the packet or implicitly by including the WESP header as part of the ICV check. I disagree with the or in this sentence, for two reasons. First, the I-D calls for the receiver to perform the consistency check, so it's not an or. Second, it would not suffice to perform JUST the ICV check you described, since that would not address the possibility that the sender created the misleading WESP header. The motivation for allowing WESP to be used for encrypted data was brought up as a consistency argument and also allows for future extensibility in a uniform manner. I agree that this was not part of the original charter, as shown in the earlier revisions of the WESP drafts. It appears that we agree that it was out of scope (although others do not), and that the principle motivation cited was to allow for extensions. The phrase :in a uniform manner is, I believe, shorthand for extensions that apply to encrypted traffic, right? BUT, this was discussed numerous times within the WG (including an open ticket on scope) and it was agreed that this would be a useful bit to include in the flags, hence introduced in the latter revisions of the draft. I have already admitted that I lost track of this aspect of the discussion, among all of the ticket items that the WG has processed. (BTW, I congratulate Paul and Yaron for doing a very good job of managing such a large number of issues in a detailed fashion. The fact that I, and maybe a few other folks, lost track of the details on one of the many items being worked is not a reflection on the management style that have employed.) When I re-read the I-D during IETF last call, I was surprised to learn that ESP processing had been changed, so cause the ICV to cover non-ESP fields. This seems to be unnecessary and it is a bad design, in my opinion. Note that this does not mandate using WESP for encrypted traffic, but allows it as optional and can be dictated as part of the session setup based on local policy. Another benefit may be that in running mixed mode environments (encrypted + ESP_NULL traffic), it allows for an explicit distinction from the packet that certain traffic is encrypted and other traffic is not. Otherwise, one would use ESP and WESP in these mixed mode environments and to be absolutely sure if ESP traffic is encrypted or not, would need to fall back to heuristics, which somewhat defeats the object of having this spec. If local policy can be used to dictate whether WESP is or is not used for encrypted traffic, then that policy also can dictate that ESP is used only for encrypted traffic. Even in an environment where some but not all hosts support WESP, I don't see the need for this flag. A host that is WESP capable need not use WESP for encrypted traffic; it can use ESP. if so, then ITs see three classes of traffic: - encrypted using ESP - integrity-protected using WESP - integrity-protected using ESP The third class of traffic poses a problem for the ITs, but adding the encrypted flag to WESP does not seem to address that problem. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Gabriel, ... One may argue whether that consistency check is best served by extending the ICV to include the WESP header fields (per the current WG consensus as expressed in the existing draft), or whether that is best done by the end nodes checking the fields explicitly. My reply to Ken addresses the issue you raise about the need for consistency checks. I don't think there is a misunderstanding here. The I-D calls for such checks and I agree that they are the right thing to do. What is at issue, in part, is whether the ESP ICV should have been extended to cover the WESP header. My view, and that of several other folks, is that it should not have been done, for the reasons I cited previously. This aspect of the current I-D could be fixed by having WESP have NO ICV, of by having WESP include its own ICV, which would call for nested processing by hosts. As I explained in my reply to Ken, extending the ESP ICV does not achieve the same effect, so this is not an either or situation. On a broader note, as Paul and Russ noted, the IESG gets to decide whether a WG-approved I-D will be published as an RFC (modulo appeals to the IAB, etc.). The IETF last allows anyone, even members of the WG that approved an I-D, to raise questions that the IESG will consider as part of the approval process. I've had over 15 years of experience as a WG chair (opening for Paul to make a snide comment :-)) and I have had WG members raise questions during IETF LC, after WG consensus has been achieved. This is how our process works. Also, even in the face of WG consensus, an AD may request changes to a document. This is not uncommon. when this has happened in the PKIX context, the Wg chairs and document authors have discussed the requested changes with the AD and we have almost always made the changes. Sometimes this has required another WGLC. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
At 10:10 PM + 1/5/10, Brian Swander wrote: I'll resend my message from earlier today that gives a concrete scenario for why the WESP encryption bit is in charter. To satisfy the existing charter item, we need a deployable solution, which entails working with legacy systems that don't support this functionality yet. Here's an explicit scenario that requires the encrypted bit for WESP, fully within the current charter of enabling ESP-NULL inspection. Transport policies for within an organization that want to enable intermediary inspection of ESP-NULL non-heurisitically. Organization has a mix of version of systems. Sample policy: When talking to/from non-WESP capable machines: must do ESP-NULL only When both peers are WESP capable: do WESP/ESP-NULL most places. However, where policy requires encryption, do WESP/ESP. This is where I have a problem with the analysis. If the policy were that WESP-capable hosts did ESP when then needed to send encrypted traffic, the flag inn question would not be needed, right? I don't think we can justify the inclusion of this flag based on the scenario you described above, because that scenario adopts a particular local policy that it not required. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
At 9:45 AM +0530 1/6/10, Venkatesh Sriram wrote: Would it help if WESP is renamed to something else? Since we're discussing the fundamental principles of the protocol, i see no reason why we cant change the name, if that helps. I think its the Wrapped in the WESP thats causing most heart burn, lets change that to something else .. something thats appeases everyone. I agree. How about VESP - Visible ESP ? Its phonetically the same as WESP. :) I agree that WESP should not be clipped to only support ESP-NULL; WESP was not initially proposed as a protocol that would encapsulate encrypted traffic, so the term clipped is approproprioate only relative to what WESP has mutated to become :-). it should be able to carry encrypted packets as well. Without this the middle boxes would never know whether the ESP packet thats passing is encrypted or not. One way could be to deprecate the use of ESP-NULL in ESP, which would mean that if someone sees an ESP packet then it MUST be an encrypted packet. This is a local policy decision that avoid the need to have a flag in the WESP header to indicate encrypted content. It need not be a standards track action, as you suggest above. This is as i understand impossible, so the only option left is to let WESP also carry encrypted packets. It certainly is not impossible as a local policy. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
At 5:19 PM +0200 1/6/10, Yaron Sheffer wrote: I would like to reframe the migration discussion. Manav, Scott and everyone else, please correct me if I got it wrong. Suppose we have a middlebox that can do useful things if it knows that the flow is unencrypted, and only basic things if it is encrypted. A load balancer is a good example. We are slowly migrating all endpoints in an enterprise to be WESP-capable. During the migration period, the middlebox sees 3 or 4 types of traffic: 1. WESP from the new nodes. 2. Depending on your view of whether we have the bit in question: encrypted ESP from WESP-capable (new) nodes. 3. Encrypted ESP from WESP-incapable (old) nodes. 4. And ESP-null from old nodes. Taking Manav's perspective, the middlebox can always use heuristics to distinguish encrypted ESP from ESP-null. As the number of WESP-capable nodes grows, it will see less and less ESP, so will spend ever less CPU power on heuristics. It's not clear why nodes sending encrypted traffic would need to use WESP (vs. native ESP), even if there is a WESP flag that indicates an encrypted payload. Thus I don't agree with the conclusion that over time there would be less ESP over all. If you said there would be less use of ESP-NULL (w/o a WES header), I would agree. To suggest otherwise is to pre-suppose that replacing ESP with WESP in general is a goal, and I certainly don't think the WG has indicated that (nor is it in scope at this time). Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
At 9:34 PM +0200 1/6/10, Yaron Sheffer wrote: Hi Steve, [No hat.] Thanks for the analysis, I hope this'll help the discussion to converge. You are taking an either-or approach in the last paragraph below. But assuming that WESP is useful (bear with me), there will be a gradual deployment within any given network. I agree that heuristics will still be needed, until the last endpoint is WESP-enabled (i.e., forever). But if we adopt W*, during the migration less and less heuristic processing will be needed. Much of this discussion is about performance, so quantitative arguments are also useful. Thanks, Yaron Yaron, So, is the argument that use of W* would reduce the quantity of traffic that requires heuristic processing at some stages in the deployment process, because as the number of WESP-capable nodes increases, cases 3 4 predominate? if this is the argument, why did it take this long to get a clear articulation of the argument (and why was I the one who had to do the analysis to support it :-))? That argument makes sense, but only in the context of other assumptions about deployment (which have yet to be articulated). For example, if an enterprise deploys an intermediate system that can perform packet inspection on IPsec traffic before most of the nodes are WESP-capable, then that system will have to use heuristics to deal with the vast majority of traffic initially. Such a system could continue to use those heuristics until WESP-deployment is complete. So that scenario does not motivate use of W*. However, if the traffic load grows a lot during deployment, it might exceed the capacity of the intermediate system before WESP deployment was complete. In that case use of W* would help, if encrypted traffic were a lot more common than integrity-protected traffic. Or, one might argue that use of W* would allow deployment of an intermediate system that uses WESP, but still incorporates heuristic support, at an earlier stage in WESP-deployment, though not initially. Of course the (earlier) point at which such deployment could take place is very context-specific. These could be reasonable arguments, but I've not seen them articulated clearly. Nor have I seen any rough estimates of ratios of traffic types and the processing burden of heuristics to provide some quantitative basis for arguments of this sort. So, I think the WG needs to do more homework on this if we're going to make such arguments. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
At 12:48 PM -0700 1/6/10, Grewal, Ken wrote: Steve, The either-or on using an ICV or explicitly checking the WESP header on the recipient was based on the assumption that the threat does not come from the sender and only from some other malicious entity after the packet has been sent. This was the reason for simplifying the header check by using the ICV, instead of explicitly checking every field. You cited my comments about a vulnerability as the rationale for pursuing this design. I noted that my comments did not specify the source of the mismatch between header data that IPsec acts upon (for access control) vs. what WESP caused an intermediate system to examine. You chose to focus on one possible source of manipulation, i.e., a MITM attack. That's fine, but it does not necessitate changing the ESP ICV computation, i.e., checking by the recipient suffices. Also, the I-D calls for consistency checking, so I was (justifiably) confused by the either-or statement you made. If the sender is malicious, then an encrypted (covert) channel is all that is needed to bypass any intermediate checking and furthermore, any explicit checking of each WESP field on the recipient does not help, as the payload can contain whatever is intended by the malicious sender! I see we have a miscommunication about the nature of the vulnerability that I cited. It is what I noted above, i.e., a mismatch between header data that IPsec acts upon (for access control) vs. what WESP caused an intermediate system to examine. This is an old security concern, dating from the mid/late 1970s, when it was discovered that one could make a call to an OS with one set of parameters, and then change the parameters after an access control check was performed but before the OS acted upon the call. The fix for this sort of attavck was to copy the parameters into OS-controlled address space, out of user-space. An encrypted covert channel was not what motivated my comments, because IPsec makes its access control decisions based on the 5-tuples from the IP and transport layer headers. We did debate this a number of times and extending the integrity appears as early as May of last year in version 3 of the draft (at version 12 now), so it should not have been a surprise at last call. I have already apologized for not closely tracking the changes to WESP. However, during IETF last call everyone is free to raise questions of this sort, so we ought not devote too much time and energy to this aspect of the discussion. In either case, as Gabriel indicates in a separate email, if it makes sense to go back to not integrity protecting the WESP header, I am fine with that. This was the original position and aligns with your other email on WESP acting as a wrapper to ESP, and should also address other comments indicating that the name Wrapped ESP is a misnomer! That works for me too, but I would feel better if we were all in agreement about the nature of the vulnerability that I cited, which motivated this in the first place. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] this discussion
Folks, The flurry of messages that have been exchanged today and yesterday have often struck me as incorporating rather vague arguments. I find myself having to do a lot of work to fill in the blanks for not well-articulated comments, construct detailed analyses, and postulate rationales for the arguments made by others. I think everyone ought to spend more time composing messages that are clear and persuasive, so as to not unduly consume the time of others. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
At 7:55 PM + 1/6/10, Brian Swander wrote: I trust my clarification (to Yaron) addressed these questions. Let me know if there are any outstanding. I understood the first two lines about lots of legacy systems, only a few of which need to perform encryption. The next two lines were too terse for me: Routing infrastructure that doesn't do heuristics Requires intermediaries that can do full ESP-NULL parsing if the intermediaries are part of the routing infrastructure, why use different terms in these two lines? Also within an enterprise context, one might well be able to configure the intermediaries with the addresses of the few machines that perform encryption, and which therefore are allowed to communicate with one another w/o benefit of packet inspection. So I would not say that your response addresses my questions in the lager context. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
At 12:27 AM +0200 1/5/10, Yaron Sheffer wrote: Hi, We have had a few discusses during the IESG review of the WESP draft. To help resolve them, we would like to reopen the following two questions to WG discussion. Well reasoned answers are certainly appreciated. But plain yes or no would also be useful in judging the group's consensus. - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) defines the ESP trailer's ICV calculation to include the WESP header. This has been done to counter certain attacks, but it means that WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do you support this design decision? My previous message describing why I think the current design is seriously flawed provided the rationale for my NO response to this question. WESP as a modular, separate, nested protocol would be preferable. - The current draft allows WESP to be applied to encrypted ESP flows, in addition to the originally specified ESP-null. This was intended so that encrypted flows can benefit from the future extensibility offered by WESP. But arguably, it positions WESP as an alternative to ESP. Do you support this design decision? I am concerned about the wording of the penultimate sentence above. Several folks argued against applying WESP to encrypted traffic and they cited various reasons for why this might be inappropriate. You did not choose to cite those reasons, which I think may bias responses. I think the two major issues cited re the extension of WESP to encrypted traffic are: - it is formally outside the charter - no good WESP extensions have been proposed for encrypted traffic Even if WESP is approved for use with encrypted traffic, that does not mean that it will supplant ESP. ESP still has a smaller header than WESP, so for environments where there is no intent to accommodate middlebox snooping, ESP is still preferable. So, NO to this question as well. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
At 6:17 AM +0530 12/29/09, Jack Kohn wrote: Are you suggesting that ESP ICV should not cover the WESP fields? I think, and my memory could be failing me, that this was discussed in the WG before this got added to the draft. Jack I am suggesting that WESP should be cleanly layered, in one of two ways: - do not interfere with the ESP ICV computation (be unauthenticated, for the reasons already noted by Tero and Russ) - incorporate the necessary info from the ESP header and not replicate the ESP structure, i.e., become a full-fledged alternative to ESP-NULL (not for ESP when confidentiality is employed) when end systems are configured to expose encapsulated header info to middle boxes. The current design is a hybrid that imposes undue complexity on IPsec implementations. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: Childless IKE SA
At 8:20 AM +0530 12/18/09, Raj Singh wrote: ... IKE is Internet Key Exchange protocol NOT IPsec Key Exchange protocol. IKEv2 is not just a mean of exchanging keys but its a full package. This package provides mutual authentication, keys and readiness to secure data as needed. The main motivation for this draft is Remote Access VPN scenario. Depite the name, IKE really is the IPsec Key Exchange Protocol. It is true that the original vision for IKE was much broader, but over time we have tailored IKE to support IPsec. Steve___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Yaron, I hate to admit it, but I lost track of the details of WESP as it progressed through WG discussions and briefings at IETF meetings. When I read the I-D in detail, I was very surprised to see that it was no longer a neatly-layered wrapper, as originally proposed. The fact that it now calls for the ESP ICV to be computed in a new fashion means that it really is replacing ESP, when used to mark ESP-NULL packets. From a protocol design perspective, the current version makes no sense to me. Why keep the ESP header when ESP processing is now changed in a significant way. The WESP header cannot be processed (completely) by itself, because of the dependence on the ESP ICV. So it makes little or no sense to retain the ESP header in this context. I see no strong backward compatibility motivation for this format, given that ESP processing must change to accommodate WESP (as defined). The issue of using WESP for marking encrypted traffic is a separate topic. I believe the rationale you cited was to enable WESP extensions, but I may have missed other arguments put forth for this. Since most of the WESP extension proposals discussed so far have proven to be questionable, I am not enthusiastic about that rationale. Others have noted that using WESP with encrypted traffic is not consistent with the scope of the WG charter item that authorized work on WESP. Unless Pasi approves a WESP extension WG item as part of re-chartering, I think it is inappropriate to have a flag to mark a WESP payload as encrypted. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: WESP extensibility
At 6:24 PM + 12/7/09, Brian Swander wrote: 0 - option data does not change en-route. This option is included in the WESP ICV computation. We'll be using this flag, so this option will always be integrity protected. integrity protected for checking by the end system, but not verifiable by the intermediate system. I'm not sure what you mean by effecting key distribution. what I meant was that the intermediate system cannot verify the WESP data. In the integrity only case, the intermediaries can still see into the packet. In the fully encrypted ESP case, only the WESP extension will be visible, and the intermediaries will have to trust the end systems to do the correct marking. And the end system will have to check another set of data, which may be complex. A while ago I noted a vulnerability in a prior version of WESP. Specifically, the (ultimate) recipient of the WESP packet has to verify that the Next Header and the HdrLen fields are consistent with the encapsulated content that it is processing. Othwewise, an attacker could change these fields to make the packet acceptable to an intermediate system but be different from what the recipient processes. This proposed extension would require that the recipient MUST also verify that the data being made available to intermediaries for packet inspection is consistent with the data being delivered as IPsec output. At the current level of specification, this additional processing is arbitrary. If I were a hardware IPsec vendor I would worry about the possible implications of this sort of facility. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: WESP extensibility
At 7:50 PM + 12/7/09, Brian Swander wrote: In case it wasn't clear for the earlier WESP discussions, we need this to also work with simple transport mode: i.e. not just transport mode inside tunnels terminating at various infrastructure, and not just in tunnel mode. The transport nesting from 2401 doesn't give us what this extension proposal does. bs Understood. And I agree that transport mode inside of a tunnel does not provide comparable functionality. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: Labelled IPsec
Paul, From your comments it seems as though an IP option would be preferable, as it is not IP-sec-specific, and it an be protected if needed, in the IPSec context, e.g., via tunneling. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] password auth methods debate
Folks, I think there is merit to pursing both the EAP-based and the SPSK-based password authentication proposals as WG items. My rationale is: - EAP-based methods are well-suited to client-server interactions and to enterprise environments that already use RADIUS/DIAMATER. Unfortunately, these methods seem ill-suited to peer communications, and IPsec is a peer communication architecture, so having only these methods available for password-based auth seems inappropriate. Also, Dan has indicated that there are IP clams associated with the specific methods that have been cited, which makes me leery of relying too heavily in them. - a generic password-based scheme seems desirable for peer (cs. client-server) contexts, and if such schemes are IP-free, so much the better. However, enterprise use of IPsec is primarily for road warriors, and thus is a client-server context, and there is a strong preference for a RADIUS/DIAMATER compatibility in this context. So, i see a benefit in this WG pursuing both work items. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WESP - Roadmap Ahead
Jack, Thanks for describing the additional selection criteria that must be employed to avoid the problem I cited. Given this more complete description of the selection criteria, I am not convinced that that is a significant benefit for using WESP in this context. - Whether using WESP or just ESP-NULL, the router needs to determine that the packet is addressed to it. This means looking for either a unicast address (per interface?) or a multicast address. I thought that the traffic of interest would arrive on a multicast address. If so, then this is a very easy check. - Traffic other than OSPF can be addressed to the router, but I'm not sure what other traffic would be multicast. For unicast traffic addressed to the router, if some of that is protected using ESP with confidentiality, then the address check might have to be extended to include a source address as well. - There is an assumption that the OPSFv3 traffic is (ultimately) protected using ESP-NULL. The next check that you described, i.e., looking for a few bits that indicate whether the payload is OSPF and appears to be a HELLO or ACK, is the real focus of this thread. There appears to be a couple of cases: - If all multicast traffic directed to the router and protected using ESP is ESP-NULL, then WESP seems to help ONLY if there are algorithms being used for different SAs, AND if those algorithms result in different offsets for the start of the ESP-NULL payload. It's not clear that this is a realistic case. But, in this case, using WESP could avoid the need to check the SPI in the packet. What's not clear is whether checking for WESP and extracting the offset info is faster than matching against a set of SPIs. - if some multicast traffic directed to the router is protected with ESP with confidentiality, in addition to the ESP-NULL OSPF traffic, then one would need to check SPI values to differentiate between these two classes of traffic. So, the question of whether we have one multicast SA for this traffic, or potentially a lot of these SAs is potentially relevant. As I mentioned in my previous message, this is not completely clear to me from 4552. You didn't respond to that part of my message, so I don't know if that means you find the RFC unclear on this point as well, or if you didn't think it mattered to this discussion. Well, if appears to matter, if one believes that the number is substantial. So, the bottom line appears to be that WESP might be better than just using ESP-NULL, depending on the number of multicast SAs that terminate at the router, that make use of ESP, and maybe whether the ones that use ESP make use of different integrity algorithms that result in different offsets. That is a lot of IFs for which we have yet to get an answer. In any case, as I noted earlier, because of the use of manual keying in this context, selecting a subset of packets for out-of-order processing does not impose any burden on the IPsec for the remaining packets, so all of the comments about that issue were red herrings. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: WESP extensibility
I am opposed to pursing this work at this time. The ongoing discussion on the list suggests that the arguments put forth for WESP use in the OSPFv3 context, the first concrete proposal outside of the middlebox inspection context that motivated WESP, have not been validated. The presentation in Hiroshima listed a variety of possible use cases, without providing any detailed analysis, and at least one such case was considered and rejected by the IPSEC WG on at least two occasions. My recollection is that Pasi agreed with my suggestion that at least 2 or 3 valid use cases need to be thoroughly vetted before the WG pursue this as a new work item. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WESP - Roadmap Ahead
At 12:11 PM +0100 11/25/09, Daniel Migault wrote: Hi Manav, I agree that for an already negotiated SA, the SPD lookup detects IP source address spoofing. So in that case ESP detects the address spoofing during the SPD check whereas AH would detect it while checking the signature check. However SAD lookup is done with the longest match rule, and section 4.1 of RFC4301 specifies : 3. Search the SAD for a match on only SPI if the receiver has chosen to maintain a single SPI space for AH and ESP, and on both SPI and protocol, otherwise. This seems to enable a ESP or AH datagram with spoofed IP addresses to match the SAD and SPD. I'm confused at this juncture. The 4301 inbound processing algorithm (section 5.2 in RFC 4310) refers to SAD entries for processing IPsec-protected packets; the SPD inbound cache (SPD-I) is used only for bypass and discard traffic. So there should be no reference to the SPD in the sentence immediately above, right? Also, you should remind folks that this rule applies only to multicast SAs. That's relevant to the OSPFv3 discussion we are having, but it seems inconsistent with the comment below of a middlebox that changes addresses, i.e., does one really expect to encounter a NAT on a link between two routers running OSPF? I am not criticizing your later comments about AH vs. ESP applicability in mobile environments, just trying to keep the various arguments straight. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WESP - Roadmap Ahead
At 11:09 PM +0530 11/21/09, Jack Kohn wrote: Steve, 4301 contains We have explicit directions on how to use multiple SAs when the peers know that they want to send traffic with different QoS parameters. This appears to be an instance where the middle boxes are to examining traffic, and putting in into different QoS queues. That raises the question You got it all wrong. The sender is sending packets with the same QoS parameters; its the receiver thats trying to prioritize some packets over the others. One would typically do this for the Hellos/KeepAlives that are associated with a protocol, so that the adjacency/peering session are not timed out. Jack Jack, Maybe I got it all wrong because the explanation provided in the messages was, at best, ambiguous :-). Your description above is only marginally better: - it fails to characterize the range of protocols for which you believe this argument applies, -it fails to explain how WESP is relevant, since a receiver has the ability to process encrypted packets. WESP is a protocol that has been promoted as designed to aid middle boxes, not end systems Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WESP - Roadmap Ahead
At 6:48 AM +0530 11/13/09, Bhatia, Manav (Manav) wrote: Daniel, AH is a security feature we need to keep for header authentication Am really not sure about the value that AH adds even in case of header authentication. So what fields does AH protect: Version, Payload length, Next Header, Source IP and dest IP you forgot IPv4 and IPv6 options that have predictable values at the destination Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WESP - Roadmap Ahead
At 7:44 AM +0530 11/12/09, Bhatia, Manav (Manav) wrote: Steve, I would have no problem deprecating AH in the context of the IPsec architecture document, if others agree. It is less efficient than ESP-NULL. However, other WGs have cited AH as the IPsec protocol of choice for integrity/authentication in their environments, so there will be a need to coordinate with them, and it may be unacceptable to kill AH as a standalone protocol for them. I agree that it is a trifle too early to start deprecating AH, though I wouldn't mind doing so. OTOH, don't most WGs already suggest AH as a MAY, and ESP-NULL as a MUST? Not always. For example, I believe that OSPF security makes use of AH, outside the IPsec context. In any case what should be the stand for the newer work that comes out of these WGs. Should they spell out support for AH, or should they just be talking about ESP (or ESP-NULL or WESP)? I'd recommend ESP-NULL, unless the context on which the operate might require inspection by an intermediate system. If we want to deprecate AH, or at least discourage its use in the context of the IPSec architecture in the near future then shouldn't we be working on this? Part of the problem is that some WGs want to make use of IPsec protocols outside of the IPsec architecture. I am not comfortable with the notion of ESP with WESP. WESP adds more per-packet overhead than ESP, and some users are very sensitive to this aspect of IPsec use. Also, other WG rely on ESP and we would need to convince them that the packet inspection features of WESP merit making changes to their standards, which might be a tough sell. I agree. However, we should start socializing WESP in other WGs so that folks are at least aware of it. Agree. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Difference between IPv4 and IPv6 IPsec
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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt
Marcus, Thanks for the additional background. I am not an expert on 3GPP. Do you know if there an IETF liaison to the 3GPP? If so, the right approach is to have that individual coordinate an action like this between the SDOs, i.e., when SDO-A wants SDO-B to modify/extend a protocol to accommodate a function that SDO-A wants to implement using SDO-B's protocol. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt
At 4:06 PM -0400 9/11/09, Marcus Wong wrote: Steve, you are mostly right, but this I-D only deals with the integrity data exchange using the notify payload. Thanks. Marcus Thanks for the clarification. That still raises the question of why we ought to duplicate this NEA functionality in IKE. Does the I-D provide suitable motivation for that, and has the idea been passed by the NEA WG folks? Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-wong-ipsecme-ikev2-integrity-data-00.txt
At 11:46 AM -0400 9/11/09, Marcus Wong wrote: Hi Everyone, I'm new to the working group. I've uploaded a draft on the use of notify payload for integrity data exchanges in IKEv2 for your comments and review. All comments are highly appreciated. Thanks everyone. A new version of I-D, draft-wong-ipsecme-ikev2-integrity-data-00.txt has been successfuly submitted by Marcus Wong and posted to the IETF repository. Filename:draft-wong-ipsecme-ikev2-integrity-data Revision:00 Title: Integrity Data Exchanges in IKEv2 Creation_date: 2009-09-11 WG ID: Independent Submission Number_of_pages: 9 Abstract: IKEv2 supports mutual authentication of the peers but does not support platform integrity validation of the peers nor does it support the exchange of data related to the platform integrity validation. This extension allows platform integrity validation data to be exchanged from one peer (initiator) to another (respondent), allowing the other peer to either use the data for statistical analysis, pass it along to a validation entity for validation or pass it along to a Fraud Information Gathering System for fraud detection or analysis. I have mot read you I-D, but this sounds like a NEA issue being pushed into an IPsec protocol. Am I wrong? Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New draft about issues in alternative Traffic Selectors in IPSec/IKEv2
At 2:57 PM +1000 7/27/09, Greg Daley wrote: ... Your reference to 4301 regarding the use of multiple parallel SAs solving the example is helpful. I will remove the example for clarity. As Tero noted, RFC 4301 provides a discussion of how an implementation can, on a local basis, deal with mapping traffic of different priorities to different SAs, without the need to define additional traffic selectors. That's why it has not been seen as necessary to create traffic selectors for this purpose. My feeling is that the selectors cannot express the case where specific traffic is to be encrypted/authenticated and others are not though. For example, if EF and AF31 are to be encrypted but other data is to travel clear. Do you think this is sufficiently covered by the current definitions? This seems more like your example with regard to protocol numbers. The protocol number example refers to the fact that we cannot express protocol number ranges in IKE, and that caused us to remove support for this feature from IPsec. IO agree with Tero that, going forward, we should require support for ranges of values for ALL new TS values that we define. If you are asking whether IPsec supports a policy where the basis for protecting traffic is exclusively a DSCP, the answer is no. It also is not clear that the ability to do so is a real requirement. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IV in ESP packets for DES and 3DES methods
At 9:34 PM +0530 5/12/09, Murthy N Srinivas-B22237 wrote: Is there a new draft/rfc posted with the change incorporated? -ns murthy DES is deprecated, so I would not expect a revised RFC on that. AES is strongly preferred over 3DES, so there is little incentive to rev that doc, although it makes more sense than for DES. Steve___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Reopening issue #12
At 2:18 PM +0300 4/29/09, Tero Kivinen wrote: ... In most case I would not expect Bob to create the old SA that way at all, as it would require it to combine two SPD rules together when accepting such entry. As the SPD entries are ordered list that would mean it was combining two entries which had different locations in the list, and I am not sure if combining two SPD entries when creating SA is actually allowed by the RFC4301. 4301 does not have any notion of combining SPD entries. As you note, the SPD is ordered, so whichever SPD entry matches and is encountered first is used. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification
Prabhat, With regard to your first observation, I'll note that your argument appears to be based on particular implementation choices. We don't generally consider changes to standards based on such choices, unless a lot of vendors indicate that there are no viable implementation options consistent with the standard. With regard to your second observation, the text I cited from 4301 clearly identified IPsec (not IKE) SAs as the way to accommodate QoS-induced reordering. The 64-packet receive window is a MINIMUM value. So a receiver is always free to make the window bigger. The impact of this is minimal for software implementations, but might be an issue in hardware, depending on how the window is implemented. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
