>>>>> "JKV" == JKV writes:

JKV> Hi,

JKV> What is the current status of X.509 support in SSH? I know there
JKV> is support for X.509 under the form of a patch
JKV> (http://roumenpetrov.info/openssh). But as far as I know it's not
JKV> supported by clients such as PuTTY.

It is best supported in commercial products, such as Tectia (ssh.com) and
VShell (vandyke.com).

--
Richard Silverman
res@qoxp.net

"Richard E. Silverman" writes:
>>>>>> "JKV" == JKV writes:
> JKV> Hi,

> JKV> What is the current status of X.509 support in SSH? I know there
> JKV> is support for X.509 under the form of a patch
> JKV> (http://roumenpetrov.info/openssh). But as far as I know it's not
> JKV> supported by clients such as PuTTY.

>It is best supported in commercial products, such as Tectia (ssh.com) and
>VShell (vandyke.com).

It should be mentioned that since the required formats were never properly
specified in any standards, what's implemented is vendor-specific and
nonstandard. The only way that something like Putty could support whatever it
is that the ssh.com and VanDyke implementations do is by reverse-engineering
the applications.

Peter.

"Peter Gutmann" wrote in message
news:450h8aF48i2uU1@individual.net...
> "Richard E. Silverman" writes:
> >>>>>> "JKV" == JKV writes:
> > JKV> Hi,
>
> > JKV> What is the current status of X.509 support in SSH? I know there
> > JKV> is support for X.509 under the form of a patch
> > JKV> (http://roumenpetrov.info/openssh). But as far as I know it's
not
> > JKV> supported by clients such as PuTTY.
>
> >It is best supported in commercial products, such as Tectia (ssh.com) and
> >VShell (vandyke.com).
>
> It should be mentioned that since the required formats were never properly
> specified in any standards, what's implemented is vendor-specific and
> nonstandard. The only way that something like Putty could support
whatever it
> is that the ssh.com and VanDyke implementations do is by
reverse-engineering
> the applications.
>
> Peter.
>

Is there any effort going on in standardizing the use of X.509 in ssh?

Thanks,

Jan

"JKV" writes:

>Is there any effort going on in standardizing the use of X.509 in ssh?

There's an expired RFC draft for this that no-one seems to be terribly
interested in. As an extension of this, the SSH drafts contained placeholders
for X.509 for over eight years that were finally removed before they were
published as RFCs due to lack of interest - SSH was specifically designed to
not require X.509 (which is one of the contributing reasons for its runaway
success), so you can forgive the developers for not falling over themselves to
implement it :-).

As an even further extension, this question has come up every now and then on
the SSH list. The response is "If you're really interested in it, write a
draft RFC", whereupon the person asking the question suddenly decides that
they're not really that interested in it after all. So I guess I could also
say "If you're really interested in it, write a draft RFC".

Peter.

Latest draft is draft-ietf-secsh-x509-02.txt.

Also note that Peter Gutmann is against X.509 support in secure shells
- mail archive on secsh working group clearly show this.

>>>>> "PG" == Peter Gutmann writes:

PG> "Richard E. Silverman" writes:
>>>>>>> "JKV" == JKV writes:
JKV> Hi,

JKV> What is the current status of X.509 support in SSH? I know there
JKV> is support for X.509 under the form of a patch
JKV> (http://roumenpetrov.info/openssh). But as far as I know it's not
JKV> supported by clients such as PuTTY.

>> It is best supported in commercial products, such as Tectia
>> (ssh.com) and VShell (vandyke.com).

PG> It should be mentioned that since the required formats were never
PG> properly specified in any standards, what's implemented is
PG> vendor-specific and nonstandard. The only way that something like
PG> Putty could support whatever it is that the ssh.com and VanDyke
PG> implementations do is by reverse-engineering the applications.

That's not quite true. Although X.509 is not part of the final SSH-TRANS
RFC, X.509 key types were defined in earlier drafts (as you note later in
this thread). Both Tectia and VShell use those key types (x509v3-sign-rsa
and x509v3-sign-dsa) as specified in that draft, so I don't believe there
is any need to reverse engineer anything. If you think there is, please
explain.

It is true that, since these types are no longer part of the spec, they
should technically be qualified in use now (e.g. x509v3-sign-rsa@ssh.com).

--
Richard Silverman
res@qoxp.net

>>>>> "PG" == Peter Gutmann writes:

PG> "JKV" writes:
>> Is there any effort going on in standardizing the use of X.509 in
>> ssh?

PG> SSH was specifically designed to not require X.509 (which is one
PG> of the contributing reasons for its runaway success), so you can
PG> forgive the developers for not falling over themselves to
PG> implement it :-).

It is indeed a reason for its early success -- and it is now an impediment
to its adoption in large organizations. The simple known-hosts file
mechanism for server authentication is great for getting SSH up and
running quickly for oneself, or among a small number of hosts. In a
collection of hundreds or thousands of clients and servers, maintaining
these lists becomes an impossible and non-scaling task. Maintaining and
distributing them every time a server is added, removed, or rekeyed
anywhere in the organization is a nightmare. In fact, it may be
practically impossible when you consider that implementations represent
these lists using different formats and mechanisms (e.g. PuTTY uses the
Windows registry), and many clients are simply not available for updating
much of the time (e.g. laptops).

With a standard, distributed trust system such as X.509 PKI, this problem
simply goes away. It is only necessary to distribute to clients, once, a
single root certificate under which server hostkey certificates are
issued. Servers may then be added, removed, or rekeyed at will, with no
client updates needed. Similar improvements are realized if certificates
are also used for user authentication, although that entails much more
overhead and hence is less likely to be necessary or used.

GSSAPI/Kerberos solves the server authentication problem as well, using a
different technology, and solves the hostname aliasing problem too (modulo
security of the DNS). However, it is often not feasible to implement
Kerberos due to practical limitations of today's networks, such as NAT and
firewalls. X.509 is much more self-contained.

Finally, I will note that this definitely is not a theoretical problem. I
am right now in the process of reviewing SSH usage at my company. It is
quite likely that we will go with a commercial implementation rather than
OpenSSH, despite the many advantages of OpenSSH, for precisely this
reason.

--
Richard Silverman
res@qoxp.net

"Richard E. Silverman" writes:
> With a standard, distributed trust system such as X.509 PKI, this problem
> simply goes away. It is only necessary to distribute to clients, once, a
> single root certificate under which server hostkey certificates are
> issued. Servers may then be added, removed, or rekeyed at will, with no
> client updates needed. Similar improvements are realized if certificates
> are also used for user authentication, although that entails much more
> overhead and hence is less likely to be necessary or used.
>
> GSSAPI/Kerberos solves the server authentication problem as well, using a
> different technology, and solves the hostname aliasing problem too (modulo
> security of the DNS). However, it is often not feasible to implement
> Kerberos due to practical limitations of today's networks, such as NAT and
> firewalls. X.509 is much more self-contained.

aka digital certificates are an analogy to the letters of
credit/introduction from the sailing ship days where the relying
parties (clients) otherwise didn't have access to the necessary
information (either their own local repository or realtime/online
access to some certifying authority).

one of the issues from the early 90s with x.509 identity certificates
and trusted third party PKI certification authorities ... was that the
TTP/CAs were looking at making the identification useful for relying
parties helping justify the prices that they would be charging the
key-owners (for the certificates). not knowing ahead of time ... all
possibly relying-parties (that might be making use of the
certificates), there was a tendency to grossly overload the x.509
identity certificates with personal information (in the hopes that
majority of future relying parties might find something of use).

one of the issues going into the mid-90s, was that a dawning
realization that x.509 identity certificates, grossly overloaded with
personal information represented significant privacy and liability
issues.

the original pk-init draft for kerberos ... simply involved
registering a public key (in lieu of a password) ... and then
performing digital signature verification using the onfile public key
(in place of password matching). I periodically get email from the
person that claims to have been responsible for pki-based certificates
added to the pk-init draft, apologizing for not realizing (at the
time) that it was redundant and superfluous.

misc past kerberos related posts
http://www.garlic.com/~lynn/subpubkey.html#kerberos

when working on the original payment gateway ... there were proposals
that consumers could register a public key with their certificatoin
authority ... aka their financial institution and then digitally sign
the transactions ... for verification by their financial institution
using the onfile public key. one such is the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959

there were also PKI-oriented suggestions that adding digital
signatures and attached digital certificates to financial transactins
would modernize financial transactions. the counter observation was
that the purpose of digital certificates were to allow offline
verification (i.e. when the relying party didn't have online access to
the certifying authority) which was the case prior to the
infrastructure going online in the 70s (aka the certificate-oriented
proposal was essentially to return to the offline days of 30 years
earlier).

again, given that the relying party has their own repository of
information and/or online access to some certifying authority, then
the digital certificates were redundant and superfluous. an adequant
modernization would be to digitally sign the transactions and verify
the digitally signature with the onfile public keys.

there was a separate problem with appending digital ceritificates to
such financial transactions. the typical financial transaction is on
the order of 60-80 bytes ... and the typical PKI certificate appending
protocols of the mid-90s added another 4k-12k bytes to the financial
transaction ... and enormous payload bloat (increase of 100 times) for
something that was redundant and superfluous.

for a time, there was a standardization effort in the X9 financial
standards group looking at creating PKI digital certificates that
would be on the order of 300 bytes ... eliminating the enormous
payload penalty for redundant and superfluous digital certificates.
One approach was itemizing the various fields in a standard digital
certificate that were common across all digital certificates issued by
the same financial institution, and then eliminating the redundant
fields. This would only result in retaining those fields that were
unique to a specific certificate. However, it was possible to show
that the financial institution (as both the relying party and the
certificate issuing party) would be in possesion of all certificate
fields and therefor it was possible to reduce such digital
certificates to zero fields and zero bytes ... an enormous improvement
in the payload bloat associated with appending redundant and
superfluous digital certificates.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

On 2006-02-11, Richard E. Silverman wrote:
> The simple known-hosts file [snip discussion of x.509 and kerberos
> as alternatives to static known hosts files]

There's another option not mentioned, and it is a (proposed) standard:
SSH fingerprints via DNS, RFC4255. It needs a secure DNS to be useful,
and only helps with known hosts, though.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

>>>>> "DT" == Darren Tucker writes:

DT> On 2006-02-11, Richard E. Silverman wrote:
>> The simple known-hosts file [snip discussion of x.509 and kerberos
>> as alternatives to static known hosts files]

DT> There's another option not mentioned, and it is a (proposed)
DT> standard: SSH fingerprints via DNS, RFC4255. It needs a secure
DT> DNS to be useful, and only helps with known hosts, though.

Good point; thanks. I'm not sure what you mean by "only helps with known
hosts," though; could you clarify?

I should also have pointed out that Kerberos server authentication (a
GSSAPI key exchange) is not available in OpenSSH per se, but rather in
some derived versions (such as the Debian ssh-krb5 package).

--
Richard Silverman
res@qoxp.net

On 2006-02-12, Richard E. Silverman wrote:
>>>>>> "DT" == Darren Tucker writes:
> DT> There's another option not mentioned, and it is a (proposed)
> DT> standard: SSH fingerprints via DNS, RFC4255. It needs a secure
> DT> DNS to be useful, and only helps with known hosts, though.
>
> Good point; thanks. I'm not sure what you mean by "only helps with known
> hosts," though; could you clarify?

You can't use it to centralise, eg, authorized_keys.

To achieve the same effect as, eg, kerberos single sign on you would
still need to distribute authorized_keys files to the relevant servers.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

>>>>> "DT" == Darren Tucker writes:

DT> On 2006-02-12, Richard E. Silverman wrote:
>>>>>>> "DT" == Darren Tucker writes:
DT> There's another option not mentioned, and it is a (proposed)
DT> standard: SSH fingerprints via DNS, RFC4255. It needs a secure
DT> DNS to be useful, and only helps with known hosts, though.
>> Good point; thanks. I'm not sure what you mean by "only helps
>> with known hosts," though; could you clarify?

DT> You can't use it to centralise, eg, authorized_keys.

DT> To achieve the same effect as, eg, kerberos single sign on you
DT> would still need to distribute authorized_keys files to the
DT> relevant servers.

Oh, you mean it doesn't help with user authentication. Yes; I was only
talking about server auth.

--
Richard Silverman
res@qoxp.net

Richard E. Silverman wrote:
>>>>>> "PG" == Peter Gutmann writes:
>
> PG> "JKV" writes:
> >> Is there any effort going on in standardizing the use of X.509 in
> >> ssh?
>
> PG> SSH was specifically designed to not require X.509 (which is one
> PG> of the contributing reasons for its runaway success), so you can
> PG> forgive the developers for not falling over themselves to
> PG> implement it :-).
>
> It is indeed a reason for its early success -- and it is now an impediment
> to its adoption in large organizations. The simple known-hosts file
> mechanism for server authentication is great for getting SSH up and
> running quickly for oneself, or among a small number of hosts. In a
> collection of hundreds or thousands of clients and servers, maintaining
> these lists becomes an impossible and non-scaling task. Maintaining and
> distributing them every time a server is added, removed, or rekeyed
> anywhere in the organization is a nightmare. In fact, it may be
> practically impossible when you consider that implementations represent
> these lists using different formats and mechanisms (e.g. PuTTY uses the
> Windows registry), and many clients are simply not available for updating
> much of the time (e.g. laptops).
>
> With a standard, distributed trust system such as X.509 PKI, this problem
> simply goes away. It is only necessary to distribute to clients, once, a
> single root certificate under which server hostkey certificates are
> issued. Servers may then be added, removed, or rekeyed at will, with no
> client updates needed. Similar improvements are realized if certificates
> are also used for user authentication, although that entails much more
> overhead and hence is less likely to be necessary or used.
>
> GSSAPI/Kerberos solves the server authentication problem as well, using a
> different technology, and solves the hostname aliasing problem too (modulo
> security of the DNS). However, it is often not feasible to implement
> Kerberos due to practical limitations of today's networks, such as NAT and
> firewalls. X.509 is much more self-contained.
>
> Finally, I will note that this definitely is not a theoretical problem. I
> am right now in the process of reviewing SSH usage at my company. It is
> quite likely that we will go with a commercial implementation rather than
> OpenSSH, despite the many advantages of OpenSSH, for precisely this
> reason.
>

Couldn't something be built into the protocol to distribute known_hosts?
For example I connect to server X, it's fingerprint matches the one I
have on file, therefore I trust it and it pushes down a list of all the
hosts it trusts? If there are any new ones, I get them the next time I
connect to the server.

--
To reply by email remove "_nospam"

Chuck writes:
> Couldn't something be built into the protocol to distribute known_hosts?
> For example I connect to server X, it's fingerprint matches the one I
> have on file, therefore I trust it and it pushes down a list of all the
> hosts it trusts? If there are any new ones, I get them the next time I
> connect to the server.

basically all the public key oriented authentication schemes is
dependent on having a local trusted repository of public keys and what
they are associated with. this is true even for PKI x.509
infrastructures ... although in the PKI case, the repository may be
significantly obfuscated and almost cloaded in mysticism.

the PKI case may have all sorts of obstructions involved with dealing
with any local tursted public key repository and/or adding new entries
to the repository ... where an attempt is made in both software and
policy that only certain privileged entities known as "certification
authorities" have their trusted public keys in your repository.

another variation is secure DNS. basically almost any kind of
information can be registered with the domain name infrastructure and
distributed ... including lots of infrastructure for local caching of
that information. basically secure DNS would do what you describe ...
if public keys were registered in domain name infrastructure.

one of the issues that i've observed with the SSL domain name server
certificates is that the PKI certification authority industry has
somewhat sponsored secure DNS and registration of public keys.

the issue is that frequently that somebody reguests a SSL domain name
server certificate from a certification authority ... and must supply
a bunch of identification information. the certification authority
then must validate the supplied identification information corresponds
to the identification information onfile with the domain name
infrastructure (for that domain name owner). this is a time-consuming,
expensive and error-prone process.

note however, there have been various vulnerabilities with the domain
name infrastructure like domain name hijacking ... which puts at risk
the certification process done by the PKI certification authorities.
So somewhat to improve the integrity of domain name infrastructure
(and therefor the certification done by PKI certificatio authorities),
the proposal is that domain name owners register their public key when
they register a domain name.

this also offers an opportunity for the PKI certification authorities,
they now can require that SSL domain name certificate applications be
digital signed by the applicant. Then the PKI certificaiton authority
can replace their time-consuming, error-prone and expensive
identification process with a much simpler, more reliable, and less
expensive authentication process by doing a real-time retrieval of the
domain name owner's public key and verifying the digital signature
attached to the SSL domain name certificate application.

This significantly enhancing the business process of the PKI
certification authorities as well as the integrity of the domain name
infrastructure (which the PKI certification authorities are dependent
on for their certifications). The catch-22 or downside is that if the
PKI certification authorities can do real-time retrieval of onfile
public keys for verifying digital signatures ... then it is possible
that the rest of the world could start doing it also ... which in turn
could make any SSL domain name certificates redundent and superfluous.

Furthermore, one could imagine that such secure DNS implementation (of
real-time retrieval of onfile trusted public keys) could have the
local caching implementation slightly enhanced to interoperate with
any local repository of trusted public keys ... and integrated with
something like the PGP-like user interface allowing users to provide
optional trust ratings for any public keys in their local repository
of trusted public keys.

misc. past posts on SSL domain name server certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

one suggestion for an enhancement to the SSL protocol is to allow any
public key and associated crypto-protocol options to be piggybacked on
the domain name infrastructure response to request for a server's
ip-address. then the client has the server's public key in the same
response that it acquires the server's ip-address. the client could
then do the session key generation, encode it with the server's public
key and transmit it in the initial encrypted session setup
.... eliminating all the upfront SSL session protocol chatter. One
could even imagine it being done for a single round-trip transaction
protocol ... say using something like UDP.

the client currently is able to cache ip-address response from the
domain name infrastructure ... so one could imagine that any public
key responses could be cached similar. with some enhancements, such
public key responses could be even given longer cached lifetimes (say
in the local trusted public key repository).

basically ... using the existing domain name infrastructure real-time
information distribution and caching mechanism ... and eliminating the
need for PKI stale, static, redundant and superfluous (x.509 or other)
certificate-based operations.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Anne & Lynn Wheeler wrote:

[lots of stuff snipped]

> local trusted public key repository).
>
> basically ... using the existing domain name infrastructure real-time
> information distribution and caching mechanism ... and eliminating the
> need for PKI stale, static, redundant and superfluous (x.509 or other)
> certificate-based operations.
>

