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

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 8 Nov 2021 19:40:52 +0000

I’m glad to see this work; 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.

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?

And, finally, a typo: it’s P-521, not P-512 😊

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Nov 2021 23:04:17 +0200

Scott Fluhrer \(sfluhrer\) writes:
> I’m glad to see this work; 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).
> 

The reason for this notify is that if the peer has multiple key pairs
(i.e., private keys) it needs to pick one private key to sign the AUTH
payload with. If one of those private keys is using EC and another is
using RSA, then without this notification there is no way of knowing
which one to pick (except perhaps by prior configuration or by
heuristics based on the CERTREQ etc).

Also in some cases same private key can be used with multiple hashing
methods etc, thus indicating what formats of signature are accepted is
also needed.

On the other hand the signatures in the certificates are already
there, and the peers do not have any way of changing them, thus
negotiating what are accepted does not help. Peers can already send as
many certificates they want and they can also indicate the CAs they
trust using CERTREQs, so that should be enough for peers to get
algorithms in the certificates sorted out.

I.e., if they have multiple paths from certificate(s) matching their
private key they are going to use for signing to the trusted roots
trusted by other end, they can send all those paths out.

The one who gets all those certificate payloads will then search from
them, and from its local cache, or even querying more intermediate
certificates from the CA and form a trusted path from the one EE
certificate to any trusted root that matches the security policy
required for the that end.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Nov 2021 16:12:12 -0500 (EST)

> heuristics based on the CERTREQ etc).

What will be in the notification then? Since the authenticaion method
for both is "RFC 7425 Digital Signatures" as per existing IANA registry
for IKEv2 Authentication Methods.

We would still need a new registry or we need to identify auth algorithms
by their SPKI similar to how we can signature supported hash algorithms.
But we would prob end up with seeing lots of duplicate entries with
slightly different SPKI prefixes.

The RSS-v1.5 vs RSS-PSS is a major pain right now, and implementations
using 7425 and specifying RSA-v1.5 SHA1 are a double pain as the RFCs
clearly doesn't allow that. We run into frequent interop issues with
these.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 9 Nov 2021 11:38:53 +0200

>From the draft:

----------------------------------------------------------------------
   The following format is currently used only with the "Digital
   Signature" (14) authentication method.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Length (>3)  |  Auth Method  |   Cert Link   |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   |                                                               |
   ~                AlgorithmIdentifier ASN.1 object               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
----------------------------------------------------------------------

I.e., for RFC7425 Digital Signatures, there is also the ASN.1
algorithm identifier to tell which algorithm(s) is/are supported.

> slightly different SPKI prefixes.

If the Cert Link is zero then the algorithms can be used with any CA,
otherwise they are only to specific CA listed in the CERTREQ, so in
most cases you simply list method 14 few times with the
AlgorithmIdentifiers you support. 

> clearly doesn't allow that. We run into frequent interop issues with

My understanding is that the one of the reasons for this draft is to
try to solve that issue...
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 9 Nov 2021 14:16:31 +0300

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.

          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.

          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.

          Thank you. These buttons are so close to each other :-)

          Regards,

          Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 9 Nov 2021 14:25:08 +0300

Hi Paul,

> for IKEv2 Authentication Methods.

The notification contain a list of supported auth methods.
Each method is represented by a structure containing a value for a auth
method from 
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ike
v2-parameters-12
IANA registry AND IF this method is "Digital Signature" (defined in RFC
7427)
then IN ADDITION an AlgorithmIdentifier for the supported signature
algorithm is included. So, there may be multiple "Digital Signature"
auth methods with different AlgorithmIdentifiers.

> slightly different SPKI prefixes.

We can use AlgorithmIdentifier, so no new registry is needed.
But there is a trade off, so this can be discussed if the draft is adopted.

> clearly doesn't allow that. We run into frequent interop issues with

That what this draft tries to address.

Regards,
Valery.

> Paul
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Nov 2021 20:03:47 -0500 (EST)

> We can use AlgorithmIdentifier, so no new registry is needed.

Ah sorry, it does state that indeed. Although we might almost want to
not support non-RFC7427 "legacy" methods. Then again, if all software
updated and be RFC compliant, we wouldn't need this to begin with :)

> That what this draft tries to address.

If that is the most prominent use case, then I'd rather push to fix the
implementations that dont comply to RFC 8247's:

3.2.  Digital Signature Recommendations

    When a Digital Signature authentication method is implemented, the
    following recommendations are applied for hash functions:

                +--------+-------------+----------+---------+
                | Number | Description | Status   | Comment |
                +--------+-------------+----------+---------+
                | 1      | SHA1        | MUST NOT |         |
                | 2      | SHA2-256    | MUST     |         |
                | 3      | SHA2-384    | MAY      |         |
                | 4      | SHA2-512    | SHOULD   |         |
                +--------+-------------+----------+---------+

    When the Digital Signature authentication method is used with RSA
    signature algorithm, RSASSA-PSS MUST be supported and RSASSA-
    PKCS1-v1.5 MAY be supported.

The problem is receiving RSA-v1.5-SHA1 or RSA-PSS-SHA1 in Digital
Signatures. These are MUST NOT. I am not sure this document would
help here, as our implementation still will refuse these, even
if we are notified of this earlier.

I also still believe that "supported" is the wrong concept here. We are
really looking for "accepted".

As I said in the meeting, it becomes really tricky for the responder. It
can select a better configuration in IKE_SA_INIT based on the initiator's
information, but it is not really helping the initiator choose between
which algorithms to use as it can't really get information from the
responder in time to make a decision in IKE_AUTH unless it sent its ID
in IKE_SA_INIT in which case the responder might be able to switch to
a better configuration profile in time and share accepted authentication
methods. But I guess it won't hurt trying to get more information
across.

Paul