Valery Smyslov writes: > Section 4 lists conformance requirements for IKEv2 implementations. > > First, the following text: > > Every implementation MUST be capable of doing four-message > IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, > one for ESP or AH). > > is formally incorrect, because IKE_AUTH results in two child SAs - > one in each direction. Moreover, AH support is purely optional, so > why is it here? I suggest to rephrase: > > Every implementation MUST be capable of doing four-message > IKE_SA_INIT and IKE_AUTH exchanges establishing one SA for IKE, > and a pair SAs for ESP.
This change looks good to me. > Then, paragraphs: > > A minimal IPv4 responder implementation will ignore the contents of > the CP payload except to determine that it includes an > INTERNAL_IP4_ADDRESS attribute and will respond with the address and > other related attributes regardless of whether the initiator > requested them. > > A minimal IPv4 initiator will generate a CP payload containing only > an INTERNAL_IP4_ADDRESS attribute and will parse the response > ignoring attributes it does not know how to use. > > seem just to repeat what is said in previous paragraph. I suggest to > remove them. Yes, they just repeat what could be also seen from the generic text, but they do agree on the same thing and I think they clarify (at least a bit) what are the minimal requirements. > And last (but not least). THe following requrements: > > For an implementation to be called conforming to this specification, > it MUST be possible to configure it to accept the following: > > o PKIX Certificates containing and signed by RSA keys of size 1024 > or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, > ID_RFC822_ADDR, or ID_DER_ASN1_DN. > > o Shared key authentication where the ID passed is any of ID_KEY_ID, > ID_FQDN, or ID_RFC822_ADDR. > > o Authentication where the responder is authenticated using PKIX > Certificates and the initiator is authenticated using shared key > authentication. > > suggest that every implementation MUST support both RSA PKIX certificates > and preshared key. Isn't it too strong requirement? > > 1. Why to pay so much attention to "minimal IKEv2 implementation" > lacking some not-so-difficult-to-implement functions, if we still > require it to have full PKIX support? I see no logic here. > PKIX support requires quite a lot of code and resources, so making > "IPsec garage opener" becomes problematic. > > 2. Some implementations may have pluggable crypto modules (or use > external tokens for authentication), so it may not have RSA at > all, while having all public key authentication support for > other algorithms. Or implementation may elect not to support > 1024 bits RSA keys as not so strong. Do such implementations > become non-conformant? > > > Is it possible to lower those requirements from MUST to SHOULD? We need at least one "MUST to implement" authentication methods, so we know two complient implementations can talk to each other. Selecting Shared key authentication would put the limit too low. On the other hand I agree that full PKIX Certificates support puts the rquirement bit too high. On the other hand, does it really matter that your garage door opener is conformant to the RFC4306 / IKEv2bis. Shouldn't it be enough to say that your garage door opener is implementing enough IKEv2bis that it can talk to the conformant IKEv2bis server implementation? If we want to set one mandatory to implement authentication method I think the some type of RSA keys is the logical choice. This would not care whether the RSA keys are in form of RAW RSA keys or whether they are in form of PKIX Certificate. You can always take the PKIX Certificate having RSA key and extract the RSA key from there and configure it to the system which only supports RAW RSA keys. Also you can take RAW RSA key and make self-signed certificate it using generally available tools, and if you configure that self-signed certificate as trusted in your system with suitable ID data, then other end can use the raw rsa keys and you can use certificates. Anyways the certificates is mandatory to implement feature of RFC4306, and I think it should stay there, even when it makes some of those very minimal garage door openers not following the full spec as they might use raw rsa keys or even shared keys instead of certificates. For example section 3.6 also says: 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 two Hash and URL formats (with HTTP URLs). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
