[IPsec] Issue #26: Missing treatment of error cases
Hello all. Issue #26 was submitted by Tero Kivinen. It concerns section 2.21 (error handling) and states that several things are missing: - handling of errors before authentication - listing what error conditions cause the IKE SA to be deleted entirely - listing how errors are handled in the piggybacked exchanges. 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? 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. If an error occurs outside the context of an IKE request (e.g., the node is getting ESP messages on a nonexistent SPI), the node SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem. 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. If a node receives a message on UDP port 500 or 4500 outside the context of an IKE SA known to it (and not a request to start one), it may be the result of a recent crash of the node. If the message is marked as a response, the node MAY audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node MAY audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain a Notify payload indicating INVALID_IKE_SPI. The INVALID_IKE_SPI notification indicates an IKE message was received with an unrecognized destination SPI; this usually indicates that the recipient has rebooted and forgotten the existence of an IKE SA. A node receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message might be a forgery or might be a response, the genuine correspondent was tricked into sending. A node should treat such a message (and also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and should initiate a liveness check for any such IKE SA. An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a denial of service attack. A node receiving a suspicious message from an IP address (and port, if NAT traversal is used) with which it has an IKE SA MAY send an IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. The recipient MUST NOT change the state of any SAs as a result, but may wish to audit the event to aid in diagnosing malfunctions. A node MUST limit the rate at which it will send messages in response to unprotected messages. 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. 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. If the error occurs on the initiator, the notification MUST be returned in a separate INFORMATIONAL exchange, with no other payloads. 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. If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established, provided that there are no unsupported critical payloads. Establishing the child SA, or requesting configuration information may still fail, but they do not automatically cause the IKE SA to be deleted. Specifically, a responder may
[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
Re: [IPsec] Issue #26: Missing treatment of error cases
On Sep 1, 2009, at 5:07 PM, Tero Kivinen wrote: 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 But wouldn't this cause a state de-synchronization? 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? (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. 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. 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). Agree. Will fix tomorrow or Thursday. 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 considers 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. OK. 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
[IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets
Hi All, I have a question about IVs of retransmitted packets. 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. 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? 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? Question 3: How about IV of retransmitted RESPONSE? Does it need to be identical to the original one too? It seems to me that the following statement in section 2.1 implicitly requires that. But I'm not sure. 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. 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). Thanks in advance, Naoyoshi Ueda ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-08.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, et al. Filename: draft-ietf-ipsecme-traffic-visibility-08.txt Pages : 15 Date: 2009-09-01 This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on top of Encapsulating Security Payload (ESP) [RFC4303] and is designed to allow intermediate devices to ascertain if ESP-NULL [RFC2410] is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate ESP-NULL from ESP encrypted packets, without compromising on the security provided by ESP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-08.txt ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] PROTO write up for draft-ietf-ipsecme-traffic-visibility-08
I believe the draft is ready for AD review now. Below is my shepherd write-up, for your comments. Thanks, Yaron Document name: Wrapped ESP for Traffic Visibility, draft-ietf-ipsecme-traffic-visibility-08.txt (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Yaron Sheffer, co-chair of the ipsecme WG. I have reviewed it and believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had in-depth review within the ipsecme WG. I am not aware of any non-WG reviews. I do not have any concerns about these reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns, the document lies fully within the ipsecme WG's area of expertise. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I have no such concerns. There have been no IPR disclosures. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is wide WG consensus. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No, there were no such conflicts. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes, I have personally verified that. No formal review criteria are applicable. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. No issues identified. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document defines a new IP Protocol Number. In addition, it defines a new IKEv2 notification, and one new IANA registry. There are no issues with any of them. I expect the Responsible AD to request the existing
