idnits 2.17.1 draft-ietf-secsh-publickey-subsystem-02.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 717. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 694. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 707. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 126: '... servers SHOULD provide a configurat...' RFC 2119 keyword, line 162: '... implementations SHOULD reject this re...' RFC 2119 keyword, line 165: '... is TRUE, the server MUST respond with...' RFC 2119 keyword, line 170: '... The server SHOULD respond with SSH_...' RFC 2119 keyword, line 174: '... It is RECOMMENDED that clients requ...' (50 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 159 has weird spacing: '...boolean want...' == Line 182 has weird spacing: '... string req...' == Line 198 has weird spacing: '... string res...' == Line 209 has weird spacing: '... string des...' == Line 210 has weird spacing: '... string lan...' == (13 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 (March 17, 2005) is 6951 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC-2279' on line 209 -- Looks like a reference, but probably isn't: 'RFC-1766' on line 210 ** Obsolete normative reference: RFC 1766 (ref. '5') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2279 (ref. '6') (Obsoleted by RFC 3629) -- Obsolete informational reference (is this intentional?): RFC 822 (ref. '7') (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '9') (Obsoleted by RFC 5226) Summary: 9 errors (**), 0 flaws (~~), 8 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 Expires: September 18, 2005 B. McClure 5 VanDyke Software 6 J. Bright 7 Silicon Circus 8 March 17, 2005 10 Secure Shell Public-Key Subsystem 11 draft-ietf-secsh-publickey-subsystem-02.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 18, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 SECSH defines an authentication mechanism that is based on public 47 keys, but does not define any mechanism for key distribution. No 48 common key management solution exists in current implementations. 50 This document describes a protocol that can be used to configure 51 public keys in an implementation-independent fashion, allowing client 52 software to take on the burden of this configuration. 54 This protocol is intended to be used from the Secure Shell Connection 55 Protocol [4] as a subsystem, as described in the Section "Starting a 56 Shell or a Command". The subsystem name used with this protocol is 57 "publickey". 59 The public-key subsystem provides a server-independent mechanism for 60 clients to add public keys, remove public keys, and list the current 61 public keys known by the server. Rights to manage public keys are 62 specific and limited to the authenticated user. 64 A public key may also be associated with various restrictions, 65 including a mandatory command or subsystem. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Public-Key Subsystem Overview . . . . . . . . . . . . . . . . 5 71 2.1 Opening the Public-Key Subsystem . . . . . . . . . . . . . 5 72 2.2 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 2.3 Responses . . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.3.1 The Status Response . . . . . . . . . . . . . . . . . 6 75 3. Public-Key Subsystem Operations . . . . . . . . . . . . . . . 8 76 3.1 Version Packet . . . . . . . . . . . . . . . . . . . . . . 8 77 3.2 Adding a public key . . . . . . . . . . . . . . . . . . . 8 78 3.3 Removing a public key . . . . . . . . . . . . . . . . . . 11 79 3.4 Listing public keys . . . . . . . . . . . . . . . . . . . 11 80 3.5 Listing server capabilities . . . . . . . . . . . . . . . 11 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 5.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 14 84 5.2 Names . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 5.2.1 Conventions for Names . . . . . . . . . . . . . . . . 14 86 5.2.2 Future Assignments of Names . . . . . . . . . . . . . 14 87 5.3 Request names . . . . . . . . . . . . . . . . . . . . . . 15 88 5.4 Response names . . . . . . . . . . . . . . . . . . . . . . 15 89 5.5 Attribute names . . . . . . . . . . . . . . . . . . . . . 15 90 5.6 Status codes . . . . . . . . . . . . . . . . . . . . . . . 16 91 5.6.1 Conventions . . . . . . . . . . . . . . . . . . . . . 16 92 5.6.2 Initial Assignments . . . . . . . . . . . . . . . . . 16 93 5.6.3 Future Assignments . . . . . . . . . . . . . . . . . . 16 94 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 6.1 Normative References . . . . . . . . . . . . . . . . . . . 17 96 6.2 Informative References . . . . . . . . . . . . . . . . . . 17 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 98 Intellectual Property and Copyright Statements . . . . . . . . 19 100 1. Introduction 102 SECSH is a protocol for secure remote login and other secure network 103 services over an insecure network. SECSH defines an authentication 104 mechanism that is based on public keys, but does not define any 105 mechanism for key distribution. Common practice is to authenticate 106 once with password authentication and transfer the public key to the 107 server. However, to date no two implementations use the same 108 mechanism to configure a public key for use. 110 This document describes a subsystem that can be used to configure 111 public keys in an implementation-independent fashion. This approach 112 allows client software to take on the burden of this configuration. 113 The public-key subsystem protocol is designed for extreme simplicity 114 in implementation. It is not intended as a PKIX replacement. 116 The Secure Shell Public-Key subsystem has been designed to run on top 117 of the SECSH transport layer [2] and user authentication protocols 118 [3]. It provides a simple mechanism for the client to manage public 119 keys on the server. 121 This document should be read only after reading the SECSH 122 architecture [1] and SECSH connection [4] documents. 124 This protocol requires that the user be able to authenticate in some 125 fashion before it can be used. If password authentication is used, 126 servers SHOULD provide a configuration option to disable the use of 127 password authentication after the first public key is added. 129 2. Public-Key Subsystem Overview 131 The public-key subsystem provides a server-independent mechanism for 132 clients to add public keys, remove public keys, and list the current 133 public keys known by the server. The subsystem name is "publickey". 135 The public keys added, removed, and listed using this protocol are 136 specific and limited to those of the authenticated user. 138 The operations to add, remove and list the authenticated user's 139 public keys are performed as request packets sent to the server. The 140 server sends response packets that indicate success or failure as 141 well as provide specific response data. 143 The format of public-key blobs are detailed in the SSH Transport 144 Protocol document [2]. 146 2.1 Opening the Public-Key Subsystem 148 The public-key subsystem is opened when the clients sends a 149 SSH_MSG_CHANNEL_REQUEST over an existing session. 151 The details of how a session is opened are described in the SSH 152 Connection Protocol document [4] in the section "Opening a Session". 154 To open the public-key subsystem, the client sends: 156 byte SSH_MSG_CHANNEL_REQUEST 157 uint32 recipient channel 158 string "subsystem" 159 boolean want reply 160 string "publickey" 162 Client implementations SHOULD reject this request; it is normally 163 only sent by the client. 165 If want reply is TRUE, the server MUST respond with 166 SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully 167 started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or 168 does not support the public-key subsystem. 170 The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user 171 authenticated with a restricted public key that does not allow access 172 to the publickey subsystem. 174 It is RECOMMENDED that clients request and check the reply for this 175 request. 177 2.2 Requests 179 All public-key subsystem requests are sent in the following form: 181 uint32 length 182 string request-name 183 ... request specific data follows 185 The length field describes the length of the request-name field and 186 the request-specific data, but not of the length field itself. The 187 client MUST receive acknowledgement of each request prior to sending 188 a new request. 190 All requests described in Section 3 are a description of the 191 'request-name' and 'data' portion of the packet. 193 2.3 Responses 195 All public-key subsystem responses are sent in the following form: 197 uint32 length 198 string response-name 199 ... response specific data follows 201 2.3.1 The Status Response 203 A request is acknowledged by sending a status packet. If there is 204 data in response to the request, the status packet is sent after all 205 data has been sent. 207 string "status" 208 uint32 status code 209 string description [RFC-2279] 210 string language tag [RFC-1766] 212 A status message MUST be sent for any unrecognized packets and the 213 request SHOULD NOT close the subsystem. 215 2.3.1.1 Status Codes 217 The status code gives the status in a more machine-readable format 218 (suitable for localization), and can have the following values: 220 SSH_PUBLICKEY_SUCCESS 0 221 SSH_PUBLICKEY_ACCESS_DENIED 1 222 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 223 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 224 SSH_PUBLICKEY_KEY_NOT_FOUND 4 225 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 226 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 227 SSH_PUBLICKEY_GENERAL_FAILURE 7 228 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 230 3. Public-Key Subsystem Operations 232 The public-key subsystem currently defines four operations: add, 233 remove, list, and listattributes. 235 3.1 Version Packet 237 Both sides MUST start by sending a version packet that indicates the 238 version of the protocol they are using. 240 string "version" 241 uint32 protocol-version-number 243 The version of the protocol described by this document is version 2. 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. 253 Both sides MUST wait to receive this version before continuing. The 254 "version" packet MUST NOT be sent again after this initial exchange. 256 3.2 Adding a public key 258 If the client wishes to add a public key, the client sends: 260 string "add" 261 string public-key algorithm name 262 string public-key blob 263 boolean overwrite 264 uint32 attribute-count 265 string attrib-name 266 string attrib-value 267 bool mandatory 268 repeated attribute-count times 270 The server MUST attempt to store the public key for the user in the 271 appropriate location so the public key can be used for subsequent 272 public-key authentications. If the overwrite field is false and the 273 specified key already exists, the server MUST return 274 SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the 275 client SHOULD provide an option to the user to overwrite the key. If 276 the overwrite field is true and the specified key already exists but 277 cannot be overwritten, the server MUST return 278 SSH_PUBLICKEY_ACCESS_DENIED 280 Attribute names are defined following the same scheme laid out for 281 algorithm names in [1]. If the server does not implement a mandatory 282 attribute, it MUST fail the add. For the purposes of a mandatory 283 attribute, storage of the attribute is not sufficient, but requires 284 that the server understand and implement the intent of the attribute. 286 The following attributes are currently defined: 288 "comment" 290 The value of the comment attribute contains user-specified text about 291 the public key. The server SHOULD make every effort to preserve this 292 value and return it with the key during any subsequent list 293 operation. The server MUST NOT attempt to interpret or act upon the 294 content of the comment field in any way. The comment attribute must 295 be specified in UTF-8 format [6]. 297 The comment field is useful so the user can identify the key without 298 resorting to comparing its fingerprint. This attribute SHOULD NOT be 299 mandatory. 301 "comment-language" 303 If this attribute is specified, it MUST immediately follow a 304 "comment" attribute and specifies the language for that attribute 305 [5]. The client MAY specify more than comment if it additionally 306 specifies a different language for each of those comments. The 307 server SHOULD attempt to store each comment, together with that 308 comment's lanuage attribute. This attribute SHOULD NOT be mandatory. 310 "command-override" 312 "command-override" specifies a command to be executed when this key 313 is in use. The command should be executed by the server when it 314 receives an "exec" or "shell" request from the client, in place of 315 the command or shell which would otherwise have been executed as a 316 result of that request. If the command string is empty, both "exec" 317 and "shell" requests should be denied. If no "command-override" 318 attribute is specified, all "exec" and "shell" requests should be 319 permitted (as long as they satisfy other security or authorisation 320 checks the server may perform). This attribute SHOULD be mandatory. 322 "subsystem" 324 "subsystem" specifies a comma-separated list of subsystems that may 325 be started (using a "subsystem" request) when this key is in use. 327 This attribute SHOULD be mandatory. If the value is empty, no 328 subsystems may be started. 330 "x11" 332 "x11" specifies that X11 forwarding may not be performed when this 333 key is in use. The attribute-value field SHOULD be empty for this 334 attribute. This attribute SHOULD be mandatory. 336 "shell" 338 "shell" specifies that session channel "shell" requests should be 339 denied when this key is in use. The attribute-value field SHOULD be 340 empty for this attribute. This attribute SHOULD be mandatory. 342 "exec" 344 "exec" specifies that session channel "exec" requests should be 345 denied when this key is in use. The attribute-value field SHOULD be 346 empty for this attribute. This attribute SHOULD be mandatory. 348 "agent" 350 "agent" specifies that session channel "auth-agent-req" requests 351 should be denied when this key is in use. The attribute-value field 352 SHOULD be empty for this attribute. This attribute SHOULD be 353 mandatory. 355 "env" 357 "env" specifies that session channel "env" requests should be denied 358 when this key is in use. The attribute-value field SHOULD be empty 359 for this attribute. This attribute SHOULD be mandatory. 361 "from" 363 "from" specifies a comma-separated list of hosts from which the key 364 may be used. If a host not in this list attempts to use this key for 365 authorisation purposes, the authorisation attempt MUST be denied. 366 The server SHOULD make a log entry regarding this. 368 "port-forward" 370 "port-forward" specifies that no "direct-tcpip" requests should be 371 accepted, except to those hosts specified in the comma-separated list 372 supplied as a value to this attribute. If the value of this 373 attribute is empty, all "direct-tcpip" requests should be refused 374 when using this key. This attribute SHOULD be mandatory. 376 "reverse-forward" 378 "reverse-forward" specifies that no "tcpip-forward" requests should 379 be accepted, accept for the port numbers in the comma-separated list 380 supplied as a value to this attribute. If the value of this 381 attribute is empty, all "tcpip-forward" requests should be refused 382 when using this key. This attribute SHOULD be mandatory. 384 In addition to the attributes specified by the client, the server MAY 385 provide a method for administrators to compulsorily enforce certain 386 attributes. 388 3.3 Removing a public key 390 If the client wishes to remove a public key, the client sends: 392 string "remove" 393 string public-key algorithm name 394 string public-key blob 396 The server MUST attempt to remove the public key for the user from 397 the appropriate location, so that the public key cannot be used for 398 subsequent authentications. 400 3.4 Listing public keys 402 If the client wishes to list the known public keys, the client sends: 404 string "list" 406 The server will respond with zero or more of the following responses: 408 string "publickey" 409 string public-key algorithm name 410 string public-key blob 411 uint32 attribute-count 412 string attrib-name 413 string attrib-value 414 repeated attribute-count times 416 Following the last "publickey" response, a status packet MUST be 417 sent. 419 An implementation MAY choose not to support this request. 421 3.5 Listing server capabilities 423 If the client wishes to know which key attributes the server 424 supports, it sends: 426 string "listattributes" 428 The server will respond with zero or more of the following responses: 430 string "attribute" 431 string attribute name 432 boolean compulsory 434 The "compulsory" field indicates whether this attribute will be 435 compulsorily applied to any added keys (irrespective of whether the 436 attribute has been specified by the client) due to administrative 437 settings on the server. If the server does not support 438 administrative settings of this nature, it MUST return false in the 439 compulsory field. An example of use of the "compulsory" attribute 440 would be a server with a configuration file specifying that the user 441 is not permitted shell access. Given this, the server would return 442 the "shell" attribute, with "compulsory" marked true. Whatever 443 attributes the user subsequently asked the server to apply to their 444 key, the server would also apply the "shell" attribute, rendering it 445 impossible for the user to use a shell. 447 Following the last "attribute" response, a status packet MUST be 448 sent. 450 An implementation MAY choose not to support this request. 452 4. Security Considerations 454 This protocol assumes that it is run over a secure channel and that 455 the endpoints of the channel have been authenticated. Thus, this 456 protocol assumes that it is externally protected from network-level 457 attacks. 459 This protocol provides a mechanism that allows client authentication 460 data to be uploaded and manipulated. It is the responsibility of the 461 server implementation to enforce any access controls that may be 462 required to limit the access allowed for any particular user (the 463 user being authenticated externally to this protocol, typically using 464 the SSH User Authentication Protocol [3]). In particular, it is 465 possible for users to overwrite an existing key on the server with 466 this protocol, whilst at the same time specifying fewer restrictions 467 for the new key than were previously present. Servers should take 468 care that when doing this, clients are not able to override presets 469 from the server's administrator. 471 This protocol requires the client to assume that the server will 472 correctly implement and observe attributes applied to keys. 473 Implementation errors in the server could cause clients to authorise 474 keys for access they were not intended to have, or to apply fewer 475 restrictions than were intended. 477 5. IANA Considerations 479 This section contains conventions used in naming the namespaces, the 480 initial state of the registry, and instructions for future 481 assignments. 483 5.1 Registrations 485 Consistent with section 7 of [1], this document makes the following 486 registration: 488 The subsystem name "publickey". 490 5.2 Names 492 In the following sections, the values for the name spaces are 493 textual. The conventions and instructions to the IANA for future 494 assignments are given in this section. The initial assignments are 495 given in their respective sections. 497 5.2.1 Conventions for Names 499 All names registered by the IANA in the following sections MUST be 500 printable US-ASCII strings, and MUST NOT contain the characters 501 at-sign ("@"), comma (","), or whitespace or control characters 502 (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be 503 longer than 64 characters. 505 A provision is made here for locally extensible names. The IANA will 506 not register, and will not control names with the at-sign in them. 507 Names with the at-sign in them will have the format of 508 "name@domainname" (without the double quotes) where the part 509 preceeding the at-sign is the name. The format of the part preceding 510 the at-sign is not specified, however these names MUST be printable 511 US-ASCII strings, and MUST NOT contain the comma character (","), or 512 whitespace, or control characters (ASCII codes 32 or less). The part 513 following the at-sign MUST be a valid, fully qualified internet 514 domain name [8] controlled by the person or organization defining the 515 name. Names are case-sensitive, and MUST NOT be longer than 64 516 characters. It is up to each domain how it manages its local 517 namespace. It has been noted that these names resemble STD 11 [7] 518 email addresses. This is purely coincidental and actually has 519 nothing to do with STD 11 [7]. An example of a locally defined name 520 is "ourcipher-cbc@example.com" (without the double quotes). 522 5.2.2 Future Assignments of Names 524 Requests for assignments of new Names MUST be done through the IETF 525 CONSENSUS method as described in [9]. 527 5.3 Request names 529 The following table lists the initial assignments of Request names 531 Request Name 532 ------------- 533 version 534 add 535 remove 536 list 537 listattributes 539 5.4 Response names 541 The following table lists the initial assignments of Response names 543 Response Name 544 -------------- 545 version 546 status 547 publickey 548 attribute 550 5.5 Attribute names 552 Attributes are used to define properties or restrictions for public 553 keys. The following table lists the initial assignments of Response 554 names 556 Attribute Name 557 --------------- 558 comment 559 comment-language 560 command-override 561 subsystem 562 x11 563 shell 564 exec 565 agent 566 env 567 from 568 port-forward 569 reverse-forward 571 5.6 Status codes 573 The status code is a byte value, describing the status of a request. 575 5.6.1 Conventions 577 Status responses have status codes in the range 0 to 255. These 578 numbers are allocated as follows. Of these, the range 192 to 255 is 579 reserved for use by local, private extensions. 581 5.6.2 Initial Assignments 583 The following table identifies the initial assignments of the status 584 code values. 586 Status code Value Reference 587 ------------ ----- --------- 588 SSH_PUBLICKEY_SUCCESS 0 589 SSH_PUBLICKEY_ACCESS_DENIED 1 590 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 591 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 592 SSH_PUBLICKEY_KEY_NOT_FOUND 4 593 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 594 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 595 SSH_PUBLICKEY_GENERAL_FAILURE 7 596 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 598 5.6.3 Future Assignments 600 Requests for assignments of new message numbers in the range of 0 to 601 191 MUST be done through the STANDARDS ACTION method as described in 602 [9]. 604 The IANA will not control the message numbers range of 192 through 605 255. This range will be left for PRIVATE USE. 607 6. References 609 6.1 Normative References 611 [1] Lonvick, C., "SSH Protocol Architecture", 612 Internet-Draft draft-ietf-secsh-architecture-22, March 2005. 614 [2] Lonvick, C., "SSH Transport Layer Protocol", 615 Internet-Draft draft-ietf-secsh-transport-24, March 2005. 617 [3] Lonvick, C., "SSH Authentication Protocol", 618 Internet-Draft draft-ietf-secsh-userauth-27, March 2005. 620 [4] Lonvick, C., "SSH Connection Protocol", 621 Internet-Draft draft-ietf-secsh-connect-25, March 2005. 623 [5] Alvestrand, H., "Tags for the Identification of Languages", 624 RFC 1766, March 1995. 626 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 627 RFC 2279, January 1998. 629 6.2 Informative References 631 [7] Crocker, D., "Standard for the format of ARPA Internet text 632 messages", STD 11, RFC 822, August 1982. 634 [8] Mockapetris, P., "Domain names - concepts and facilities", 635 STD 13, RFC 1034, November 1987. 637 [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 638 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 640 Authors' Addresses 642 Joseph Galbraith 643 VanDyke Software 644 4848 Tramway Ridge Blvd 645 Suite 101 646 Albuquerque, NM 87111 647 US 649 Phone: +1 505 332 5700 650 Email: galb-list@vandyke.com 651 Jeff P. Van Dyke 652 VanDyke Software 653 4848 Tramway Ridge Blvd 654 Suite 101 655 Albuquerque, NM 87111 656 US 658 Phone: +1 505 332 5700 659 Email: jpv@vandyke.com 661 Brent McClure 662 VanDyke Software 663 4848 Tramway Ridge Blvd 664 Suite 101 665 Albuquerque, NM 87111 666 US 668 Phone: +1 505 332 5700 669 Email: bdm@vandyke.com 671 Jon Bright 672 Silicon Circus 673 24 Jubilee Road 674 Chichester, West Sussex PO19 7XB 675 UK 677 Phone: +49 172 524 0521 678 Email: jon@siliconcircus.com 680 Trademark notice 682 "ssh" is a registered trademark in the United States and/or other 683 countries. 685 Intellectual Property Statement 687 The IETF takes no position regarding the validity or scope of any 688 Intellectual Property Rights or other rights that might be claimed to 689 pertain to the implementation or use of the technology described in 690 this document or the extent to which any license under such rights 691 might or might not be available; nor does it represent that it has 692 made any independent effort to identify any such rights. Information 693 on the procedures with respect to rights in RFC documents can be 694 found in BCP 78 and BCP 79. 696 Copies of IPR disclosures made to the IETF Secretariat and any 697 assurances of licenses to be made available, or the result of an 698 attempt made to obtain a general license or permission for the use of 699 such proprietary rights by implementers or users of this 700 specification can be obtained from the IETF on-line IPR repository at 701 http://www.ietf.org/ipr. 703 The IETF invites any interested party to bring to its attention any 704 copyrights, patents or patent applications, or other proprietary 705 rights that may cover technology that may be required to implement 706 this standard. Please address the information to the IETF at 707 ietf-ipr@ietf.org. 709 Disclaimer of Validity 711 This document and the information contained herein are provided on an 712 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 713 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 714 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 715 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 716 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 717 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 719 Copyright Statement 721 Copyright (C) The Internet Society (2005). This document is subject 722 to the rights, licenses and restrictions contained in BCP 78, and 723 except as set forth therein, the authors retain all their rights. 725 Acknowledgment 727 Funding for the RFC Editor function is currently provided by the 728 Internet Society.