Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Grewal, Ken writes: The 'bait and switch' attack where a connection uses ESP-NULL and then at a later stage uses ESP-Encrypted may also be possible unintentionally. E.g. Connection to a server (cluster / farm) to gain access to a 'normal' service uses ESP-NULL and then at a later stage, where the previous connection was torn down and a new one built, the connection is obtaining some sensitive data and is now using ESP-Encrypted. On the outside, the connection attributes look the same (same server IP, same client IP (but may be different client due to NAT), same SPI - SPIs can be reused for new connections to preserve fast lookups algorithms at recipients), but underneath the connection is to access a different resource (may be using a different port or service above the IP layer). If the intermediate device has a cached rule (based on the previous connection) indicating the traffic is clear, it will lead to falsely inferring the contents of the payload and undesirable results. This was covered in the draft section 7, where it said that if deep inspection engine suddenly starts getting lots of garbage then it should rerun the heuristics. I agree with Yoav that this attack may also be possible intentionally between two colluding parties, where the policy indicates all traffic is ESP-NULL. It is much easier to use ESP-NULL wrapped TLS, or SSH in those cases. If both ends want to use encryption then the middle boxes cannot really prevent it very easily. If TLS and SSH and blocked then use IP(sec) over DNS, or IP(sec) over HTTP, and if even those fail then use IP(sec) over mail :-) -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Grewal, Ken writes: [Ken] This may be feasible for stateful devices, but does not work for stateless devices (QOS/Statistics/auditing functions). Even in stateful devices, it requires coupling between observation on flows and the associated heuristics cache engine, which creates an additional overhead. As the draft says this is mostly meant for stateful devices, and that has been the main goal for the document. The charter says: A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system ... I.e. the main goal was set to be on the devices doing deeper inspection i.e. firewalls and intrusion detection systems. At least my conclusion on the list when we discussed on the usage cases were for that kind of stateful devices. Are QOS and auditing devices really stateless? I would expect QOS devices to have all kind of reservation systems and so on and for those I would expect them to be keeping state? For the auditing I have been using I have usually enabled auditing of new connections, not all packets, thus all my auditing systems I have set up have been keeping state. What kind of usage is completely stateless auditing devices used for your example of 10Gbps links? Statistics devices could even be stateless, but is that really something we should aim for? I.e. to wait for 5-10 years before we can use our stateless statistics devices, compared to use stateful statistics devices for doing the thing this or next year. [Ken] These require timestamps (or other ordering / metric based approaches) and monitoring to ensure the cache is up to date. Stateful devices do already have all that. Furthermore, it may also provide opportunities for adversaries to use periodic replays to provide cache thrash and associated overhead in re-executing heuristics engines. As far as I have understood we are still talking about the inside one enterprice network, not internet as whole. If they do have untrusted users inside (i.e. attackers), they should enable encryption, thus all this is not really a point. As ESP-NULL does not offer confidentiality it can only be used in trusted environments, where the denial-of-service attacks against the device in the middle should not be big problem. I am not convinced that SW based solutions will scale 10Gbps solutions, let alone future 40/100Gbps bandwidth requirements, especially at these network 'choke' points, so a HW orientated solution may be desirable...which brings us back to cost/complexity... Limits for software based heuristics are not really related to the line speed, but number of new IPsec connections per second going through the device. The line speed do affect the HW based flow cache lookup (i.e. the appendix A.1 fastpath part of the processing), but that is doable even at 10Gbps speed, as it basically does same thing as normal stateful firewall rules (i.e. fetch flow information based on IP address pair, protocol and in this SPI number instead of port numbers). As here the heuristics is run on the same device which is running the deep inspection, they do already require methods of transferring that deep inspection state from one device to another, and moving the IPsec SPI cache state at the same time should not be a problem. [Ken] But again, this is additional work, which can be avoided if we have no state. Yes, it is additional data. You need to transfer 6 bytes (SPI + ICV len and IV len) per flow more when you transfer the whole deep inspection state from device to other (which might include whole TCP transmission window, which is around 64kB or so), so the increase of additional work is about 0.009% (actually it is normally even less, as TCP state is per TCP flow, and usually one IPsec flow has multiple TCP flows inside, but in this case I took the worst case scenario, where each IPsec flow have exactly one TCP flow inside). I do not really consider that to really be matter. (Doing deep inspection on TCP streams usually do require reconstructing TCP stream in fully including dropped and retransmitted packets. Otherwise there are attacks where you only inspect packet which never reaches the end node (attacker causes it to be dropped), and the retransmission packet is different than the first packet and if you let that pass to the end node, attacker managed to get uninspected packet through. Solution is that you either do the retransmissions from your internal data or you verify that retransmissions sent by the original node contains same data than original packet, both of them do require you keep the TCP transmission window data. This text is here just to explain that doing deep inspection (for IDS or IPS) on TCP stream is very costly operation and heuristics do have minimal cost compared to them.) Auditing / logging / sniffing / sampling are some examples of stateless devices that do require to peek in the packets. Probably lots more also, so look for others to provide
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
Grewal, Ken writes: Are QOS and auditing devices really stateless? I would expect QOS devices to have all kind of reservation systems and so on and for those I would expect them to be keeping state? [Ken] QoS may be applied on the need of the underlying service. E.g. A static rule that indicates that I place voice traffic in a priority queue over data traffic may be sufficient as a basic stateless rule. Note that you cannot do QoS without the co-operation of the sending IPsec site. The sending IPsec node needs to put packets getting separate QoS handling to separate SAs as otherwise the receiving IPsec node will drop packets if they get out of the replay window. Because of this there is no need to inspect the content of the ESP packet, QoS must be done based on the IPsec SA, i.e. IP-addresses and SPI number. So for QoS there is no need to inspect the data inside the ESP-NULL packet, as you cannot give different handling to different packets, as if you do so, then those ESP-NULL packets getting slower path might get dropped by the receiving IPsec node, as those packets getting faster path have already moved replay window so that those slower packets do not fit in to it anymore. [Ken] We have been through the deployment timeframe arguments before and it looks like we are going in circles here. It is speculative to say how long one solution will take to be adopted instead of another. This depends on a number of factors - e.g. some network appliance vendors have indicated that they will not employ heuristics in their network devices due the cost / complexity, but prefer a more deterministic approach, whereas others may be more willing to add this support and charge a premium for the appliances. My guess is that regardless what we do, at least some middle box vendors will implement heuristics in their high-end boxes, and after one vendor supports it, others need to support it too to be able to offer similar features than their competitors do. After a while even more low-end devices will support it and soon most middle boxes do support it. After that the requirements for supporting WESP will drop, as middle-boxes work without it, so general support for it will stay even lower. But that is just my guess... [Ken] Why is DoS not a big problem, especially if we generate a new DoS opportunity on a new 'cache' in the network device? DoS opportunities is a problem, but I do not think SPI cache will create that much new opportunities. I.e. I claim that the SPI cache can be implemented in such way that it does not offer any major DoS opportunity. BTW, insider threats are on the rise according to various public reports, so should not be discounted. This is one of the motivations of employing security, even within the Enterprise. Yes, but I do not really think people are going to solve those using ESP-NULL. I think they must move to encrypted ESP to provide confidentiality also, and that makes the need for ESP-NULL visibility even less. For example most of the insider information (insider trading, leaking trade secrets, espionage) problems cannot be solved by using ESP-NULL. [Ken] Perhaps there is a migration path consideration, where heuristics can offer interim benefits until a more deterministic solution is adopted. Adoption of either / both / neither will be ultimately based on numerous factors, including value, customer demand, etc. This I agree and I have even tried to bring this up in my draft (see last paragraph in the introduction section). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Question on RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying
Keith Welter writes: RFC 4718 section 5.11.8. Collisions with IKE_SA Rekeying says: The case where CHILD_SAs are being closed is even worse. Our recommendation is that if a host receives a request to rekey the IKE_SA when it has CHILD_SAs in half-closed state (currently being closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host receives a request to close a CHILD_SA after it has started rekeying the IKE_SA, it should reply with an empty Informational response. This ensures that at least the other peer will eventually notice that the CHILD_SA is still in half-closed state and will start a new IKE_SA from scratch. Say that host A sends the response with NO_PROPOSAL_CHOSEN and host B receives it. What should host B do next? Host B was attempting to rekey the IKE SA and needs to retry that operation. Is it acceptable for host B to retransmit the CCSA request with the same message ID even though it has received a response? If B retransmits the CCSA request with same message ID, then host A will retransmit its NO_PROPOSAL_CHOSEN reply, so there is no point of retransmitting old CCSA request with same message ID. If IKE SA is in half-closed state and B does not know that yet, then it means that A has already sent out delete notification for the IKE SA, and then B sent CCSA before receiving that delete notification, and that was the reason A replied with NO_PROPOSAL_CHOSEN. So B does not really need to do anything, it should receive delete notification very soon. It can install timer (for example 60 seconds or so), and retry the operation after that (or it can wait until the hard lifetime is reached, and delete the old child SA then and then next packet will trigger new child sa creation). If it still fails, it knows there is something wrong with the syncronization of the both ends, and in that case it should delete the IKE SA and start from the scratch. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
pasi.ero...@nokia.com writes: I have one somewhat substantial concern with the document: it needs to be much clearer about what information is updated by the received REDIRECT messages, and what is not. Never really thought that issue. I myself assumed that both GWs are identical, i.e. they return same ID, and use same authentication data (i.e. if PSK, both use same PSK, if certs, both authenticate against same trust anchor and use same identity in cert, but not necessarely same private key). One possible answer would be that REDIRECT is interpreted just as data received from DNS, so all the gateways (redirecting among each other) would send same IDr value. I think this is the easiest way to make sure redirect is secure. - Section 5: I don't think treating REDIRECT+sufficient time period as implicit delete is a good idea. RFC 4306 requires sending delete payloads whenever possible, and if the VPN GW wants to close the IKE_SA, it could include the Delete payload in the same message as the REDIRECT notification... I think it said that it can delete it without client sending any packets, but that delete is not implicit, it is explicit, and gateway will then send delete payload to delete the IKE SA. The sufficient time is used when the client has been talking to the gateway for longer already, and has multiple IPsec SAs up and in use. Then when gateway decides to redirect client somewhere else it sends N(REDIRECT) and client acks that. After that client starts recreating existing IKE SA and Child SAs with the new gateway, and after finishing that the client will delete the IKE SA with delete payload. If server runs out of resources before that it can send delete payload even before client finishes its redirection process but as that causes disruption of the flow of packets (if client didn't have time to set up new Child SAs), server should allow some time for that. I agree that the text could be written in more clear way, i.e. explictly say that the delete the securition association does mean the normal IKEv2 way, i.e. sending delete payload. - Section 7: I'm a bit skeptical if this actually works. The rest of the document certainly does not describe how it would work, and in many places, assumes the client-gateway case (e.g. Section 6.1 says REDIRECT_SUPPORTED is only sent in initial IKE_SA_INIT request, so the responder can't actually tell the initiator it supports this feature, etc.) Also, the what is actually updated by REDIRECT and what is not may get even more complex in peer-to-peer case. My personal preference would be to restrict the scope to client-gateway unless someone really has the energy needed to specify how the peer-to-peer case works in detail. Also the current text says the responder MUST NOT respond to re-direct message from the initiator, if it has already decided to re-direct the initiator. and that is impossible with IKEv2. If node receives some request, it must reply with response, it cannot leave that response out, as if he does that then the IKE SA will be teared down when the other end times out the exchange. I think the original idea was that even when we talk about VPN client and gateway, this could be used as building block for other things too, and even this document uses terms like VPN client and VPN gateway, this could also be used even when the IKE peers are not VPN client/gateway. This includes cases where for example SIP/MobileIP client connects to SIP/MobileIP server using IPsec. I do not think this can be used as generic gateway to gateway redirection mechinism (MOBIKE can be used for that too). I.e. I would simply change the section 7. to contain: -- 7. Use of the Redirect Mechanism between IKEv2 Peers The Re-direct mechanism described in this document is mainly intended for use in client-gateway scenarios. However, the mechanism can also be used between any two IKEv2 peers, but this protocol is asymmetric, meaning that only the responder can redirect initiator to some other server. -- And leave everything else out, including changing the protocol so it can be used in both directions. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
Vijay Devarapalli writes: The draft currently requires the client to delete the SA once it receives the REDIRECT message from the gateway. I do not want the gateway to delete the SA right away. The gateway should allow the client to setup the necessary security associations with the new gateway before deleting the SA with the existing gateway, if that is what the client wants to do. The current text is to handle the case where for some reason the gateway does not receive the DELETE payload from the client. Note that this shouldn't happen normally. The gateway garbage collects the SA after a certain time period. I don't think the gateway needs to send a DELETE payload at this point. I disagree with that. If gateway decides to delete the IKE SA, it needs to send DELETE payload in that case. The only case where you do not send DELETE payload is when you delete the IKE SA because some exchange over the IKE SA timed out (i.e. other end didn't respond). In that timeout case there is no point of sending DELETE payload, as most likely that will not reach the other end any better than the original exchange, thus it will also timeout. In this redirect case the client might just be slow, or it might be that the gateway where client was redirected to does not respond, and client does not delete the old IKE SA before it gets new one up and running. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DoS Attack Possibility?
Yaron Sheffer writes: I'm not sure in what way this is worse than other potential attacks at this stage, such as sending back an unprotected notification saying that the offered group is unacceptable. If attacker sends notification back saying the offered group is unacceptable, it will also indicate new group (which must be part of initiators offer) in the notification payload, and then initiator tries again with that. If that new group is acceptable by the server too, then they create IKE_SA with that group, and as it was acceptable with both it is ok. It might not be the strongest group they supported, but the group is one of the acceptable groups for both ends. For other unauthenticated error emssages the initiator should ignore them, and keep trying until the exchange times out. This case is different though if the attacker redirects into a legitimate gateway, because things look normal, traffic gets through, but an innocent gateway may get overwhelmed if all other equivalent gateways are redirected to it. Yes. It may be simpler to echo the nonce Ni back to the initiator as part of the Redirect payload. This would introduce no new state. That would also be good solution, as the nonce is already defined to be random and large enough. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go?
Yaron Sheffer writes: From Appendix C: The specification does not say which messages can contain N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is not yet shown below. SF discussion: Paul said, wherever you wish. I agree on that. Logical places are: 1) In separate the INFORMATIONAL exchange immediately after IKE_AUTH or IKE SA rekey CREATE_CHILD_SA to set the initial window. 2) In the IKE_AUTH or in the IKE SA rekey CREATE_CHILD_SA to set initial window. I do not think there is any need to prefer either one of those two locations. Usually the window size is something that is set once after the IKE SA is created (and after it is rekeyed), and it will never be changed after that. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IKEv2: Question on INFORMATIONAL exchange response motivation
Matthew Cini Sarreo writes: I would like to ask the reason behind this. As live peer detection is done by sending an empty INFORMATIONAL exchange (Encrypted Payload with no payloads), wouldn't it better to have a response be constructed in such a way so that the requesting peer can explicitly know that this INFORMATIONAL exchange is a confirmation of the request sent? This is already done. Each request has unique message-id, and each response will have same message-id, so other end can always tie correct request and responses togehter. This way, the requester would have to parse the response, and not decrypt the message, discover that there is no payload in the Encrypted Payload, check if the message is marked as a response and assume it is a confirmation of a request. Would a message ID be used to check the corresponding request? It is. In the IKEv2 the exchanges are always request-reply pairs, which are identified by the message-id (which is incremented by 1 for each exchange). There is separate request-reply pairs in both directions (separated by the Initiator flag). And if then the message ID on the responder (to the INFORMATIONAL exchange) somehow got messed up and does not match what the requester is expecting? If the message id got messed up, the recipient of that message will throw that message away immediately as it does not fit the message id window, and it will then wait for the other end to retransmit the message with correct message id. If the other end has bug causing the message ids to be messed up in all responses, then the recipient will time out the exchange, and tear down the whole IKEv2 SA, as the other end did not reply to its messages. Note, that IKEv1 handled message id, and exchanges completely differently waythan what IKEv2 does, so do not assume anything is staying same from the IKEv1 to IKEv2. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Issue #28: UDP encapsulation and transport mode ESP
Ticket #28 (new defect) Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP Opened 7 months ago Reported by: kivi...@iki.fi Owned by: paul.hoff...@vpnc.org Component:draft-ietf-ipsecme-ikev2bis o Implementations MUST process received UDP-encapsulated ESP packets even when no NAT was detected. o The original source and destination IP address required for the transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) are obtained from the Traffic Selectors associated with the exchange. In the case of NAT traversal, the Traffic Selectors MUST contain exactly one IP address, which is then used as the original IP address. Getting original source and destination IP address from the traffic selectors do not really work currently. Especially when combined with the selectors from the packet and when responder is behind nat or similar problems. Paul: Not done. Specify replacement text and discuss on the mailing list. I wrote a longer description of the whole transport mode NAT-T problem, and also added some text which could be used as parts of the solution to be added to the IKEv2bis. The problem is that currently there is no way of doing transport mode NAT-transport without violating at least one of the following MUSTs in the IKEv2bis document: ikev2bis-02: section 2.9: o If the responder's policy allows it to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the initiator's first choices. and the generic requirement from the same section which in short says responder MUST narrow the traffic selectors to be a subset of initiators traffic selectors (this is said in quite complicated way in IKEv2bis). ikev2bis-02: section 2.23: ... In the case of NAT traversal, the Traffic Selectors MUST contain exactly one IP address, which is then used as the original IP address. RFC4301: section 5.2: ... IPsec MUST perform the following steps: ... 4. Apply AH or ESP processing as specified, using the SAD entry selected in step 3a above. Then match the packet against the inbound selectors identified by the SAD entry to verify that the received packet is appropriate for the SA via which it was received. The problem with transport mode NAT-traversal and narrowing and SAD entry checks is that two end nodes talking with transport mode cannot work if they have same traffic selectors in both ends. This is because the packet will look like having different IP-addresses depending which end is seeing it, thus there is no way that both parties could agree on any single addresses that would work for both ends. In my following longer text I explain the solution how the transport mode NAT traversal can be made to work. This will be protocol change, but on the other hand it cannot break any existing complient implementations as there was no way to do this before (even when the RFC claimed so): -- Transport mode NAT Traversal When transport mode is used with NAT Traversal that requires special handling of the traffic selectors used in the IKEv2. The complete scenario is like this: +--++--++--+ +--+ |Client| IP1| NAT | IPN1 IPN2 | NAT | IP2 |Server| |node |--| A |--| B |---| | +--++--++--+ +--+ In this scenario there is two address translating NATs NAT A and NAT B. NAT A is dynamic NAT that maps the clients source address IP1 to IPN1. NAT B is static NAT configured so that connections coming to IPN2 address are mapped to the gateways adddress IP2, i.e IPN2 destination address is mapped to IP2. This allows client to connect server by connecting to the IPN2. NAT B does not necessarely need to be static NAT, but client needs to know how to connect to the server, and it can only do that if it somehow knows the outer address of the NAT B, i.e. the IPN2 address. If NAT B is static NAT, then this can be configured to the client's configuration. Other options would be find it using some other protocol (like DNS), but those are outside of scope of this document. As other scenarios are just simplications of this complex case (i.e. where you can just remove NAT A or NAT B), we do not need to consider them separately. In this scenario both client and server are configured to use transport mode for the traffic originating from the client node and destinationed to the server. When client starts creating IKEv2 SA and Child SA for sending traffic to the server, it has triggering packet with source IP address of IP1, and destination IP address of IPN2. Its PAD and SPD needs to have configuration matching those addresses (or wildcard entries covering them). As this
Re: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying
Yoav Nir writes: The traffic selectors in the REKEY exchange are not currently specified. If were designing IKEv2 from scratch, I would be in favor of removing traffic selectors altogether from REKEY exchanges - I don't think it should be called a rekey if you get a totally different SA. This does raise the question (that has been asked before) of why do we really need REKEY_SA exchanges as opposed to regular exchanges. I think the reason for REKEY_SA is to know which SA is being replaced with the one we are creating now. I.e. from where we can move statistics to, and from which SA we should move traffic to this new SA (even before the old SA expires, but after we know other end has also installed the SAs, i.e. after responder sees traffic in the new incoming SA). For example in our implementation rekeyed SA shares same internal SA slot in the engine, i.e. we have one SA slot having two associated crypto contextes and SPIs, and only one of them are in active use. I.e. old one is in use until traffic moves to new one and then later the old ones are removed (but might still be used to decrypt traffic as there might be out of order packets coming in) etc. I.e. it makes implementations easier and more efficient when you know which SA is going to be replaced with the rekey. In IKEv1 you usually tried to do same by inspecting the selectors and tried to guess which one was the old SA being replaced. This is not possible in IKEv2, as it is normal to have multiple overlapping Child SAs with same selectors for different QoS classes. As it is, I think the initiator of the rekey (not necessarily the same as the initiator of the old SA) should keep the selectors in the old SA, and the responder should either accept of reject, but I don't think we need to capitalize the SHOULD. Responder should do normal narrowing of the selectors, it should not ever reject the selectors. I mean if the selectors initiator offered is superset of the old selectors of the SA, they cannot be against the policy of the responder, thus the responder should either accept wider ones or narrow it down to subset of the offered selectors as normally. In some implementations, the REKEY is generated because of traffic passing the IPsec stack when little time remains before the child SA expiration. It may be much more convenient to rekey with the narrowed selectors rather than locating an SPD entry which is a superset of the SPD cache entry that matches this SA. I agree that should be allowed, but in most cases the implementations do have pointers back to the original SPD entry anyways, and in that case they SHOULD use the original selectors from the SPD entry if they are readily available. I think the rekey initiator SHOULD propose any superset of the current selectors, which can be the current selectors, or anything that matches its policy. Yes. I don't think we should recommend doing one or the other. I would prefer to say SHOULD for the selectors from the original SPD entry, but I can accept also the wording saying that either one can be used. We can and should, however, require the responder to not expect the traffic selectors in a rekey-SA to exactly match those of the current SA. Yes, this is something we should at least require (even as MUST). Now that I think more of this I think the initiators proposed selectors MUST always be same or superset of the old SAs selectors. They cannot be narrower than what was used before, as that would normally mean that the policy of the inititor was changed so that old SA is no longer valid with the new policy, which means it should be deleted and new SA created (and this is so rare case, that we do not need to optimize performance for this). Earlier I though we could use rekey in that case too, but I think it is better to say it MUST be same or superset of the currently used selectors. The responder should narrow the offered proposal down to either superset of the current used selectors, or same as currently used selectors. Again it really cannot narrow it down to anything smaller than currently used, as in that it case the current SA is against its policy, and should be deleted. If we go with those rules (i.e. SA can be rekeyed only to superset of the current SA, never to subset), then we actually do NOT need the specific selectors from the packet, as we always know that the subset where we need to narrow it down to, is the one containing the old SAs selectors. So perhaps we should change the resolution to issue #12 (and #11): -- - When initiator proposes traffic selectors when rekeying Child SA, the proposed traffic selectors SHOULD be either superset of the traffic selectors used in the Child SA (i.e. come from the currently active (decorrelated) policy), or same as the traffic selectors currently used. - When responder narrows traffic selectors down when rekeying Child
[IPsec] IKEv2: Possibility of storing configuration (Cryptographic Suite) for a certain Peer
Matthew Cini Sarreo writes: In such a scenario, it might be required to have different D-H groups for different peers. Due to the ID payload being inexistant at this time, is there a way (that is allowed) to identify a peer during IKE_SA_INIT (for example, based on an IP address that has been stored in a configuration file that is known to always be for a certain peer), or are such identification methods (IP-based during IKE_SA_INIT just by checking the IP address source in the IP header of an IKE_SA_INIT message) prohibited? Does not really sound like reasonable real world use case, and I would firstly try to convince people that hosts should never ever allow anybody to use too weak cryptographic suites, and if you only allow strong enough ones, then it does not matter which one of those strong enough ones is used. But to your question. Yes, you can select the IKE SA cryptographic algorithms based on the IP address of the request. Actually you can use whatever means you can, including the phase of the moon, but usually only useful thing you have is the IP address of the other end. This of course has the problem that if the other does not have fixed IP-address, then you might have problems (or you end up problems if you have multiple hosts having dynamic IP-addresses and their required policies do not match). If there really is strong requirement that specific host MUST use some cryptographic suite that is not allowed for another host and both of them use dynamic IP-addresses, you can always do so that you do IKE_SA_INIT exchange and then when you see IKE_AUTH message, you know the identity, and then you can verify that your IKE_SA_INIT parameters were correct, and if so continue. If your IKE_SA_INIT parameters were wrong, then you simply store information to your local cache saying that host from this IP address, should use these IKE_SA_INIT parameters next time, and return some fatal error message to IKE_AUTH. When the initiator then retries and sends next IKE_SA_INIT, you can then check your cache, and see that for this IP-address you should use these parameters, and use those and then continue. Then in the IKE_AUTH you again verify that your parameters were correct and continue. P.S this point comes from the IKEv2 RFC, section 2.6 (IKE SA SPIs and Cookies), par. 2 which states: Incoming IKE packets are mapped to an IKE SA only using the packet's SPI, not using (for example) the source IP address of the packet. But the identification for fixed configuration purposes would be before this, as the packet would not be mapped to an SA, but a configuration for the SA resulting my that message would be loaded from configuration. That text means that the source address of the UDP IKE packet does not matter when finding the IKE SA state. When doing lookup to PAD you can use the remote IP address of the peer (RFC 4301, PAD). If PAD contains restrictions that these PAD entries must have remote peer location of IP address XXX, then it is best to first concentrate your searching of the suitable PAD entry for new connection to those PAD entries having matching IP-address. If you only find one PAD entry then you can assume that this will be the one that will be used, and then later in the IKE_AUTH verify that your guess was correct by doing PAD/SPD lookup again using the full information available and check that you get same PAD/SPD entry back. For example in our implementation the configuration can specify that this IPsec connection must have local and/or remote IP as specified in the configuration, and then when new connection comes in we first search entry matching both to the remote and local IP, and if such is found, we guess that is the correct one. If that is not found, we search one having correct remote IP, and if that is not found then we search for having correct local IP, and otherwise use defaults. Later we then verify that the final selected IPsec connection is same than what we guessed earlier (or at least has same parameters for IKE SA). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Issue #98: 1 or two round trips for resumption
Paul Hoffman writes: Greetings again. Tracker issue #98 is the same as the message that Pasi sent to the mailing list last month; see http://www.ietf.org/mail-archive/web/ipsec/current/msg04050.html. There is disagreement among the authors of the session resumption draft how to deal with this issue. One proposal is to add text similar to Pasi's to the document in order to let implementers understand all the things that they might need to do to prevent damage from a replay attack. If this is the method chosen, it should probably be as a section in the main body of the document, not as a security consideration because the issues are more operational than security. A different proposal is to get rid of the one-round-trip mode and have the protocol always take two round trips. This prevents the attack that Pasi brings up, at a higher cost for the clients and server. If you have a preference between these two proposal, please state it now. This comes back to again to what use the resumption is aimed for (I tried to ask this in meeting, and it seems nobody knows, so it makes it impossible to think whether some optimization in the protocol is needed or not). Anyways, I would prefer to have safer protocol even if it would be one more round trip. It would also make protocol simplier, as we would not need to have separate optional cookie exchange version. So I would vote for 2 round trip version of the protocol. BTW the ticket #98 has wrong component (draft-ietf-ipsecme-ikev2bis), it should have ikev2-resumption instead. Also the ticket component names are not consistent, there is both ikev2bis and draft-ietf-ipsecme-ikev2bis and only the last one of them is used, but all other components ignore the draft-ietf-ipsecme part... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKEv2: Moving Child SA traffic from an SA to a new SA when rekeying
J. Sun writes: Matthew, It has to be Case #2. No where in the CREATE_CHILD_SA - IKE_SA Rekey exchange do you update to the other endpoint the new CHILD_SA SPIs - without exchanging the CHILD_SA SPIs, you'll most definitely run into interoperability issues, namely you'll start black holing traffic. As a result, it would be what you consider a copy. However, you shouldn't really think about it in that way. Depending on implementation, generally speaking - CHILD_SAs existing in a SAD would simply have an object that essentially references the parenting IKE_SA. After the successful IKE_SA Rekey, the CHILD_SA simply would update this object to simply point to its new parent, the rekeyed IKE_SA. But to qualify, it all really depends on implementation. Actually it is more like of move, not copy, i.e. just like you explain in the end. There is no two copies of the same Child SA, there is only one, and that one has exactly one parent SA, i.e. either the old or new IKE SA, depending on where we are at the IKE SA rekey process. I.e. it is mostly: IKE SA A - Expiring IKE SA B - Rekeyed No Child SAs Moved Child SA from A all Childs are moved to new IKE SA SPI (incoming) 0x12345678 Protocol AH Same cryptographic suite as A's Child SA (moved) I.e. after that you MUST send all management traffic relating the Child SA using the new IKE SA B, you cannot use IKE SA A anymore for delete notifications or similar relating to the Child SA which was moved. Note, also that in case of the simultaneous rekeys, you need to move the Child SAs to the winning IKE SA. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #63: Position of arbitrary notify payloads
Paul Hoffman writes: At 3:55 PM +0300 4/3/09, Tero Kivinen wrote: Btw, is there any reason why [V+] is not listed in the IKE_AUTH excghange with EAP in the intermediate EAP messages and final AUTH request from the initiator? We could add it, but I think that would surprise some implementers. Is it really needed? I do not think any of the [V+] payloads are really needed, as section 3.12 clearly says that A Vendor ID payload may be sent as part of any message.. My question was more of was this omission trying to say something. I.e. does that it is NOT listed in that those messages trying to say that those messages are not logical place for vendor ID payloads. (I actually only now noticed the text about most logical place). I would at least expect that vendor ID payloads could be also used in the last AUTH message from client to server, i.e. after the EAP authentication is finished. The server is already marked so that it can use [V+] in its last response. I.e. for server the logical places are first and last response, but for client the only logical place listed is the first request, last request was ommitted. I agree that during the EAP exchanges itself (the ones repeted 1..N times) the vendor ID payloads might not be that logical (as most likely all extensions during that is done inside the EAP messages itself, not as IKEv2 vendor ID payloads). But I think the last request is bit different case, and I myself consider that as one that could be logical place for vendor ID payload for some extension. Currently it is bit funny that only places where vendor ID payloads are not supposed to be most logical are: - IKE_AUTH exchange with EAP: EAP payload request - IKE_AUTH exchange with EAP: EAP payload response - IKE_AUTH exchange with EAP: last request from client - CREATE_CHILD_SA for Child SA: generic error case response - INFORMATIONAL exchange: request - INFORMATIONAL exchange: response It is not very most logical locations if it is listed in 71% of cases (i.e. 15 packets out of 21). I think the most logical place currently to send those vendor ID payloads is only during IKE_SA_INIT exchange request, and IKE_SA_INIT exchange normal response. We currently do not have any extensions which would send them in any other locations, and I have not seen any implementations sending them in any other locations yet. If you want to pick the most logical place, then I would only put it on those exchanges, and say that they can still be part of any other message too if needed. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Narayanan, Vidya writes: Hi Yaron, We are going back to revisiting consensus here and re-explaining the use cases and I'd certainly like to keep this to as minimum a revisit as possible. The use cases go back to what has been documented in the problem statement we published a while back - draft-vidya-ipsec-failover-ps-02 - it is now expired, but, you should be still able to get to the draft. From the ipsecme charter: Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Thus failover from one gateway to another is outside the scope of this document. If I remember right most of the use cases in draft-vidya-ipsec-failover-ps-02.txt was specifically failover, not resumption use cases. As a key point, I'll note that the situation where resumption is used here is a handoff case for a particular client and does not involve all clients connecting at once, where DH could be a problem. And, in these cases, there is no user interaction involved - the mobile devices are doing everything they can to make handoffs seamless and work with no user or even application involvement. If you are only worried about the case of simultaneous reconnection of thousands of nodes, you can feel free to always use the 2-RT method in your gateway implementation - I am pointing out that it is not the universally applicable use case. From the abstract of the resumption document: To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. So at least it was seen as important use case, and is thats why included in the abstract (and the ipsecme charter text). And, in most cellular deployments, IPsec is used for untrusted access networks (e.g., WLAN), while the DHCP servers and AAA servers are accessible from other access networks as well. And, a handoff from cellular to WLAN needs to be seamless - you can envision an IPsec SA being set up all the time, but only resumed and actively used after you handoff to WLAN. Hmm.. This is again something completely different what I tought for what the resumption protocol is supposed for. For example for this use it would be useful to have have some way to force deletion of the state from the server, i.e. say that this IKE SA is now going to go to sleep, so you can remove the state, and there is no need to do dead peer detection on it. The current protocol do not have anything like that, and if you delete IKE SA you also delete the ticket, so that mechanism cannot be used for that. I still do not think making the 1 RT protocol to 2 RT protocol in that case would really cause any noticeable effect to the actual handover. Especially as you still most likely have the cellular network there to be used, while you are doing DHCP + IKE_SESSION_RESUME etc on the WLAN, thus only thing that is affected is that traffic moves 100ms later from cellular to WLAN. On the other hand security problems are big issue, as you most likely try to IKE_SESSION_RESUME exchange over any WLAN you happen to see, thus you effectively broadcast your tickets to attackers at will, so attackers can simply take those tickets and sent them to server and get your session resumed, but not forward any other traffic. Also any firewall allowing port 500 packets out but not in, will cause similar effect, as you will not get reply back, but server will consume your ticket. That case also brings out completely new issue which has not been discussed before, i.e. whether the IKE_SESSION_RESUME must come from the same IP-address than what was used before for the IKE SA, i.e. can the IP-addresses change during the IKE_SESSION_RESUME. If that is allowed, then what about NATs, i.e. is it allowed that even when there was no NAT between hosts before, there is new NAT found during the IKE_SESSION_RESUME? Those are not covered by the current document, and at least something MUST be said about those issues. After this example use scenario, I am even more convinced that 2 RT protocol is better and needed, especially if we do allow IP-addresses change, and might need to do NAT-T detection on the IKE_SESSION_RESUME exchange too. Allowing IP-addresses change means that the network where the packets can come in, are different, meaning they might have misconfigured firewalls or similars there, and killing your resumption ticket by just trying to connect through broken firewall is bad idea. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Some comments to draft-ietf-ipsecme-ikev2-resumption-02.txt
During the other discussion I read the draft-ietf-ipsecme-ikev2-resumption-02 through and here are some more generic comments to it: --- In Section 3 we present 2 use cases, and then after figure 1 start talking about In this scenario... and I think that refers to first use scenario described in second paragraph of section 3, not the second use scenario described just above that in third paragraph. It would be useful to change the In this scenario... to explicitly mention which one of those two scenarios it is talking about. As far as I can understand the second use scenario is not talked in detail anywhere, i.e. only reference to it is 3rd paragraph of section 3. --- In Section 4.3, it might be good idea to clarify that reuse of the ticket is when you successfully use it, not just when you try to use the ticket, i.e. client can try to send IKE_SESSION_RESUME exchanges every now and then to the server and ticket is only really used when it gets reply from server. --- Also the text The client SHOULD NOT use this exchange type unless it knows that the gateway supports it. is bit pointless, as at least from my understanding is that when server presents ticket to client it indicates the gateway supports this, thus if client has ticket it can use this exchange. If client does not have ticket it cannot use this exchange anyways, as ticket is required for this exchange. --- I would also like to rename TICKET_OPAQUE' to something else, perhaps use TICKET_REQUEST, TICKET_REPLY, TICKET_PRESENT or similar names instead (main reason for that is that I like to define those names to actual defines in C-code or similar, and then I need to rename TICKET_OPAQUE' to something like TICKET_OPAUQE_DOT or so). --- Why is the IDr there? I know I asked this before, but I do not sill understand why it is there. Gateway cannot have multiple identities having different session resumption caches, as IDr is encrypted, meaning gateway needs to parse presented ticket first, and that ticket must have information of which identity the connection is connecting so it can select suitable session resumption cache. Section 4.7 says that IDr is obtained from the new exchange, so that seems to indicate it is used, but IDi, and IDr is used to check PAD, which is then used to check SPD entries etc, and I do not think we want to redo policy lookups at this point. Also in normal IKE we do not directly use the IDr that client sent, we use that as hint when selecting one of the our own allowed IDr for this connection. The text in 4.7 would indicate that we directly use the IDr client sent us as is. The IDi was already removed, but is there any reason to keep the IDr there? Even if it is kept, the section 4.7 will most likely need text saying that IDr is selected as normally, i.e. the IDr from exchange is only used as hint. Also note that the gateway does not tell back to the client which IDr it finally decided to use... --- Also still in section 4.3 when talking about the response packet, the text about what is filled in the SPI fields is wrong. For the response packet the SPIi value is of course copied from the request, and SPIr is filled with random number allocated by the responder (gateway). --- Section 4.3 also needs to clarify what is going to be message IDs of the exchanges. Especially with the 2 RT version there is two options, i.e. it could be that the cookie exchange has message ID of 0, and actual exchange has message ID of 1. When the cookie exchange was optional, then it was quite clear that all of the IKE_SESSION_RESUME exchange messages have message ID of 0. --- In section 4.7 it says The sequence numbers are reset to 0.. I was trying to search that earlier, but didn't find it because I searched using Message ID text... Unfortunately IKEv2 document uses both sequence number and Messsage ID. It uses Message ID bit more, and good thing with Message ID term is that it cannot be confused with the sequence numbers of the ESP/AH packets. I would recommend changing that text to The Message ID counters are reset to 0.. --- Section 5.2 says that The lifetime of the ticket carried in the N(TICKET_OPAQUE) notification SHOULD be the minimum of the IKE SA lifetime and its re-authentication time, and also that The gateway SHOULD set the expiration date for the ticket to a larger value than the lifetime of the IKE SA. That is bit confusing, and at first looks like it is conflicting. I assume it was supposed to say that the lifetime sent in the ticket is actually different that what is enforced by the server, i.e. server should allow ticket also after the life time sent to client? Hmm.. on the other hand client MUST NOT present ticket which is expired... Actually I am not sure what the current text is trying to say. I.e. is the ticket lifetime supposed to be same or smaller than IKE SA lifetime, or larger? (On the other hand I still think the whole lifetime concept should be removed from this document, but lets not go there here
[IPsec] Multiple payloads of same type
Kalyani Garigipati (kagarigi) writes: Please validate if the following is true. Apart form Notify, DELETE, Vendor ID, CERT, CERTREQ, PROPOSAL, TRANFORM, TSi and TSr all other payloads like SA1, SA2, IDi, IDr, KE, NONCE, DELETE, AUTH, CONFIG, ENCRYPT should not be sent as multiple payloads. Encrypt MUST be last packet, thus that also limits that there can be only one of such payloads in packet. For all others there is no explicit restriction that they cannot appear multiple times, but on the other hand the exchanges we now have do not ever put multiple SA, KE, IDi, IDr, AUTH, Ni/Nr (Nonce), TSi, TSr, or EAP payloads in the same packet. For CERT, CERTREQ, N (notify), D (delete), V (Vendor ID) it is clear that there CAN be multiple payloads of those types in same packet. For CP (configuration payload) it not clear whether there can be multiple or not, but I would expect most implementations expect to find only one, and will only use one. In future someone might make extensions which puts multiple CP payloads in same packet, but currently we do not have such. Like if we get packet as HDR, SA1, SA1, KE, N We should reject it ? Best would be to check first the exchange type, and check out that all mandatory payloads which are required for that are there. Also when parsing it should be quite ok to stop parsing immediately when you see for example 2nd encrypted payload, or 2nd SA payload (In IKEv1 we could have multiple SA payloads in one quick mode exchange, as there was option to create multiple IPsec SAs at once, but that is not allowed in IKEv2). After that parsing all optional payloads (notifies, vendor id payloads, etc). Then the question is whether there is any need to check if there is any extra payloads in the exchange, and if such is found what to do (lets say someone puts configuration payload as part of the IKE_SA_INIT instead of IKE_AUTH). For this there is no clear answer, if you want to be able to work with future extensions without breaking when seeing them, best might be just ignore them. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Lakshminath Dondeti writes: I still do not think making the 1 RT protocol to 2 RT protocol in that case would really cause any noticeable effect to the actual handover. How do you know this? Because 10ms-100ms is MUCH less than 10 seconds or so I usually see as DHCP delays on WLAN networks. And there is already way to do that in 1 RT protocol, i.e. MOBIKE. With MOBIKE you can recover the changing of the network or IP-address in 1 RT. Resumption should not really be used for that. Resumption means that something caused the IKEv2 SA in the client to removed, without telling that to the server, and thats why client decided to use resumption instead of just continuing using the IKEv2 SA it has up and running. If we take the network outage example from the charter, the duration of network outage is usually MUCH, MUCH longer than the 2 RTs required to reconnect to the server. I ask because, I would like to use those arguments to tell people who are experts in handovers that multiple RTs don't matter. Tell them to use correct protocol on correct places. If they want subsecond recovery from the handover from one network to another, they should use MOBIKE, and keep the IKEv2 SA up all the time (Altough even with MOBIKE it usually takes several seconds for the nodes to actually react that they have lost connectivity, and needs to start corrective actions, but if we assume subsecond recovery is required, then we can also assume the network can immediately tell when recovery actions are required). Even if this happens, the payoff for the attacker is very little since the legitimate parties can always establish another connection. No, he does not, as if he was trying to do handover from cellular to WLAN, he would simply continue using cellular in that point, but the accounting for example would be enabled for both (i.e. for servers point of view he is using WLAN and cellular simulatenously, from clients point of view he using only cellular). Again then when he finally gets WLAN which works, he suddenly have 3 RT protocol to use (trying resumption, failing that, and falling back to full IKE) with user authentication, and possibly even user interaction. The quality of experience would be bad because another session needs to be established when under attack, but at the cost the attacker has to pay, one might even say that this is not even a serious threat. Making the user to do user interaction by simply sniffing one packet from the air, and forwarding it to the right server is very cheap way to annoy people... For users point of view it does not even look he is under attack, he just sees that this crappy network again requires him to reauthenticate at random times. Note, that he does not blame the attacker's network, as he didn't detect anything there. The attack can have happened hours before, and then when he finally comes to the home WLAN network, or some other network which actually works, he sees that he needs to reauthenticate. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
Matthew Cini Sarreo writes: You still need the IDr and AUTH payloads in the reply. This is needed as INVALID_SYNTAX is authenticated and encrypted. INVALID_SYNTAX is fatal error meaning that other end didn't follow the protocol specification, and the IKE SA is going to be removed anyways, and there is not really point of putting AUTH payload there (it can be there, but there is no need). If the other end is not following protocol specification (i.e. is non-complient), there is not really point of trying to be nice. This is something that cannot be seen by normal customers ever, it should only be seen by the implementors when they are testing against broken implementations. So better just send error message back as it is easiest for your implementation (i.e. if it is easy to include AUTH etc to the error message, then do so, if not, then leave them out). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Lakshminath Dondeti writes: When did MOBIKE come into picture? What are you saying Tero, that IPsec session resumption is an alternative to MOBIKE and a slow one at that? Yes. Both solve the same problem that IKE SA recovers from the IP-address change, or switching from one network to another (i.e. from cellular to WLAN). I do not really see any fundamental reason why the IKE SA needs to be taken down when in cellular. I can see reasons why it might not be needed, but the IKE SA could still be kept up and running, and if done that way, then MOBIKE will offer solution how to move the IKE SA to the new network, and it will mostly do it in 1 RT. Annoy being the keyword. I am now more convinced that we are really making the protocol inefficient because some kid might try to annoy some people some time. To counter such potential annoyances which may not happen at any frequency that matters, we are going to sacrifice the user experience all the time? I am saying we are not sacrificing the user experience in any noticeable way even if we do 2 RT protocol. I expect that 99.999% users will never notice whether the 1 RT or 2 RT protocol was used if there is no attack. On the other hand, 100% users will notice the attacks if 1 RT protocol is used, and 0% of users will notice the attacks if 2 RT protocol is used. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Narayanan, Vidya writes: Somehow, we in the IETF think that we can make decisions for other standards bodies, especially ones that do real deployments. I don't know how we can say things like they should always use the IKE SA whether they need it or not - there can be several reasons not to use it when they don't need it, including how some VPN vendors may charge. It is impossible for IETF to think about those other standard bodies, as we do not know what they plan to do. I have several times tried to get people to explain me the use case for which this protocol has been aimed for, so I could think whether some specific attack or optimization is suitable or not, but as only reply I have received is, that it is outside the scope of this discussion, then there is really no point of blaming people for making decisions for other standard bodies. What else can we do? Nobody has still explained me why the 1 RT protocol is required for those other standard bodies, and why should the security of this protocol be weaker because of the requirements from those other unknown standard bodies. Also, mobility may need to be handled by MIP6 and we know that it doesn't co-exist with MOBIKE. That is news for me. One of the reasons MOBIKE was created was to allow it to be used as building block for Mobile IP. So why does not MIP6 and MOBIKE co-exits? We at least tried to make MOBIKE so it could be used by Mobile IP, and there were Mobile IP people taking part in the specification process back then. So what is the exact problem there? I am thinking it might not be worth of standardizing the resumption at all, if we for that again hear 3 years after we finished the work that it cannot be used because of some unspecified reason. I'm also further intrigued by this attack we are so passionately discussing - the motivation for the attacker here is to annoy other users? Almost all DoS attacks are only there to annoy the users. If someone uses DoS attack to bring some web server or dns-name server or similar down for few hours, that is just annoying users. Everything will work again when the attacks stops, and might even work during the attack but access might be much slower than normally. Surely, the attacker gets nothing meaningful in return - I simply can't see how the risk of such an attack can be anywhere close to even medium - it is barely low in my view. Most of the DoS attackers are not wanting to get something meaningful in return. I still think we need to design protocols so they are secure against such attacks. And it is not only against protecting against the attacks, this is also against normal working of the protocol. I.e. if sending one packet whose response packets gets lost, can destroy state from the server, in such way that client cannot detect that, and needs to start IKE SA creation from the beginning, I consider even that a big problem. When we were specifying the MOBIKE we made sure it works also in cases where some of the network connections are one-way, i.e. no return packets get back. It consideres such links broken, and does not use them. This was considered important to get it right, because in that environment it was seen that quite often the links it might see might have such unidirectional properties, and the whole protocol cannot be broken because of one such link. With resumption the whole protocol breaks down if such unidirectional link is ever tried to be used. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Lakshminath Dondeti writes: You should not really do break-before-make style of transitions on real-time environments, and if you keep the old connection while making the new one, then this whole issue is non-issue. Good advice, but that consensus process is from elsewhere. Not every device has multiple interfaces, not every architecture implements the idea of multiple simultaneous associations with base stations, and so on. We were discussing moving traffic from secure cellular network (which do not require IPsec protection, and IKE SA was suspended because of that) to unsecure WLAN network (which now requires IPsec protection because it is unsecure). Do you really say some device which can talk to both WLAN and cellular network cannot talk to both of them simultaneously? Even with if they cannot be used simultaneously they can still bring the IKE SA up while using the cellular network, and then use MOBIKE to move the already up and resumed IKE SA from cellular to WLAN. It seems there is again some scenarios you are refering to that I do not know about, as I do not really think you are now talking about the same use case anymore. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Reopening issue #12
Paul Hoffman writes: It was pointed out that (a) this is a new MUST and Yes, but it can mostly be already deducted from the requirement that end node cannot violate its own policy, meaning it needs to delete Child SA which are not following his policy. If that is already done, there is no point for the new SA having narrower scope than old SA had, and making this MUST makes it simplier for implementations (i.e. they do not need to think what to do for the traffic which do not fit the rekeyed SA, and we do not need to add the traffic selectors from the packet parts). (b) this also assumes that the encryption algorithm and so on will be the same. No it does not. I do not see any text there saying anything about encryption algorithms. Those are negotiated as normally and again if policy has been changed so that the original algorithms are not valid anymore, then the child SA should have been deleted already. There are cases where intiator can only propose subset of algorithms it itself finds acceptable, but that will simply result in NO_PROPOSAL_CHOSEN failure, if other end does not accept any of the algorithms initiator offered. So, how does the WG want to proceed here? I do not think we need to do anything more than what is already done here. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Comments to draft-ietf-ipsecme-ikev2-redirect-08
Section 3 says:
The gateway MUST include the nonce data from the Ni payload sent by
the initiator in the REDIRECT payload. This prevents certain Denial-
but the figures showing how redirect is done does not include Ni data
in the N(REDIRECT, IP_R). Also as GW identity can also be FQDN, it is
bit misleading to use IP_R in the payload, perhaps New_GW_ID would be
better. I.e. it would be better to write the reply as:
(Initial_IP_R:500 - IP_I:500)
-- HDR(A,0), N(REDIRECT, New_GW_ID, Ni_data)
Similar change is also needed in later sections too.
---
In section 5 it should be:
-- HDR, SK {N(REDIRECT, New_GW_ID,)}
(also changed the N[] to N() as is used normally).
---
In section 6 it should be:
(IP_R:500 - IP_I:500)
-- HDR(A,B), SK {IDr, [CERT,] AUTH,
N(REDIRECT, New_GW_ID,)}
(Again changed the N[] to N()). This section does not say whether the
Ni is included in the response, but I assume it is omitted as there is
no need for it. This section should make it clear whether it is
included or omitted.
---
In section 6 the text:
In such cases, the gateway should send the REDIRECT notification
payload in the final IKE_AUTH response message that carries the AUTH
payload and the traffic selectors. The gateway MUST NOT send and the
client MUST NOT accept a redirect in an earlier IKE_AUTH message.
is bit confusing. First it says the gateway (lowercase) should send
REDIRECT in final IKE_AUTH response that carries the AUTH payload and
traffic selectors. Then it says that gateway MUST NOT send redirect in
earlier messages.
Firstly the final IKE_AUTH response willnot include the traffic
selectors, as they are omitted if client is redirected. Thus it is
misleading to say that carries the AUTH payload and traffic
selectors.
Secondly, it is not clear whether the In such cases only refers to
the cases wher gateway decides to do something (interact with AAA
server/ use external authentication server), or in all cases where EAP
or multiple authentication is used. If it is in all cases where EAP or
multiple authentication is used, then that means gateway cannot
redirect in first IKE_AUTH (which is fine for me, but I am not sure if
that was meant). If it is only when gateway needs AAA/external
authentication server, then how can client enforce the MUST NOT
accept redirect in an earlier IKE_AUTH message, if it does not know
whether gateway needs to consult external authentication server or AAA
server...
In general the text is so confusing that I am not sure what is meant.
One easy way to solve this problem is to say things clearly, i.e.
either add one of the following texts:
If multiple IKE_AUTH exchanges are used the REDIRECT notification
payload MUST be in the IKE_AUTH response from gateway to the client,
which also includes the gateways AUTH payload. With EAP, there is
two possible places (first IKE_AUTH and last IKE_AUTH). With
multiple authentication support there are AUTH payload after each
authentication finished, thus server can redirect after each
authentication step is finished. REDIRECT notification MUST NOT be
sent or accepted in any other messages than those having AUTH
payload.
or
If multiple IKE_AUTH exchanges are used the REDIRECT notification
payload MUST be in the final IKE_AUTH response from the gateway to
the client, i.e the one that contains the AUTH payload, and that
would also contain the Child SA SA payload and traffic selectors,
if connection would not have redirected. REDIRECT notification MUST
NOT be sent or accepted in any of the earlier IKE_AUTH messages.
---
In section 7.2 the first paragraph says that The message includes the
new responder's IP address., but this payload can also include FQDN,
I think it should be changed to The message includes the
new responder's IP address or DNS name..
---
In section 7.2. the GW Identity Type should be made to be IANA
allocated registry. We have already had all kind of problems when we
have such registries which are not clearly defined, and then someone
wanted to add entries to there.
It would also be good to explicitly say that IPv4 address are encoded
as 4 octects, and IPv6 addresses are encoded as 16 octets, and that
the FQDN of the new VPN gateway is encoded as dns name without any
terminators (e.g., NUL, CR, etc). Perhaps it would be good to
cut paste the similar parts from the section 3.5 of the rfc4306.
---
In section 7.3 it is not clear whether this registry used for GW Ident
Type is same as in section 7.2 or not. As it does not have same
values, I assume it is supposed to be separate registry. In that case
it would be better to use some different name for it, so there is no
confusion which registry is used (for eaxmple Original GW Ident
Type).
As a separate registry it also need to be
[IPsec] Issue #79: Remove CP from Create_Child_SA ?
Yaron Sheffer writes: Patricia noted in a post to the IPsec mailing list (12/12/2008) that section 2.19 says that request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload. IMO the normal way of doing things is in this message 3, so rather than a parenthetical remark, it's really the only one anyone uses. I don't think it makes sense to assign a different IP address for each SA, and I don't think anyone actually intended for this to be implied. In RFC 4306 http://tools.ietf.org/html/rfc4306 , section 3.15, one of the attributes that can be sent in the CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time before the client needs to renew the address with the gateway (probably renew the lease with a DHCP server). With such an attribute, it made sense for the client to renew the address along with rekeying some CHILD_SA. In the bis document, we've deprecated this attribute, and it is now marked as RESERVED. Since we've done that, I suggest we remove the CP payload from the Create Child SA exchange in appendix A, and reword section 2.19 to reflect that requesting an IP address is only acceptable during IKE_AUTH. I agree in the common case of doing configuration payloads only during IKE_AUTH, but I do not think it is good idea to restrict it in such way. In future we might make extensions (for example the ipv6-config or similar) where we might want to do configuration payloads as separate informational exchanges, or as part of another create child sa exchange. I am in favor of removing the CP from the appendix C.4 from create child SA, but for example section 2.20 has example showing how configuration payload can be used in separate INFORMATIONAL exchange. The section 4 already mentions that minimal implementations are required to send CP request in message 3, and servers understanding it must return CP payload (it does not explictly mention it must be in same message as where the other child SA specific payloads (SA, TSi, TSr) are). There is no requirement anywhere for implementations to process Configuration payloads in any locations, but I do not think we should forbid them in other locations. In other locations they might be simply ignored if the other end does not support them in those locations. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #36: Interaction of IKE_SA_INIT retransmissions with specific notifies
pasi.ero...@nokia.com writes:
Yaron Sheffer wrote:
{{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require
 some special handling. When a responder receives an IKE_SA_INIT
request, it has to determine whether the packet is retransmission
belonging to an existing 'half-open' IKE_SA (in which case the
responder retransmits the same response), or a new request (in which
case the responder creates a new IKE_SA and sends a fresh response),
or it belongs to an existing IKE_SA where the IKE_AUTH request has
been already received (in which case the responder ignores it).
Tero:
There is also the case of the invalid KE and cookie notifies, i.e. we
need to add comment about those too:
   ... or it belongs to an existing IKE_SA where the IKE_AUTH request
has been already received (in which case the responder ignores it),
or it is INVALID_KE_PAYLOAD or COOKIE notify responses to the
   IKE_SA_INIT request.
Paul: Not done. This is interesting, but should be discussed on the list.
The current text is about processing of IKE_SA_INIT *requests* by
the responder, so talking about IKE_SA_INIT responses (such as
INVALID_KE_PAYLOAD) in the same sentence would be IMHO very confusing.
Hmm... true, missed that it was only talking from the responders side,
not from the initiator side.
I'd suggest we keep this paragraph as is.
I agree on that now when I reread the section.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Reopening issue #12
pasi.ero...@nokia.com writes: Tero Kivinen wrote: Paul Hoffman writes: It was pointed out that (a) this is a new MUST and Yes, but it can mostly be already deducted from the requirement that end node cannot violate its own policy, meaning it needs to delete Child SA which are not following his policy. If that is already done, there is no point for the new SA having narrower scope than old SA had, and making this MUST makes it simplier for implementations (i.e. they do not need to think what to do for the traffic which do not fit the rekeyed SA, and we do not need to add the traffic selectors from the packet parts). (b) this also assumes that the encryption algorithm and so on will be the same. No it does not. I do not see any text there saying anything about encryption algorithms. Those are negotiated as normally and again if policy has been changed so that the original algorithms are not valid anymore, then the child SA should have been deleted already. Hmm... narrowing and algorithm negotiation can interact. Consider the following situation: Alice's SPD: traffic on UDP ports 1000-1999 MUST use ESP w/3DES or AES (AES preferred) Bob's SPD: traffic on UDP ports 1000-1499 MUST use ESP w/3DES or AES (3DES preferred) traffic on UDP ports 1500-1999 MUST use ESP w/AES The old SA (OK to both Alice and Bob): UDP ports 1000-1999, AES Now, suppose Alice sends a CREATE_CHILD_SA exchange for rekeying this SA, proposing algorithms AES and 3DES, and traffic selectors for UDP ports 1000-1999. Bob prefers 3DES, and picks that. Bob cannot pick that one, as it would be against his own policy for the port 1500-1999 range, thus he MUST select AES, which is acceptable for the whole range. But now Bob cannot meet the requirement new SA MUST NOT be narrower than the old one, because it would violate his policy. This depends which happens first, algorithm selection or narrowing. In most cases the first thing happens that traffic selectors are used to find suitable policy entry from SPD and then algorithms and traffic selectors are selected based on that. 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. In general I do not expect implementations ever to do that, and if they happen to do that then they should also have code that understands the rekeying requirements, meaning they must select those same SPD entries for the rekeying and also use the policy restrictions from them to select algorithms for the rekey. Meaning that, in your example the Bob can still pick same SA traffic selectors (UDP ports 1000-1999) and select algorithm which is acceptable for him (AES). He cannot select 3DES even when that is his preferred algorithm for one part of the range. So, I think the current text in 2.9.2 *does* assume that encryption algorithm negotiation behaves differently when rekeying (and IMHO this requirement is not in RFC 4306). I do not find anything from 2.9.2 which would indicate that it assumes algorithms to stay same (which was the actual question of b). It does require algorithm selection to work so it does result in algorithm that is acceptable for the whole old SA. Note, that when the Bob initially created the SA he had exactly same algorithm selection problem, and that algorithm selection problem is because he allowed SA to use multiple SPD entries. If Bob makes sure that SA is derived from exactly one SPD entry, then this problem cannot arise. In that case Bob would also delete the SA when it was reconfigured to have that new policy which splitted old SPD entry to 2 new SPD entries, as the SA would then refer to two SPD entries. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #98: 1 or two round trips for resumption
Narayanan, Vidya writes: The requirement is quite simple and you just seem to ignore it or provide unacceptable alternatives. The handoff latency must be good What handoff? We are talking about resumption, not handoff. I do not consider those same. Or then I understand completely wrong what handoff is, and what resumption is. For me handoff is when you have active connection to one place, and then you want to move that connection to another place without interrupting the communications. Resumption is when we have connection that was disconnected temporarely because of some reason, and we want to resume it after some period of time. Their requirements are very different and if we are really making standard for handoff, then our protocol would be different. enough to support VoIP like applications and the handoff may imply needing an IPsec session between the mobile and a network entity (be it a VPN or for MIP6 channel security). You claim that in such scenarios, IPsec should be used all the time, even on the interfaces that don't require it for security purposes - so, even if the device is not running MIP6 until it moves to the new interface, it now needs to establish an IPsec session. I am not claiming it should be used all the time, but I am claiming that if you are planning to start to use IPsec again you should not first tear down your non-IPsec connection while you set up the IPsec connection. You should keep the old connection alive and then when you have IPsec connection ready, then you move your traffic to that connection requiring IPsec. I do not really belive you get very good handoff with break before make methods on any networks. However, this is not acceptable for various reasons (including that operators are not interested in maintaining IPsec sessions for all devices just in case it roams at some point). They do not need to maintaing IPsec session for all devices for all time, they need to resume them about 10-100ms before they are actually required, i.e. before they break their old connection. One dropped packet on the IPsec resume is going to cause several times longer delay than one round trip. It is bed idea to design system so it does not tolerate even single lost packet. Also, designing for a fixed set of interfaces is a problem - it may not always be 3G and WiFi - it could be 3G and WiMAX; it could be 3G infrastructure and 3G Femto; it could be 3G infrastructure and 3G multi-hop, etc. In many of these cases, handoffs don't happen using a single radio operating in multi-mode. Then when you decide you are going to roam to network that requires IPsec, you can resume the IPsec connection using the old connection (even when it is unneeded there), and then you have IPsec connection which you can move to new network with single round trip protocol. With WiFi the network setup time is usually much longer than one round trip. In devices I normally use (laptop, pda etc) the device requires about 3-10 seconds to get network up and working (turning radio on, finding basestation, connecting to basestation, getting IP-address via DHCP etc). I have not ever seen wlan that would work so fast that it would be enough for VoIP handoffs. I do not know about WiMAX, but at least my 3G cellular phone usually takes about 1-2 seconds to create data connection (i.e. when I select which internet connection to use to the time when it actually starts loading the page) and it seemed to take about one more second before the packet it sent out actually reaching my server. Adding 20-40 ms for one more round trip time to that does not really affect the big picture. On the other hand if you can do network setup while still keeping old connection alive, then you can also do the resumption and the one round trip during that time too. Can you explain me on what kind of devices you can really do handoff to new network with break and make method? So what is the exact problem there? The fundamental issue is that MIP6, using the K bit, allows the IP address on the IKE SA to change, thereby accomplishing the MOBIKE functionality and also conflicting with it if it ran together. When using MOBIKE you should not use the K-bit (if that is what I think it is), but you should just leave the IP-address handling of the IKE and IPsec to MOBIKE. The MOBIKE was meant to be used as building tool for MIP6, i.e. it still requires MIP6 to start using it, i.e. there should have been separate document specifying how to use MOBIKE and MIP6 together. It never assumed it would solve the MIP6 problem directly, it assumed that MIP6 and MOBIKE could together be used to solve the problem. Please read the thread on MOBIKE and MIP6 on the MIP6 mailing list from back in 2006 if you are interested in more details. I have not really been interested in MIP6, after I showed them how MIP6 and IPsec can easily used together without any modifications to either MIP6 or IPsec, but they said that solution was
[IPsec] Transform IDs for AES-GMAC in IKEv1
pasi.ero...@nokia.com writes: (1) ask IANA to assign the four missing numbers (after IESG approval). (2) submit an RFC Editor errata, saying something like this: (3) ask IANA to include a pointer to this errata in the isakmp-registry entries. Does this sound like a reasonable plan? I think this is good way to solve the issue. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Issue #90: Shorter WESP negotiation
Grewal, Ken writes: In the current traffic visibility draft, we indicate that WESP can be negotiated via IKEv2 using a new protocol identifier. Charlie Kaufman suggested that it may be plausible to use a notification method along the lines of USE_TRANSPORT_MODE in RFC 4306, where the type of transport is negotiated independently of the cryptographic parameters. Pros: Shorted negotiation using notifications. For pros you can also put down automatic fallback to normal ESP if other end does not support WESP. There is no guarantee that other end will properly fall back to other protocol if protocol identifier is used when negotiating WESP, but responder MUST ignore unrecognized status notification types. There is no specified requirement for IKEv2 implementation to support multiple proposal substructures, thus trying to propose ESP-NULL or WESP-NULL might not work (i.e. implementation can only check first the most preferred proposal and ignore the others). The current RFC does not specify how many proposals implementations should check, and at least some implementations do have some kind limit for number of proposals they check (and that limit might even be 1). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Issue #57: Clarify D-H transform
Yaron Sheffer writes: Yaron: 3.3.2: there is no explanation here or elsewhere that the D-H transform for ESP and AH is used for PFS. Paul (off list): Not done. I don't think it belongs in 3.3.2, and I also don't agree that the transform is the D-H transform for ESP and AH is used for PFS; that's an oversimplification. Yaron: I will settle for 1.3.1, and/or 1.3.3. It is not clear for me what kind of text you want to add to there. Can you propose some text so it would be easier to understand what the issue here is? -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Issue #58: Access control: add ref to IPsec architecture
Yaron Sheffer writes: 3.5: this section is extremely liberal on what access control policies people can implement, but that's too late to change now. However, we CAN at least add a reference to RFC 4301, Sec. 4.4.3.1 (as was done in RFC 4945, pki4ipsec). ... The following new text, adapted from RFC 4945: The Peer Authorization Database (PAD) as described in RFC 4301 [XX] describes the use of the ID payload in IKEv2 and provides a formal model for the binding of identity to policy in addition to providing services that deal more specifically with the details of policy enforcement. The PAD is intended to provide a link between the SPD and the IKE security association management. See RFC 4301 [14], Section 4.4.3 for more details. This paragraph looks good for me. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails
pasi.ero...@nokia.com writes: What do you think of the proposed text here? http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html The NO_ADDITIONAL_SAS error should be added to the error list, and I am not completely happy with the last paragraph, i.e. it could be expanded bit more to explain the situation more, not just say treated with caution. I am bit worried that implementors do not understand the difference with encrypted and MACed compared to the fact that the other peer has authenticated himself (i.e. sent AUTH payload). I think adding bit more text there to make that clear would be needed. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Reopening issue #12
pasi.ero...@nokia.com writes: Tero Kivinen wrote: But now Bob cannot meet the requirement new SA MUST NOT be narrower than the old one, because it would violate his policy. This depends which happens first, algorithm selection or narrowing. In most cases the first thing happens that traffic selectors are used to find suitable policy entry from SPD and then algorithms and traffic selectors are selected based on that. 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. Well, nothing in RFC 4301 requires implementing the SPD internally as an ordered list of entries; some kind of tree or associative array data structure could work, too. The requirement for ordered list of entries applies to the management UI, not the internals. So I think an implementation that treats the following two policies equivalently *is* allowed by RFC 4301 and 4306: Policy A: traffic on UDP ports 1000 MUST use ESP w/AES traffic on UDP ports 1001 MUST use ESP w/AES Policy B: traffic on UDP ports 1000-1001 MUST use ESP w/AES Perhaps, but it should not consider following policies equivalently: Policy A: traffic on UDP ports 1000 MUST use ESP w/AES or w/3DES traffic on UDP ports 1001 MUST use ESP w/AES Policy B: traffic on UDP ports 1000-1001 MUST use ESP w/AES meaning that it should delete the Child SA immediately when the one of the policy entries in the policy A was changed to include 2 algorithms. My main concern was whether this (new SA MUST NOT be narrower than old one, but MAY be wider) is a new requirement compared to RFC 4306... Does that really matter even if it is new requirement or not? Is there something wrong with that requirement, i.e what is the reason why we should not add that MUST NOT in document? As we have already argued quite long about whether it is new requirement or not, that really says that there was nothing that said it was clearly allowed before. I.e. mostly RFC4306 was silent about the issue, and by interpreting other MUSTs in RFC4301 and RFC4306 I think we can derive same MUST NOT requirement we added there. I.e. we are just clarifying RFC4306 to explicitly say something that could have beeen derived from very complex text combination from RFC4301 and RFC4306. I do not think we really must add that text, as I still think it can be derived from other part of specifications, but I think it would make it easier to understand how rekeying child SA is supposed to work. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails
Yaron Sheffer writes: Hi Pasi, Tero's mail gives a clearer explanation of the situation than your proposed text. Gluing the two together, how about replacing your last paragraph with: If the failure is related to creating the IKE SA (for example, AUTHENTICATION_FAILED), the IKE_SA is not created. Note that although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet (or if the peer fails to authenticate the other end for some reason), the information needs to be treated with caution. More precisely, (assuming that the MAC verifies correctly) the sender of the error indication is known to be the responder of the IKE_SA_INIT exchange, but the sender's identity cannot be assured. That is also good, but I would like to add also something about what implementations should do in that situation. Texts with treated with caution etc are fine for specifications, but are really annoying for implementors. What does that mean for my implementation? What kind of things should I do after that? I.e. it should tell following things: - If properly MACed error reply is received, the IKE SA creation fails, and no more retransmissions is sent. - This is not fatal permanent error as the identity of the other end could not be proven, meaning active attacker could have faked those messages. - Because of this it should still retry IKE SA creation from the beginning several times, before completely giving up (and perhaps enable multiple IKE_SA_INIT response processing described in section 2.4). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #57: Clarify D-H transform
Yaron Sheffer writes: Hi Tero, Sec. 3.3.2 mentions that you negotiate a D-H group for ESP/AH, even though you only need encryption and integrity transforms for these protocols. I find it confusing, certainly for newcomers. For clarity, I suggest to add after the table in Sec. 3.3.3, this text: Although ESP and AH do not directly include a Diffie Hellman exchange, a D-H group MAY be negotiated for the Child SA. This allows the peers to employ D-H in the CREATE_CHILD_SA exchange, providing Perfect Forward Secrecy for the generated Child SA keys. Ok, I see no problem adding that text, and I think it really belongs to the 3.3.2 as you originally requested, not in 1.3.1/1.3.3. The section 1.3 section already describes about KE payloads and PFS: 1.3. The CREATE_CHILD_SA Exchange The CREATE_CHILD_SA request MAY optionally contain a KE payload for an additional Diffie-Hellman exchange to enable stronger guarantees of forward secrecy for the Child SA. The keying material for the Child SA is a function of SK_d established during the establishment of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA exchange, and the Diffie-Hellman value (if KE payloads are included in the CREATE_CHILD_SA exchange). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Comments to draft-ietf-ipsecme-ikev2-redirect-08
Vijay Devarapalli writes:
In section 6 it should be:
(IP_R:500 - IP_I:500)
-- HDR(A,B), SK {IDr, [CERT,] AUTH,
N(REDIRECT, New_GW_ID,)}
Fixed all of the above.
(Again changed the N[] to N()). This section does not say whether the
Ni is included in the response, but I assume it is omitted as there is
no need for it. This section should make it clear whether it is
included or omitted.
It is included only in the IKE_SA_INIT response. Section 7.2 says
The 'Nonce Data' field
is present in the REDIRECT payload only when the REDIRECT payload is
sent in the IKE_SA_INIT response message. It MUST NOT be included in
the REDIRECT payload if sent in an IKE_AUTH response or in a gateway-
initiated redirect message.
I hope this is sufficient.
I found that later, but when I was reading the protocol description in
section 6 I was wondering whether the nonce is included or not. It
might be enough to explain that in the description of the payload
itself, especially now if the N(REDIRECT, New_GW_ID,) in example
clearly indicates nonce is empty.
In section 6 the text:
In such cases, the gateway should send the REDIRECT notification
payload in the final IKE_AUTH response message that carries the AUTH
payload and the traffic selectors. The gateway MUST NOT send and the
client MUST NOT accept a redirect in an earlier IKE_AUTH message.
is bit confusing. First it says the gateway (lowercase) should send
REDIRECT in final IKE_AUTH response that carries the AUTH payload and
traffic selectors. Then it says that gateway MUST NOT send redirect in
earlier messages.
Firstly the final IKE_AUTH response willnot include the traffic
selectors, as they are omitted if client is redirected. Thus it is
misleading to say that carries the AUTH payload and traffic
selectors.
Please see my response to Pasi's email. This text has been updated. Redirect
during the first IKE_AUTH response is always allowed even when EAP or
multiple authentication is used.
The text was not very clear about this. I will wait to see next
version to see if that is clearer.
Secondly, it is not clear whether the In such cases only refers to
the cases wher gateway decides to do something (interact with AAA
server/ use external authentication server), or in all cases where EAP
or multiple authentication is used. If it is in all cases where EAP or
multiple authentication is used, then that means gateway cannot
redirect in first IKE_AUTH (which is fine for me, but I am not sure if
that was meant). If it is only when gateway needs AAA/external
authentication server, then how can client enforce the MUST NOT
accept redirect in an earlier IKE_AUTH message, if it does not know
whether gateway needs to consult external authentication server or AAA
server...
In general the text is so confusing that I am not sure what is meant.
One easy way to solve this problem is to say things clearly, i.e.
either add one of the following texts:
If multiple IKE_AUTH exchanges are used the REDIRECT notification
payload MUST be in the IKE_AUTH response from gateway to the client,
which also includes the gateways AUTH payload. With EAP, there is
two possible places (first IKE_AUTH and last IKE_AUTH). With
multiple authentication support there are AUTH payload after each
authentication finished, thus server can redirect after each
authentication step is finished. REDIRECT notification MUST NOT be
sent or accepted in any other messages than those having AUTH
payload.
or
If multiple IKE_AUTH exchanges are used the REDIRECT notification
payload MUST be in the final IKE_AUTH response from the gateway to
the client, i.e the one that contains the AUTH payload, and that
would also contain the Child SA SA payload and traffic selectors,
if connection would not have redirected. REDIRECT notification MUST
NOT be sent or accepted in any of the earlier IKE_AUTH messages.
If the gateway decides to redirect after the first authentication,
it would be the same as the exchange in section 6. The second
authentication would not even happen.
If initiator decides to use EAP, then the exchange is not same as in
section 6, as the initiator has not proven his identity yet. The first
authentication only authenticates the identity of the server.
If Shared secret or certificates are used then both ends identities
are authenticated during the first IKE_AUTH exchange.
With multiple authentications the server can at any point decided that
it has had enough authentication and ignore the ANOTHER_AUTH_FOLLOWS
wish from client (as far as I understand the rfc4739), thus it can at
any point when authentication is finished decided to finish the whole
IKE_SA creation and send final AUTH.
I think we need bit more
Re: [IPsec] Reopening issue #12
pasi.ero...@nokia.com writes: I agree that rekeying is currently not very easy to understand. But e.g. early drafts of ikev2-clarifications (-00 and -01) included some text wondering about what exactly N(REKEY_SA) means (that is, what is different when you do/don't include REKEY_SA in CREATE_CHILD_SA exchange), and all of those reasons (which I think you also commented back then) would IMHO allow the new SA to be narrower than the old (even when N(REKEY_SA) is included)... I originally also tought so, i.e. that is the reason this issue is here in the first place. I.e. if the narrower traffic selectors are allowed, then we MUST also have traffic selectors from the triggering packet. Then other people convinced me that if there would be reason for the rekeyed SA to have narrower traffic selectors that are currently used, then the SA would have been already deleted because it would have been against policy, thus such situation cannot ever happen. Check the original ticket description (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/12?version=1#L1). I do not really have strong opinion which way to go, but we either needs to make sure there is the triggering packet traffic selectors (which might be problematic if SA was rekeyed because of time) and the rekey can narrow down traffic selectors. Or we assume that narrowing case cannot happen, as the SAs were already deleted before they were rekeyed in such situations, and we can say that traffic selectors MUST NOT narrow down. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
Michael Richardson writes: Let me suggest a situation where perhaps I would like to bring up an IKE_SA and not a CHILD_SA: it might be for just sending initial contact, and perhaps even a DELETE. I sometimes move quickly from being outside my IPsec gateway/firewall (such as being on wireless), to being wired behind the gateway, where I do not need IPsec. The DPD doesn't kick off fast enough, and my traffic goes to where I am no longer. It would be nice to bring up the IKE_SA (or... haha, resume it), just so that I can send a delete and/or initial_contact. Or MOBIKE, and just move tunnel end point to your new location. Seems like to do this, once needs to include a known-to-be-unacceptable CHILD_SA proposal. Or just create valid Child SA, and then send delete to IKE SA which will take care of the IKE SA and Child SA. The extra Child SA created there do not really cost anything. The cpu cost will be few symmetric hashing and macin etc, so I do not really consider this worth of one extra mode again. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
Yoav Nir writes: A far more common situation is when I'm outside, not moving anywhere, and I want to connect. I haven't even opened my mail client yet, or launched the browser (because those thing hate it when the VPN client changes routing to addresses they are trying to reach). The reason I want to connect before everything else, is that connecting involves some effort (typing the PKCS#12 password, entering a username and password, copying the OTP from the cellphone to the computer...). I want to get this over with, but there's still no packet to derive selectors from. Most likely in such situations you already have your configuration set up so you know that you are going to request IP-address from inside, and you are going to use traffic selectors from that IP-address to the whole subnet on the other, end so you will propose the any to any traffic selectors to the server anyways. Then server will assign IP-address, narrow the traffic selectors down and then create the Child SA at the same time. All of this could be tied up to the virtual interface up event, i.e. when you say ifconfig vipsec0 up or similar (or pressing the Connect gui button, which will do the same thing internally), that will trigger the IKE negotiation and all of this. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Issue #107
Yoav Nir writes: I've submitted issue #107 about certificate encoding. IMO it's not clear how certificate chains are to be encoded in IKEv2. http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107 If certificate chain is sent using X.509 certificate - signature (4) format, then it is sent as multiple separate CERT payloads. There is text about this in multiple places in the RFC4306. In 1.2 it clearly indicates that there can be multiple CERT payloads and the first certificate provided must contain the public key used to verify AUTH field: -- 1.2. The Initial Exchanges ... 2.15). It might also send its certificate(s) in CERT payload(s) and a list of its trust anchors in CERTREQ payload(s). If any CERT payloads are included, the first certificate provided MUST contain the public key used to verify the AUTH field. The optional payload ... -- and then there is the text you put to the #107: -- 3.6. Certificate Payload ... X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. ... Implementations MUST be capable of being configured to send and accept up to four X.509 certificates in support of authentication, and also MUST be capable of being configured to send and accept the first two Hash and URL formats (with HTTP URLs). Implementations SHOULD be capable of being configured to send and accept Raw RSA keys. If multiple certificates are sent, the first certificate MUST contain the public key used to sign the AUTH payload. The other certificates may be sent in any order. ... -- So if that format 4 (and 7) is used then multiple CERT payloads are used and first of the CERT payloads must be the one matching the public key of the AUTH payload. If other formats which support bundles are used (RCKS#7 wrapped (1), hash and url of X.509 bundle (13)) are used then there usually is only one payload containining the whole chain. As the current document leaves PCKS#7 wrapped X.509 certificates with very little specification implementations could also do things differently there (i.e. wrap each certificate separately or do something else). For the X.509 bundle I think the format is more clear and only one CERT payload is sent containing hash and url of all certificates and crls needed (and first certificate there is the one used for AUTH payload). It might be good to add bit more text to the X.509 Certificate - Signature (4) text, i.e something like: If multiple certificates are sent, then each of them is encoded as separate CERT payload.. Note, that some implementations might send certificates in multiple formats, i.e. they might send RAW RSA key first, than then provide for example HASH and URL of X.509 bundle also. Depending on the recipient it might jsut use the RAW RSA key or might might actually fetch the bundle and use that. Note, that the ordering requirement that first certificate provided MUST contain the public key used to verify AUTH field, is for the first certificate provided, it is not separately for each certificate encoding type, i.e. if first certificate provided happened to be in RAW RSA format, then even if the same public key is given out in different format too (for example as X.509 cetificate), there is no ordering requirements there anymore. Of course it would be best if implementations would keep the same order there, i.e. if they include same public key used in AUTH payload in multiple formats they always include that first for each certificate type they provide (i.e. the first X.509 certificate - signature (4) CERT payload has the public key used in AUTH payload, even when it is not strictly required if there has already been other CERT payloads before it in different format). Smart implementations will simply put all certificates regardless of format to their certificate validator, and then take public key from the first CERT payload (most likely ignoring all they do not understand) and try to verify if that public key can be verified to be valid with configured trust anchors. I do not expect mixing of cert encodings to happen that much, but the RAW RSA key combined with X.509 certificates might be the exception of that. I.e. in some environments it might be useful to provide both, so minimal implementations just use preconfigured RAW RSA key, and other implementations might actually verify the certificates instead. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #107
Paul Hoffman writes: At 3:09 PM +0300 5/11/09, Yaron Sheffer wrote: Or possibly: X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. With this encoding, if a chain of certificates needs to be sent, multiple CERT payloads of type 4 MUST be used, the first of which holds the public key used to directly validate the sender's AUTH payload. The other CERT payloads contain the other components of the chain in natural order, i.e. each certificate signing the preceding one. In a word: no. This is a new requirement on a topic that was vague before. It should be sufficient for us to say something in 3.6 about multiple CERT payloads being acceptable, and probably (but not necessarily) the correct way to send a PKIX chain if the party believes that it is needed. Yes, it might be better to say at the beginning of the section 3.6 that multiple CERT payloads is allowed, and if CERT encoding is such that it can only encode one certificate then multiple CERT payloads is the way to send the chains. If encoding can handle multiple certificates (Hash and URL of X.509 bundle), then the whole certificate chain (and associated CRLs if needed) can be sent as one CERT payload (or split to multiple pieces if needed). There can also be multiple CERT payloads with different encodings. Sending multiple CERT payloads is not only restricted to X.509 Certificate - Signature (4) format, and because of this the text should be at the beginning of 3.6 section. Note, that 3.6 explicitly says that except the first certificate, all other certificates can be in any order. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Next Header field in WESP header
gabriel montenegro writes: Your point below about Next Header being useful is specially valuable as it is from someone involved in developing these boxes. If the box can do IPv6 header processing (which do require similar offset calculations) to find the WESP header in the first place, then doing packet length - ICV length (from packet) and get byte from there is not that complicated and hardware can most likely do that already. And I hope nobody is designing new hardware now which cannot do IPv6 processing... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Next Header field in WESP header
gabriel montenegro writes: Perhaps we need more details on what exactly we mean by the endpoint thus must verify the sanity of the WESP header before accepting the packet? And the action to drop the offending packet? Yes. I think we need very specific rules with MUSTs in them to say that packet MUST be dropped if ESP-NULL packet has Next header field in WESP header which do not match the real Next Header field in the end. Also final recipient MUST check that the HdrLen or TrailerLen fields in the WESP header match the negotiate SA and MUST drop the packet if they do not match. Next question is what values are used for HdrLen and TrailerLen if encrypted ESP is used. If we use real values we do leak out information, but on the other hand there is no point of giving that information out as middle nodes cannot do anything with it. Actually what are we trying to do if we send encrypted ESP with WESP wrapper. If we are just making so that we can extend the WESP header in the future, isn't the version bits enough for that? I mean if we do not know why someone would want to use WESP encoding for encrypted ESP now, why do we allow it? -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Next Header field in WESP header
Yaron Sheffer writes: I agree that the HdrLen and TrailerLen fields MUST be 0 for encrypted WESP. So yes, we use WESP for encrypted traffic to get: - Extensibility (with the 8-bit Flags field). This is future extensibility, which is needed only after we define some future extensions using this. When we define those future extensions we can also define that encrypted traffic can be used. I would rather keep this for future extension, i.e. only define the use after we find out what we want to do, as all the end nodes needs to be updated anyways before those new extensions can be used (and the intermediate nodes too perhaps). The current document is not very clear what to do if reserved bits are set. It says On receiving a packet, these values must be checked to ensure that they are as indicated above.. This does not specify whether this is only for the final receiver (i.e. the node talking IPsec), or also all intermediate nodes, or only those intermediate nodes who actually look inside the WESP or what. It also does not specify what needs to be done if those fields are not as specified. I.e. we need more text for that, i.e. specific processing rules for a) intermediate nodes who parse WESP header, b) end IPsec entity. In some cases the dropping / passbying the packet depends on the policy. On the other hand if flags is set or version number does not match then that usually means that the format of the WESP header might be different thus it might be that intermediate nodes cannot parse header any further. - A single protocol that can do both cases. By wasting extra 4 bytes and using protocol which might not be supported by other end. I think it is better to use plan normal ESP for encrypted traffic, but I agree that we should probably define the WESP header so that if Next Header in WESP header is 0 then contents is encrypted, and intermediate nodes MUST NOT try to parse it. I would still recommend using normal ESP for encrypted traffic... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Some comments about redirect
Vijay Devarapalli writes: Anyone else have any comments on including 4 - Locally Meaningful Name? I can see use for that, so I would say it is good idea to add such. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-00.txt
Paul Hoffman writes: Title : Heuristics for Detecting ESP-NULL packets S, that was two months ago, and there has been no discussion. Has anyone other than the document authors (and the WESP authors) read the document? Does the WG find this to be useful? Tero and Dan: have you found anything that you want to change? We did receive few comments that might be added to the draft, those were about the GCM IV (i.e. they might not be random, but might be counter, which means they might have lots of zeroes in the beginning, and that might affect the heuristics a bit), and another were about adding some section about how end-nodes can make small changes to make the heuristics more efficient (i.e. use more than minimal number of padding, for first few packets for new SA, and make sure GCM IVs look random enough, so they cannot be confused for TCP or UDP headers). I have not made those changes, as I am not sure if we want to even add both of them. I was mostly waiting for more comments and then think again about whether to add those or not. Ps. I am currently on vacation until IETF, so I am reading my emails very randomly... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Handling Redirect Loops
Vijay Devarapalli writes: 7. Handling Redirect Loops The client could end up getting redirected multiple times in a sequence, either because of wrong configuration or a DoS attack. The client could even end up in a loop with two or more gateways redirecting the client to each other. This could deny service to the client. To prevent this, the client SHOULD be configured not to accept more than a certain number of redirects (MAX_REDIRECTS) within a short time period (REDIRECT_LOOP_DETECT_PERIOD) for a particular IKEv2 SA setup. The default value for MAX_REDIRECTS configuration variable is 5. The default value for REDIRECT_LOOP_DETECT_PERIOD configuration variable is 300 seconds. These values MUST be configurable on the client. Is there really any reason to have the last MUST I.e. what is the reason to force those parameters to be changeable? I do not really see reason to change those in most cases, and if someone really uses some really wierd setup where 5 is not enough for the max redirects, then he can use some implementation where those are configurable... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] AD review comments for draft-ietf-ipsecme-ikev2-resumption
pasi.ero...@nokia.com writes: - Section 5: Peer vendor IDs cannot be implementation specific -- if the old gateway sent Vendor ID FOO, the client has to unambiguously know whether it's allowed to FOO vendor-specific payloads to the new gateway or not. Probably this should be Not resumed, Vendor ID payloads are resent in new exchange if required. As we are resuming back to the same GW (failover from one GW to another was specific non-goal for this document), I think we can safely assume that GW support exactly same vendor IDs which it did last time we connected it (or if the GW version was changed and support for some vendor IDs were removed, then resumption tickets were also invalidated). So in this case the implementation specific is quite ok. I.e if server and client support extension FOO indicated by vendor ID FOO, which requires some external data to be stored, then that information that FOO was supported and that information was stored to ticket needs to be stored to ticket. If the extension FOO does not need any data to be stored across the resumptions, then there is no need to modify ticket, thus there is not really need to store information whether FOO was supported in the first place or not. Then there is this second case whether client is allowed to remember that gateway supported extension FOO without sending any Vendor ID payloads, or whether they need to be resent. I think we should require them to be resent, as you said there. But there is still cases where ticket might need to store extra information depending whether vendor ID was originally used or not. So I think we need two separate cases one for Supported Vendor IDs which is Not resumed, Vendor ID payloads are resent in new exchange if required, and some kind of Vendor ID specific data, which is Implementation specific (needed in ticket only, if vendor-specific state is required). BTW, the table would be much more readable if there would be some kind of separators between items, i.e. change to be: ++--+ | State Item | After Resumption | ++--+ | IDi| From the ticket (but must| || also be exchanged in | || IKE_AUTH). See also Note 1 | ++--+ | IDr| From the ticket (but must| || also be exchanged in | || IKE_AUTH)| ++--+ | Authentication method (PKI,| From the ticket | | pre-shared secret, EAP, PKI-less | | | EAP| | | [I-D.eronen-ipsec-ikev2-eap-auth] | | | etc.) | | ++--+ | Certificates (when applicable) | From the ticket, see Note 2 | ++--+ | Local IP address/port, peer IP | Selected by the client, see | | address/port | Note 3 | ++--+ | NAT detection status | From new exchange| ++--+ | SPIs | From new exchange, see Note | || 4| ++--+ | Which peer is the original| Determined by the initiator | | initiator?| of IKE_SESSION_RESUME| ++--+ | IKE SA sequence numbers (Message | Reset to 0 in| | ID)| IKE_SESSION_RESUME, and | || subsequently incremented | || normally | ++--+ | IKE SA algorithms (SAr)| From the ticket | ++--+ | IKE SA keys (SK_*) | The old SK_d is obtained | || from the ticket and all keys | || are refreshed, see | || Section 5.1
[IPsec] draft-ietf-ipsecme-ikev2-redirect-13.txt
I read through this document, and it seems to be mostly ok. Only think that might require clarification is the section 11. IANA Considerations. It currently says that A specification that extends this registry MUST also mention which of the new values are valid in which Notification payload., but looking at the initial IANA table, that does not give that information. It would be much better if the initial table would be specified correctly already in this document i.e give initial table as: -- Registry: Value Description Used In Reference --- --- --- - 1 IPv4 address of the new VPN gateway R,RF [RFC] 2 IPv6 address of the new VPN gateway R,RF [RFC] 3 FQDN of the new VPN gateway R [RFC] 4-240 Unassigned [RFC] 241-255 Private Use [RFC] R = REDIRECT notify RF = REDIRECTED_FROM notify -- This kind of method is already used in IANA registries, for example IKEv2 Transform Type registry lists which values are used in IKE and which are used in ESP/AH (http://www.iana.org/assignments/ikev2-parameters). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.txt
Sean Shen writes: Hi, IPSECME WG, The 01 version of draft-ietf-ipsecme-aes-ctr-ike was uploaded. The modification addressed comments we received so far and also include some other editing. Major changes are as following: #4 Section 3.2 Added clear reference to rfc4302 and rfc4307 for integrity requirement and algorithm choice. I do not think it is good idea to copy the table from RFC4307 as it is likely to change in the future, so better would be just to give reference to the document. On the other hand RFC4306 already says that ... implementations MUST NOT negotiate NONE as the IKE integrity protection algorithm ... (section 5. Security Considerations of RFC4306), thus AES-CTR cannot be used without integrity algorithm in this context anyways. One thing that is not 100% clear from the draft is that whether there is any padding in the encrypted payload. RFC4306 says that encrypted part is padded up to the block size of the cipher. In AES-CTR the block size is 1, thus that does not require any padding. Normal ESP requires padding for at least up to 4-byte boundary, regardless of the block size of the cipher, thus even AES-CTR uses padding up to 4-byte boundary. The IKEv2 SA does not require thus. I think it would be better to add text explictly saying this. I.e. add text like this to the end of 2.3: ... For this reason, AES-CTR does not require the plaintext to be padded to a multiple of the block size. For Encrypted Payload this means that Padding field is always empty, and Pad Length field will always be 0. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.txt
Sean Shen writes: The point here is to say that integrity protection is needed with aes-ctr, not trying to specify which integrity algorithm to choose. rfc4306 already required integrity for ikev2 and we refered to 4306 here. The choice of integrity algorithm is up to rfc4307 or some update document, we just listed what rfc4307 chooses to make this document more rich of information. If you think the table gives misleading impression of only requiring these particular algorithms, we may add another sentence to hint that integrity algorithm requirement may change over time, please check 4307 and 4307's update, the following listed algorithm is just showing current 4307's requirement. I think it is better to remove the table, and just refer to RFC4307 directly. One thing that is not 100% clear from the draft is that whether there is any padding in the encrypted payload. RFC4306 says that encrypted part is padded up to the block size of the cipher. In AES-CTR the block size is 1, thus that does not require any padding. Normal ESP requires padding for at least up to 4-byte boundary, regardless of the block size of the cipher, thus even AES-CTR uses padding up to 4-byte boundary. The IKEv2 SA does not require thus. I think it would be better to add text explictly saying this. I.e. add text like this to the end of 2.3: ... For this reason, AES-CTR does not require the plaintext to be padded to a multiple of the block size. For Encrypted Payload this means that Padding field is always empty, and Pad Length field will always be 0. I don't agree with this. Specifying Padding field to be empty and Pad Length to be zero here is not proper, because rfc4306 requires that recipient MUST accept any lenght that results in proper alignment (section 3.14). Yes, it MUST accept, and it says SHOULD set Pad Length to minimum value, which in this case is zero. I think it is important to note that no padding is required, thus Pad Length field can be zero, and if the SHOULD in the RFC4306 is followed it will be zero. As this is different from the ESP, I think it is important to note this difference. In ESP the padding length MUST be selected so that provides 4-byte alignment for the encrypted data, but for IKEv2 there is no such requirement, and this should be even more explictly mentioned in the draft. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Comments on draft-ietf-ipsecme-esp-null-heuristics-00
Yaron Sheffer writes: - Sec. 5. In the definition of IPsec flows, how is this done for (typically tunnel mode) UDP-encapsulated ESP? Are port numbers part of the flow definition? This text belongs either here or in Sec. 8. Adding port numbers as part of the flow table might make some extra flows in case the NAT box is rebooted and port numbers change, but it is also safer assumption to do, as in case there is multiple clients behind the same NAT box talking to the same SGW, the port numbers is the only thing that differentiates those clients from each other. I added text to section 8 saying Each unique port pair makes separate IPsec flow, i.e. UDP encapsulated IPsec flows are identified by the source and destination IP, source and destination port number and SPI number. - 5. Unsure - if we choose the option of dropping such packets, are there cases when retransmitted packets do not add any information and we will remain forever unsure? It depends. If the packet is really encrypted ESP, then no, as each retransmission will have different IV, which means every packet will completely different, and that will make the heuristics to find out that flow is not ESP-NULL (i.e. Self describing padding checks will fail). If packet is ESP-NULL packet and is about known protocol (TCP/UDP) then simple checks given in the pseudocode work, i.e. we check that the source and destination port numbers are same for the retransmitted packet, and each of those will add some bits to the Check_Bits value, and when it reaches the threshold set in the policy the flow is recognized as ESP-NULL with given parameters. The problem case is that if only packets sent by the flow are of some unknown protocol, then heuristics cannot determine whether any of the fields in the protocol data are correct, thus it cannot determine the IV length. Even in this case the flow can be recognized as ESP-NULL packet with known ICV length, but unknow IV length if we get consistent next header fields in retrasmitted packets (as described at the end of section 9.2). - 6, first paragraph. in to - into Fixed. - 6. This section seems to discuss the construction of an ESP-null detection engine out of an off-the-shelf DPI engine. If this is the case, please say so. The section describes relationship between the deep inspection engine and the heuristics, it is not necessarely related to the existing or off-the-shelf DPI engines. - 9.1. 160, 192, and 256 bit algorithms are used - 160, 192, and 256 field lengths are used Fixed. - 9.1. Payload Data is starred for some reason, probably cut-and-paste. Fixed. - 10. The Security Considerations needs to have an explanation of what this is good for, i.e. what security policy is enforced, what kind of DPI is done. Also, (malicious) traffic can be encrypted in multiple ways, e.g. simply by using TLS on top of TCP. One of the problems with using ESP-NULL is that I myself do not think there is really any good uses for it. The attackers can bypass it so easily by using encryption that I do not really know what kind of security policies can be enforced with it (unless you use disallow encrypted ESP compeltely, in which case heuristics come trivial). This is the main reason I do not see that WESP or heuristics will ever really get widely used anywhere. My reason for heuristics is that for those who want this kind of thing and who can explain themselves why they want it can implement them without messing up the IPsec implementations :-) The security considerations section already says that The whole deep inspection for ESP-NULL flows only has the problem that attacker can always bypass it by using encrypted ESP instead of ESP-NULL unless that is not forbidden by policy. Changed that now to be: The whole deep inspection for ESP-NULL flows only has the problem that attacker can always bypass it by using encrypted ESP (or some other encryption or tunneling method) instead of ESP-NULL unless that is not forbidden by policy. so that should cover TLS over TCP, or IP over DNS etc style bypassing methods... In addition, we need to note the DOS potential of the ESP-null detection process. Do we really? I think it is clear that any protocol can have bugs and implementation issues, but we do not list that in every single security considerations section (i.e. IKEv2 or AH or ESP). The DoS potential of the ESP-null detection is not any different than DoS potential of the IKEv2 implementation or ESP itself. - Pseudocode: are we assuming one protocol per SPI? No. There can be multiple protocols going through the same SA. In some cases it is more efficient if multiple TCP packets are sent during detection process, but it works even if they come mixed in any way (i.e. when it checks if the last packet received had same TCP/UDP source/destination ports etc that is more efficient if the last packet really was part of same TCP/UDP flow than this current packet, but that is not required for correct
Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP
Scott C Moonen writes: Tero, I am not comfortable with the following statement: . . . thus it will send back traffic selectors having IPN1 and IP2 as their IP addresses . . . I would prefer that the server re-map the TS values back to IP1 and IPN2 when sending its response. This is not possible, as the other end needs to know the address if IPN1 and IP2 (those are not known to him otherwise). Those addresses are used as original source and destination addresses for incremental checksum fixup. This is consistent with the general expectation that the response's TS payloads are a subset of the request's payloads. Yes, but then we still would have problem that we do not get the original addresses from anywhere. Currently IKEv2 says they are taken from the traffic selectors, but if we do not send IPN1 and IP2 back from responder to initiator, initiator does not get them anywhere. The client does not absolutely need this information (it would perhaps help for deterministic checksum fixup, however in transport mode as long as an integrity algorithm is used the checksum provides no additional value anyway). RFC3948 do want them to do incremental checksum fixup, and one of the reasons we want to modify this text is to provide that information. I think it is also advantageous to contain this fixup processing to one code path (processing TS payloads in received requests), and it also simplifies the response message processing (the client does not need to complicate its checks to verify that the response's TS payloads are a subset of the request's). This separation of responsibility is more advantageous to a client implementation that needs to be as minimal as possible. Yes, it might make it bit more simplier, but would loose functionality that is supposed to be there. The initiators processing of the responders reply is quite simple anyways, i.e. check if USE_TRASPORT_MODE was returned (i.e. transport mode was selected), and if so store traffic selectors as original addresses, and replace them similarly as is done in other cases. Then normal processing can continue without any changes (i.e. traffic selector verification, IPsec SA installing etc). Finally, what I propose above is how our own IKEv1 implementation works in cases where ID payloads are sent for transport mode. :) As a responder we found it best to bend over backwards to cater to the initiator's view of the world. In IKEv1 there is separate payloads for sending the original addresses. In IKEv2 we do not have that, thus we must use traffic selectors for that. I'm also concerned about the following statement: After this it does SPD lookup based on those new traffic selectors. . . . If entry is found but it does not allow transport mode, then MUST undo the address substitution and redo the SPD lookup using the original traffic selectors. . . . This statement is incoherent to me. From the fact that the initiator proposed transport mode, it is clear that the initiator identifies TSi with itself and TSr with the server. No. As USE_TRASPORT_MODE is only hint in IKEv2. Responder has full choice of ignoring it and using tunnel mode instead. TSi and TSr do NOT identify initiator at all, initiator is already identified by the ID payloads. TSi and TSr are used to select suitable SPD entry for the given identified initiator. As for transport-mode NAT-T case the original TSi and TSr can be quite unknown for the responder, we first try with the converted addresses, but if we need to fall back to tunnel-mode NAT-T, then we want to keep original traffic selectors as now the packets exiting from the tunnel will have those addresses (i.e. packets coming from the tunnel will have IP1 and IPN2 as their source and destination addresses, as NAT in the middle does not substitute them). The address substitution exactly translates these addresses into the domain of the responder's SPD. If the responder's policy indicates that transport mode is not acceptable for this SPD entry, then I think the only possible outcome is that SA negotiation should be failed. No other SPD entry could possibly match the initiator's intentions. Initiator asked that if possible use transport mode with these addresses, if transport mode is not possible then use tunnel mode. Even if transport mode was not allowed, it is possible that responder do have tunnel mode rule that is allowed for that client even when transport mode was not. I do not see how you can claim that No other SPD entry could not be found, as initiator only gave hint that it would like to use transport mode. The use of tunnel vs transport mode is fully based on the responders policy. However, the MUST quoted above causes the responder to treat these addresses in an incoherent way: 1) The responder has detected a NAT in front of the initiator, so treating IP1 as being within the domain of the
[IPsec] Issue #26: Missing treatment of error cases
Yoav Nir writes: Following is our suggested new text. Please let us know what you think. Also, please take a look at the description of AUTHENTICATION_FAILED in section 3.10.1. response to an IKE_AUTH message means either an IKE_AUTH response to an IKE_AUTH request, or an INFORMATIONAL request that describes an error in the IKE_AUTH response. Do you think this phrasing is clear enough? Yes, altought I think most of the implementations do not bother sending INFORMATIONAL requests when IKE_AUTH response has errors. I think most implementations will then simply remove the IKE SA as failed without any further communications to the other end (I do not know any implementation sending that kind of INFORMATIONAL requests, but I expect that almost all implementations will act correctly if someone happen to send them (i.e. they will delete the IKE SA as failed and send empty reply back)). All errors that occur in an IKE_AUTH exchange, causing the authentication to fail for whatever reason (invalid shared secret, unrecognized ID, untrusted certificate issuer, revoked or expired certificate, etc.) MUST result in an AUTHENTICATION_FAILED notification. This MUST there is too strong, especially for the unrecognized ID part. For example our implementation send AUTHENTICATION_FAILED return only if processing of AUTH Payload faiiled (i.e. signature check failed (for RSA/DSA), mac failed for shared keys authentication, or no valid public key / shared key found for the ID). In cases where the other end is unknown (i.e. ID is not configured to the policy) it will return NO_PROPOSAL_CHOSEN as it does not find valid policy to accept the other ends proposal when looking it based on the ID. So at least remove the unrecognized ID from the list, as it does not belong there, and change the MUST to SHOULD as specifying exactly one error code in such situations will make lots of implementations non-conforming. I know that people writing conformance tests are going to test this kind of things, and I have already several times explained them that the exact error codes returned by different implementations can differ depending what checks they do and in which order. If the error occurred on the responder, the notification MUST be returned in the protected response, and MUST be the only payload in that response. Again the two MUSTs there will make some implementations non-conforming. We had discussion about this earlier, and in general it is good idea to send them encrypted and MACed, but as that was not required before this is real protocol change. For such I think it requires more explantion. Also I want to have warning here saying that even if it is encrypted and MACed, that does not mean it is authentic from the real recipient. It is coming from the recipient you talked to, but if there is man-in-the-middle he can also generate such messages, meaning the initiator should still continue trying with this peer (he can immediately delete the current IKE SA exchange, as it cannot succeed after this, but next try might get to the real end node instead of man-in-the-middle and succeed). If the error occurs on the initiator, the notification MUST be returned in a separate INFORMATIONAL exchange, with no other payloads. This MUST there is way too strong, as there is no implementations I know that implements that. For example our implementation simply consides the IKE SA failed in such case and removes the IKE SA, and then when next triggering packet comes it will try again. I would say MAY would be correct in this case. Note, however, that messages that contain an unsupported critical payload, or that are otherwise malformed, MUST be rejected in their entirety, and only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification. The receiver MUST NOT verify the payloads related to authentication in this case. This MUST NOT is again too strong, as in some implementations they might process payloads in order and depending how deep in which place, they might for example process AUTH payload before noticing that the SA payload of the IPsec SA is malformed in its transform substructure. This MOST NOT would make such implementations non-conforming, meaning every single implementation must do full parsing of the payloads first and only after that do second phase when it processes the payloads. If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established, provided that there are no unsupported critical payloads. The provide that there are no unsupported critical payloads is not really needed, as the first part asked to check those first, thus authentication cannot succeed (it is not even tried) if there is unsupported critical payload. Even if we allow parsing AUTH payloads before checking all critical bits, then I do not think that text is needed, it just confuses people. This next text
[IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets
naoyoshi ueda writes: According to ikev2bis-04 section 2.1: A retransmission from the initiator MUST be bitwise identical to the original request. That is, everything starting from the IKE Header (the IKE SA Initiator's SPI onwards) must be bitwise identical; items before it (such as the IP and UDP headers, and the zero non-ESP marker) do not have to be identical. So, IV of retransmitted request must be the same as that of original request. Yes. Meanwhile, ikev2bis-04 section 3.14 says o Initialization Vector - For CBC mode ciphers, the length of the initialization vector (IV) is equal to the block length of the underlying encryption algorithm. Senders MUST select a new unpredictable IV for every message; recipients MUST accept any value. Question 1: Does the statement recipients MUST accept any value. stay true even if retransmitted IV differs from that of original request? Most likely, but it does not matter as the packet will fail window check, thus will be considered as retransmission or old packet, and thrown away (it might trigger retransmission of responders reply in case it was packet in the window). Note, that this can only happen if the other is non-conforming, or there is attacker between which modifies the IV. Conforming implementation will use same IV all time. Question 2: If the answer to Question 1 is no, what should the recipient do? Just ignore it? Abandon the IKE_SA? Or send some Notify? If recipient has already seen the message before (i.e it has already processed it), it can resend its reply. It can also notice that the packet is not bitwise-same as previously and the message id is old, and silently ignore it. So this is implementation depended what will happen. If it has not seen the message before, then it does not know the IV has changed, thus will process the packet normally. Question 3: How about IV of retransmitted RESPONSE? Does it need to be identical to the original one too? The retransmitted response should also be bitwise identical to original one. It seems to me that the following statement in section 2.1 implicitly requires that. But I'm not sure. I would agree you that it implicitly requires that. Actually, I'm now involved in a IKEv2 implementation that sends retransmitted response with different IV from original one and I cannot tell if the behavior is allowed or not. I would say it is not allowed, but on the other hand, the other end should not ever notice this, as it only process one of the responses (the first to reach him), and then ignores rest even before decrypting them (when it checks its message id). I.e. it ignores further responses to requests it has already received response. ikev2bis-04 section 2.1: The responder MUST remember each response until it receives a request whose sequence number is larger than or equal to the sequence number in the response plus its window size (see Section 2.3). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Yoav Nir writes: Yes, altought I think most of the implementations do not bother sending INFORMATIONAL requests when IKE_AUTH response has errors. I think most implementations will then simply remove the IKE SA as failed without any further communications to the other end But wouldn't this cause a state de-synchronization? Yes, but not in normal case. If the responder sends a revoked certificate, the initiator will have no IKE SA, but the responder would have an IKE SA, which it thinks is valid. Wouldn't this necessarily later lead to requests that time out? Then the responder is already going against the RFC4306 which says Certificate revocation checking must be considered during the chaining process used to select a certificate. meaning the responder cannot send certifiate which itself considers revoced. Only case when this can happen is when responder thinks he has valid certificate but initiator then checks it against certificate authority's system (for example OCSP) and finds out it is not valid anymore. This is not common case, thus it can lead to timeouts. In cases where the other end is unknown (i.e. ID is not configured to the policy) it will return NO_PROPOSAL_CHOSEN as it does not find valid policy to accept the other ends proposal when looking it based on the ID. That allows for ID enumeration. It's similar to a password entry form, that says wrong user or wrong password. An attacker would be able to verify whether a particular ID (say, user name) exists on a system. If the other ends source IP-address is not configured to system (and no wildcard entry found) then it will always return NO_PROPOSAL_CHOSEN regardless of the ID or AUTH payloads. Anyways active attacker can always find out the used IDs anyways. Also from timing it is easy to see whether other end actually did only database lookup for the ID, or whether he actually verified the RSA signature. If you consider ID enumeration a problem that needs to be added to the Security Considerations section (regardless whether we return AUTHENTICATION_FAILED or NO_PROPOSAL_CHOSEN in this case). This MOST NOT would make such implementations non-conforming, meaning every single implementation must do full parsing of the payloads first and only after that do second phase when it processes the payloads. How about if we limit this to packets that are malformed in their entirety, rather than some particular payload (and packets that have unrecognized critical payloads) ? If you say MUST in any of these error cases you need to be very specific which cases are covered, most likely giving similar pseudo code saying you first check this, and if it fails, return this error code, then you check this and so on... Similar than RFC2408 Section 5 did, but even then you most likely get implementations which do things differently because they just happen to use some external library or other thing that does parts of the checks in different order than what is listed in the RFC. I have been explaining this to several customers when they have run some external tester which required specific error code to be reported in specific case, and we returned some other error code because we checked things in different order. Thats why it is bad idea to specify MUSTs (or even SHOULDs) when taking which error to return. It is ok to say this check MUST be done (especially if it is security related), but there is no point of listing the order or specific error codes in all possible places. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] CRL checking when selecting a certifcate
David Wierbowski writes: Tero, thanks for the comments and the clarification on how to read a lower case must. I do have a few more comments. So implementations cannot just search uppercase MUST/SHOULD/MAY texts and assume it is enough to make sure those are correct. It also needs to do what the text says... I think most implementers focus on the MUST and SHOULDs and then apply common sense to the remaining text. I agree. I have done that myself too, and only noticed that this does not really help when the latest version of ikev2bis had following change (this is unrelated to current case, but it is more generic case): Old text: -- The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the new SA, or (2) the new SA rekeys an existing SA and it receives an IKE request to close the replaced SA. When rekeying an SA, the responder SHOULD continue to send messages on the old SA until one of those events occurs. -- New text: -- The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the new SA, or (2) the new SA rekeys an existing SA and it receives an IKE request to close the replaced SA. When rekeying an SA, the responder continues to send traffic on the old SA until one of those events occurs. -- Earlier we knew that we didn't follow that SHOULD exactly, as we moved to use new SA either if old one was deleted or after short timeout. We knew this was against the SHOULD and changing it was on our todo list. Now the new text does not say SHOULD anymore (it was removed, not lowercased), it just says you continue to send traffic on the old SA so effectually now it is MUST as it says you do that, you are not allowed to do anything else. So when the text removed SHOULD it actually made the required behavior much stricter, and made our old implementations so they do not follow the given behavior (as this was in our todo list, we have already changed the code). This is more generic thing than just CRLs (or rekey behavior), i.e. what does non-lowercase do this statement in the RFC really mean. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Ikev2 HA message Id Issue
pasi.ero...@nokia.com writes: If dpd is enabled then ikev2 counters keep updated frequently. This depends on how often you do DPD... Obviously, you want dead IKE_SAs to go away eventually, but e.g. 30 minute DPD interval would be sufficient for that. If your DPD interval was close to the value of N, that would not work well... but on the other hand, if you have lot of traffic going back and forth, IKEv2 DPD won't get triggered.. You should not really have fixed timer for DPD. You should base your DPD interval depending on the other things, i.e. if there is ESP traffic coming from the other end to your site, there is no point of doing DPD based on timer unless something else says otherwise. If you start suspecting there might be something wrong with IKEv2 SA (i.e. you receive ICMP or network goes down and comes up again etc), then you might trigger DPD once to see if the other end is still there. If you only trigger timer based DPD when there is no ESP traffic at all (i.e. the both IKEv2 SA and IPsec SA are completely idle) then there is no point of trying to use too short DPD timers as the SA is idle anyways, and in such cases you do not need very fast recovery from other ends crashes... Only case where you might need more frequent timer based DPD is when your traffic is unidirectional, i.e. you are sending ESP traffic to other end but other end is not sending anything back. As this is not a common case in normal operation, that is good indication there might be something wrong and in such cases you should trigger DPD to verify it the other end is up. In general I consider syncing HA boxes after each IKEv2 Message (or once per second etc) not too big problem. HA boxes are usually directly connected with fast network cable (usually at least as fast as their traffic in), and every single IKEv2 message requires some cryptographic operations anyways, and is bigger than what it would be to send short cleartext message to other HA telling I finished processing my request message id XXX at IKE SA YYY or I finished processing my reply to message id XXX at IKE SA YYY and packet sent was ZZZ (you need to sync the reply packet data you sent to other end just in case the packet was lost and other end didn't get it, so you can retransmit it from HA pair). In any case you will loose all IKE SA which are in the middle of exchanges when one of the devices goes down, as syncing intermediate state from one device to other would be way too complex. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Keith Welter writes: I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted either. I do consider INVALID_SYNTAX fatal error, meaning the IKE SA will be deleted immediately after sending that response containing INVALID_SYNTAX and if I receive INVALID_SYNTAX notification I will immediately silently delete the IKE SA. INVALID_SYNTAX can only happen in if there bugs in implementations. There is no way it could happen during normal operation, and it is also error which does NOT go way. I.e. if other end has bug that it sends payload whose for example payload length exceeds the packet length, that error will not go away even if we ignore the exchange. Usually receiving INVALID_SYNTAX means there is something seriously wrong in the either implementation, and there is no point of trying to continue connection with it, as future attemtps to communicate will most likely result in same error (or at least cause peers to get out of sync (for example if delete payload had incorrect length and was ignored, then peers do not agree on which SAs are up after that)). As this is only error code that can be fixed by the programmers fixing bugs in implementations, there is no point of writing code to cope with such cases. If such code is written it is most likely be completely untested, thus it most likely have even more bugs (in worst case it can have security bugs), thus it is better to take the simple and easy solution instead, and simply delete the IKE SA immediately. As this cannot ever happen with conforming implementations there is no need for conforming implementations to agree on what they do on this error... If this error is ever seen that means either implementation is not conforming the specification. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fw: Issue #26: Missing treatment of error cases
Keith Welter writes: In this case, the INVALID_SYNTAX could relate to the SA, TSi or TSr payload in the IKE_AUTH response which would would mean that creation of the CHILD SA failed, not the IKE SA. I think INVALID_SYNTAX is ambiguous here without an explicit delete payload for either the IKE SA or the CHILD SA. For normal errors in the SA payload there is NO_PROPOSAL_CHOSEN error and for TSi and TSr there is TS_UNACCEPTABLE error. If INVALID_SYNTAX is generated from for example SA payload because the payload lengths inside the SA / Proposal / Transform payload substructure is wrong (or there is other payload type inside SA payload than what is allowed) then that again means the one end is broken and there is no point of continuing creating the IKE SA as most likely all future exchanges will fail in similar way. It is clear for me that if INVALID_SYNTAX is ever returned to IKE_AUTH exchange, that means the IKE SA was not successfully created (as we do now know whether the other end for example verified the AUTH payload). In that case when IKE SA was not created there is no IKE SA to send delete payload to. If INVALID_SYNTAX is returned after that as response to INFORMATIONAL or CREATE_CHILD exchange, then it is not clear whether other deleted the SA or not, but as I said earlier that can only happen if there is bugs in implementations, so better to cut the discussion short to limit attack options. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Yoav Nir writes: OK. Let's try this again. Is this acceptable? 2.21. Error Handling There are many kinds of errors that can occur during IKE processing. If a request is received that is badly formatted, or unacceptable for reasons of policy (e.g., no matching cryptographic algorithms), the response MUST contain a Notify payload indicating the error. If an error occurs in the processing of a response, then the initiator SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. I think MAY is better than SHOULD there, or even forbidding this completely. As said before I do not know any implementation which does this now, and there is also problem that there is no way to correlate the INFORMATIONAL exchange to the exchange which caused this problem. I.e. if you have window size 5, and you have 3 CREATE_CHILD_SA exchanges going, and then you get response to second of them that is invalid and you send INFORMATIONAL exchange out saying there was something wrong with the response, then there is no way for the other end to know to which of those exchanges that INFORMATIONAL related. Also I do not know any normal cases where it would be useful to send error message to the response. In some cases it may possible that initiator will process the response packet, and notice there is something wrong and do actions. One of the cases is for example when initiator asked for transport mode, but responder selected tunnel mode and initiator's policy does not allow tunnel mode. In this example the current RFC4306 text already says initiator deletes the SA. Can you give me any example when it would be possible to use this feature? Note, that this is new requirement that was not in the RFC4306. Note, that this also goes against the rule that no response never generates new requests (it is not explictly mentioned in the IKEv2, but is still there). This means that if either end has bug that cases for example the response packet of the INFORMATIONAL exchange causes other end to send error notification to the other end (using same broken INFORMATIONAL exchange) then the peers will go to INFORMATIONAL exchange loop. Because of the looping problem, and the problem there is no way to relate new INFORMATIONAL exchange request to the response which triggered it, I would actually suggest we forbid this situation and say that errors in response must be handled otherwise (most likely by deleting the IPsec SA or IKE SA or simply ignoring the error case (if it does not affect the state of the SAs)). All errors that occur in an IKE_AUTH exchange, causing the authentication to fail for whatever reason (invalid shared secret, invalid ID, untrusted certificate issuer, revoked or expired certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED notification. If the error occurred on the responder, the notification is returned in the protected response, and should be the only payload in that response. When we discussed about the ticket #9 Pasi proposed a text that explains this case better, i.e. specifying that the although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet, the information needs to be treated with caution. http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html This was supposed to be added to section 1.2, but it is not there. Perhaps we should add it here instead of 1.2 then (or at least add it to 1.2 if not here). If the error occurs on the initiator, the notification MAY be returned in a separate INFORMATIONAL exchange, usually with no other payloads. Here creating new INFORMATIONAL exchanges based on the errors in response may be allowed as there is no problems with correlating the message (no other exchanges is allowed before IKE_AUTH finishes), and there should not problems with loops, as the error notification was related to the IKE_AUTH not generic stuff. Also if there was problem when processing IKE_AUTH response, I would indicate that then the IKE_AUTH didn't finishs, thus we do not have IKE SA. If the problem was only in the Chid / IPsec SA part of the exchange then that can be fixed by deleting the IPsec SA. Note, however, that messages that contain an unsupported critical payload, or where the whole message is malformed (rather than just bad payload contents), MUST be rejected in their entirety, and only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification. The receiver should not verify the payloads related to authentication in this case. If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established, but establishing the child SA, or requesting configuration information may still fail. This failure does not automatically cause the IKE SA to be deleted. Specifically, a
Re: [IPsec] Issue #26: Missing treatment of error cases
Yoav Nir writes: I wish that were true, but here's what the draft says about INVALID_SYNTAX INVALID_SYNTAX7 Indicates the IKE message that was received was invalid because some type, length, or value was out of range or because the request was rejected for policy reasons. To avoid a denial of service attack using forged messages, this status may only be returned for and in an encrypted packet if the message ID and cryptographic checksum were valid. This or because the request was rejected for policy reasons means that even perfectly good implementations might get an INVALID_SYNTAX. I don't know why this is so, but that's the way it is in RFC 4306 as well. I do not think it should be sent because of policy reasons, as we do have specific errors (authentication failed, no proposal chosen and ts unacceptable etc). I have not seen anybody sending this because of policy reasons, only case where I have seen this was in interops when someone send some broken packets to other end. I think we should remove the for policy reasons part and specify that this is only used in protocol error situations. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Yoav Nir writes: I think MAY is better than SHOULD there, or even forbidding this completely. As said before I do not know any implementation which does this now, and there is also problem that there is no way to correlate the INFORMATIONAL exchange to the exchange which caused this problem. I.e. if you have window size 5, and you have 3 CREATE_CHILD_SA exchanges going, and then you get response to second of them that is invalid and you send INFORMATIONAL exchange out saying there was something wrong with the response, then there is no way for the other end to know to which of those exchanges that INFORMATIONAL related. Agreed. How about SHOULD, but adding if the error occurred in the response to an IKE_AUTH exchange, and in payloads related to authentication. A new exchange SHOULD NOT be triggered for reporting errors in child SAs, CFG, or notifications. If that error occurred during IKE_AUTH because of authentication failure or INVALID_SYNTAX or similar then there is no way to start new INFORMATIONAL exchange as for the initiators part the IKE SA wasn't finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on. So only place where IKE_AUTH could fail so that you have IKE SA but you would want to send notification back is that there was something wrong with the configuration payload or Child SA processing. If there is something wrong with Child SA processing, then correct way is not to install the SA, and send delete for the Child SA. If there was something wrong with the configuration payload processing, then depending on the situation you might want to delete the IKE SA (if you didn't get the IP-address at all or similar) or just ignore the error. I really DO NOT like the idea of triggering new exchanges based on the failures when parsing the response. In general IKEv2 has been written so there cannot really be errors on the responder (i.e. traffic selectors are narrowed based on the initiators proposal, so responder cannot select something that is not allowed by initiator, and same is for SAs proposals etc). Can you give me example where this would be used? I.e. situation where IKE_AUTH response packet caused error which needs to be communicated to the other end and which is not related to IKE SA authentication. I think that any of these would be fatal to the particular exchange, but will not cause a silent discard of the IKE SA. You might have a policy that tells you to delete any IKE SA where you got or sent an INVALID_SYNTAX, but because it can also be a policy matter, we shouldn't really mandate it. Our implementation will silently delete IKE SA (i.e do not send DELETE notification as if state is so messed up that you get INVALID_SYNTAX errors, then DELETE notification will mostly generate same response) when it receives INVALID_SYNTAX or after it has sent out INVALID_SYNTAX as it assumes there is something badly wrong with either implementation and there is no point of continuing at that situation. I do not have any plans of changing that, and I think other implementations do something similar (i.e if you start sending them properly encrypted and authenticated random garbage they will tear down the IKE SA). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
David Wierbowski writes: You are sending an informational notification, so how could you say the SA does not exist and no delete should be sent? The IKE SA is NOT up and valid in the initiator. It is halfway up as the other end has not been authenticated, and that IKE SA cannot be used in general. If an authentication error is discovered when processing the IKE_AUTH response then responder thinks an IKE SA exists and the initiator intends to delete that SA. In this case it seems clean for the initiator to send an INFORMATIONAL exchange containing AUTHENTICATION_FAILED and treating the SA as being deleted. I do not see the harm in including a DELETE in this case and it seems to be a more appropriate action than sending the AUTHENTICATION_FAILED. I'm fine with not requiring the DELETE, but I don't think including the DELETE is bad and should be discouraged. I think it reinforces the initiator's intentions and is unambiguous. If you use that kind of halfway up IKE SA for sending INFORMATIONAL message to other end (who thinks the IKE SA is up and valid), then I agree that sending both N(AUTHENTICATION_FAILED) and DELETE would be the correct way to do it. DELETE only would also be ok. Sending only N(AUTHENTICATION_FAILED) would be bit ambiquous, and I would not recommend that, but as initiator still do not have IKE SA up but has only halfway up SA, for initiator it does not matter what other end does for the INFORMATIONAL exchange anyways... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Scott C Moonen writes: Tero, Agreed. How about SHOULD, but adding if the error occurred in the response to an IKE_AUTH exchange, and in payloads related to authentication. A new exchange SHOULD NOT be triggered for reporting errors in child SAs, CFG, or notifications. If that error occurred during IKE_AUTH because of authentication failure or INVALID_SYNTAX or similar then there is no way to start new INFORMATIONAL exchange as for the initiators part the IKE SA wasn't finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on. We've already bent this rule a little bit if the responder detects an authentication failure. I.e., we've documented that the responder should encryptMAC his N(AUTHENTICATION_FAILED) response even though from his perspective he doesn't have a valid IKE SA. True, but that does not mean the IKE SA is valid, it just means they do have shared unauthenticated keys for encryption and MAC. I.e that encrypt MAC proves that the reply comes back from the same server who did Diffie-Hellman, but it does not mean it came back from the correct intended responder. The reply could be generated also by man in the middle. It seems reasonable to do something similar in this case. I.e., if the initiator detects an authentication failure (say, the responder's certificate has expired), it is reasonable for him to 1) send a protected INFORMATIONAL request over the unauthenticated SA with the error notify, and 2) disallow any other possible activity on that invalid SA except for retransmitting the request and waiting on the response. That adds quite of lot of special code (i.e you need to make sure that IKE SA is not used for anything else while you are waiting for reply), and does not really help that much. This will cause server to clean up the IKE SA faster than it normally would, but as client initiated this there is most likely no data coming from the server to client anyways thus no traffic is really lost. The client will still fail the IKE SA and as client was the one who initiated it, it will most likely try again and the user noticing things does not work tries to fix things. This kind of authentication failures usually do not go away without user intervention anyways. From the responders point of view the IKE SA is there, so he does not care which way the initiator does, so this is not something that needs to be defined at all (i.e. there is no need to define whether it is allowed, recommended or forbidden). Whether implementation does this can be completely left to as local matter. In our own case, if this happens as initiator, we will do this, sending a protected INFORMATIONAL request containing both N(AUTHENTICATION_FAILED) and also a DELETE for the IKE SA. In my view the DELETE is actually the more crucial payload here, and the Notify payload is primarily a courtesy to hint to the responder why the delete is being sent (since there is really no way to assert that a Notify in an INFORMATIONAL request relates to some other particular exchange). You are free to do that. It will gain you so that server will delete the IKE SA bit earlier than it would otherwise (i.e. otherwise it would need to wait for the DPD to kick in (which would most likely happen quite soon, as there is completely idle IKE and IPsec SA there) and that would then delete the IKE SA). For the original users point of view (i.e. the initiator / client) this does not matter, as he still cannot get connection... I myself as implementor writing code do not want to add such code to our product as it is just adding code that is very seldomly run and even less seldomly tested, and which can contain security bugs, thus the product is safer and better without such code. But this is just my own opinion, and other implementors might have different opinions, and I am ok with text which says you MAY do it. I would object against SHOULD, and object very strongly against MUST. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Yoav Nir writes: OK. One more try: I think this is still bit confusing. How about splitting it to few subsections, i.e. 2.21. Error Handling 2.21.1 Error Handling in IKE_SA_INIT 2.21.2 Error Handling in IKE_AUTH 2.21.3 Error Handling after IKE SA is Authenticated 2.21.4 Error Handling Outside IKE SA or something. Now you need to be very careful when reading the text to understand when it is taking about IKE_AUTH or some other exchange and whether it is talking about errors in request and replies. For example the text could look something like this: -- 2.21. Error Handling There are many kinds of errors that can occur during IKE processing. The general rule is that if a request is received that is badly formatted, or unacceptable for reasons of policy (e.g., no matching cryptographic algorithms), the response contains a Notify payload indicating the error. Whether to send such response depends whether the there is authenticated IKE SA or not. If there is an error parsing or processing response packet, then generic rule is not to send any error back, as responses should not generate new requests (which would be the only way to send error message back). Such errors in parsing or processing response packets should still take care to clean up the state (for example, by sending DELETEs for bad SAs). Only authentication failures (AUTHENTICATION_FAILED) and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without requiring an explicit INFORMATIONAL exchange carrying a DELETE payload. Other error conditions require such an exchange, if policy dictates that this is needed. 2.21.1 Error Handling in IKE_SA_INIT Errors that occur before a cryptographically protected IKE SA is established must be handled very carefully. There is a trade-off between wanting to be helpful in diagnosing a problem and responding to it and wanting to avoid being a dupe in a denial of service attack based on forged messages. In an IKE_SA_INIT exchange, any error notification causes the exchange to fail, although some, like COOKIE, INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent successful exchange. Note, as all error notifications are completely unauthenticated, the recipient should not immediately act based on them (unless corrective actions are known like COOKIE, INVALID_KE_PAYLOAD etc), but continue trying for some time before giving up. 2.21.2 Error Handling in IKE_AUTH All errors that occur in an IKE_AUTH exchange, causing the authentication to fail for whatever reason (invalid shared secret, invalid ID, untrusted certificate issuer, revoked or expired certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED notification. If the error occurred on the responder, the notification is returned in the protected response, and is usually the only payload in that response. Note, that although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet, the information needs to be treated with caution. If the error occurs on the initiator, the notification MAY be returned in a separate INFORMATIONAL exchange, usually with no other payloads. This is exception for the general rule of not starting new exchanges based on errors in responses. Note, however, that request messages that contain an unsupported critical payload, or where the whole message is malformed (rather than just bad payload contents), MUST be rejected in their entirety, and only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification sent as response. The receiver should not verify the payloads related to authentication in this case. If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established, but establishing the child SA, or requesting configuration information may still fail. This failure does not automatically cause the IKE SA to be deleted. Specifically, a responder may include all the payloads associated with authentication (IDr, Cert and AUTH) while sending error notifications for the piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, NO_PROPOSAL_CHOSEN, etc.), and the initiator MUST NOT fail the authentication because of this. The initiator MAY, of course, for reasons of policy later delete such an IKE SA. In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately following it (in case error happened in when processing response to IKE_AUTH), only the following notifications cause the IKE SA to be deleted or not created, without a DELETE payload: o UNSUPPORTED_CRITICAL_PAYLOAD o INVALID_SYNTAX o AUTHENTICATION_FAILED Extension
[IPsec] Comments on draft-ietf-ipsecme-roadmap-03
Yaron Sheffer writes: - I would have liked to see ESP BEET mode referenced, since it's more widely implemented than other docs that we do mention. But as far as I know it is not on track to becoming an RFC. I agree on that, and I think it might also be good to mention other very widely implemented (expired) drafts which will never come out as RFCs, namely IKEv1 configuration mode (draft-dukes-ike-mode-cfg-02) and IKEv1 xauth (draft-beaulieu-ike-xauth-02). - 4.1.1: if RFC 2409 is N/A for IPsec-v3, how come RFC 4304 defines the use of ESN in IKEv1? But you can't expect a Roadmap document to resolve all issues. As RFC4303 says ESP does not have version number, thus version is only known by the signaling methods or out of band configuration. Use of IKEv2 automatically implies ESP-v3. If IKEv1 is used then that would imply ESP-v2, but RFC4304 explictly defines method of negotiating ESP-v3 feature in IKEv1, thus if that feature is used, then ESP-v3 is also assumed. That is at least my interpretation of the situation... Of course everybody should stop using already obsoleted IKEv1 protocol :-) - 7.5: I would describe the history differently (I was there...). IPSRA attempted to tack user authentication onto IKEv1 with no change to IKE. This indeed proved cumbersome, and the result was the brand new IKEv2, which in fact adopted some of the IPSRA ideas, primarily the use of EAP. Agree... - Table 1: There is nothing that limits the Heuristics draft to ipsec-v3. In facts legacy devices are a major reason for publishing these heuristics. True, altough in IPsec-v2 things are bit easier, as there is no combined mode ciphers i.e. no GMAC, thus no need to detect IV. The draft does not limit itself to either version. BTW, the latest draft is draft-ietf-ipsecme-esp-null-heuristics-01.txt not draft-kivinen-ipsecme-esp-null-heuristics. Other comments: -- It would be much easier to read the document if each document would be easier to detect from each other. Now when moving from one document to next is indicated by even more indented bulletpoint text than the actual text it does not provide good visual feedback to search documents. It might be better to change all document headers to sections (and perhaps exclude them from toc (i.e. add toc=exclude to them if using xml to rfc)). -- In section 5.2 covering RFC3686 document says: ... AES-CTR is a stream cipher with a 32-bit random nonce (1/SA) and a 64-bit IV, both of which are sent in the packet along with the encrypted data. The description of the random noise and 64-bit IV is correct, but only the 64-bit IV is sent along the packet. The nonce is provided by the IKE with the keying material. There is also draft-ietf-ipsecme-aes-ctr-ikev2-02 to define how that is used in IKEv2 (and as IKEv2 and ESP-v3 share same iana registry there is already number for it). -- For RFC5529 I do not think we need separate RFC to use Camellia-CBC in IKEv2. It is just normal CBC mode algorithm and the generic rules in RFC4306 covers it. As it also already has IANA number I do not see any reason why it cannot be used in IKEv2 too. For the Camellia-CTR the situation is different as generic RFC4306 text only covers CBC mode ciphers, not counter mode ciphers. Perhaps the draft-ietf-ipsecme-aes-ctr-ikev2-02 should be expanded to include more of the counter mode ciphers (i.e. provide generic rules how counter mode ciphers are used in IKEv2)? For the Camellia-CCM there is the RFC5282 which describes how combined mode ciphers are used in the IKEv2. I think that document along with RFC5529 should be enough to specify how Camellia-CCM is used in IKEv2. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Working Group Last Call: draft-ietf-ipsecme-aes-ctr-ikev2-02.txt
Paul Hoffman writes: Greetings again. This message starts the WG Last Call on draft-ietf-ipsecme-aes-ctr-ikev2-02.txt. Please read the draft and comment on the list whether or not you think it is ready for standardization. We are particularly interested in hearing from implementers who have carefully read the details to be sure they are implementable and seem correct. Of course, we want to hear from everyone as well. When reading the roadmap I noticed that camellia-ctr is also not defined for IKEv2 SAs, so I was wondering if the text in this document could be made generic enough so any counter mode cipher could be used. There is not really anything that much different between different counter mode ciphers, they take IV, which must not be repeated for same key, I think almost all of them also take nonce which is generated when key is generated but not transmitted on the wire and they do not have padding requirements. To be able to use counter mode in IKEv2 SA the implementation needs to know the IV format, transmitted IV length and padding requirements. Usually the RFC specifying the counter mode cipher defines IV format already and also specifies the transmitted IV length, so the required information is there but as the RFC4306 talks only about CBC mode ciphers and says things like the IV is same size as block length of cipher we could not use CTR ciphers in IKEv2. Making part of the draft bit more generic so it can be used to combine any counter mode cipher document and IKEv2 document in a such way that counter mode cipher can also be used to protect IKEv2, would make things easier for the future (i.e. there is no need to create separate RFC for each counter mode cipher). Mostly the information is already there in section 3, but some text might need to talk generic case first and the add text specifically for AES_CTR. For example: Changing: -- 3.1. Initialization Vector(IV) The IV field MUST be eight octets when AES_CTR algorithm is used for encryption. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is NOT used more than once with a given encryption key. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs). -- to -- 3.1. Initialization Vector(IV) The IV field length used for encryption depends on the counter mode algorithm. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is NOT used more than once with a given encryption key. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs). For AES_CTR algorithm IV field MUST be eight octects. -- Other option is of course to include text to ikev2bis which specifies how to use counter mode ciphers when protecting IKEv2 SAs. Currently draft-ietf-ipsecme-ikev2bis-04.txt says: ... Future documents may specify the processing of Encrypted payloads for other types of transforms, such as counter mode encryption and authenticated encryption algorithms. so instead of saying that we could say that [RFC5282] specifies how to use authenticated encryption algorithms with the Encrypted Payload, and [draft-ietf-ipsecme-aes-ctr-ikev2] specifies how to use counter mode encryption algorithms with Encrypted Payload. Future documents may specify the processing of Encrypted payloads for other types of transforms. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility
pasi.ero...@nokia.com writes: - A question: did the WG discuss the pros and cons of integrity protecting the WESP header? (This does make WESP more complex to implement, and currently the WESP header does not contain any data that would benefit from integrity protection in any way.) Thats is actually good question, as all of the data in the WESP header is verified by comparing it to data elsewhere (either in packet (Next Header) or data associated to SA (HdrLen, TrailerLen, flags)) already I do not think if protecting WESP header adds anything. I think that if we don't add it to ICV that could simplify implementations as the ICV calculations would be exactly same as they were before, so converting ESP - WESP would be simple, by just insertting new header and changing protocol number. - Section 2: The bits are defined LSB first, so bit 0 would be the least significant bit of the flags octet. This doesn't match the bit numbering in Figure 2 (where bit 0 is the most significant bit). However, the bit numbers are not really used anywhere, so I would just suggest deleting this sentence. I earlier proposed change that would add those bit numbers to the text, so bit positions would be also given in other place than in the picture. See my earlier message http://www.ietf.org/mail-archive/web/ipsec/current/msg04761.html - Section 2: the text about TrailerLen is a bit unclearly written -- the offset from the end of the packet to the last byte of the payload would be a negative number. I'd suggest phrasing this something like the The number of bytes following the payload data in the packet, in octets: i.e. the total length of TFC Padding (normally not present for unencrypted packets), ESP Trailer (Padding, Pad Length, Next Header), and ESP ICV. TFC Padding cannot be included in the TrailerLen as it can be too large to expressed in 8 bits. Actually reading the description it would indicate that the Padding, Pad Length and Next Header at the end of packet would be included in the TrailerLen, which would mean that even that might not be expressed in 8 bits in octects. I originally only assumed it includes the ICV field length, nothing else. That is the only thing needed by the intermediate device, as it can see pad length and padding from the packet and it can also skip the TFC padding in the same way recipient will do. With the current wording the TrailerLen would be different for each packet depending how many bytes of padding there is, which will mean that final recipient needs to do some extra calculations while verifying its length is correct (i.e it cannot simply compare the TrailerLen to fixed value based on the SA (12 for HMAC-SHA1 etc), but it needs to calculate Pad Length + ICV length + 2 + TFC Padding length and see that it matches the TralerLen. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Populating ID_DER_ASN1_DN
David Wierbowski writes: Thanks for the clarification. The text in 4301 makes sense. What I do not agree with is the text in 4945 that requires implementations MUST be able to perform matching based on a bitwise comparison of the entire DN in ID to its entry in the SPD. I can agree with saying that implementations MUST be able to perform matching of the entire DN in ID to its entry in the SPD. It's the based on a bitwise comparison that I do not agree with. It should be up to the implementation to decide if it wants to do a bitwise match or use normal x.500 DN matching rules. I think one of the reasons the bitwise comparison is there, that some CA products have been known to issue certificates which are invalid by normal processing rules, for example they can use characters that are not allowed for PRINTABLE STRINGS (for example Latin1 characters for names). Depending on your matching engine it might be impossible to get those matching without bitwise comparison. I agree that it being MUST is not needed, it could be MAY or SHOULD. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPSECME Virtual Interim Meeting
Paul Hoffman writes: At 10:03 PM +0300 9/12/09, Yaron Sheffer wrote: The ipsecme WG will have a virtual interim WG meeting in about a month. We will have a conference call on Tuesday September 22, 15:00 GMT (18:00 Israel, 17:00 CET, 11:00 EDT, 8:00 PDT), for 2 hours. We are planning on the same format as the previous time: a VoIP conference bridge and posted slides. Technical details are available here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls We are using the same TeamSpeak server as before, teamspeak.vpnc.org. I have turned on that server now so people can test it before the meeting. If you want to test your TeamSpeak client before the meeting, we will have a short test-run 24 hours before the meeting (that is, the same times as above, but on Monday, September 21). Now it is also good idea to make sure you find and enable the +20db gain / Mic Boost or similar setting of your windows sound card (Usually it is found in the Recording Control - microphone - Advanced - Advanced Controls for Microphone - Other Controls - Mic Boost / +20 DB gain / 1 (Yes sometimes it is just checkbox marked with 1)). If you do not have that activated your voice will be way too weak to be heard. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP
Paul Hoffman writes: Here is the edited text. Please be sure it is still correct. There is the same typo my original text had: tNAT A will then replace the source address of the IKE packet from IP1 to IPN2, and NAT B will replace the destination address of the IKE This should be IPN1. packet from IPN2 to IP2, so when the packet arrives to the server it will still have the exactly same traffic selectors which were sent by the client, but the IP address of the IKE packet has been replaced to IPN1 and IP2./t figureartwork![CDATA[ For the responder, when transport mode is proposed by client: - Store the original traffic selector IP addresses as real source and destination address in case we need to undo address substitution. The IP addresses are also needed for the RFC 3948 incremental checksum fixup in udp encapsulation, not only for undoing the address substitution. - If the client is behind a NAT, substitute the IP address in the TSi entries with the remote address of the IKE SA. - If the server is behind a NAT substitute the IP address in the TSr entries with the local address of the IKE SA. Client and server are ok here, but my original text used other end and this end at least in our implementation our NAT traversal detection does tests that way. I.e. it know whether this end and/or other end is behind nat and knows to enable suitable processing based on that (i.e. sending of RFC3948 keepalives etc). Client and server makes this bit more vpn roadwarrior case centric, compared to using this end and other end. But either one is acceptable here. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] #22 Simultaneous IKE SA rekey text
Paul Hoffman writes: #22 - Add section on simultaneous IKE SA rekey There was no discussion. We will bring this up one more time because it is important, but if there is not more interest and more inclination to review Tero's text, we will write a short note in the document that simultaneous IKE SA rekey is an issue but nothing else. I would propose cut pasting the simultaneous IKE SA rekey issue from the clarifications RFC 4718, and adding some more text: -- X.Y.Z Simultaneous IKE_SA Rekeying Probably the most complex case occurs when both peers try to rekey the IKE_SA at the same time. Basically, the text in Section 2.8 applies to this case, however, it is important to ensure that the CHILD_SAs are inherited by the right IKE_SA. After the CREATE_CHILD_SA exchanges, two new IKE_SAs exist between A and B; the one containing the lowest nonce inherits the CHILD_SAs. The old IKE SA is deleted by the node which created the winning IKE SA. The loosing IKE SA is deleted by the node which created it. The basic case is where both ends notice this is simultaneous rekey, and can delay moving of the CHILD_SAs until they know which one wins. The more complex case happens where there is dropped packets and one end does not detect simultaneous rekey until it has already finished its rekey and moved CHILD_SAs. As the basic case can be processed in similar way as the more complex case, this example here only covers the more complex case. In this case host A and B has IKE SA up and running and both ends decide to rekey it: Host A Host B --- --- send req1: ... Ni1 ... -- -- send req2: ... Ni2 ... -- recv req1 Now if the req2 is dropped for some reason, the Host A does not know there is simultaneous rekey, but host B will know it when it receives the req1. It will process the req1, but it cannot yet move the CHILD_SAs as it does not know the Nr2. It postpones the CHILD_SA moving until the req2/resp2 rekey finishes. It sends resp1 back to the Host A to answer req1 IKE SA rekey: -- send resp1: ... Nr1 ... recv resp1 -- Now the Host A has finished the IKE SA rekey without knowing it was simultaneous rekey. It will move the CHILD_SAs from the old IKE SA to new rekeyed IKE SA A. It MUST NOT immediately delete the old IKE SA, but instead wait for some time to see in case there was simultaneous rekey ongoing or not. When Host B retransmits its req2 the Host A will notice that there was simultaneous rekey going on, and it will send normal reply to that: recv req1 -- send resp2: ... Nr2 ... -- -- recv resp2 After sending that reply that also creates the second IKE SA B in Host A and then Host A can check all the four nonces and see which of them is lowest, and it will then move all the CHILD_SAs to that new IKE SA having lowest nonce unless they were already there (i.e. if the IKE SA A had lowest nonce, Host A has already moved the CHILD_SAs there, if IKE SA B had lowest nonce, host A needs to move CHILD_SAs from the IKE SA A to this IKE SA B, and start timer to delete IKE SA A). When Host B receives the resp2 it knows that simultaneous rekey is finished, and it can check the nonces and move CHILD_SAs from the original IKE SA to either IKE SA A or B depending which had lowest nonce. If it was IKE SA A, the host B needs to start timer to delete IKE SA B. Depending who created the winning rekeyed IKE SA decides who is going to delete the old IKE SA, i.e. the one who created the winning IKE SA also cleans up the old IKE SA. Note, that Host B processing is identical to the basic case where host notices during processing that there is simultaneous rekey ongoing. In case the Host A didn't wait for long enough before start deleting old IKE SA there can be case where host B is still trying to retransmit its req2 in the old IKE SA when it receives the delete to the old IKE SA. In that case it knows that Host A has NOT received any of its requests, thus is unaware that there is simultaneous rekey ongoing, thus it can safely stop retrasnmitting req2, and allow old IKE SA to be deleted, and move all CHILD_SAs to the IKE SA A created by Host A. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Paul Hoffman writes: section anchor='sect-2.21' title='Error Handling' tIf there is an error parsing or processing a response packet, the general rule is to not send bac any error message because responses ^^^ s/bac/back/ should not generate new requests (and a new request would be the only way to send back an error message). Such errors in parsing or processing response packets should still cause the recipient to clean up the IKE state (for example, by sending a DELETE for a bad SA)./t tIn an IKE_SA_INIT exchange, any error notification causes the exchange to fail. Note that some error notifications such as COOKIE, INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent successful exchange. Because all error notifications are completely unauthenticated, the recipient should continue trying for some time before giving up but not immediately act based on the error notification unless corrective actions are defined in this specification, such as for COOKIE, INVALID_KE_PAYLOAD, and INVALID_MAJOR_VERSION./t I think the last sentence is bit hard to parse. tNOTE FOR WG DISCUSSION: Having other payloads in the message is allowed but there are none suggested. One WG member mentioned the possibility of adding a DELETE payload when the error is sent in a separate INFORMATIONAL exchange. Do we want to allow such additional payloads that have operational semantics?/t As I do not see any other reason to start new informational exchange when processing IKE_AUTH reply than fatal errors when creating it (i.e. AUTHENTICATION_FAILED) which already deletes the IKE SA, I do not see any benefit from adding DELETE notification to the message. It would be saying the same thing twice: There was fatal error delete the sa, and by the way delete the sa. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP
Paul Hoffman writes: At 2:49 PM +0300 9/21/09, Tero Kivinen wrote: The IP addresses are also needed for the RFC 3948 incremental checksum fixup in udp encapsulation, not only for undoing the address substitution. As I said in my earlier note, I have removed all discussion of RFC 3948 from this new text. RFC 3948 is for IKEv1 only, and is not relevant here. RFC3947 is for IKEv1, RFC3948 is for IKEv1 and IKEv2. We do have references from RFC4306 to RFC3948 as that is the only document that describes how to do the UDP encapsulation. The problem is that it just says peer's real source and distination address have been received according to [RFC3947], incrementally ... and the longer description of original source and destination addresses are in the RFC3947 section 5.2. So we definately need reference to RFC3948 (we already have that as [UDPENCAPS]), but as its description of the addresses is so short my original text refered to longer text in RFC3947. On the other hand as this longer text is just background information and is not really needed for protocol reasons the ones implementing UDPENCAPS/RFC3948 can then see the reference to RFC3947 and read that as background information if they want to. - If the client is behind a NAT, substitute the IP address in the TSi entries with the remote address of the IKE SA. - If the server is behind a NAT substitute the IP address in the TSr entries with the local address of the IKE SA. Client and server are ok here, but my original text used other end and this end at least in our implementation our NAT traversal detection does tests that way. I.e. it know whether this end and/or other end is behind nat and knows to enable suitable processing based on that (i.e. sending of RFC3948 keepalives etc). Client and server makes this bit more vpn roadwarrior case centric, compared to using this end and other end. But either one is acceptable here. I changed to client and server to match the figure. Let me know if this is not OK. As I said it is OK, I just explained my reasons to why I originally selected other words, but matching the ones in the figure is also good. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Scott C Moonen writes: tNOTE FOR WG DISCUSSION: Having other payloads in the message is allowed but there are none suggested. One WG member mentioned the possibility of adding a DELETE payload when the error is sent in a separate INFORMATIONAL exchange. Do we want to allow such additional payloads that have operational semantics?/t I think you are asking specifically about the IKE_AUTH response? If so, I agree that DELETE does not make sense in the IKE_AUTH response, and N(AUTHENTICATION_FAILED), for example, is sufficient to delete the IKE SA. I think we can forbid DELETE in the IKE_AUTH response. However, because a separate INFORMATIONAL exchange cannot be definitively correlated to the IKE_AUTH exchange, I'd like to retain the option of sending both DELETE and N(AUTHENTICATION_FAILED) (for example) in a separate INFO exchange. You cannot really get AUTHENTICATION_FAILED in any other places than IKE_AUTH, as the text says: AUTHENTICATION_FAILED24 Sent in the response to an IKE_AUTH message when for some reason the authentication failed. There is no associated data. Thus AUTHENTICATION_FAILED can always be correlated to the IKE_AUTH. On the other hand, I think it is clear that unless we explictly forbid other payloads you are free to add whatever payloads are normally allowed in INFORMATIONAL exchange anyways (i.e. notice, delete, vendori ID payloads, or even configuration payloads etc). Most likely the other end either processes those or ignores them, and if your error notify is fatal error like INVALID_SYNTAX then it really does not matter as the IKE SA will be deleted anyways. The IKEv2 does not really restrict what you can send in INFORMATIONAL exchange, but there are lots of cases where those simply do not make any sense. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01
Scott C Moonen writes: - Is Section 1.2 necessary? None of these terms are used in this fashion in this document. True. Removed. - page 8, sees an new = sees a new - page 8, in the Section 8 = in Section 8 Fixed. - page 12, excessive space in i.e. UDP encapsulated; perhaps replace with comma. xml2rfc seems to want to put it there, but that is something that can be fixed in the final RFC editing phase. - page 16, with a new SA which needs heuristics = produces a new SA which needs heuristics and will benefit from the existing flows. Fixed. - page 21, things what needs = things that need - page 21, suggest optimize things = optimize steps, just to reduce repetition - page 21, For example implementation = For example, implementations Fixed. - page 25, I believe that DES-MAC has a 64-bit ICV (FIPS 113) and KPDK has a 128-bit ICV (RFC 1828). RFC4306 does not give reference to AUTH_DES_MAC, and the AUTH_KPDK_MD5 reference is to RFC1826 whic does not define it. I do not want to put those there as both of them are actually quite unsecure and should not be used anyways. Changed to: // AUTH_DES_MAC and AUTH_KPDK_MD5 are left out from // this document. - page 30, for tunnel mode checks it might be worth just mentioning that tunnel mode is inferred by protocol 4 for IPv4 and protocol 41 for IPv6. Changed it to be: // Tunnel mode checks (protocol 4 for IPv4 and protocol 41 for // IPv6) is also left out from here to make the document shorter. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #22 Simultaneous IKE SA rekey text
David Wierbowski writes: I see no reason why Host A MUST NOT immediately delete the old IKE SA. Deleting the IKE SA immediately makes it impossible to know what happened to other exchanges going on the same IKE SA. Waiting for 30 seconds or so after rekey would allow those other exchanges to finish before the old IKE SA is deleted. The current IKEv2 document does not specify what happens to the ongoing exchanges when IKE SA is deleted. In normal case that does not matter, as all the IKE SA state goes away when SA is deleted, thus it is simply the case that all exchanges are immediately discarded and all CHILD_SAs on the IKE SA are deleted. This is not the case on the rekey case, as here there might be CREATE_CHILD_SAs and other exchanges ongoing on the IKE SA when it is rekeyed. Now if the IKE SA is deleted immediately without waiting those to finish when rekey finishes the other end does not know what the node deleting the IKE SA did for those exchanges. It might have silently discarded them, or it might have already processed them but their responses were lost because of network error etc. This causes the peers state to get out of sync, which will lead problems and will cause IKE SAs to be deleted completely later. In fact I think is SHOULD immediately delete the old IKE SA. By this I mean it should mark the SA as being deleted, it should send a delete payload, and it should refuse to create any additional SAs. I agree it should mark the SA so that it is no longer used for the new SAs initiated from this end, but the other end might have its own exchanges ongoing when the rekey started, and waiting those to finish makes protocol work better. When both end mark the old SA as being old, meaning no new exchanges are started on it, but old exchanges are allowed to finished then when those old exchanges are finished, then the old IKE SA should be deleted (and all operations done on the old IKE SA should be moved to the winning SA). recv req1 -- send resp2: ... Nr2 ... -- Host A should respond with NO_ADDITIONAL SAS in this case because Host A did not detect a simultaneous rekey and should have immediately deleted the original IKE_SA. NO_ADDITIONAL_SAS is not correct error for this case, as we are talking about IKE SAs not about CHILD_SAs. The NO_ADDITIONAL_SAS description clearly says it is used when no more CHILD_SAs are to be used. Sending some more suitable error could most likely also work, but still the IKE SA cannot be deleted immediately. It can only be deleted when ongoing exchanges have been finished. I have not checked out if your suggested version works with all possible combinations of simulatenous rekeys, but from the first look it seems it might also work. On the other hand there is no text indicating such behavior in the IKEv2 document, so it is protocol change compared to the old text which said that simulatenous rekey is processed by checking out the nonces. The rekeys in this case are simulatenous even when Host A didn't initially detect that. After sending that reply that also creates the second IKE SA B in Host A and then Host A can check all the four nonces and see which of them is lowest, and it will then move all the CHILD_SAs to that new IKE SA having lowest nonce unless they were already there (i.e. if the IKE SA A had lowest nonce, Host A has already moved the CHILD_SAs there, if IKE SA B had lowest nonce, host A needs to move CHILD_SAs from the IKE SA A to this IKE SA B, and start timer to delete IKE SA A). Why do you want to mandate all this complication for a case that will occur infrequently? You are impacting every IKE_SA rekey, not just the simultaneous case. I doubt that anybody delays the delete of an IKE_SA on a rekey based on RFC 4306. At the very least I'm sure there are implementations that do not delay the delete. Requiring this delay is a protocol change and one that I do not see the need for. We do delay the delete, as we do want to wait for the ongoing exchanges to finish. On the other hand we are almost only one of the implementations who also implement the window size 1, which means we have cases where might have several CREATE_CHILD_SA exchanges initiated by the host B ongoing when host A decides to do rekey on the IKE SA. That delay does not have anything to do with simultaneous rekey, it is needed to allow the ongoing exchanges to finish before old IKE SA is deleted. On the other hand RFC4306 specifies exactly ONE way to handle simulatenous rekey and that is by checking the nonces. The rekey is simulatenous even when one host didn't immediately detect it as simulatenous because some packet was lost. I agree now that MUST NOT immediately delete was too strong, so SHOULD NOT immediately delete is better. If implementation does not implement larger window sizes, and is used in environments where there is very limited number of CHILD SAs per IKE SA, so the probability of getting CREATE_CHILD_SA
[IPsec] IKEv2 NAT-T and Traffic Selectors
Matthew Cini Sarreo writes: Hello all, I have a question regarding proper choosing of traffic selectors in the situation where an initator is behind a NAT device. Let us use the following scenario: [initia...@a]--[nat@x][respon...@y] Say A is 192.168.2.22, X is 192.168.3.5 and Y is 192.168.4.25, and all have a 24bit mask. The initiator policy requires traffic selectors for the whole subnet. In the case that A is initiating: TSi 192.168.2.0 to 192.168.2.255 TSr 192.168.4.0 to 192.168.4.255 As these are subnets, I assume this is tunnel mode not transport mode. Y does not know about 192.168.2.* but only about 192.168.3.*. So when it receives TSi it does not match with anything it knows about. Should the responder just accept these due to NAT being previously detected, or should the initiator send selectors with address A (TSi) and Y (TSr) and due to there being NAT the responder just copy them in the reply? The Y should be configured to accept 192.168.2.0/24 as this is tunnel mode and packets exiting from the tunnel will have those addresses as their source address. NAT does not change this, it only affects the gateway address, i.e only the outer IP address of the ESP packet. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #22 Simultaneous IKE SA rekey text
David Wierbowski writes:
I agree with what you stated here, but I feel you are addressing something
that is not limited to a simultaneous rekey of the IKE SA. It deals with
any
rekey of an IKE SA. In my opinion the text is misplaced and should be in a
section that deals with handling of outstanding exchanges when an IKE SA
is rekeyed.
True. This wait is not really because of simultaneous rekey, but rekey
in general. The reason I brought this up here, is that I think that
wait is important and the solution for simulatenous rekey should be
one that works with such wait.
With that said I'm not sure I agree with how you propose to
handle the outstanding exchanges.
I do not think there is any other way than to wait some time to get
them finished (or at least failed and acked). The other end who
started those outstanding exchanges MUST know whether they were
processed or not. If IKE SA is deleted immediately there is no way
other end can know that as after IKE SA is deleted the other end does
not send ACKs back.
I agree it should mark the SA so that it is no longer used for the new
SAs initiated from this end, but the other end might have its own
exchanges ongoing when the rekey started, and waiting those to finish
makes protocol work better. When both end mark the old SA as being
old, meaning no new exchanges are started on it, but old exchanges
are allowed to finished then when those old exchanges are finished,
then the old IKE SA should be deleted (and all operations done on the
old IKE SA should be moved to the winning SA).
This sounds like a good idea, but it's not what 4306 required and is a
protocol change.
Not really. The RFC4306 do say that you MUST be able to process
incoming requests while having your own requests out:
2.3. Window Size for Overlapping Requests
...
An
IKE endpoint MUST be prepared to accept and process a request while
it has a request outstanding in order to avoid a deadlock in this
situation. An IKE endpoint SHOULD be prepared to accept and process
multiple requests while it has a request outstanding.
I.e. when you have REKEY started and even when the rekey itself has
finished, and delete request sent out (and even replied), you still
might receive requests from the other end which were started before
the REKEY was started.
I agree that the behavior how to handle the deleting of IKE SA after
rekey is not described explicitly in RFC4306, but the generic text
that you MUST be able toprocess incoming requests while having your
own requests out is there, and that is regardless what those requests
are.
Based on 4306 I think when an informational exchange request is received
containing the delete of an IKE_SA that the receiver can conclude that most
likely any outstanding request will fail once a response to the delete is
sent. The receiver of the delete request has ways to deal with this.
The other end cannot know that, and IKEv2 is deterministic protocol,
thus such most likely is not enough for it. Here is example to show
the situation:
Host A Host B
--
-- sends request
packet is dropped by network it
never reaches the host A
starts rekey --
-- replies to rekey
starts IKE SA delete --
-- replies to IKE SA delete
Now Host A will delete all of the state of old IKE SA and cannot then
process the request from Host B even if it ever reaches it. It cannot
even send error back as the crypto keys and so on are already deleted.
Host B does not know whether the request was processed or not, as
situation could have also been this:
Host A Host B
--
-- sends request
processes request and sends reply --
reply packet is dropped by network it
never reaches the host B
starts rekey --
-- replies to rekey
starts IKE SA delete --
-- replies to IKE SA delete
Now Host A thinks that the request host B sent was done and finished
before rekey, but the Host B does not know that. Host A will not
retransmit the reply packet unless host B retransmits its request, but
if the IKE SA is deleted by A before that host B might not have time
to ever send retransmission for its request, thus B does not know
whether its request was processed or not.
If host A delays deleting of the IKE SA so long that Host B's
retransmissions reach it (i.e. time depending on the retransmission
timers, i.e. for example 31.5 seconds if original retry timer is 500
ms, and retry timer is doubled after each retry, and retry limit
Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01
Nicolas Williams writes: - Section 7, 1st paragraph: MOBIKE is mentioned without a reference. - Section 7, 2nd paragraph: s/avare/aware/ - Section 8.1, next to last sentence: this sentence is grammatically incorrect, I think. How about: If the protocol (also known as the, next header) of thepacket is one that is not supported by the heuristics, then detecting the IV length is impossible, thus the heuristics cannot finish. - Section 8.2, 2nd paragraph: s/shorted/shortest/ - Section 8.2, 2nd paragraph, 2nd sentence: s/implementation/the implementation/ - Section 8.2, 2nd paragraph, 2nd sentence: s/valid looking/valid-looking/ - Section 8.2, bottom of page 15: s/insure/ensure/ (yes, nowadays your use if 'insure' in this way is quite common) All fixed. - Section 8.2, next to last paragraph, next to last sentence: I'm not sure what is meant. Can you try to re-write this sentence? How about: By counting how many unsure returns obtained via heuristics, and after the receipt of a consistent, but unknown, next-header number in same location (i.e., likely with the same ICV length), the node can conclude that that flow has a high probability of being ESP-NULL (since it's unlikely that so many packets would pass the integrity check at the destination unless they were legitimate). (The key change is the addition of a comma and moving a clause into a parenthetical.) Changed to: tAn intermediate node's policy, however, can aid in detecting an ESP-NULL flow even when the protocol is not a common-case one. By counting how many unsure returns obtained via heuristics, and after the receipt of a consistent, but unknown, next-header number in same location (i.e. likely with the same ICV length), the node can conclude that the flow has high probability of being ESP-NULL (since it is unlikely that so many packets would pass the integrity check at the destination unless they are legitimate). The flow can be classified as ESP-NULL with a known ICV length, but an unknown IV length./t - Section 8.3, 1st paragraph, 2nd sentence: this sentence is grammatically incorrect, and I'm unsure as to what is meant. This was commented already by others and was changed to: For example, when many TCP / UDP flows are established over one SA, a rekey produces a new SA which needs heuristics and will benefit from the existing flows. I think what is meant is that if an intermediate node has seen a stateful ULP flow over an ESP-NULL flow, and later the SA is changed and the new flow looks like ESP-NULL and appears to contain a next protocol header that matches that previously-seentateful ULP flow, then chances are very good that the old ESP-NULL flow is abandoned and replaced by the new one. In such situations the intermediate node can simply change the old ESP-NULL state's lookup key. Yes. That was what I tried to say. Do you think my already changed sentence is ok, or do we need to explain it more. - Section 8.3.1, 1st paragraph, 1st sentence: s/feed/fed/ Fixed. - Section 8.3.1, third paragraph: are you suggesting that intermediate nodes drop TCP-looking packets to elicit retransmission? It says that if a packets is dropped, i.e. it does not say whether the intermediate node does or does not do it, as that depends on the policy. If the intermediate node's policy is that no packets go through before they can be inspected meaning ESP-NULL detection needs to finish first before they can be inspected, that will cause all packets to be dropped while heuristics is in progress. This will cause next packets to be retransmissions. If the policy is so that packets are passed, even when we cannot yet inspect them, then the next packet still might be to the same flow. - Section 9, 1st paragraph, 1st sentence, I think you may want to make this change: s/unless that is not/unless that is/ Yes. Fixed that. - Section 9, 1st paragraph, 1st sentence: this is an odd sentence construction. How about: Attackers can always bypass ESP-NULL deep packet inspection by using encrypted ESP (or some other encryption or tunneling method) instead, unless the intermediate node's policy requires dropping of packets that it cannot inspect. - Section 9, 1st paragraph, 2nd sentence, rewrite: Ultimately the responsibility for performing deep inspection, or allowing intermediate nodes to perform deep inspection, must rest on the end nodes. - Section 9, 1st paragraph, last sentence: s/but in that/in which/ Ok, took all of those in, here is the current version of section 9: tAttackers can always bypass ESP-NULL deep packet inspection by using encrypted ESP (or some other encryption or tunneling method) instead, unless the intermediate node's policy requires dropping of
Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02
Shen Sean writes: (3) Section 2 (and ff.) ... The number of (internal) rounds is totally irrelevant for the application of the AES. Any attempt to mangle with this 'parameter' would raise significant security concerns and conformance issues. I strongly request to elide all mention of rounds from the draft. I agree on that. In most cases the AES is implemented as part of cryptographic library or hardware, and for those you usually just indicate the key length to be used and that automatically selects the number of rounds. [Sean] The intention of such a document is to give what a IKEv2 product MUST/SHOULD/MAY provide. A user may not have choices of rounds or size, but a vendor need to know what to provide. Usually even the vendor does not have choice, or even possibility to change the number of rounds, as that is hidden inside cryptographic library. (15) Section 7 I suggest to more clearly indicate what this draft is expecting IANA to do: adding a reference to this memo for an existing registration. | IANA has assigned 13 as the transform ID for ENCR_AES_CTR encryption | with an explicit IV. This ID is to be used during IKE_SA | negotiation. --- | Per [RFC3686], IANA has assigned 13 as the IKEv2 Encryption | Transform ID to the name ENCR_AES_CTR for AES-CTR encryption with | an explicit IV, in the IANA Internet Key Exchange Version 2 (IKEv2) | Parameters registry. This document specifies how to use this | transform during IKE_SA negotiations. Hence IANA should add to that | entry a reference to this RFC. [Sean] It's a good point, but for IANA's reference to this document, I assume iana will updated their reference (following some rocedure?) when this document is processed. Let me know if we have to request it in the draft. I would not count on that. For example IANA didn't update the ENCR_AES-CCM_* or AES_GCM with a * octect ICV references for the RFC5282 automatically, so better add text there. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #22 Simultaneous IKE SA rekey text
David Wierbowski writes: I'm not sure this makes RFC4718 incorrect. It just makes it incomplete. Ok, but that still means we need to find a way to fix that problem before we can use that solution in IKEv2bis. This solution might cause peers to stay in live lock state, causing the whole IKE SA to be unusable. I.e. host A starts IKE SA rekey and host B starts Create Child SA. Host B replies NO_PROPOSAL_CHOSEN to host A's IKE SA rekey, and Host A replies NO_ADDITIONAL_SAS to Host B's Create Child SA request. Both ends process replies, and notices they failed, thus both start again, causing both ends to be trying these operations as fast as they can. This situation will stay as it is unless something kicks hosts out of sync. Or returning NO_ADDITIONAL_SAS might cause other end to delete the whole IKE SA and start from scratch. I do not like that RFC 4718 used NO_PROPOSAL_CHOSEN as the indicator that a rekey is being rejected because there are outstanding requests. To me a new notify would have made sense. True, but as RFC4718 tried to be so it does not modify IKEv2, it could not define new error code. In IKEv2bis we can do this, so I think we should define new error code something like TEMPORAL_FAILURE which means there was some kind of temporal error (i.e. the problem will disappear without anybody changing policy) and other end should try again after short timeout. This error code could have uses for other places too. NO_PROPOSAL_CHOSEN has indication that the problem will NOT disappear unless someone changes something (i.e. proposals or policy or traffic selectors etc). So some implementations might (and should) use much larger timeout before trying again with exactly same parameters. Given that RFC 4718 did use NO_PROPOSAL_CHOSEN it seems to me that when HOST A is rekeying the IKE_SA it should assume the peer is busy when it receives NO_PROPOSAL_CHOSEN and should continue to attempt to periodically rekey the IKE SA again. Yes. I do not agree that when Host B receives NO_ADDITIONAL_SAS that it should retry the operation using the same IKE SA. True, if it follows the RFC4306, it should tear down the whole IKE SA, and start from beginning: -- 4. Conformance Requirements ... If the responder rejects the CREATE_CHILD_SA request with a NO_ADDITIONAL_SAS notification, the implementation MUST be capable of instead closing the old SA and creating a new one. ... -- This would be very unfortunate operation to be done in this case, as it would tear down the whole IKE SA, and all the IPsec SAs along with it. I do not think we can use NO_ADDITIONAL_SAS with the current definition anywhere else because of this. If on the other hand the host B which receives NO_ADDITIONAL_SAS does not tear down the whole IKE SA, but decides to keep the existing IKE SA up and running, there is no text anywhere saying it cannot start create child exchange again in future. Most likely it will do that whenever next packet requiring IPsec SA to be created is received, thus if there is constant stream of packets which would require protection it will trigger new create child exchange immediately. If we want that when host B receives NO_ADDITIONAL_SAS or when it rejects the IKE SA rekey with NO_PROPOSAL_CHOSEN (or with new TEMPORAL_FAILURE) then it needs to mark the IKE SA in some kind of on hold state, which means no new exchanges can be started on it, that needs to be explictly mentioned. As such I do not think there is a live lock state. What should be done is up to the implementation. An implementation could assume the other end is in the process of rekeying or deleting the IKE SA and delay taking any action or it could take immendiate action. If it takes immediate action it would need to do so on a new IKE SA. How long should it delay those operations? Forever? Does that include DPD? If so how is the other end going to get rid of the IKE SA if Host A crashes and forgets everything about the IKE SA, as there will not be any more exchanges from Host A from that on etc. As the behavior of the nodes affects interoperability we should define what to do in this case. This is not in RFC4306, this is just one proposal given in RFC4718 which might be used, but as I noted above, it can cause live lock loop, thus it is not really acceptable. I think it is appropriate to add this to the new draft. If you are concerned about the lock state then a warning should be added stating that when you receive NO_ADDITIONAL_SAS that you should not attempt to retry that operation on the same IKE SA, although that seems self-evident. Yes, I would want to have some kind of text describing that, and also describing how long does this limit for retry take effect, and I assume that if the other end does not rekey or delete the IKE
Re: [IPsec] RFC4307 ENCR_NULL USGv6 profile Roadmap document
Frankel, Sheila E. writes: I interpreted RFC 4307 slightly differently than Tero does, and I stand by the wording of both the USGv6 Profile and the IPsec Roadmap. Although RFC 4307's domain is limited to IKEv2, it clearly specifies both those algorithms used within IKEv2 and also those algorithms that IKEv2 negotiates for use by IPsec. That is why there are 2 separate lists of algorithms: Section 3.1.1 (Encrypted Payload Algorithms) specifies those algorithms that are used BY IKEv2 in its Encrypted Payload. Sections 3.1.3 (IKEv2 Transform Type 1 Algorithms) and 3.1.5 (IKEv2 Transform Type 3 Algorithms) lists those algorithms that IKEv2 should be able to negotiate for use within IPsec/child SAs. One detail that supports this interpretation is the inclusion of NULL encryption in section 3.1.3 - clearly, this is not appropriate in the IKE Encrypted Payload. If the applicability of Sections 3.1.3 and 3.1.5 is limited to IKEv2 SAs, then there is no need for the more constrained list in Section 3.1.1, which clearly applies only to IKEv2's payloads. Hmm... Yes, it could be interpreted so also, but what is the relationship between RFC4307 and RFC4305/4835 then. Would RFC4305/RFC4835 then cover only manual keying and IKEv1? I always assumed that RFC4307 talks about IKEv2 SAs and RFC4305/4835 talks about ESP and AH (i.e. IPsec SAs aka Child SAs). One reason I think this is the correct interpretation is that RFC4307 section 3.1.4 lists Transform Type 2 Algorithms (Pseudor-random functions, PRFs), and those are applicable ONLY to IKEv2. IPsec SAs/Child SAs/ESP/AH cannot have PRFs. Also section 3.1.5 does not give any status for NONE authentication (as it cannot be used for IKEv2 SAs), but for example RFC4305/RFC4835 both give requirement for it (MUST / MAY). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #115: Camellia req levels for IKEv2
Frankel, Sheila E. writes: #115: Camellia req levels for IKEv2 Proposed changes to Roadmap doc: 1) Change IKEv2 requirement level for Camellia-CBC from undefined (no RFC) to optional 2) Add text to Section 5.2.6 (RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec) Looks ok for me. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] #116: The AUTH payload signature
Yaron Sheffer writes: The definition of the payload (sec. 3.8) should mention explicitly that the payload hash algorithm is unrelated to the one used in the certificate, or the algorithm used to sign the IKE Encrypted Payload. What is the exact wording you are plannig to add there. As in some cases the hash functions are related to the keys used (for example hash must be SHA if DSS digital Signatures are used) the exact wording is important. Also it is very good idea to see that if other end used certificates using SHA-2 as their hash algorithm for certificates, then he most likely do support SHA-2 as auth method hash algorithm too, so using it to hash the RSA keys might be good idea. This means that hash algorithm used here and the hash algorithm used in the certificate are related, altought that does not mean they need to be same. Moreover, the words by default are confusing and should be deleted. I cannot find words by default from rfc4306 nor from draft-ietf-ipsecme-ikev2bis-05.txt. Are you refering this text: ... To promote interoperability, implementations that support this type SHOULD support signatures that use SHA-1 as the hash function and SHOULD use SHA-1 as the default hash function when generating signatures. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] #120: CA indication with cert req - allowed types
Yaron Sheffer writes: Sec. 3.7 has: The contents of the Certification Authority field are defined only for X.509 certificates, which are types 4, 10, 12, and 13. Other values SHOULD NOT be used until standards-track specifications that specify their use are published. This is clearly wrong and is not present in the RFC4306. There is two meanings for the certificate request payload, one is to specify preferred format in which certificates are requested and another is to tell which authority the certificate is wanted from. So if someone wants to have certificate payloads in raw rsa format, he should be able to give certificate request with encoding of type 11 and with empty authority field (as for raw rsa keys there is no authority field). Also as the certificate request is just hint the contents of the authority field is not that important, it is there just in case the other end happens to have MULTIPLE certificates it could use and needs to decide which of them to use. If it has only one of the requested format then it should send it regardless what the authority field said. So the text most likely should say that For other values the certificate authority field contents is not defined, and can be anything (or empty) until specifications that specify their contents is published. This excludes certificate requests of type 7, i.e. for CRLs. For requesting a specific CRL type 7 would make sense, in particular in chain situations. Should we add it to the list of allowed types here? Giving certificate authorities for the CRLs is usually no operation as it will be the same as the ones for X.509 certificates (usually hosts do trust same CAs for certificates and CRLs, they do not have separate sets of authorities for those two uses). So in most cases certificate request of type 7 is just indicating that other end would like to have CRLs inline also if possible in addition to certificates, and the authority field could be empty there. This kind of telling only the format not the exact authority is inherited from the IKEv1 and is specified for example in the RFC4945 section 3.2.7.2. I think we had discussion about this when we were specifying IKEv2 as some people wanted to disallow it but I think we decided to allow it (at least I couldn't find text in the RFC4306 which would disallow it). OTOH, this allows type 10, which is unspecified and should be removed. Most likely. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fw: Preshared key authentication in IKEv2
Paul Hoffman writes: At 9:58 AM +0300 10/30/09, Valery Smyslov wrote: Hi all, I'd like to reiterate my early message, which I haven't got answer to. My concerns are: 1. How padding pre-sahred key with string Key Pad for IKEv2 could help to avoid storing pre-shared key in IKE implementation if prf is not known untill IKE_SA_INIT exchange is finished? The PRF (or set of PRFs) is known by the receiving party. If the two parties always only use one PRF, it is known. The padding is not a universal solution for the reasons you give, but it works in the common case of peers who know each other's crypto choices. As Paul said recipient knows which algorithms it support, and it can store the pre-shared key using all of those algoritms to its database. I.e. if it supports PRF_HMAC_SHA1, and PRF_AES128_XCBC then it needs to calculate the PRF(Shared Secret, Key Pad for IKEv2) using those two PRFs and store both of the results to its authentication database. This way if someone manages to get the authentication database it cannot directly know the Shared Secret, it just knows the hash, and cannot use the Shared Secret in any other protocols. 2. It is a bit unclear whether EAP generated key should also be padded before use in IKE, or used directly. I'm pretty sure the key is used in its PRF form, not in its as is form, but I would want to hear from one or two implementers on that. As section 2.16 refers to the 2.15 and says the AUTH payloads in messages 7 and 8 using the syntax for shared secrets specified in section 2.15, and section 2.15 tells that this padding is used, so I think it should be used always (and by quick look in our code seemed to use the same format for both cases). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] RFC4307 ENCR_NULL USGv6 profile Roadmap document
pasi.ero...@nokia.com writes: I think you're correct that RFC 4307 has a bug: ENCR_NULL should be MUST NOT, instead of MAY (note that ENCR_NULL in 4305/4835 is MUST). Go ahead and submit an errata about this! Done. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fw: Preshared key authentication in IKEv2
Valery Smyslov writes: Hi Paul and Tero, thank you for your answers. The PRF (or set of PRFs) is known by the receiving party. If the two parties always only use one PRF, it is known. The padding is not a universal solution for the reasons you give, but it works in the common case of peers who know each other's crypto choices. As Paul said recipient knows which algorithms it support, and it can Sometimes it doesn't. I refer to implementations with pluggable crypto, when crypto providers are separated from IKE implementation and can be added/removed later. Then you need to store the original shared key not the hashed version of it. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication
Yoav Nir writes: Since the gateway acts as a pass-through, the requirement here is more for the client, which is typically more integrated. The client should be prepared to give an identity hint both in IKE and later in the EAP session. And in that case the identities should really be same, and if they differ then the authenticated identity needs to be used for policy lookups, meaning that the EAP identity needs to be used. So the gateway needs to get that authenticated identity from the AAA server so it can do policy lookups based on it. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WESP - Roadmap Ahead
Jack Kohn writes: From operational perspective if we are supporting both v4 and v6 (and we will) then having different protocols ESP and AH is and will be a nightmare. Common denominator is ESP-Null. However, there were issues with ESP-Null as it couldnt be deep inspected which has now been solved with WESP. ESP-NULL and AH will still have different properties. AH will also protect data which is not protected by the ESP-NULL, i.e. IP-header including IP-addresses (unless ESP-NULL is used with tunnel mode). In short, the argument that Oh, but we can inspect AH packets is not relevant anymore. I do not think it was never really relevant... AH was not used because it offers ability to inspect packets, it was used when encryption was not necessarely and where protection of the IP header was needed. Given this, should we still have AH as a MAY for IPSEC - Cant we deprecate it? I do not see any reason why it should be deprecated. It is already MAY which means it does not need to be implemented unless your environment or use scenario needs it. I was earlier in favor of changing it to MAY, but I do not think we need to move it further than that. WESP is ESP++, and it offers everthing that ESP offers plus more. What is our stance for ESP moving forward? I am very sceptical for the WESP getting lots of implementations quickly, so I do not really consider WESP as competitor for ESP. Also I do not see any reason to wasting bytes for extra WESP header for encrypted traffic, so I assume WESP will be used (if it will be used) for ESP-NULL traffic not for encrypted traffic. Also, I see that a lot of work done in other WGs is still using ESP (primarily for data integrity). Shouldn?t they be moving to WESP, as WESP offers more flexibility? It will take several years before implementations start to implement WESP, and even more years before hardware chips support WESP. Most of the IPsec users are still using IKEv1, even when we published IKEv2 2005, i.e. 4 years ago. And IKEv2 draft was finished and publication was requested at end of 2003. So stable draft which could be used to implement IKEv2 was ready 6 years ago, and while there are several implementations out, people are still using IKEv1. Also before WESP can be used people would first need to move to IKEv2 anyways... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01
Nicolas Williams writes: On Wed, Oct 14, 2009 at 02:36:20PM +0300, Tero Kivinen wrote: Yes. That was what I tried to say. Do you think my already changed sentence is ok, or do we need to explain it more. Well, the heuristics will benefit from the information cached for the TCP/UDP flow over the previous SA. ...benefit from the existing flows doesn't quite get that point across (though it's the only realistic meaning). Changed the text still more: Generic protocol checking is much easier with pre-existing state. For example, when many TCP / UDP flows are established over one IPsec SA, a rekey produces a new SA which needs heuristics to detect its parameters, and those heuristics benefit from the existing TCP / UDP flows which were present in the previous IPsec SA. In that case it is just enough to check that if a new IPsec SA has packets belonging to the flows of some other IPsec SA (previous IPsec SA before rekey), and if those flows are already known by the deep inspection engine, it will give a strong leaning that the new SA is really ESP-NULL. But surely actively trying to elicit retransmissions could be used as a way to get enough information to classify a flow... The retransmissions should have different MACs, thus retransmissions help resolve ambiguities, even if the policy isn't to drop packets that cannot be inspected. I would be quite hesitant to add text which actively tries to elicit more retransmissions. If packets are dropped because of policy reasons and that triggers retransmissions which helps heuristics, then that is good. If packets are passed through then we can most likely use heuristics over multiple packets to gain same information. If the policy is so that packets are passed, even when we cannot yet inspect them, then the next packet still might be to the same flow. I see. Having a policy that says drop packets that can't be inspected actually helps resolve ambiguities if the end nodes retransmit. Yes, but it also helps to resolve ambiguities, if we see multiple packets to the same flow, i.e. get 3 TCP packets having same source and destionation IP and ports, and first having SYN bit, next reply having SYN/ACK and next one having ACK (with all of them with expected sequence numbers etc). enforcement and protection of the end node. One way to enforce deep inspection for all traffic, is to forbid encrypted ESP completely, in which case ESP-NULL detection is easier, as all packets must be ESP-NULL based on the policy, and further restriction can eliminate ambiguities in ICV and IV sizes./t ^ s Great! Fixed. A few more comments: - Should there be an explicit threat model in the document? I am not sure if it belongs to this document, or to the WESP or as separate document. I agree that having explicit threat model could probably help understanding the problem, but I am not sure I am correct person to write such. I think the threat model is this: - End nodes trying to access inappropriate data, end nodes trying sneak confidential data out, but without collusion with other end nodes outside the network. - Malware (since deep inspection could find malware and terminate flows before malware downloads complete). The first one shows how simple it is to defeat deep packet inspection: just find a peer to collude with. There is also some cases where this can be used even when there is no real threat, i.e. statics, and log gathering etc. - A security considerations note about the security impact of forcing the use of ESP-NULL (and/or WESP) would be nice. Specifically a note about the increased risk of sending confidential information where eavesdroppers can see it. Added note: tUsing ESP-NULL or especially forcing using of it everywhere inside the enterprice can have increased risk of sending confidential information where eavesdroppers can see it./t The thought occurred that the pseudo-code could be expressed as a BSD Packet Filter program. From what I can tell BPF does not have instructions by which one can implement state caching, but you could still implement, and _test_, large parts of the code in the appendix as BPF programs. I wouldn't demand that -- it's a lot of work for a feature that we all seem to agree is not exactly hot (and it might mean doing implementation work for some vendors for free). I do not expect the pseudo-code to include all required operations, and I do not think it would be good idea to put executable code in the RFC. It is meant to be as example pseudo-code, not final implementation. I think it might be better if someone could take that pseudo-code, and implement as much as possible of it as BSD packet filter or some other filtering language and put that out as open-source implementation. This might be suitable exercise
[IPsec] Comments on draft-ietf-ipsecme-esp-null-heuristics-01
Tero Mononen writes: Overall comments: The draft contains quite a lot of background information (what you are trying to achieve on technical point of view, what were the alternative solutions considered). Part of this background is also available on WESP draft. Making this draft an information disclosure on algorithm to determine if IPsec ESP packet stream has been encrypted or not, without too much explanation or hand waving would increase its usability. The background could be find by-reference on the WESP RFC. I think having background information in this document also makes this document easier to understand. WESP document actually has quite a little of the background information. Please consider adding definitions/glossary entries for the following concepts: flow, flow-cache. I know they are relevant on certain implementations, but not necessarily well defined on that sense, or at least introducing these terms properly before using them. I added terminology section and added those terms there. About the abstract: Consider changing abstract in a way that really points out the good on this approach. Something like: -8--- This document describes an algorithm for distinguishing IPSEC ESP- NULL packets from encrypted ESP packets. The algorithm can be used on intermediate devices, like traffic analyzers, and deep inspection engines, to quickly decide whether given packet flow is interesting or not. Use of this algorithm does not require any changes made on existing RFC4303 compliant IPSEC hosts. -8--- Changed. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] draft-ietf-ipsecme-esp-null-heuristics-02.txt
Submitted now a new version of the heuristics draft, which includes changes from Williams, Mononen, Richardson, Graveman and Moononen. This should now include all changes that were requested, if I missed some, send me a note. Draft can already be found from the ietf repository http://www.ietf.org/id/draft-ietf-ipsecme-esp-null-heuristics-02.txt but it takes some time before it appears to the tools site (i.e. if you want to get diffs etc): http://tools.ietf.org/html/draft-ietf-ipsecme-esp-null-heuristics -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question
Paul Hoffman writes:
We earlier agreed in issue #50 to make the KEr in Section 1.3.2
(Rekeying IKE SAs with the CREATE_CHILD_SA Exchange) mandatory:
-- HDR, SK {SA, Nr, KEr}
Note that this is not in the current draft, but will be in the next one.
So, what happens if the responder does not include a KEr, following
the syntax in RFC 4306? Does the process revert back to using only
the SK_d and the new nonces, or does the responder reject the
request and indicate its preferred DH group in the
INVALID_KE_PAYLOAD notification payload (section 1.3)? The latter
seems much more likely, given the text in 2.18. If so, we should say
so explicitly.
Note, that this can only happen if initiator allowed responder to not
give KEr. Initiator tells the responder whether it requires
Diffie-Hellman by listing Diffie-Hellman groups in its SA payload. If
it does not include group 0 (NONE) then responder does not have option
to send KEr (both for RFC4306 and IKEv2bis implementations).
RFC4306 implementations are allowed to include the Diffie-Hellman
group 0 (NONE), but IKEv2bis implementations are not allowed to
include it anymore.
This means that if RFC4306 implementation talks as initiator to the
IKEv2bis responder implementation and RFC4306 implementation selects
Diffie-Hellman group 0, and does not include KEi then IKEv2bis
implementation will return INVALID_KE_PAYLOAD and request RFC4306
implementation to select some other group (provided the RFC4306
implementation listed any acceptable group in its SA payload). If they
cannot find group which is acceptable for both then the negotiation
will fail with NO_PROPOSAL_CHOSEN.
On the other hand if IKEv2bis implementation talks as initiator to the
RFC4306 implementation, then IKEv2bis implementation will include KEi,
and MUST NOT include group 0 (NONE) in its SA payload, thus RFC4306
implementation is not allowed to select group 0, meaning it must
return proper KEr, or NO_PROPOSAL_CHOSEN if none of the groups were
acceptable (or INVALID_KE_PAYLOAD if group selected by KEi was not
acceptable, but some other group in SA payload is).
This means that if either end is IKEv2bis implementation, there cannot
be situation where KEr is ignored, and where we would not have g^ir
(new) for SKEYSEED calculation.
I do not think we need extra text for this, as if implementors follow
the currect text in section 2.18 which says IKEv2bis implementations
MUST NOT propose the value NONE, and MUST NOT accept such proposal,
then there is no problem.
Section 2.18 also states that in the case of the old and new IKE SA
selecting different PRFs, that the rekeying exchange (for SKEYSEED)
is done using the *old* IKE SA's PRF. What happens after that? The
end of section 2.18 says that SK_d, etc are computed from SKEYSEED
as specified in section 2.14. If the PRF changed, which PRF is used
for the prf+ calculations, the old PRF or the new PRF?
I would interpret because the rekeying exchange belongs to the old
IKE SA, it is the old IKE SA's PRF that is used, to cover also the
SK_d, SK_ai, etc generation and also prf+ uses. First thing that uses
new PRF, is when new IKE SA is used to generate KEYMAT, or SKEYSEED
for next IKE SA rekey. But I agree this is not very clear, and could
be clarified.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] #122: Integrity proposals with combined algorithms
Paul Hoffman writes: The 4th paragraph of section 3.3 says If an algorithm that combines encryption and integrity protection is proposed, it MUST be proposed as an encryption algorithm and an integrity protection algorithm MUST NOT be proposed. This means that an integrity protection algorithm can only be proposed with a Transform ID equal to NONE, given that a few paragraphs above, it says: Combined-mode ciphers include both integrity and encryption in a single encryption algorithm, and are not allowed to be offered with a separate integrity algorithm other than none. We should thus make this clear in the 4th paragraph. I interpreted the text integrity protection algorithm MUST NOT be proposed to mean that there is no transform type 3 (Integrity algorithm) at all in the proposal, i.e. it is left out completely. Accepting proposal having transform type 3 (Integrity algorithm) with value 0 (none) is ok, but I think we should prefer for not including it at all, as it makes packets shorter. I agree that the text earlier would indicate that you send NONE, but RFC5282 says: This document updates [RFC4306] to require that when an authenticated encryption algorithm is selected as the encryption algorithm for any SA (IKE or ESP), an integrity algorithm MUST NOT be selected for that SA. This document further updates [RFC4306] to require that if all of the encryption algorithms in any proposal are authenticated encryption algorithms, then the proposal MUST NOT propose any integrity transforms. where I read the MUST NOT propose any ingerity tranforms to also include integrity transform for value 0 (NONE). So I would change the section 3.3 text where it says Combined-mode ciphers include both integrity and encryption in a single encryption algorithm, and are not allowed to be offered with a separate integrity algorithm other than none. to say Combined-mode ciphers include both integrity and encryption in a single encryption algorithm, and are not allowed to be offered with a separate integrity algorithm. to align with the RFC5282. Also note that the [AEAD] reference to the RFC5116 in IKEv2bis is wrong, it should point to the RFC5282, which defines how AEAD modes are used in IKE (all those references refer to IKEv2 used of AEAD). HOWEVER, in section 3.3.2, in the table for transform types, it says: Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP (*) Negotiating an integrity algorithm is mandatory for the Encrypted payload format specified in this document. For example, [AEAD] specifies additional formats based on authenticated encryption, in which a separate integrity algorithm is not negotiated. The second sentence seems wrong. Proposed rewording: For example, [AEAD] specifies additional formats based on authenticated encryption, in which the integrity algorithm is an inherent part of the combined algorithm; in this case, the integrity algorithm is specified as none. When you fix the reference from RFC5116 to RFC5282, then you notice that NONE is not allowed, thus the original text was correct and your new text is incorrect, as NONE cannot be proposed or accepted. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Paul Hoffman writes: This has flummoxed a few reviewers. Tables such as those in section 3.3.2 are already out of date because things have been added since RFC 4306. I propose that we remove all these tables from IKEv2bis, and add notes pointing to the current IANA registries. I cannot see how doing this lookup will hurt developers: in fact, it forces them to actually look at the up-to-date tables. I can see how we might want to leave the tables in, but it really is confusing. I would be in favor of removing the tables which are updated frequently, but I think most of the tables should still stay in the IKEv2bis. For example I think IKEv2 exchange types, Next Payload Types, Protocol ID, Transform type values etc should stay, but for example tables like Transform type 1 (Encryption Algorithm) could point to the IANA registry. I.e if table is integral part of the protocol, then it should stay in the IKEv2bis document, but if it is something like listing of crypto algorithm etc, then it can be changed to point to the IANA registry. Mostly that means that if the IANA registry has some other RFC(s) as reference for the values in the registry (ENCR_3DES points ot RFC2451 etc, PRF_HMAC_MD5 points to RFC2104) then it it is useful to put references to the IANA registry. On the other hand if only references in the IANA registry is back to the RFC4306 (or IKEv2bis document in future), then its bit pointless to ask people to go to the iana registry to see that they should read this document they are reading to get more information :-) For examples of such registries are Next Payload Type, Transform Type Values, IKEv2 Transform Attribute Types, IKEv2 Identification Payload ID Types, IKEv2 Certificate Encodings... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
