[ssh_x509] Validating host with certificate chain

ssh_x509 at roumenpetrov.info ssh_x509 at roumenpetrov.info
Fri May 19 08:06:23 EEST 2017


On May 17, 2017, at 11:32 PM, ssh_x509 at roumenpetrov.info wrote:
> ssh_x509 at roumenpetrov.info wrote:
>> [SNIP]
>> Does pkixssh do the other validations mentioned in RFC 6187? In particular, I’m thinking about:
>> 
>>    Additionally, the following constraints apply:
>> 
>>    o  The sender's certificate MUST be the first certificate and the
>>       public key conveyed by this certificate MUST be consistent with
>>       the public key algorithm being employed to authenticate the
>>       sender.
> (1s) Server does not validate that "sender's certificate MUST be the first certificate". Note dependency from second constraint. Server assumes this.
> (1c) On load client expect first loaded certificate from key material to match private key. This is not related to rfc6187. Control was implemented long time ago.

[Ron] Yeah - the RFC doesn’t dictate anything about where the keys come from on the local system. They could be in the same file as the private key or a totally different file (like the “-cert.pub” files used in the OpenSSH certificate case), or something entirely different. However, I was asking here about validating what goes on the wire in the “public key” data that is sent by the server during the key exchange or the client during public key authentication.


> Algorithm is checked. This is not related to RTF6187. It is checked even for "plain keys”.

[Ron] Ok. When matching on allowed algorithms, though, it seems like there’s some leniency here, where the older x509v3-sign-* types and the newer x509v3-ssh-* types are treated as both allowed, even when the config says only one of them is allowed.


>>    o  Each following certificate MUST certify the one preceding it.
> (1s) On server side - no. I chose non-restrictive model more or less based on functionality of cryptographic library .
> OpenSSL Verification requested two stores "trusted" and "untrusted": root certificate must be in "trusted". root in "untrusted" is ignored. Additional certificates from key in rfc6187 format are passed to untrusted (dunno why I forgot to pass them).

[Ron] I see. I guess if you already have OpenSSL able to reconstruct the chain for you, there isn’t much harm in allowing other orderings.


> (2c) On client side: yes since 9.0 chain is build internally, so order is correct. In 8.* certificate was send is same order as loaded from file.
> 
>>    o  The self-signed certificate specifying the root authority MAY be
>>       omitted.  All other intermediate certificates in the chain leading
>>       to a root authority MUST be included.
> (3c) On client side yes - since 9.0 client sends root certificate and all intermediate are included (see 2c).

[Ron] I was a bit surprised that pkixssh was sending the root certificate here. While the RFC allows for the root CA to optionally be included, it doesn’t require it, and I’m not sure there’s any value in sending it. It needs to already be present on the other side in the trust store, or the validation of the chain will fail. It would save a bit of bandwidth if it was left out.


> (3s) Server side is less restrictive : more or less because is not required by crypto-backend - openssl build chains internally.
> 
>> I did a quick test and it looks like it enforces the first constraint on the server side when first loading the keys, but I’m not sure if it enforces this on the client side.
> Process is bidirectional (public key from client to server, host key from server to client) and in bot direction processing is same.
> I mean that for host keys daemon work according "client" rules above (1c 2c 3c) . Client behaviour is same as rules 1s, 2s, 3s.
>> The second point doesn’t appear to be enforced on either side right now. I tried adding an unrelated cert into the middle of the list of certificates and the server didn’t error out. It sent all 3 certificates to the client, and the client still validated the chain just fine, despite the extra certificate not certifying the one before it, or being certified by the certificate after it.
> So in 8.* as client/server sends certificates as they are loaded you could insert a lot of unrelated certificates - manual process.
> In 9.0 extra certificate from key are loaded into untrusted store and along with trusted one are used to build chain . Only certificates from chain are send.

[Ron] Ok, thanks.

>> Also, do you do validation of the OCSP responses included with the certificates?
> 
> I prefer do not implement this, i.e. client(sender) does not send and server(receiver) ignore OCSP part.
> More or less because:
> - I prefer to avoid extra complexity in programs
> - OCSP validation was implemented long time ago expired from past configuration of Mozilla's based browsers.
> 
> Lets review option VAType (pkixssh client or server):
> 
> (a) none: do not use OCSP to validate certificates;
> (b) ocspcert:validate only certificates that specify ‘OCSP Service Locator’ URL;
> (c) ocspspec:use specified in the configuration ‘OCSP Responder’ to validate all certificates.
> 
> In the past (c) was allowed to be set in Mozilla's configuration but today it is only a check box: checked/unchecked <-> ocspcert/none.

[Ron] I tend to agree about not wanting to implement an OCSP client. I was actually asking about the “stapled” OCSP responses that are provided as part of the public key data, though. In addition to the intermediate CAs in the chain, RFC 6187 allows for the certificate data to include already constructed OCSP responses for each of the certificates which are sent. This saves the peer from having to implement the code to send an OCSP request, but it still allows for the revocation status of each of the certificates to be validated, at least as of the time the OCSP response was constructed.

Thanks for taking the time to answer my questions!
-- 
Ron Frederick
ronf at timeheart.net






More information about the ssh_x509 mailing list