I like it. I really like it. Is this just at the proposal stage or is it
actually being implemented somewhere?

--
To reply by email remove "_nospam"

Chuck writes:
> I like it. I really like it. Is this just at the proposal stage or is it
> actually being implemented somewhere?

ref:
http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh

i think that the PKI/CA forces are quite ambivalent about it ... on
the one hand they need the public key registration as part of overall
improving the integrity of the domain name infrastructure (which they
are dependent on when they go thru the business process of certifying
the domain name owner, before issueing the digital certificate
represented that they had done the appropriate certification).

They can also use real-time retrieval of the onfile, registered public
key to move from the error-prone, time-consuming, and expensive
identification process to a much simpler, less expensive, and more
reliable authentication process.

however, opening up real-time retrieval of onfile, registered public
keys is a pandoras box for them since it leads down the trail of
obsoleting the stale, static, redundant and superfluous certificates.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Anne & Lynn Wheeler wrote:
> Chuck writes:
>> I like it. I really like it. Is this just at the proposal stage or is it
>> actually being implemented somewhere?
>
> ref:
> http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
>
> i think that the PKI/CA forces are quite ambivalent about it ... on
> the one hand they need the public key registration as part of overall
> improving the integrity of the domain name infrastructure (which they
> are dependent on when they go thru the business process of certifying
> the domain name owner, before issueing the digital certificate
> represented that they had done the appropriate certification).
>
> They can also use real-time retrieval of the onfile, registered public
> key to move from the error-prone, time-consuming, and expensive
> identification process to a much simpler, less expensive, and more
> reliable authentication process.
>
> however, opening up real-time retrieval of onfile, registered public
> keys is a pandoras box for them since it leads down the trail of
> obsoleting the stale, static, redundant and superfluous certificates.
>

