Ignore:
Timestamp:
09/03/09 11:13:57 (14 years ago)
Author:
julian.reschke@…
Message:

update boilerplate and Makefile

File:
1 edited

Legend:

Unmodified
Added
Removed

  • 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
Note: See TracChangeset for help on using the changeset viewer.