Internet Engineering Task Force Joseph Salowey
INTERNET-DRAFT WRQ
Expires February 2001 August 2000
Using Kerberos as a key exchange method in Secure Shell
< draft-salowey-secsh-kerbkeyex-00.txt >
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
anytime. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). See the Full Copyright
Notice below for details.
Abstract
This memo describes two methods for using Kerberos [KRB5] for
authentication and key exchange in the Secure Shell protocol. The first
method uses Kerberos as a means to authenticate the Diffie-Hellman
exchange described in [SSH-TRANSPORT]. The second method uses Kerberos
for authentication and key-exchange. This memo also defines a new user
authentication method which allows an authorization name and optional
credentials to build upon the underlying authenticated key exchange.
1. Kerberos Authenticated Diffie-Hellman Key Exchange
This defines a new key exchange method
kerberos-diffie-hellman-group1-sha1
and a new server host key algorithm
kerberos
This method combines the Diffie-Hellman key exchange from section 6 of
[SSH-TRANSPORT] with mutual authentication using Kerberos.
In the following description (C is the client, S is the server, p is a
large safe prime, g is a generator for a subgroup of GF(p), and q is the
order of the subgroup; V_S is S's version string; V_C is C's version
string; AP_REQ [KRB5] is the application request message sent to the
server; I_C is C's KEXINIT message and I_S S's KEXINIT message which
have been exchanged before this part begins):
1. C obtains a service ticket for S. C generates an AP_REQ [KRB5]
message consisting of the service ticket for S and an
authenticator. C generates a random number x (1 < x < q) and
computes e = g^x mod p. C sends "e" along with the AP_REQ to S.
2. S generates a random number y (0 < y < q) and computes f = g^y
modp. S receives and verifies the AP_REQ message. S receives "e".
It computes K = e^y mod p, H = hash(V_C || V_S || I_C || I_S ||
AP_REQ || e || f || K), and encrypts H with the session key in the
service ticket to form E_H. S sends "f || E_H" to C.
3. C then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S
|| AP_REQ || e || f || K), and verifies that E_H decrypts to H.
Either side MUST NOT send or accept e or f values that are not in the
range [1, p-1]. If this condition is violated, the key exchange fails.
The hash algorithm for computing the exchange hash is SHA1. The hash is
encrypted using the cipher suite specified by the service ticket. See
section 6 for consideration on cipher types.
This is implemented with the following messages.
First, the client sends:
byte SSH_MSG_KRB5_KEXDH_INIT
string AP_REQ message
mpint e
The server responds with:
byte SSH_MSG_KRB5_KEXDH_REPLY
mpint f
string H encrypted with session key from service ticket
The hash H is computed as the sha-1 hash of the concatenation of the
following:
string V_C, the client's version string (CR and NL excluded)
string V_S, the server's version string (CR and NL excluded)
string I_C, the payload of the client's SSH_MSG_KEXINIT
string I_S, the payload of the server's SSH_MSG_KEXINIT
string AP_REQ, the application request message
mpint e, exchange value sent by the client
mpint f, exchange value sent by the server
mpint K, the shared secret
2. Kerberos Key Exchange Method
This defines a new key exchange method
kerberos-sha1
and uses the host key algorithm defined above
kerberos
The Kerberos protocol [KRB5] negotiates a shared secret key during
mutual authentication between client and server.
In the following description (C is the client, S is the server; V_S is
S's version string; V_C is C's version string; AP_REQ is the application
request message; I_C is C's KEXINIT message and I_S S's KEXINIT message
which have been exchanged before this part begins):
1. C obtains a service ticket for S. C generates an AP_REQ [KRB5]
message. This message consists of the service ticket for S, an
authenticator containing an optional sub-session-key, and the
mutual-required flag set. C sends this message to S.
2. S decrypts the session ticket and verifies the authenticator. S
formats a AP_REP with an optional sub-session key. The session key
is negotiated as follows: if the sub-key in the AP_REP is present
it is used, else if the sub-key in the AP_REQ is used, else the
session key from the service ticket is used. It computes H =
hash(V_C || V_S || I_C || I_S || AP_REQ || K), and encrypts H with
the negotiated session key K. S sends "AP_REP || E_H" to C.
3. C verifies the AP_REP, then computes H = hash(V_C || V_S || I_C ||
I_S || ST || AP_REQ || K), and verifies that E_H decrypts to H.
The hash algorithm for computing the exchange hash is SHA1. The hash is
encrypted using the cipher suite specified by the key negotiation. See
section 6 for consideration on cipher types.
This is implemented with the following messages.
First, the client sends:
byte SSH_MSG_KRB5_INIT
string Kerberos AP_REQ message
The server responds with:
byte SSH_MSG_KRB5_REPLY
String Kerberos AP_REP
String H encrypted with negotiated session key
The hash H is computed as the sha-1 hash of the concatenation of the
following:
string V_C, the client's version string (CR and NL excluded)
string V_S, the server's version string (CR and NL excluded)
string I_C, the payload of the client's SSH_MSG_KEXINIT
string I_S, the payload of the server's SSH_MSG_KEXINIT
string AP_REQ, Kerberos AP_REQ message
String K, the negotiated shared secret
3. Naming Conventions
To obtain an appropriate service ticket, the SSH client must determine
the principal name of the SSH server. The Kerberos service naming
convention is used for this purpose, as follows, taken from [TLS-KRB]:
host/MachineName@Realm where:
- The literal, "host", follows the Kerberos convention when not
concerned about the protection domain on a particular machine.
- "MachineName" is the particular instance of the service.
- The Kerberos "Realm" is the domain name of the machine.
4. External Key Exchange user authentication
This section describes a user authentication method building on the
framework described in [SSH-AUTH] This method relies upon the key
exchange to authenticate both the client and the server. If the key
exchange did not successfully perform these functions then this request
must always return SSH_MSG_USERAUTH_FAILURE with partial success set to
false. The new mechanism is defined as follows:
byte SSH_MSG_USERAUTH_REQUEST
string authorization-ID
string service
string "external-keyx"
boolean FALSE
If the user authenticated in the key-exchange is allowed to assume the
authorization identity then SSH_MSG_USERAUTH_FAILURE with partial success
set to true. If the underlying authentication does not authorize use of
the authorization identity then SSH_MSG_USERAUTH_FAILURE must be
returned.
In some cases additional credentials may be passed to allow further
authentication and authorizations. The following message is used in this
case.
byte SSH_MSG_USERAUTH_REQUEST
string authorization-ID
string service
string "external-keyx"
boolean FALSE
string credential type
string additional credentials
This document defines credential types for Kerberos credentials and x509
authorization certificates. If the additional credentials do not
authorize the user to use the service or use the authorization-ID then
then SSH_MSG_USERAUTH_FAILURE with partial success set to false should
be returned. The binding between the additional credential and the
underlying authentication must be carefully examined to insure the
credential refers to the authenticated party.
4.1 Kerberos Credentials
The credential type for kerberos credentials is kerberos-cred. The
additional credentials in this case is a KRB_CRED message. The KRB_CRED
message may contain fowarded TGTs and/or proxied service tickets. The
KRB_CRED message is defined in [KRB5] The SSH userauth message is as
follows:
byte SSH_MSG_USERAUTH_REQUEST
string authorization-ID
string service
string "external-keyx"
boolean TRUE
string "kerberos-cred"
string KRB_CRED message
4.2 X.509 Authorization Certificate
The credential type for an X509 authorization certificate is x509ac. The
additional credential in this case is an X.509 authorization
certificate. X509 authorization certificates are defined in [X509AC].
The holder of the certificate must match the authenticated client in the
key exchange. The message is as follows:
byte SSH_MSG_USERAUTH_REQUEST
string authorization-ID
string service
string "external-keyx"
boolean TRUE
string "x509ac"
string x509 authorization certificate
5. Security Considerations
Kerberos key exchange is subject to the same security considerations as
the SSH protocol. Kerberos implementation must be careful to protect the
secret keys shared between the KDC and principals. In order to avoid
replay of authenticators the SSH server must maintain a replay cache of
authenticators for the amount of time equivalent to the clock skew.
[KRB5]
In order to maintain consistency between the strength of the
authenticated key exchange and the strength of the data stream
encryption and integrity protection use kerberos ciphers that use triple
DES or equivalent security is recommended. Kerberos using single DES
should only be used if the resulting data stream is going to be
encrypted with a weak cipher.
The external key exchange user authentication method must have acces to
information form the key exchange. If this information is unavailable
the authentication must fail. Care must be taken when matching verifying
additional credentials escpecially in the case when the binding is just
to a name as it may be in the case of authorization certificates.
6. References
[KRB5] Kohl J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet
Draft, draft-secsh-transport-07.txt
[SSH-USERAUTH] Ylonen, T., et al, "SSH Authentication Protocol",
Internet Draft, draft-ietf-secsh-userauth-07.txt
[X509AC] S. Farrell and R. Housley "An Internet Attribute Certificate
Profile for Authorization," ,Internet Draft,
draft-ietf-pkix-ac509prof-05.txt
[TLS-KRB] A. Medvinsky and M. Hur, "Addition of Kerberos Cipher Suites
to Transport Layer Security (TLS)", RFC 2712, October 1999
7. AuthorÆs Address
Joseph Salowey
WRQ
1500 Dexter Ave. N
Seattle, WA 98109
Phone: +1 206 217 7129
Email: joes@wrq.com
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
This draft expires February 2001.