If I were a CA I would NOT be pushing for this at all. What good would
it be to me to speed up the certification process if it eliminates me in
the end? Or perhaps they will simply get into the domain registration
business.




--
To reply by email remove "_nospam"

Chuck writes:
> If I were a CA I would NOT be pushing for this at all. What good would
> it be to me to speed up the certification process if it eliminates me in
> the end? Or perhaps they will simply get into the domain registration
> business.

ref:
http://www.garlic.com/~lynn/2006b.html#57 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#12 X.509 and ssh

the part about making it cheaper, more reliable, and less
time-consuming by verifying a digital signature on a certificate
application (by doing a real-time retrieval of onfile, registered
public key) ... is somewhat incidental to the real objective of
improving the overall integrity of the domain name infrastructure.

by having a public key registered as part of domain name registration
.... then all future communication between the domain name owner and
the domain name infrastructure can be digitally signed (and validated)
.... which helps to reduce things like domain name hijacking.

fundamentally, a digital certificate (or any other physical license,
credential, etc) is a stale, static, locally cached representation of
some certification process. in the case of ssl domain name
certificates, the certification includes certifying that the entity
requesting the ssl domain name certificate is the domain name owner.

if there are integrity issues with the domain name infrastructure with
regard to the true owner of a domain name (from exploits like domain
name hijacking) then the trust root for the whole ssl domain name
pki/certificate infrastructure (the information on file as to the
identity of the true domain name owner) is at risk ... aka attacker
creates a dummy front company, hijacks the domain name, and then
applies for a ssl domain name digital certificate ... and succesfully
is issued a ssl domain name digital certificate ... because the
attacker is, in fact, the current, onfile, registered owner of the
domain name. for more information use one of the search engines to
find a lot more about (even recent) domain name hijacking exploits.

