1 2 3Kerberos working group J.Brezak 4Internet Draft Microsoft 5Document: draft-brezak-spnego-http-00.txt 6Category: Informational 7 September 2001 8 9 10 HTTP Authentication: SPNEGO Access Authentication 11 12 13Status of this Memo 14 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. Internet-Drafts are 20 draft documents valid for a maximum of six months and may be 21 updated, replaced, or obsoleted by other documents at any time. It 22 is inappropriate to use Internet- Drafts as reference material or to 23 cite them other than as "work in progress." 24 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 30 311. Abstract 32 33 This document describes how Microsoft�s Internet Explorer 5.0 and 34 Internet Information Services 5.0 use Kerberos for security 35 enhancements of web transactions. The HTTP auth-scheme of 36 'negotiate' is defined here; when the negotiation results in the 37 selection of Kerberos, the security services of authentication and 38 optionally impersonation are performed. 39 40 412. Conventions used in this document 42 43 In examples, "C:" and "S:" indicate lines sent by the client and 44 server respectively. 45 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 48 this document are to be interpreted as described in RFC-2119 [3]. 49 50 513. Access Authentication 52 533.1 Reliance on the HTTP/1.1 Specification 54 55 This specification is a companion to the HTTP/1.1 specification [4] 56 and builds on the authentication mechanisms defined in [5]. It uses 57 58Brezak Category � Informational 1 59 60 61 62 63 64 65 66 67 SPNEGO Access Authentication September 2001 68 69 the augmented BNF section 2.1 of that document, and relies on both 70 the non-terminals defined in that document and other aspects of the 71 HTTP/1.1 specification. 72 73 744. HTTP Negotiate Authentication Scheme 75 76 Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate". 77 The auth-params exchanged use data formats defined for use with the 78 GSS-API [6]. In particular, they follow the formats set for the 79 SPNEGO [7] and Kerberos [8] "mechanisms" for GSSAPI. The 80 "Negotiate" auth-scheme calls for the use of SPNEGO GSSAPI tokens 81 which the specific mechanism type specifies. 82 834.1 The WWW-Authenticate Response Header 84 85 If the server receives a request for an access-protected object, and 86 an acceptable Authorization header is not sent, the server responds 87 with a "401 Unauthorized" status code, and a WWW-Authenticate header 88 as per the framework described in [4]. The negotiate scheme will 89 operate as follows: 90 91 92 challenge = "Negotiate" auth-data 93 auth-data = 1#( [gssapi-data] ) 94 95 The meanings of the values of the directives used above are as 96 follows: 97 98 gssapi-data 99 If the gss_accept_security_context return a token for the 100 client, this directive contains is the base64 encoding of an 101 InitialContextToken as defined in [6]. 102 103 A status code 200 response can also carry a WWW-Authenticate 104 response header containing the final leg of a authentication. Before 105 using the contents of the response, the gssapi-data should be 106 processed by gss_init_security_context to determine the state of the 107 security context. If this function indicates success, the response 108 can be used by the application. Otherwise an appropriate action 109 based on the authentication status should be. 110 111 For example the authentication could have failed on the final leg if 112 mutual authentication was requested and the server was not able to 113 prove its identity. In this case, the returned results are suspect. 114 It is not always possible to mutually authenticate the server before 115 the HTTP operation. POST methods are in this category. 116 117 When the Kerberos Version 5 GSSAPI mechanism [RFC-1964] is being 118 used, the HTTP server will be using a principal name of the form of 119 "http/<hostname>". 120 1214.2 The Authorization Request Header 122 123 124Brezak Category � Informational 2 125 126 127 128 129 130 131 132 133 SPNEGO Access Authentication September 2001 134 135 The client is expected to retry the request, passing an 136 Authorization header line, which is defined according to the 137 framework described in [4] utilized as follow: 138 139 credentials = "Negotiate" auth-data2 140 auth-data2 = 1#( gssapi-data ) 141 142 gssapi-data 143 This directive contains is the base64 encoding of an 144 InitialContextToken as defined in [6]. 145 146 If a directive or its value is improper, or required directives are 147 missing, the propose response is 400 Bad Request. If a 401 148 Unauthorized status code is returned, the contents of the WWW- 149 Authenticate response header is used to continue the authentication 150 as long as the opaque value is the same. 151 1525. Negotiate Operation Example 153 154 The user is logged onto realm A.COM as user@A.COM. The web server is 155 in realm B using the principal http/server@B.COM. Realm B.COM trusts 156 Realm A.COM 157 158 The client requests an access-protected document from server via a 159 GET method request. The URI of the document is 160 "http://www.nowhere.org/dir/index.html". 161 162 The first time the client requests the document, no Authorization 163 header is sent, so the server responds with: 164 165 HTTP/1.1 401 Unauthorized 166 WWW-Authenticate: Negotiate 167 168 The client will obtain the user credentials using the SPNEGO GSSAPI 169 mechanism type to identify generate a GSSAPI message to be sent to 170 the server with a new request, including the following Authorization 171 header: 172 173 Authorization: Negotiate 174 2a87421000492ade0234568ac0289eca874209af8bc028 175 176 The server will decode the gssapi-data and pass this to the SPNEGO 177 GSSAPI mechanism in the gss_accept_security_context function. The 178 return value from the gss_accept_security_context function can 179 indicate the security context is complete and supply final 180 authentication data to be returned to the client. If the server has 181 more gssapi data to send to the client to complete the context it is 182 to be carried in WWW-Authenticate header with the final response. 183 The response will be sent to the client, including the following 184 header: 185 186 HTTP/1.1 200 Success 187 WWW-Authenticate: Negotiate ade0234568ac874209af8bc0280289eca 188 189 190Brezak Category � Informational 3 191 192 193 194 195 196 197 198 199 SPNEGO Access Authentication September 2001 200 201 The client will decode the gssapi-data and supply it to 202 gss_init_security_context using the context for this server. If the 203 status is successful from the final gss_init_security_context, the 204 response can be used by the application. 205 2067. Security Considerations 207 208 The SPNEGO HTTP authentication facility is only used to provide 209 authentication of a user to server. It provides no facilities for 210 protecting the HTTP headers or data including the Authorization and 211 WWW-Authenticate headers that are used to implement this mechanism. 212 213 This mechanism is not used for HTTP authentication to HTTP proxies. 214 215 If an HTTP proxy is used between the client and server, it must take 216 care to not share authenticated connections between different 217 authenticated clients to the same server. If this is not honored, 218 then the server can easily lose track of security context 219 associations. A proxy that correctly honors client to server 220 authentication integrity will supply the "Proxy-support: Session- 221 Based-Authentication" HTTP header to the client in HTTP responses 222 from the proxy. The client MUST NOT utilize the SPNEGO HTTP 223 authentication mechanism through a proxy unless the proxy supplies 224 this header with the 401 Unauthorized response from the server. 225 226 2278. References 228 229 230 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 231 9, RFC 2026, October 1996. 232 233 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 234 Levels", BCP 14, RFC 2119, March 1997 235 236 4 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 237 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 238 HTTP/1.1", RFC 2616, June 1999. 239 240 5 Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, 241 P., Luotonen, A., Stewart, L., "HTTP Authentication: Basic and 242 Digest Access Authentication", RFC 2617, June 1999. 243 244 6 Linn, J., "Generic Security Service Application Program Interface, 245 Version 2", RFC 2078, January 1997. 246 247 7 Baize, E., Pinkas, D., "The Simple and Protected GSS-API 248 Negotiation Mechanism", RFC 2478, December 1998. 249 250 8 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 251 June 1996. 252 253 254 255 256Brezak Category � Informational 4 257 258 259 260 261 262 263 264 265 SPNEGO Access Authentication September 2001 266 267 26810. Author's Addresses 269 270 John Brezak 271 Microsoft 272 One Microsoft Way 273 Redmond, Washington 274 Email: jbrezak@microsoft.com 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322Brezak Category � Informational 5 323 324 325 326 327 328 329 330 331 SPNEGO Access Authentication September 2001 332 333 334Full Copyright Statement 335 336 Copyright (C) The Internet Society (2001). All Rights Reserved. 337 338 This document and translations of it may be copied and furnished to 339 others, and derivative works that comment on or otherwise explain it 340 or assist in its implementation may be prepared, copied, published 341 and distributed, in whole or in part, without restriction of any 342 kind, provided that the above copyright notice and this paragraph 343 are included on all such copies and derivative works. However, this 344 document itself may not be modified in any way, such as by removing 345 the copyright notice or references to the Internet Society or other 346 Internet organizations, except as needed for the purpose of 347 developing Internet standards in which case the procedures for 348 copyrights defined in the Internet Standards process must be 349 followed, or as required to translate it into languages other than 350 English. 351 352 The limited permissions granted above are perpetual and will not be 353 revoked by the Internet Society or its successors or assigns. 354 355 This document and the information contained herein is provided on an 356 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 357 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 358 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 359 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 360 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388Brezak Category � Informational 6 389 390 391 392 393 394 395 396