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@<hostname>"
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]