doc/standardisation/draft-brezak-spnego-http-01.txt

   1
   2
   3 Kerberos working group                                         J.Brezak
   4 Internet Draft                                                Microsoft
   5 Document: draft-brezak-spnego-http-01.txt
   6 Category: Informational
   7                                                          September 2001
   8
   9
  10            HTTP Authentication: SPNEGO Access Authentication
  11
  12
  13 Status 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
  31 1. 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
  41 2. 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
  51 3. Access Authentication
  52
  53 3.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
  58 Brezak                 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
  74 4. 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
  83 4.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
 121 4.2 The Authorization Request Header
 122
 123
 124 Brezak                 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
 152 5. 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
 190 Brezak                 Category - Informational