Federated TLS Authentication
draft-halen-fed-tls-auth-00

Document Type Active Internet-Draft (individual)
Authors Jakob Schlyter  , =?utf-8?q?Stefan_Hal=C3=A9n?= 
Last updated 2020-10-12
Stream (None)
Intended RFC status (None)
Formats plain text html xml pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        J. Schlyter
Internet-Draft                                                  Kirei AB
Intended status: Informational                                  S. Halen
Expires: 15 April 2021                   The Swedish Internet Foundation
                                                         12 October 2020

                      Federated TLS Authentication
                      draft-halen-fed-tls-auth-00

Abstract

   This document describes how to establish a secure end-to-end channel
   between two parties within a federation, where both client and server
   are mutually authenticated.  The trust relationship is based upon a
   trust anchor held and published by the federation.  A federation is a
   trusted third party that inter-connect different trust domains with a
   common set of policies and standards.

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 15 April 2021.

Copyright Notice

   Copyright (c) 2020 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.

Schlyter & Halen          Expires 15 April 2021                 [Page 1]
Internet-Draft             Federated TLS AuthN              October 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Reserved Words  . . . . . . . . . . . . . . . . . . . . .   3
   2.  Federation Chain of Trust . . . . . . . . . . . . . . . . . .   3
   3.  Authentication  . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Federation Metadata . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Federation Metadata claims  . . . . . . . . . . . . . . .   4
       4.1.1.  Entities  . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Metadata Schema . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Metadata Signing  . . . . . . . . . . . . . . . . . . . .   6
     4.4.  Metadata Example  . . . . . . . . . . . . . . . . . . . .   7
   5.  Usage Examples  . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Client  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  Server  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  SPKI Generation . . . . . . . . . . . . . . . . . . . . .  10
     5.4.  Curl and Public Key Pinning . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     6.1.  TLS . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.2.  Federation Metadata Updates . . . . . . . . . . . . . . .  11
     6.3.  Federation Metadata Signing Key . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
   10. Informative References  . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   This document describes how to establish a secure end-to-end channel
   between two parties within a federation, where both client and server
   are mutually authenticated (TLS [RFC8446]).  The trust relationship
   is based upon a trust anchor held and published by the federation.  A
   federation is a trusted third party that inter-connect different
   trust domains with a common set of policies and standards.  The
   federation aggregates and publishes information ("federation
   metadata") about all the federated entities including certificate
   issuers and public key information.  When the term "federation
   metadata" is used in this document, it always refer to the aggregated
   information published by a federation in the sense of this document.

   The federation provides a common framework for providing endpoint
   information.  When two parties establish a connection, the
   information of the other endpoint is retrieved from the metadata.
   The parties leverage this every time they commence a transaction with
Show full document text