One document matched: draft-josefsson-kitten-crotp-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 14:15:37 |