Network Working Group Johansson Internet-Draft SU Intended status: Standards Track October 13, 2006 Expires: April 16, 2007 GSSAPI authentication for HTTP draft-johansson-http-gss-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 any time. 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. This Internet-Draft will expire on April 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Johansson Expires April 16, 2007 [Page 1] Internet-Draft http-gss October 2006 Abstract This document specifies an extention to the HTTP Negotiate authentication mechanism defined in RFC4559 which supports mutual authentication, fast session-based reauth and channel bindings. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction and motivation . . . . . . . . . . . . . . . . . 4 3. HTTP GSS Authentication Mechanism . . . . . . . . . . . . . . 5 3.1. GSS Token Header Syntax . . . . . . . . . . . . . . . . . 5 3.2. Naming and Transport . . . . . . . . . . . . . . . . . . . 5 3.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6 3.3.1. Intiating authentication . . . . . . . . . . . . . . . 6 3.3.2. The authentication phase . . . . . . . . . . . . . . . 6 3.3.3. Fast Renegotiation . . . . . . . . . . . . . . . . . . 7 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Notes & TODO . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Johansson Expires April 16, 2007 [Page 2] Internet-Draft http-gss October 2006 1. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119] Johansson Expires April 16, 2007 [Page 3] Internet-Draft http-gss October 2006 2. Introduction and motivation [RFC4559] describes an authentication mechanism based on SPNEGO for HTTP. This mechanism suffers from a couple of drawbacks, notably: Only supports single-round-trip GSS-API mechanisms Lack of channel bindings to the underlying HTTPS connection which makes in unsuitable for deployment in situations where proxies exists. Lack of session-based re-authentication (compare with TLS). This document is intended to solve these problems by introducing a new authentication mechanism called 'GSS'. This mechanism is a proper extension of Negotiate but since Negotiate is already widely deployed this mechanism was given a separate name. Johansson Expires April 16, 2007 [Page 4] Internet-Draft http-gss October 2006 3. HTTP GSS Authentication Mechanism The GSS mechanism is an authentication mechanism for [RFC2616] based on a multi-roundrip handshake using base64-encoded GSS-API [RFC2743] tokens encoded in the WWW-Authenticate Response Header and the Authorization Request Header. An important difference from [RFC4559] is that multple roundtrips are supported which means that the server can be authenticated to the client (aka mutual authentication). 3.1. GSS Token Header Syntax Both the Authorization and the WWW-Authenticate headers use the same syntax in the handshake (cf below for details on the protocol flow) specified byt the following ABNF ([RFC4234]): challenge = "GSS" [WSP auth-data] [WSP "OPTIONS" options] auth-data = [base64-data] options = *(WSP gss-option) gss-option = option-type "=" option-value option-type = 1*(ALPHA) option-value = [base64-data] Note that the auth-data element may be absent. This specification defines a single option-type "context-identifier". The option-value in this case is an opaque binary encoded in base64. The semantics of this option will be explained below. Each option-type MUST not occur more than once in a single challenge. 3.2. Naming and Transport Following [RFC4559] the GSS name of the server is "HTTP@" This mechanism SHOULD be used together with a HTTP transport providing session protection and encryption such as [RFC2817] or [RFC2818]. This is a requirement for fast reauthentication described below. Like [RFC4559] the mechanism described in this specification is based on mapping the GSS-API protocol to HTTP requests and responses where the GSS-API tokens are sent in the Authorization and WWW- Authentication headers. Unlike [RFC4559] the entire handshake need not take place using a single TCP connection or a single HTTP/1.1 session. Instead opaque identifiers in the GSS challenge option field are optionally used together with channel bindings to provide a way to share a security context over several HTTP connections. This mechanism also serves as a way to let the client do a fast reauthentication to the server. Johansson Expires April 16, 2007 [Page 5] Internet-Draft http-gss October 2006 3.3. Protocol Flow 3.3.1. Intiating authentication Both the client and the server may initiate an authentication handshake. In both cases the GSS-API negotiation is initiated by the client - i.e if the server initiates the authentication it is only to inform the client that authentication is required. The client SHOULD request mutual authentication from the GSS-API layer. If the client initiates the authentication it MAY do so by sending a request with a Authorization header with empty auth-data (i.e without first calling gss_accept_sec_context) in order to let the client and server establish channel-bindings over any underlying transport (eg HTTPS - cf below). If the client tries to access a protected resource the server may return a code 401 response with an WWW-Authenticate header containing (the header is normally multivalued allowing the client to choose among different authentication mechanisms) a GSS token with an empty auth-data element. In this case this first request allows the client and server to establish channel-bindings so an extra roundtrip with empty auth-data is not needed. In general the client MUST preserve the original request with the exception of headers involved in the authentication. This includes any content of the request (eg in a POST) which must also be preserved throughout the negotiation. 3.3.2. The authentication phase A client initiates the authentication phase by sending the token resulting from the first call to gss_init_security_context to the server encoded in the auth-data element of the Authenticate header. Upon receipt of a request with an accompanying Authenticate header with non-empty auth-data, the server MUST call gss_accept_security_context returning the resulting token in a code 401 response (unless the call to gss_accept_security_context fails in which case an code 500 response is returned) with the token as the base64-encoded auth-data in the WWW-Authenticate header. If the underlying transport provides encryption (eg HTTPS) and if channel- bindings are in place (cf below) then the server MAY include a unique identifier of the security context (beeing negotiated) in the context-identifier option along with the GSS token. The server MUST in this case associate this identifier with the client and the security context beeing established. Johansson Expires April 16, 2007 [Page 6] Internet-Draft http-gss October 2006 Upon receipt of a code 401 response with the WWW-Authenticate header with a non-empty auth-data element, the client MUST call gss_initiate_security_context again with this token as input and resend the request with the resulting token as auth-data in an Authorization header. If a context-identifier option is present in the response from the server the client MUST include it in each ensuing request. If the option-value is not present in the response the client MUST use the same HTTP/1.1 connection for each ensuing response in the handshake. If the client breaks the HTTP/1.1 connection the server MUST invalidate the security context unless a context-identifier was sent to the client. This process continues until either an error occurs or the GSS-API layer has successfully completed the negotiation at which point the server sends a final code 200 response to the client. An error on the server-side of the negotiation MUST result in a code 500 response beeing returned to the client. If the last call to gss_accept_sec_context resulted in a non-empty token the server MUST include this in a WWW-Authenticate header. If the underlying transport provides encryption (eg HTTPS) and if channel-bindings are in place (cf below) then the server MAY include an opaque unique identifier of the established security context in the context- identifier option along with the GSS token. The server MUST associate this identifier with the client and with the established security context. The server MAY decide to limit the validity of the established context and MAY choose not to consider references to the context after a certain amount of time (cf below). If the client receives a 200 response with an non-empty auth-data the client MUST call gss_initiate_sec_context with this token as input to complete the authentication. If the final code 200 response contains a context-identifier option the client may cache it and use it to provide fast reauthentication by including it in a Authorization header with "GSS" mechanism and empty auth-data element. 3.3.3. Fast Renegotiation Upon receipt of a request containing an Authorization header with the "GSS" mechanism, an empty auth-data and the context-identifier option, the server MUST verify that the identifier references a valid security context. If the security context is missing or invalid the server MUST return a 401 response prompting the client to re- negotiate the security context. If the identifier references a valid security context the server MUST process the request as if the client had just completed the full authentication handshake. When this process is completed the client is authenticated to the server and possibly (depending on the way the GSS-API layer was Johansson Expires April 16, 2007 [Page 7] Internet-Draft http-gss October 2006 called and which GSS-mechanism was used) the server is authenticated to the client. Johansson Expires April 16, 2007 [Page 8] Internet-Draft http-gss October 2006 4. Examples TODO Johansson Expires April 16, 2007 [Page 9] Internet-Draft http-gss October 2006 5. Implementation Notes The context-identifier could be produced by exporting the security context through gss_export_sec_context which requires that the GSS- API implementation supports exporting unfinished contexts. Johansson Expires April 16, 2007 [Page 10] Internet-Draft http-gss October 2006 6. Security Considerations Should channel-bindings be absent, the protocol is subject to a MITM attack unless the authentication is between a client and a server with no proxies in between and each request is sent over the same HTTP/1.1 connection. Johansson Expires April 16, 2007 [Page 11] Internet-Draft http-gss October 2006 7. Notes & TODO Write a specification of how the client and server uses draft-johansson-http-tls-cb. Consider having the client elliminate content from the request during the handshake (to save bits on the wire) and then re-issue the real request with the fast-reauth token. Consider writing the protocol flow section so that it is possible to understand it. Johansson Expires April 16, 2007 [Page 12] Internet-Draft http-gss October 2006 8. IANA Considerations Registration of the GSS HTTP authentication mechanism? Johansson Expires April 16, 2007 [Page 13] Internet-Draft http-gss October 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. 9.2. Informative References [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows", RFC 4559, June 2006. Johansson Expires April 16, 2007 [Page 14] Internet-Draft http-gss October 2006 Author's Address Leif Johansson Stockholm university Email: leifj@it.su.se URI: http://www.su.se/ Johansson Expires April 16, 2007 [Page 15] Internet-Draft http-gss October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Johansson Expires April 16, 2007 [Page 16]