Ignore:
Timestamp:
Mar 9, 2009, 4:13:57 AM (11 years ago)
Author:
julian.reschke@…
Message:

update boilerplate and Makefile

Location:
draft-ietf-httpbis-security-properties/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis-security-properties/latest/Makefile

    r216 r549  
    1 xml2rfc = "/Users/paul/Documents/xml2rfc-dev/xml2rfc.tcl"
     1xml2rfc = "../../xml2rfc/xml2rfc.tcl"
    22saxpath = "$(HOME)/java/saxon-8-9-j/saxon8.jar"
    33saxon = java -classpath $(saxpath) net.sf.saxon.Transform -novw
  • draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.html

    r279 r549  
    6262  page-break-after: avoid;
    6363}
    64 h2 a {
    65   color: black;
    66 }
    67 h3 {
     64h3, h4, h5, h6 {
    6865  font-size: 10pt;
    6966  page-break-after: avoid;
    7067}
    71 h3 a {
    72   color: black;
    73 }
    74 h4 {
    75   font-size: 10pt;
    76   page-break-after: avoid;
    77 }
    78 h4 a {
    79   color: black;
    80 }
    81 h5 {
    82   font-size: 10pt;
    83   page-break-after: avoid;
    84 }
    85 h5 a {
     68h2 a, h3 a, h4 a, h5 a, h6 a {
    8669  color: black;
    8770}
     
    183166ul p {
    184167  margin-left: 0em;
    185 }
    186 ul.ind {
    187   list-style: none;
    188   margin-left: 1.5em;
    189   margin-right: 0em;
    190   padding-left: 0em;
    191 }
    192 li.indline0 {
    193   font-weight: bold;
    194   line-height: 200%;
    195   margin-left: 0em;
    196   margin-right: 0em;
    197 }
    198 li.indline1 {
    199   font-weight: normal;
    200   line-height: 150%;
    201   margin-left: 0em;
    202   margin-right: 0em;
    203168}
    204169
     
    333298      <link rel="Appendix" title="A Acknowledgements" href="#rfc.section.A">
    334299      <link rel="Appendix" title="B Document History" href="#rfc.section.B">
    335       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.379, 2008-07-06 13:38:32, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     300      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.426, 2009-03-07 10:31:10, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    336301      <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
    337302      <meta name="DC.Creator" content="Hoffman, P.">
    338303      <meta name="DC.Creator" content="Melnikov, A.">
    339       <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-02">
     304      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-latest">
    340305      <meta name="DC.Date.Issued" scheme="ISO8601" content="2008-07">
    341306      <meta name="DC.Description.Abstract" content="Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes the trade-offs of each.">
     
    353318         <tr>
    354319            <td class="header left">
    355                &lt;draft-ietf-httpbis-security-properties-02&gt;
     320               &lt;draft-ietf-httpbis-security-properties-latest&gt;
    356321               
    357322            </td>
     
    364329         <tr>
    365330            <td class="header left">Expires: January 2009</td>
    366             <td class="header right">July 14, 2008</td>
     331            <td class="header right">July 2008</td>
    367332         </tr>
    368333      </table>
    369       <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-02</span></p>
     334      <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-latest</span></p>
    370335      <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
    371       <p>By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she
    372          is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section
    373          6 of BCP 79.
     336      <p>This Internet-Draft is submitted to IETF pursuant to, and in full conformance with, the provisions of BCP 78 and BCP 79. This
     337         document may contain material from IETF Documents or IETF Contributions published or made publicly available before November
     338         10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to
     339         allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s)
     340         controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative
     341         works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate
     342         it into languages other than English.
    374343      </p>
    375344      <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
     
    385354      </p>
    386355      <p>This Internet-Draft will expire in January 2009.</p>
     356      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
     357      <p>Copyright © 2008 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     358      <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
     359         and restrictions with respect to this document.
     360      </p>
    387361      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    388362      <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant
     
    694668      <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p>
    695669      <p id="rfc.section.B.3.p.3">Filled in section 2.5.</p>
    696       <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
    697       <p>This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the
    698          authors retain all their rights.
    699       </p>
    700       <p>This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION
    701          HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE
    702          DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
    703          WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
    704       </p>
    705       <hr class="noprint">
    706       <h1 class="np"><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>
    707       <p>The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might
    708          be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any
    709          license under such rights might or might not be available; nor does it represent that it has made any independent effort to
    710          identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and
    711          BCP 79.
    712       </p>
    713       <p>Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result
    714          of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users
    715          of this specification can be obtained from the IETF on-line IPR repository at &lt;<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>&gt;.
    716       </p>
    717       <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
    718          rights that may cover technology that may be required to implement this standard. Please address the information to the IETF
    719          at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>.
    720       </p>
    721670   </body>
    722671</html>
  • draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.txt

    r220 r549  
    55Internet-Draft                                            VPN Consortium
    66Intended status: Informational                               A. Melnikov
    7 Expires: August 25, 2008                                      Isode Ltd.
    8                                                        February 22, 2008
     7Expires: January 2, 2009                                      Isode Ltd.
     8                                                               July 2008
    99
    1010
    1111                     Security Requirements for HTTP
    12                draft-ietf-httpbis-security-properties-01
     12             draft-ietf-httpbis-security-properties-latest
    1313
    1414Status of this Memo
    1515
    16    By submitting this Internet-Draft, each author represents that any
    17    applicable patent or other IPR claims of which he or she is aware
    18    have been or will be disclosed, and any of which he or she becomes
    19    aware will be disclosed, in accordance with Section 6 of BCP 79.
     16   This Internet-Draft is submitted to IETF in full conformance with the
     17   provisions of BCP 78 and BCP 79.  This document may contain material
     18   from IETF Documents or IETF Contributions published or made publicly
     19   available before November 10, 2008.  The person(s) controlling the
     20   copyright in some of this material may not have granted the IETF
     21   Trust the right to allow modifications of such material outside the
     22   IETF Standards Process.  Without obtaining an adequate license from
     23   the person(s) controlling the copyright in such materials, this
     24   document may not be modified outside the IETF Standards Process, and
     25   derivative works of it may not be created outside the IETF Standards
     26   Process, except to format it for publication as an RFC or to
     27   translate it into languages other than English.
    2028
    2129   Internet-Drafts are working documents of the Internet Engineering
     
    3543   http://www.ietf.org/shadow.html.
    3644
    37    This Internet-Draft will expire on August 25, 2008.
     45   This Internet-Draft will expire on January 2, 2009.
    3846
    3947Copyright Notice
    4048
    41    Copyright (C) The IETF Trust (2008).
     49   Copyright (c) 2008 IETF Trust and the persons identified as the
     50   document authors.  All rights reserved.
     51
     52
     53
     54
     55Hoffman & Melnikov       Expires January 2, 2009                [Page 1]
     56
     57
     58Internet-Draft       Security Requirements for HTTP            July 2008
     59
     60
     61   This document is subject to BCP 78 and the IETF Trust's Legal
     62   Provisions Relating to IETF Documents in effect on the date of
     63   publication of this document (http://trustee.ietf.org/license-info).
     64   Please review these documents carefully, as they describe your rights
     65   and restrictions with respect to this document.
    4266
    4367Abstract
     
    5074
    5175
    52 
    53 
    54 
    55 Hoffman & Melnikov       Expires August 25, 2008                [Page 1]
    56 
    57 
    58 Internet-Draft       Security Requirements for HTTP        February 2008
    59 
    60 
    6176Table of Contents
    6277
     
    6479   2.  Existing HTTP Security Mechanisms  . . . . . . . . . . . . . .  3
    6580     2.1.  Forms And Cookies  . . . . . . . . . . . . . . . . . . . .  3
    66      2.2.  HTTP Access Authentication . . . . . . . . . . . . . . . .  4
     81     2.2.  HTTP Access Authentication . . . . . . . . . . . . . . . .  5
    6782       2.2.1.  Basic Authentication . . . . . . . . . . . . . . . . .  5
    6883       2.2.2.  Digest Authentication  . . . . . . . . . . . . . . . .  5
    69        2.2.3.  Other Access Authentication Schemes  . . . . . . . . .  6
    70      2.3.  Centrally-Issued Tickets . . . . . . . . . . . . . . . . .  6
    71      2.4.  Web Services . . . . . . . . . . . . . . . . . . . . . . .  6
    72      2.5.  Transport Layer Security . . . . . . . . . . . . . . . . .  7
    73    3.  Revisions To HTTP  . . . . . . . . . . . . . . . . . . . . . .  7
    74    4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
    75    5.  Normative References . . . . . . . . . . . . . . . . . . . . .  7
    76    Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . .  8
    77    Appendix B.  Document History  . . . . . . . . . . . . . . . . . .  9
     84       2.2.3.  Authentication Using Certificates in TLS . . . . . . .  6
     85       2.2.4.  Other Access Authentication Schemes  . . . . . . . . .  6
     86     2.3.  Centrally-Issued Tickets . . . . . . . . . . . . . . . . .  7
     87     2.4.  Web Services . . . . . . . . . . . . . . . . . . . . . . .  7
     88     2.5.  Transport Layer Security . . . . . . . . . . . . . . . . .  8
     89   3.  Revisions To HTTP  . . . . . . . . . . . . . . . . . . . . . .  8
     90   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
     91   5.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
     92   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . .  9
     93   Appendix B.  Document History  . . . . . . . . . . . . . . . . . . 10
    7894     B.1.  Changes between draft-sayre-http-security-variance-00
    79            and   draft-ietf-httpbis-security-properties-00  . . . . .  9
    80      B.2.  Changes between -00 and -01  . . . . . . . . . . . . . . .  9
    81    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
    82    Intellectual Property and Copyright Statements . . . . . . . . . . 11
    83 
    84 
    85 
    86 
    87 
    88 
    89 
    90 
    91 
    92 
    93 
    94 
    95 
    96 
    97 
    98 
    99 
    100 
    101 
    102 
    103 
    104 
    105 
    106 
    107 
    108 
    109 
    110 
    111 
    112 Hoffman & Melnikov       Expires August 25, 2008                [Page 2]
    113 
    114 
    115 Internet-Draft       Security Requirements for HTTP        February 2008
     95           and   draft-ietf-httpbis-security-properties-00  . . . . . 10
     96     B.2.  Changes between -00 and -01  . . . . . . . . . . . . . . . 10
     97     B.3.  Changes between -01 and -02  . . . . . . . . . . . . . . . 11
     98   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
     99
     100
     101
     102
     103
     104
     105
     106
     107
     108
     109
     110
     111
     112Hoffman & Melnikov       Expires January 2, 2009                [Page 2]
     113
     114
     115Internet-Draft       Security Requirements for HTTP            July 2008
    116116
    117117
     
    167167
    168168
    169 Hoffman & Melnikov       Expires August 25, 2008                [Page 3]
    170 
    171 
    172 Internet-Draft       Security Requirements for HTTP        February 2008
     169Hoffman & Melnikov       Expires January 2, 2009                [Page 3]
     170
     171
     172Internet-Draft       Security Requirements for HTTP            July 2008
    173173
    174174
     
    193193   (credentials are not differentiated in the protocol).
    194194
    195    HTML forms provide a facility for sites to indicate that a password
    196    should never be pre-populated. [[ More needed here on autocomplete ]]
     195   Many Web browsers have an auto-complete feature that stores a user's
     196   information and pre-populates fields in forms.  This is considered to
     197   be a convenience mechanism, and convenience mechanisms often have
     198   negative security properties.  The security concerns with auto-
     199   completion are particularly poignant for web browsers that reside on
     200   computers with multiple users.  HTML forms provide a facility for
     201   sites to indicate that a field, such as a password, should never be
     202   pre-populated.  However, it is clear that some form creators do not
     203   use this facility when they should.
    197204
    198205   The cookies that result from a successful form submission make it
     
    213220   have no use.
    214221
     222
     223
     224
     225
     226Hoffman & Melnikov       Expires January 2, 2009                [Page 4]
     227
     228
     229Internet-Draft       Security Requirements for HTTP            July 2008
     230
     231
    2152322.2.  HTTP Access Authentication
    216233
     
    221238   degree of support for one or both is available in many
    222239   implementations.  Neither scheme provides presentation control,
    223 
    224 
    225 
    226 Hoffman & Melnikov       Expires August 25, 2008                [Page 4]
    227 
    228 
    229 Internet-Draft       Security Requirements for HTTP        February 2008
    230 
    231 
    232240   logout capabilities, or interoperable internationalization.
    233241
     
    270278   implementations do not implement the mode that provides full message
    271279   integrity.  Perhaps one reason is that implementation experience has
     280
     281
     282
     283Hoffman & Melnikov       Expires January 2, 2009                [Page 5]
     284
     285
     286Internet-Draft       Security Requirements for HTTP            July 2008
     287
     288
    272289   shown that in some cases, especially those involving large requests
    273290   or responses such as streams, the message integrity mode is
     
    278295
    279296   Digest is extremely susceptible to offline dictionary attacks, making
    280 
    281 
    282 
    283 Hoffman & Melnikov       Expires August 25, 2008                [Page 5]
    284 
    285 
    286 Internet-Draft       Security Requirements for HTTP        February 2008
    287 
    288 
    289297   it practical for attackers to perform a namespace walk consisting of
    290    a few million passwords [[ CITATION NEEDED ]].
     298   a few million passwords for most users.
    291299
    292300   Many of the most widely-deployed HTTP/1.1 clients are not compliant
     
    305313   characters outside of the ISO 8859-1 repertoire.
    306314
    307 2.2.3.  Other Access Authentication Schemes
     3152.2.3.  Authentication Using Certificates in TLS
     316
     317   Running HTTP over TLS provides authentication of the HTTP server to
     318   the client.  HTTP over TLS can also provides authentication of the
     319   client to the server using certificates.  Although forms are a much
     320   more common way to authenticate users to HTTP servers, TLS client
     321   certificates are widely used in some environments.  The public key
     322   infrastructure (PKI) used to validate certificates in TLS can be
     323   rooted in public trust anchors or can be based on local trust
     324   anchors.
     325
     3262.2.4.  Other Access Authentication Schemes
    308327
    309328   There are many niche schemes that make use of the HTTP Authentication
     
    311330   transport layer connections.
    312331
    313 2.2.3.1.  Negotiate (GSS-API) Authentication
    314 
    315    [[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP
    316    Authentication in Microsoft Windows" [RFC4559] goes here. ]]
     3322.2.4.1.  Negotiate (GSS-API) Authentication
     333
     334   Microsoft has designed an HTTP authentication mechanism that utilizes
     335   SPNEGO [RFC4178] GSSAPI [RFC4559].  In Microsoft's implementation,
     336   SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan
     337
     338
     339
     340Hoffman & Melnikov       Expires January 2, 2009                [Page 6]
     341
     342
     343Internet-Draft       Security Requirements for HTTP            July 2008
     344
     345
     346   Manager protocols).
     347
     348   In Kerberos, clients and servers rely on a trusted third-party
     349   authentication service which maintains its own authentication
     350   database.  Kerberos is typically used with shared secret key
     351   cryptography, but extensions for use of other authentication
     352   mechnanisms such as PKIX certificates and two-factor tokens are also
     353   common.  Kerberos was designed to work under the assumption that
     354   packets traveling along the network can be read, modified, and
     355   inserted at will.
     356
     357   Unlike Digest, Negotiate authentication can take multiple round trips
     358   (client sending authentication data in Authorization, server sending
     359   authentication data in WWW-Authenticate) to complete.
     360
     361   Kerberos authentication is generally more secure than Digest.
     362   However the requirement for having a separate network authentication
     363   service might be a barrier to deployment.
    317364
    3183652.3.  Centrally-Issued Tickets
     
    335382   in XML-based protocols, using HTTP as a substitute for TCP.  Like the
    336383   amalgam of HTTP technologies mentioned above, the XML-based protocols
    337 
    338 
    339 
    340 Hoffman & Melnikov       Expires August 25, 2008                [Page 6]
    341 
    342 
    343 Internet-Draft       Security Requirements for HTTP        February 2008
    344 
    345 
    346384   are defined by an ever-changing combination of standard and vendor-
    347385   produced specifications, some of which may be obsoleted at any time
     
    355393   to differentiate it from REST. ]]
    356394
     395
     396
     397Hoffman & Melnikov       Expires January 2, 2009                [Page 7]
     398
     399
     400Internet-Draft       Security Requirements for HTTP            July 2008
     401
     402
    3574032.5.  Transport Layer Security
    358404
    359    [[ A discussion of HTTP over TLS needs to be added here. ]]
    360 
    361    [[ Discussion of connection confidentiality should be separate from
    362    the discussion of access authentication based on mutual
    363    authentication with certificates in TLS. ]]
     405   In addition to using TLS for client and/or server authentication, it
     406   is also very commonly used to protect the confidentiality and
     407   integrity of the HTTP session.  For instance, both HTTP Basic
     408   authentication and Cookies are often protected against snooping by
     409   TLS.
     410
     411   It should be noted that, in that case, TLS does not protect against a
     412   breach of the credential store at the server or against a keylogger
     413   or phishing interface at the client.  TLS does not change the fact
     414   that Basic Authentication passwords are reusable and does not address
     415   that weakness.
    364416
    365417
     
    393445              <http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf>.
    394446
    395 
    396 
    397 Hoffman & Melnikov       Expires August 25, 2008                [Page 7]
    398 
    399 
    400 Internet-Draft       Security Requirements for HTTP        February 2008
    401 
    402 
    403447   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
    404448              3", BCP 9, RFC 2026, October 1996.
    405449
    406450   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
     451
     452
     453
     454Hoffman & Melnikov       Expires January 2, 2009                [Page 8]
     455
     456
     457Internet-Draft       Security Requirements for HTTP            July 2008
     458
     459
    407460              Mechanism", RFC 2109, February 1997.
    408461
     
    434487              RFC 3986, January 2005.
    435488
     489   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
     490              Simple and Protected Generic Security Service Application
     491              Program Interface (GSS-API) Negotiation Mechanism",
     492              RFC 4178, October 2005.
     493
    436494   [RFC4559]  Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
    437495              Kerberos and NTLM HTTP Authentication in Microsoft
     
    451509
    452510
    453 
    454 Hoffman & Melnikov       Expires August 25, 2008                [Page 8]
    455 
    456 
    457 Internet-Draft       Security Requirements for HTTP        February 2008
     511Hoffman & Melnikov       Expires January 2, 2009                [Page 9]
     512
     513
     514Internet-Draft       Security Requirements for HTTP            July 2008
    458515
    459516
     
    509566
    510567
    511 Hoffman & Melnikov       Expires August 25, 2008                [Page 9]
    512 
    513 
    514 Internet-Draft       Security Requirements for HTTP        February 2008
     568Hoffman & Melnikov       Expires January 2, 2009               [Page 10]
     569
     570
     571Internet-Draft       Security Requirements for HTTP            July 2008
    515572
    516573
     
    530587   In A, added the WG.
    531588
     589B.3.  Changes between -01 and -02
     590
     591   In section 2.1, added more to the paragraph on auto-completion of
     592   HTML forms.
     593
     594   Added the section on TLS for authentication.
     595
     596   Filled in section 2.5.
     597
    532598
    533599Authors' Addresses
     
    557623
    558624
    559 
    560 
    561 
    562 
    563 
    564 
    565 
    566 
    567 
    568 Hoffman & Melnikov       Expires August 25, 2008               [Page 10]
    569 
    570 
    571 Internet-Draft       Security Requirements for HTTP        February 2008
    572 
    573 
    574 Full Copyright Statement
    575 
    576    Copyright (C) The IETF Trust (2008).
    577 
    578    This document is subject to the rights, licenses and restrictions
    579    contained in BCP 78, and except as set forth therein, the authors
    580    retain all their rights.
    581 
    582    This document and the information contained herein are provided on an
    583    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    584    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
    585    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
    586    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
    587    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    588    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
    589 
    590 
    591 Intellectual Property
    592 
    593    The IETF takes no position regarding the validity or scope of any
    594    Intellectual Property Rights or other rights that might be claimed to
    595    pertain to the implementation or use of the technology described in
    596    this document or the extent to which any license under such rights
    597    might or might not be available; nor does it represent that it has
    598    made any independent effort to identify any such rights.  Information
    599    on the procedures with respect to rights in RFC documents can be
    600    found in BCP 78 and BCP 79.
    601 
    602    Copies of IPR disclosures made to the IETF Secretariat and any
    603    assurances of licenses to be made available, or the result of an
    604    attempt made to obtain a general license or permission for the use of
    605    such proprietary rights by implementers or users of this
    606    specification can be obtained from the IETF on-line IPR repository at
    607    http://www.ietf.org/ipr.
    608 
    609    The IETF invites any interested party to bring to its attention any
    610    copyrights, patents or patent applications, or other proprietary
    611    rights that may cover technology that may be required to implement
    612    this standard.  Please address the information to the IETF at
    613    ietf-ipr@ietf.org.
    614 
    615 
    616 Acknowledgment
    617 
    618    Funding for the RFC Editor function is provided by the IETF
    619    Administrative Support Activity (IASA).
    620 
    621 
    622 
    623 
    624 
    625 Hoffman & Melnikov       Expires August 25, 2008               [Page 11]
    626 
    627 
     625Hoffman & Melnikov       Expires January 2, 2009               [Page 11]
     626
     627
  • draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.xml

    r279 r549  
    1414]>
    1515
    16 <rfc category="info" ipr="full3978"
    17   docName="draft-ietf-httpbis-security-properties-02">
     16<rfc category="info" ipr="pre5378Trust200902"
     17  docName="draft-ietf-httpbis-security-properties-latest">
    1818
    1919<?xml-stylesheet type='text/xsl' href='rfc2629xslt/rfc2629.xslt' ?>
Note: See TracChangeset for help on using the changeset viewer.