draft-ietf-secsh-architecture-15.txt

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

   The password mechanism as specified in the authentication protocol
   assumes that the server has not been compromised.  If the server has
   been compromised, using password authentication will reveal a valid
   username / password combination to the attacker, which may lead to
   further compromises.

   This vulnerability can be mitigated by using an alternative form of



Ylonen & Moffat          Expires March 31, 2004                [Page 22]

Internet-Draft         SSH Protocol Architecture                Oct 2003


   authentication.  For example, public-key authentication makes no
   assumptions about security on the server.

9.3.6 Host based authentication

   Host based authentication assumes that the client has not been
   compromised.  There are no mitigating strategies, other than to use
   host based authentication in combination with another authentication
   method.

9.4 Connection protocol

9.4.1 End point security

   End point security is assumed by the connection protocol.  If the
   server has been compromised, any terminal sessions, port forwarding,
   or systems accessed on the host are compromised.  There are no
   mitigating factors for this.

   If the client end point has been compromised, and the server fails to
   stop the attacker at the authentication protocol, all services
   exposed (either as subsystems or through forwarding) will be
   vulnerable to attack.  Implementors SHOULD provide mechanisms for
   administrators to control which services are exposed to limit the
   vulnerability of other services.

   These controls might include controlling which machines and ports can
   be target in 'port-forwarding' operations, which users are allowed to
   use interactive shell facilities, or which users are allowed to use
   exposed subsystems.

9.4.2 Proxy forwarding

   The SSH connection protocol allows for proxy forwarding of other
   protocols such as SNMP, POP3, and HTTP.  This may be a concern for
   network administrators who wish to control the access of certain
   applications by users located outside of their physical location.
   Essentially, the forwarding of these protocols may violate site
   specific security policies as they may be undetectably tunneled
   through a firewall.  Implementors SHOULD provide an administrative
   mechanism to control the proxy forwarding functionality so that site
   specific security policies may be upheld.

   In addition, a reverse proxy forwarding functionality is available,
   which again can be used to bypass firewall controls.

   As indicated above, end-point security is assumed during proxy
   forwarding operations.  Failure of end-point security will compromise



Ylonen & Moffat          Expires March 31, 2004                [Page 23]

Internet-Draft         SSH Protocol Architecture                Oct 2003


   all data passed over proxy forwarding.

9.4.3 X11 forwarding

   Another form of proxy forwarding provided by the ssh connection
   protocol is the forwarding of the X11 protocol.  If end-point
   security has been compromised, X11 forwarding may allow attacks
   against the X11 server.  Users and administrators should, as a matter
   of course, use appropriate X11 security mechanisms to prevent
   unauthorized use of the X11 server.  Implementors, administrators and
   users who wish to further explore the security mechanisms of X11 are
   invited to read [SCHEIFLER] and analyze previously reported problems
   with the interactions between SSH forwarding and X11 in CERT
   vulnerabilities VU#363181 and VU#118892 [CERT].

   X11 display forwarding with SSH, by itself, is not sufficient to
   correct well known problems with X11 security [VENEMA].  However, X11
   display forwarding in SSHv2 (or other, secure protocols), combined
   with actual and pseudo-displays which accept connections only over
   local IPC mechanisms authorized by permissions or ACLs, does correct
   many X11 security problems as long as the "none" MAC is not used.  It
   is RECOMMENDED that X11 display implementations default to allowing
   display opens only over local IPC.  It is RECOMMENDED that SSHv2
   server implementations that support X11 forwarding default to
   allowing display opens only over local IPC.  On single-user systems
   it might be reasonable to default to allowing local display opens
   over TCP/IP.

   Implementors of the X11 forwarding protocol SHOULD implement the
   magic cookie access checking spoofing mechanism as described in
   [ssh-connect] as an additional mechanism to prevent unauthorized use
   of the proxy.

Normative References

   [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 & Moffat          Expires March 31, 2004                [Page 24]

Internet-Draft         SSH Protocol Architecture                Oct 2003


              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 References

   [FIPS-186]
              Federal Information Processing Standards Publication,
              "FIPS PUB 186, Digital Signature Standard", May 1994.

   [FIPS-197]
              National Institue of Standards and Technology, "FIPS 197,
              Specification for the Advanced Encryption Standard",
              November 2001.

   [ANSI T1.523-2001]
              American National Standards Insitute, Inc., "Telecom
              Glossary 2000", February 2001.

   [SCHEIFLER]
              Scheifler, R., "X Window System : The Complete Reference
              to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital
              Press ISBN 1555580882, Feburary 1992.

   [RFC0854]  Postel, J. and J. Reynolds, "Telnet Protocol
              Specification", STD 8, RFC 854, May 1983.

   [RFC0894]  Hornig, C., "Standard for the transmission of IP datagrams
              over Ethernet networks", STD 41, RFC 894, April 1984.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1134]  Perkins, D., "Point-to-Point Protocol: A proposal for
              multi-protocol transmission of datagrams over
              Point-to-Point links", RFC 1134, November 1989.

   [RFC1282]  Kantor, B., "BSD Rlogin", RFC 1282, December 1991.

   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
              Authentication Service (V5)", RFC 1510, September 1993.



Ylonen & Moffat          Expires March 31, 2004                [Page 25]

Internet-Draft         SSH Protocol Architecture                Oct 2003


   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

   [RFC1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
              Recommendations for Security", RFC 1750, December 1994.

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

   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
              1964, June 1996.

   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
              (SPKM)", RFC 2025, October 1996.

   [RFC2085]  Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with
              Replay Prevention", RFC 2085, February 1997.

   [RFC2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
              Keyed-Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC2246]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
              and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
              January 1999.

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

   [RFC2410]  Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
              Its Use With IPsec", RFC 2410, November 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.

   [SCHNEIER]
              Schneier, B., "Applied Cryptography Second Edition:
              protocols algorithms and source in code in C", 1996.

   [KAUFMAN,PERLMAN,SPECINER]
              Kaufman, C., Perlman, R. and M. Speciner, "Network
              Security: PRIVATE Communication in a PUBLIC World", 1995.

   [CERT]     CERT Coordination Center, The., "http://www.cert.org/nav/



Ylonen & Moffat          Expires March 31, 2004                [Page 26]

Internet-Draft         SSH Protocol Architecture                Oct 2003


              index_red.html".

   [VENEMA]   Venema, W., "Murphy's Law and Computer Security",
              Proceedings of 6th USENIX Security Symposium, San Jose CA
              http://www.usenix.org/publications/library/proceedings/
              sec96/venema.html, July 1996.

   [ROGAWAY]  Rogaway, P., "Problems with Proposed IP Cryptography",
              Unpublished paper http://www.cs.ucdavis.edu/~rogaway/
              papers/draft-rogaway-ipsec-comments-00.txt, 1996.

   [DAI]      Dai, W., "An attack against SSH2 protocol", Email to the
              SECSH Working Group [e-mail] ftp://
              ftp.ietf.org/ietf-mail-archive/secsh/2002-02.mail, Feb
              2002.

   [BELLARE,KOHNO,NAMPREMPRE]
              Bellaire, M., Kohno, T. and C. Namprempre, "Authenticated
              Encryption in SSH: Fixing the SSH Binary Packet Protocol",
              , Sept 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  CA 94025
   USA

   EMail: [e-mail]











Ylonen & Moffat          Expires March 31, 2004                [Page 27]

Internet-Draft         SSH Protocol Architecture                Oct 2003


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 resp