Re: [IPsec] Comments on draft-smyslov-ipsecme-ikev2-auth-announce

[Valery Smyslov <[e-mail]>]

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.