ECC Key Usage ignored with and ECDH(E) ciphers

[Xuelei Fan]

On 5/23/2017 1:34 PM, Bernd Eckenfels wrote:
> Hello,
> 
> It is a PKIX KeyManager with a loaded P12 key store. But I tried quite a 
> few alternatives, so maybe there is something wrong within all the 
> commented code. If you think it should work I can try to clean it up for 
> reproduction.
> 
I think, it is needed to check the KeyAgreement key usage in both 
key/trust manager in the JSSE implementation.  I appreciate it very much 
if you can help and clean up the test code for reproduction.

Thanks & Regards,
Xuelei

> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *From:* Xuelei Fan <xuelei.fan at oracle.com>
> *Sent:* Tuesday, May 23, 2017 9:12:10 PM
> *To:* Bernd; security-dev at openjdk.java.net
> *Subject:* Re: ECC Key Usage ignored with and ECDH(E) ciphers
> Hi Bernd,
> 
> What are the JSSE key/trust managers used for the testing ("SunX509" or
> "PKIX")?
> 
> Thanks & Regards,
> Xuelei
> 
> On 5/23/2017 7:08 AM, Bernd wrote:
>> Hello,
>> 
>> according to RFC 4492 the key usage for ECDHE and ECDH ciphers need to 
>> be observed in regards to key agreement: When I use ECDH_ECDSA ciphers 
>> then the server certificate must have the keyAgreement usage. When I use 
>> ECDHE_ECDSA ciphers then the server certificate must have 
>> "digitalSignature".
>> 
>> # Note that there is no structural difference between ECDH and ECDSA
>> # keys.  A certificate issuer may use X.509 v3 keyUsage and
>> # extendedKeyUsage extensions to restrict the use of an ECC public key
>> # to certain computations [15 <https://tools.ietf.org/search/rfc4492#ref-15>].  This document refers to 
> an ECC key as
>> # ECDH-capable if its use in ECDH is permitted.  ECDSA-capable is
>> # defined similarly.
>> 
>> 
>> This rule is enforced by the openssl s_client: when the server proposes 
>> a cipher which does not pass this check it will terminate the connection:
>> 
>>  > openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect 
>> localhost:1234
>>  > 1252:error:1411713E:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc 
>> cert not for signing:.\ssl\ssl_lib.c:2512:
>>  > 1252:error:14082130:SSL routines:ssl3_check_cert_and_algorithm:bad 
>> ecc cert:.\ssl\s3_clnt.c:3544:
>> 
>> In this case the certificate had key usage:
>> 
>>  > [ server-exch ]
>>  > extendedKeyUsage = serverAuth
>>  > basicConstraints = CA:FALSE
>>  > keyUsage = keyAgreement
>>  > subjectAltName=IP:127.0.0.1,DNS:localhost.
>> 
>> The connect with static ECDH works:
>> 
>>  > openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234
>> ...
>>  > SSL-Session:
>>  >    Protocol  : TLSv1.2
>>  >    Cipher    : ECDH-ECDSA-AES128-SHA256
>> 
>> The other way around, when I use the following key usage:
>> 
>>  > [ server-sign ]
>>  > extendedKeyUsage = serverAuth
>>  > basicConstraints = CA:FALSE
>>  > keyUsage = digitalSignature
>>  > subjectAltName=IP:127.0.0.1,DNS:localhost.
>> 
>> OpenSSL client works this way:
>> 
>>  >openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234
>>  >9916:error:1411713D:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc 
>> cert not for key agreement
>> 
>>  >openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect localhost:1234
>>  >SSL-Session:
>>  >    Protocol  : TLSv1.2
>>  >    Cipher    : ECDHE-ECDSA-AES128-SHA256
>> 
>> In both cases however JSSE (OracleJDK8u121 or OpenJDK 9-ea+162) will 
>> offer both cipher suites and not filter them by key usage capabilties. 
>> Would you agree this is a bug? And should this also apply to client 
>> side? I have not tested it with RSA certificates, but I would expect 
>> this to be the same.
>> 
>> Gruss
>> Bernd
>> 
>> PS: config file and openssl commands to create multiple ECC certificates 
>> used for this test:
>> https://gist.github.com/ecki/d66d79bf0cf12872d015804f5edec6e4
>> 
>>