Subject: [IPsec] Working Group Last Call: draft-kivinen-ipsecme-signature-auth-02

From: Yaron Sheffer <[email-masked]>
Date: Wed, 23 Oct 2013 20:20:30 +0300

Hi, this is to start a 3-week working group last call on the IKE 
Signature Authentication document, ending Nov. 13.

The draft is at: 
http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-02. 
<http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-02> The 
document is a product of a design team that was started for this 
purpose, but should now be treated like any WG document.

Please read this draft and send any comments to the WG mailing list, 
even if the comments are "I see no problems". Comments such as "I do not 
understand this part" or "this part could be explained better in this 
way" are particularly useful at this point.

Thanks,
     Paul and Yaron

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 24 Oct 2013 16:39:18 +0400

Hi all,

first, I think that the draft is very important for interoperability.
But I also think, that in its current form it is insufficient
in some situations and could have been made better.

The problem, that the draft is not solving, is the situation,
when one of the peers has more than one private key, each
for different signature algorithm. This may happen if in deployed
VPN there is a need to move from one signature alg
to another (for any reason, for example when old algorithm
is found to be broken or obsoleted by authorities). As the
transition cannot be done at once, there will be a period when
some of the hosts will have only a single key, while the others
will have more than one. In general, host with multiple keys
cannot decide which of them to use with different peers,
so there is a possibility, that IKE will fail, when it could have
completed. CERTREQ payloads may help in some cases,
but not in all (single CA may issue both certificates signed
with one trusted root) and they are optional anyway.

The solution to the problem would be if host be able to 
explicitely indicate, which signature algorithms 
it supports. Currently draft includes ability to indicate
to the peer which hash algorithms it supports.

I suggest to change this as following. Instead of
adding IKE registry, listing hash algorithms,
add registry listing combinations of hash&signature
algorithms, as listed in Appendix A.
So, the registry would look like:

    RESERVED                              0
    sha1WithRSAEncryption            1
    sha256WithRSAEncryption        2
    sha384WithRSAEncryption        3
    sha512WithRSAEncryption        4
    dsa-with-sha1                           5
    dsa-with-sha256                        6
    ecdsa-with-sha1                        7
    ecdsa-with-sha256                    8
    ecdsa-with-sha384                    9
    ecdsa-with-sha512                    10
    RSASSA-PSS-default                11

And to include values from this registry into 
SIGNATURE_HASH_ALGORITHMS notification. 
This will allow peer indicate not only hash alg,
but the particular pairs signature-hash which it supports.

Regards,
Valery Smyslov.

P.S. One small typo in the draft.
in Appendix A last sentence of first para:

    "These values are taken form the New
   ASN.1 Modules..."

s/form/from

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 24 Oct 2013 18:40:37 +0300

> with one trusted root) and they are optional anyway.

Lets take example where someone thinks that RSA keys are not strong
enough anymore, and should be replaced with ECDSA keys. They also have
old implementation which only support RSA, and then they have newer
implementation which support both.

To do the change, they need to provide newer implementations a ECDSA
certificates and keys, but also keep the old RSA keys around, as those
are needed to talk to the old implementations.

Also note, as they do consider RSA keys too weak to be used, they
would also need to change the signature algorithms on their
certificates. This would mean they would need to get new CA or sub CA
key with ECDSA keys to sign those new ECDSA certificates.

So when the old device talks to new device, it will send CERTREQ to
the old RSA CA, and because the new implementation only has
RSA certificate for that older RSA CA, it will automatically pick RSA
key and use that. Everything works automatically.

The new device knows both ECDSA and RSA so it can always verify what
the old device sends. Things work automatically there too.

CERTREQ payloads may be optional, but so is support for this. If you
want to support changing from one CA infrastructure to another you
need to support CERTREQ payloads.

Changing the underlaying key used in the IPsec is useless unless you
also change it in the certificate infrastructure too. 

The real problem is that with Raw Public keys you do not have this
option, as CERTREQ payloads are not useful there (their contents are
empty). But on the other hand RFC5996bis does not have Raw public keys
anymore :-)

And you can always retry when you notice that you get authentication
error after using private key, provided you have multiple types of
keys.

