Re: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2-resumption
Yaron Sheffer wrote: - Section A.1 should say that the notation used for the example ticket formats is intended to be pseudo-code, and does not specify exact octet-by-octet format. (And probably things like reserved[3] should be removed, since they don't really belong in pseudo-code like this.) This is an example only, but it can still be precise. It *does* specify an octet-by-octet format, except you're free to implement something else, or change whatever you feel like. In general, I think an implementer is better off starting from a precise definition than from a vague pseudo-code description. The text never specifies how e.g. opaque state_ref would be encoded (e.g. if it's variable length, there's probably some kind of length field somewhere), so IMHO it does not specify octet-by-octet format (two persons reading this would very likely end up with different octets). Best regards, Pasi ___ 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
Re: [IPsec] Comment/Request on IKEv2bis Draft
Looks good! Thank you. BR, Emre On Mon, Aug 17, 2009 at 3:55 AM, pasi.ero...@nokia.com wrote: The original text in RFC 4306 was slightly confusing, but I think we should leave room for ROHCoIPsec here. Perhaps adding something like this after the bulleted list? If the Child SA negotiation includes some future IPsec protocol(s) in addition to (or instead of) ESP or AH (e.g., ROHC_INTEG), then (1) all keys for SAs carrying data from the initiator to the responder are taken before SAs going in the reverse direction, and (2) keying material for the IPsec protocols are taken in the order in which the protocol headers will appear in the encapsulated packet. Best regards, Pasi (not wearing any hats) -Original Message- From: Emre Ertekin Sent: 15 August, 2009 00:54 To: ipsec@ietf.org Subject: [IPsec] Comment/Request on IKEv2bis Draft Hi All, One comment/request on the IKEv2bis draft. One of the differences between RFC 4306 and the IKEv2bis draft is in Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of the IKEv2bis draft indicates the following: In Section 2.17, removed If multiple IPsec protocols are negotiated, keying material is taken in the order in which the protocol headers will appear in the encapsulated packet because multiple IPsec protocols cannot be negotiated at one time. Is it possible to leave the quoted text in the spec? I agree that multiple IPsec protocols cannot be negotiated at one time; however, the text is useful for ROHCoIPsec implementers, where multiple keys may need to be generated for a ROHC-enabled Child SA. For example, if a ROHC-enabled Child-SA with ROHC_INTEG [draft-ietf-rohc-ikev2-extensions-hcoipsec-09] is instantiated, first the IPsec encryption/authentication keying material will be taken, then an additional key will be taken for the algorithm used to verify the proper decompression of packet headers. BR, Emre ___ 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
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. Your comments will be appreciated. Regard, Sean 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 : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 Author(s) : S. Shen, et al. Filename: draft-ietf-ipsecme-aes-ctr-ikev2-01.txt Pages : 17 Date: 2009-08-17 This document describes the usage of Advanced Encryption Standard Counter Mode (AES_CTR), with an explicit initialization vector, by IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr -ikev2-01.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. Major changes are as following: #1. Section 2 Rearranged sentences at the beginning of section 2 to simplify and clarify AES and AES_CTR. #2 Section 2.1 Detailed description of counter mode was cited from corresponding section of rfc3686 #3 Section 2.2: old: All IKEv2 implementations MUST support the 128 key size. new: All IKEv2 implementations that implement AES-CTR MUST support the 128 key size. Because AES-CTR is a SHOULD requirement for IKEv2. #4 Section 3.2 Added clear reference to rfc4302 and rfc4307 for integrity requirement and algorithm choice. #5 Section 4 Rewrote second paragraph in section 4 to clarify the role of Counter Block. The Counter Block is same as that defined by rfc3686. #6 Section 4 Keep the Counter Block description in the same style as in rfc3686 Message/External-body; name=draft-ietf-ipsecme-aes-ctr-ikev2-01.txt: Unrecognized ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
