rfc2941.txt

RFC 的详细文档！

   The following is an example of use of the option with encryption
   negotiated via telnet ENCRYPT:

   Client                           Server
                                    IAC DO AUTHENTICATION
   IAC WILL AUTHENTICATION
   [ The server is now free to request authentication information.
     ]
                                    IAC SB AUTHENTICATION SEND
                                    KERBEROS_V4
                                    CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
                                    KERBEROS_V4 CLIENT|ONE_WAY IAC
                                    SE
   [ The server has requested mutual Kerberos authentication, but is
     willing to do just one-way Kerberos authentication.  In both
     cases it is willing to encrypt the data stream.  The client
     will now respond with the name of the user that it wants to log
     in as, and the Kerberos ticket.  ]
   IAC SB AUTHENTICATION NAME "joe"
   IAC SE
   IAC SB AUTHENTICATION IS
   KERBEROS_V4
   CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
   AUTH 4 7 1 67 82 65 89 46 67 7 9
   77 0 48 24 49 244 109 240 50 208
   43 35 25 116 104 44 167 21 201
   224 229 145 20 2 244 213 220 33
   134 148 4 251 249 233 229 152 77
   2 109 130 231 33 146 190 248 1 9
   31 95 94 15 120 224 0 225 76 205
   70 136 245 190 199 147 155 13
   IAC SE
   [ The server responds with an ACCEPT command to state that the
     authentication was successful.  ]
                                    IAC SB AUTHENTICATION REPLY
                                    KERBEROS_V4
                                    CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
                                    ACCEPT IAC SE
   [ Next, the client sends across a CHALLENGE to verify that it is
     really talking to the right server.  ]
   IAC SB AUTHENTICATION IS
   KERBEROS_V4
   CLIENT|MUTUAL|ENCRYPT_USING_TELOPT








Ts'o & Altman               Standards Track                    [Page 11]

RFC 2941              Telnet Authentication Option        September 2000


   CHALLENGE xx xx xx xx xx xx xx
   xx IAC SE
   [ The server sends across a RESPONSE to prove that it really is
     the right server.  ]
                                    IAC SB AUTHENTICATION REPLY
                                    KERBEROS_V4
                                    CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
                                    RESPONSE yy yy yy yy yy yy yy yy
                                    IAC SE
   [ At this point, the client and server begin to negotiate the
     telnet ENCRYPT option in each direction for a secure channel.
     If the option fails in either direction for any reason the
     connection must be immediately terminated.  ]

   The following is an example of use of the option with integrated
   encryption:

   Client                           Server
                                    IAC DO AUTHENTICATION
   IAC WILL AUTHENTICATION
   [ The server is now free to request authentication information.
     ]
                                    IAC SB AUTHENTICATION SEND
                                    KEA_SJ
                                    CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
                                    IAC SE
   [ The server has requested mutual KEA authentication with
     SKIPJACK encryption.  The client will now respond with the name
     of the user that it wants to log in as and the KEA cert.  ]
   IAC SB AUTHENTICATION NAME "joe"
   IAC SE IAC SB AUTHENTICATION IS
   KEA_SJ
   CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
   '1' CertA||Ra IAC SE
   [ The server responds with its KEA Cert.  ]
                                    IAC SB AUTHENTICATION REPLY
                                    KEA_SJ
                                    CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
                                    '2'
                                    CertB||Rb||IVb||Encrypt(NonceB)
                                    IAC SE
   [ Next, the client sends across a CHALLENGE to verify that it is
     really talking to the right server.  ]
   IAC SB AUTHENTICATION IS KEA_SJ
   CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
   '3' IVa||Encrypt( NonceB xor
   0x0C18 || NonceA ) IAC SE




Ts'o & Altman               Standards Track                    [Page 12]

RFC 2941              Telnet Authentication Option        September 2000


   [ At this point, the client begins to encrypt the outgoing data
     stream, and the server, after receiving this command, begins to
     decrypt the incoming data stream.  Lastly, the server sends
     across a RESPONSE to prove that it really is the right server.
     ]
                                    IAC SB AUTHENTICATION REPLY
                                    KEA_SJ
                                    CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
                                    '4' Encrypt( NonceA xor 0x0C18 )
                                    IAC SE
   [ At this point, the server begins to encrypt its outgoing data
     stream, and the client, after receiving this command, begins to
     decrypt its incoming data stream.  ]

   It is expected that any implementation that supports the Telnet
   AUTHENTICATION option will support all of this specification.

9.  Security Considerations

   This memo describes a general framework for adding authentication and
   encryption to the telnet protocol.  The actual authentication
   mechanism is described in the authentication suboption
   specifications, and the security of the authentication option is
   dependent on the strengths and weaknesses of the authentication
   suboption.

   It should be noted that the negotiation of the authentication type
   pair is not protected, thus allowing an attacker to force the result
   of the authentication to the weakest mutually acceptable method.
   (For example, even if both sides of the negotiation can accept a
   "strong" mechanism and a "40-bit" mechanism, an attacker could force
   selection of the "40-bit" mechanism.)  An implementation should
   therefore only accept an authentication mechanism to be negotiated if
   it is willing to trust it as being secure.

   It should also be noted that the negotiation of the username in the
   IAC SB AUTHENTICATION NAME name IAC SE message is not protected.
   Implementations should verify the value by a secure method before
   using this untrusted value.

11.  Acknowledgements

   Many people have worked on this document over the span of many years.
   Dave Borman was a document editor and author of much of the original
   text.  Other folks who have contributed ideas and suggestions to this
   text include: David Carrel, Jeff Schiller, and Richard Basch.





Ts'o & Altman               Standards Track                    [Page 13]

RFC 2941              Telnet Authentication Option        September 2000


10.  References

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

   [2] Borman D., "Telnet Authentication Option", RFC 1416, February
       1993.

   [3] Ts'o, T., "Telnet Data Encryption Option", RFC 2946, September
       2000.

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

12.  Authors' Addresses

   Theodore Ts'o, Editor
   VA Linux Systems
   43 Pleasant St.
   Medford, MA 02155

   Phone: [phone]
   EMail: [e-mail]


   Jeffrey Altman
   Columbia University
   Watson Hall Room 716
   612 West 115th Street
   New York NY 10025

   Phone: [phone]
   EMail: [e-mail]


   Mailing List: [e-mail]















Ts'o & Altman               Standards Track                    [Page 14]

RFC 2941              Telnet Authentication Option        September 2000


13.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.



















Ts'o & Altman               Standards Track                    [Page 15]