idnits 2.17.1 draft-johansson-http-gss-04.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 509. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 2, 2008) is 5654 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** 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) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Johansson 3 Internet-Draft SU 4 Intended status: Standards Track November 2, 2008 5 Expires: May 6, 2009 7 GSSAPI authentication for HTTP 8 draft-johansson-http-gss-04 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 6, 2009. 35 Abstract 37 This document specifies a template extension to the HTTP Negotiate 38 authentication mechanism defined in RFC4559 which supports mutual 39 authentication, fast session-based re-authentication and channel 40 bindings. An IANA registry for such GSS-API HTTP authentication 41 mechanisms is defined. 43 Table of Contents 45 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Introduction and motivation . . . . . . . . . . . . . . . . . 4 47 3. HTTP GSS Authentication Mechanism . . . . . . . . . . . . . . 5 48 3.1. GSS Token Header Syntax . . . . . . . . . . . . . . . . . 5 49 3.2. Naming and Transport . . . . . . . . . . . . . . . . . . . 5 50 3.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6 51 3.3.1. Intiating authentication . . . . . . . . . . . . . . . 6 52 3.3.2. The authentication phase . . . . . . . . . . . . . . . 7 53 3.3.3. The authorization phase . . . . . . . . . . . . . . . 8 54 3.3.4. Fast Renegotiation . . . . . . . . . . . . . . . . . . 8 55 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 56 5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 11 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 58 7. Notes & TODO . . . . . . . . . . . . . . . . . . . . . . . . . 13 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 60 8.1. Registration Procedure . . . . . . . . . . . . . . . . . . 14 61 8.2. Change Control . . . . . . . . . . . . . . . . . . . . . . 15 62 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 63 9.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . . 16 64 9.2. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 9.3. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . . 16 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 Intellectual Property and Copyright Statements . . . . . . . . . . 19 72 1. Terminology 74 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" 75 and "MAY" that appear in this document are to be interpreted as 76 described in [RFC2119] 78 2. Introduction and motivation 80 [RFC4559] describes an authentication mechanism based on SPNEGO for 81 HTTP. This mechanism suffers from a couple of drawbacks, notably: 83 Only supports single-round-trip GSS-API mechanisms due to lack of 84 support for proxies. 86 Lack of channel bindings to the underlying HTTPS connection which 87 makes in unsuitable for deployment in situations where proxies 88 exists. 90 Lack of session-based re-authentication (compare with TLS). 92 This document is intended to solve these problems by introducing a 93 new authentication mechanism called 'GSS'. This mechanism is a 94 proper extension of Negotiate but since Negotiate is already widely 95 deployed this mechanism was given a separate name. 97 3. HTTP GSS Authentication Mechanism 99 The GSS mechanism is an authentication mechanism for [RFC2616] based 100 on a multi-roundrip handshake using base64-encoded GSS-API [RFC2743] 101 tokens encoded in the WWW-Authenticate Response Header and the 102 Authorization Request Header. An important difference from [RFC4559] 103 is that multiple round trips are supported which means that the 104 server can be authenticated to the client (aka mutual 105 authentication). This document specifies a template authentication 106 mechanism with an associated IANA registry which provides input 107 parameters to the HTTP authentication mechanism describe below. 109 3.1. GSS Token Header Syntax 111 Both the Authorization and the WWW-Authenticate headers use the same 112 syntax throughout the handshake (cf below for details on the protocol 113 flow) specified by this Augmented BNF following [RFC2617] and 114 [RFC2616]: 116 challenge = auth-scheme-name 1*SP 1#auth-param 117 auth-scheme-name = token 118 auth-param = ( auth-data-value | 119 auth-param-type "=" auth-param-value ) 120 auth-param-value = ( token | quoted-string ) 121 auth-param-type = ( "auth-data" | "context-identifier" ) 122 auth-data-value = 1*(UPALPHA|DIGIT) ;base64-encoded 123 context-identifier-value = 1*(UPALPHA|DIGIT) ;base64-encoded 125 The auth-param types defined by this specification (auth-data and 126 context-identifier) both have auth-param-value which contain base64 127 encoded data. Note that both the auth-data and context-identifier 128 auth-param may be absent. The semantics of these parameters will be 129 explained below. Each auth-param-type MUST NOT occur more than once 130 in a single challenge. 132 The auth-scheme-name token is the name of the mechanism and is 133 supplied in the IANA registry template described below. 135 For reasons of backwards compatibility with [RFC4559] two forms of 136 the auth-param are allowed - one version based on attribute-parameter 137 pairs and one where only GSS-API data is sent. 139 3.2. Naming and Transport 141 The GSS name of the server is "HTTP@[:port]" where the 142 :port part is absent if the port == 80 or if the port == 443. 144 This mechanism SHOULD be used together with an HTTP transport 145 providing session protection and encryption such as [RFC2817] or 146 [RFC2818] . Session protection is a requirement for fast re- 147 authentication described below. 149 Like [RFC4559] the mechanism described in this specification is based 150 on mapping the GSS-API protocol to HTTP requests and responses where 151 the GSS-API tokens are sent in the Authorization and WWW- 152 Authentication headers. Unlike [RFC4559] the entire handshake need 153 not take place using a single TCP connection or a single HTTP/1.1 154 session. Instead opaque identifiers in the GSS challenge option 155 field are optionally used together with channel bindings to provide a 156 way to share a security context over several HTTP connections. This 157 mechanism also serves as a way to let the client do a fast re- 158 authentication to the server. 160 3.3. Protocol Flow 162 3.3.1. Intiating authentication 164 Normally the server initiates an authentication handshake when the 165 client attempts to access a protected resource. The exception is 166 when the client knows that it is accessing a protected resource and 167 that the server supports the GSS mechanism, for instance when fast 168 re-authentication is attempted by the client (cf below). In both 169 cases the GSS-API negotiation is initiated by the client - i.e if the 170 server initiates the authentication it is only to inform the client 171 that authentication is required. The client SHOULD request mutual 172 authentication from the GSS-API layer. 174 Note that the first request by the client to a protected resource 175 will also serve to let the client and server establish channel 176 bindings in the sense of [RFC5056] using the 'tls-server-end-point' 177 CB type which means that this first request is not in general 178 "wasted" even in the case when the client has no prior knowledge 179 about the server or is attempting fast re-authentication. 181 If the client tries to access a protected resource the server may 182 return a code 401 response with an WWW-Authenticate header containing 183 a list of authentication challenges allowing the client to choose 184 among different authentication mechanisms supported by the server. 185 If the server supports the mechanism specified by the auth-scheme- 186 name the server returns a challenge with only the auth-scheme-name 187 part and no parameters along with any other challenges for mechanisms 188 supported by the server. This first request also allows the client 189 and server to establish channel-bindings. 191 3.3.2. The authentication phase 193 In each case below when GSS-API tokens resulting from calls into the 194 GSS-API layer are sent from the server to the client or vice-versa, 195 the token is encoded using base64 and sent as the "auth-data" 196 parameter value of the Authorization and WWW-Authenticate headers 197 respectively. 199 A client initiates the authentication phase by sending the token 200 resulting from the first call to gss_init_security_context to the 201 server. 203 Upon receipt of token (i.e a request with an accompanying 204 Authenticate header with non-empty "auth-data" parameter value), the 205 server MUST return the token resulting from a call to 206 gss_accept_security_context in a code 401 response, unless the call 207 to gss_accept_security_context fails in which case a code 403 208 response is returned. 210 If the underlying transport provides session protection (eg HTTPS) 211 and if channel-bindings are in place (cf below) then the server MAY 212 include a unique identifier of the security context beeing negotiated 213 (or having been negotiated in the case of the last transaction) in 214 the "context-identifier" parameter value. The server MUST uniquely 215 associate this identifier with the client and the security context. 217 Upon receipt of a code 401 response from the server when the WWW- 218 Authenticate header contains a non-empty "auth-data" parameter value, 219 the client MUST return the token resulting from a call to 220 gss_initiate_security_context to the server in a new request to the 221 same resource. If the call fails the client MUST close the 222 connection. If a "context-identifier" parameter value is present in 223 the response from the server the client MUST include this in the 224 ensuing request as the "context-identifier" parameter value. If the 225 "context-identifier" parameter value is not present in the response 226 from the server the client MUST use the same HTTP/1.1 connection for 227 the entier handshake. If the client breaks the HTTP/1.1 connection 228 the server MUST invalidate the security context unless a context 229 identifier was sent to the client and returned to the server. 231 A client may close the connection both as the result of using the 232 context-identifier to spread the authentication over several 233 underlying connections or as the result of a failed call to 234 gss_initiate_security_context. This might at first seem like a 235 problem but the GSS-API layer combined with proper handling of the 236 context identifier will ensure that handling of these cases are 237 disambiguated at the server. 239 The client and server continues the handshake until either an error 240 occurs (in which case a 403 is returned to the client or the client 241 closes the connection depending on where the error happens) or the 242 GSS-API layer has successfully completed the negotiation in which 243 case the server sends a normal response to the client. If the last 244 call to gss_accept_sec_context on the server resulted in a non-empty 245 token the server MUST include this in a WWW-Authenticate header in 246 the response to the client regardless of the return code which is 247 beeing sent to the client. If the underlying transport provides 248 session protection (eg HTTPS) and if channel-bindings are in place 249 (cf below) then the server MAY include a "context-identifier" 250 parameter value uniquely identifying the established security 251 context. The server MAY decide to limit the validity of the 252 established context and MAY choose not to consider references to the 253 context after a certain amount of time (cf below). 255 If the client receives a normal response with an non-empty "auth- 256 data" parameter value the client MUST call gss_initiate_sec_context 257 with this token as input to complete the authentication handshake. 258 If the final response contains a "context-identifier" parameter value 259 the client may cache it and use it to provide fast re-authentication 260 by including it in a Authorization header with auth-scheme-name and 261 empty "auth-data" parameter value. 263 3.3.3. The authorization phase 265 Authorization failures can occur even if the client is successfully 266 authenticated to the server. In this case the server will send a 403 267 response to the client even though the GSS-API handshake has 268 succeeded. It is important to let the client and server finish the 269 authentication handshake even if the client is not authorized to 270 access the resource. Therefore the client MUST call 271 gss_initiate_sec_context with any GSS-API token returned to the 272 client, even if the token was sent along with a 403 response. 274 During authorization the server MAY use the GSS-API name associated 275 with the established security context for authorization decisions and 276 should provide a string representation of the GSS-API name as the 277 REMOTE_USER meta-variable and the auth-scheme-name as the AUTH_TYPE 278 meta-variable if the Common Gateway Interface (CGI) is provided by 279 the server. 281 3.3.4. Fast Renegotiation 283 Upon receipt of a request containing an Authorization header with the 284 auth-scheme-name, an empty auth-data and the context-identifier 285 parameter value, the server MUST verify that the identifier 286 references a valid security context. If the security context is 287 missing or invalid the server MUST return a 401 response prompting 288 the client to re-negotiate the security context. If the identifier 289 references a valid security context the server MUST process the 290 request as if the client had just completed the full authentication 291 handshake. 293 When this process is completed the client is authenticated to the 294 server and possibly (depending on the way the GSS-API layer was 295 called and which GSS-mechanism was used) the server is authenticated 296 to the client. 298 The use of fast regegotiation is optional and clients and servers 299 MUST NOT assume that this feature is supported. 301 4. Examples 303 TODO 305 5. Implementation Notes 307 The context-identifier could be produced by exporting the security 308 context through gss_export_sec_context which requires that the GSS- 309 API implementation supports exporting unfinished contexts. 311 6. Security Considerations 313 Should channel-bindings be absent, the protocol is subject to a MITM 314 attack unless the authentication is between a client and a server 315 with no proxies in between and each request is sent over the same 316 HTTP/1.1 connection. 318 If fast re-authentication is used together with GSS-API credentials 319 delegation the server will need to associate forwarded credentials 320 with the negotiated security context. This presents a challenge for 321 server implementors since it must be guarateed that security states 322 and their associated credentials must be separated from each other. 324 7. Notes & TODO 326 Examples 328 8. IANA Considerations 330 IANA will create a new registry for HTTP authentication mechanisms 331 based on this document. The purpose of the registry is to bind the 332 HTTP authentication mechanism name (auth-scheme-name in the syntax 333 above) to the GSS-API mechanism OID. Such HTTP authentication 334 mechanisms will be called GSS-API HTTP authentication mechanisms. 336 Names for GSS-API HTTP authentication mechanisms must follow the 337 token syntax of section 2.2 of [RFC2616]. 339 The procedure detailed in the section below is to be used for 340 registration of a value naming a specific GSS-API HTTP authentication 341 mechanism. 343 8.1. Registration Procedure 345 Registration of a new GSS-API HTTP authentication mechanism requires 346 expert review as defined in BCP 26 [RFC2434]. Registration of a GSS- 347 API HTTP authentication mechanism is requested by filling in the 348 following template: 350 Subject: Registration of GSS-API HTTP authentication mechanism X 352 GSS-API HTTP authentication mechanism name: 354 GSS-API mechanism OID: 356 Description or Published Specification: 358 State management: (one of INTERNAL or EXTERNAL) 360 Intended usage: (one of COMMON, LIMITED USE, OBSOLETE) 362 Person and email address to contact for further information: 364 Change manager name and email address: 366 Expert reviewer name and contact information: (leave blank) 368 Note: (Any other information deemed relevant) 370 and sending it via electronic mail to (a public 371 mailing list) and carbon copying (cc:) IANA at . 372 After allowing new fewer than 2 weeks for community input on the 373 mailing list to be determined, an expert will determine the 374 appropriateness of the registration request and either approve or 375 disapprove the request with notice to the requester, the mailing list 376 and IANA. 378 If the registration was approved the expert adds her name to the 379 submitted registration. 381 The expert is responsible for making sure that GSS-API authentication 382 scheme names are unique among all HTTP authentication mechanism names 383 and represent an appropriate name for the underlying GSS-API 384 mechanism. 386 Authors are encouraged to pursue community review by posting the 387 technical specification as an Internet-Draft and soliciting comment 388 by posting to appropriate IETF mailing lists. 390 8.2. Change Control 392 Once a GSS-API HTTP authentication mechanism has been published by 393 IANA, the author may request a change to its definition. The change 394 request follows the same procedure as the registration request. The 395 change manager is part of the registration template and controls who 396 may request changes to the registration. Passing control of a 397 registration is also accomplished by submitting a change request. 399 The IESG may also reassign control and responsibility for GSS-API 400 HTTP authentication mechanism registrations. This is expected to 401 happen when the author of a registration has died, has moved out of 402 contact, or is otherwise unable to make changes to the registered 403 mechanism(s)s. Furthermore the IESG is the owner of all GSS-API HTTP 404 authentication mechanisms that correspond to specifications on the 405 IETF standards track. 407 9. Changes 409 9.1. 00 to 01 411 Changed from ABNF to Augmented BNF to align with [RFC2616]. 413 9.2. 02 to 03 415 Added reference to rfc 5056. 417 Reference to tls-server-end-point channel binding mechanism. 419 9.3. 03 to 04 421 Generalized to IANA-controlled registry of authentication mechanisms. 422 Wrote IANA considerations section. Generalized the ABNF to cover old 423 Negotiate case which can now be turned into an IANA registration 424 covered by this specification. 426 10. References 428 10.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, March 1997. 433 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 434 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 435 October 1998. 437 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 438 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 439 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 441 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 442 Leach, P., Luotonen, A., and L. Stewart, "HTTP 443 Authentication: Basic and Digest Access Authentication", 444 RFC 2617, June 1999. 446 [RFC2743] Linn, J., "Generic Security Service Application Program 447 Interface Version 2, Update 1", RFC 2743, January 2000. 449 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 450 HTTP/1.1", RFC 2817, May 2000. 452 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 454 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 455 Channels", RFC 5056, November 2007. 457 10.2. Informative References 459 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 460 Kerberos and NTLM HTTP Authentication in Microsoft 461 Windows", RFC 4559, June 2006. 463 Author's Address 465 Leif Johansson 466 Stockholm university 468 Email: leifj@it.su.se 469 URI: http://www.su.se/ 471 Full Copyright Statement 473 Copyright (C) The IETF Trust (2008). 475 This document is subject to the rights, licenses and restrictions 476 contained in BCP 78, and except as set forth therein, the authors 477 retain all their rights. 479 This document and the information contained herein are provided on an 480 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 481 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 482 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 483 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 484 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 485 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 487 Intellectual Property 489 The IETF takes no position regarding the validity or scope of any 490 Intellectual Property Rights or other rights that might be claimed to 491 pertain to the implementation or use of the technology described in 492 this document or the extent to which any license under such rights 493 might or might not be available; nor does it represent that it has 494 made any independent effort to identify any such rights. Information 495 on the procedures with respect to rights in RFC documents can be 496 found in BCP 78 and BCP 79. 498 Copies of IPR disclosures made to the IETF Secretariat and any 499 assurances of licenses to be made available, or the result of an 500 attempt made to obtain a general license or permission for the use of 501 such proprietary rights by implementers or users of this 502 specification can be obtained from the IETF on-line IPR repository at 503 http://www.ietf.org/ipr. 505 The IETF invites any interested party to bring to its attention any 506 copyrights, patents or patent applications, or other proprietary 507 rights that may cover technology that may be required to implement 508 this standard. Please address the information to the IETF at 509 ietf-ipr@ietf.org.