Anyways, I do not really consider this as serious problem in the real
world. In most of the cases the certificate hierarchy needs to be
changed anyways at the same time when changing authentication keys,
and then you get this negotiation automatically.

On those situations this does not work, then you can always manually
configure the devices to use specific keys, or try both keys. 

>     sha512WithRSAEncryption        4

The problem here is that RSA Encryption is not enough. For example
there might be implementations which only support 1024-bit RSA keys,
as they have old crypto hardware. 

>     ecdsa-with-sha512                    10

Or there is implementation which support ECDSA only with NIST curves,
and not with brainpool curves.

> but the particular pairs signature-hash which it supports.

The problem with that kind of registry is that the registry gets quite
large quite quickly, especially if we take different curves etc in to
account too. And also it will make the initial IKE_SA_INIT packets
bigger. On the other hand we could move that negotiation at the same
place where have CERTREQ, i.e. responders IKE_SA_INIT, and initiators
IKE_AUTH, as this is where that information is needed. 

>     "These values are taken form the New

Fixed.
-- 
[email-masked]

---

From: Pekka Riikonen <[email-masked]>
Date: Thu, 24 Oct 2013 18:40:02 +0200 (CEST)

The ASN.1 used here are the same ASN.1 which is used in the
    AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]).  The

It should specify encoding rules, even though it references RFC5280.  So 
this could say something like:

    The ASN.1 used here are the same ASN.1 which is used in the
    AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280])
    encoded using distinguished encoding rules (DER) [X.690].

--
    the authentication methods are not negotiated in the IKEv2, the peer
    is only allowed to use this authentication method if the
    SIGNATURE_HASH_ALGORITHMS Notify Payload has been sent and received.

I think I said this already for -00 version, that I'd still prefer to 
allow the use of the new authentication method even if the hashes weren't 
negotiated (the hash is is indicated in the ASN.1).  I get why we want to 
negotiate them, but it's not always necessary, necessarily.  And if it 
isn't allowed should it be MUST NOT?

Otherwise it's great, and important work.

 	Pekka

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 25 Oct 2013 11:25:42 +0400

Hi Tero,

> are needed to talk to the old implementations.

Right.

> key with ECDSA keys to sign those new ECDSA certificates.

Most probably yes. But I can imagine situations when new ECDSA certificates
will be signed by old RSA keys. Root CA keys are usually made
much longer than EE keys, so they may still be considered secure
for mean time. Changing all CA infrastructure at once is a big
problem.

And algorithm weakness is only one example of the necessity to change it.
Trere may be other reasons as well (administartive requirements,
performance, licensing issues), and not all of them will require to
change CA and its algorithm.

> the old device sends. Things work automatically there too.

Yes, but see above.

> error after using private key, provided you have multiple types of

In general you can't if it is responder who selected wrong key.

> configure the devices to use specific keys, or try both keys.

I admit, that such situations are rare but not non-existent.
And manual configuration is not an option for large VPNs.
Retry is not always possible and is a hack anyway.

> as they have old crypto hardware.

There might also be implementations, that supports only md5,
but we do not consider them, do we?

And the problem with the current SIGNATURE_HASH_ALGORITHMS
is that it decouples hash from signature, assuming that any hash
could be used with any signature algorithm.
Actually this is not true, as some algorithms are administratively defined
only in conjunction with particular hash function.
For example GOST signature algorithm is defined ONLY with GOST hash.

And even if you could use DSA with SHA-2 or even SHA-3,
I would more likely expect the existence of crypto
that supports DSA only with SHA-1, than the crypto,
that supports only RSA with 1024 bit keys and no other RSA key sizes.

> and not with brainpool curves.

Probably they should also be added.

> large quite quickly, especially if we take different curves etc in to

Yes, this is a problem. But I hope the registry will
still be of reasonable size, much less that its capacity.

> bigger. On the other hand we could move that negotiation at the same

Yes, this is also a problem. That's why I'd prefer registry
to approach, when supported ASN.1 are listed in the notification.
And I still expect, that the number of supported
hash-sign combinations in real life will be limited
(probably by configuration).

