Subject: [IPsec] New Version Notification for draft-kivinen-ipsecme-signature-auth-00.txt

From: Tero Kivinen <[email-masked]>
Date: Tue, 4 Dec 2012 16:24:47 +0200

I posted first version of the signature authentication method. This is
based on the design team work on the ECDSA, but as the design team
decided not to forbid other authentication methods, I named the draft
to signature-auth, not ecdsa-auth.

This draft is initial version, meaning it has still some things
missing. I would need some good references for different things, and
then there is missing the text about the guidance how to select
suitable hash functions. We decided that adding such guidance is good
idea, but design team didn't specify what such guidance should say, so
I need more input for that.

Another thing is that we need to decide whether we want to fully
support RSASSA-PSS. The current draft only includes the OID from the
AlgorithmIdentifier field, thus it cannot be used with RSASSA-PSS when
parameters are used (as pointed out by Sean earlier). Actually I am
not sure whether we can even use it with defaults, i.e. can RSASSA-PSS
be used at all. We might need to add text saying it is always used
with default parameters or something.

To fully support RSASSA-PSS we would need to include full
AlgorithmIdentifier ASN.1 including the parameters. I myself would
think that would be best option, as that would allow widest possible
use for this new method, i.e. we can support whatever PKIX does. Some
design team members disagreed, and we ended up with the current
compromize...

Other things:

In my draft I say:
----------------------------------------------------------------------
			   For the hash truncation the method of
      X9.62, SEC1 and IO 14888-3 MUST be used.  XXX Need reference for
      X9.62/SEC1 etchere XXX.
----------------------------------------------------------------------

I.e. the draft points to this hash truncation method. Does anybody
have proper reference for that, and it might be good if we could
summarize it here too, as not all people have access to those other
specifications.

In security considerations section I have text:
----------------------------------------------------------------------
   The hash algorithm registry does not include MD5 as supported hash
   algorithm, as it is not considered safe enough for signature use.

      XXX Need reference for MD5 considered unsafe.  XXX
----------------------------------------------------------------------

Does anybody have good reference for MD5 especially with signatures
(not with HMAC).

In the security considerations section I also have:
----------------------------------------------------------------------
   The current IKEv2 uses RSASSA-PKCS1-v1_5, and does not allow using
   newer padding methods like RSASSA-PSS.  This new method allows using
   other padding methods.

      XXX Need reference for RSASSA-PSS vs RSASSA-PKCS1-v1_5 security.
      XXX
----------------------------------------------------------------------

RFC4055 says

"   The RSASSA-PSS signature algorithm is preferred over the PKCS #1
   Version 1.5 signature algorithm.  Although no attacks are known
   against PKCS #1 Version 1.5 signature algorithm, in the interest of
   increased robustness, RSASSA-PSS signature algorithm is recommended
   for eventual adoption, especially by new applications."

Is this still the case, or do we have some reference which would point
out why RSASSA-PSS is better.... Of course if we cannot support
RSASSA-PSS with the this new method properly, this text in the
security considerations section might not be needed...

In the security considerations section:
----------------------------------------------------------------------
      XXX The text about the guidance how to select suitable hash
      functions is missing here.  XXX
----------------------------------------------------------------------

I.e we need to guidance or references to good guidance. As this draft
is no longer only ECDSA, the RFC5480 might not be enough. For RSA, or
normal DSA might also need some guidance. What kind of guidance do we
want here.

[email-masked] writes:
> 
> A new version of I-D, draft-kivinen-ipsecme-signature-auth-00.txt
> has been successfully submitted by Tero Kivinen and posted to the
> IETF repository.
> 
> Filename:	 draft-kivinen-ipsecme-signature-auth
> Revision:	 00
> Title:		 Signature Authentication in IKEv2
> Creation date:	 2012-12-04
> WG ID:		 Individual Submission
> Number of pages: 9
> URL:             http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-signature-auth-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth
> Htmlized:        http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-00
> 
> 
> Abstract:
>    The Internet Key Exchange Version 2 (IKEv2) protocol has limited
>    support for the Elliptic Curve Digital Signature Algorithm (ECDSA).
>    The current support only includes support for three Elliptic Curve
>    groups, and there is fixed hash algorithm tied to each curve.  This
>    document generalizes the IKEv2 signature support so it can support
>    any signature method supported by the PKIX and also adds signature
>    hash algorithm negotiation.  This generic mechanism is not limited to
>    ECDSA, but can also be used with other signature algorithms.
-- 
[email-masked]

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 04 Dec 2012 19:11:31 +0100

