The IESG has approved the following document: - 'Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism ' <draft-ietf-sasl-scram-10.txt> as a Proposed Standard This document is the product of the Simple Authentication and Security Layer Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-scram-10.txt Technical Summary The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use. This specification describes a family of Simple Authentication and Security Layer (SASL, RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status-quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. Working Group Summary There were significant and long discussions over several design choices, worth mentioning are: 1) Hash function. The decision was to define a SASL mechanism family to allow for future extension, but not register it as a family in the IANA registry. The decision is to use HMAC-SHA-1 as the initial default, and to register SCRAM-SHA-1* the mechanism name. The alternatives considered were HMAC-MD5 and HMAC-SHA-2. HMAC-SHA-1 was the compromise proposal. 2) Channel binding type negotiation. After long considerations, it was decided to leave channel binding type negotiation external to SCRAM and to provide a default of tls-unique. This simplify the design and makes it easy to implement in popular configurations (i.e., together with TLS). 3) IANA policy. Two aspects have been considered. First, whether to actually register a SASL mechanism family or just define a family and register the two family members as separate mechanism names. The conclusion has been to register a family. Secondly, the registration policy has been discussed. Document Quality There are several early experimental implementations and more implementers are interested. Personnel The document shepherd is Simon Josefsson, and the responsible area director is Pasi Eronen. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
