SSH v3 specs?
ssh...@rednu.com
elsewhere, and if so what enhancements are being looked
at. Is it too early to consider such things, or should we
open the door to the new features a protocol update would
bring?
More specifically I have been investigating working toward
a more enterprise-friendly hierichical authentication
scheme, but I have quickly realized the magnitude of such
a change. I have worked with LDAP/PAM, but there are
parts of ssh that are not very interoperable with LDAP,
such as pub/priv keypairs. These can be stored in a
directory, but it is quite a kludge to do so at this
point.
Thoughts and comments appreciated.
Thanks,
Ryan
_______________________________________________
openssh-...@mindrot.org mailing list
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
Danny De Cock
I would be very interested in an ssh protocol which supports certificate
validation. what I mean is this: if one uses a smartcard to perform the
digital signature generation, the ssh client currently requires the
presence of a certificate in that card, but the certificate itself is not
used where it is designed for: the ssh server fetches the reference value
of the smartcard's private key's public key from its authorized_keys file,
but that's it.
I would be very happy if the user's certificate could be stored in the
authorized_keys file (or a similar file), and if the ssh server checked
the digital signature on the challenge during the client's authentication
using that certificate, and granting access to the user only if the
certificate itself has been found to be valid...
the ssh server could offer different validation mechanisms of the
certificate: using a local set of trusted (possibly self-signed)
certificates, fetching a certificate revocation list if necessary,
presenting the certificate to an external certificate validation service
(e.g., ocsp responder), etc.
the easiest way for the ssh server to obtain the client's certificate
could consist of the authorized_keys file, or the ssh client could push it
to the server after having it fetched from a local repository (such as the
user's smartcard)...
does this sound reasonable to you, or pure nonsense? :))
cu, danny.
Markus Friedl
> I would be very interested in an ssh protocol which supports certificate
> validation.
how is this related to the ssh protocol?
have you checked draft-ietf-secsh-transport-xx.txt ?
the protocol already supports certificates.
Markus Friedl
> Has any thought toward a v3 protocol spec been discussed
> elsewhere, and if so what enhancements are being looked
> at. Is it too early to consider such things, or should we
> open the door to the new features a protocol update would
> bring?
where is ssh v3 beeing discussed?
>
> More specifically I have been investigating working toward
> a more enterprise-friendly hierichical authentication
> scheme, but I have quickly realized the magnitude of such
> a change. I have worked with LDAP/PAM, but there are
> parts of ssh that are not very interoperable with LDAP,
> such as pub/priv keypairs. These can be stored in a
> directory, but it is quite a kludge to do so at this
> point.
storing the private keys in LDAP makes no sense,
but why is storing the public keys a problem?
Markus Friedl
> More specifically I have been investigating working toward
> a more enterprise-friendly hierichical authentication
> scheme, but I have quickly realized the magnitude of such
> a change.
i don't think you need a new protocol versions if you want to
do this. you can take what's already there.
Danny De Cock
> On Mon, Jan 06, 2003 at 06:07:12AM +0100, Danny De Cock wrote:
> > I would be very interested in an ssh protocol which supports certificate
> > validation.
>
> how is this related to the ssh protocol?
it is true that the validation itself is not related to certificate
validation, but the user's certificate might have to be pushed to the
server during the user authentication step...
> have you checked draft-ietf-secsh-transport-xx.txt ?
not yet ];-)
cu, danny.
> the protocol already supports certificates.
m...@appgate.com
> Has any thought toward a v3 protocol spec been discussed
> elsewhere, and if so what enhancements are being looked
> at. Is it too early to consider such things, or should we
> open the door to the new features a protocol update would
> bring?
I am not aware of any such discussion and I do not see any need for it
either. The ssh protocol is quite flexible and new authentication
methods can be defined without moving to a new protocol version (IMHO a
very good thing:-).
> More specifically I have been investigating working toward
> a more enterprise-friendly hierichical authentication
> scheme, but I have quickly realized the magnitude of such
> a change. I have worked with LDAP/PAM, but there are
> parts of ssh that are not very interoperable with LDAP,
> such as pub/priv keypairs. These can be stored in a
> directory, but it is quite a kludge to do so at this
> point.
I agree that the normal pub/priv keyparts do not operate very well with
LDAP but why should they? You can always use certificates instead of the
current pub/priv keypairs, and that can work well with LDAP.
Our product, AppGate, which uses ssh also supports certificate
authentication and that without any protocol modifications whatsoever.
/MaF
--
Martin Forssen <m...@appgate.com> Development Manager
Phone: +46 31 7744361 AppGate Network Security AB
Damien Miller
> Has any thought toward a v3 protocol spec been discussed elsewhere, and
> if so what enhancements are being looked at. Is it too early to
> consider such things, or should we open the door to the new features a
> protocol update would bring?
What can't you do with the existing protocol? It is very flexible and
extensible...
-d