Hi Tero,

> to signature-auth, not ecdsa-auth.

Thanks for your work.

> design team members disagreed, and we ended up with the current

If RSA-PSS keys are used then this should not be an issue. In this case the SPKI of the cert specifies the parameters to
be used. However, RSA-PSS keys are hardly supported yet.
If the SPKI includes just an rsaEncryption OID, there are several problems:
- A peer with an RSA signing key supporting RSA-PSS has no means to determine if the other peer supports PSS as well or
if he should better fall back to PKCS#1v1.5. At least he can find out with trial and error.
- When verifying a RSA-PSS signature based on a certificate specifying rsaEncryption in SPKI, additional information on
the parameters used are needed.
I would also advocate inclusion of parameters in the AlgorithmIdentifier inside Authentication Data. In most cases
(except RSA-PSS with non-standard parameters) it is NULL, but I don't think, this is a problem.

> In my draft I say:

I have been the one bringing up this issue, so I should comment on this ;-)
The issue is that ISO 15946-2 defines a different hash truncation method. But actually, ISO 15946-2 is deprecated
(withdrawn) in favor of ISO 14888. Therefore, I don't think we need to specify anything w.r.t hash truncation. It is now
uniformly defined in all current standards.

> In security considerations section I have text:
Wikipedia list a good reference: Xiaoyun Wang; Hongbo Yu (2005). "How to Break MD5 and Other Hash Functions".

If you  are looking for standards... NIST SP 800-57 does not list MD5 as approved but does not explicitly mention it as
ineligible. An explicit caveat is included in ETSI TS 102 176-1
"Recently some new attacks against hash function MD5
succeeded, it was shown that MD5 is not collision
resistant by constructing classes of messages-pairs
with the same hash value. Whereas the loss of collision
resistance does not imply that a pre-image or second
pre-image can easier be constructed, it is recommended
to migrate to other hash functions, if the collision
resistance becomes weaker."
However, this standard is is from 2005 and focuses on Secure Electronic Signatures. Is this a problem?

> In the security considerations section I also have:
There are attacks against implementations not checking for garbage after the hash value when using public exponent e=3
(a very special case, but the best attack I know of).
http://csrc.nist.gov/groups/ST/toolkit/documents/dss/RSAstatement_10-12-06.pdf
As permanent reference, this one is better:
Ulrich Kuehn, Andrei Pyshkin, Erik Tews, Ralf-Philipp Weinmann: Variants of Bleichenbacher's Low-Exponent Attack on
PKCS#1 RSA Signatures. Proceedings of Sicherheit 2008, pp. 97-109.

> In the security considerations section:

NIST SP 800-57, Tables 2 in combination with Table 3. It seems that RFC 4055 also point to an early draft of NIST SP 800-57.

-- 
Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Wed, 05 Dec 2012 19:15:32 +0100

Hi Tero,

some additional feedback:

Introduction:
In the paragraph 4 you point out the two achievements of the draft:
- A generalized authentication method for authentication with digital signatures
- A negotiation method for the hash function used as message digest within the signature
The motivation should be structured to reflect this distinction. In particular, the first and third paragraphs motivate
the authentication method, while the second one motivates the second one. As ECDSA groups, RSASSA-PSS and DSA with other
hash than SHA-1 all point to deficiencies of the old authentication method, I would use a list.
How about the following?

The current signature based authentication methods in the IKEv2 are per
   algorithm, i.e. there is one for RSA Digital signatures, one for DSS
   Digital Signatures (using SHA-1) and three for different ECDSA curves
   each tied to exactly one hash algorithm.  This design starts to be
   cumbersome when more signature algorithms, hash algorithms and elliptic
   curves are to be supported:
     * The RSA Digital Signatures format in the IKEv2 is specified to use
       RSASSA-PKCS1-v1_5 padding, but [RFC 4055] and [PKCS1] recommend the
       use of the newer RSASSA_PSS. This new padding method is specified by
       additional parameters and for each parameter set to be supported new
       authentication methods would be required.
     * With ECDSA and DSS there is no way to extract the hash algorithm from
       the signature, thus, for each new hash function to be supported with
       ECDSA or DSA new authentication methods would be needed. Support for
       new hash functions is particularly needed for DSS because the current
       restriction to SHA-1 limits its security, meaning there is no point
       of using long keys with it.
     * The tying of ECDSA authentication methods to particular elliptic curve
       groups requires definition of additional methods for each new group.
       By combination of new ECDSA groups with various hash functions the
       number of required authentication methods may grow unmanageable.
       Furthermore, the restriction of ECDSA authentication to a specific
       group is inconsistent with the approach taken with DSS.

   With the selection of SHA-3 [Ref_TBD], it is seen that it might be
   possible that in the future the signature methods are used with SHA-3
   also, not only SHA-2.  This means new mechanism for negotiating the
   hash algorithm for the signature algorithms is needed.

