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

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 23 Mar 2005 20:55:07 -0500

[WG chair hat off...]

I've been following the efforts of the PKI4IPsec working group as it
struggles to hash out a profile for the use of X.509 with IPsec.  

In reading this document I'm struck by how little it says about what
ought to go inside certificates.  

I would have hoped to see:

 1) expected relationship(s), if any between the certificate Subject
and/or subjectAltName fields and the identity of the server or user
which owns the certificate.  (This of course opens up the "Naming is
Hard" discussion.)

 2) text regarding KeyUsage and ExtendedKeyUsage.

 3) text regarding recommendations for certificate revocation checks.

 4) discussion of how to handle certificate chains.

 5) more text about the use of certificates for user authentication or a
claim that it's entirely out of scope for the document..

and I bet someone who actually follows PKIX closely would have a
somewhat longer list of concerns...

						- Bill

---

From: Henrick Hellström <[email-masked]>
Date: Thu, 24 Mar 2005 08:48:13 +0100

> which owns the certificate.  (This of course opens up the "Naming is 

I mostly agree with these points. Without these there seems to be little
point in using X.509 certificates at all.

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.

In the case of naming, what would really make sense would be a
relationship between:

a) On one hand the URI and version string of the server, and on the
other hand the subject and/or subjectAltName of the server certificate
b) On one hand the username of the client, and on the other hand the
subject and/or subjectAltName of the client certificate.

The presumption of the secsh wg ought to be that the URI of the server
and the username of the client user already identifies these entities.

The draft should not go into details about the theory of names. If any,
such discussions should occur in the X.509 documents and/or Analytical
Philosophy 101.

> 2) text regarding KeyUsage and ExtendedKeyUsage.

This is application specific, so it should go into the secsh-x509 spec.

> 4) discussion of how to handle certificate chains.

These two points are already covered by PKIX documents. I don't think
there are any secsh specific considerations here.

> 5) more text about the use of certificates for user authentication or
> a claim that it's entirely out of scope for the document..

Agreed.

-- 
Henrick Hellström
www.streamsec.com

---

From: Oskari Saarenmaa <[email-masked]>
Date: Thu, 24 Mar 2005 16:39:52 +0200

> which owns the certificate.  (This of course opens up the "Naming is

Host certificate matching against the server name should probably be 
mentioned in the Implementation Considerations section.  Currently there 
are implementations that check either the host certificate subject CN, 
subjectAltName DNS names, or both, so we should recommend checking both 
of these for interoperability purposes.

Defining how to use user certificates is out of scope for this document 
in my opinion; mapping of certificates to system accounts is mostly just 
a configuration issue.  There are a lot of different ways to do it, and 
I don't think we should place any requirements for the format of the 
certificates.

>  4) discussion of how to handle certificate chains.

These are already covered by other documents.  I don't really see the 
need for new ssh-specific extendedKeyUsage flags.

Regards,
Oskari

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 24 Mar 2005 10:25:27 -0500

> there are any secsh specific considerations here.

There's at least one:  we should either provide an in-band way to carry
cert chains, CRL's, OCSP, etc., or explicitly declare that such traffic
must flow out-of-band.

A use case which came up in pki4ipsec: a firewalled enclave with its pki
infrastructure inside it, with <insert protocol name here> as the only
way in. 

I was in some sense trolling for text explicitly ruling that use case
out of scope for this document....

						- Bill

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 24 Mar 2005 10:08:12 -0700

> cert chains, CRL's, OCSP, etc., or explicitly declare that such traffic

Well... hmmm...

Now, I'll admit, I'm not an PKI expert (I'm an SSH expert which is why
you got a document describing how to encode x.509 into the SSH protocol 
:-)  So perhaps this is naive...

But, can we really safely carry the data?  Let's say the client is
trying to authenticate using a revoked certificate.  If we allow the
client to send us the revocation list, doesn't the bad guy just
not send anything?

Or does even the empty revocation list have to be signed in some
fashion?  And if so, what if the root certificate is revoked?  Or
is that even possible?

Or is securing the CRL during transit from a untrusted source stuff
we have to specify as part of specifying a way to carry CRLs in the
SSH protocol?