> IKE_AUTH, as this is where that information is needed.

It will solve the last problem only partially.

Regards,
Valery.

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 25 Oct 2013 10:24:45 +0200

Valery,

>> as they have old crypto hardware.

Your proposal creates exactly the issue which the draft is trying to solve: The lack of flexibility by relying on IPsec
code points for the signature algorithm (as opposed to using existing OIDs commonly used in certificates and CMS) and
the coupling of signing algorithms and signature hash functions.

> could be used with any signature algorithm.

This decoupling was explicitly stated as objective by the WG chairs when the design team was set-up:
Yaron Sheffer wrote on 24.07.2012 18:08:
> - Allows flexibility in associating hash functions with EC groups. 

Therefore, this feature is not the problem, it is the solution.

> only in conjunction with particular hash function.

This is the exception. For the most commonly used algorithms, RSA and ECDSA, There are no requirements to use fixed
combinations. For ECDSA, there is only a minimum requirement relating to the targeted security level.

> For example GOST signature algorithm is defined ONLY with GOST hash.

The current proposal allows to use that combination, so what is the problem?

> that supports only RSA with 1024 bit keys and no other RSA key sizes.

I do not think, DSA is used much at all. Even if it was, SHA-1 is phasing out due to (not so) recent advances in
cryptoanalysis. Thus, I would expect either implementations to change to allow the use of DSA with SHA-2/3, or the
(limited)  prevalence of DSA to end soon.

> Probably they should also be added.

There are 4 Brainpool curves registered and 5 NIST curves. Each can be combined with a bunch of hash functions (from the
SHA-2 and SHA-3 families).

>>>     RSASSA-PSS-default                11

The default is with SHA-1 which will soon be outdated. Thus, you would need to allow many further PSS combinations.

-- 
Johannes

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 25 Oct 2013 15:41:30 +0400

Hi Johannes,

> Your proposal creates exactly the issue which the draft is trying to 
> solve: The lack of flexibility by relying on IPsec
> code points for the signature algorithm (as opposed to using existing OIDs 
> commonly used in certificates and CMS) and

The main idea of my proposal is to allow node to advertise
what signature algorithms it supports along with what hash
functions it supports.

> Therefore, this feature is not the problem, it is the solution.

As far as I remember, the main problem was that Auth Method field in AUTH 
Payload
was only 8 bits and its codepoints coupled signature with particular hash.
And proposed solution just moves this coupling from IPsec
registry to AlgorithmIdentifier ASN.1 object, where they are
coupled naturally. That's great and I don't have any objections against it.

But the other part of solution - advertising supported algorithms,
is, IMHO, currently a bit deficient, as it lists only hash algoritms,
while supported signature algorithms must be guessed by some indirect means.

I don't insist on coupling while advertising algorithms.
Another possible option is to use one more notification,
say SIGNATURE_ALGORITHMS (with associated registry),
listing signature algorithms (decupled from hashes) that node supports.
Then peer may assume that any combination of listed
signature algorithms and hashes is supported.

But again, we have some special cases when some signature
algorithms are defined only with particular hash functions.

Regards,
Valery.

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 25 Oct 2013 14:10:46 +0200

Hi Valery,

>
> As far as I remember, the main problem was that Auth Method field in AUTH Payload

Well, this was the initial problem, but then Yoav had the great idea of generalizing the mechanism by using the OIDs in
CERT payload. Hash flexibility was added later and this finally resulted in the current draft.

> registry to AlgorithmIdentifier ASN.1 object, 

Experience shows that the standardization of ASN.1 AlgorithmIdentifiers is done much sooner than registration of code
points for protocols. Consider the Brainpool curves or RSA-PSS as examples.

> where they are coupled naturally.

At least for RSA-PSS, ASN.1 AlgorithmIdentifiers provide more flexibility by the parameters field.

> while supported signature algorithms must be guessed by some indirect means.
I do not object to this point. While I agree with Tero, that in most situations, a transition of the algorithm  will be
accompanied with a change of the CA, it may not always be the case. For instance, the usage of an RSA key specified in
the certificate (SPKI) by a rsaPublicKey OID may change from PKCS#1v1.5 to RSA-PSS even without replacing the certificate.