>   The new digital signature method needs to be flexible enough to
>   include all current signature methods (ECDSA, ECGDSA, RSASSA-PSS,
>   ElGamal, etc),
The term "current signature methods" is not precise. Currently used with IKE? Currently used in practice at all?
Currently specified in standards (which ones)?
Actually:
- the new authentication method is agnostic to the signature algorithm (like X.509 or CMS are) as far as an ASN.1
algorithm identifier exists. (This holds true only, if parameters of the algorithm can be included)
- The hash negotiation method supports only those hash algorithms for which code points have been defined.

Furthermore, I suggest not to list specific signature methods supported, as some of them (ECDSA) are common while others
are not. This may provoke discussion, in particular, as RSA with PKCS#1v1.5 as the most common one (by far) is not listed.

Best regards,
Johannes

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 7 Dec 2012 15:49:11 +0200

Johannes Merkle writes:
> If RSA-PSS keys are used then this should not be an issue. In this
> case the SPKI of the cert specifies the parameters to be used.

Even in that case we need to say in this draft that the RSASSA-PSS
parameters are taken from the SPKI of the cert. If the SPKI includes
parameters, are those the only parameters that can be used with the
cert, i.e. does that mean that you cannot use any other hash than what
is speficied there (I am not familiar enough with RSASSA-PSS to know
how it works). 

> However, RSA-PSS keys are hardly supported yet. If the SPKI includes
> just an rsaEncryption OID, there are several problems:
> - A peer with an RSA signing key supporting RSA-PSS has no means to
> determine if the other peer supports PSS as well or if he should
> better fall back to PKCS#1v1.5. At least he can find out with trial
> and error.

Or by configuration / policy. I.e. if the policy says RSASSA-PSS is to
be used, then it can be assumed it also works for those peers where
the policy requires it...

I do not think this is going to be problem in general case. The IPsec
configuration usually have quite a lot of all kind of configuration /
policy information in both ends and some of those needs to match.

> - When verifying a RSA-PSS signature based on a certificate
> specifying rsaEncryption in SPKI, additional information on the
> parameters used are needed.

But the problem is when you do know from the configuration that other
end do support RSASSA-PSS, and you can see the supported hash
functions from the SIGNATURE_HASH_ALGORITHMs, but you do not know
which hash function the other end uses, as the RSASSA-PSS oid does not
include it... I think that is much bigger problem. 

> I would also advocate inclusion of parameters in the
> AlgorithmIdentifier inside Authentication Data. In most cases

Yep.

> I have been the one bringing up this issue, so I should comment on
> this ;-) The issue is that ISO 15946-2 defines a different hash
> truncation method. But actually, ISO 15946-2 is deprecated
> (withdrawn) in favor of ISO 14888. Therefore, I don't think we need
> to specify anything w.r.t hash truncation. It is now uniformly
> defined in all current standards.

So do you have any RFC that we can point to which specifies the hash
truncation? If there ever has been two ways of doing things, I would
like to point to some place where it is clear which way is used here,
even when the other way has already been deprecated.

> Wikipedia list a good reference: Xiaoyun Wang; Hongbo Yu (2005).
> "How to Break MD5 and Other Hash Functions".

Added that...

> If you are looking for standards... NIST SP 800-57 does not list MD5
> as approved but does not explicitly mention it as ineligible. An
> explicit caveat is included in ETSI TS 102 176-1 "Recently some new
> attacks against hash function MD5 succeeded, it was shown that MD5
> is not collision resistant by constructing classes of messages-pairs
> with the same hash value. Whereas the loss of collision resistance
> does not imply that a pre-image or second pre-image can easier be
> constructed, it is recommended to migrate to other hash functions,
> if the collision resistance becomes weaker." However, this standard
> is is from 2005 and focuses on Secure Electronic Signatures. Is this
> a problem?

I think the the "How to break MD5 ..." paper is good enough. 

