idnits 2.17.1 draft-ietf-secsh-publickey-subsystem-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 756. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 163 has weird spacing: '...boolean want...' == Line 187 has weird spacing: '... string nam...' == Line 207 has weird spacing: '... string des...' == Line 208 has weird spacing: '... string lan...' == Line 278 has weird spacing: '... string pub...' == (12 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 5, 2006) is 6385 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC-3629' on line 207 -- Looks like a reference, but probably isn't: 'RFC-3066' on line 208 ** Obsolete normative reference: RFC 3066 (ref. '6') (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 822 (ref. '8') (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '10') (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Shell Working Group J. Galbraith 3 Internet-Draft J. Van Dyke 4 Intended status: Informational B. McClure 5 Expires: April 8, 2007 VanDyke Software 6 J. Bright 7 Silicon Circus 8 October 5, 2006 10 Secure Shell Public-Key Subsystem 11 draft-ietf-secsh-publickey-subsystem-08.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 8, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 Secure Shell defines a user authentication mechanism that is based on 45 public keys, but does not define any mechanism for key distribution. 46 No common key management solution exists in current implementations. 47 This document describes a protocol that can be used to configure 48 public keys in an implementation-independent fashion, allowing client 49 software to take on the burden of this configuration. 51 The public-key subsystem provides a server-independent mechanism for 52 clients to add public keys, remove public keys, and list the current 53 public keys known by the server. Rights to manage public keys are 54 specific and limited to the authenticated user. 56 A public key may also be associated with various restrictions, 57 including a mandatory command or subsystem. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Public-Key Subsystem Overview . . . . . . . . . . . . . . . . 6 64 3.1. Opening the Public-Key Subsystem . . . . . . . . . . . . . 6 65 3.2. Requests and Responses . . . . . . . . . . . . . . . . . . 7 66 3.3. The Status Message . . . . . . . . . . . . . . . . . . . . 7 67 3.3.1. Status Codes . . . . . . . . . . . . . . . . . . . . . 7 68 3.4. The Version Packet . . . . . . . . . . . . . . . . . . . . 8 69 4. Public-Key Subsystem Operations . . . . . . . . . . . . . . . 9 70 4.1. Adding a Public Key . . . . . . . . . . . . . . . . . . . 9 71 4.2. Removing a Public Key . . . . . . . . . . . . . . . . . . 12 72 4.3. Listing Public Keys . . . . . . . . . . . . . . . . . . . 12 73 4.4. Listing Server Capabilities . . . . . . . . . . . . . . . 12 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 6.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 15 77 6.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 6.2.1. Conventions for Names . . . . . . . . . . . . . . . . 15 79 6.2.2. Future Assignments of Names . . . . . . . . . . . . . 16 80 6.3. Public-Key Subystem Request Names . . . . . . . . . . . . 16 81 6.4. Public-Key Subsystem Response Names . . . . . . . . . . . 16 82 6.5. Public-Key Subsystem Attribute Names . . . . . . . . . . . 16 83 6.6. Public-Key subsystem Status Codes . . . . . . . . . . . . 17 84 6.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 17 85 6.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 17 86 6.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 17 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 89 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 91 Intellectual Property and Copyright Statements . . . . . . . . . . 21 93 1. Introduction 95 Secure Shell is a protocol for secure remote login and other secure 96 network services over an insecure network. Secure Shell defines a 97 user authentication mechanism that is based on public keys, but does 98 not define any mechanism for key distribution. Common practice is to 99 authenticate once with password authentication and transfer the 100 public key to the server. However, to date no two implementations 101 use the same mechanism to configure a public key for use. 103 This document describes a subsystem that can be used to configure 104 public keys in an implementation-independent fashion. This approach 105 allows client software to take on the burden of this configuration. 106 The public-key subsystem protocol is designed for extreme simplicity 107 in implementation. It is not intended as a PKIX replacement. 109 The Secure Shell Public-Key subsystem has been designed to run on top 110 of the Secure Shell transport layer [2] and user authentication 111 protocols [3]. It provides a simple mechanism for the client to 112 manage public keys on the server. 114 This document should be read only after reading the Secure Shell 115 architecture [1] and Secure Shell connection [4] documents. 117 This protocol is intended to be used from the Secure Shell Connection 118 Protocol [4] as a subsystem, as described in the section "Starting a 119 Shell or a Command". The subsystem name used with this protocol is 120 "publickey". 122 This protocol requires that the user be able to authenticate in some 123 fashion before it can be used. If password authentication is used, 124 servers SHOULD provide a configuration option to disable the use of 125 password authentication after the first public key is added. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC2119 [5]. 133 3. Public-Key Subsystem Overview 135 The public-key subsystem provides a server-independent mechanism for 136 clients to add public keys, remove public keys, and list the current 137 public keys known by the server. The subsystem name is "publickey". 139 The public keys added, removed, and listed using this protocol are 140 specific and limited to those of the authenticated user. 142 The operations to add, remove, and list the authenticated user's 143 public keys are performed as request packets sent to the server. The 144 server sends response packets that indicate success or failure as 145 well as provide specific response data. 147 The format of public-key blobs are detailed in section 6.6, "Public 148 Key Algorithms" of the SSH Transport Protocol document [2]. 150 3.1. Opening the Public-Key Subsystem 152 The public-key subsystem is started by a client sending an 153 SSH_MSG_CHANNEL_REQUEST over an existing session's channel. 155 The details of how a session is opened are described in the SSH 156 Connection Protocol document [4] in the section "Opening a Session". 158 To open the public-key subsystem, the client sends: 160 byte SSH_MSG_CHANNEL_REQUEST 161 uint32 recipient channel 162 string "subsystem" 163 boolean want reply 164 string "publickey" 166 Client implementations SHOULD reject this request; it is normally 167 sent only by the client. 169 If want reply is TRUE, the server MUST respond with 170 SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully 171 started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or 172 does not support the public-key subsystem. 174 The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user is 175 not allowed access to the public-key subsystem (for example, because 176 the user authenticated with a restricted public key). 178 It is RECOMMENDED that clients request and check the reply for this 179 request. 181 3.2. Requests and Responses 183 All public-key subsystem requests and responses are sent in the 184 following form: 186 uint32 length 187 string name 188 ... request/response specific data follows 190 The length field describes the length of the name field and of the 191 request/response-specific data, but does not include the length of 192 the length field itself. The client MUST receive acknowledgement of 193 each request prior to sending a new request. 195 The version packet, as well as all requests and responses described 196 in Section 4, are a description of the 'name' field and the data part 197 of the packet. 199 3.3. The Status Message 201 A request is acknowledged by sending a status packet. If there is 202 data in response to the request, the status packet is sent after all 203 data has been sent. 205 string "status" 206 uint32 status code 207 string description [RFC-3629] 208 string language tag [RFC-3066] 210 A status message MUST be sent for any unrecognized packets, and the 211 request SHOULD NOT close the subsystem. 213 3.3.1. Status Codes 215 The status code gives the status in a more machine-readable format 216 (suitable for localization), and can have the following values: 218 SSH_PUBLICKEY_SUCCESS 0 219 SSH_PUBLICKEY_ACCESS_DENIED 1 220 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 221 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 222 SSH_PUBLICKEY_KEY_NOT_FOUND 4 223 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 224 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 225 SSH_PUBLICKEY_GENERAL_FAILURE 7 226 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 227 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 229 If a request completed successfully, the server MUST send the status 230 code SSH_PUBLICKEY_SUCCESS. The meaning of the failure codes is as 231 implied by their names. 233 3.4. The Version Packet 235 Both sides MUST start a connection by sending a version packet that 236 indicates the version of the protocol they are using. 238 string "version" 239 uint32 protocol-version-number 241 This document describes version 2 of the protocol. Version 1 was 242 used by an early draft of this document. The version number was 243 incremented after changes in the handling of status packets. 245 Both sides send the highest version that they implement. The lower 246 of the version numbers is the version of the protocol to use. If 247 either side can't support the lower version, it should close the 248 subsystem and notify the other side by sending an 249 SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a 250 status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 251 SHOULD be sent. Note that, normally, status messages are only sent 252 by the server (in response to requests from the client). This is the 253 only occasion on which the client sends a status message. 255 Both sides MUST wait to receive this version before continuing. The 256 "version" packet MUST NOT be sent again after this initial exchange. 257 The SSH_PUBLICKEY_VERSION_NOT_SUPPORTED status code must not be sent 258 in response to any other request. 260 Implementations MAY use the first 15 bytes of the version packet as a 261 "magic cookie" to avoid processing spurious output from the user's 262 shell (as described in section 6.5 of [4]). These bytes will always 263 be: 265 0x00 0x00 0x00 0x0F 0x00 0x00 0x00 0x07 0x76 0x65 0x72 0x73 0x69 0x6F 266 0x6E 268 4. Public-Key Subsystem Operations 270 The public-key subsystem currently defines four operations: add, 271 remove, list, and listattributes. 273 4.1. Adding a Public Key 275 If the client wishes to add a public key, the client sends: 277 string "add" 278 string public-key algorithm name 279 string public-key blob 280 boolean overwrite 281 uint32 attribute-count 282 string attrib-name 283 string attrib-value 284 bool critical 285 repeated attribute-count times 287 The server MUST attempt to store the public key for the user in the 288 appropriate location so the public key can be used for subsequent 289 public-key authentications. If the overwrite field is false and the 290 specified key already exists, the server MUST return 291 SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the 292 client SHOULD provide an option to the user to overwrite the key. If 293 the overwrite field is true and the specified key already exists, but 294 cannot be overwritten, the server MUST return 295 SSH_PUBLICKEY_ACCESS_DENIED. 297 Attribute names are defined following the same scheme laid out for 298 algorithm names in [1]. If the server does not implement a critical 299 attribute, it MUST fail the add, with the status code 300 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a 301 critical attribute, mere storage of the attribute is not sufficient 302 -- rather, the server must understand and implement the intent of the 303 attribute. 305 The following attributes are currently defined: 307 "comment" 309 The value of the comment attribute contains user-specified text about 310 the public key. The server SHOULD make every effort to preserve this 311 value and return it with the key during any subsequent list 312 operation. The server MUST NOT attempt to interpret or act upon the 313 content of the comment field in any way. The comment attribute must 314 be specified in UTF-8 format [7]. 316 The comment field is useful so the user can identify the key without 317 resorting to comparing its fingerprint. This attribute SHOULD NOT be 318 critical. 320 "comment-language" 322 If this attribute is specified, it MUST immediately follow a 323 "comment" attribute and specify the language for that attribute [6]. 324 The client MAY specify more than one comment if it additionally 325 specifies a different language for each of those comments. The 326 server SHOULD attempt to store each comment with its language 327 attribute. This attribute SHOULD NOT be critical. 329 "command-override" 331 "command-override" specifies a command to be executed when this key 332 is in use. The command should be executed by the server when it 333 receives an "exec" or "shell" request from the client, in place of 334 the command or shell which would otherwise have been executed as a 335 result of that request. If the command string is empty, both "exec" 336 and "shell" requests should be denied. If no "command-override" 337 attribute is specified, all "exec" and "shell" requests should be 338 permitted (as long as they satisfy other security or authorization 339 checks the server may perform). This attribute SHOULD be critical. 341 "subsystem" 343 "subsystem" specifies a comma-separated list of subsystems that may 344 be started (using a "subsystem" request) when this key is in use. 345 This attribute SHOULD be critical. If the value is empty, no 346 subsystems may be started. If the "subsystem" attribute is not 347 specified, no restrictions are placed on which subsystems may be 348 started when authenticated using this key. 350 "x11" 352 "x11" specifies that X11 forwarding may not be performed when this 353 key is in use. The attribute-value field SHOULD be empty for this 354 attribute. This attribute SHOULD be critical. 356 "shell" 358 "shell" specifies that session channel "shell" requests should be 359 denied when this key is in use. The attribute-value field SHOULD be 360 empty for this attribute. This attribute SHOULD be critical. 362 "exec" 363 "exec" specifies that session channel "exec" requests should be 364 denied when this key is in use. The attribute-value field SHOULD be 365 empty for this attribute. This attribute SHOULD be critical. 367 "agent" 369 "agent" specifies that session channel "auth-agent-req" requests 370 should be denied when this key is in use. The attribute-value field 371 SHOULD be empty for this attribute. This attribute SHOULD be 372 critical. 374 "env" 376 "env" specifies that session channel "env" requests should be denied 377 when this key is in use. The attribute-value field SHOULD be empty 378 for this attribute. This attribute SHOULD be critical. 380 "from" 382 "from" specifies a comma-separated list of hosts from which the key 383 may be used. If a host not in this list attempts to use this key for 384 authorization purposes, the authorization attempt MUST be denied. 385 The server SHOULD make a log entry regarding this. The server MAY 386 provide a method for administrators to disallow the appearance of a 387 host in this list. The server should use whatever method is 388 appropriate for its platform to identify the host - e.g. for IP-based 389 networks, checking the IP address or performing a reverse DNS lookup. 390 For IP-based networks, it is anticipated that the "from" parameter 391 will take the form of a specific IP address or hostname. 393 "port-forward" 395 "port-forward" specifies that no "direct-tcpip" requests should be 396 accepted, except those to hosts specified in the comma-separated list 397 supplied as a value to this attribute. If the value of this 398 attribute is empty, all "direct-tcpip" requests should be refused 399 when using this key. This attribute SHOULD be critical. 401 "reverse-forward" 403 "reverse-forward" specifies that no "tcpip-forward" requests should 404 be accepted, except for the port numbers in the comma-separated list 405 supplied as a value to this attribute. If the value of this 406 attribute is empty, all "tcpip-forward" requests should be refused 407 when using this key. This attribute SHOULD be critical. 409 In addition to the attributes specified by the client, the server MAY 410 provide a method for administrators to enforce certain attributes 411 compulsorily. 413 4.2. Removing a Public Key 415 If the client wishes to remove a public key, the client sends: 417 string "remove" 418 string public-key algorithm name 419 string public-key blob 421 The server MUST attempt to remove the public key for the user from 422 the appropriate location, so that the public key cannot be used for 423 subsequent authentications. 425 4.3. Listing Public Keys 427 If the client wishes to list the known public keys, the client sends: 429 string "list" 431 The server will respond with zero or more of the following responses: 433 string "publickey" 434 string public-key algorithm name 435 string public-key blob 436 uint32 attribute-count 437 string attrib-name 438 string attrib-value 439 repeated attribute-count times 441 There is no requirement that the responses be in any particular 442 order. Whilst some server implementations may send the responses in 443 some order, client implementations should not rely on responses being 444 in any order. 446 Following the last "publickey" response, a status packet MUST be 447 sent. 449 Implementations SHOULD support this request. 451 4.4. Listing Server Capabilities 453 If the client wishes to know which key attributes the server 454 supports, it sends: 456 string "listattributes" 458 The server will respond with zero or more of the following responses: 460 string "attribute" 461 string attribute name 462 boolean compulsory 464 The "compulsory" field indicates whether this attribute will be 465 compulsorily applied to any added keys (irrespective of whether the 466 attribute has been specified by the client) due to administrative 467 settings on the server. If the server does not support 468 administrative settings of this nature, it MUST return false in the 469 compulsory field. An example of use of the "compulsory" attribute 470 would be a server with a configuration file specifying that the user 471 is not permitted shell access. Given this, the server would return 472 the "shell" attribute, with "compulsory" marked true. Whatever 473 attributes the user subsequently asked the server to apply to their 474 key, the server would also apply the "shell" attribute, rendering it 475 impossible for the user to use a shell. 477 Following the last "attribute" response, a status packet MUST be 478 sent. 480 An implementation MAY choose not to support this request. 482 5. Security Considerations 484 This protocol assumes that it is run over a secure channel and that 485 the endpoints of the channel have been authenticated. Thus, this 486 protocol assumes that it is externally protected from network-level 487 attacks. 489 This protocol provides a mechanism that allows client authentication 490 data to be uploaded and manipulated. It is the responsibility of the 491 server implementation to enforce any access controls that may be 492 required to limit the access allowed for any particular user (the 493 user being authenticated externally to this protocol, typically using 494 the SSH User Authentication Protocol [3]). In particular, it is 495 possible for users to overwrite an existing key on the server with 496 this protocol, whilst at the same time specifying fewer restrictions 497 for the new key than were previously present. Servers should take 498 care that when doing this, clients are not able to override presets 499 from the server's administrator. 501 This protocol requires the client to assume that the server will 502 correctly implement and observe attributes applied to keys. 503 Implementation errors in the server could cause clients to authorize 504 keys for access they were not intended to have, or to apply fewer 505 restrictions than were intended. 507 6. IANA Considerations 509 This section contains conventions used in naming the namespaces, the 510 initial state of the registry, and instructions for future 511 assignments. 513 6.1. Registrations 515 Consistent with Section 7 of [1], this document makes the following 516 registration: 518 The subsystem name "publickey". 520 6.2. Names 522 In the following sections, the values for the namespaces are textual. 523 The conventions and instructions to the IANA for future assignments 524 are given in this section. The initial assignments are given in 525 their respective sections. 527 6.2.1. Conventions for Names 529 All names registered by the IANA in the following sections MUST be 530 printable US-ASCII strings, and MUST NOT contain the characters at- 531 sign ("@"), comma (","), or whitespace or control characters (ASCII 532 codes 32 or less). Names are case-sensitive, and MUST NOT be longer 533 than 64 characters. 535 A provision is made here for locally extensible names. The IANA will 536 not register, and will not control names with the at-sign in them. 537 Names with the at-sign in them will have the format of 538 "name@domainname" (without the double quotes) where the part 539 preceding the at-sign is the name. The format of the part preceding 540 the at-sign is not specified, however these names MUST be printable 541 US-ASCII strings, and MUST NOT contain the comma character (","), or 542 whitespace, or control characters (ASCII codes 32 or less). The part 543 following the at-sign MUST be a valid, fully qualified Internet 544 domain name [9] controlled by the person or organization defining the 545 name. Names are case-sensitive, and MUST NOT be longer than 64 546 characters. It is up to each domain how it manages its local 547 namespace. It has been noted that these names resemble STD 11 [8] 548 email addresses. This is purely coincidental and actually has 549 nothing to do with STD 11 [8]. An example of a locally defined name 550 is "our-attribute@example.com" (without the double quotes). 552 6.2.2. Future Assignments of Names 554 Requests for assignments of new Names MUST be done through the IETF 555 Consensus method as described in [10]. 557 6.3. Public-Key Subystem Request Names 559 The following table lists the initial assignments of Public-Key 560 subsystem Request names. 562 Request Name 563 ------------- 564 version 565 add 566 remove 567 list 568 listattributes 570 6.4. Public-Key Subsystem Response Names 572 The following table lists the initial assignments of Public-Key 573 subsystem Response names. 575 Response Name 576 -------------- 577 version 578 status 579 publickey 580 attribute 582 6.5. Public-Key Subsystem Attribute Names 584 Attributes are used to define properties or restrictions for public 585 keys. The following table lists the initial assignments of Public- 586 Key subsystem Attribute names. 588 Attribute Name 589 --------------- 590 comment 591 comment-language 592 command-override 593 subsystem 594 x11 595 shell 596 exec 597 agent 598 env 599 from 600 port-forward 601 reverse-forward 603 6.6. Public-Key subsystem Status Codes 605 The status code is a byte value, describing the status of a request. 607 6.6.1. Conventions 609 Status responses have status codes in the range 0 to 255. These 610 numbers are allocated as follows. Of these, the range 192 to 255 is 611 reserved for use by local, private extensions. 613 6.6.2. Initial Assignments 615 The following table identifies the initial assignments of the Public- 616 Key subsystem status code values. 618 Status code Value Reference 619 ------------ ----- --------- 620 SSH_PUBLICKEY_SUCCESS 0 621 SSH_PUBLICKEY_ACCESS_DENIED 1 622 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 623 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 624 SSH_PUBLICKEY_KEY_NOT_FOUND 4 625 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 626 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 627 SSH_PUBLICKEY_GENERAL_FAILURE 7 628 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 629 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 631 6.6.3. Future Assignments 633 Requests for assignments of new status codes in the range of 0 to 191 634 MUST be done through the Standards Action method as described in 635 [10]. 637 The IANA will not control the status code range of 192 through 255. 638 This range will be left for private use. 640 7. References 642 7.1. Normative References 644 [1] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol 645 Architecture", RFC 4251, January 2006. 647 [2] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport 648 Layer Protocol", RFC 4253, January 2006. 650 [3] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 651 Authentication Protocol", RFC 4252, January 2006. 653 [4] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection 654 Protocol", RFC 4254, January 2006. 656 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 657 Levels", BCP 14, RFC 2119, March 1997. 659 [6] Alvestrand, H., "Tags for the Identification of Languages", 660 BCP 47, RFC 3066, January 2001. 662 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 663 STD 63, RFC 3629, November 2003. 665 7.2. Informative References 667 [8] Crocker, D., "Standard for the format of ARPA Internet text 668 messages", STD 11, RFC 822, August 1982. 670 [9] Mockapetris, P., "Domain names - concepts and facilities", 671 STD 13, RFC 1034, November 1987. 673 [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 674 Considerations Section in RFCs", BCP 26, RFC 2434, 675 October 1998. 677 Authors' Addresses 679 Joseph Galbraith 680 VanDyke Software 681 4848 Tramway Ridge Blvd 682 Suite 101 683 Albuquerque, NM 87111 684 US 686 Phone: +1 505 332 5700 687 Email: galb-list@vandyke.com 689 Jeff P. Van Dyke 690 VanDyke Software 691 4848 Tramway Ridge Blvd 692 Suite 101 693 Albuquerque, NM 87111 694 US 696 Phone: +1 505 332 5700 697 Email: jpv@vandyke.com 699 Brent McClure 700 VanDyke Software 701 4848 Tramway Ridge Blvd 702 Suite 101 703 Albuquerque, NM 87111 704 US 706 Phone: +1 505 332 5700 707 Email: bdmccl@yahoo.com 709 Jon Bright 710 Silicon Circus 711 24 Jubilee Road 712 Chichester, West Sussex PO19 7XB 713 UK 715 Phone: +49 172 524 0521 716 Email: jon@siliconcircus.com 718 Full Copyright Statement 720 Copyright (C) The Internet Society (2006). 722 This document is subject to the rights, licenses and restrictions 723 contained in BCP 78, and except as set forth therein, the authors 724 retain all their rights. 726 This document and the information contained herein are provided on an 727 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 728 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 729 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 730 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 731 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 732 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 734 Intellectual Property 736 The IETF takes no position regarding the validity or scope of any 737 Intellectual Property Rights or other rights that might be claimed to 738 pertain to the implementation or use of the technology described in 739 this document or the extent to which any license under such rights 740 might or might not be available; nor does it represent that it has 741 made any independent effort to identify any such rights. Information 742 on the procedures with respect to rights in RFC documents can be 743 found in BCP 78 and BCP 79. 745 Copies of IPR disclosures made to the IETF Secretariat and any 746 assurances of licenses to be made available, or the result of an 747 attempt made to obtain a general license or permission for the use of 748 such proprietary rights by implementers or users of this 749 specification can be obtained from the IETF on-line IPR repository at 750 http://www.ietf.org/ipr. 752 The IETF invites any interested party to bring to its attention any 753 copyrights, patents or patent applications, or other proprietary 754 rights that may cover technology that may be required to implement 755 this standard. Please address the information to the IETF at 756 ietf-ipr@ietf.org. 758 Acknowledgment 760 Funding for the RFC Editor function is provided by the IETF 761 Administrative Support Activity (IASA).