Search This Blog

Sunday, March 14, 2010

IETF Internet Draft: Security Requirements for HTTP

Jeff Hodges and Barry Leiba (eds), IETF Internet Draft

An updated version of the IETF Informational Internet Draft has beenpublished docmenting "Security Requirements for HTTP." Recent InternetEngineering Steering Group (IESG) practice dictates that IETF protocolsmust specify mandatory-to-implement (MTI) security mechanisms, so thatall conformant implementations share a common baseline. This documentexamines all widely deployed HTTP security technologies, and analyzesthe trade-offs of each. The document examines the effects of applyingsecurity constraints to Web applications, documents the properties thatresult from each method, and will make Best Current Practicerecommendations for HTTP security in a later document version.
Some existing HTTP Security Mechanisms include: Forms And Cookies, HTTPAccess Authentication [Basic Authentication, Digest Authentication,Authentication Using Certificates in TLS, Other Access AuthenticationSchemes, Centrally-Issued Tickets, and Web Services security mechanisms.In addition to using TLS for client and/or server authentication, itis also very commonly used to protect the confidentiality and integrityof the HTTP session. For instance, both HTTP Basic authentication andCookies are often protected against snooping by TLS. It should be notedthat, in that case, TLS does not protect against a breach of thecredential store at the server or against a keylogger or phishinginterface at the client. TLS does not change the fact that BasicAuthentication passwords are reusable and does not address that weakness.
Is is possible that HTTP will be revised in the future. "HTTP/1.1" (RFC2616) and "Use and Interpretation of HTTP Version Numbers" (RFC 2145)define conformance requirements in relation to version numbers. In HTTP1.1, all authentication mechanisms are optional, and no single transportsubstrate is specified. Any HTTP revision that adds a mandatory securitymechanism or transport substrate will have to increment the HTTP versionnumber appropriately. All widely used schemes are non-standard and/orproprietary..."

No comments: