3 Kerberos working group J.Brezak
4 Internet Draft Microsoft
5 Document: draft-brezak-spnego-http-01.txt
6 Category: Informational
10 HTTP Authentication: SPNEGO Access Authentication
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."
25 The list of current Internet-Drafts can be accessed at
26 http://www.ietf.org/ietf/1id-abstracts.txt
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
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.
41 2. Conventions used in this document
43 In examples, "C:" and "S:" indicate lines sent by the client and
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].
51 3. Access Authentication
53 3.1 Reliance on the HTTP/1.1 Specification
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
58 Brezak Category - Informational 1
67 SPNEGO Access Authentication September 2001
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.
74 4. HTTP Negotiate Authentication Scheme
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.
83 4.1 The WWW-Authenticate Response Header
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
92 challenge = "Negotiate" auth-data
93 auth-data = 1#( [gssapi-data] )
95 The meanings of the values of the directives used above are as
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].
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.
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.
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
121 4.2 The Authorization Request Header
124 Brezak Category - Informational 2
133 SPNEGO Access Authentication September 2001
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:
139 credentials = "Negotiate" auth-data2
140 auth-data2 = 1#( gssapi-data )
143 This directive contains is the base64 encoding of an
144 InitialContextToken as defined in [6].
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.
152 5. Negotiate Operation Example
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
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".
162 The first time the client requests the document, no Authorization
163 header is sent, so the server responds with:
165 HTTP/1.1 401 Unauthorized
166 WWW-Authenticate: Negotiate
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
173 Authorization: Negotiate
174 2a87421000492ade0234568ac0289eca874209af8bc028
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
187 WWW-Authenticate: Negotiate ade0234568ac874209af8bc0280289eca
190 Brezak Category - Informational