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.
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.
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?
Regards,
Valery Smyslov.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
