idnits 2.17.1 draft-ietf-secsh-publickey-subsystem-04.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 718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 708. ** 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 '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 123: '... servers SHOULD provide a configurat...' RFC 2119 keyword, line 159: '... implementations SHOULD reject this re...' RFC 2119 keyword, line 162: '... is TRUE, the server MUST respond with...' RFC 2119 keyword, line 167: '... The server SHOULD respond with SSH_...' RFC 2119 keyword, line 171: '... It is RECOMMENDED that clients requ...' (51 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 156 has weird spacing: '...boolean want...' == Line 180 has weird spacing: '... string nam...' == Line 200 has weird spacing: '... string des...' == Line 201 has weird spacing: '... string lan...' == Line 261 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 (September 13, 2005) is 6794 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 200 -- Looks like a reference, but probably isn't: 'RFC-1766' on line 201 ** 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: 7 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: March 17, 2006 B. McClure 5 VanDyke Software 6 J. Bright 7 Silicon Circus 8 September 13, 2005 10 Secure Shell Public-Key Subsystem 11 draft-ietf-secsh-publickey-subsystem-04.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 March 17, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 SECSH defines an authentication mechanism that is based on public 45 keys, but does not define any mechanism for key distribution. No 46 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 This protocol is intended to be used from the Secure Shell Connection 52 Protocol [4] as a subsystem, as described in the Section "Starting a 53 Shell or a Command". The subsystem name used with this protocol is 54 "publickey". 56 The public-key subsystem provides a server-independent mechanism for 57 clients to add public keys, remove public keys, and list the current 58 public keys known by the server. Rights to manage public keys are 59 specific and limited to the authenticated user. 61 A public key may also be associated with various restrictions, 62 including a mandatory command or subsystem. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Public-Key Subsystem Overview . . . . . . . . . . . . . . . . 4 68 2.1. Opening the Public-Key Subsystem . . . . . . . . . . . . . 4 69 2.2. Requests and Responses . . . . . . . . . . . . . . . . . . 5 70 2.3. The Status Message . . . . . . . . . . . . . . . . . . . . 5 71 2.3.1. Status Codes . . . . . . . . . . . . . . . . . . . . . 5 72 2.4. The Version Packet . . . . . . . . . . . . . . . . . . . . 6 73 3. Public-Key Subsystem Operations . . . . . . . . . . . . . . . 7 74 3.1. Adding a public key . . . . . . . . . . . . . . . . . . . 7 75 3.2. Removing a public key . . . . . . . . . . . . . . . . . . 10 76 3.3. Listing public keys . . . . . . . . . . . . . . . . . . . 10 77 3.4. Listing server capabilities . . . . . . . . . . . . . . . 10 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 5.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 13 81 5.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 5.2.1. Conventions for Names . . . . . . . . . . . . . . . . 13 83 5.2.2. Future Assignments of Names . . . . . . . . . . . . . 13 84 5.3. Request names . . . . . . . . . . . . . . . . . . . . . . 14 85 5.4. Response names . . . . . . . . . . . . . . . . . . . . . . 14 86 5.5. Attribute names . . . . . . . . . . . . . . . . . . . . . 14 87 5.6. Status codes . . . . . . . . . . . . . . . . . . . . . . . 15 88 5.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 15 89 5.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 15 90 5.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 15 91 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 93 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 95 Intellectual Property and Copyright Statements . . . . . . . . . . 18 97 1. Introduction 99 SECSH is a protocol for secure remote login and other secure network 100 services over an insecure network. SECSH defines an authentication 101 mechanism that is based on public keys, but does not define any 102 mechanism for key distribution. Common practice is to authenticate 103 once with password authentication and transfer the public key to the 104 server. However, to date no two implementations use the same 105 mechanism to configure a public key for use. 107 This document describes a subsystem that can be used to configure 108 public keys in an implementation-independent fashion. This approach 109 allows client software to take on the burden of this configuration. 110 The public-key subsystem protocol is designed for extreme simplicity 111 in implementation. It is not intended as a PKIX replacement. 113 The Secure Shell Public-Key subsystem has been designed to run on top 114 of the SECSH transport layer [2] and user authentication protocols 115 [3]. It provides a simple mechanism for the client to manage public 116 keys on the server. 118 This document should be read only after reading the SECSH 119 architecture [1] and SECSH connection [4] documents. 121 This protocol requires that the user be able to authenticate in some 122 fashion before it can be used. If password authentication is used, 123 servers SHOULD provide a configuration option to disable the use of 124 password authentication after the first public key is added. 126 2. Public-Key Subsystem Overview 128 The public-key subsystem provides a server-independent mechanism for 129 clients to add public keys, remove public keys, and list the current 130 public keys known by the server. The subsystem name is "publickey". 132 The public keys added, removed, and listed using this protocol are 133 specific and limited to those of the authenticated user. 135 The operations to add, remove and list the authenticated user's 136 public keys are performed as request packets sent to the server. The 137 server sends response packets that indicate success or failure as 138 well as provide specific response data. 140 The format of public-key blobs are detailed in the SSH Transport 141 Protocol document [2]. 143 2.1. Opening the Public-Key Subsystem 145 The public-key subsystem is started by a client sending an 146 SSH_MSG_CHANNEL_REQUEST over an existing session's channel. 148 The details of how a session is opened are described in the SSH 149 Connection Protocol document [4] in the section "Opening a Session". 151 To open the public-key subsystem, the client sends: 153 byte SSH_MSG_CHANNEL_REQUEST 154 uint32 recipient channel 155 string "subsystem" 156 boolean want reply 157 string "publickey" 159 Client implementations SHOULD reject this request; it is normally 160 sent only by the client. 162 If want reply is TRUE, the server MUST respond with 163 SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully 164 started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or 165 does not support the public-key subsystem. 167 The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user is 168 not allowed access to the publickey subsystem (for example because 169 the user authenticated with a restricted public key). 171 It is RECOMMENDED that clients request and check the reply for this 172 request. 174 2.2. Requests and Responses 176 All public-key subsystem requests and responses are sent in the 177 following form: 179 uint32 length 180 string name 181 ... request/response specific data follows 183 The length field describes the length of the name field and the 184 request/response-specific data, but does not include the length of 185 the length field itself. The client MUST receive acknowledgement of 186 each request prior to sending a new request. 188 The version packet, as well as all requests and responses described 189 in Section 3, are a description of the 'name' field and the data part 190 of the packet. 192 2.3. The Status Message 194 A request is acknowledged by sending a status packet. If there is 195 data in response to the request, the status packet is sent after all 196 data has been sent. 198 string "status" 199 uint32 status code 200 string description [RFC-2279] 201 string language tag [RFC-1766] 203 A status message MUST be sent for any unrecognized packets and the 204 request SHOULD NOT close the subsystem. 206 2.3.1. Status Codes 208 The status code gives the status in a more machine-readable format 209 (suitable for localization), and can have the following values: 211 SSH_PUBLICKEY_SUCCESS 0 212 SSH_PUBLICKEY_ACCESS_DENIED 1 213 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 214 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 215 SSH_PUBLICKEY_KEY_NOT_FOUND 4 216 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 217 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 218 SSH_PUBLICKEY_GENERAL_FAILURE 7 219 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 220 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 222 If a request completed successfully, the server MUST send the status 223 code SSH_PUBLICKEY_SUCCESS. The meaning of the failure codes is as 224 implied by their names. 226 2.4. The Version Packet 228 Both sides MUST start by sending a version packet that indicates the 229 version of the protocol they are using. 231 string "version" 232 uint32 protocol-version-number 234 The version of the protocol described by this document is version 2. 236 Both sides send the highest version that they implement. The lower 237 of the version numbers is the version of the protocol to use. If 238 either side can't support the lower version, it should close the 239 subsystem and notify the other side by sending an 240 SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a 241 status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 242 SHOULD be sent. Note that normally, status messages are only sent by 243 the server (in response to requests from the client). This is the 244 only occasion on which the client sends a status message. 246 Both sides MUST wait to receive this version before continuing. The 247 "version" packet MUST NOT be sent again after this initial exchange. 248 The SSH_PUBLICKEY_VERSION_NOT_SUPPORTED status code must not be sent 249 in response to any other request. 251 3. Public-Key Subsystem Operations 253 The public-key subsystem currently defines four operations: add, 254 remove, list, and listattributes. 256 3.1. 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, with the status code 283 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a 284 mandatory attribute, mere storage of the attribute is not sufficient 285 -- rather, the server must understand and implement the intent of the 286 attribute. 288 The following attributes are currently defined: 290 "comment" 292 The value of the comment attribute contains user-specified text about 293 the public key. The server SHOULD make every effort to preserve this 294 value and return it with the key during any subsequent list 295 operation. The server MUST NOT attempt to interpret or act upon the 296 content of the comment field in any way. The comment attribute must 297 be specified in UTF-8 format [6]. 299 The comment field is useful so the user can identify the key without 300 resorting to comparing its fingerprint. This attribute SHOULD NOT be 301 mandatory. 303 "comment-language" 305 If this attribute is specified, it MUST immediately follow a 306 "comment" attribute and specifies the language for that attribute 307 [5]. The client MAY specify more than one comment if it additionally 308 specifies a different language for each of those comments. The 309 server SHOULD attempt to store each comment, together with that 310 comment's lanuage attribute. This attribute SHOULD NOT be mandatory. 312 "command-override" 314 "command-override" specifies a command to be executed when this key 315 is in use. The command should be executed by the server when it 316 receives an "exec" or "shell" request from the client, in place of 317 the command or shell which would otherwise have been executed as a 318 result of that request. If the command string is empty, both "exec" 319 and "shell" requests should be denied. If no "command-override" 320 attribute is specified, all "exec" and "shell" requests should be 321 permitted (as long as they satisfy other security or authorisation 322 checks the server may perform). This attribute SHOULD be mandatory. 324 "subsystem" 326 "subsystem" specifies a comma-separated list of subsystems that may 327 be started (using a "subsystem" request) when this key is in use. 328 This attribute SHOULD be mandatory. If the value is empty, no 329 subsystems may be started. If the "subsystem" attribute is not 330 specified, no restrictions are placed on which subsystems may be 331 started when authenticated using this key. 333 "x11" 335 "x11" specifies that X11 forwarding may not be performed when this 336 key is in use. The attribute-value field SHOULD be empty for this 337 attribute. This attribute SHOULD be mandatory. 339 "shell" 341 "shell" specifies that session channel "shell" requests should be 342 denied when this key is in use. The attribute-value field SHOULD be 343 empty for this attribute. This attribute SHOULD be mandatory. 345 "exec" 346 "exec" specifies that session channel "exec" requests should be 347 denied when this key is in use. The attribute-value field SHOULD be 348 empty for this attribute. This attribute SHOULD be mandatory. 350 "agent" 352 "agent" specifies that session channel "auth-agent-req" requests 353 should be denied when this key is in use. The attribute-value field 354 SHOULD be empty for this attribute. This attribute SHOULD be 355 mandatory. 357 "env" 359 "env" specifies that session channel "env" requests should be denied 360 when this key is in use. The attribute-value field SHOULD be empty 361 for this attribute. This attribute SHOULD be mandatory. 363 "from" 365 "from" specifies a comma-separated list of hosts from which the key 366 may be used. If a host not in this list attempts to use this key for 367 authorisation purposes, the authorisation attempt MUST be denied. 368 The server SHOULD make a log entry regarding this. The server MAY 369 provide a method for administrators to disallow the appearance of a 370 host in this list. 372 "port-forward" 374 "port-forward" specifies that no "direct-tcpip" requests should be 375 accepted, except to those hosts specified in the comma-separated list 376 supplied as a value to this attribute. If the value of this 377 attribute is empty, all "direct-tcpip" requests should be refused 378 when using this key. This attribute SHOULD be mandatory. 380 "reverse-forward" 382 "reverse-forward" specifies that no "tcpip-forward" requests should 383 be accepted, accept for the port numbers in the comma-separated list 384 supplied as a value to this attribute. If the value of this 385 attribute is empty, all "tcpip-forward" requests should be refused 386 when using this key. This attribute SHOULD be mandatory. 388 In addition to the attributes specified by the client, the server MAY 389 provide a method for administrators to compulsorily enforce certain 390 attributes. 392 3.2. Removing a public key 394 If the client wishes to remove a public key, the client sends: 396 string "remove" 397 string public-key algorithm name 398 string public-key blob 400 The server MUST attempt to remove the public key for the user from 401 the appropriate location, so that the public key cannot be used for 402 subsequent authentications. 404 3.3. Listing public keys 406 If the client wishes to list the known public keys, the client sends: 408 string "list" 410 The server will respond with zero or more of the following responses: 412 string "publickey" 413 string public-key algorithm name 414 string public-key blob 415 uint32 attribute-count 416 string attrib-name 417 string attrib-value 418 repeated attribute-count times 420 Following the last "publickey" response, a status packet MUST be 421 sent. 423 An implementation MAY choose not to support this request. 425 3.4. Listing server capabilities 427 If the client wishes to know which key attributes the server 428 supports, it sends: 430 string "listattributes" 432 The server will respond with zero or more of the following responses: 434 string "attribute" 435 string attribute name 436 boolean compulsory 438 The "compulsory" field indicates whether this attribute will be 439 compulsorily applied to any added keys (irrespective of whether the 440 attribute has been specified by the client) due to administrative 441 settings on the server. If the server does not support 442 administrative settings of this nature, it MUST return false in the 443 compulsory field. An example of use of the "compulsory" attribute 444 would be a server with a configuration file specifying that the user 445 is not permitted shell access. Given this, the server would return 446 the "shell" attribute, with "compulsory" marked true. Whatever 447 attributes the user subsequently asked the server to apply to their 448 key, the server would also apply the "shell" attribute, rendering it 449 impossible for the user to use a shell. 451 Following the last "attribute" response, a status packet MUST be 452 sent. 454 An implementation MAY choose not to support this request. 456 4. Security Considerations 458 This protocol assumes that it is run over a secure channel and that 459 the endpoints of the channel have been authenticated. Thus, this 460 protocol assumes that it is externally protected from network-level 461 attacks. 463 This protocol provides a mechanism that allows client authentication 464 data to be uploaded and manipulated. It is the responsibility of the 465 server implementation to enforce any access controls that may be 466 required to limit the access allowed for any particular user (the 467 user being authenticated externally to this protocol, typically using 468 the SSH User Authentication Protocol [3]). In particular, it is 469 possible for users to overwrite an existing key on the server with 470 this protocol, whilst at the same time specifying fewer restrictions 471 for the new key than were previously present. Servers should take 472 care that when doing this, clients are not able to override presets 473 from the server's administrator. 475 This protocol requires the client to assume that the server will 476 correctly implement and observe attributes applied to keys. 477 Implementation errors in the server could cause clients to authorise 478 keys for access they were not intended to have, or to apply fewer 479 restrictions than were intended. 481 5. IANA Considerations 483 This section contains conventions used in naming the namespaces, the 484 initial state of the registry, and instructions for future 485 assignments. 487 5.1. Registrations 489 Consistent with section 7 of [1], this document makes the following 490 registration: 492 The subsystem name "publickey". 494 5.2. Names 496 In the following sections, the values for the name spaces are 497 textual. The conventions and instructions to the IANA for future 498 assignments are given in this section. The initial assignments are 499 given in their respective sections. 501 5.2.1. Conventions for Names 503 All names registered by the IANA in the following sections MUST be 504 printable US-ASCII strings, and MUST NOT contain the characters at- 505 sign ("@"), comma (","), or whitespace or control characters (ASCII 506 codes 32 or less). Names are case-sensitive, and MUST NOT be longer 507 than 64 characters. 509 A provision is made here for locally extensible names. The IANA will 510 not register, and will not control names with the at-sign in them. 511 Names with the at-sign in them will have the format of 512 "name@domainname" (without the double quotes) where the part 513 preceeding the at-sign is the name. The format of the part preceding 514 the at-sign is not specified, however these names MUST be printable 515 US-ASCII strings, and MUST NOT contain the comma character (","), or 516 whitespace, or control characters (ASCII codes 32 or less). The part 517 following the at-sign MUST be a valid, fully qualified internet 518 domain name [8] controlled by the person or organization defining the 519 name. Names are case-sensitive, and MUST NOT be longer than 64 520 characters. It is up to each domain how it manages its local 521 namespace. It has been noted that these names resemble STD 11 [7] 522 email addresses. This is purely coincidental and actually has 523 nothing to do with STD 11 [7]. An example of a locally defined name 524 is "ourcipher-cbc@example.com" (without the double quotes). 526 5.2.2. Future Assignments of Names 528 Requests for assignments of new Names MUST be done through the IETF 529 CONSENSUS method as described in [9]. 531 5.3. Request names 533 The following table lists the initial assignments of Request names 535 Request Name 536 ------------- 537 version 538 add 539 remove 540 list 541 listattributes 543 5.4. Response names 545 The following table lists the initial assignments of Response names 547 Response Name 548 -------------- 549 version 550 status 551 publickey 552 attribute 554 5.5. Attribute names 556 Attributes are used to define properties or restrictions for public 557 keys. The following table lists the initial assignments of Response 558 names 560 Attribute Name 561 --------------- 562 comment 563 comment-language 564 command-override 565 subsystem 566 x11 567 shell 568 exec 569 agent 570 env 571 from 572 port-forward 573 reverse-forward 575 5.6. Status codes 577 The status code is a byte value, describing the status of a request. 579 5.6.1. Conventions 581 Status responses have status codes in the range 0 to 255. These 582 numbers are allocated as follows. Of these, the range 192 to 255 is 583 reserved for use by local, private extensions. 585 5.6.2. Initial Assignments 587 The following table identifies the initial assignments of the status 588 code values. 590 Status code Value Reference 591 ------------ ----- --------- 592 SSH_PUBLICKEY_SUCCESS 0 593 SSH_PUBLICKEY_ACCESS_DENIED 1 594 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 595 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 596 SSH_PUBLICKEY_KEY_NOT_FOUND 4 597 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 598 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 599 SSH_PUBLICKEY_GENERAL_FAILURE 7 600 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 601 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 603 5.6.3. Future Assignments 605 Requests for assignments of new message numbers in the range of 0 to 606 191 MUST be done through the STANDARDS ACTION method as described in 607 [9]. 609 The IANA will not control the message numbers range of 192 through 610 255. This range will be left for PRIVATE USE. 612 6. References 614 6.1. Normative References 616 [1] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 617 draft-ietf-secsh-architecture-22 (work in progress), March 2005. 619 [2] Lonvick, C., "SSH Transport Layer Protocol", 620 draft-ietf-secsh-transport-24 (work in progress), March 2005. 622 [3] Lonvick, C. and T. Ylonen, "SSH Authentication Protocol", 623 draft-ietf-secsh-userauth-27 (work in progress), March 2005. 625 [4] Lonvick, C. and T. Ylonen, "SSH Connection Protocol", 626 draft-ietf-secsh-connect-25 (work in progress), March 2005. 628 [5] Alvestrand, H., "Tags for the Identification of Languages", 629 RFC 1766, March 1995. 631 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 632 RFC 2279, January 1998. 634 6.2. Informative References 636 [7] Crocker, D., "Standard for the format of ARPA Internet text 637 messages", STD 11, RFC 822, August 1982. 639 [8] Mockapetris, P., "Domain names - concepts and facilities", 640 STD 13, RFC 1034, November 1987. 642 [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 643 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 645 Authors' Addresses 647 Joseph Galbraith 648 VanDyke Software 649 4848 Tramway Ridge Blvd 650 Suite 101 651 Albuquerque, NM 87111 652 US 654 Phone: +1 505 332 5700 655 Email: galb-list@vandyke.com 657 Jeff P. Van Dyke 658 VanDyke Software 659 4848 Tramway Ridge Blvd 660 Suite 101 661 Albuquerque, NM 87111 662 US 664 Phone: +1 505 332 5700 665 Email: jpv@vandyke.com 667 Brent McClure 668 VanDyke Software 669 4848 Tramway Ridge Blvd 670 Suite 101 671 Albuquerque, NM 87111 672 US 674 Phone: +1 505 332 5700 675 Email: bdm@vandyke.com 677 Jon Bright 678 Silicon Circus 679 24 Jubilee Road 680 Chichester, West Sussex PO19 7XB 681 UK 683 Phone: +49 172 524 0521 684 Email: jon@siliconcircus.com 686 Intellectual Property Statement 688 The IETF takes no position regarding the validity or scope of any 689 Intellectual Property Rights or other rights that might be claimed to 690 pertain to the implementation or use of the technology described in 691 this document or the extent to which any license under such rights 692 might or might not be available; nor does it represent that it has 693 made any independent effort to identify any such rights. Information 694 on the procedures with respect to rights in RFC documents can be 695 found in BCP 78 and BCP 79. 697 Copies of IPR disclosures made to the IETF Secretariat and any 698 assurances of licenses to be made available, or the result of an 699 attempt made to obtain a general license or permission for the use of 700 such proprietary rights by implementers or users of this 701 specification can be obtained from the IETF on-line IPR repository at 702 http://www.ietf.org/ipr. 704 The IETF invites any interested party to bring to its attention any 705 copyrights, patents or patent applications, or other proprietary 706 rights that may cover technology that may be required to implement 707 this standard. Please address the information to the IETF at 708 ietf-ipr@ietf.org. 710 Disclaimer of Validity 712 This document and the information contained herein are provided on an 713 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 714 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 715 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 716 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 717 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 718 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 720 Copyright Statement 722 Copyright (C) The Internet Society (2005). This document is subject 723 to the rights, licenses and restrictions contained in BCP 78, and 724 except as set forth therein, the authors retain all their rights. 726 Acknowledgment 728 Funding for the RFC Editor function is currently provided by the 729 Internet Society.