RFC 2951 (rfc2951) - Page 2 of 11

TELNET Authentication Using KEA and SKIPJACK

RFC 2951       TELNET Authentication Using KEA & SKIPJACK September 2000


       AUTH_HOW_MASK            2
       AUTH_HOW_ONE_WAY         0
       AUTH_HOW_MUTUAL          2

       ENCRYPT_MASK            20
       ENCRYPT_OFF              0
       ENCRYPT_USING_TELOPT     4
       ENCRYPT_AFTER_EXCHANGE  16
       ENCRYPT_RESERVED        20

       INI_CRED_FWD_MASK        8
       INI_CRED_FWD_OFF         0
       INI_CRED_FWD_ON          8

     Sub-option Commands:

       KEA_CERTA_RA             1
       KEA_CERTB_RB_IVB_NONCEB  2
       KEA_IVA_RESPONSEB_NONCEA 3
       KEA_RESPONSEA            4

2. TELNET Security Extensions

   TELNET, as a protocol, has no concept of security.  Without
   negotiated options, it merely passes characters back and forth
   between the NVTs represented by the two TELNET processes.  In its
   most common usage as a protocol for remote terminal access (TCP port
   23), TELNET normally connects to a server that requires user-level
   authentication through a user name and password in the clear.  The
   server does not authenticate itself to the user.

   The TELNET Authentication Option provides for:

     *  User authentication -- replacing or augmenting the normal host
        password mechanism;
     *  Server authentication -- normally done in conjunction with user
        authentication;
     *  Session parameter negotiation -- in particular, encryption key
        and attributes;
     *  Session protection -- primarily encryption of the data and
        embedded command stream, but the encryption algorithm may also
        provide data integrity.

   In order to support these security services, the two TELNET entities
   must first negotiate their willingness to support the TELNET
   Authentication Option.  Upon agreeing to support this option, the
   parties are then able to perform sub-option negotiations to determine




Housley, et al.              Informational