Re: Comments on draft-ietf-secsh-x509-00

[Henrick Hellström <henrick%streamsec.se@localhost>]

Joseph Galbraith wrote:

> Henrick Hellström wrote:
> > I can only see a point in using X.509 certificates with SSH, in case
> > secure distribution of public keys between the server and the clients is
> > not feasible.
>
>
> To be honest, this covers most SSH cases, right?
>
> Or at least, in most cases, password authentication must also
> be enable to enable the secure distribution of publickeys,
> and host keys are generally not distributed securely.

I haven't conducted any empirical studies of actual world wide SSH usage 
(<g>), but I would argue e.g. that it is recommended to only accept 
server host keys you already acquired securely out-of-band.

For example, if you use SSH for connecting to your home computer from 
work (or vice versa), it would be recommended to not let the client 
software accept any public key sent by the server unless it is identical 
to the one you carry with you on an USB stick.

Please note that I don't buy any arguments of the kind: "We already have 
a PKI infrastructure and management tells us to use it for everything so 
we really want to send X.509 certificates over SSH." If the host already 
maps user accounts to KNOWN certificates, the server might just as well 
extract the public keys from the certificates and use them as regular 
public keys.

The only valid reason I can see for using X.509 certificates would be to 
take advantage of the fact that a trusted CA has already mapped the name 
of the certificate subject to the private key of certificate subject. 
IOW the host administrator would just have to enter the username (and 
possibly other personal info likely to end up in a certificate) of a new 
user into a database (what ever), and send an unprotected email to the 
user instructing him to get a client certificate. Note that no 
confidential (password) or authenticated (publickey) information is 
exchanged directly between the host and the user at this stage. The 
client would instead go to a trusted CA to get a client certificate. The 
first time the client connects with the certificate the server would be 
able to immediately authenticate the identity of the user.


> When the certificate is used as a hostkey, either the subject name
> or the subjectaltname SHOULD match the canonical name of the server.
> (Are their multiple names in the subject name or subject alt name;
> I don't recall?)
>
> Or should match the name used by the user?  Are there DNS issues
> in saying canonical name?

I don't know. Typically, server certificates used by SSL/TLS servers 
have a subject.commonName identical to the *domain name* of the server.

Note that both the subject name and the subjectAltName might contain a 
lot of other name fields, such as organizationName, country, 
stateOrProvince, etc.


> And what you are saying here is that the draft ought to include text
> along the lines of:
>
> When the certificate is used as part of publickey authentication,
> the username specified in the publickey packet SHOULD match
> either the subject name or the subjectAltName in the certificate.

It is a lot more complex than that. Perhaps it would be a better idea to 
state that the user<->certificate mapping is assumed to be 
implementation specific and/or server specific.


> > > 2) text regarding KeyUsage and ExtendedKeyUsage.
> >
> >
> > This is application specific, so it should go into the secsh-x509 spec.
>
>
> It sounds like there is a missing 'not' in this sentance?
>
> If their isn't a missing 'not', can you give me some more
> details as to what you are thinking?

No, there is no 'not' missing. Example:

"A host server certificate SHOULD include the id_kp_serverAuth OID in 
the extKeyUsage extension, and a client user certificate SHOULD include 
the id_kp_clientAuth OID. The extKeyUsage extension SHOULD be marked as 
critical. Client implementations SHOULD reject host server certificates 
that contain the id_kp_clientAuth OID in the extKeyUsage extension, and 
server implementations SHOULD reject client certificates that contain 
the id_kp_serverAuth OID in the extKeyUsage extension."

Please note that I don't suggest that the above paragraph should be 
added. It just serves as an example of an application specific PKI policy.


--
Henrick Hellström
www.streamsec.com