idnits 2.17.1 draft-salowey-secsh-kerbkeyex-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 342 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([SSH-TRANSPORT], [KRB5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 77: '...Either side MUST NOT send or accept e ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2000) is 8626 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SSH-TRANSPORT' is mentioned on line 54, but not defined == Missing Reference: 'SSH-AUTH' is mentioned on line 187, but not defined == Unused Reference: 'SSH-TRANS' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'SSH-USERAUTH' is defined on line 287, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1510 (ref. 'KRB5') (Obsoleted by RFC 4120, RFC 6649) -- No information found for draft-secsh-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-TRANS' == Outdated reference: A later version (-27) exists of draft-ietf-secsh-userauth-07 == Outdated reference: A later version (-09) exists of draft-ietf-pkix-ac509prof-05 Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Joseph Salowey 2 INTERNET-DRAFT WRQ 3 Expires February 2001 August 2000 5 Using Kerberos as a key exchange method in Secure Shell 7 < draft-salowey-secsh-kerbkeyex-00.txt > 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at 19 anytime. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2000). See the Full Copyright 31 Notice below for details. 33 Abstract 35 This memo describes two methods for using Kerberos [KRB5] for 36 authentication and key exchange in the Secure Shell protocol. The first 37 method uses Kerberos as a means to authenticate the Diffie-Hellman 38 exchange described in [SSH-TRANSPORT]. The second method uses Kerberos 39 for authentication and key-exchange. This memo also defines a new user 40 authentication method which allows an authorization name and optional 41 credentials to build upon the underlying authenticated key exchange. 43 1. Kerberos Authenticated Diffie-Hellman Key Exchange 45 This defines a new key exchange method 47 kerberos-diffie-hellman-group1-sha1 49 and a new server host key algorithm 51 kerberos 53 This method combines the Diffie-Hellman key exchange from section 6 of 54 [SSH-TRANSPORT] with mutual authentication using Kerberos. 56 In the following description (C is the client, S is the server, p is a 57 large safe prime, g is a generator for a subgroup of GF(p), and q is the 58 order of the subgroup; V_S is S's version string; V_C is C's version 59 string; AP_REQ [KRB5] is the application request message sent to the 60 server; I_C is C's KEXINIT message and I_S S's KEXINIT message which 61 have been exchanged before this part begins): 63 1. C obtains a service ticket for S. C generates an AP_REQ [KRB5] 64 message consisting of the service ticket for S and an 65 authenticator. C generates a random number x (1 < x < q) and 66 computes e = g^x mod p. C sends "e" along with the AP_REQ to S. 68 2. S generates a random number y (0 < y < q) and computes f = g^y 69 modp. S receives and verifies the AP_REQ message. S receives "e". 70 It computes K = e^y mod p, H = hash(V_C || V_S || I_C || I_S || 71 AP_REQ || e || f || K), and encrypts H with the session key in the 72 service ticket to form E_H. S sends "f || E_H" to C. 74 3. C then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S 75 || AP_REQ || e || f || K), and verifies that E_H decrypts to H. 77 Either side MUST NOT send or accept e or f values that are not in the 78 range [1, p-1]. If this condition is violated, the key exchange fails. 80 The hash algorithm for computing the exchange hash is SHA1. The hash is 81 encrypted using the cipher suite specified by the service ticket. See 82 section 6 for consideration on cipher types. 84 This is implemented with the following messages. 86 First, the client sends: 88 byte SSH_MSG_KRB5_KEXDH_INIT 89 string AP_REQ message 90 mpint e 92 The server responds with: 94 byte SSH_MSG_KRB5_KEXDH_REPLY 95 mpint f 96 string H encrypted with session key from service ticket 98 The hash H is computed as the sha-1 hash of the concatenation of the 99 following: 101 string V_C, the client's version string (CR and NL excluded) 102 string V_S, the server's version string (CR and NL excluded) 103 string I_C, the payload of the client's SSH_MSG_KEXINIT 104 string I_S, the payload of the server's SSH_MSG_KEXINIT 105 string AP_REQ, the application request message 106 mpint e, exchange value sent by the client 107 mpint f, exchange value sent by the server 108 mpint K, the shared secret 110 2. Kerberos Key Exchange Method 112 This defines a new key exchange method 114 kerberos-sha1 116 and uses the host key algorithm defined above 118 kerberos 120 The Kerberos protocol [KRB5] negotiates a shared secret key during 121 mutual authentication between client and server. 123 In the following description (C is the client, S is the server; V_S is 124 S's version string; V_C is C's version string; AP_REQ is the application 125 request message; I_C is C's KEXINIT message and I_S S's KEXINIT message 126 which have been exchanged before this part begins): 128 1. C obtains a service ticket for S. C generates an AP_REQ [KRB5] 129 message. This message consists of the service ticket for S, an 130 authenticator containing an optional sub-session-key, and the 131 mutual-required flag set. C sends this message to S. 133 2. S decrypts the session ticket and verifies the authenticator. S 134 formats a AP_REP with an optional sub-session key. The session key 135 is negotiated as follows: if the sub-key in the AP_REP is present 136 it is used, else if the sub-key in the AP_REQ is used, else the 137 session key from the service ticket is used. It computes H = 138 hash(V_C || V_S || I_C || I_S || AP_REQ || K), and encrypts H with 139 the negotiated session key K. S sends "AP_REP || E_H" to C. 141 3. C verifies the AP_REP, then computes H = hash(V_C || V_S || I_C || 142 I_S || ST || AP_REQ || K), and verifies that E_H decrypts to H. 144 The hash algorithm for computing the exchange hash is SHA1. The hash is 145 encrypted using the cipher suite specified by the key negotiation. See 146 section 6 for consideration on cipher types. 148 This is implemented with the following messages. 150 First, the client sends: 152 byte SSH_MSG_KRB5_INIT 153 string Kerberos AP_REQ message 155 The server responds with: 157 byte SSH_MSG_KRB5_REPLY 158 String Kerberos AP_REP 159 String H encrypted with negotiated session key 161 The hash H is computed as the sha-1 hash of the concatenation of the 162 following: 164 string V_C, the client's version string (CR and NL excluded) 165 string V_S, the server's version string (CR and NL excluded) 166 string I_C, the payload of the client's SSH_MSG_KEXINIT 167 string I_S, the payload of the server's SSH_MSG_KEXINIT 168 string AP_REQ, Kerberos AP_REQ message 169 String K, the negotiated shared secret 171 3. Naming Conventions 173 To obtain an appropriate service ticket, the SSH client must determine 174 the principal name of the SSH server. The Kerberos service naming 175 convention is used for this purpose, as follows, taken from [TLS-KRB]: 177 host/MachineName@Realm where: 179 - The literal, "host", follows the Kerberos convention when not 180 concerned about the protection domain on a particular machine. 181 - "MachineName" is the particular instance of the service. 182 - The Kerberos "Realm" is the domain name of the machine. 184 4. External Key Exchange user authentication 186 This section describes a user authentication method building on the 187 framework described in [SSH-AUTH] This method relies upon the key 188 exchange to authenticate both the client and the server. If the key 189 exchange did not successfully perform these functions then this request 190 must always return SSH_MSG_USERAUTH_FAILURE with partial success set to 191 false. The new mechanism is defined as follows: 193 byte SSH_MSG_USERAUTH_REQUEST 194 string authorization-ID 195 string service 196 string "external-keyx" 197 boolean FALSE 199 If the user authenticated in the key-exchange is allowed to assume the 200 authorization identity then SSH_MSG_USERAUTH_FAILURE with partial success 201 set to true. If the underlying authentication does not authorize use of 202 the authorization identity then SSH_MSG_USERAUTH_FAILURE must be 203 returned. 205 In some cases additional credentials may be passed to allow further 206 authentication and authorizations. The following message is used in this 207 case. 209 byte SSH_MSG_USERAUTH_REQUEST 210 string authorization-ID 211 string service 212 string "external-keyx" 213 boolean FALSE 214 string credential type 215 string additional credentials 217 This document defines credential types for Kerberos credentials and x509 218 authorization certificates. If the additional credentials do not 219 authorize the user to use the service or use the authorization-ID then 220 then SSH_MSG_USERAUTH_FAILURE with partial success set to false should 221 be returned. The binding between the additional credential and the 222 underlying authentication must be carefully examined to insure the 223 credential refers to the authenticated party. 225 4.1 Kerberos Credentials 227 The credential type for kerberos credentials is kerberos-cred. The 228 additional credentials in this case is a KRB_CRED message. The KRB_CRED 229 message may contain fowarded TGTs and/or proxied service tickets. The 230 KRB_CRED message is defined in [KRB5] The SSH userauth message is as 231 follows: 233 byte SSH_MSG_USERAUTH_REQUEST 234 string authorization-ID 235 string service 236 string "external-keyx" 237 boolean TRUE 238 string "kerberos-cred" 239 string KRB_CRED message 241 4.2 X.509 Authorization Certificate 243 The credential type for an X509 authorization certificate is x509ac. The 244 additional credential in this case is an X.509 authorization 245 certificate. X509 authorization certificates are defined in [X509AC]. 246 The holder of the certificate must match the authenticated client in the 247 key exchange. The message is as follows: 249 byte SSH_MSG_USERAUTH_REQUEST 250 string authorization-ID 251 string service 252 string "external-keyx" 253 boolean TRUE 254 string "x509ac" 255 string x509 authorization certificate 257 5. Security Considerations 259 Kerberos key exchange is subject to the same security considerations as 260 the SSH protocol. Kerberos implementation must be careful to protect the 261 secret keys shared between the KDC and principals. In order to avoid 262 replay of authenticators the SSH server must maintain a replay cache of 263 authenticators for the amount of time equivalent to the clock skew. 264 [KRB5] 266 In order to maintain consistency between the strength of the 267 authenticated key exchange and the strength of the data stream 268 encryption and integrity protection use kerberos ciphers that use triple 269 DES or equivalent security is recommended. Kerberos using single DES 270 should only be used if the resulting data stream is going to be 271 encrypted with a weak cipher. 273 The external key exchange user authentication method must have acces to 274 information form the key exchange. If this information is unavailable 275 the authentication must fail. Care must be taken when matching verifying 276 additional credentials escpecially in the case when the binding is just 277 to a name as it may be in the case of authorization certificates. 279 6. References 281 [KRB5] Kohl J. and C. Neuman, "The Kerberos Network Authentication 282 Service (V5)", RFC 1510, September 1993. 284 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet 285 Draft, draft-secsh-transport-07.txt 287 [SSH-USERAUTH] Ylonen, T., et al, "SSH Authentication Protocol", 288 Internet Draft, draft-ietf-secsh-userauth-07.txt 290 [X509AC] S. Farrell and R. Housley "An Internet Attribute Certificate 291 Profile for Authorization," ,Internet Draft, 292 draft-ietf-pkix-ac509prof-05.txt 294 [TLS-KRB] A. Medvinsky and M. Hur, "Addition of Kerberos Cipher Suites 295 to Transport Layer Security (TLS)", RFC 2712, October 1999 297 7. Author�s Address 299 Joseph Salowey 300 WRQ 301 1500 Dexter Ave. N 302 Seattle, WA 98109 304 Phone: +1 206 217 7129 305 Email: joes@wrq.com 307 Full Copyright Statement 309 Copyright (C) The Internet Society (2000). All Rights Reserved. 311 This document and translations of it may be copied and furnished to 312 others, and derivative works that comment on or otherwise explain it or 313 assist in its implmentation may be prepared, copied, published and 314 distributed, in whole or in part, without restriction of any kind, 315 provided that the above copyright notice and this paragraph are included 316 on all such copies and derivative works. However, this document itself 317 may not be modified in any way, such as by removing the copyright notice 318 or references to the Internet Society or other Internet organizations, 319 except as needed for the purpose of developing Internet standards in 320 which case the procedures for copyrights defined in the Internet 321 Standards process must be followed, or as required to translate it into 322 languages other than English. 324 The limited permissions granted above are perpetual and will not be 325 revoked by the Internet Society or its successors or assigns. 327 This document and the information contained herein is provided on an "AS 328 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 329 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 330 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 331 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 332 FITNESS FOR A PARTICULAR PURPOSE." 334 This draft expires February 2001.