Sorry for the (very) late review. I support the document but have a few
comments and questions.
The SUPPORTED_AUTH_METHODS NOTIFY is used for multiple purposes. One of
these methods (with no payload data) is used for two different things.
Would it be better to split this in two? eg SUPPORTED_AUTH_METHODS_SUPPORTED
and SUPPORTED_AUTH_METHODS ?
The recommendations on in which IKE_INTERMEDIATE to send the payload is
a lot of handwaving. Maybe just say "in any IKE_INTERMEDIATE, but later
might give you more protection"
There is text about IDi/IDr payloads being used in IKE_INTERMEDIATE and
then talk about SHOULD be identical to the ones in IKE_AUTH. I would
prefer a different notify for this (eg SAM_IDi/SAM_IDr) to avoid
implementers confusing/erroring on confusing these with the real IDi/IDr
payloads.
There are two methods described, one for old style RSA/ECDSA and one for
Digital Signatures (RFC 7247, auth method 14). I would prefer to not
support the old style, as we are trying to obsolete those. These use
undesirable features anyway (RSA v1.5, sha-1, etc)
There are oddities with the CERTREQ payload. Some implementations using
a list of hashes in 1 CERTREQ, others using 1 hash per CERTREQ. This
makes using a numbered cert link number a bit tricky. (eg number 2 of
the 3rd CERTREQ). I'd much rather select based on hash, not number.
Additionally, implementations might build the CERTREQ payload and then
throw it away. I wouldn't want to need to keep those around for this
extension.
With PAKE, can we say MUST NOT instead of SHOULD NOT, and throw a fatal
error?
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
