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