< draft-ietf-tls-tls13-cert-with-extern-psk-04.txt		draft-ietf-tls-tls13-cert-with-extern-psk-05.txt >
	Network Working Group R. Housley		Network Working Group R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Intended status: Experimental December 19, 2019		Intended status: Experimental December 22, 2019
	Expires: June 21, 2020		Expires: June 24, 2020
	TLS 1.3 Extension for Certificate-based Authentication with an External		TLS 1.3 Extension for Certificate-based Authentication with an External
	Pre-Shared Key		Pre-Shared Key
	draft-ietf-tls-tls13-cert-with-extern-psk-04		draft-ietf-tls-tls13-cert-with-extern-psk-05
	Abstract		Abstract
	This document specifies a TLS 1.3 extension that allows a server to		This document specifies a TLS 1.3 extension that allows a server to
	authenticate with a combination of a certificate and an external pre-		authenticate with a combination of a certificate and an external pre-
	shared key (PSK).		shared key (PSK).
	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
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 June 21, 2020.		This Internet-Draft will expire on June 24, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	valid digital signature to demonstrate that it possesses the		valid digital signature to demonstrate that it possesses the
	corresponding private key. Second, the server can be authenticated		corresponding private key. Second, the server can be authenticated
	by demonstrating that it possesses a pre-shared key (PSK) that was		by demonstrating that it possesses a pre-shared key (PSK) that was
	established by a previous handshake. A PSK that is established in		established by a previous handshake. A PSK that is established in
	this fashion is called a resumption PSK. A PSK that is established		this fashion is called a resumption PSK. A PSK that is established
	by any other means is called an external PSK. This document		by any other means is called an external PSK. This document
	specifies a TLS 1.3 extension permitting certificate-based server		specifies a TLS 1.3 extension permitting certificate-based server
	authentication to be combined with an external PSK as an input to the		authentication to be combined with an external PSK as an input to the
	TLS 1.3 key schedule.		TLS 1.3 key schedule.
			Several implementors wanted to gain more experience with this
			specification before producing a standards-track RFC. As a result,
			this specification is being published as an Experimental RFC to
			enable interoperable implementations and gain deployment and
			operational experience.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Motivation and Design Rationale		3. Motivation and Design Rationale
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 34 ¶
	in any other message, then the implementation MUST abort the		in any other message, then the implementation MUST abort the
	handshake with an "illegal_parameter" alert.		handshake with an "illegal_parameter" alert.
	The general extension mechanisms enable clients and servers to		The general extension mechanisms enable clients and servers to
	negotiate the use of specific extensions. Clients request extended		negotiate the use of specific extensions. Clients request extended
	functionality from servers with the extensions field in the		functionality from servers with the extensions field in the
	ClientHello message. If the server responds with a HelloRetryRequest		ClientHello message. If the server responds with a HelloRetryRequest
	message, then the client sends another ClientHello message as		message, then the client sends another ClientHello message as
	described in Section 4.1.2 of [RFC8446], including the same		described in Section 4.1.2 of [RFC8446], including the same
	"tls_cert_with_extern_psk" extension as the original ClientHello		"tls_cert_with_extern_psk" extension as the original ClientHello
	message or aborts the handshake.		message, or aborts the handshake.
	Many server extensions are carried in the EncryptedExtensions		Many server extensions are carried in the EncryptedExtensions
	message; however, the "tls_cert_with_extern_psk" extension is carried		message; however, the "tls_cert_with_extern_psk" extension is carried
	in the ServerHello message. Successful negotiation of the		in the ServerHello message. Successful negotiation of the
	"tls_cert_with_extern_psk" extension affects the key used for		"tls_cert_with_extern_psk" extension affects the key used for
	encryption, so it cannot be carried in the EncryptedExtensions		encryption, so it cannot be carried in the EncryptedExtensions
	message. Therefore, the "tls_cert_with_extern_psk" extension is only		message. Therefore, the "tls_cert_with_extern_psk" extension is only
	present in the ServerHello message if the server recognizes the		present in the ServerHello message if the server recognizes the
	"tls_cert_with_extern_psk" extension and the server possesses one of		"tls_cert_with_extern_psk" extension and the server possesses one of
	the external PSKs offered by the client in the "pre_shared_key"		the external PSKs offered by the client in the "pre_shared_key"
End of changes. 5 change blocks.
	5 lines changed or deleted		11 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/