< draft-ietf-kitten-scram-2fa-00.txt		draft-ietf-kitten-scram-2fa-01.txt >
	Network Working Group A. Melnikov		Network Working Group A. Melnikov
	Internet-Draft Isode Ltd		Internet-Draft Isode Ltd
	Intended status: Standards Track 12 January 2022		Intended status: Standards Track 25 January 2022
	Expires: 16 July 2022		Expires: 29 July 2022
	Extensions to Salted Challenge Response (SCRAM) for 2 factor		Extensions to Salted Challenge Response (SCRAM) for 2 factor
	authentication		authentication
	draft-ietf-kitten-scram-2fa-00		draft-ietf-kitten-scram-2fa-01
	Abstract		Abstract
	This specification describes an extension to family of Simple		This specification describes an extension to family of Simple
	Authentication and Security Layer (SASL; RFC 4422) authentication		Authentication and Security Layer (SASL; RFC 4422) authentication
	mechanisms called the Salted Challenge Response Authentication		mechanisms called the Salted Challenge Response Authentication
	Mechanism (SCRAM), which provides support for 2 factor		Mechanism (SCRAM), which provides support for 2 factor
	authentication.		authentication. It also includes a separate extension for quick
			reauthentication.
	This specification also gives an example of how TOTP (RFC 6238) can		This specification also gives an example of how TOTP (RFC 6238) can
	be used as the second factor.		be used as the second factor.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 16 July 2022.		This Internet-Draft will expire on 29 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions Used in This Document . . . . . . . . . . . . . . 2		2. Conventions Used in This Document . . . . . . . . . . . . . . 3
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. SCRAM Extension for 2FA . . . . . . . . . . . . . . . . . . . 3		3. SCRAM Extension for 2FA . . . . . . . . . . . . . . . . . . . 3
	4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 4		4. SCRAM Extension for reauthentication . . . . . . . . . . . . 4
	5. Use of TOTP with SCRAM . . . . . . . . . . . . . . . . . . . 4		5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 4
	6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		6. Use of TOTP with SCRAM . . . . . . . . . . . . . . . . . . . 5
	7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 5		7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 5		8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 6
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	11. Normative References . . . . . . . . . . . . . . . . . . . . 6		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7		12. Normative References . . . . . . . . . . . . . . . . . . . . 7
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	SCRAM [RFC5802] is a password based SASL [RFC4422] authentication		SCRAM [RFC5802] is a password based SASL [RFC4422] authentication
	mechanism that provides (among other things) mutual authentication		mechanism that provides (among other things) mutual authentication
	and binding to an external security layer such as TLS.		and binding to an external security layer such as TLS.
	Two-factor authentication (2FA) is a way to add additional security		Two-factor authentication (2FA) is a way to add additional security
	to an authentication exchange. The first "factor" is a password.		to an authentication exchange. The first "factor" is a password.
	The second "factor" is a verification code retrieved from an		The second "factor" is a verification code retrieved from an
	application on a mobile device or computer. 2FA is conceptually		application on a mobile device or computer. 2FA is conceptually
	similar to a security token device that banks in some countries		similar to a security token device that banks in some countries
	require for online banking. Other names for 2FA systems include OTP		require for online banking. Other names for 2FA systems include OTP
	(one-time password) and TOTP (Time-based One-time Password algorithm,		(one-time password) and TOTP (Time-based One-time Password algorithm,
	such as [RFC6238]).		such as [RFC6238]).
	This specification describes an extension to SCRAM to provide 2		This specification describes an extension to SCRAM to provide 2
	factor authentication. SCRAM already relies on passwords for		factor authentication. SCRAM already relies on passwords for
	authentication. This document specifies how second "factors" can be		authentication. This document specifies how second "factors" can be
	incorporated into SCRAM authentication.		incorporated into SCRAM authentication. It also includes a separate
			(but frequently used together with the 2 factor authentication)
			extension for quick reauthentication.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Formal syntax is defined by [RFC5234] including the core rules		Formal syntax is defined by [RFC5234] including the core rules
	defined in Appendix B of [RFC5234].		defined in Appendix B of [RFC5234].
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 51 ¶
	Second "factors" are conveyed in the second message ("client-final-		Second "factors" are conveyed in the second message ("client-final-
	message-without-proof" ABNF production) sent from the client to the		message-without-proof" ABNF production) sent from the client to the
	server.		server.
	This extension doesn't change how the client authenticates the		This extension doesn't change how the client authenticates the
	server.		server.
	The server authenticates the client after receiving the second		The server authenticates the client after receiving the second
	message as described in Section 3 of [RFC5802] If the client included		message as described in Section 3 of [RFC5802] If the client included
	"type" and "second-factor" attributes defined in this document (see		"type" and "second-factor" attributes defined in this document (see
	Section 4) and the server supports the specified second factor type,		Section 5) and the server supports the specified second factor type,
	the server verifies content of the "second-factor" according to the		the server verifies content of the "second-factor" according to the
	"type". If the second factor verification fails, the server MUST		"type". If the second factor verification fails, the server MUST
	fail authentication and SHOULD return either "replayed-second-factor"		fail authentication and SHOULD return either "replayed-second-factor"
	or "invalid-second-factor" error in the "e" attribute. [[It would be		or "invalid-second-factor" error in the "e" attribute. [[It would be
	possible to make the extra attributes mandatory by using SCRAM's		possible to make the extra attributes mandatory by using SCRAM's
	"m=", but the text above doesn't do that.]]		"m=", but the text above doesn't do that. This is one of open issues
			to resolve.]]
	4. Formal Syntax		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:		This document defines the following new SCRAM attributes:
	* t: This attribute specifies the type of second factor. [[Create		* t: This attribute specifies the type of second factor. [[Create
	IANA registry for these?]] This document defines one type: "totp".		IANA registry for these?]] This document defines one type: "totp".
	If this attribute is specified, the "f" attribute MUST also be		If this attribute is specified, the "f" attribute MUST also be
	specified.		specified.
	* f: This attribute specifies the value of the second factor. For		* f: This attribute specifies the value of the second factor. For
	"t=totp" it is 6 digit decimal number. [[Use 8 digits per Rick		"t=totp" it is 6 digit decimal number. [[Use 8 digits per Rick
	van Rein?]] This attribute MUST be ignored unless the "t"		van Rein?]] This attribute MUST be ignored unless the "t"
	attribute is also specified.		attribute is also specified.
			* o: This attribute specifies the base64-encoded value of the
			reauthentication token.
	The following syntax specification uses the Augmented Backus-Naur		The following syntax specification uses the Augmented Backus-Naur
	Form (ABNF) notation as specified in [RFC5234].		Form (ABNF) notation as specified in [RFC5234].
	type = "t=" type-value		type = "t=" type-value
	; Complies with "attr-val" syntax.		; Complies with "attr-val" syntax.
	type-value = "totp" / value		type-value = "totp" / value
	; Type of second factor.		; Type of second factor.
	; Should be registered with IANA.		; Should be registered with IANA.
	second-factor = "f=" second-factor-value		second-factor = "f=" second-factor-value
	; Complies with "attr-val" syntax.		; Complies with "attr-val" syntax.
	second-factor-value = 6DIGIT / value		second-factor-value = 6DIGIT / value
	; 6DIGIT when "t=totp"		; 6DIGIT when "t=totp"
	server-error-value-ext =		server-error-value-ext =
	"replayed-second-factor" /		"replayed-second-factor" /
	"invalid-second-factor" /		"invalid-second-factor" /
	"second-factor-value-missing"		"second-factor-value-missing"
	value = <as defined in RFC 5802>		value = <as defined in RFC 5802>
	5. Use of TOTP with SCRAM		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"		When TOTP is used with SCRAM, the following values for "t" and "f"
	attributes (see Section 4 for their generic syntax) are used:		attributes (see Section 5 for their generic syntax) are used:
	* t: This attribute specifies the type of second factor. For TOTP		* t: This attribute specifies the type of second factor. For TOTP
	the value is "totp". If this attribute is specified, the "f"		the value is "totp". If this attribute is specified, the "f"
	attribute MUST also be specified.		attribute MUST also be specified.
	* f: This attribute specifies the value of the second factor. For		* f: This attribute specifies the value of the second factor. For
	"t=totp" it is 6 digit decimal number. This attribute MUST be		"t=totp" it is 6 digit decimal number. This attribute MUST be
	ignored unless the "t" attribute is also specified.		ignored unless the "t" attribute is also specified.
	A TOTP URI is specified with the following ABNF:		A TOTP URI is specified with the following ABNF:
	totp-uri = "otpauth" "://" "totp/" label "?secret=" secret		totp-uri = "otpauth" "://" "totp/" label "?secret=" secret
	"&issuer=" issuer		"&issuer=" issuer
	label = issuer (":" / "%3A") identity		label = issuer (":" / "%3A") identity
	identity = 1*CHAR ; URI-encoded SASL identity		identity = 1*CHAR ; URI-encoded SASL identity
	secret = 40 * HEXCHAR ; Base32 (hex) encoded secret with no padding.		secret = 40 * HEXCHAR ; Base32 (hex) encoded secret with no padding.
	issuer = 1*CHAR ; Issuer name.		issuer = 1*CHAR ; Issuer name.
	6. Example		7. Example
	The following example extends the example from Section 5 of [RFC5802]		The following example extends the example from Section 5 of [RFC5802]
	to demonstrate use of TOTP:		to demonstrate use of TOTP:
	C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL		C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
	S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,		S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
	i=4096		i=4096
	C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,		C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
	t=totp,f=776804,p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=		t=totp,f=776804,p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
	S: v=lz59pqV8S7suAoZWja4dJRkFsKQ=		S: v=lz59pqV8S7suAoZWja4dJRkFsKQ=
	Please note that TOTP extension described in this document works in		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/		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		SCRAM-SHA-512-PLUS or any other SCRAM variants that use other hash
	functions.		functions.
	7. Open Issues		8. Open Issues
	Simon Josefsson: should this be a new SASL mechanism name, e.g.		Simon Josefsson: should this be a new SASL mechanism name, e.g.
	CROTP-SHA-256?		CROTP-SHA-256?
	Simon Josefsson: cookie option for fast reauthentication? Alexey:		Simon Josefsson: cookie option for fast reauthentication? Alexey:
	can do or just used CLIENT-KEY (draft-cridland-kitten-clientkey)?		can do or just used CLIENT-KEY (draft-cridland-kitten-clientkey)?
	Rick van Rein: specify a HOTP variant as well?		Rick van Rein: specify a HOTP variant as well?
	Rick van Rein: use TOTP with 6 or 8 digits? Register both variants?		Rick van Rein: use TOTP with 6 or 8 digits? Register both variants?
	8. Security Considerations		9. Security Considerations
	Unless an external security layer (such as TLS) is also used, the OTP		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		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		server, which allows an attacker to read the OTP value and perform a
	race with the server to validate the OTP.		race with the server to validate the OTP.
	TBD		TBD
	9. IANA Considerations		10. IANA Considerations
	IANA is requested to update the definition of the SASL family SCRAM		IANA is requested to update the definition of the SASL family SCRAM
	in the SASL Mechanism registry established by [RFC4422] to also point		in the SASL Mechanism registry established by [RFC4422] to also point
	to this document.		to this document.
	IANA is also requested to create a new subregistry of "SASL		IANA is also requested to create a new subregistry of "SASL
	mechanism" for registering second factor schemes used in the "t"		mechanism" for registering second factor schemes used in the "t"
	attribute as specified in this document.		attribute as specified in this document.
	The registration template is as follows:		The registration template is as follows:
	skipping to change at page 6, line 31 ¶		skipping to change at page 7, line 31 ¶
	The registration procedure for the above subregistry is Expert		The registration procedure for the above subregistry is Expert
	Review.		Review.
	IANA is requested to register a new value in the subregistry defined		IANA is requested to register a new value in the subregistry defined
	above:		above:
	SCRAM Second Factor Scheme Name: TOTP		SCRAM Second Factor Scheme Name: TOTP
	Pointer to specification text: [[ this document ]]		Pointer to specification text: [[ this document ]]
	Notes (optional): (none)		Notes (optional): (none)
	10. Acknowledgements		11. Acknowledgements
	Thank you to Stephen Farrell for motivating creation of this document		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		and to Dave Cridland for describing how TOTP can be used with XMPP in
	XEP-400. Thank you to Rick van Rein and Simon Josefsson for comments		XEP-0400. Thank you to Rick van Rein and Simon Josefsson for
	and corrections, but all final errors in this document remain mine.		comments and corrections, but all final errors in this document
			remain mine.
	11. Normative References		12. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple		[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
	Authentication and Security Layer (SASL)", RFC 4422,		Authentication and Security Layer (SASL)", RFC 4422,
	DOI 10.17487/RFC4422, June 2006,		DOI 10.17487/RFC4422, June 2006,
	<https://www.rfc-editor.org/info/rfc4422>.		<https://www.rfc-editor.org/info/rfc4422>.
End of changes. 20 change blocks.
	29 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/