source: draft-ietf-httpbis/20/draft-ietf-httpbis-p7-auth-20.xml @ 1807

Last change on this file since 1807 was 1807, checked in by julian.reschke@…, 8 years ago

Prepare release of -20 drafts

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 48.5 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!--
3    This XML document is the output of clean-for-DTD.xslt; a tool that strips
4    extensions to RFC2629(bis) from documents for processing with xml2rfc.
5-->
6<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
7<?rfc toc="yes" ?>
8<?rfc symrefs="yes" ?>
9<?rfc sortrefs="yes" ?>
10<?rfc compact="yes"?>
11<?rfc subcompact="no" ?>
12<?rfc linkmailto="no" ?>
13<?rfc editing="no" ?>
14<?rfc comments="yes"?>
15<?rfc inline="yes"?>
16<?rfc rfcedstyle="yes"?>
17<!DOCTYPE rfc
18  PUBLIC "" "rfc2629.dtd">
19<rfc obsoletes="2616" updates="2617" category="std" ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p7-auth-20">
20
21
22<front>
23
24  <title abbrev="HTTP/1.1, Part 7">HTTP/1.1, part 7: Authentication</title>
25
26  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
27    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
28    <address>
29      <postal>
30        <street>345 Park Ave</street>
31        <city>San Jose</city>
32        <region>CA</region>
33        <code>95110</code>
34        <country>USA</country>
35      </postal>
36      <email>fielding@gbiv.com</email>
37      <uri>http://roy.gbiv.com/</uri>
38    </address>
39  </author>
40
41  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
42    <organization abbrev="W3C">World Wide Web Consortium</organization>
43    <address>
44      <postal>
45        <street>W3C / ERCIM</street>
46        <street>2004, rte des Lucioles</street>
47        <city>Sophia-Antipolis</city>
48        <region>AM</region>
49        <code>06902</code>
50        <country>France</country>
51      </postal>
52      <email>ylafon@w3.org</email>
53      <uri>http://www.raubacapeu.net/people/yves/</uri>
54    </address>
55  </author>
56
57  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
58    <organization abbrev="greenbytes">greenbytes GmbH</organization>
59    <address>
60      <postal>
61        <street>Hafenweg 16</street>
62        <city>Muenster</city><region>NW</region><code>48155</code>
63        <country>Germany</country>
64      </postal>
65      <email>julian.reschke@greenbytes.de</email>
66      <uri>http://greenbytes.de/tech/webdav/</uri>
67    </address>
68  </author>
69
70  <date month="July" year="2012" day="16"/>
71  <workgroup>HTTPbis Working Group</workgroup>
72
73<abstract>
74<t>
75   The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
76   distributed, collaborative, hypermedia information systems. HTTP has been in
77   use by the World Wide Web global information initiative since 1990. This
78   document is Part 7 of the seven-part specification that defines the protocol
79   referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616.
80</t>
81<t>
82   Part 7 defines the HTTP Authentication framework.
83</t>
84</abstract>
85
86<note title="Editorial Note (To be removed by RFC Editor)">
87  <t>
88    Discussion of this draft takes place on the HTTPBIS working group
89    mailing list (ietf-http-wg@w3.org), which is archived at
90    <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
91  </t>
92  <t>
93    The current issues list is at
94    <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
95    documents (including fancy diffs) can be found at
96    <eref target="http://tools.ietf.org/wg/httpbis/"/>.
97  </t>
98  <t>
99    The changes in this draft are summarized in <xref target="changes.since.19"/>.
100  </t>
101</note>
102</front>
103<middle>
104<section title="Introduction" anchor="introduction">
105<t>
106   This document defines HTTP/1.1 access control and authentication. It
107   includes the relevant parts of RFC 2616
108   with only minor changes (<xref target="RFC2616"/>), plus the general framework for HTTP authentication,
109   as previously defined in "HTTP Authentication: Basic and Digest Access
110   Authentication" (<xref target="RFC2617"/>).
111</t>
112<t>
113   HTTP provides several OPTIONAL challenge-response authentication
114   mechanisms which can be used by a server to challenge a client request and
115   by a client to provide authentication information. The "basic" and "digest"
116   authentication schemes continue to be specified in
117   RFC 2617.
118</t>
119
120<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
121<t>
122   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
123   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
124   document are to be interpreted as described in <xref target="RFC2119"/>.
125</t>
126<t>
127   This specification targets conformance criteria according to the role of
128   a participant in HTTP communication.  Hence, HTTP requirements are placed
129   on senders, recipients, clients, servers, user agents, intermediaries,
130   origin servers, proxies, gateways, or caches, depending on what behavior
131   is being constrained by the requirement. See Section 2 of <xref target="Part1"/> for definitions
132   of these terms.
133</t>
134<t>
135   The verb "generate" is used instead of "send" where a requirement
136   differentiates between creating a protocol element and merely forwarding a
137   received element downstream.
138</t>
139<t>
140   An implementation is considered conformant if it complies with all of the
141   requirements associated with the roles it partakes in HTTP. Note that
142   SHOULD-level requirements are relevant here, unless one of the documented
143   exceptions is applicable.
144</t>
145<t>
146   This document also uses ABNF to define valid protocol elements
147   (<xref target="notation"/>).
148   In addition to the prose requirements placed upon them, senders MUST NOT
149   generate protocol elements that do not match the grammar defined by the
150   ABNF rules for those protocol elements that are applicable to the sender's
151   role. If a received protocol element is processed, the recipient MUST be
152   able to parse any value that would match the ABNF rules for that protocol
153   element, excluding only those rules not applicable to the recipient's role.
154</t>
155<t>
156   Unless noted otherwise, a recipient MAY attempt to recover a usable
157   protocol element from an invalid construct.  HTTP does not define
158   specific error handling mechanisms except when they have a direct impact
159   on security, since different applications of the protocol require
160   different error handling strategies.  For example, a Web browser might
161   wish to transparently recover from a response where the
162   Location header field doesn't parse according to the ABNF,
163   whereas a systems control client might consider any form of error recovery
164   to be dangerous.
165</t>
166</section>
167
168<section title="Syntax Notation" anchor="notation">
169<t>
170   This specification uses the Augmented Backus-Naur Form (ABNF) notation
171   of <xref target="RFC5234"/> with the list rule extension defined in
172   Section 1.2 of <xref target="Part1"/>. <xref target="imported.abnf"/> describes rules imported from
173   other documents. <xref target="collected.abnf"/> shows the collected ABNF
174   with the list rule expanded.
175</t>
176</section>
177</section>
178
179<section title="Access Authentication Framework" anchor="access.authentication.framework">
180
181<section title="Challenge and Response" anchor="challenge.and.response">
182 
183 
184 
185 
186 
187<t>
188   HTTP provides a simple challenge-response authentication mechanism
189   that can be used by a server to challenge a client request and by a
190   client to provide authentication information. It uses an extensible,
191   case-insensitive token to identify the authentication scheme, followed
192   by additional information necessary for achieving authentication via that
193   scheme. The latter can either be a comma-separated list of parameters or a
194   single sequence of characters capable of holding base64-encoded
195   information.
196</t>
197<t>
198   Parameters are name-value pairs where the name is matched case-insensitively,
199   and each parameter name MUST only occur once per challenge.
200</t>
201<figure><iref item="auth-scheme" primary="true"/><iref item="auth-param" primary="true"/><iref primary="true" item="Grammar" subitem="auth-scheme"/><iref primary="true" item="Grammar" subitem="auth-param"/><iref item="b64token" primary="true"/><iref primary="true" item="Grammar" subitem="b64token"/><artwork type="abnf2616"><![CDATA[
202  auth-scheme    = token
203 
204  auth-param     = token BWS "=" BWS ( token / quoted-string )
205
206  b64token       = 1*( ALPHA / DIGIT /
207                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
208]]></artwork></figure>
209<t>
210   The "b64token" syntax allows the 66 unreserved URI characters (<xref target="RFC3986"/>),
211   plus a few others, so that it can hold a base64, base64url (URL and filename
212   safe alphabet), base32, or base16 (hex) encoding, with or without padding, but
213   excluding whitespace (<xref target="RFC4648"/>).
214</t>
215<t>
216   The <xref target="status.401" format="none">401 (Unauthorized)</xref> response message is used by an origin server
217   to challenge the authorization of a user agent. This response MUST
218   include a <xref target="header.www-authenticate" format="none">WWW-Authenticate</xref> header field containing at least one
219   challenge applicable to the requested resource.
220</t>
221<t>  
222   The <xref target="status.407" format="none">407 (Proxy Authentication Required)</xref> response message is
223   used by a proxy to challenge the authorization of a client and MUST
224   include a <xref target="header.proxy-authenticate" format="none">Proxy-Authenticate</xref> header field containing at least
225   one challenge applicable to the proxy for the requested resource.
226</t>
227<figure><iref item="challenge" primary="true"/><iref primary="true" item="Grammar" subitem="challenge"/><artwork type="abnf2616"><![CDATA[
228  challenge   = auth-scheme [ 1*SP ( b64token / #auth-param ) ]
229]]></artwork></figure>
230<t><list>
231  <t>
232     Note: User agents will need to take special care in parsing the
233     <xref target="header.www-authenticate" format="none">WWW-Authenticate</xref> and <xref target="header.proxy-authenticate" format="none">Proxy-Authenticate</xref>
234     header field values because they can contain more than one challenge, or
235     if more than one of each is provided, since the contents of a challenge
236     can itself contain a comma-separated list of authentication parameters.
237  </t>
238</list></t>
239<t><list>
240  <t>
241     Note: Many clients fail to parse challenges containing unknown
242     schemes. A workaround for this problem is to list well-supported schemes
243     (such as "basic") first.<!-- see http://greenbytes.de/tech/tc/httpauth/#multibasicunknown2 -->
244  </t>
245</list></t>
246<t>
247   A user agent that wishes to authenticate itself with an origin server
248   — usually, but not necessarily, after receiving a <xref target="status.401" format="none">401 (Unauthorized)</xref>
249   — can do so by including an <xref target="header.authorization" format="none">Authorization</xref> header field with the
250   request.
251</t>
252<t>  
253   A client that wishes to authenticate itself with a proxy — usually,
254   but not necessarily, after receiving a <xref target="status.407" format="none">407 (Proxy Authentication Required)</xref>
255   — can do so by including a <xref target="header.proxy-authorization" format="none">Proxy-Authorization</xref> header field with the
256   request.
257</t>
258<t>
259   Both the <xref target="header.authorization" format="none">Authorization</xref> field value and the <xref target="header.proxy-authorization" format="none">Proxy-Authorization</xref> field value
260   contain the client's credentials for the realm of the resource being
261   requested, based upon a challenge received from the server (possibly at
262   some point in the past). When creating their values, the user agent ought to
263   do so by selecting the challenge with what it considers to be the most
264   secure auth-scheme that it understands, obtaining credentials from the user
265   as appropriate.
266</t>
267<figure><iref item="credentials" primary="true"/><iref primary="true" item="Grammar" subitem="credentials"/><artwork type="abnf2616"><![CDATA[
268  credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ]
269]]></artwork></figure>
270<t>
271   Upon a request for a protected resource that omits credentials, contains
272   invalid credentials (e.g., a bad password) or partial credentials (e.g.,
273   when the authentication scheme requires more than one round trip), an origin
274   server SHOULD return a <xref target="status.401" format="none">401 (Unauthorized)</xref> response. Such
275   responses MUST include a <xref target="header.www-authenticate" format="none">WWW-Authenticate</xref> header field
276   containing at least one (possibly new) challenge applicable to the
277   requested resource.
278</t>
279<t>
280   Likewise, upon a request that requires authentication by proxies that omit
281   credentials or contain invalid or partial credentials, a proxy SHOULD
282   return a <xref target="status.407" format="none">407 (Proxy Authentication Required)</xref> response. Such responses
283   MUST include a <xref target="header.proxy-authenticate" format="none">Proxy-Authenticate</xref> header field containing a (possibly
284   new) challenge applicable to the proxy.
285</t>
286<t>
287   A server receiving credentials that are valid, but not adequate to gain
288   access, ought to respond with the 403 (Forbidden) status code (Section 4.6.3 of <xref target="Part2"/>).
289</t>
290<t>
291   The HTTP protocol does not restrict applications to this simple
292   challenge-response mechanism for access authentication. Additional
293   mechanisms MAY be used, such as encryption at the transport level or
294   via message encapsulation, and with additional header fields
295   specifying authentication information. However, such additional
296   mechanisms are not defined by this specification.
297</t>
298<t>
299   Proxies MUST forward the <xref target="header.www-authenticate" format="none">WWW-Authenticate</xref> and
300   <xref target="header.authorization" format="none">Authorization</xref> header fields unmodified and follow the rules
301   found in <xref target="header.authorization"/>.
302</t>
303</section>
304
305<section title="Protection Space (Realm)" anchor="protection.space">
306  <iref item="Protection Space"/>
307  <iref item="Realm"/>
308  <iref item="Canonical Root URI"/>
309<t>
310   The authentication parameter realm is reserved for use by authentication
311   schemes that wish to indicate the scope of protection.
312</t>
313<t>
314   A protection space is defined by the canonical root URI (the
315   scheme and authority components of the effective request URI; see
316   Section 5.5 of <xref target="Part1"/>) of the
317   server being accessed, in combination with the realm value if present.
318   These realms allow the protected resources on a server to be
319   partitioned into a set of protection spaces, each with its own
320   authentication scheme and/or authorization database. The realm value
321   is a string, generally assigned by the origin server, which can have
322   additional semantics specific to the authentication scheme. Note that
323   there can be multiple challenges with the same auth-scheme but
324   different realms.
325</t>
326<t>
327   The protection space determines the domain over which credentials can
328   be automatically applied. If a prior request has been authorized, the
329   same credentials MAY be reused for all other requests within that
330   protection space for a period of time determined by the
331   authentication scheme, parameters, and/or user preference. Unless
332   otherwise defined by the authentication scheme, a single protection
333   space cannot extend outside the scope of its server.
334</t>
335<t>
336   For historical reasons, senders MUST only use the quoted-string syntax.
337   Recipients might have to support both token and quoted-string syntax for
338   maximum interoperability with existing clients that have been accepting both
339   notations for a long time.
340</t>
341</section>
342
343<section title="Authentication Scheme Registry" anchor="authentication.scheme.registry">
344<t>
345  The HTTP Authentication Scheme Registry defines the name space for the
346  authentication schemes in challenges and credentials.
347</t>
348<t>
349  Registrations MUST include the following fields:
350  <list style="symbols">
351    <t>Authentication Scheme Name</t>
352    <t>Pointer to specification text</t>
353    <t>Notes (optional)</t>
354  </list>
355</t>
356<t>
357  Values to be added to this name space require IETF Review
358  (see <xref target="RFC5226"/>, Section 4.1).
359</t>
360<t>
361  The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-authschemes"/>.
362</t>
363
364<section title="Considerations for New Authentication Schemes" anchor="considerations.for.new.authentication.schemes">
365<t>
366  There are certain aspects of the HTTP Authentication Framework that put
367  constraints on how new authentication schemes can work:
368</t>
369<t>
370  <list style="symbols">
371    <t>
372      HTTP authentication is presumed to be stateless: all of the information
373      necessary to authenticate a request MUST be provided in the request,
374      rather than be dependent on the server remembering prior requests.
375      Authentication based on, or bound to, the underlying connection is
376      outside the scope of this specification and inherently flawed unless
377      steps are taken to ensure that the connection cannot be used by any
378      party other than the authenticated user
379      (see Section 2.4 of <xref target="Part1"/>).
380    </t>
381    <t>
382      The authentication parameter "realm" is reserved for defining Protection
383      Spaces as defined in <xref target="protection.space"/>. New schemes
384      MUST NOT use it in a way incompatible with that definition.
385    </t>
386    <t>
387      The "b64token" notation was introduced for compatibility with existing
388      authentication schemes and can only be used once per challenge/credentials.
389      New schemes thus ought to use the "auth-param" syntax instead, because
390      otherwise future extensions will be impossible.
391    </t>
392    <t>
393      The parsing of challenges and credentials is defined by this specification,
394      and cannot be modified by new authentication schemes. When the auth-param
395      syntax is used, all parameters ought to support both token and
396      quoted-string syntax, and syntactical constraints ought to be defined on
397      the field value after parsing (i.e., quoted-string processing). This is
398      necessary so that recipients can use a generic parser that applies to
399      all authentication schemes.
400    <vspace blankLines="1"/>
401      Note: The fact that the value syntax for the "realm" parameter
402      is restricted to quoted-string was a bad design choice not to be repeated
403      for new parameters.
404    </t>
405    <t>
406      Definitions of new schemes ought to define the treatment of unknown
407      extension parameters. In general, a "must-ignore" rule is preferable
408      over "must-understand", because otherwise it will be hard to introduce
409      new parameters in the presence of legacy recipients. Furthermore,
410      it's good to describe the policy for defining new parameters (such
411      as "update the specification", or "use this registry").
412    </t>
413    <t>
414      Authentication schemes need to document whether they are usable in
415      origin-server authentication (i.e., using <xref target="header.www-authenticate" format="none">WWW-Authenticate</xref>),
416      and/or proxy authentication (i.e., using <xref target="header.proxy-authenticate" format="none">Proxy-Authenticate</xref>).
417    </t>
418    <t>
419      The credentials carried in an <xref target="header.authorization" format="none">Authorization</xref> header field are specific to
420      the User Agent, and therefore have the same effect on HTTP caches as the
421      "private" Cache-Control response directive, within the scope of the
422      request they appear in.
423    <vspace blankLines="1"/>
424      Therefore, new authentication schemes which choose not to carry
425      credentials in the <xref target="header.authorization" format="none">Authorization</xref> header field (e.g., using a newly defined
426      header field) will need to explicitly disallow caching, by mandating the use of
427      either Cache-Control request directives (e.g., "no-store") or response
428      directives (e.g., "private").
429    </t>
430  </list>
431</t>
432</section>
433
434</section>
435
436</section>
437
438<section title="Status Code Definitions" anchor="status.code.definitions">
439<section title="401 Unauthorized" anchor="status.401">
440  <iref primary="true" item="401 Unauthorized (status code)"/>
441  <iref primary="true" item="Status Codes" subitem="401 Unauthorized"/>
442 
443<t>
444   The request requires user authentication. The response MUST include a
445   <xref target="header.www-authenticate" format="none">WWW-Authenticate</xref> header field (<xref target="header.www-authenticate"/>)
446   containing a challenge applicable to the target resource. The client MAY
447   repeat the request with a suitable <xref target="header.authorization" format="none">Authorization</xref> header field
448   (<xref target="header.authorization"/>). If the request already included
449   Authorization credentials, then the 401 response indicates that authorization
450   has been refused for those credentials. If the 401 response contains the
451   same challenge as the prior response, and the user agent has already attempted
452   authentication at least once, then the user SHOULD be presented the
453   representation that was given in the response, since that representation might
454   include relevant diagnostic information.
455</t>
456</section>
457<section title="407 Proxy Authentication Required" anchor="status.407">
458  <iref primary="true" item="407 Proxy Authentication Required (status code)"/>
459  <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required"/>
460 
461<t>
462   This code is similar to <xref target="status.401" format="none">401 (Unauthorized)</xref>, but indicates that the
463   client ought to first authenticate itself with the proxy. The proxy MUST
464   return a <xref target="header.proxy-authenticate" format="none">Proxy-Authenticate</xref> header field (<xref target="header.proxy-authenticate"/>) containing a
465   challenge applicable to the proxy for the target resource. The
466   client MAY repeat the request with a suitable <xref target="header.proxy-authorization" format="none">Proxy-Authorization</xref>
467   header field (<xref target="header.proxy-authorization"/>).
468</t>
469</section>
470</section>
471
472<section title="Header Field Definitions" anchor="header.field.definitions">
473<t>
474   This section defines the syntax and semantics of HTTP/1.1 header fields
475   related to authentication.
476</t>
477
478<section title="Authorization" anchor="header.authorization">
479  <iref primary="true" item="Authorization header field"/>
480  <iref primary="true" item="Header Fields" subitem="Authorization"/>
481 
482<t>
483   The "Authorization" header field allows a user agent to authenticate
484   itself with a server — usually, but not necessarily, after receiving a <xref target="status.401" format="none">401
485   (Unauthorized)</xref> response. Its value consists of credentials containing
486   information of the user agent for the realm of the resource being
487   requested.
488</t>
489<figure><iref primary="true" item="Grammar" subitem="Authorization"/><artwork type="abnf2616"><![CDATA[
490  Authorization = credentials
491]]></artwork></figure>
492<t>
493   If a request is
494   authenticated and a realm specified, the same credentials SHOULD
495   be valid for all other requests within this realm (assuming that
496   the authentication scheme itself does not require otherwise, such
497   as credentials that vary according to a challenge value or using
498   synchronized clocks).
499</t>
500<t>
501      When a shared cache (see Section 1.2 of <xref target="Part6"/>) receives a request
502      containing an Authorization field, it MUST NOT return the
503      corresponding response as a reply to any other request, unless one
504      of the following specific exceptions holds:
505</t>
506<t>
507  <list style="numbers">
508      <t>If the response includes the "s-maxage" cache-control
509         directive, the cache MAY use that response in replying to a
510         subsequent request. But (if the specified maximum age has
511         passed) a proxy cache MUST first revalidate it with the origin
512         server, using the header fields from the new request to allow
513         the origin server to authenticate the new request. (This is the
514         defined behavior for s-maxage.) If the response includes "s-maxage=0",
515         the proxy MUST always revalidate it before re-using
516         it.</t>
517
518      <t>If the response includes the "must-revalidate" cache-control
519         directive, the cache MAY use that response in replying to a
520         subsequent request. But if the response is stale, all caches
521         MUST first revalidate it with the origin server, using the
522         header fields from the new request to allow the origin server
523         to authenticate the new request.</t>
524
525      <t>If the response includes the "public" cache-control directive,
526         it MAY be returned in reply to any subsequent request.</t>
527  </list>
528</t>
529</section>
530
531<section title="Proxy-Authenticate" anchor="header.proxy-authenticate">
532  <iref primary="true" item="Proxy-Authenticate header field"/>
533  <iref primary="true" item="Header Fields" subitem="Proxy-Authenticate"/>
534 
535<t>
536   The "Proxy-Authenticate" header field consists of at least one
537   challenge that indicates the authentication scheme(s) and parameters
538   applicable to the proxy for this effective request URI (Section 5.5 of <xref target="Part1"/>).
539   It MUST be included as part of a <xref target="status.407" format="none">407 (Proxy Authentication Required)</xref> response.
540</t>
541<figure><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/><artwork type="abnf2616"><![CDATA[
542  Proxy-Authenticate = 1#challenge
543]]></artwork></figure>
544<t>
545   Unlike <xref target="header.www-authenticate" format="none">WWW-Authenticate</xref>, the Proxy-Authenticate header field
546   applies only to the current connection, and intermediaries SHOULD NOT
547   forward it to downstream clients. However, an intermediate proxy might need
548   to obtain its own credentials by requesting them from the downstream client,
549   which in some circumstances will appear as if the proxy is forwarding the
550   Proxy-Authenticate header field.
551</t>
552<t>
553   Note that the parsing considerations for <xref target="header.www-authenticate" format="none">WWW-Authenticate</xref>
554   apply to this header field as well; see <xref target="header.www-authenticate"/>
555   for details.
556</t>
557</section>
558
559<section title="Proxy-Authorization" anchor="header.proxy-authorization">
560  <iref primary="true" item="Proxy-Authorization header field"/>
561  <iref primary="true" item="Header Fields" subitem="Proxy-Authorization"/>
562 
563<t>
564   The "Proxy-Authorization" header field allows the client to
565   identify itself (or its user) to a proxy which requires
566   authentication. Its value consists of
567   credentials containing the authentication information of the user
568   agent for the proxy and/or realm of the resource being requested.
569</t>
570<figure><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/><artwork type="abnf2616"><![CDATA[
571  Proxy-Authorization = credentials
572]]></artwork></figure>
573<t>
574   Unlike <xref target="header.authorization" format="none">Authorization</xref>, the Proxy-Authorization header field applies only to
575   the next outbound proxy that demanded authentication using the <xref target="header.proxy-authenticate" format="none">Proxy-Authenticate</xref>
576   field. When multiple proxies are used in a chain, the
577   Proxy-Authorization header field is consumed by the first outbound
578   proxy that was expecting to receive credentials. A proxy MAY relay
579   the credentials from the client request to the next proxy if that is
580   the mechanism by which the proxies cooperatively authenticate a given
581   request.
582</t>
583</section>
584
585<section title="WWW-Authenticate" anchor="header.www-authenticate">
586  <iref primary="true" item="WWW-Authenticate header field"/>
587  <iref primary="true" item="Header Fields" subitem="WWW-Authenticate"/>
588 
589<t>
590   The "WWW-Authenticate" header field consists of at least one
591   challenge that indicates the authentication scheme(s) and parameters
592   applicable to the effective request URI (Section 5.5 of <xref target="Part1"/>).
593</t>
594<t>  
595   It MUST be included in <xref target="status.401" format="none">401 (Unauthorized)</xref> response messages and MAY be
596   included in other response messages to indicate that supplying credentials
597   (or different credentials) might affect the response.
598</t>
599<figure><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/><artwork type="abnf2616"><![CDATA[
600  WWW-Authenticate = 1#challenge
601]]></artwork></figure>
602<t>
603   User agents are advised to take special care in parsing the WWW-Authenticate
604   field value as it might contain more than one challenge,
605   or if more than one WWW-Authenticate header field is provided, the
606   contents of a challenge itself can contain a comma-separated list of
607   authentication parameters.
608</t>
609<figure>
610  <preamble>For instance:</preamble>
611  <artwork type="example"><![CDATA[
612  WWW-Authenticate: Newauth realm="apps", type=1,
613                    title="Login to \"apps\"", Basic realm="simple"
614]]></artwork>
615  <postamble>
616  This header field contains two challenges; one for the "Newauth" scheme
617  with a realm value of "apps", and two additional parameters "type" and
618  "title", and another one for the "Basic" scheme with a realm value of
619  "simple".
620</postamble></figure>
621<t><list>
622  <t>
623    Note: The challenge grammar production uses the list syntax as
624    well. Therefore, a sequence of comma, whitespace, and comma can be
625    considered both as applying to the preceding challenge, or to be an
626    empty entry in the list of challenges. In practice, this ambiguity
627    does not affect the semantics of the header field value and thus is
628    harmless.
629  </t>
630</list></t>
631</section>
632
633</section>
634
635<section title="IANA Considerations" anchor="IANA.considerations">
636
637<section title="Authentication Scheme Registry" anchor="authentication.scheme.registration">
638<t>
639  The registration procedure for HTTP Authentication Schemes is defined by
640  <xref target="authentication.scheme.registry"/> of this document.
641</t>
642<t>
643   The HTTP Method Authentication Scheme shall be created at <eref target="http://www.iana.org/assignments/http-authschemes"/>.
644</t>
645</section>
646
647<section title="Status Code Registration" anchor="status.code.registration">
648<t>
649   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/>
650   shall be updated with the registrations below:
651</t>
652
653<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually-->
654<texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table">
655   <ttcol>Value</ttcol>
656   <ttcol>Description</ttcol>
657   <ttcol>Reference</ttcol>
658   <c>401</c>
659   <c>Unauthorized</c>
660   <c>
661      <xref target="status.401"/>
662   </c>
663   <c>407</c>
664   <c>Proxy Authentication Required</c>
665   <c>
666      <xref target="status.407"/>
667   </c>
668</texttable>
669<!--(END)-->
670
671</section>
672
673<section title="Header Field Registration" anchor="header.field.registration">
674<t>
675   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
676   with the permanent registrations below (see <xref target="RFC3864"/>):
677</t>
678
679<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
680<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
681   <ttcol>Header Field Name</ttcol>
682   <ttcol>Protocol</ttcol>
683   <ttcol>Status</ttcol>
684   <ttcol>Reference</ttcol>
685
686   <c>Authorization</c>
687   <c>http</c>
688   <c>standard</c>
689   <c>
690      <xref target="header.authorization"/>
691   </c>
692   <c>Proxy-Authenticate</c>
693   <c>http</c>
694   <c>standard</c>
695   <c>
696      <xref target="header.proxy-authenticate"/>
697   </c>
698   <c>Proxy-Authorization</c>
699   <c>http</c>
700   <c>standard</c>
701   <c>
702      <xref target="header.proxy-authorization"/>
703   </c>
704   <c>WWW-Authenticate</c>
705   <c>http</c>
706   <c>standard</c>
707   <c>
708      <xref target="header.www-authenticate"/>
709   </c>
710</texttable>
711<!--(END)-->
712
713<t>
714   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
715</t>
716</section>
717</section>
718
719<section title="Security Considerations" anchor="security.considerations">
720<t>
721   This section is meant to inform application developers, information
722   providers, and users of the security limitations in HTTP/1.1 as
723   described by this document. The discussion does not include
724   definitive solutions to the problems revealed, though it does make
725   some suggestions for reducing security risks.
726</t>
727
728<section title="Authentication Credentials and Idle Clients" anchor="auth.credentials.and.idle.clients">
729<t>
730   Existing HTTP clients and user agents typically retain authentication
731   information indefinitely. HTTP/1.1 does not provide a method for a
732   server to direct clients to discard these cached credentials. This is
733   a significant defect that requires further extensions to HTTP.
734   Circumstances under which credential caching can interfere with the
735   application's security model include but are not limited to:
736  <list style="symbols">
737     <t>Clients which have been idle for an extended period following
738        which the server might wish to cause the client to reprompt the
739        user for credentials.</t>
740
741     <t>Applications which include a session termination indication
742        (such as a "logout" or "commit" button on a page) after which
743        the server side of the application "knows" that there is no
744        further reason for the client to retain the credentials.</t>
745  </list>
746</t>
747<t>
748   This is currently under separate study. There are a number of work-arounds
749   to parts of this problem, and we encourage the use of
750   password protection in screen savers, idle time-outs, and other
751   methods which mitigate the security problems inherent in this
752   problem. In particular, user agents which cache credentials are
753   encouraged to provide a readily accessible mechanism for discarding
754   cached credentials under user control.
755</t>
756</section>
757
758<section title="Protection Spaces" anchor="protection.spaces">
759<t>
760  Authentication schemes that solely rely on the "realm" mechanism for
761  establishing a protection space will expose credentials to all resources on a
762  server. Clients that have successfully made authenticated requests with a
763  resource can use the same authentication credentials for other resources on
764  the same server. This makes it possible for a different resource to harvest
765  authentication credentials for other resources.
766</t>
767<t>
768  This is of particular concern when a server hosts resources for multiple
769  parties under the same canonical root URI (<xref target="protection.space"/>).
770  Possible mitigation strategies include restricting direct access to
771  authentication credentials (i.e., not making the content of the
772  <xref target="header.authorization" format="none">Authorization</xref> request header field available), and separating protection
773  spaces by using a different host name for each party.
774</t>
775</section>
776</section>
777
778<section title="Acknowledgments" anchor="acks">
779<t>
780  This specification takes over the definition of the HTTP Authentication
781  Framework, previously defined in RFC 2617.
782  We thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence,
783  Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work
784  on that specification. See Section 6 of <xref target="RFC2617"/>
785  for further acknowledgements. 
786</t>
787<t>
788  See Section 9 of <xref target="Part1"/> for the Acknowledgments related to this document revision.
789</t>
790</section>
791</middle>
792
793<back>
794
795<references title="Normative References">
796
797<reference anchor="Part1">
798  <front>
799    <title>HTTP/1.1, part 1: Message Routing and Syntax"</title>
800    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
801      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
802      <address><email>fielding@gbiv.com</email></address>
803    </author>
804    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
805      <organization abbrev="W3C">World Wide Web Consortium</organization>
806      <address><email>ylafon@w3.org</email></address>
807    </author>
808    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
809      <organization abbrev="greenbytes">greenbytes GmbH</organization>
810      <address><email>julian.reschke@greenbytes.de</email></address>
811    </author>
812    <date month="July" year="2012"/>
813  </front>
814  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-20"/>
815 
816</reference>
817
818<reference anchor="Part2">
819  <front>
820    <title>HTTP/1.1, part 2: Semantics and Payloads</title>
821    <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
822      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
823      <address><email>fielding@gbiv.com</email></address>
824    </author>
825    <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon">
826      <organization abbrev="W3C">World Wide Web Consortium</organization>
827      <address><email>ylafon@w3.org</email></address>
828    </author>
829    <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
830      <organization abbrev="greenbytes">greenbytes GmbH</organization>
831      <address><email>julian.reschke@greenbytes.de</email></address>
832    </author>
833    <date month="July" year="2012"/>
834  </front>
835  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-20"/>
836 
837</reference>
838
839<reference anchor="Part6">
840  <front>
841    <title>HTTP/1.1, part 6: Caching</title>
842    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
843      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
844      <address><email>fielding@gbiv.com</email></address>
845    </author>
846    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
847      <organization abbrev="W3C">World Wide Web Consortium</organization>
848      <address><email>ylafon@w3.org</email></address>
849    </author>
850    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
851      <organization>Rackspace</organization>
852      <address><email>mnot@mnot.net</email></address>
853    </author>
854    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
855      <organization abbrev="greenbytes">greenbytes GmbH</organization>
856      <address><email>julian.reschke@greenbytes.de</email></address>
857    </author>
858    <date month="July" year="2012"/>
859  </front>
860  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-20"/>
861 
862</reference>
863
864<reference anchor="RFC2119">
865  <front>
866    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
867    <author initials="S." surname="Bradner" fullname="Scott Bradner">
868      <organization>Harvard University</organization>
869      <address><email>sob@harvard.edu</email></address>
870    </author>
871    <date month="March" year="1997"/>
872  </front>
873  <seriesInfo name="BCP" value="14"/>
874  <seriesInfo name="RFC" value="2119"/>
875</reference>
876
877<reference anchor="RFC5234">
878  <front>
879    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
880    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
881      <organization>Brandenburg InternetWorking</organization>
882      <address>
883        <email>dcrocker@bbiw.net</email>
884      </address> 
885    </author>
886    <author initials="P." surname="Overell" fullname="Paul Overell">
887      <organization>THUS plc.</organization>
888      <address>
889        <email>paul.overell@thus.net</email>
890      </address>
891    </author>
892    <date month="January" year="2008"/>
893  </front>
894  <seriesInfo name="STD" value="68"/>
895  <seriesInfo name="RFC" value="5234"/>
896</reference>
897
898</references>
899
900<references title="Informative References">
901
902<reference anchor="RFC2616">
903  <front>
904    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
905    <author initials="R." surname="Fielding" fullname="R. Fielding">
906      <organization>University of California, Irvine</organization>
907      <address><email>fielding@ics.uci.edu</email></address>
908    </author>
909    <author initials="J." surname="Gettys" fullname="J. Gettys">
910      <organization>W3C</organization>
911      <address><email>jg@w3.org</email></address>
912    </author>
913    <author initials="J." surname="Mogul" fullname="J. Mogul">
914      <organization>Compaq Computer Corporation</organization>
915      <address><email>mogul@wrl.dec.com</email></address>
916    </author>
917    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
918      <organization>MIT Laboratory for Computer Science</organization>
919      <address><email>frystyk@w3.org</email></address>
920    </author>
921    <author initials="L." surname="Masinter" fullname="L. Masinter">
922      <organization>Xerox Corporation</organization>
923      <address><email>masinter@parc.xerox.com</email></address>
924    </author>
925    <author initials="P." surname="Leach" fullname="P. Leach">
926      <organization>Microsoft Corporation</organization>
927      <address><email>paulle@microsoft.com</email></address>
928    </author>
929    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
930      <organization>W3C</organization>
931      <address><email>timbl@w3.org</email></address>
932    </author>
933    <date month="June" year="1999"/>
934  </front>
935  <seriesInfo name="RFC" value="2616"/>
936</reference>
937
938<reference anchor="RFC2617">
939  <front>
940    <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
941    <author initials="J." surname="Franks" fullname="John Franks">
942      <organization>Northwestern University, Department of Mathematics</organization>
943      <address><email>john@math.nwu.edu</email></address>
944    </author>
945    <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
946      <organization>Verisign Inc.</organization>
947      <address><email>pbaker@verisign.com</email></address>
948    </author>
949    <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
950      <organization>AbiSource, Inc.</organization>
951      <address><email>jeff@AbiSource.com</email></address>
952    </author>
953    <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
954      <organization>Agranat Systems, Inc.</organization>
955      <address><email>lawrence@agranat.com</email></address>
956    </author>
957    <author initials="P.J." surname="Leach" fullname="Paul J. Leach">
958      <organization>Microsoft Corporation</organization>
959      <address><email>paulle@microsoft.com</email></address>
960    </author>
961    <author initials="A." surname="Luotonen" fullname="Ari Luotonen">
962      <organization>Netscape Communications Corporation</organization>
963    </author>
964    <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
965      <organization>Open Market, Inc.</organization>
966      <address><email>stewart@OpenMarket.com</email></address>
967    </author>
968    <date month="June" year="1999"/>
969  </front>
970  <seriesInfo name="RFC" value="2617"/>
971</reference>
972
973<reference anchor="RFC3864">
974  <front>
975    <title>Registration Procedures for Message Header Fields</title>
976    <author initials="G." surname="Klyne" fullname="G. Klyne">
977      <organization>Nine by Nine</organization>
978      <address><email>GK-IETF@ninebynine.org</email></address>
979    </author>
980    <author initials="M." surname="Nottingham" fullname="M. Nottingham">
981      <organization>BEA Systems</organization>
982      <address><email>mnot@pobox.com</email></address>
983    </author>
984    <author initials="J." surname="Mogul" fullname="J. Mogul">
985      <organization>HP Labs</organization>
986      <address><email>JeffMogul@acm.org</email></address>
987    </author>
988    <date year="2004" month="September"/>
989  </front>
990  <seriesInfo name="BCP" value="90"/>
991  <seriesInfo name="RFC" value="3864"/>
992</reference>
993
994<reference anchor="RFC3986">
995 <front>
996  <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
997  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
998    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
999    <address>
1000       <email>timbl@w3.org</email>
1001       <uri>http://www.w3.org/People/Berners-Lee/</uri>
1002    </address>
1003  </author>
1004  <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
1005    <organization abbrev="Day Software">Day Software</organization>
1006    <address>
1007      <email>fielding@gbiv.com</email>
1008      <uri>http://roy.gbiv.com/</uri>
1009    </address>
1010  </author>
1011  <author initials="L." surname="Masinter" fullname="Larry Masinter">
1012    <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
1013    <address>
1014      <email>LMM@acm.org</email>
1015      <uri>http://larry.masinter.net/</uri>
1016    </address>
1017  </author>
1018  <date month="January" year="2005"/>
1019 </front>
1020 <seriesInfo name="STD" value="66"/>
1021 <seriesInfo name="RFC" value="3986"/>
1022</reference>
1023
1024<reference anchor="RFC4648">
1025  <front>
1026    <title>The Base16, Base32, and Base64 Data Encodings</title>
1027    <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
1028    <date year="2006" month="October"/>
1029  </front>
1030  <seriesInfo value="4648" name="RFC"/>
1031</reference>
1032
1033<reference anchor="RFC5226">
1034  <front>
1035    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
1036    <author initials="T." surname="Narten" fullname="T. Narten">
1037      <organization>IBM</organization>
1038      <address><email>narten@us.ibm.com</email></address>
1039    </author>
1040    <author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
1041      <organization>Google</organization>
1042      <address><email>Harald@Alvestrand.no</email></address>
1043    </author>
1044    <date year="2008" month="May"/>
1045  </front>
1046  <seriesInfo name="BCP" value="26"/>
1047  <seriesInfo name="RFC" value="5226"/>
1048</reference>
1049
1050</references>
1051
1052<section title="Changes from RFCs 2616 and 2617" anchor="changes.from.rfc.2616">
1053<t>
1054  The "realm" parameter isn't required anymore in general; consequently, the
1055  ABNF allows challenges without any auth parameters.
1056  (<xref target="access.authentication.framework"/>)
1057</t>
1058<t>
1059  The "b64token" alternative to auth-param lists has been added for consistency
1060  with legacy authentication schemes such as "Basic".
1061  (<xref target="access.authentication.framework"/>)
1062</t>
1063<t>
1064  Introduce Authentication Scheme Registry.
1065  (<xref target="authentication.scheme.registry"/>)
1066</t>
1067<t>
1068  Change ABNF productions for header fields to only define the field value.
1069  (<xref target="header.field.definitions"/>)
1070</t>
1071</section>
1072 
1073<section title="Imported ABNF" anchor="imported.abnf">
1074 
1075 
1076 
1077 
1078 
1079 
1080 
1081 
1082 
1083 
1084 
1085<t>
1086  The following core rules are included by
1087  reference, as defined in Appendix B.1 of <xref target="RFC5234"/>:
1088  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
1089  DIGIT (decimal 0-9), DQUOTE (double quote),
1090  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
1091  OCTET (any 8-bit sequence of data), SP (space), and
1092  VCHAR (any visible US-ASCII character).
1093</t>
1094<t>
1095   The rules below are defined in <xref target="Part1"/>:
1096</t>
1097<figure><artwork type="abnf2616"><![CDATA[
1098  BWS           = <BWS, defined in [Part1], Section 3.2.1>
1099  OWS           = <OWS, defined in [Part1], Section 3.2.1>
1100  quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
1101  token         = <token, defined in [Part1], Section 3.2.4>
1102]]></artwork></figure>
1103</section>
1104
1105
1106<section title="Collected ABNF" anchor="collected.abnf">
1107<figure>
1108<artwork type="abnf" name="p7-auth.parsed-abnf"><![CDATA[
1109Authorization = credentials
1110
1111BWS = <BWS, defined in [Part1], Section 3.2.1>
1112
1113OWS = <OWS, defined in [Part1], Section 3.2.1>
1114
1115Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
1116 challenge ] )
1117Proxy-Authorization = credentials
1118
1119WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
1120 ] )
1121
1122auth-param = token BWS "=" BWS ( token / quoted-string )
1123auth-scheme = token
1124
1125b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
1126 *"="
1127
1128challenge = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) *(
1129 OWS "," [ OWS auth-param ] ) ] ) ]
1130credentials = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param )
1131 *( OWS "," [ OWS auth-param ] ) ] ) ]
1132
1133quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
1134
1135token = <token, defined in [Part1], Section 3.2.4>
1136]]></artwork>
1137</figure>
1138</section>
1139
1140
1141<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
1142<t>
1143  Changes up to the first Working Group Last Call draft are summarized
1144  in <eref target="http://trac.tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#appendix-C"/>.
1145</t>
1146
1147<section title="Since draft-ietf-httpbis-p7-auth-19" anchor="changes.since.19">
1148<t>
1149  Closed issues:
1150  <list style="symbols">
1151    <t>
1152      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/348"/>:
1153      "Realms and scope"
1154    </t>
1155    <t>
1156      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/349"/>:
1157      "Strength"
1158    </t>
1159    <t>
1160      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/357"/>:
1161      "Authentication exchanges"
1162    </t>
1163    <t>
1164      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>:
1165      "ABNF requirements for recipients"
1166    </t>
1167    <t>
1168      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/368"/>:
1169      "note introduction of new IANA registries as normative changes"
1170    </t>
1171  </list>
1172</t>
1173</section>
1174
1175</section>
1176
1177</back>
1178</rfc>
Note: See TracBrowser for help on using the repository browser.