1
2
3Kerberos working group                                         J.Brezak 
4Internet Draft                                                Microsoft 
5Document: draft-brezak-spnego-http-01.txt                                      
6Category: Informational                                                 
7                                                         September 2001 
8 
9 
10           HTTP Authentication: SPNEGO Access Authentication 
11 
12 
13Status of this Memo 
14 
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." 
24     
25   The list of current Internet-Drafts can be accessed at 
26   http://www.ietf.org/ietf/1id-abstracts.txt  
27    
28   The list of Internet-Draft Shadow Directories can be accessed at 
29   http://www.ietf.org/shadow.html. 
30    
311. Abstract 
32    
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. 
39    
40    
412. Conventions used in this document 
42    
43   In examples, "C:" and "S:" indicate lines sent by the client and 
44   server respectively. 
45    
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]. 
49    
50    
513. Access Authentication 
52    
533.1 Reliance on the HTTP/1.1 Specification 
54 
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 
57  
58Brezak                 Category - Informational                      1 
59
60
61
62
63
64
65
66
67                     SPNEGO Access Authentication       September 2001 
68
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. 
72    
73    
744. HTTP Negotiate Authentication Scheme 
75    
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. 
82    
834.1 The WWW-Authenticate Response Header 
84    
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 
89   operate as follows: 
90    
91    
92        challenge       = "Negotiate" auth-data 
93        auth-data       = 1#( [gssapi-data] ) 
94         
95   The meanings of the values of the directives used above are as 
96   follows: 
97    
98   gssapi-data 
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]. 
102  
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. 
110    
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. 
116    
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 
119   "http/<hostname>". 
120    
1214.2 The Authorization Request Header 
122 
123  
124Brezak                 Category - Informational                      2 
125
126
127
128
129
130
131
132
133                     SPNEGO Access Authentication       September 2001 
134
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: 
138    
139        credentials             = "Negotiate" auth-data2 
140        auth-data2              = 1#( gssapi-data ) 
141                                 
142   gssapi-data 
143        This directive contains is the base64 encoding of an 
144        InitialContextToken as defined in [6]. 
145    
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. 
151    
1525. Negotiate Operation Example 
153    
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 
156   Realm A.COM  
157    
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". 
161    
162   The first time the client requests the document, no Authorization 
163   header is sent, so the server responds with: 
164    
165        HTTP/1.1 401 Unauthorized 
166        WWW-Authenticate: Negotiate 
167         
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 
171   header: 
172    
173        Authorization: Negotiate 
174        2a87421000492ade0234568ac0289eca874209af8bc028 
175         
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 
184   header: 
185    
186        HTTP/1.1 200 Success 
187        WWW-Authenticate: Negotiate ade0234568ac874209af8bc0280289eca 
188         
189  
190Brezak                 Category - Informational