Hi Scott.
I’m glad to see this work;
Thank you.
however I see a potentially important constraint on authentication that the
current draft does not appear to address.
It allows the peers to specify which signature algorithms they accept; however
if we are talking about certificates, those include internal signature
algorithms, which may be different. One instance where I expect this to come
up is that the root certificate may have a more conservative algorithm choice
(e.g. a hash based signature, or one with NIST level 5) than the device
certificates (which may have a short expiry time, and so being so conservative
might not be necessary).
Does the AuthMethod apply to the algorithms within the certificate as well?
The RFC should clarify this.
Maybe implicitly, but not explicitly. The problem the draft addresses
is an ambiguity
for an IKE implementation having several credentials which to use so
that its peer can authenticate it.
So, if there are several certificate chains for host's certificates
(e.g. several CAs each issuing
EE certificate), then an implementation selects one of its
certificates, thus implicitly
selecting the chain to corresponding CA. But of course, the announced
Auth Methods
indicate only the algorithm the implementation use to create AUTH
payloads, not algorithm within the chain.
Listing the AlgorithmIdentifier’s for all the signature algorithms we can
support seems unnecessarily chatty; would it be more prudent to extend the
AuthMethod field to 16 bits (and so we (or IANA) would feel more free to dole
them out?
I considered this option. My intention was to avoid creating new
registries so, that
new algorithms can be used without the process of allocation a new
value
(that takes a while), so the choice of AlgorithmIdentifier. I agree
that it makes
the size of the notification larger. Whether it is a real problem
depends
on the number of supported algorithms. RFC 7427 lists a dozen, and
most of them (except for RSA-PSS) have AlgorithmIdentifier length
11-15 bytes.
RSA-PSS is very special, it has a lot of parameters, but in practice
most of
time it is used with default parameters. We don't know yet about
AlgorithmIdentifiers for PQ signature schemes, but it is my
understanding
from yesterday's LAMPS meeting that they most likely will contain no
parameters, just a single OID.
So, it looks like in most cases the size of the SUPPORTED_AUTH_METHODS
notification will be about one or two hundred bytes compared to about
20-30
bytes if we use new registry. One can also use IKE_INTERMEDIATE
if this amount extra bytes overflows IKE_SA_INIT.
So, there is a trade of, but we can return to this and probably
reconsider
if the draft is adopted.
And, finally, a typo: it’s P-521, not P-512 😊
Thank you. These buttons are so close to each other :-)
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