the monkey wrench in this whole scheme is the domain name
infrastructure being fundamentally a real-time trusted information
distribution implementation. if there are registered public keys in
the domain name infrastructure ... then it is possible for the domain
name infrastructure to also provide trusted, real-time distribution of
any and all information on file.

i've frequently asserted that real-time distribution of trusted
information is orders of magnitude perferred to using stale, static
redundant and superfluous digital certificates.

in effect, digital certificates are paradigm analogous to the letters
of credit/introduction from the sailing ship days ... where they
substituted for the relying party having either their own information
(about the subject in question) and/or direct communication with some
recognized authority. over the centuries,
credential/license/certificates have acted as substitutes for direct
knowledge and/or direct communication. however, as infrastructures
migrate to online, all-the-time operations ... direct communication is
available ... and the credentials/licenses/certificates substitutes
are becoming more and more redundant and superfluous.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

"Richard E. Silverman" wrote in message
news:m2pslto3v8.fsf@darwin.oankali.net...
>
> With a standard, distributed trust system such as X.509 PKI, this problem
> simply goes away. It is only necessary to distribute to clients, once, a
> single root certificate under which server hostkey certificates are
> issued. Servers may then be added, removed, or rekeyed at will, with no
> client updates needed. Similar improvements are realized if certificates
> are also used for user authentication, although that entails much more
> overhead and hence is less likely to be necessary or used.
>
I would like to use it the other way around. All users presenting a X.509
certificate issued by a trusted party can access the server. Then I only
need to install the root certificate of the trusted party on the server and
the user management doesn't need to be done on that server but can be done
independently.

Jan