idnits 2.17.1 draft-joseph-pkix-p6rsshextension-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 30 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 189 has weird spacing: '... string cer...' == Line 190 has weird spacing: '... string cer...' == Line 191 has weird spacing: '...boolean over...' == Line 193 has weird spacing: '... string att...' == Line 194 has weird spacing: '... string att...' == (24 more instances...) -- The document date (Sept 30, 2013) is 4128 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Joseph 3 Internet-Draft J. Susoy 4 Intended status: Informational P6R, Inc 5 Sept 30, 2013 7 P6R's Secure Shell Public Key Subsystem 8 draft-joseph-pkix-p6rsshextension-04.txt 10 Abstract 12 The Secure Shell Public Key Subsystem protocol defines a key distribution 13 protocol to provision an SSH server with user's public keys. However, 14 that protocol is limited to provisioning an SSH server. This document 15 describes a new protocol that builds on the protocol defined in RFC 4819 16 to allow the provisioning of keys and certificates to a server using the 17 SSH transport. 19 The new protocol allows the calling client to organize 20 keys and certificates in different namespaces on a server. These 21 namespaces can be used by the server to allow a client to configure 22 any application running on the server (e.g., SSH, KMIP, SNMP). 24 The new protocol provides a server-independent mechanism for clients 25 to add public keys, remove public keys, add certificates, remove 26 certificates, and list the current set of keys and certificates known by 27 the server by namespace (e.g., list all public keys in the SSH 28 namespace). 30 Rights to manage keys and certificates in a specific namespace are 31 specific and limited to the authorized user and are defined as part of 32 the server's implementation. The described protocol is backward 33 compatible to version 2 defined by RFC 4819. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other documents 47 at any time. It is inappropriate to use Internet-Drafts as 48 reference material or to cite them other than as "work in progress." 50 This Internet-Draft will expire on December 17, 2013. 52 Copyright Notice 54 Copyright (c) 2013 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. Code Components extracted from this 63 document must include Simplified BSD License text as described in 64 Section 4.e of the Trust Legal Provisions and are provided without 65 warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Overview of extensions to the Public Key Subsystem . . . . . . 3 72 3.1. Extended Status Codes . . . . . . . . . . . . . . . . . . 3 73 3.2. The Version Packet . . . . . . . . . . . . . . . . . . . . 4 74 3.3. The Namespace Attribute . . . . . . . . . . . . . . . . . 4 75 4. New Operations . . . . . . . . . . . . . . . . . . . . . . . 4 76 4.1. Adding a Certificate . . . . . . . . . . . . . . . . . . 4 77 4.2. Removing a Certificate . . . . . . . . . . . . . . . . . . 5 78 4.3. Listing Certificates . . . . . . . . . . . . . . . . . . 6 79 4.4. Listing Namespaces . . . . . . . . . . . . . . . . . . . . 6 80 5. Extending Public Key Operations . . . . . . . . . . . . . . . 7 81 5.1. Adding a Public Key . . . . . . . . . . . . . . . . . . . 7 82 5.2. Removing a Public Key . . . . . . . . . . . . . . . . . . 7 83 5.3. Listing Public Keys . . . . . . . . . . . . . . . . . . . 8 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 89 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 91 1. Introduction 93 This document describes a new protocol based on the protocol defined 94 in RFC 4819 that can be used to configure public keys and certificates 95 in an implementation-independent fashion. The addition of the concept 96 of a namespace which allows the client to organize keys and certificates 97 by application or organizational structure is added to the protocol's 98 operations. 100 P6R's Secure Shell Public Key Subsystem has been designed to run on top 101 of the Secure Shell transport layer [3] and user authentication 102 protocols [4]. It provides a simple mechanism for the client to 103 manage the public keys and certificates on the server related to the 104 client. These keys and certificates are normally used for 105 authentication of the client to a service, but can be used for 106 encrypting results back to the client as well. Uploaded keys and 107 certificates are meant to be able to configure all protocols running 108 on a server (e.g., SSH, SSL, KMIP [8]) that use keys and certificates as 109 well as applications that run on a server. 111 This document should be read only after reading the Secure Shell Public 112 Key Subsystem [1] document. The new protocol described in this document 113 builds on and is meant to be backwards compatible with the protocol 114 described in [1]. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [2]. 122 3. Overview of extensions to the Public Key Subsystem 124 The Public Key Subsystem provides a server-independent mechanism for 125 clients to add public keys, remove public keys, list the current 126 public keys known by the server, add certificates, remove 127 certificates, and list the current set of certificates known by 128 the server. This secure key distribution mechanism is implemented 129 by a new SSH subsystem with the name of "publickey@p6r.com". 131 3.1. Extended Status Codes 133 The status code gives the status in a more machine-readable format 134 (suitable for localization), and can have the following values: 136 SSH_PUBLICKEY_CERTIFCATE_NOT_FOUND 192 137 SSH_PUBLICKEY_CERTIFCATE_NOT_SUPPORTED 193 138 SSH_PUBLICKEY_CERTIFCATE_ALREADY_PRESENT 194 139 SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED 195 140 SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE 196 142 The meaning of the failure codes is as implied by their names. 143 See Security Considerations for the use of the failure code: 144 SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED. 146 3.2. The Version Packet 148 Both sides MUST start a connection by sending a version packet that 149 indicates the version of the protocol they are using. 151 string "version" 152 uint32 protocol-version-number 154 This document defines version 3 of the new protocol. We are using 155 version 3 so that it can be backward compatible with the protocol 156 defined by RFC 4819 [1]. 158 3.3. The Namespace Attribute 160 The "namespace" attribute is added as an extension to what was 161 described in RFC 4819. The purpose of this attribute is to be able 162 to organize the uploaded keys and certificates into groups where 163 each group represents an application or organization structure. 164 This attribute is a string that should not be longer than 300 165 characters and MUST be specified in UTF-8 format [5]. 167 This new protocol uses the "ssh" namespace for the 168 manipulation of public keys in an SSH server and should be 169 considered as the default namespace when none is provided. 171 As a convention, namespaces used for protocols are lower case strings 172 of the protocol's standard abbreviation. For example, "ssl" should 173 be the namespace used for the Secure Sockets Layer protocol. 174 Namespaces for applications should contain the product and vendor's 175 name. To help determine what namespaces already exist on a server 176 a new operation "list-namespaces" is defined in Section 4. 178 4. New Operations 180 P6R's Public Key Subsystem extends the functionality defined in 181 RFC 4819 with the following operations: add-certificate, 182 remove-certificate, list-certificates, and list-namespaces. 184 4.1. Adding a Certificate 186 If the client wishes to add a certificate, the client sends: 188 string "add-certificate" 189 string certificate format name 190 string certificate blob 191 boolean overwrite 192 uint32 attribute-count 193 string attrib-name 194 string attrib-value 195 bool critical 196 repeated attribute-count times 198 This request MUST include at least the "namespace" attribute so that 199 the server knows where to save the certificate to. Only one namespace 200 attribute can be used per add-certificate request. It is possible 201 for the same user to save the same certificate into multiple namespaces 202 but this must be done with several separate add-certificate requests. 204 If the namespace appearing in an add-certificate request does not 205 already exist on a server then it is created by this operation. 206 However, if the user is not authorized to create a namespace the server 207 MUST return SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE. 209 If the overwrite field is false and the specified certificate already 210 exists in the given namespace, the server MUST return 211 SSH_PUBLICKEY_CERTIFICATE_ALREADY_PRESENT. If the server returns this, 212 the client SHOULD provide an option to the user to overwrite the 213 certificate. If the overwrite field is true and the specified key 214 already exists in the given namespace, but cannot be overwritten, the 215 server MUST return SSH_PUBLICKEY_ACCESS_DENIED. 217 However, a user may not be authorized to add a certificate to the 218 specified namespace. If the user does not have permission to add 219 a certificate then the server MUST return 220 SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED. 222 Examples of possible "certificate format name" are: "X509", 223 "pgp-sign-rsa", and "pgp-sign-dss". The format of public key and 224 certificate blobs are detailed in Section 6.6, "Public Key Algorithms" 225 of the SSH Transport Protocol document [3], where X509 certificates 226 are to be encoded using a DER [6,7] format in a certificate blob. 228 4.2. Removing a Certificate 230 If the client wishes to remove a certificate, the client sends: 232 string "remove-certificate" 233 string certificate format name 234 string certificate blob 235 uint32 attribute-count 236 string attrib-name 237 string attrib-value 238 repeated attribute-count times 240 This request MUST include at least the "namespace" attribute so 241 that the server knows where to delete the certificate from. Only 242 one namespace attribute can be used per remove-certificate request. 243 The server MUST attempt to remove the certificate from the 244 the appropriate location. 246 However, a user may not be authorized to remove a certificate from the 247 specified namespace. If the user does not have permission to remove 248 the certificate then the server MUST return 249 SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED. 251 Examples of possible "certificate format name" are: "X509", 252 "pgp-sign-rsa", "pgp-sign-dss". 254 4.3. Listing Certificates 256 If the client wishes to list the known certificates, the client sends: 258 string "list-certificates" 260 The server will respond with zero or more of the following responses: 262 string "certificate" 263 string certificate format name 264 string certificate blob 265 uint32 attribute-count 266 string attrib-name 267 string attrib-value 268 repeated attribute-count times 270 There is no requirement that the responses be in any particular 271 order. Whilst some server implementations may send the responses in 272 some order, client implementations should not rely on responses being 273 in any order. 275 This response MUST include at least the "namespace" attribute so that 276 a client can tell which namespace the certificate resides. 277 Only one namespace attribute can be used per list-certificate request. 279 Following the last "certificate" response, a status packet MUST be 280 sent. 282 4.4. Listing Namespaces 284 If the client wishes to know existing namespaces on the server, it 285 sends: 287 string "list-namespaces" 289 The server will respond with zero or more of the following responses: 291 string "namespace" 292 string namespace name 294 It is possible that not all namespaces will be visible to every 295 authenticated user. In this case the responding server will return 296 a subset of existing namespaces. See Security Considerations below. 298 Following the last "namespace" response, a status packet MUST be 299 sent. 301 5. Extending Public Key Operations 303 In addition to adding new operations, this document describes 304 extensions to the operations defined in RFC 4819. 306 5.1. Adding a Public Key 308 If the client wishes to add a public key, the client sends: 310 string "add" 311 string public key algorithm name 312 string public key blob 313 boolean overwrite 314 uint32 attribute-count 315 string attrib-name 316 string attrib-value 317 bool critical 318 repeated attribute-count times 320 This request MAY include one "namespace" attribute so that 321 a client can save the public key into a specific namespace. 322 It is possible for the same user to save the same key into 323 multiple namespaces but will require multiple add requests 324 to do so. 326 If the namespace appearing in an add public key request does not already 327 exist on a server then it is created by this operation. However, if 328 the user is not authorized to create a namespace the server MUST return 329 SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE, 331 5.2. Removing a Public Key 333 If the client wishes to remove a public key, the client sends: 335 string "remove" 336 string public key algorithm name 337 string public key blob 338 uint32 attribute-count 339 string attrib-name 340 string attrib-value 341 bool critical 342 repeated attribute-count times 344 This extension allows attributes to be added to a remove request. 345 This request MAY include one "namespace" attribute so that 346 a client can remove the public key from a specific namespace. 348 5.3. Listing Public Keys 350 If the client wishes to list the known public keys, the client sends: 352 string "list" 353 uint32 attribute-count 354 string attrib-name 355 string attrib-value 356 bool critical 357 repeated attribute-count times 359 This extension allows attributes to be added to a list request. 360 This request MAY include one "namespace" attribute so that 361 a client can list the public keys from a specific namespace. 363 The server will respond with zero or more of the following responses: 365 string "publickey" 366 string public key algorithm name 367 string public key blob 368 uint32 attribute-count 369 string attrib-name 370 string attrib-value 371 repeated attribute-count times 373 This response MAY include at the "namespace" attribute so that 374 a client can tell which namespace the key resides. 376 6. Security Considerations 378 This protocol assumes that it is run over a secure channel and that 379 the endpoints of the channel have been authenticated. \Thus, this 380 protocol assumes that it is externally protected from network-level 381 attacks. 383 This protocol provides a mechanism that allows key and certificate 384 material to be uploaded and manipulated into a server 385 application. It is the responsibility of the server implementation 386 to enforce access controls that may be required to limit the access 387 allowed for any particular user to that data in a namespace. For 388 example, one user may be allowed to list only the contents of a 389 namespace but not add or remove keys or certificates to/from it. 390 The server MUST return SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED when a 391 user's action goes against its defined access controls. 393 This protocol requires the client to assume that the server will 394 correctly implement and observe attributes applied to keys. 395 Implementation errors in the server could cause clients to authorize 396 keys and certificates for access they were not intended to have, or 397 to apply fewer restrictions than were intended. 399 7. IANA Considerations 401 Although section 3.1 defines four new status codes, these are in 402 the 'Private Use' range of IANA's Publickey Subsystem Attributes, 403 Registry as defined by section 6.6.1. Conventions in [1]. 404 No IANA action is requested for this document. 406 8. References 408 8.1. Normative References 410 [1] J. Galbraith, J. Van Dyke, and J. Bright, "Secure Shell Public 411 Key Subsystem", RFC 4819, March 2007. 413 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 414 Levels", BCP 14, RFC 2119, March 1997. 416 [3] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport 417 Layer Protocol", RFC 4253, January 2006. 419 [4] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 420 Authentication Protocol", RFC 4252, January 2006. 422 [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 423 STD 63, RFC 3629, November 2003. 425 [6] Cooper, D. et al., "Internet X.509 Public Key Infrastructure 426 Certificate and Certificate Revocation List (CRL) Profile", 427 RFC 5280, May 2008. 429 [7] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 430 Information technology - ASN.1 encoding rules: 431 Specification of Basic Encoding Rules (BER), Canonical 432 Encoding Rules (CER) and Distinguished Encoding Rules (DER). 434 8.1. Informative References 436 [8] OASIS, Key Management Interoperability Protocol (KMIP) 1.1, 437 http://docs.oasis-open.org/kmip/spec/v1.1/os/kmip-spec-v1.1-os.html. 438 24 January 2013. 440 9. Authors' Addresses 442 Mark Joseph, PhD 443 P6R, Inc 444 1840 41st Ave 445 Suite 102-139 446 Capitola, CA 95010 447 US 449 Phone: +1 888 452 2580 (x702) 450 EMail: mark@p6r.com 452 Jim Susoy 453 P6R, Inc 454 1840 41st Ave 455 Suite 102-139 456 Capitola, CA 95010 457 US 459 Phone: +1 888 452 2580 (x701) 460 EMail: jim@p6r.com