> signature algorithms and hashes is supported.

This is ok for me. But of course any additional means of negotiation adds complexity which must be balanced with its
benefits.

> algorithms are defined only with particular hash functions.
Yes, but I do not see a problem here with decoupling signature and hash.

-- 
Johannes

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 28 Oct 2013 15:14:58 +0200

> In general you can't if it is responder who selected wrong key. 

That is something I realized on our way home, but it is easy to fix.
We add suggestion to the draft that the responder should use same type
of key than what initiator used.

I.e Initiator selects algorithm based on the CERTREQ and his own
preferences (and one of those might be algorithms already used
previously, or previously tried).

The Responder should select same type of key that was used by
initiator, provided he has the that type of private key. If not, then
he picks a key based on his policy. 

> And manual configuration is not an option for large VPNs.

Large VPNs should use centralized management systems anyways, and all
of this is also avoidable by using suitable sub CA keys. You do not
need to change the root CA, it is enough to change the sub CA used to
signing the EE cert, and send CERTREQ containg that key instead.

> Retry is not always possible and is a hack anyway.

For initiator it is possiblity, for responder adding the text which
says it should use same algoritm than other end will solve the issue.

I do not think it as a hack, we already do that in IKEv2 with
Diffie-Hellman group negotiation. On the other hand we do not want to
complicate the IKEv2 more by making the retry inside the exchange like
we do with INVALID_KE_PAYLOAD, but we could add new error notify that
the responder can send which says INVALID_AUTH_KEY_TYPE, and we could
even add supported key types in that notify. Or we can simply use the
AUTHENTICATION_FAILED notify and assume that it might have been
because of wrong key type, and as we do not have anything better to
do, we can simply retry. Nothing will go through the tunnel anyways
unless we do something... 

> but we do not consider them, do we?

As I said in draft, MD5 is not considered safe enough to be used in
the signatures. It is OK to use in HMAC etc cases, but not with
signatures. 

> could be used with any signature algorithm.

This is feature, not bug as pointed out Johannes Merkle. 

> Actually this is not true, as some algorithms are administratively
> defined only in conjunction with particular hash function. For
> example GOST signature algorithm is defined ONLY with GOST hash.

Which is not problem, as the same policy is in both ends. I.e. if one
end supports GOST it will send GOST hash. If the other end does not
support, it will ignore GOST hash and use some other has (and some
other type of key too). If both ends support GOST hash, and pick GOST
key, they will use GOST hash, as that is only one that is allowed by
their policy.

If one end uses GOST key with any other hash algorithm it is violating
the GOST specification, and it is not expected to work. 

> And even if you could use DSA with SHA-2 or even SHA-3,

You can use DSA with SHA-2. You cannot use it in IKEv2, as the current
DSS signature method is defined to always use SHA-1.

This is one of the reasons we initially started this work. 

> that supports only RSA with 1024 bit keys and no other RSA key sizes.

Agree on that, but it is easy to see that some implementations
supporting RSA keys do support SHA-1, some support SHA-1 and SHA-2 and
so on, so the hash negotiation is also needed there. The
implementation which supports both SHA-1 and 2 for RSA cannot use RSA
with SHA-2 unless it knows the other end can support SHA-2.

I agree that my example with 1024-bit RSA support was not good, but
the problem is that there are no good examples of why people would
want to do implementations which only support some features. I.e. it
makes my point stronger that this problem is not seen in real world.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 28 Oct 2013 15:24:04 +0200

>     encoded using distinguished encoding rules (DER) [X.690].

Added.

> isn't allowed should it be MUST NOT?

If you do not send SIGNATURE_HASH_ALGORITHMS you can use the old types
of the authentication methods. That notify has dual meaning. It
notifices that we support this new types of authentication method, and
the list of hash algoritms supported.

There is no other negotiation of this feature, i.e. the version number
stays same and there is no other notifies to indicate support for
this draft.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 29 Oct 2013 11:05:57 +0400

> of key than what initiator used.

That will not work in case of EAP. 

> signing the EE cert, and send CERTREQ containg that key instead.

