Client Application Layer Encryption
draft-deutch-lamps-client-app-encrypt-00

Document Type Active Internet-Draft (individual)
Last updated 2018-08-24
Stream (None)
Intended RFC status (None)
Formats plain text pdf html 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                                        B. Deutsch
INTERNET-DRAFT                                    Independent Submitter
Intended status: Standards Track
Expires: February 25, 2019                              August 24, 2018

            Client Application Layer Encryption
          draft-deutch-lamps-client-app-encrypt-00

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Status of This Memo

   This document specifies an Experimental protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "Internet Official
   Protocol Standards" (STD 1) for the standardization state and status
   of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document
authors. All rights reserved.

Abstract

   The protocol for Client Application Layer Encryption offers
   organizations a method of securely providing users data with very
   few authentication steps.  This protocol makes use of X.509 public
   key infrastructure and SHOULD NOT be implemented without transport
   layer security.  The protocol described below helps to ensure that
   response messages may only be read by the intended recipient.

Deutsch         Client Application Layer Encryption            [Page 1]

INTERNET-DRAFT          Expires: 17/02/2019                    Aug 2018

Table Of Contents

Abstract  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1  Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.2  Abbreviations  . . . . . . . . . . . . . . . . . . . . . . .   3
  1.3  Roles  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.4  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
  1.5  Motivation   . . . . . . . . . . . . . . . . . . . . . . . .   4
  1.6  Strengths and Weaknesses   . . . . . . . . . . . . . . . . .   4
2.  Security Considerations   . . . . . . . . . . . . . . . . . . .   5
3.  IANA Considerations   . . . . . . . . . . . . . . . . . . . . .   5
4.  Communication Patterns  . . . . . . . . . . . . . . . . . . . .   5
  4.1  Initiation  . . . .  . . . . . . . . . . . . . . . . . . . .   5
  4.2  Standard Request   . . . . . . . . . . . . . . . . . . . . .   5
  4.3  whoami Request  . . .. . . . . . . . . . . . . . . . . . . .   7
  4.4  Server Revocation  . . . . . . . . . . . . . . . . . . . . .   8
References  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
  Normative   . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
  Informative   . . . . . . . . . . . . . . . . . . . . . . . . . .   8
Appendix A: UML Flow Diagrams   . . . . . . . . . . . . . . . . . .   9
  A.1  Initiation   . . . . . . . . . . . . . . . . . . . . . . . .   9
  A.2  Standard Request   . . . . . . . . . . . . . . . . . . . . .  10
  A.3  whoami Request   . . . . . . . . . . . . . . . . . . . . . .  11
Appendix B: Example Requests and Responses  . . . . . . . . . . . .  12
  B.1  Initiation   . . . . . . . . . . . . . . . . . . . . . . . .  12
  B.2  Standard Request   . . . . . . . . . . . . . . . . . . . . .  15
  B.3  whoami Request   . . . . . . . . . . . . . . . . . . . . . .  20
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . .  22
Full Copyright Statement  . . . . . . . . . . . . . . . . . . . . .  22
Intellectual Property Statement   . . . . . . . . . . . . . . . . .  22

Deutsch         Client Application Layer Encryption            [Page 2]

INTERNET-DRAFT          Expires: 17/02/2019                    Aug 2018

1. Introduction

   This protocol offers a way to reduce the number of network
   communications that must occur for a system to have confidence in
   the identity of the requester and reduces the risk in the case of
   impersonation.  This was designed with application programming
   interfaces in mind.

1.1 Terminology

   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 RFC 2119 [RFC2119].

1.2 Abbreviations

   CN: Common Name [RFC4514]
   CSR: certificate signing request [RFC5280]
   DN: Distinguished Name [RFC4514]
   GUID: Globally Unique IDentifier [RFC4122]
   IaaS: infrastructure as a Service
   OU: Organizational Unit [RFC4514]
   PaaS: Platform as a Service
   SAN: subject alternative name [RFC4514]
   SaaS: Software as a Service
   TLS: transport layer security [RFC5246]

1.3 Roles

   resource owner: The party with rights to the data.

   resource server: The object housing the data.

   authorization server: The server that fulfills certificate
   signing requests and catalogs them for validation.  All calls to
   this device should be over TLS with mutual certificate exchange
   [RFC5246].
Show full document text