diff options
Diffstat (limited to 'doc/draft-ietf-secsh-userauth-17.txt')
-rw-r--r-- | doc/draft-ietf-secsh-userauth-17.txt | 840 |
1 files changed, 840 insertions, 0 deletions
diff --git a/doc/draft-ietf-secsh-userauth-17.txt b/doc/draft-ietf-secsh-userauth-17.txt new file mode 100644 index 00000000..6624665e --- /dev/null +++ b/doc/draft-ietf-secsh-userauth-17.txt @@ -0,0 +1,840 @@ + + +Network Working Group T. Ylonen +Internet-Draft T. Kivinen +Expires: March 2, 2003 SSH Communications Security Corp + M. Saarinen + University of Jyvaskyla + T. Rinne + S. Lehtinen + SSH Communications Security Corp + September 2002 + + + SSH Authentication Protocol + draft-ietf-secsh-userauth-17.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on March 2, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + SSH is a protocol for secure remote login and other secure network + services over an insecure network. This document describes the + SSH authentication protocol framework and public key, password, + and host-based client authentication methods. Additional + authentication methods are described in separate documents. The + + + +Ylonen, et. al. Expires March 2, 2003 [Page 1] + +Internet-Draft SSH Authentication Protocol September 2002 + + + SSH authentication protocol runs on top of the SSH transport layer + protocol and provides a single authenticated tunnel for the SSH + connection protocol. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Authentication Protocol Framework . . . . . . . . . . . . 3 + 2.1 Authentication Requests . . . . . . . . . . . . . . . . . . . 4 + 2.2 Responses to Authentication Requests . . . . . . . . . . . . . 5 + 2.3 The "none" Authentication Request . . . . . . . . . . . . . . 6 + 2.4 Completion of User Authentication . . . . . . . . . . . . . . 6 + 2.5 Banner Message . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Authentication Protocol Message Numbers . . . . . . . . . . . 7 + 4. Public Key Authentication Method: publickey . . . . . . . . . 7 + 5. Password Authentication Method: password . . . . . . . . . . . 9 + 6. Host-Based Authentication: hostbased . . . . . . . . . . . . . 11 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 8. Intellectual Property . . . . . . . . . . . . . . . . . . . . 12 + 9. Additional Information . . . . . . . . . . . . . . . . . . . . 13 + References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ylonen, et. al. Expires March 2, 2003 [Page 2] + +Internet-Draft SSH Authentication Protocol September 2002 + + + 1. Introduction + + The SSH authentication protocol is a general-purpose user + authentication protocol. It is intended to be run over the SSH + transport layer protocol [SSH-TRANS]. This protocol assumes that + the underlying protocols provide integrity and confidentiality + protection. + + This document should be read only after reading the SSH + architecture document [SSH-ARCH]. This document freely uses + terminology and notation from the architecture document without + reference or further explanation. + + The service name for this protocol is "ssh-userauth". + + When this protocol starts, it receives the session identifier from + the lower-level protocol (this is the exchange hash H from the + first key exchange). The session identifier uniquely identifies + this session and is suitable for signing in order to prove + ownership of a private key. This protocol also needs to know + whether the lower-level protocol provides confidentiality + protection. + + 2. The Authentication Protocol Framework + + The server drives the authentication by telling the client which + authentication methods can be used to continue the exchange at any + given time. The client has the freedom to try the methods listed + by the server in any order. This gives the server complete + control over the authentication process if desired, but also gives + enough flexibility for the client to use the methods it supports + or that are most convenient for the user, when multiple methods + are offered by the server. + + Authentication methods are identified by their name, as defined in + [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed + as supported. However, it MAY be sent by the client. The server + MUST always reject this request, unless the client is to be + allowed in without any authentication, in which case the server + MUST accept this request. The main purpose of sending this + request is to get the list of supported methods from the server. + + The server SHOULD have a timeout for authentication, and + disconnect if the authentication has not been accepted within the + timeout period. The RECOMMENDED timeout period is 10 minutes. + Additionally, the implementation SHOULD limit the number of failed + authentication attempts a client may perform in a single session + (the RECOMMENDED limit is 20 attempts). If the threshold is + + + +Ylonen, et. al. Expires March 2, 2003 [Page 3] + +Internet-Draft SSH Authentication Protocol September 2002 + + + exceeded, the server SHOULD disconnect. + + 2.1 Authentication Requests + + All authentication requests MUST use the following message format. + Only the first few fields are defined; the remaining fields depend + on the authentication method. + + byte SSH_MSG_USERAUTH_REQUEST + string user name (in ISO-10646 UTF-8 encoding [RFC2279]) + string service name (in US-ASCII) + string method name (US-ASCII) + The rest of the packet is method-specific. + + The user name and service are repeated in every new authentication + attempt, and MAY change. The server implementation MUST carefully + check them in every message, and MUST flush any accumulated + authentication states if they change. If it is unable to flush + some authentication state, it MUST disconnect if the user or + service name changes. + + The service name specifies the service to start after + authentication. There may be several different authenticated + services provided. If the requested service is not available, the + server MAY disconnect immediately or at any later time. Sending a + proper disconnect message is RECOMMENDED. In any case, if the + service does not exist, authentication MUST NOT be accepted. + + If the requested user does not exist, the server MAY disconnect, + or MAY send a bogus list of acceptable authentication methods, but + never accept any. This makes it possible for the server to avoid + disclosing information on which accounts exist. In any case, if + the user does not exist, the authentication request MUST NOT be + accepted. + + While there is usually little point for clients to send requests + that the server does not list as acceptable, sending such requests + is not an error, and the server SHOULD simply reject requests that + it does not recognize. + + An authentication request MAY result in a further exchange of + messages. All such messages depend on the authentication method + used, and the client MAY at any time continue with a new + SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST + abandon the previous authentication attempt and continue with the + new one. + + + + + +Ylonen, et. al. Expires March 2, 2003 [Page 4] + +Internet-Draft SSH Authentication Protocol September 2002 + + + 2.2 Responses to Authentication Requests + + If the server rejects the authentication request, it MUST respond + with the following: + + byte SSH_MSG_USERAUTH_FAILURE + string authentications that can continue + boolean partial success + + "Authentications that can continue" is a comma-separated list of + authentication method names that may productively continue the + authentication dialog. + + It is RECOMMENDED that servers only include those methods in the + list that are actually useful. However, it is not illegal to + include methods that cannot be used to authenticate the user. + + Already successfully completed authentications SHOULD NOT be + included in the list, unless they really should be performed again + for some reason. + + "Partial success" MUST be TRUE if the authentication request to + which this is a response was successful. It MUST be FALSE if the + request was not successfully processed. + + When the server accepts authentication, it MUST respond with the + following: + + byte SSH_MSG_USERAUTH_SUCCESS + + Note that this is not sent after each step in a multi-method + authentication sequence, but only when the authentication is + complete. + + The client MAY send several authentication requests without + waiting for responses from previous requests. The server MUST + process each request completely and acknowledge any failed + requests with a SSH_MSG_USERAUTH_FAILURE message before processing + the next request. + + A request that results in further exchange of messages will be + aborted by a second request. It is not possible to send a second + request without waiting for a response from the server, if the + first request will result in further exchange of messages. No + SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted + method. + + SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When + + + +Ylonen, et. al. Expires March 2, 2003 [Page 5] + +Internet-Draft SSH Authentication Protocol September 2002 + + + SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication + requests received after that SHOULD be silently ignored. + + Any non-authentication messages sent by the client after the + request that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST + be passed to the service being run on top of this protocol. Such + messages can be identified by their message numbers (see Section + Message Numbers (Section 3)). + + 2.3 The "none" Authentication Request + + A client may request a list of authentication methods that may + continue by using the "none" authentication method. + + If no authentication at all is needed for the user, the server + MUST return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST + return SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of + authentication methods that can continue. + + This method MUST NOT be listed as supported by the server. + + 2.4 Completion of User Authentication + + Authentication is complete when the server has responded with + SSH_MSG_USERAUTH_SUCCESS; all authentication related messages + received after sending this message SHOULD be silently ignored. + + After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the + requested service. + + 2.5 Banner Message + + In some jurisdictions, sending a warning message before + authentication may be relevant for getting legal protection. Many + UNIX machines, for example, normally display text from + `/etc/issue', or use "tcp wrappers" or similar software to display + a banner before issuing a login prompt. + + The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any + time before authentication is successful. This message contains + text to be displayed to the client user before authentication is + attempted. The format is as follows: + + byte SSH_MSG_USERAUTH_BANNER + string message (ISO-10646 UTF-8) + string language tag (as defined in [RFC1766]) + + The client SHOULD by default display the message on the screen. + + + +Ylonen, et. al. Expires March 2, 2003 [Page 6] + +Internet-Draft SSH Authentication Protocol September 2002 + + + However, since the message is likely to be sent for every login + attempt, and since some client software will need to open a + separate window for this warning, the client software may allow + the user to explicitly disable the display of banners from the + server. The message may consist of multiple lines. + + If the message string is displayed, control character filtering + discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending + terminal control characters. + + 3. Authentication Protocol Message Numbers + + All message numbers used by this authentication protocol are in + the range from 50 to 79, which is part of the range reserved for + protocols running on top of the SSH transport layer protocol. + + Message numbers of 80 and higher are reserved for protocols + running after this authentication protocol, so receiving one of + them before authentication is complete is an error, to which the + server MUST respond by disconnecting (preferably with a proper + disconnect message sent first to ease troubleshooting). + + After successful authentication, such messages are passed to the + higher-level service. + + These are the general authentication message codes: + + #define SSH_MSG_USERAUTH_REQUEST 50 + #define SSH_MSG_USERAUTH_FAILURE 51 + #define SSH_MSG_USERAUTH_SUCCESS 52 + #define SSH_MSG_USERAUTH_BANNER 53 + + In addition to the above, there is a range of message numbers + (60..79) reserved for method-specific messages. These messages + are only sent by the server (client sends only + SSH_MSG_USERAUTH_REQUEST messages). Different authentication + methods reuse the same message numbers. + + 4. Public Key Authentication Method: publickey + + The only REQUIRED authentication method is public key + authentication. All implementations MUST support this method; + however, not all users need to have public keys, and most local + policies are not likely to require public key authentication for + all users in the near future. + + With this method, the possession of a private key serves as + authentication. This method works by sending a signature created + + + +Ylonen, et. al. Expires March 2, 2003 [Page 7] + +Internet-Draft SSH Authentication Protocol September 2002 + + + with a private key of the user. The server MUST check that the + key is a valid authenticator for the user, and MUST check that the + signature is valid. If both hold, the authentication request MUST + be accepted; otherwise it MUST be rejected. (Note that the server + MAY require additional authentications after successful + authentication.) + + Private keys are often stored in an encrypted form at the client + host, and the user must supply a passphrase before the signature + can be generated. Even if they are not, the signing operation + involves some expensive computation. To avoid unnecessary + processing and user interaction, the following message is provided + for querying whether authentication using the key would be + acceptable. + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + string "publickey" + boolean FALSE + string public key algorithm name + string public key blob + + Public key algorithms are defined in the transport layer + specification [SSH-TRANS]. The public key blob may contain + certificates. + + Any public key algorithm may be offered for use in authentication. + In particular, the list is not constrained by what was negotiated + during key exchange. If the server does not support some + algorithm, it MUST simply reject the request. + + The server MUST respond to this message with either + SSH_MSG_USERAUTH_FAILURE or with the following: + + byte SSH_MSG_USERAUTH_PK_OK + string public key algorithm name from the request + string public key blob from the request + + To perform actual authentication, the client MAY then send a + signature generated using the private key. The client MAY send + the signature directly without first verifying whether the key is + acceptable. The signature is sent using the following packet: + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + string "publickey" + + + +Ylonen, et. al. Expires March 2, 2003 [Page 8] + +Internet-Draft SSH Authentication Protocol September 2002 + + + boolean TRUE + string public key algorithm name + string public key to be used for authentication + string signature + + Signature is a signature by the corresponding private key over the + following data, in the following order: + + string session identifier + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + string "publickey" + boolean TRUE + string public key algorithm name + string public key to be used for authentication + + When the server receives this message, it MUST check whether the + supplied key is acceptable for authentication, and if so, it MUST + check whether the signature is correct. + + If both checks succeed, this method is successful. Note that the + server may require additional authentications. The server MUST + respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications + are needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, + or more authentications are needed). + + The following method-specific message numbers are used by the + publickey authentication method. + + /* Key-based */ + #define SSH_MSG_USERAUTH_PK_OK 60 + + + 5. Password Authentication Method: password + + Password authentication uses the following packets. Note that a + server MAY request the user to change the password. All + implementations SHOULD support password authentication. + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + string "password" + boolean FALSE + string plaintext password (ISO-10646 UTF-8) + + Note that the password is encoded in ISO-10646 UTF-8. It is up to + + + +Ylonen, et. al. Expires March 2, 2003 [Page 9] + +Internet-Draft SSH Authentication Protocol September 2002 + + + the server how it interprets the password and validates it against + the password database. However, if the client reads the password + in some other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST + convert the password to ISO-10646 UTF-8 before transmitting, and + the server MUST convert the password to the encoding used on that + system for passwords. + + Note that even though the cleartext password is transmitted in the + packet, the entire packet is encrypted by the transport layer. + Both the server and the client should check whether the underlying + transport layer provides confidentiality (i.e., if encryption is + being used). If no confidentiality is provided (none cipher), + password authentication SHOULD be disabled. If there is no + confidentiality or no MAC, password change SHOULD be disabled. + + Normally, the server responds to this message with success or + failure. However, if the password has expired the server SHOULD + indicate this by responding with + SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. In anycase the server MUST NOT + allow an expired password to be used for authentication. + + byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ + string prompt (ISO-10646 UTF-8) + string language tag (as defined in [RFC1766]) + + In this case, the client MAY continue with a different + authentication method, or request a new password from the user and + retry password authentication using the following message. The + client MAY also send this message instead of the normal password + authentication request without the server asking for it. + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + string "password" + boolean TRUE + string plaintext old password (ISO-10646 UTF-8) + string plaintext new password (ISO-10646 UTF-8) + + The server must reply to request message with + SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another + SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as + follows: + + SSH_MSG_USERAUTH_SUCCESS The password has been changed, and + authentication has been successfully completed. + + SSH_MSG_USERAUTH_FAILURE with partial success The password has + + + +Ylonen, et. al. Expires March 2, 2003 [Page 10] + +Internet-Draft SSH Authentication Protocol September 2002 + + + been changed, but more authentications are needed. + + SSH_MSG_USERAUTH_FAILURE without partial success The password + has not been changed. Either password changing was not + supported, or the old password was bad. Note that if the + server has already sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we + know that it supports changing the password. + + SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because + the new password was not acceptable (e.g. too easy to guess). + + The following method-specific message numbers are used by the + password authentication method. + + #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 + + + 6. Host-Based Authentication: hostbased + + Some sites wish to allow authentication based on the host where + the user is coming from, and the user name on the remote host. + While this form of authentication is not suitable for high- + security sites, it can be very convenient in many environments. + This form of authentication is OPTIONAL. When used, special care + SHOULD be taken to prevent a regular user from obtaining the + private host key. + + The client requests this form of authentication by sending the + following message. It is similar to the UNIX "rhosts" and + "hosts.equiv" styles of authentication, except that the identity + of the client host is checked more rigorously. + + This method works by having the client send a signature created + with the private key of the client host, which the server checks + with that host's public key. Once the client host's identity is + established, authorization (but no further authentication) is + performed based on the user names on the server and the client, + and the client host name. + + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + string "hostbased" + string public key algorithm for host key + string public host key and certificates for client host + string client host name (FQDN; US-ASCII) + string user name on the client host (ISO-10646 UTF-8) + string signature + + + +Ylonen, et. al. Expires March 2, 2003 [Page 11] + +Internet-Draft SSH Authentication Protocol September 2002 + + + Public key algorithm names for use in "public key algorithm for + host key" are defined in the transport layer specification. The + "public host key for client host" may include certificates. + + Signature is a signature with the private host key of the + following data, in this order: + + string session identifier + byte SSH_MSG_USERAUTH_REQUEST + string user name + string service + string "hostbased" + string public key algorithm for host key + string public host key and certificates for client host + string client host name (FQDN; US-ASCII) + string user name on the client host(ISO-10646 UTF-8) + + The server MUST verify that the host key actually belongs to the + client host named in the message, that the given user on that host + is allowed to log in, and that the signature is a valid signature + on the appropriate value by the given host key. The server MAY + ignore the client user name, if it wants to authenticate only the + client host. + + It is RECOMMENDED that whenever possible, the server perform + additional checks to verify that the network address obtained from + the (untrusted) network matches the given client host name. This + makes exploiting compromised host keys more difficult. Note that + this may require special handling for connections coming through a + firewall. + + 7. Security Considerations + + The purpose of this protocol is to perform client user + authentication. It assumed that this runs over a secure transport + layer protocol, which has already authenticated the server + machine, established an encrypted communications channel, and + computed a unique session identifier for this session. The + transport layer provides forward secrecy for password + authentication and other methods that rely on secret data. + + Full security considerations for this protocol are provided in + Section 8 of [SSH-ARCH] + + 8. Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + + + +Ylonen, et. al. Expires March 2, 2003 [Page 12] + +Internet-Draft SSH Authentication Protocol September 2002 + + + pertain to the implementation or use of the technology described + in this document or the extent to which any license under such + rights might or might not be available; neither does it represent + that it has made any effort to identify any such rights. + Information on the IETF's procedures with respect to rights in + standards-track and standards-related documentation can be found + in BCP-11. Copies of claims of rights made available for + publication and any assurances of licenses to be made available, + or the result of an attempt made to obtain a general license or + permission for the use of such proprietary rights by implementers + or users of this specification can be obtained from the IETF + Secretariat. + + The IETF has been notified of intellectual property rights claimed + in regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + 9. Additional Information + + The current document editor is: Darren.Moffat@Sun.COM. Comments + on this internet draft should be sent to the IETF SECSH working + group, details at: http://ietf.org/html.charters/secsh- + charter.html + +References + + [RFC1766] Alvestrand, H., "Tags for the Identification of + Languages", RFC 1766, March 1995. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of + ISO 10646", RFC 2279, January 1998. + + [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D + draft-ietf-architecture-14.txt, July 2003. + + [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D + draft-ietf-transport-16.txt, July 2003. + + [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D + draft-ietf-userauth-17.txt, July 2003. + + [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- + ietf-connect-17.txt, July 2003. + + [SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned + Numbers", I-D draft-ietf-secsh-assignednumbers- + 03.txt, July 2003. + + + +Ylonen, et. al. Expires March 2, 2003 [Page 13] + +Internet-Draft SSH Authentication Protocol September 2002 + + +Authors' Addresses + + Tatu Ylonen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: ylo@ssh.com + + + Tero Kivinen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: kivinen@ssh.com + + + Markku-Juhani O. Saarinen + University of Jyvaskyla + + + Timo J. Rinne + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: tri@ssh.com + + + Sami Lehtinen + SSH Communications Security Corp + Fredrikinkatu 42 + HELSINKI FIN-00100 + Finland + + EMail: sjl@ssh.com + + + + + + + + + + + +Ylonen, et. al. Expires March 2, 2003 [Page 14] + +Internet-Draft SSH Authentication Protocol September 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished + to others, and derivative works that comment on or otherwise + explain it or assist in its implementation may be prepared, + copied, published and distributed, in whole or in part, without + restriction of any kind, provided that the above copyright notice + and this paragraph are included on all such copies and derivative + works. However, this document itself may not be modified in any + way, such as by removing the copyright notice or references to the + Internet Society or other Internet organizations, except as needed + for the purpose of developing Internet standards in which case the + procedures for copyrights defined in the Internet Standards + process must be followed, or as required to translate it into + languages other than English. + + The limited permissions granted above are perpetual and will not + be revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on + an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Ylonen, et. al. Expires March 2, 2003 [Page 15] + |