Usually corporate CA infrastructure is used not only for IPsec,
and changing CA hierarchy will influence other services too.
Sometimes it is unacceptable.

> even add supported key types in that notify. Or we can simply use the

It is a good idea, but it will not work in case of EAP. If responder picks 
a wrong key, then initiator may send this notification, but it will
require responder to keep this information somewhere untill
initiator retries (if ever). Or we neet to complicate IKE_AUTH
to make retry inside the exchange (as with INVALID_KE_PAYLOAD),
this way it might work. But in this case it is more complex, than just
announcing supported signature algorithms in IKE_SA_INIT.

> unless we do something... 

Not this way, please. That is a real protocol hack, IMHO...

Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Oct 2013 16:12:13 +0200

> That will not work in case of EAP. 

True, so in that case the Initiator needs to use proper CERTREQ or IDr
payload to indicate to which responder key he wants other end to pick.

If you are not happy with CERTREQs doing that you can also use the IDr
in the IKE_AUTH request to tell from the initiator which key should be
used by the responder. 

> Sometimes it is unacceptable.

So then use IDr. That is what it is meant for. I.e. for the initiator
to tell the responder which of multiple identities the responder has
it is connecting to. If responder has multiple keys with different
algorithms, you can configure each of them having different identity
and use that to separate them. 

> initiator retries (if ever).

Yes, it only works if the initiator picked wrong key. On the other
hand as I pointed out there are already 3 ways for the responder to
pick right key (optional IDr in initiators IKE_AUTH request, CERTREQ,
and AUTH payload sent by the initiator).

> Or we neet to complicate IKE_AUTH

Or we just say it is local implementation issue, as I do not really
belive this will happen in real world that often. Or we just say that
implementations having multiple types of public keys SHOULD use
different IDr for each of the keys if there is any possibility that
initiators do not support all of the public key types. 
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 30 Oct 2013 15:40:28 +0400

> payload to indicate to which responder key he wants other end to pick.

We already discussed CERTREQ, it may not always be an indicator.
The same for IDr - IDs are supposed to remain the same with different keys.

> and use that to separate them.

Identities are usually linked to certificate's Subject (or AltSubject) 
field.
And those fields will most probably be the same with different key types.

> and AUTH payload sent by the initiator).

And none of them looks good.

> initiators do not support all of the public key types.

Of course we can always leave it to implemetations by the cost
of lacking interoperability in such situations.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 31 Oct 2013 14:31:43 +0200

> And none of them looks good.

We do have 3 ways proposed to the implementors how they can pick key
if they want to implement them. Some of those will require
configuration changes, some might require external changes, some
requires using certain authentication methods.

For example IDr, IDr does NOT HAVE to come from certificate it can
also have mapping from IDr -> certificate subject key. The RFC4301
says ID is used to find the PAD entry. The PAD entry is then used to
find the X.509 certificate and private key:

----------------------------------------------------------------------
4.4.3.2.  IKE Peer Authentication Data
...
   This document does not require that the IKE ID asserted by a peer be
   syntactically related to a specific field in an end entity
   certificate that is employed to authenticate the identity of that
   peer.  However, it often will be appropriate to impose such a
   requirement, e.g., when a single entry represents a set of peers each
   of whom may have a distinct SPD entry.
...
----------------------------------------------------------------------

> of lacking interoperability in such situations.

This is implementation issue anyways. The implementations do have
information (IDr, CERTREQ, AUTH payload algoritm other end sent, PAD
entry, IP address etc) and then the implementation will pick the
private key to be used and the associated certificate.

I do not want to make this even more complex by adding yet another way
to send the same information.

I assume you problem is that implementations you are thinking of, are
too limited in the way they can express the IDr -> PAD -> private key
-> certificate mapping, and thats why you think that solution is not
suitable.

That does not have to be that way, as the RFC4301 already allows all
kind of things there, and there is nothing for allowing
implementations to implement that kind of code.

The fact that current implementations do not do that, is most likely
because implementors have not felt it would be important enough
feature for them to implement.

This document will require changes in the implementation anyways, so
those implementors who feel this situation is common enough to require
special coding can implement the IDr processing in their code... 
-- 
[email-masked]