summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7076.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7076.txt')
-rw-r--r--doc/rfc/rfc7076.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc7076.txt b/doc/rfc/rfc7076.txt
new file mode 100644
index 0000000..8c669b7
--- /dev/null
+++ b/doc/rfc/rfc7076.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Independent Submission M. Joseph
+Request for Comments: 7076 J. Susoy
+Category: Informational P6R, Inc
+ISSN: 2070-1721 November 2013
+
+
+ P6R's Secure Shell Public Key Subsystem
+
+Abstract
+
+ The Secure Shell (SSH) Public Key Subsystem protocol defines a key
+ distribution protocol that is limited to provisioning an SSH server
+ with a user's public keys. 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.
+
+ 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, Key Management
+ Interoperability Protocol (KMIP), Simple Network Management Protocol
+ (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 particular 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.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This is a contribution to the RFC Series, independently of any other
+ RFC stream. The RFC Editor has chosen to publish this document at
+ its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+
+
+
+
+Joseph & Susoy Informational [Page 1]
+
+RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013
+
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7076.
+
+Copyright Notice
+
+ Copyright (c) 2013 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.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................3
+ 3. Overview of Extensions to the Public Key Subsystem ..............3
+ 3.1. Extended Status Codes ......................................4
+ 3.2. The Version Packet .........................................4
+ 3.3. The Namespace Attribute ....................................4
+ 4. New Operations ..................................................5
+ 4.1. Adding a Certificate .......................................5
+ 4.2. Removing a Certificate .....................................6
+ 4.3. Listing Certificates .......................................6
+ 4.4. Listing Namespaces .........................................7
+ 5. Extending Public Key Operations .................................8
+ 5.1. Adding a Public Key ........................................8
+ 5.2. Removing a Public Key ......................................8
+ 5.3. Listing Public Keys ........................................9
+ 6. Security Considerations .........................................9
+ 7. IANA Considerations ............................................10
+ 8. References .....................................................10
+ 8.1. Normative References ......................................10
+ 8.2. Informative References ....................................10
+
+
+
+
+
+
+
+
+
+
+
+
+
+Joseph & Susoy Informational [Page 2]
+
+RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013
+
+
+1. Introduction
+
+ This document describes a new protocol that builds on the protocol
+ defined in RFC 4819 that can be used to configure public keys and
+ certificates in an implementation-independent fashion. The concept
+ of a namespace is added to the protocol's operations; it allows the
+ client to organize keys and certificates by application or
+ organizational structure.
+
+ P6R's Secure Shell Public Key Subsystem has been designed to run on
+ top of the Secure Shell transport layer [3] and user authentication
+ protocols [4]. It provides a simple mechanism for the client to
+ manage the public keys and certificates on the server related to that
+ client. These keys and certificates are normally used for
+ authentication of the client to a service, but they can be used for
+ encrypting results back to the client as well. Uploaded keys and
+ certificates are meant to be able to configure all protocols running
+ on a server (e.g., SSH, SSL, KMIP [8]) that use keys and
+ certificates, as well as the applications that run on a server.
+
+ 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".
+
+
+
+
+
+
+
+
+
+
+
+
+Joseph & Susoy Informational [Page 3]
+
+RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013
+
+
+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_CERTIFICATE_NOT_FOUND 192
+ SSH_PUBLICKEY_CERTIFICATE_NOT_SUPPORTED 193
+ SSH_PUBLICKEY_CERTIFICATE_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.
+
+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. We are using
+ version 3 so that it can be backward compatible with the protocol
+ defined by RFC 4819 [1].
+
+3.3. The Namespace Attribute
+
+ The "namespace" attribute is added as an extension to what was
+ described in RFC 4819. The purpose of this attribute is to be able
+ to organize the uploaded keys and certificates into groups where each
+ group represents an application or organization structure. This
+ attribute is a string that should not be longer than 300 characters
+ and MUST be specified in UTF-8 format [5].
+
+ This new protocol uses the "ssh" namespace for the manipulation of
+ public keys in an SSH server and should be considered as the default
+ namespace when none is provided.
+
+ As a convention, namespaces used for protocols are lowercase strings
+ of the protocol's standard abbreviation. For example, "ssl" should
+ be the namespace used for the Secure Sockets Layer protocol.
+ Namespaces for applications should contain the product and vendor's
+ name. To help determine what namespaces already exist on a server, a
+ new operation "list-namespaces" is defined in Section 4.
+
+
+
+
+
+Joseph & Susoy Informational [Page 4]
+
+RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013
+
+
+4. New Operations
+
+ P6R's Public Key Subsystem extends the functionality defined in RFC
+ 4819 with the following operations: add-certificate,
+ remove-certificate, list-certificates, and list-namespaces.
+
+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. Only one namespace
+ attribute can be used per an add-certificate request. It is possible
+ for the same user to save the same certificate into multiple
+ namespaces, but this must be done with several separate
+ add-certificate requests.
+
+ 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.
+
+ However, a user may not be authorized to add a certificate to the
+ specified namespace. If the user does not have permission to add a
+ certificate, then the server MUST return
+ SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED.
+
+ Examples of possible "certificate format names" are: "X509",
+ "pgp-sign-rsa", and "pgp-sign-dss". The format of the public key and
+ certificate blobs are detailed in Section 6.6, "Public Key
+
+
+
+Joseph & Susoy Informational [Page 5]
+
+RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013
+
+
+ Algorithms", of the SSH Transport Protocol document [3], where X.509
+ certificates are to be encoded using a DER format [6] [7] in a
+ certificate blob.
+
+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 from where to delete the certificate. Only one
+ namespace attribute can be used per remove-certificate request. The
+ server MUST attempt to remove the certificate from the appropriate
+ location.
+
+ However, a user may not be authorized to remove a certificate from
+ the specified namespace. If the user does not have permission to
+ remove the certificate, then the server MUST return
+ SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED.
+
+ Examples of possible "certificate format names" are: "X509",
+ "pgp-sign-rsa", and "pgp-sign-dss".
+
+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
+
+
+
+
+
+Joseph & Susoy Informational [Page 6]
+
+RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013
+
+
+ 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 least the "namespace" attribute so that
+ a client can tell in which namespace the certificate resides. Only
+ one namespace attribute can be used per list-certificate request.
+
+ Following the last "certificate" response, a status packet MUST be
+ sent.
+
+4.4. Listing Namespaces
+
+ If the client wishes to know existing namespaces on the server, it
+ sends:
+
+ string "list-namespaces"
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Joseph & Susoy Informational [Page 7]
+
+RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013
+
+
+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 one "namespace" attribute so that a client
+ can save the public key into a specific namespace. It is possible
+ for the same user to save the same key into multiple namespaces, but
+ this requires multiple add requests.
+
+ 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,
+
+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 one "namespace" attribute so that a client
+ can remove the public key from a specific namespace.
+
+
+
+
+
+
+Joseph & Susoy Informational [Page 8]
+
+RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013
+
+
+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 one "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 the "namespace" attribute so that a client
+ can tell in which namespace the key resides.
+
+6. Security Considerations
+
+ This protocol assumes that it is run over a secure channel and that
+ the endpoints of the channel have been authenticated. Thus, this
+ protocol assumes that it is externally protected from network-level
+ attacks.
+
+ This protocol provides a mechanism that allows key and certificate
+ 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 any particular user's
+ access to the 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.
+
+
+
+
+
+
+
+Joseph & Susoy Informational [Page 9]
+
+RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013
+
+
+ This protocol requires the client to assume that the server will
+ correctly implement and observe attributes applied to keys.
+ Implementation errors in the server could cause clients to authorize
+ keys and certificates for access they were not intended to have, or
+ to apply fewer restrictions than were intended.
+
+7. IANA Considerations
+
+ Although Section 3.1 defines four new status codes, these are in the
+ 'Private Use' range of IANA's Publickey Subsystem Status Codes
+ registry as defined by Section 6.6.1 ("Conventions") in [1]. No IANA
+ actions are required for this document.
+
+8. References
+
+8.1. Normative References
+
+ [1] Galbraith, J., Van Dyke, J., 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, Ed., "The Secure Shell (SSH) Transport
+ Layer Protocol", RFC 4253, January 2006.
+
+ [4] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+ Authentication Protocol", RFC 4252, January 2006.
+
+ [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
+ 63, RFC 3629, November 2003.
+
+ [6] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R.,
+ and W. Polk, "Internet X.509 Public Key Infrastructure
+ Certificate and Certificate Revocation List (CRL) Profile", RFC
+ 5280, May 2008.
+
+ [7] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
+ Information technology -- ASN.1 encoding rules: Specification of
+ Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER).
+
+8.2. Informative References
+
+ [8] OASIS, "Key Management Interoperability Protocol (KMIP) 1.1",
+ January 2013, <http://docs.oasis-open.org/kmip/spec/v1.1/os/
+ kmip-spec-v1.1-os.html>.
+
+
+
+
+Joseph & Susoy Informational [Page 10]
+
+RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013
+
+
+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 Informational [Page 11]
+