P6R's Secure Shell Public Key Subsystem
draft-joseph-pkix-p6rsshextension-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7076.
|
|
---|---|---|---|
Authors | Mark Joseph, Jim Susoy | ||
Last updated | 2013-05-27 | ||
RFC stream | (None) | ||
Formats | |||
IETF conflict review | conflict-review-joseph-pkix-p6rsshextension, conflict-review-joseph-pkix-p6rsshextension, conflict-review-joseph-pkix-p6rsshextension, conflict-review-joseph-pkix-p6rsshextension, conflict-review-joseph-pkix-p6rsshextension, conflict-review-joseph-pkix-p6rsshextension, conflict-review-joseph-pkix-p6rsshextension | ||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Became RFC 7076 (Informational) | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-joseph-pkix-p6rsshextension-00
Network Working Group M. Joseph Internet-Draft J. Susoy Intended status: Informational P6R, Inc Expires: November 22, 2013 May 27, 2013 P6R's Secure Shell Public Key Subsystem draft-joseph-pkix-p6rsshextension-00.txt 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 http://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 November 12, 2012. Copyright Notice Copyright (c) 2012 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract The Secure Shell Public Key Subsystem protocol defines a key distribution protocol to provision an SSH server with user's public keys. However, that protocol is limited to provisioning an SSH server. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport. Joseph & Susoy Expires November 22, 2013 [Page 1] Internet-Draft P6R's Secure Shell Public Key Subsystem May 2013 The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, KMIP, SNMP). The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace). Rights to manage keys and certificates in a specific namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of extensions to the Public Key Subsystem . . . . . . 3 3.1. Extended Status Codes . . . . . . . . . . . . . . . . . . 3 3.2. The Version Packet . . . . . . . . . . . . . . . . . . . . 4 4. New Operations . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Adding a Certificate . . . . . . . . . . . . . . . . . . 4 4.2. Removing a Certificate . . . . . . . . . . . . . . . . . . 5 4.3. Listing Certificates . . . . . . . . . . . . . . . . . . 5 4.4. Listing Namespaces . . . . . . . . . . . . . . . . . . . . 6 5. Extending Public Key Operations . . . . . . . . . . . . . . . 6 5.1. Adding a Public Key . . . . . . . . . . . . . . . . . . . 6 5.2. Removing a Public Key . . . . . . . . . . . . . . . . . . 7 5.3. Listing Public Keys . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Joseph & Susoy Expires November 22, 2013 [Page 2] Internet-Draft P6R's Secure Shell Public Key Subsystem May 2013 1. Introduction This document describes a new protocol based on the protocol defined in RFC 4819 that can be used to configure public keys and certificates in an implementation-independent fashion. The addition of the concept of a namespace which allows the client to organize keys and certificates by application or organizational structure is added to the protocol's operations. This document should be read only after reading the Secure Shell Public Key Subsystem [1] document. The new protocol described in this document builds on and is meant to be backwards compatible with the protocol described in [1]. 2. 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 [2]. 3. Overview of extensions to the Public Key Subsystem The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, list the current public keys known by the server, add certificates, remove certificates, and list the current set of certificates known by the server. This secure key distribution mechanism is implemented by a new SSH subsystem with the name of "publickey@p6r.com". This new protocol uses the "ssh" namespace for the manipulation of public keys in an SSH server. 3.1. Extended Status Codes The status code gives the status in a more machine-readable format (suitable for localization), and can have the following values: SSH_PUBLICKEY_CERTIFCATE_NOT_FOUND 192 SSH_PUBLICKEY_CERTIFCATE_NOT_SUPPORTED 193 SSH_PUBLICKEY_CERTIFCATE_ALREADY_PRESENT 194 SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED 195 SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE 196 The meaning of the failure codes is as implied by their names. See Security Considerations for the use of the failure code: SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED. Joseph & Susoy Expires November 22, 2013 [Page 3] Internet-Draft P6R's Secure Shell Public Key Subsystem May 2013 3.2. The Version Packet Both sides MUST start a connection by sending a version packet that indicates the version of the protocol they are using. string "version" uint32 protocol-version-number This document defines version 3 of the new protocol. 4. New Operations P6R's Public Key Subsystem extendeds the functionality defined in RFC 4819 with the following operations: add-certificate, remove-certificate, list-certificates, and listnamespaces. 4.1. Adding a Certificate If the client wishes to add a certificate, the client sends: string "add-certificate" string certificate format name string certificate blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times This request MUST include at least the "namespace" attribute so that the server knows where to save the certificate to. It is possible for the same user to save the same certificate into multiple namespaces. If the namespace appearing in an add-certificate request does not already exist on a server then it is created by this operation. However, if the user is not authorized to create a namespace the server MUST return SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE, If the overwrite field is false and the specified certificate already exists in the given namespace, the server MUST return SSH_PUBLICKEY_CERTIFICATE_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the certificate. If the overwrite field is true and the specified key already exists in the given namespace, but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED. Joseph & Susoy Expires November 22, 2013 [Page 4] Internet-Draft P6R's Secure Shell Public Key Subsystem May 2013 The format of public key and certificate blobs are detailed in Section 6.6, "Public Key Algorithms" of the SSH Transport Protocol document [3]. 4.2. Removing a Certificate If the client wishes to remove a certificate, the client sends: string "remove-certificate" string certificate format name string certificate blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times This request MUST include at least the "namespace" attribute so that the server knows where to delete the certificate from. The server MUST attempt to remove the certificate from the the appropriate location. 4.3. Listing Certificates If the client wishes to list the known certificates, the client sends: string "list-certificates" The server will respond with zero or more of the following responses: string "certificate" string certificate format name string certificate blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times There is no requirement that the responses be in any particular order. Whilst some server implementations may send the responses in some order, client implementations should not rely on responses being in any order. This response MUST include at the "namespace" attribute so that a client can tell which namespace the certificate resides. Examples of possible "certificate format name" are: "X509", "PGP". Following the last "certificate" response, a status packet MUST be sent. Joseph & Susoy Expires November 22, 2013 [Page 5] Internet-Draft P6R's Secure Shell Public Key Subsystem May 2013 4.4. Listing Namespaces If the client wishes to know existing namespaces on the server, it sends: string "listnamespaces" The server will respond with zero or more of the following responses: string "namespace" string namespace name It is possible that not all namespaces will be visible to every authenticated user. In this case the responding server will return a subset of existing namespaces. See Security Considerations below. Following the last "namespace" response, a status packet MUST be sent. 5. Extending Public Key Operations In addition to adding new operations, this document describes extensions to the operations defined in RFC 4819. 5.1. Adding a Public Key If the client wishes to add a public key, the client sends: string "add" string public key algorithm name string public key blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times This request MAY include at the "namespace" attribute so that a client can save the public key into a specific namespace. Thus it is possible for the same user to save the same key into multiple namespaces. If the namespace appearing in an add public key request does not already exist on a server then it is created by this operation. However, if the user is not authorized to create a namespace the server MUST return SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE, Joseph & Susoy Expires November 22, 2013 [Page 6] Internet-Draft P6R's Secure Shell Public Key Subsystem May 2013 5.2. Removing a Public Key If the client wishes to remove a public key, the client sends: string "remove" string public key algorithm name string public key blob uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times This extension allows attributes to be added to a remove request. This request MAY include at the "namespace" attribute so that a client can remove the public key from a specific namespace. 5.3. Listing Public Keys If the client wishes to list the known public keys, the client sends: string "list" uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times This extension allows attributes to be added to a list request. This request MAY include at the "namespace" attribute so that a client can list the public keys from a specific namespace. The server will respond with zero or more of the following responses: string "publickey" string public key algorithm name string public key blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times This response MAY include at the "namespace" attribute so that a client can tell which namespace the key resides. Joseph & Susoy Expires November 22, 2013 [Page 7] Internet-Draft P6R's Secure Shell Public Key Subsystem May 2013 6. Security Considerations This protocol provides a mechanism that allows certificate an key material to be uploaded and manipulated into a server application. It is the responsibility of the server implementation to enforce access controls that may be required to limit the access allowed for any particular user to that data in a namespace. For example, one user may be allowed to list only the contents of a namespace but not add or remove keys or certificates to/from it. The server MUST return SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED when a user's action goes against its defined access controls. 7. References 7.1. Normative References [1] J. Galbraith, J. Van Dyke, and J. Bright, "Secure Shell Public Key Subsystem", RFC 4819, March 2007. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. 8. Authors' Addresses Mark Joseph, PhD P6R, Inc 1840 41st Ave Suite 102-139 Capitola, CA 95010 US Phone: +1 888 452 2580 (x702) EMail: mark@p6r.com Jim Susoy P6R, Inc 1840 41st Ave Suite 102-139 Capitola, CA 95010 US Phone: +1 888 452 2580 (x701) EMail: jim@p6r.com Joseph & Susoy Expires November 22, 2013 [Page 8]