I'm afraid my x.509 knowledge is sufficient to call someone elses
(Microsoft's) API and let them deal with all of this stuff.

> infrastructure inside it, with <insert protocol name here> as the only

Unfortunately, this may be a more common use case in SSH than
in ipsec because of it's adhoc nature.  In particular, this use
case applies to me!  (I suspect it is not unusual for SSH to be
the only thing going through a firewall.)

I can imagine extending the format to be

string name ("x509v3-sign-rsa2", "x509v3-sign-dss2" or "x509v3-sign")
string der-encoded certificate
string der-encode crl list
string certs-in-chain[0..n]

I'm mildly reluctant to do so, since the sender has no way
to probe whether the (potentially volumous) data is needed
by the peer or not.  If we have to worry about securing
the CRL list and the certificate chain, I begin to get more
than just mildly reluctant.

Adding language to explicitly state that we refuse to carry
such information in the SSH protocol and that it must be
out-of-band is pretty easy (and wimpy, but I'm a first class
wimp.)

Thanks,

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 24 Mar 2005 10:31:00 -0700

> secure distribution of public keys between the server and the clients is

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.

> other hand the subject and/or subjectAltName of the server certificate

So what you are saying is that the draft ought to include text along
the lines of:

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?

> subject and/or subjectAltName of the client certificate.

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.

> and the username of the client user already identifies these entities.

Is this saying what I said above?

> 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?

>> a claim that it's entirely out of scope for the document..

This I can handle.  They can be used for authentication... once I start
to get a handle on what other changes we are going to make to the
document to address the other concerns, I'll make sure this is clear.

Thanks,

Joseph

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 24 Mar 2005 12:49:57 -0500

On Thu, 2005-03-24 at 12:08, Joseph Galbraith wrote:

> Let's say the client is trying to authenticate using a revoked certificate.  
> If we allow the client to send us the revocation list, doesn't the bad guy just
> not send anything?

if the relying party is set up to require CRL's, bits don't move.

> fashion? 

Correct.

> And if so, what if the root certificate is revoked?  Or 
> is that even possible?

CRL's are signed and have validity periods; they must be periodically
reissued.
If you're doing CRL checking and the peer hands you a stale CRL, you
reject it.

> And if so, what if the root certificate is revoked?  Or 
> is that even possible?

It's not.

> out-of-band is pretty easy (and wimpy, but I'm a first class

This is probably the right way to go for now.  

Note that in the firewall-traversal case you can reduce information
leaks through a published CRL by having a distinct CA for the access
points which is *not* the CA for your users or your internal servers,
and by having your remote clients configured to trust the
access-point-CA directly.

The firewall-traversal server can presumably talk to the internal PKI
infrastructure for validating the client certificates.

and if you only have one access point, you don't need to be using X.509
for the access points.

								- Bill

---

From: Darren J Moffat <[email-masked]>
Date: Thu, 24 Mar 2005 10:31:07 -0800

Given that the SSH protocol already has support for GSSAPI and
there are GSSAPI mechanisms that can use X.509 certs, is there
really any need for this other than to cause more complications ?

This might be particularly important on the client side since
a user may be able to use their key and cert via a GSSAPI mechanism
already.

--
Darren J Moffat

---

From: Henrick Hellström <[email-masked]>
Date: Thu, 24 Mar 2005 22:39:28 +0100

> 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.

> 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.

> 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.

> 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

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 25 Mar 2005 13:24:31 +1200

Joseph Galbraith <[email-masked]> writes:

>But, can we really safely carry the data?  Let's say the client is trying to
>authenticate using a revoked certificate.  If we allow the client to send us
>the revocation list, doesn't the bad guy just not send anything?

The assumption is that you always have to send some sort of CRL, if there's
nothing revoked then you send an empty one.  This weird requirement is an
unfortunate side-effect of the blacklist-based checking used in X.509, if it
was done properly with a liveness proof this wouldn't be an issue.

>Or does even the empty revocation list have to be signed in some fashion?
>And if so, what if the root certificate is revoked?  Or is that even
>possible? Or is securing the CRL during transit from a untrusted source stuff
>we have to specify as part of specifying a way to carry CRLs in the SSH
>protocol?

I would just ignore all this, allow the server to send a cert or cert chain
and leave the rest to the user.  Otherwise you have to deal with cached CRLs,
fetched CRLs, OCSP, out-of-band checks, etc etc etc.  Then you have to decide
what you want to do with delta CRLs (do you send the last full CRL and all
deltas, the latest delta, ... )?.  This is a complete mess, and given that the
interest in use of X.509 certs in SSH to date has been within epsilon of
absolute zero, it's just not worth bothering with.  Tell 'em they can include
certs/cert chains and leave it at that.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 25 Mar 2005 13:29:33 +1200

=?ISO-8859-1?Q?Henrick_Hellstr=F6m?= <[email-masked]> writes:

>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.

I was just about to make the same point.  Putting in a huge amount of work to
describe some elaborate infrastructure when to date everyone has got along
just fine with raw public keys (so that by extension any attacker who wants to
sidestep it can just extract and send the raw key) is pretty pointless.  X.509
is a convenient alternative bit-bagging technique for use if you've already
got a pile of PKI set up, not a reason to re-work half the SSH trust model.

Peter.

---

From: Roumen Petrov <[email-masked]>
Date: Fri, 25 Mar 2005 02:41:11 +0200

Henrick Hellström wrote:

>> [SNIP]
>> [SNIP]
> 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."

One part is "Public Key Authentication Method" and example above cover 
only it.
Other method is "Host-Based Authentication" and in this case host  key 
(certificate) may contain both extentions id_kp_clientAuth and 
id_kp_serverAuth.

> added. It just serves as an example of an application specific PKI 

I agree with this.

RFC 3280 cover enough "Certificate Extensions".

-- 
Roumen Petrov
http://roumenpetrov.info/openssh/

---

From: Tomi Salo <[email-masked]>
Date: Tue, 29 Mar 2005 15:42:30 +0300

> (Are their multiple names in the subject name or subject alt name;

 There is only one subject name, but the number of alternative names
 is unlimited. 

 RFC 2818 (HTTP Over TLS) describes a procedure of comparing a 
 hostname against a X.509 cerficate received from a server. 
 (Section 3, Endpoint Identification). 
 
 In short: "If a subjectAltName extension of type dNSName is present,
 that MUST be used as the identity. Otherwise, the (most specific)
 Common Name field in the Subject field of the certificate MUST be
 used." Additionally a subjectAltName of type iPAddress may be
 allowed to match the server's IP address. 

-- 
Tomi T. Salo <[email-masked]>

---

From: Joseph Galbraith <[email-masked]>
Date: Wed, 30 Mar 2005 12:45:19 -0700

>  allowed to match the server's IP address. 

Perhaps we should include similar text a new section specifically
about hostnames... or maybe we should reference RFC2818 directly?

Thanks,

Joseph