[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/