Network Working Group S. Josefsson Internet-Draft SJD AB Intended status: Standards Track February 22, 2011 Expires: August 26, 2011 SASL and GSS-API Mechanism for Two Factor Authentication based on a Password and a One-Time Password (OTP): CROTP draft-josefsson-kitten-crotp-00 Abstract The CROTP mechanism family provide support for two-factor authentication using a static long-term password and a single use changing one-time password (OTP) in the SASL and GSS-API frameworks. The design of CROTP is based on SCRAM described in RFC 5802. CROTP works with several OTP system, including the Open AuTHentication HOTP algorithm described in RFC 4226. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 26, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Josefsson Expires August 26, 2011 [Page 1]
Internet-Draft CROTP SASL & GSS-API Mechanism February 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 3. Mechanism Name . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. CROTP as a GSS-API Mechanism . . . . . . . . . . . . . . . . . 4 6. Implementation guidelines . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Josefsson Expires August 26, 2011 [Page 2]
Internet-Draft CROTP SASL & GSS-API Mechanism February 2011 1. Introduction Simple Authentication and Security Layer (SASL) [RFC4422] is a framework that provide user authentication for connection-based protocols. The SCRAM [RFC5802] mechanism family provides username/ password based authentication. Several systems for One-Time Password exists, including S/KEY [RFC1760] (revised into OTP [RFC2289]) and OATH HOTP [RFC4226]. The CROTP mechanism extends SCRAM by adding a new mandatory field to transfer a One-Time Password (OTP) and specifying some additional requirements on implementations. CROTP is defined as a SASL mechanism that is wire compatible with a GSS-API mechanism used through the GS2 [RFC5801] framework, which effectively specifies a new GSS-API [RFC2743] mechanism of CROTP. Because CROTP is specified as SCRAM with some modification, familiarity with SCRAM is required by the reader. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Mechanism Name The CROTP mechanism name is constructed from the SCRAM mechanism name by replacing "SCRAM" with "CROTP". The length of the complete CROTP mechanism name will thus be the same as the complete "SCRAM" mechanism name. This permit use of any hash function name as per the discussion in section 4 of [RFC5802]. For example, the CROTP mechanism names that correspond to SCRAM-SHA-1 and SCRAM-SHA-1-PLUS are CROTP-SHA-1 and CROTP-SHA-1-PLUS respectively. For interoperability, all CROTP clients and servers MUST implement the CROTP-SHA-1 authentication mechanism, i.e., an authentication mechanism from the CROTP family that uses the SHA-1 hash function as defined in [RFC3174]. Generally, the usage of PLUS vs non-PLUS names are the same as for SCRAM. (If it weren't for the maximum name length of 20 characters imposed Josefsson Expires August 26, 2011 [Page 3]
Internet-Draft CROTP SASL & GSS-API Mechanism February 2011 by the SASL framework, we would have used a more illustrative name such as "OTP-SCRAM" rather than "CROTP".) 4. Protocol CROTP is defined as a set of modifications of the SCRAM protocol. We provide a new field to transfer the OTP from the client to the server. The OTP is sent in unencrypted/unhashed form, to allow for OTP systems where the server is cannot calculate OTPs locally but require the OTP in clear text from the client to be able to validate it. In the wire protocol the "client-final-message-without-proof" field is replaced as follows: ;; from RFC 5802 client-final-message-without-proof = channel-binding "," nonce ["," extensions] ;; variant used by CROTP otp = "o=" saslname client-final-message-without-proof = channel-binding "," nonce "," otp ["," extensions] [Design discussion: The OTP had to go either in "client-first- message-bare" or "client-final-message-without-proof" and we chose the latter to align the OTP prompt with where a client (at latest) queries the user for a password.] The hashing performed by CROTP/SCRAM covers the entire "client-final- message-without-proof" field, thus the OTP value will be bound to the authentication attempt. The optional error codes are extended with a new error code to indicate OTP related problems, as follows: server-error-value-ext = "replayed-otp" / "invalid-otp" / value [TODO: Require TLS for OTP protection, or derive keys from the SCRAM negotiation and GSS_Wrap the OTP?] 5. CROTP as a GSS-API Mechanism CROTP is identical to SCRAM as a GSS-API except that the GSS-API OID Josefsson Expires August 26, 2011 [Page 4]
Internet-Draft CROTP SASL & GSS-API Mechanism February 2011 for CROTP-SHA-1 is 1.3.6.1.4.1.11591.4.9. 6. Implementation guidelines Servers that support both SCRAM and CROTP may use the same password- equivalent for both mechanisms since they are compatible. Clients that already have a SCRAM credential (i.e., the "ClientKey") can use it as the "ClientKey" in CROTP without modification. When a server advertises support for both SCRAM and CROTP, the client may modify the password prompt to include an optional OTP field. If the user does not provide an OTP the client can proceed with SCRAM, but if the user provides an OTP the client would select CROTP. Clients MUST NOT use CROTP with an empty OTP. If the server supports SCRAM, it could be used instead, or authentication could fail. 7. IANA Considerations IANA has added the following family of SASL mechanisms to the SASL Mechanism registry established by [RFC4422]: Subject: Registration of SASL mechanism family CROTP- SASL family name (or prefix for the family): CROTP- Security considerations: This document Published specification: This document Person & email address to contact for further information: Simon Josefsson <simon@josefsson.org> Intended usage: COMMON Owner/Change controller: Simon Josefsson <simon@josefsson.org> Note: The family names are intended to match the SCRAM names, and uses the same (but separate) registration policy. Registration of CROTP names should be reviewed for alignment with similar SCRAM names. XXX: registration policy? 8. Security Considerations The CROTP mechanism is based on [RFC5802] and inherits all its security considerations The OTP is sent in unencrypted/unhashed form from the client to the server, which allows an attacker to read the OTP value and perform a race with the server to validate the OTP. Josefsson Expires August 26, 2011 [Page 5]
Internet-Draft CROTP SASL & GSS-API Mechanism February 2011 TBA. 9. Acknowledgements TBA. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 10.2. Informative References [RFC1760] Haller, N., "The S/KEY One-Time Password System", RFC 1760, February 1995. [RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One- Time Password System", RFC 2289, February 1998. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, December 2005. [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, July 2010. Josefsson Expires August 26, 2011 [Page 6]
Internet-Draft CROTP SASL & GSS-API Mechanism February 2011 Author's Address Simon Josefsson SJD AB Hagagatan 24 Stockholm 113 47 SE Email: simon@josefsson.org URI: http://josefsson.org/ Josefsson Expires August 26, 2011 [Page 7]