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.