[ldap-sdk-commits] SF.net SVN: ldap-sdk:[1586] trunk/docs
A Java-based LDAP API
Brought to you by:
dirmgr,
kennethleo
Menu
▾
▴
[ldap-sdk-commits] SF.net SVN: ldap-sdk:[1586] trunk/docs
|
From: <di...@us...> - 2023-01-16 20:46:52
|
Revision: 1586
http://sourceforge.net/p/ldap-sdk/code/1586
Author: dirmgr
Date: 2023-01-16 20:46:51 +0000 (Mon, 16 Jan 2023)
Log Message:
-----------
Update LDAP drafts
Updated documentation to include the latest versions of
draft-howard-gssapi-aead, draft-ietf-kitten-scram-2fa,
draft-melnikov-scram-bis, and draft-reitzenstein-kitten-opaque in
the set of LDAP-related specifications.
Modified Paths:
--------------
trunk/docs/release-notes.html
trunk/docs/specs/internet-drafts.html
Added Paths:
-----------
trunk/docs/specs/draft-howard-gssapi-aead-01.txt
trunk/docs/specs/draft-ietf-kitten-scram-2fa-02.txt
trunk/docs/specs/draft-melnikov-scram-bis-02.txt
trunk/docs/specs/draft-reitzenstein-kitten-opaque-02.txt
Removed Paths:
-------------
trunk/docs/specs/draft-ietf-kitten-scram-2fa-01.txt
trunk/docs/specs/draft-melnikov-scram-bis-00.txt
Modified: trunk/docs/release-notes.html
===================================================================
--- trunk/docs/release-notes.html 2023-01-10 23:46:02 UTC (rev 1585)
+++ trunk/docs/release-notes.html 2023-01-16 20:46:51 UTC (rev 1586)
@@ -38,6 +38,13 @@
obtaining the private key when it is encrypted form.
<br><br>
</li>
+
+ <li>
+ Updated documentation to include the latest versions of
+ draft-howard-gssapi-aead, draft-ietf-kitten-scram-2fa, draft-melnikov-scram-bis,
+ and draft-reitzenstein-kitten-opaque in the set of LDAP-related specifications.
+ <br><br>
+ </li>
</ul>
<p></p>
Added: trunk/docs/specs/draft-howard-gssapi-aead-01.txt
===================================================================
--- trunk/docs/specs/draft-howard-gssapi-aead-01.txt (rev 0)
+++ trunk/docs/specs/draft-howard-gssapi-aead-01.txt 2023-01-16 20:46:51 UTC (rev 1586)
@@ -0,0 +1,504 @@
+
+
+
+
+Network Working Group L. Howard
+Internet-Draft PADL
+Intended status: Experimental 6 January 2023
+Expires: 10 July 2023
+
+
+ AEAD Modes for Kerberos GSS-API
+ draft-howard-gssapi-aead-01
+
+Abstract
+
+ This document updates RFC4121 with support for encryption mechanisms
+ that can authenticate associated data such as Counter with CBC-MAC
+ (CCM) and Galois/Counter Mode (GCM). These mechanisms are often more
+ performant and need not expand the message as much as conventional
+ modes.
+
+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 https://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 10 July 2023.
+
+Copyright Notice
+
+ Copyright (c) 2023 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 (https://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 Revised BSD License text as
+ described in Section 4.e of the Trust Legal Provisions and are
+ provided without warranty as described in the Revised BSD License.
+
+
+
+
+Howard Expires 10 July 2023 [Page 1]
+
+Internet-Draft AEAD Modes for Kerberos GSS-API January 2023
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
+ 3. Authenticated Encryption with Associated Data (AEAD)
+ Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 4. Updates to RFC 2743 . . . . . . . . . . . . . . . . . . . . . 3
+ 4.1. GSS_Wrap_AEAD . . . . . . . . . . . . . . . . . . . . . . 3
+ 4.2. GSS_Unwrap_AEAD . . . . . . . . . . . . . . . . . . . . . 4
+ 5. Updates to RFC 4121 . . . . . . . . . . . . . . . . . . . . . 4
+ 5.1. Support for Associated Data . . . . . . . . . . . . . . . 4
+ 5.2. Existing Encryption Types . . . . . . . . . . . . . . . . 5
+ 5.3. Native AEAD Encryption Types . . . . . . . . . . . . . . 5
+ 5.3.1. Restriction on Native AEAD Usage . . . . . . . . . . 5
+ 5.3.2. Application-provided Cipherstate . . . . . . . . . . 5
+ 5.3.3. Encryption and Checksum Operations . . . . . . . . . 6
+ 5.3.4. DCE RPC Interoperability . . . . . . . . . . . . . . 7
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 9
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
+
+1. Introduction
+
+ This document updates [RFC4121] with support for encryption
+ mechanisms that support Authenticated Encryption with Associated Data
+ (AEAD). These mechanisms often have performance advantage over
+ conventional encryption modes as they can be efficiently parallelized
+ and do not expand the plaintext when encrypting.
+
+ In addition, this document defines new GSS-API functions for
+ protecting associated data in addition to a plaintext.
+
+2. Requirements notation
+
+ 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. Authenticated Encryption with Associated Data (AEAD) Overview
+
+ The Kerberos 5 GSS-API mechanism specified in [RFC4121] provides for
+ the authenticated encryption of plaintext, that is, it provides both
+ for confidentiality and a way to check the for integrity and
+ authenticity.
+
+
+
+
+Howard Expires 10 July 2023 [Page 2]
+
+Internet-Draft AEAD Modes for Kerberos GSS-API January 2023
+
+
+ It can be useful in many applications to provide for the integrity
+ and authenticity of some additional unencrypted data; this is termed
+ Authenticated Encryption with Associated Data (AEAD). This can be
+ done by the generic composition of existing encryption and checksum
+ mechanisms, or using algorithms which specifically provide for AEAD
+ (see [RFC5116]). The latter class of algorithms, referred to as
+ native AEAD, may have additional constraints (further described in
+ [KRB-AEAD]).
+
+4. Updates to RFC 2743
+
+ [RFC2743] is updated with variations of GSS_Wrap() and GSS_Unwrap()
+ that permit the inclusion of associated data to be authenticated
+ along with a plaintext.
+
+
+ // TBD: do we allow interleaved plaintext and associated data (which
+ // SSPI does and indeed requires for DCE), or do we limit it to a
+ // single octet string each? If the former, we need to define
+ // GSS_Wrap_IOV instead of GSS_Wrap_AEAD (and the Unwrap
+ // equivalents).
+
+4.1. GSS_Wrap_AEAD
+
+ Inputs:
+
+ * context_handle CONTEXT HANDLE,
+
+ * conf_req_flag BOOLEAN,
+
+ * qop_req INTEGER, -- 0 specifies default QOP
+
+ * input_assoc_data OCTET STRING, -- associated data
+
+ * input_message OCTET STRING -- plaintext
+
+ Outputs:
+
+ * major_status INTEGER,
+
+ * minor_status INTEGER,
+
+ * conf_state BOOLEAN,
+
+ * output_message OCTET STRING -- caller must release with
+ GSS_Release_buffer()
+
+
+
+
+
+Howard Expires 10 July 2023 [Page 3]
+
+Internet-Draft AEAD Modes for Kerberos GSS-API January 2023
+
+
+ Performs the data origin authentication, data integrity and
+ (optionally) data confidentiality functions of GSS_Wrap(),
+ additionally integrity protecting the data in input_assoc_data.
+ Return values are as for GSS_Wrap(). Note that output_message does
+ not include the data in input_assoc_data.
+
+4.2. GSS_Unwrap_AEAD
+
+ Inputs:
+
+ * context_handle CONTEXT HANDLE,
+
+ * input_message OCTET STRING, -- plaintext
+
+ * input_assoc_data OCTET STRING -- associated data
+
+ Outputs:
+
+ * conf_state BOOLEAN,
+
+ * qop_state INTEGER,
+
+ * major_status INTEGER,
+
+ * minor_status INTEGER,
+
+ * output_message OCTET STRING -- caller must release with
+ GSS_Release_buffer()
+
+ Processes a data element generated (and optionally encrypted) by
+ GSS_Wrap(), provided as input_message, additionally validating the
+ data origin and integrity of input_assoc_data. Return values are as
+ for GSS_Unwrap(). Note that output_message does not include the data
+ in input_assoc_data.
+
+5. Updates to RFC 4121
+
+5.1. Support for Associated Data
+
+ The generation of per-message tokens using the GSS_Wrap_AEAD() and
+ GSS_Unwrap_AEAD() functions is identical to GSS_Wrap() and
+ GSS_Unwrap(), except that:
+
+ * the encrypt-with-ad and decrypt-with-ad functions are used instead
+ of the encrypt and decrypt functions (respectively)
+
+ * the input_assoc_data parameter is passed as the associated data
+
+
+
+
+Howard Expires 10 July 2023 [Page 4]
+
+Internet-Draft AEAD Modes for Kerberos GSS-API January 2023
+
+
+ * the is-longterm parameter is always false
+
+5.2. Existing Encryption Types
+
+ For existing encryption mechanisms that use a generic composition of
+ encryption and checksum functions (such as the Simplified Profile in
+ [RFC3961]), the only operative difference to [RFC4121] is that the
+ associated data is prepended to the plaintext before invoking the
+ checksum function. As such, for these encryption types
+ GSS_Wrap_AEAD() with no associated data has an identical output to
+ GSS_Wrap().
+
+5.3. Native AEAD Encryption Types
+
+ When used with native AEAD encryption types as defined in [KRB-AEAD],
+ the generation of [RFC4121] per-message tokens is modified as
+ described below.
+
+5.3.1. Restriction on Native AEAD Usage
+
+ Implementations SHALL NOT use native AEAD encryption types where the
+ deterministic cipherstate length is less than 12 octets (96 bytes).
+
+
+ // TBD: if we want to support CCM with a 32-bit counter, we could
+ // remove the Filler byte and reduce the required cipherstate length
+ // to 11 octets. However, this may make it more difficult to use
+ // TLS-oriented CCM implementations that expose the Fixed-Common and
+ // Fixed-Distinct nonce components independently.
+
+ Native AEAD encryption types not supporting long-term keys MUST NOT
+ be used as ticket session keys, only as authenticator subkeys.
+ [RFC4537] SHOULD be used to indicate initiator support.
+
+5.3.2. Application-provided Cipherstate
+
+ The cipherstate for each invocation of encrypt-with-ad or decrypt-
+ with-ad is given as follows. (For consistency with [RFC4121] the
+ following definition uses 0-based indexing.)
+
+
+
+
+
+
+
+
+
+
+
+
+Howard Expires 10 July 2023 [Page 5]
+
+Internet-Draft AEAD Modes for Kerberos GSS-API January 2023
+
+
+ +==========+=========+===========================+
+ | Octet no | Name | Description |
+ +==========+=========+===========================+
+ | 0..1 | TOK_ID | Identification field, per |
+ | | | RFC4121 Section 4.2.6 |
+ +----------+---------+---------------------------+
+ | 2 | Flags | Attributes field, per |
+ | | | RFC4121 Section 4.2.6 |
+ +----------+---------+---------------------------+
+ | 3 | Filler | One octet of the hex |
+ | | | value FF |
+ +----------+---------+---------------------------+
+ | 4..11 | SND_SEQ | Sequence number field, |
+ | | | per RFC4121 Section 4.2.6 |
+ +----------+---------+---------------------------+
+ | 12.. | | Remaining octets (if any) |
+ | | | are set to zero |
+ +----------+---------+---------------------------+
+
+ Table 1
+
+ The output cipherstate from the encrypt-with-ad and decrypt-with-ad
+ functions is discarded as it is always specified explicitly as
+ described above.
+
+ The use of application-managed cipherstate allows the per-message
+ token size be reduced by omitting the confounder and encrypted copy
+ of the token header. There is no limit on the number or size of
+ messages that can be protected beyond those imposed by the sequence
+ number size and the underlying cryptosystem.
+
+5.3.3. Encryption and Checksum Operations
+
+ This text amends [RFC4121] Section 4.2.4.
+
+ In Wrap tokens that provide for confidentiality, the first 16 octets
+ of the token (the "header", as defined in [RFC4121] Section 4.2.6)
+ SHALL NOT be appended to the plaintext data before encryption.
+ Instead, the TOK_ID, Flags and SND_SEQ fields of the token header are
+ protected by the initialization vector (cipherstate). The EC field
+ is unprotected, a change from [RFC4121]. For the native AEAD
+ encryption types profiled in [KRB-AEAD] Section 5, EC SHALL be zero
+ (except when GSS_C_DCE_STYLE is in use, see below). This
+ specification does not support native AEAD encryption types that
+ require the plaintext to be padded.
+
+
+
+
+
+
+Howard Expires 10 July 2023 [Page 6]
+
+Internet-Draft AEAD Modes for Kerberos GSS-API January 2023
+
+
+ In Wrap tokens that do not provide for confidentiality, the first 16
+ octets of the token SHALL NOT be appended to the to-be-signed
+ plaintext data. As with Wrap tokens that do provide for
+ confidentiality, all fields except EC and RRC are protected by the
+ initialization vector. For the AEAD encryption types defined in
+ [KRB-AEAD] Section 5, EC SHALL be sixteen, reflecting the tag length
+ of 16 octets (128 bits).
+
+ The receiver MUST explicitly validate the EC field. Owing to this
+ specification not supporting native AEAD encryption types that
+ require padding and protecting the token header with the
+ initialization vector, all encryption can be done in-place and there
+ is no need to rotate the emitted token (see [RFC4121] Section 4.2.5).
+ As such the RRC field SHALL contain the hex value 00 00.
+
+ Because native AEAD encryption types lack an explicit checksum
+ operation, MIC tokens are generated similarly to Wrap tokens, using
+ the encrypt-with-ad function passing the to-be-signed data as the
+ associated data and using a plaintext length of zero. The key usage
+ and initialization vector serve to disambiguate MIC from Wrap tokens.
+ The octet string output by the encrypt-with-ad function contains the
+ authentication tag, which is placed in the SGN_CKSUM field of the
+ token.
+
+5.3.4. DCE RPC Interoperability
+
+ Existing implementations that support the GSS_C_DCE_STYLE context
+ flag will, when this flag is in set, set EC for Wrap tokens with
+ confidentiality to the underlying cipher's block size and use an
+ effective Right Rotation Count (RRC) of EC + RRC bytes. This
+ document does not specify otherwise.
+
+ When GSS_C_DCE_STYLE is set, receivers MUST verify that the otherwise
+ unprotected EC field is the underlying cipher's block size for Wrap
+ tokens with confidentiality. (For Wrap tokens without
+ confidentiality, the EC field remains the length of the
+ authentication tag.)
+
+ DCE interleaves plaintext and associated data; because native AEAD
+ algorithms may require associated data to be processed before any
+ plaintext, any plaintext and associated data must each be coalesced
+ before encrypting or decrypting. This document does not specify an
+ API for processing interleaved plaintext and associated data.
+
+
+
+
+
+
+
+
+Howard Expires 10 July 2023 [Page 7]
+
+Internet-Draft AEAD Modes for Kerberos GSS-API January 2023
+
+
+6. Security Considerations
+
+ The combination of a context-specific session key and the presence of
+ the the TOK_ID and SND_SEQ fields in the cipherstate guarantees that
+ the key/IV combination is safe from reuse. The allows native AEAD
+ modes such as [GCM] and [CCM] to be used securely.
+
+ Because the initialization vector has a deterministic (but non-
+ repeating) construction, it is safe for use with GCM without any
+ limitation on the number of invocations of the authenticated
+ encryption function other than that imposed by the requirement that
+ the cipherstate not repeat. (Section 8.3 of [GCM] imposes an
+ invocation limit of 2^32 where the cipherstate is randomly generated
+ or is a length other than 96 bits.)
+
+ When using native AEAD encryption types, the EC and RRC fields are
+ unprotected, however they are well known constants which can be
+ validated by the peer.
+
+ The reordering of plaintext and associated data for GSS_C_DCE_STYLE
+ interoperability may be problematic where the plaintext and
+ associated data lengths are variable.
+
+7. Acknowledgements
+
+ The author would like to thank the following individuals for their
+ comments and suggestions: Nicolas Williams and Greg Hudson.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S. and RFC Publisher, "Key words for use in RFCs
+ to Indicate Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2743] Linn, J. and RFC Publisher, "Generic Security Service
+ Application Program Interface Version 2, Update 1",
+ RFC 2743, DOI 10.17487/RFC2743, January 2000,
+ <https://www.rfc-editor.org/info/rfc2743>.
+
+ [RFC4121] Zhu, L., Jaganathan, K., Hartman, S., and RFC Publisher,
+ "The Kerberos Version 5 Generic Security Service
+ Application Program Interface (GSS-API) Mechanism: Version
+ 2", RFC 4121, DOI 10.17487/RFC4121, July 2005,
+ <https://www.rfc-editor.org/info/rfc4121>.
+
+
+
+
+Howard Expires 10 July 2023 [Page 8]
+
+Internet-Draft AEAD Modes for Kerberos GSS-API January 2023
+
+
+ [RFC4537] Zhu, L., Leach, P., Jaganathan, K., and RFC Publisher,
+ "Kerberos Cryptosystem Negotiation Extension", RFC 4537,
+ DOI 10.17487/RFC4537, June 2006,
+ <https://www.rfc-editor.org/info/rfc4537>.
+
+ [KRB-AEAD] Howard, L., "AEAD Encryption Types for Kerberos 5", Work
+ in Progress, Internet-Draft, draft-howard-krb-aead-00,
+ December 2015,
+ <https://www.ietf.org/id/draft-howard-krb-aead-00.txt>.
+
+8.2. Informative References
+
+ [RFC3961] Raeburn, K. and RFC Publisher, "Encryption and Checksum
+ Specifications for Kerberos 5", RFC 3961,
+ DOI 10.17487/RFC3961, February 2005,
+ <https://www.rfc-editor.org/info/rfc3961>.
+
+ [RFC5116] McGrew, D. and RFC Publisher, "An Interface and Algorithms
+ for Authenticated Encryption", RFC 5116,
+ DOI 10.17487/RFC5116, January 2008,
+ <https://www.rfc-editor.org/info/rfc5116>.
+
+ [CCM] Dworkin, M., "Recommendation for Block Cipher Modes of
+ Operation: The CCM Mode for Authentication and
+ Confidentiality", May 2004,
+ <http://csrc.nist.gov/publications/nistpubs/800-38C/SP-
+ 800-38C.pdf>.
+
+ [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
+ Operation: Galois/Counter Mode (GCM) and GMAC", November
+ 2007, <http://csrc.nist.gov/publications/nistpubs/800-38D/
+ SP-800-38D.pdf>.
+
+Author's Address
+
+ Luke Howard
+ PADL Software
+ PO Box 59
+ Central Park VIC 3145
+ Australia
+ Email: lu...@pa...
+
+
+
+
+
+
+
+
+
+
+Howard Expires 10 July 2023 [Page 9]
Deleted: trunk/docs/specs/draft-ietf-kitten-scram-2fa-01.txt
===================================================================
--- trunk/docs/specs/draft-ietf-kitten-scram-2fa-01.txt 2023-01-10 23:46:02 UTC (rev 1585)
+++ trunk/docs/specs/draft-ietf-kitten-scram-2fa-01.txt 2023-01-16 20:46:51 UTC (rev 1586)
@@ -1,448 +0,0 @@
-
-
-
-
-Network Working Group A. Melnikov
-Internet-Draft Isode Ltd
-Intended status: Standards Track 25 January 2022
-Expires: 29 July 2022
-
-
- Extensions to Salted Challenge Response (SCRAM) for 2 factor
- authentication
- draft-ietf-kitten-scram-2fa-01
-
-Abstract
-
- This specification describes an extension to family of Simple
- Authentication and Security Layer (SASL; RFC 4422) authentication
- mechanisms called the Salted Challenge Response Authentication
- Mechanism (SCRAM), which provides support for 2 factor
- authentication. It also includes a separate extension for quick
- reauthentication.
-
- This specification also gives an example of how TOTP (RFC 6238) can
- be used as the second factor.
-
-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 https://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 29 July 2022.
-
-Copyright Notice
-
- Copyright (c) 2022 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 (https://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
-
-
-
-Melnikov Expires 29 July 2022 [Page 1]
-
-Internet-Draft SCRAM 2FA extensions January 2022
-
-
- and restrictions with respect to this document. Code Components
- extracted from this document must include Revised BSD License text as
- described in Section 4.e of the Trust Legal Provisions and are
- provided without warranty as described in the Revised BSD License.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
- 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
- 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. SCRAM Extension for 2FA . . . . . . . . . . . . . . . . . . . 3
- 4. SCRAM Extension for reauthentication . . . . . . . . . . . . 4
- 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 4
- 6. Use of TOTP with SCRAM . . . . . . . . . . . . . . . . . . . 5
- 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
- 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
- 12. Normative References . . . . . . . . . . . . . . . . . . . . 7
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
-
-1. Introduction
-
- SCRAM [RFC5802] is a password based SASL [RFC4422] authentication
- mechanism that provides (among other things) mutual authentication
- and binding to an external security layer such as TLS.
-
- Two-factor authentication (2FA) is a way to add additional security
- to an authentication exchange. The first "factor" is a password.
- The second "factor" is a verification code retrieved from an
- application on a mobile device or computer. 2FA is conceptually
- similar to a security token device that banks in some countries
- require for online banking. Other names for 2FA systems include OTP
- (one-time password) and TOTP (Time-based One-time Password algorithm,
- such as [RFC6238]).
-
- This specification describes an extension to SCRAM to provide 2
- factor authentication. SCRAM already relies on passwords for
- authentication. This document specifies how second "factors" can be
- incorporated into SCRAM authentication. It also includes a separate
- (but frequently used together with the 2 factor authentication)
- extension for quick reauthentication.
-
-
-
-
-
-
-
-Melnikov Expires 29 July 2022 [Page 2]
-
-Internet-Draft SCRAM 2FA extensions January 2022
-
-
-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].
-
- Formal syntax is defined by [RFC5234] including the core rules
- defined in Appendix B of [RFC5234].
-
- Example lines prefaced by "C:" are sent by the client and ones
- prefaced by "S:" by the server. If a single "C:" or "S:" label
- applies to multiple lines, then the line breaks between those lines
- are for editorial clarity only, and are not part of the actual
- protocol exchange.
-
-2.1. Terminology
-
- This document uses several terms defined in [RFC4949] ("Internet
- Security Glossary") including the following: authentication,
- authentication exchange, authentication information, brute force,
- challenge-response, cryptographic hash function, dictionary attack,
- eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,
- one-way encryption function, password, replay attack and salt.
- Readers not familiar with these terms should use that glossary as a
- reference. Other terms defined in [RFC5802] are also used in this
- document.
-
-2.2. Notation
-
- This document reuses notation defined in SCRAM.
-
-3. SCRAM Extension for 2FA
-
- This extension doesn't add any extra roundtrips to SCRAM
- authentication. SCRAM was designed to be extensible, so it allows
- for optional and mandatory attributes, which covered by MAC codes.
- Second "factors" are conveyed in the second message ("client-final-
- message-without-proof" ABNF production) sent from the client to the
- server.
-
- This extension doesn't change how the client authenticates the
- server.
-
- The server authenticates the client after receiving the second
- message as described in Section 3 of [RFC5802] If the client included
- "type" and "second-factor" attributes defined in this document (see
- Section 5) and the server supports the specified second factor type,
- the server verifies content of the "second-factor" according to the
-
-
-
-Melnikov Expires 29 July 2022 [Page 3]
-
-Internet-Draft SCRAM 2FA extensions January 2022
-
-
- "type". If the second factor verification fails, the server MUST
- fail authentication and SHOULD return either "replayed-second-factor"
- or "invalid-second-factor" error in the "e" attribute. [[It would be
- possible to make the extra attributes mandatory by using SCRAM's
- "m=", but the text above doesn't do that. This is one of open issues
- to resolve.]]
-
-4. SCRAM Extension for reauthentication
-
- This reauthentication extension to SCRAM allows the server to return
- a token that can be used for quick reauthentication and bypasses 2
- factor authentication prompt to the user. The reauthentication token
- is randomly generated value. The reauthentication token is returned
- in the "o" attribute that is appended to the end of the "server-
- final-message".
-
- [[Note: it would be possible to extend SCRAM itself to do
- reauthentication, by including an earlier received reauthentication
- token in the "client-first-message" of a subsequent SCRAM
- authentication. This will also turn off the server checking for 2
- factor authentication information, unless the reauthentication
- attempt is rejected by the server. In the meantime, this document
- presents a couple of other alternatives on how to use other SASL
- mechanisms with the reauthentication token.]]
-
- When the CLIENT-KEY/CLIENT-KEY-PLUS mechanism (see draft-cridland-
- kitten-clientkey) is used for the reauthentication after a successful
- SCRAM authentication, the reauthentication token is the Client Secret
- Key. [[Need to also somehow convey token expiration?]]
-
- When the HT-* mechanism (see draft-schmaus-kitten-sasl-ht) is used
- for the reauthentication after a successful SCRAM authentication, the
- reauthentication token is the draft-schmaus-kitten-sasl-ht token.
- [[Note that the HT hash should probably match the SCRAM hash used.]]
-
-5. Formal Syntax
-
- This document defines the following new SCRAM attributes:
-
- * t: This attribute specifies the type of second factor. [[Create
- IANA registry for these?]] This document defines one type: "totp".
- If this attribute is specified, the "f" attribute MUST also be
- specified.
-
- * f: This attribute specifies the value of the second factor. For
- "t=totp" it is 6 digit decimal number. [[Use 8 digits per Rick
- van Rein?]] This attribute MUST be ignored unless the "t"
- attribute is also specified.
-
-
-
-Melnikov Expires 29 July 2022 [Page 4]
-
-Internet-Draft SCRAM 2FA extensions January 2022
-
-
- * o: This attribute specifies the base64-encoded value of the
- reauthentication token.
-
- The following syntax specification uses the Augmented Backus-Naur
- Form (ABNF) notation as specified in [RFC5234].
-
- type = "t=" type-value
- ; Complies with "attr-val" syntax.
- type-value = "totp" / value
- ; Type of second factor.
- ; Should be registered with IANA.
- second-factor = "f=" second-factor-value
- ; Complies with "attr-val" syntax.
- second-factor-value = 6DIGIT / value
- ; 6DIGIT when "t=totp"
- server-error-value-ext =
- "replayed-second-factor" /
- "invalid-second-factor" /
- "second-factor-value-missing"
-
- value = <as defined in RFC 5802>
-
-
- reauth-token = "o=" base64
- ;; base64 encoding of reauthentication
- ;; token.
-
-
-6. Use of TOTP with SCRAM
-
- When TOTP is used with SCRAM, the following values for "t" and "f"
- attributes (see Section 5 for their generic syntax) are used:
-
- * t: This attribute specifies the type of second factor. For TOTP
- the value is "totp". If this attribute is specified, the "f"
- attribute MUST also be specified.
-
- * f: This attribute specifies the value of the second factor. For
- "t=totp" it is 6 digit decimal number. This attribute MUST be
- ignored unless the "t" attribute is also specified.
-
- A TOTP URI is specified with the following ABNF:
-
-
-
-
-
-
-
-
-
-Melnikov Expires 29 July 2022 [Page 5]
-
-Internet-Draft SCRAM 2FA extensions January 2022
-
-
- totp-uri = "otpauth" "://" "totp/" label "?secret=" secret
- "&issuer=" issuer
- label = issuer (":" / "%3A") identity
- identity = 1*CHAR ; URI-encoded SASL identity
- secret = 40 * HEXCHAR ; Base32 (hex) encoded secret with no padding.
- issuer = 1*CHAR ; Issuer name.
-
-
-7. Example
-
- The following example extends the example from Section 5 of [RFC5802]
- to demonstrate use of TOTP:
-
- C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
- S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
- i=4096
- C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
- t=totp,f=776804,p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
- S: v=lz59pqV8S7suAoZWja4dJRkFsKQ=
-
-
- Please note that TOTP extension described in this document works in
- the same way with SCRAM-SHA-256/SCRAM-SHA-256-PLUS, SCRAM-SHA-512/
- SCRAM-SHA-512-PLUS or any other SCRAM variants that use other hash
- functions.
-
-8. Open Issues
-
- Simon Josefsson: should this be a new SASL mechanism name, e.g.
- CROTP-SHA-256?
-
- Simon Josefsson: cookie option for fast reauthentication? Alexey:
- can do or just used CLIENT-KEY (draft-cridland-kitten-clientkey)?
-
- Rick van Rein: specify a HOTP variant as well?
-
- Rick van Rein: use TOTP with 6 or 8 digits? Register both variants?
-
-9. Security Considerations
-
- Unless an external security layer (such as TLS) is also used, the OTP
- value 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.
-
- TBD
-
-
-
-
-
-Melnikov Expires 29 July 2022 [Page 6]
-
-Internet-Draft SCRAM 2FA extensions January 2022
-
-
-10. IANA Considerations
-
- IANA is requested to update the definition of the SASL family SCRAM
- in the SASL Mechanism registry established by [RFC4422] to also point
- to this document.
-
- IANA is also requested to create a new subregistry of "SASL
- mechanism" for registering second factor schemes used in the "t"
- attribute as specified in this document.
-
- The registration template is as follows:
-
-
- SCRAM Second Factor Scheme Name:
- Pointer to specification text:
- Notes (optional):
-
-
- The registration procedure for the above subregistry is Expert
- Review.
-
- IANA is requested to register a new value in the subregistry defined
- above:
-
-
- SCRAM Second Factor Scheme Name: TOTP
- Pointer to specification text: [[ this document ]]
- Notes (optional): (none)
-
-
-11. Acknowledgements
-
- Thank you to Stephen Farrell for motivating creation of this document
- and to Dave Cridland for describing how TOTP can be used with XMPP in
- XEP-0400. Thank you to Rick van Rein and Simon Josefsson for
- comments and corrections, but all final errors in this document
- remain mine.
-
-12. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119,
- DOI 10.17487/RFC2119, March 1997,
- <https://www.rfc-editor.org/info/rfc2119>.
-
-
-
-
-
-
-
-Melnikov Expires 29 July 2022 [Page 7]
-
-Internet-Draft SCRAM 2FA extensions January 2022
-
-
- [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
- Authentication and Security Layer (SASL)", RFC 4422,
- DOI 10.17487/RFC4422, June 2006,
- <https://www.rfc-editor.org/info/rfc4422>.
-
- [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
- FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
- <https://www.rfc-editor.org/info/rfc4949>.
-
- [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", STD 68, RFC 5234,
- DOI 10.17487/RFC5234, January 2008,
- <https://www.rfc-editor.org/info/rfc5234>.
-
- [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
- "Salted Challenge Response Authentication Mechanism
- (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
- DOI 10.17487/RFC5802, July 2010,
- <https://www.rfc-editor.org/info/rfc5802>.
-
- [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP:
- Time-Based One-Time Password Algorithm", RFC 6238,
- DOI 10.17487/RFC6238, May 2011,
- <https://www.rfc-editor.org/info/rfc6238>.
-
-Author's Address
-
- Alexey Melnikov
- Isode Ltd
-
- Email: Ale...@is...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov Expires 29 July 2022 [Page 8]
Added: trunk/docs/specs/draft-ietf-kitten-scram-2fa-02.txt
===================================================================
--- trunk/docs/specs/draft-ietf-kitten-scram-2fa-02.txt (rev 0)
+++ trunk/docs/specs/draft-ietf-kitten-scram-2fa-02.txt 2023-01-16 20:46:51 UTC (rev 1586)
@@ -0,0 +1,672 @@
+
+
+
+
+Network Working Group A. Melnikov
+Internet-Draft Isode Ltd
+Intended status: Standards Track 13 January 2023
+Expires: 17 July 2023
+
+
+ Extensions to Salted Challenge Response (SCRAM) for 2 factor
+ authentication
+ draft-ietf-kitten-scram-2fa-02
+
+Abstract
+
+ This specification describes an extension to family of Simple
+ Authentication and Security Layer (SASL; RFC 4422) authentication
+ mechanisms called the Salted Challenge Response Authentication
+ Mechanism (SCRAM), which provides support for 2 factor
+ authentication. It also includes a separate extension for quick
+ reauthentication.
+
+ This specification also gives an example of how TOTP (RFC 6238) can
+ be used as the second factor.
+
+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 https://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 17 July 2023.
+
+Copyright Notice
+
+ Copyright (c) 2023 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 (https://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
+
+
+
+Melnikov Expires 17 July 2023 [Page 1]
+
+Internet-Draft SCRAM 2FA extensions January 2023
+
+
+ and restrictions with respect to this document. Code Components
+ extracted from this document must include Revised BSD License text as
+ described in Section 4.e of the Trust Legal Provisions and are
+ provided without warranty as described in the Revised BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
+ 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. SCRAM Extension for 2FA . . . . . . . . . . . . . . . . . . . 3
+ 4. SCRAM Extension for reauthentication . . . . . . . . . . . . 4
+ 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 6. Use of TOTP with SCRAM . . . . . . . . . . . . . . . . . . . 5
+ 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 8. Use of FIDO CTAP1/U2F with SCRAM . . . . . . . . . . . . . . 6
+ 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
+ 13. Normative References . . . . . . . . . . . . . . . . . . . . 10
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
+
+1. Introduction
+
+ SCRAM [RFC5802] is a password based SASL [RFC4422] authentication
+ mechanism that provides (among other things) mutual authentication
+ and binding to an external security layer such as TLS.
+
+ Two-factor authentication (2FA) is a way to add additional security
+ to an authentication exchange. The first "factor" is a password.
+ The second "factor" is a verification code retrieved from an
+ application on a mobile device or computer. 2FA is conceptually
+ similar to a security token device that banks in some countries
+ require for online banking. Some examples of 2FA systems are OTP
+ (one-time password) and TOTP (Time-based One-time Password algorithm,
+ such as [RFC6238]).
+
+ This specification describes an extension to SCRAM to provide 2
+ factor authentication. SCRAM already relies on passwords for
+ authentication. This document specifies how second "factors" can be
+ incorporated into SCRAM authentication. It also includes a separate
+ (but frequently used together with the 2 factor authentication)
+ extension for quick reauthentication.
+
+
+
+
+
+
+Melnikov Expires 17 July 2023 [Page 2]
+
+Internet-Draft SCRAM 2FA extensions January 2023
+
+
+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].
+
+ Formal syntax is defined by [RFC5234] including the core rules
+ defined in Appendix B of [RFC5234].
+
+ Example lines prefaced by "C:" are sent by the client and ones
+ prefaced by "S:" by the server. If a single "C:" or "S:" label
+ applies to multiple lines, then the line breaks between those lines
+ are for editorial clarity only, and are not part of the actual
+ protocol exchange.
+
+2.1. Terminology
+
+ This document uses several terms defined in [RFC4949] ("Internet
+ Security Glossary") including the following: authentication,
+ authentication exchange, authentication information, brute force,
+ challenge-response, cryptographic hash function, dictionary attack,
+ eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,
+ one-way encryption function, password, replay attack and salt.
+ Readers not familiar with these terms should use that glossary as a
+ reference. Other terms defined in [RFC5802] are also used in this
+ document.
+
+2.2. Notation
+
+ This document reuses notation defined in SCRAM.
+
+3. SCRAM Extension for 2FA
+
+ This extension doesn't add any extra roundtrips to SCRAM
+ authentication. SCRAM was designed to be extensible, so it allows
+ for optional and mandatory attributes, which covered by MAC codes.
+ Second "factors" are conveyed in the second message ("client-final-
+ message-without-proof" ABNF production) sent from the client to the
+ server.
+
+ This extension doesn't change how the client authenticates the
+ server. This extension also doesn't cover enrollment with a 2FA
+ system, such enrollment happends out-of-band.
+
+ The server authenticates the client after receiving the second
+ message as described in Section 3 of [RFC5802] If the client included
+ "type" and "second-factor" attributes defined in this document (see
+ Section 5) and the server supports the specified second factor type,
+
+
+
+Melnikov Expires 17 July 2023 [Page 3]
+
+Internet-Draft SCRAM 2FA extensions January 2023
+
+
+ the server verifies content of the "second-factor" according to the
+ "type". If the second factor verification fails, the server MUST
+ fail authentication and SHOULD return either "replayed-second-factor"
+ or "invalid-second-factor" error in the "e" attribute. [[It would be
+ possible to make the extra attributes mandatory by using SCRAM's
+ "m=", but the text above doesn't do that. This is one of open issues
+ to resolve.]]
+
+4. SCRAM Extension for reauthentication
+
+ This reauthentication extension to SCRAM allows the server to return
+ a token that can be used for quick reauthentication and bypasses 2
+ factor authentication prompt to the user. The reauthentication token
+ is a randomly generated value.The reauthentication token is returned
+ in the "o" attribute that is appended to the end of the "server-
+ final-message".
+
+ [[Note: it would be possible to extend SCRAM itself to do
+ reauthentication, by including an earlier received reauthentication
+ token in the "client-first-message" of a subsequent SCRAM
+ authentication. This will also turn off the server checking for 2
+ factor authentication information, unless the reauthentication
+ attempt is rejected by the server. In the meantime, this document
+ presents a couple of other alternatives on how to use other SASL
+ mechanisms with the reauthentication token.]]
+
+ When the HT-* mechanism [draft-schmaus-kitten-sasl-ht] is used for
+ the reauthentication after a successful SCRAM authentication, the
+ reauthentication token is the SASL-HT token (see
+ [draft-schmaus-kitten-sasl-ht]). [[Note that the HT hash should
+ probably match the SCRAM hash used or "be better".]]
+
+ When the CLIENT-KEY/CLIENT-KEY-PLUS mechanism (see draft-cridland-
+ kitten-clientkey) is used for the reauthentication after a successful
+ SCRAM authentication, the reauthentication token is the Client Secret
+ Key. [[Need to also somehow convey token expiration?]]
+
+5. Formal Syntax
+
+ This document defines the following new SCRAM attributes:
+
+ * t: This attribute specifies the type of second factor. This
+ document defines two possible types: "totp" (see Section 6) and
+ "ctap1" (see Section 8). If this attribute is specified, the "f"
+ attribute MUST also be specified.
+
+
+
+
+
+
+Melnikov Expires 17 July 2023 [Page 4]
+
+Internet-Draft SCRAM 2FA extensions January 2023
+
+
+ * f: This attribute specifies the value of the second factor. For
+ "t=totp" it is 6 digit decimal number. [[Use 8 digits per Rick
+ van Rein?]] This attribute MUST be ignored unless the "t"
+ attribute is also specified.
+
+ * l: This attribute is used by some second factors (e.g. CTAP1) to
+ specify the challenge returned by the SCRAM server.
+
+ * o: This attribute specifies the base64-encoded value of the
+ reauthentication token.
+
+ The following syntax specification uses the Augmented Backus-Naur
+ Form (ABNF) notation as specified in [RFC5234].
+
+ type = "t=" type-value
+ ; Complies with "attr-val" syntax.
+ ; Returned in client-final-message.
+ type-value = "totp" / "ctap1" / value
+ ; Type of second factor.
+ ; Should be registered with IANA.
+ second-factor = "f=" second-factor-value
+ ; Complies with "attr-val" syntax.
+ ; Returned in client-final-message.
+ second-factor-value = 6DIGIT / value
+ ; 6DIGIT when "t=totp".
+ server-challenge = "l=" base64
+ ; Data returned by SCRAM server in server-first-message
+ ; to be used for construction of second-factor-value.
+
+ server-error-value-ext =
+ "replayed-second-factor" /
+ "invalid-second-factor" /
+ "second-factor-value-missing"
+
+ value = <as defined in RFC 5802>
+
+
+ reauth-token = "o=" base64
+ ; base64 encoding of reauthentication
+ ; token.
+ ; Returned in server-final-message.
+
+
+6. Use of TOTP with SCRAM
+
+ When TOTP is used with SCRAM, the following values for "t" and "f"
+ attributes (see Section 5 for their generic syntax) are used:
+
+
+
+
+Melnikov Expires 17 July 2023 [Page 5]
+
+Internet-Draft SCRAM 2FA extensions January 2023
+
+
+ * t: This attribute specifies the type of second factor. For TOTP
+ the value is "totp". If this attribute is specified, the "f"
+ attribute MUST also be specified.
+
+ * f: This attribute specifies the value of the second factor. For
+ "t=totp" it is 6 digit decimal number. This attribute MUST be
+ ignored unless the "t" attribute is also specified.
+
+ A TOTP URI is specified with the following ABNF:
+
+ totp-uri = "otpauth" "://" "totp/" label "?secret=" secret
+ "&issuer=" issuer
+ label = issuer (":" / "%3A") identity
+ identity = 1*CHAR ; URI-encoded SASL identity
+ secret = 40 * HEXCHAR ; Base32 (hex) encoded secret with no padding.
+ issuer = 1*CHAR ; Issuer name.
+
+
+7. Example
+
+ The following example extends the example from Section 5 of [RFC5802]
+ to demonstrate use of TOTP:
+
+ C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
+ S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
+ i=4096
+ C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
+ t=totp,f=776804,p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
+ S: v=lz59pqV8S7suAoZWja4dJRkFsKQ=
+
+
+ Please note that TOTP extension described in this document works in
+ the same way with SCRAM-SHA-256/SCRAM-SHA-256-PLUS, SCRAM-SHA-512/
+ SCRAM-SHA-512-PLUS or any other SCRAM variants that use other hash
+ functions.
+
+8. Use of FIDO CTAP1/U2F with SCRAM
+
+ Note that this section describes steps to achieve Client-to-
+ Authenticator Protocols v1 (CTAP1)/U2F 2FA in terms of CTAP2 API.
+
+ When FIDO CTAP1/U2F is used with SCRAM, the following values for "t",
+ "l" and "f" attributes (see Section 5 for their generic syntax) are
+ used:
+
+ * t: This attribute specifies the type of second factor. For FIDO
+ CTAP1/U2F the value is "ctap1". If this attribute is specified,
+ the "f" attribute MUST also be specified.
+
+
+
+Melnikov Expires 17 July 2023 [Page 6]
+
+Internet-Draft SCRAM 2FA extensions January 2023
+
+
+ * l: base64-encoded challenge as returned by SCRAM server.
+
+ * f: This attribute specifies the value of the second factor. For
+ "t=ctap1" it is the CBOR-serialized value of
+ authenticatorGetAssertionResponse map described below. This
+ attribute MUST be ignored unless the "t" attribute is also
+ specified.
+
+ SCRAM client sends U2F_AUTHENTICATE command formatted as specified in
+ [FIDO-U2F-Raw-Message-Formats] to the authenticator (e.g. a USB or
+ NFC device).
+
+ The "P1" framing parameter to U2F_AUTHENTICATE is a single octet
+ parameter defined as follows:
+
+ * If "up" is set to false, set it to 0x08 (dont-enforce-user-
+ presence-and-sign).
+
+ * For USB, set it to 0x07 (check-only). This should prevent call
+ getting blocked on waiting for user input. If response returns
+ success, then call again setting the enforce-user-presence-and-
+ sign.
+
+ * For NFC, set it to 0x03 (enforce-user-presence-and-sign). The tap
+ has already provided the presence and won't block.
+
+ The "P2" framing parameter to U2F_AUTHENTICATE is a single octet that
+ always has the value 0x00.
+
+ The "request-data" framing parameter (u2fAuthenticateRequest) to
+ U2F_AUTHENTICATE is constructed as follows:
+
+ * The clientData structure (see Section 5.8.1 of [W3C_webauthn_3])
+ is filled in as follows:
+
+ - The "type" field has value "webauthn.get".
+
+ - The "challenge" field contains the base64url encoding of the
+ challenge provided by the Relying Party. This is the value of
+ the "l" attribute described above. (Note, possibly need to
+ base64-decode and base64url-encode.)
+
+ - The "origin" field contains the origin of the SCRAM client in
+ the format specified in [RFC6454], for example
+ "smtp://client.example.net:587".
+
+ - Other fields are specified in Section 5.8.1 of
+ [W3C_webauthn_3].
+
+
+
+Melnikov Expires 17 July 2023 [Page 7]
+
+Internet-Draft SCRAM 2FA extensions January 2023
+
+
+ * Use clientDataHash parameter of [CTAP2] request as CTAP1/U2F
+ challenge parameter (32 bytes).
+
+ * Let rpIdHash be a byte string of size 32 initialized with SHA-256
+ hash of rp.id parameter as CTAP1/U2F application parameter (32
+ bytes). (The rp.id parameter is the hostname of the SCRAM
+ server.)
+
+ * Let credentialId is the byte string initialized with the id for
+ this PublicKeyCredentialDescriptor.
+
+ * Let keyHandleLength be a byte initialized with length of
+ credentialId byte string.
+
+ * Let u2fAuthenticateRequest be a byte string with the following
+ structure:
+
+ +===================+=============+=================================+
+ | Length (in | Description | Value |
+ | bytes) | | |
+ +===================+=============+=================================+
+ | 32 | Challenge | Initialized with clientDataHash |
+ | | parameter | parameter bytes. |
+ +-------------------+-------------+---------------------------------+
+ | 32 | Application | Initialized with rpIdHash |
+ | | parameter | bytes. |
+ +-------------------+-------------+---------------------------------+
+ | 1 | Key handle | Initialized with |
+ | | length | keyHandleLength's value. |
+ +-------------------+-------------+---------------------------------+
+ | keyHandleLength | Key handle | Initialized with credentialId |
+ | | | bytes. |
+ +-------------------+-------------+---------------------------------+
+
+ Table 1
+
+ Generate authenticatorData from the U2F authentication response
+ message received from the authenticator:
+
+ * Copy bits 0 (the UP bit) and bit 1 from the CTAP2/U2F response
+ user presence byte to bits 0 and 1 of the CTAP2 flags,
+ respectively. Set all other bits of flags to zero. Note: bit
+ zero is the least significant bit. See also Authenticator Data
+ section of [W3C_webauthn_3].
+
+ * Let signCount be a 4-byte unsigned integer initialized with CTAP1/
+ U2F response counter field.
+
+
+
+
+Melnikov Expires 17 July 2023 [Page 8]
+
+Internet-Draft SCRAM 2FA extensions January 2023
+
+
+ Let authenticatorData is a byte string of following structure:
+
+ +===================+============================+==================+
+ | Length (in bytes) | Description | Value |
+ +===================+============================+==================+
+ | 32 | SHA-256 hash of | Initialized with |
+ | | the rp.id. | rpIdHash bytes. |
+ +-------------------+----------------------------+------------------+
+ | 1 | Flags | Initialized with |
+ | | | flags' value. |
+ +-------------------+----------------------------+------------------+
+ | 4 | Signature counter | Initialized with |
+ | | (signCount) | signCount bytes. |
+ +-------------------+----------------------------+------------------+
+
+ Table 2
+
+ Let authenticatorGetAssertionResponse be a CBOR map with the
+ following keys whose values are as follows:
+
+ * Set 0x01 with the credential from allowList that whose response
+ succeeded.
+
+ * Set 0x02 with authenticatorData bytes.
+
+ * Set 0x03 with signature field from CTAP1/U2F authentication
+ response message. Note: An ASN.1-encoded ECDSA signature value
+ ranges over 8-72 bytes in length.
+
+9. Open Issues
+
+ Simon Josefsson: should this be a new SASL mechanism name, e.g.
+ CROTP-SHA-256?
+
+ Should we pick between TOTP and FIDO2 (CTAP1)?
+
+ Rick van Rein: specify a HOTP variant as well?
+
+ Rick van Rein: use TOTP with 6 or 8 digits? Register both variants?
+
+10. Security Considerations
+
+ Unless an external security layer (such as TLS) is also used, the OTP
+ value 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.
+
+ TBD
+
+
+
+Melnikov Expires 17 July 2023 [Page 9]
+
+Internet-Draft SCRAM 2FA extensions January 2023
+
+
+11. IANA Considerations
+
+ IANA is requested to update the definition of the SASL family SCRAM
+ in the SASL Mechanism registry established by [RFC4422] to also point
+ to this document.
+
+ IANA is also requested to create a new subregistry of "SASL
+ mechanism" for registering second factor schemes used in the "t"
+ attribute as specified in this document.
+
+ The registration template is as follows:
+
+
+ SCRAM Second Factor Scheme Name:
+ Pointer to specification text:
+ Notes (optional):
+
+
+ The registration procedure for the above subregistry is Expert
+ Review.
+
+ IANA is requested to register a new value in the subregistry defined
+ above:
+
+
+ SCRAM Second Factor Scheme Name: TOTP
+ Pointer to specification text: [[ this document ]]
+ Notes (optional): (none)
+
+
+12. Acknowledgements
+
+ Thank you to Stephen Farrell for motivating creation of this document
+ and to Dave Cridland for describing how TOTP can be used with XMPP in
+ XEP-0400. Thank you to Rick van Rein, Simon Josefsson and Ludovic
+ Bocquet for comments and corrections, but all final errors in this
+ document remain mine.
+
+13. Normative References
+
+ [CTAP2] Bradley, J., Hodges, J., Jones, M., Kumar, A., Lindemann,
+ R., and J. Verrept, "Client to Authenticator Prot...
[truncated message content] |