> There are attacks against implementations not checking for garbage
> after the hash value when using public exponent e=3 (a very special
> case, but the best attack I know of).
> As permanent reference, this one is better: Ulrich Kuehn, Andrei
> Pyshkin, Erik Tews, Ralf-Philipp Weinmann: Variants of
> Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures.
> Proceedings of Sicherheit 2008, pp. 97-109.

This just points the problems in the PKCS#1 RSA signatures, but does
not mention anything about RSASSA-PSS.

Anyway I added that reference as it points out reasons why RSASSA-PSS
might be needed...

> NIST SP 800-57, Tables 2 in combination with Table 3. It seems that
> RFC 4055 also point to an early draft of NIST SP 800-57. 

Added following text:

   The "Recommendations for Key Management" ([NIST800-57]) table 2
   combined with table 3 gives recommendations for how to select
   suitable hash functions for the signature.
-- 
[email-masked]

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 07 Dec 2012 16:09:13 +0100

> is speficied there (I am not familiar enough with RSASSA-PSS to know

Yes, restriction to the specified parameters is exactly the semantics of the parameter field of the SPKI. Section 1.2 of
RFC 4055 states:
   When a certificate conveys an RSA public key with the id-RSASSA-PSS
   object identifier, the certificate user MUST only use the certified
   RSA public key for RSASSA-PSS operations, and, if RSASSA-PSS-params
   is present, the certificate user MUST perform those operations using
   the one-way hash function, mask generation function, and trailer
   field identified in the subject public key algorithm identifier
   parameters within the certificate.

> policy information in both ends and some of those needs to match.

Agreed. Still it could be useful to hint to this potential issue.

> include it... I think that is much bigger problem. 
This is just part of the problem I referred to: The hash function used as message digest is part of the parameters.
The parameters consist of 4 parts, for many of which recommendations exist in RFC 4055:

1. HashAlgorithm is the hash function used for computing the message digest. In contrast to PKCS#v1.5 the hash function
is applied twice, first only to the message, the to the resulting hash concatenated with a fixed padding and a salt.
2. maskGenAlgorithm is the mask generating function for computing the padding. RFC 4055 only support the MFG-1
construction based on SHA-1 or SHA-2. RFC 4055 strongly recommends that the underlying hash function of MFG-1 be the
same as the one identified by hashAlgorithm. I.e., when following this recommendation, the maskGenAlgorithm is uniquely
defined by HashAlgorithm.
3. saltLength. Although RFC 4055 specifies a default length of 20 octets, it recommends that saltLength is the number of
octets in the hash value. I.e., when following this recommendation, the saltLength is uniquely defined by HashAlgorithm.
4. trailerField. RFC 4055 requires it to be 0xBC. So, there is also no choice left.

Thus, when following the recommendations of RFC 4055, there are only 5 parameter sets left:
Set1: (SHA-1, mgf1SHA1Identifier, 20, 0xBC)
Set2: (SHA-224, mgf1SHA224Identifier, 28, 0xBC)
Set3: (SHA-256, mgf1SHA256Identifier, 32, 0xBC)
Set4: (SHA-384, mgf1SHA384Identifier, 48, 0xBC)
Set5: (SHA-512, mgf1SHA512Identifier, 64, 0xBC)
I really wonder, why RFC 4055 has not defined simple OIDs for these 5 parameter combinations. This would make
implementations limited to RFC 4055 recommended parameters much easier. And I really see no need to deviate from these
recommendations. If we limit IKEv2 authentication with RSASSA-PSS to these sets, we could specify the missing OIDs and
forget about the parameter field. Or we could ask the pkix WG if they are willing to issue an RFC defining these 5 OIDs
for simplified use?

> even when the other way has already been deprecated.

I just looked it up in RFC 6090 and detected that there the hash value is _not truncated_, which is one more reason to
clarify this in our draft. There is no RFC defining the ECDSA algorithm and most RFCs refer to ANSI X9.62. So this is
the  proper reference.

> not mention anything about RSASSA-PSS.

The reason why RSASSA-PSS is considered better is because there is a security proof (w.r.t adaptive chosen-message
attacks) in the random oracle model. A good reference for a fair comparison with the conclusion that RSASSA-PSS is
preferable is
Alfred Menezes. Evaluation of Security Level of Cryptography: RSA-OAEP, RSA-PSS, RSA Signature. Technical Report,
University of Waterloo, 2001
However, this paper is quite old and does not consider the latest attacks against the old padding method.

-- 
Johannes

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 10 Dec 2012 16:54:54 +0200

Johannes Merkle writes:
> Yes, restriction to the specified parameters is exactly the
> semantics of the parameter field of the SPKI. Section 1.2 of 
> RFC 4055 states:

Ok, I should add pointer to that in my draft.

What happens if the RSASSA-PSS-params is NOT present? Do we use
defaults, or is the certificate user allowed to pick any hash/mask etc
he feels like? If it can use any hash, then we still have problem as
the receipient cannot know which hash the other end picked.

Added following text to my draft:

----------------------------------------------------------------------
    Note, that if the RSASSA-PSS is used, and if the public key is
    specified with id-RSASSA-PSS and there is RSASSA-PSS-params, then
    those params needs to be used as specified in the Section 1.2 of
    the RFC4055 ([RFC4055]).
----------------------------------------------------------------------

> Agreed. Still it could be useful to hint to this potential issue.

Yep. And I also want to add similar text to my raw public key draft,
pointing out that if it is used to send RSASSA-PSS keys inside the
SPKI of the raw key, then you still need to follow the RFC4055, even
when the SPKI is not inside the Certificate payload.

> This is just part of the problem I referred to: The hash function
> used as message digest is part of the parameters. The parameters
> consist of 4 parts, for many of which recommendations exist in RFC
> 4055:
> 
> 1. HashAlgorithm is the hash function used for computing the message
> digest. In contrast to PKCS#v1.5 the hash function is applied twice,
> first only to the message, the to the resulting hash concatenated
> with a fixed padding and a salt.
>
> 2. maskGenAlgorithm is the mask generating function for computing
> the padding. RFC 4055 only support the MFG-1 construction based on
> SHA-1 or SHA-2. RFC 4055 strongly recommends that the underlying
> hash function of MFG-1 be the same as the one identified by
> hashAlgorithm. I.e., when following this recommendation, the
> maskGenAlgorithm is uniquely defined by HashAlgorithm.
>
> 3. saltLength. Although RFC 4055 specifies a default length of 20
> octets, it recommends that saltLength is the number of octets in the
> hash value. I.e., when following this recommendation, the saltLength
> is uniquely defined by HashAlgorithm.
>

And in future there might be update to the RFC 4055, which adds new
hash functions to it... 

> I really wonder, why RFC 4055 has not defined simple OIDs for these
> 5 parameter combinations. This would make implementations limited to
> RFC 4055 recommended parameters much easier. And I really see no
> need to deviate from these recommendations. If we limit IKEv2
> authentication with RSASSA-PSS to these sets, we could specify the
> missing OIDs and forget about the parameter field. Or we could ask
> the pkix WG if they are willing to issue an RFC defining these 5
> OIDs for simplified use?

Or we can simply add the whole AlgorithmIdentifier sequence, which
would include the OID and parameters in front the signature, and that
will also take care of the problem. 

> I just looked it up in RFC 6090 and detected that there the hash
> value is _not truncated_, which is one more reason to clarify this
> in our draft. There is no RFC defining the ECDSA algorithm and most
> RFCs refer to ANSI X9.62. So this is the proper reference.

Ok, added:

----------------------------------------------------------------------
			For the hash truncation the method of
      X9.62 ([X9.62]) MUST be used.
...
   [X9.62]    American National Standards Institute, "Public Key
              Cryptography for the Financial Services Industry: The
              Elliptic Curve Digital Signature Algorithm (ECDSA)",
              ANSI X9.62, November 2005.
----------------------------------------------------------------------

> The reason why RSASSA-PSS is considered better is because there is a
> security proof (w.r.t adaptive chosen-message attacks) in the random
> oracle model. A good reference for a fair comparison with the
> conclusion that RSASSA-PSS is preferable is Alfred Menezes.
> Evaluation of Security Level of Cryptography: RSA-OAEP, RSA-PSS, RSA
> Signature. Technical Report, University of Waterloo, 2001 However,
> this paper is quite old and does not consider the latest attacks
> against the old padding method.

Added that

----------------------------------------------------------------------
   The current IKEv2 uses RSASSA-PKCS1-v1_5, which do have some problems
   ([KA08], [ME01]) and does not allow using newer padding methods like
   RSASSA-PSS.  This new method allows using other padding methods.
...
   [KA08]     Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann,
              "Variants of Bleichenbacher's Low-Exponent Attack on
              PKCS#1 RSA Signatures", Proc. Sicherheit 2008 pp.97-109.

   [ME01]     Menezes, A., "Evaluation of Security Level of
              Cryptography: RSA-OAEP, RSA-PSS, RSA Signature",
              December 2001.
-- 
[email-masked]