draft-ietf-secsh-userauth-18.txt

来自「OTP是开放电信平台的简称」· 文本 代码 · 共 896 行 · 第 1/3 页

   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,



Ylonen & Moffat          Expires March 2, 2003                 [Page 11]

Internet-Draft        SSH Authentication Protocol         September 2002


   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

   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.

4. Security Considerations

   The purpose of this protocol is to perform client user
   authentication. It assumed that this runs over a secure transport



Ylonen & Moffat          Expires March 2, 2003                 [Page 12]

Internet-Draft        SSH Authentication Protocol         September 2002


   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]

Normative

   [SSH-ARCH]
              Ylonen, T., "SSH Protocol Architecture", I-D
              draft-ietf-architecture-15.txt, Oct 2003.

   [SSH-TRANS]
              Ylonen, T., "SSH Transport Layer Protocol", I-D
              draft-ietf-transport-17.txt, Oct 2003.

   [SSH-USERAUTH]
              Ylonen, T., "SSH Authentication Protocol", I-D
              draft-ietf-userauth-18.txt, Oct 2003.

   [SSH-CONNECT]
              Ylonen, T., "SSH Connection Protocol", I-D
              draft-ietf-connect-18.txt, Oct 2003.

   [SSH-NUMBERS]
              Lehtinen, S. and D. Moffat, "SSH Protocol Assigned
              Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct
              2003.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Informative

   [RFC3066]  Alvestrand, H., "Tags for the Identification of
              Languages", BCP 47, RFC 3066, January 2001.

   [RFC2279]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 2279, January 1998.









Ylonen & Moffat          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: [e-mail]


   Darren J. Moffat (editor)
   Sun Microsystems, Inc
   17 Network Circle
   Menlo Park  95025
   USA

   EMail: [e-mail]

































Ylonen & Moffat          Expires March 2, 2003                 [Page 14]

Internet-Draft        SSH Authentication Protocol         September 2002


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

   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.


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 assignees.



Ylonen & Moffat          Expires March 2, 2003                 [Page 15]

Internet-Draft        SSH Authentication Protocol         September 2002


   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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







































Ylonen & Moffat          Expires March 2, 2003                 [Page 16]