idnits 2.17.1 draft-jaganathan-kerberos-http-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 344. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) 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 (July 18, 2005) is 6857 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4120' is defined on line 287, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2078 (Obsoleted by RFC 2743) ** Obsolete normative reference: RFC 2478 (Obsoleted by RFC 4178) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Jaganathan 3 Internet-Draft L. Zhu 4 Document: draft-jaganathan-kerberos-http-01.txt J. Brezak 5 Category: Informational Microsoft Corporation 6 Expires: January 19, 2006 July 18, 2005 8 Kerberos based HTTP Authentication in Windows 9 draft-jaganathan-kerberos-http-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 19, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes how the Microsoft Internet Explorer (MSIE) 43 and Internet Information Services (IIS) incorporated in Microsoft 44 Windows 2000 use Kerberos for security enhancements of web 45 transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of 46 "negotiate" is defined here; when the negotiation results in the 47 selection of Kerberos, the security services of authentication and 48 optionally impersonation(the IIS server assuming the windows identity 49 of the principal which has been authenticated) are performed. This 50 document explains how HTTP authentication utilizes the Simple and 51 Protected GSS-API Negotiation mechanism. Details of SPNEGO 52 implementation are not provided in this document. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 58 3. Access Authentication . . . . . . . . . . . . . . . . . . . . 5 59 3.1 Reliance on the HTTP/1.1 Specification . . . . . . . . . . 5 60 4. HTTP Negotiate Authentication Scheme . . . . . . . . . . . . . 6 61 4.1 The WWW-Authenticate Response Header . . . . . . . . . . . 6 62 4.2 The Authorization Request Header . . . . . . . . . . . . . 7 63 5. Negotiate Operation Example . . . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 67 Intellectual Property and Copyright Statements . . . . . . . . 12 69 1. Introduction 71 Microsoft has provided support for Kerberos authentication in MSIE 72 and IIS in addition to other mechanisms. This provides the benefits 73 of the Kerberos v5 protocol for Web applications. Support for 74 Kerberos authentication is based on other previously defined 75 mechanisms such as SPNEGO and the Generic Security Services 76 Application Program Interface(GSSAPI). 78 2. Conventions Used in This Document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 3. Access Authentication 86 3.1 Reliance on the HTTP/1.1 Specification 88 This specification is a companion to the HTTP/1.1 specification 89 [RFC2616] and builds on the authentication mechanisms defined in 90 [RFC2617]. It uses the augmented BNF section 2.1 of that document, 91 and relies on both the non-terminals defined in that document and 92 other aspects of the HTTP/1.1 specification. 94 4. HTTP Negotiate Authentication Scheme 96 Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate". 97 The auth-params exchanged use data formats defined for use with the 98 GSS-API [RFC2078]. In particular, they follow the formats set for 99 the SPNEGO [RFC2478] and Kerberos [RFC4121] mechanisms for GSSAPI. 100 The "Negotiate" auth-scheme calls for the use of SPNEGO GSSAPI tokens 101 which the specific mechanism type specifies. 103 The current implementation of this protocol is limited to the use of 104 SPNEGO with the Kerberos and Microsoft(NT Lan Manager) NTLM 105 protocols. 107 4.1 The WWW-Authenticate Response Header 109 If the server receives a request for an access-protected object, and 110 an acceptable Authorization header has not been sent, the server 111 responds with a "401 Unauthorized" status code, and a "WWW- 112 Authenticate:" header as per the framework described in [RFC2616]. 113 The initial WWW-Authenticate header will not carry any gssapi-data. 115 The negotiate scheme will operate as follows: 117 challenge = "Negotiate" auth-data 118 auth-data = 1#( [gssapi-data] ) 120 The meanings of the values of the directives used above are as 121 follows: 123 gssapi-data 125 If the gss_accept_security_context return a token for the client, 126 this directive contains the base64 encoding of an InitialContextToken 127 as defined in [RFC2078]. This is not present in the initial response 128 from the server. 130 A status code 200 status response can also carry a "WWW- 131 Authenticate" response header containing the final leg of an 132 authentication. In this case, the gssapi-data will be present. 133 Before using the contents of the response, the gssapi-data should be 134 processed by gss_init_security_context to determine the state of the 135 security context. If this function indicates success, the response 136 can be used by the application. Otherwise an appropriate action 137 based on the authentication status should be. 139 For example the authentication could have failed on the final leg if 140 mutual authentication was requested and the server was not able to 141 prove its identity. In this case, the returned results are suspect. 142 It is not always possible to mutually authenticate the server before 143 the HTTP operation. POST methods are in this category. 145 When the Kerberos Version 5 GSSAPI mechanism [RFC4121] is being used, 146 the HTTP server will be using a principal name of the form of "HTTP/ 147 hostname". 149 4.2 The Authorization Request Header 151 Upon receipt of the response containing a "WWW-Authenticate" header 152 from the server, the client is expected to retry the HTTP request, 153 passing a HTTP "Authorization" header line. This is defined 154 according to the framework described in [RFC2616] utilized as 155 follows: 157 credentials = "Negotiate" auth-data2 158 auth-data2 = 1#( gssapi-data ) 160 gssapi-data 162 This directive contains is the base64 encoding of an 163 InitialContextToken as defined in [RFC2078]. 165 Any returned code other than a success 2xx code represents an 166 authentication error. If a 401 containing a "WWW-Authenticate" 167 header with "Negotiate" and gssapi-data is returned from the server, 168 it is a continuation of the authentication request. 170 A client may initiate a connection to the server with an 171 "Authorization" header containing the initial token for the server. 172 This form will bypass the initial 401 error from the server when the 173 client knows that the server will accept the Negotiate HTTP 174 authentication type. 176 5. Negotiate Operation Example 178 The client requests an access-protected document from server via a 179 GET method request. The URI of the document is 180 "http://www.nowhere.org/dir/index.html". 182 C: GET dir/index.html 184 The first time the client requests the document, no Authorization 185 header is sent, so the server responds with: 187 S: HTTP/1.1 401 Unauthorized 188 S: WWW-Authenticate: Negotiate 190 The client will obtain the user credentials using the SPNEGO GSSAPI 191 mechanism type to identify generate a GSSAPI message to be sent to 192 the server with a new request, including the following Authorization 193 header: 195 C: GET dir/index.html 196 C: Authorization: Negotiate a87421000492aa874209af8bc028 198 The server will decode the gssapi-data and pass this to the SPNEGO 199 GSSAPI mechanism in the gss_accept_security_context function. If the 200 context is not complete, the server will respond with a 401 status 201 code with a WWW-Authenticate header containing the gssapi-data. 203 S: HTTP/1.1 401 Unauthorized 204 S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356 206 The client will decode the gssapi-data and pass this into 207 gss_init_security_context and return the new gssapi-data to the 208 server. 210 C: GET dir/index.html 211 C: Authorization: Negotiate 89a8742aa8729a8b028 213 This cycle can continue until the security context is complete. When 214 the return value from the gss_accept_security_context function 215 indicates that the security context is complete, it may supply final 216 authentication data to be returned to the client. If the server has 217 more gssapi data to send to the client to complete the context it is 218 to be carried in WWW-Authenticate header with the final response 219 containing the HTTP body. 221 S: HTTP/1.1 200 Success 222 S: WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca 224 The client will decode the gssapi-data and supply it to 225 gss_init_security_context using the context for this server. If the 226 status is successful from the final gss_init_security_context, the 227 response can be used by the application. 229 6. Security Considerations 231 The SPNEGO HTTP authentication facility is only used to provide 232 authentication of a user to server. It provides no facilities for 233 protecting the HTTP headers or data including the Authorization and 234 WWW-Authenticate headers that are used to implement this mechanism. 236 Alternate mechanisms such as TLS can be used to provide 237 confidentiality. Hashes of the TLS certificates can be used as 238 channel bindings to secure the channel. In this case clients would 239 need to enforce that the channel binding information is valid. Note 240 that Kerb-TLS [RFC2712] could be used to provide both authentication 241 and confidentiality but this requires a change to the TLS provider. 243 This mechanism is not used for HTTP authentication to HTTP proxies. 245 If an HTTP proxy is used between the client and server, it must take 246 care to not share authenticated connections between different 247 authenticated clients to the same server. If this is not honored, 248 then the server can easily lose track of security context 249 associations. A proxy that correctly honors client to server 250 authentication integrity will supply the "Proxy-support: Session- 251 Based-Authentication" HTTP header to the client in HTTP responses 252 from the proxy. The client MUST NOT utilize the SPNEGO HTTP 253 authentication mechanism through a proxy unless the proxy supplies 254 this header with the "401 Unauthorized" response from the server. 256 When using the SPNEGO HTTP authentication facility with client 257 supplied data such as PUT and POST, the authentication should be 258 complete between the client and server before sending the user data. 259 The return status from the gss_init_security_context will indicate 260 with the security context is complete. At this point the data can be 261 sent to the server. 263 7. Normative References 265 [RFC2078] Linn, J., "Generic Security Service Application Program 266 Interface, Version 2", RFC 2078, January 1997. 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, March 1997. 271 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 272 Negotiation Mechanism", RFC 2478, December 1998. 274 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 275 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 276 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 278 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 279 Leach, P., Luotonen, A., and L. Stewart, "HTTP 280 Authentication: Basic and Digest Access Authentication", 281 RFC 2617, June 1999. 283 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 284 Suites to Transport Layer Security (TLS)", RFC 2712, 285 October 1999. 287 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 288 Kerberos Network Authentication Service (V5)", RFC 4120, 289 July 2005. 291 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 292 Version 5 Generic Security Service Application Program 293 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 294 July 2005. 296 Authors' Addresses 298 Karthik Jaganathan 299 Microsoft Corporation 300 One Microsoft Way 301 Redmond, WA 98052 302 US 304 Email: karthikj@microsoft.com 306 Larry Zhu 307 Microsoft Corporation 308 One Microsoft Way 309 Redmond, WA 98052 310 US 312 Email: lzhu@microsoft.com 314 John Brezak 315 Microsoft Corporation 316 One Microsoft Way 317 Redmond, WA 98052 318 US 320 Email: jbrezak@microsoft.com 322 Intellectual Property Statement 324 The IETF takes no position regarding the validity or scope of any 325 Intellectual Property Rights or other rights that might be claimed to 326 pertain to the implementation or use of the technology described in 327 this document or the extent to which any license under such rights 328 might or might not be available; nor does it represent that it has 329 made any independent effort to identify any such rights. Information 330 on the procedures with respect to rights in RFC documents can be 331 found in BCP 78 and BCP 79. 333 Copies of IPR disclosures made to the IETF Secretariat and any 334 assurances of licenses to be made available, or the result of an 335 attempt made to obtain a general license or permission for the use of 336 such proprietary rights by implementers or users of this 337 specification can be obtained from the IETF on-line IPR repository at 338 http://www.ietf.org/ipr. 340 The IETF invites any interested party to bring to its attention any 341 copyrights, patents or patent applications, or other proprietary 342 rights that may cover technology that may be required to implement 343 this standard. Please address the information to the IETF at 344 ietf-ipr@ietf.org. 346 Disclaimer of Validity 348 This document and the information contained herein are provided on an 349 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 350 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 351 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 352 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 353 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 354 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 356 Copyright Statement 358 Copyright (C) The Internet Society (2005). This document is subject 359 to the rights, licenses and restrictions contained in BCP 78, and 360 except as set forth therein, the authors retain all their rights. 362 Acknowledgment 364 Funding for the RFC Editor function is currently provided by the 365 Internet Society.