TELNET Authentication Using DSA(2)

    The tokens are ASN.1 encoded as defined in Appendix A of　FIPS PUB 196, and each token is named to indicate the direction in　which it flows (e.g., TokenBA flows from Party B to Party A). All　data that is covered by a digital signature must be encoded using the　Distinguished Encoding Rules (DER). Data that is not covered by a digital signature may use either the Basic Encoding Rules (BER) or　DER [X.208]. Figure 1 illustrates the exchanges for unilateral　authentication.

　　During authentication, the client may provide the user name to the　server by using the authentication name sub-option. If the name　sub-option is not used, the server will generally prompt for a name　and password in the clear. The name sub-option must be sent after　the server sends the list of authentication types supported and　before the client finishes the authentication exchange, this ensures　that the server will not prompt for a user name and password. In　figure 1, the name sub-option is sent immediately after the server　presents the list of authentication types supported.

　　For one-way DSS authentication, the two-octet authentication type　pair is DSS AUTH_CLIENT_TO_SERVER | AUTH_HOW_ONE_WAY | ENCRYPT_OFF |　INI_CRED_FWD_OFF. This indicates that the DSS authentication　mechanism will be used to authenticate the client to the server and　that no encryption will be performed.

　　CertA is the clients certificate. Both certificates are X.509　certificates that contain DSS public keys[RFC2459]. The client must　validate the server's certificate before using the DSA public key it　contains.

　　Within the unbounded authentication exchange, implementation is　greatly simplified if each portion of the exchange carries a unique　identifier. For this reason, a single octet sub-option identifier is　carried immediately after the two-octet authentication type pair.　The exchanges detailed in Figure 1 below presume knowledge of FIPS　PUB 196 and the TELNET Authentication Option. The client is Party A,　while the server is Party B. At the end of the exchanges, the client　is authenticated to the server.

　　------------------------------------------------------------------

　　Client (Party A) Server (Party B)

　　<-- IAC DO AUTHENTICATION

IAC WILL AUTHENTICATION -->　　IAC WILL AUTHENTICATION -->

　　<-- IAC SB AUTHENTICATION SEND

<　　

　　IAC SE

　　IAC SB AUTHENTICATION

　　NAME -->

　　IAC SB AUTHENTICATION IS

　　DSS

　　AUTH_CLIENT_TO_SERVER |

　　AUTH_HOW_ONE_WAY |

　　ENCRYPT_OFF |

　　INI_CRED_FWD_OFF

　　DSS_INITIALIZE

　　IAC SE -->

　　<-- IAC SB AUTHENTICATION REPLY

DSS

AUTH_CLIENT_TO_SERVER |

AUTH_HOW_ONE_WAY |

ENCRYPT_OFF |

INI_CRED_FWD_OFF

DSS_TOKENBA

Sequence( TokenID, TokenBA )

IAC SE

IAC SB AUTHENTICATION IS

DSS

AUTH_CLIENT_TO_SERVER |

AUTH_HOW_ONE_WAY |

ENCRYPT_OFF |

INI_CRED_FWD_OFF

DSS_CERTA_TOKENAB

Sequence( TokenID, CertA, TokenAB )

IAC SE -->　　DSS

　　AUTH_CLIENT_TO_SERVER |

　　AUTH_HOW_ONE_WAY |

　　ENCRYPT_OFF |

　　INI_CRED_FWD_OFF

　　DSS_TOKENBA

　　Sequence( TokenID, TokenBA )

　　IAC SE

　　IAC SB AUTHENTICATION IS

　　DSS

　　AUTH_CLIENT_TO_SERVER |

　　AUTH_HOW_ONE_WAY |

　　ENCRYPT_OFF |

　　INI_CRED_FWD_OFF

　　DSS_CERTA_TOKENAB

　　Sequence( TokenID, CertA, TokenAB )

　　IAC SE -->

　　------------------------------------------------------------------

　　Figure 1

　　3.2. Mutual Authentication with DSA

　　Mutual authentication is slightly more complex. Figure 2 illustrates　the exchanges.

　　For mutual DSS authentication, the two-octet authentication type pair　is DSS AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_OFF |　INI_CRED_FWD_OFF. This indicates that the DSS authentication　mechanism will be used to mutually authenticate the client and the　server and that no encryption will be performed.

　　---------------------------------------------------------------------

　　Client (Party A) Server (Party B)

　　IAC WILL AUTHENTICATION -->

　　<-- IAC DO AUTHENTICATION

<　　<-- IAC SB AUTHENTICATION SEND

<　　

　　IAC SE

　　IAC SB AUTHENTICATION

　　NAME -->

　　IAC SB AUTHENTICATION IS

　　DSS

　　AUTH_CLIENT_TO_SERVER |

　　AUTH_HOW_MUTUAL |

　　ENCRYPT_OFF |

　　INI_CRED_FWD_OFF

　　DSS_INITIALIZE

　　IAC SE -->

　　<-- IAC SB AUTHENTICATION REPLY

DSS

AUTH_CLIENT_TO_SERVER |

AUTH_HOW_MUTUAL |

ENCRYPT_OFF |

INI_CRED_FWD_OFF

DSS_TOKENBA

Sequence( TokenID, TokenBA )

IAC SE

Client (Party A) Server (Party B)

IAC SB AUTHENTICATION IS

DSS

AUTH_CLIENT_TO_SERVER |

AUTH_HOW_MUTUAL |

ENCRYPT_OFF |

INI_CRED_FWD_OFF

DSS_CERTA_TOKENAB

Sequence( TokenID, CertA, TokenAB )

IAC SE -->　　DSS

　　AUTH_CLIENT_TO_SERVER |

　　AUTH_HOW_MUTUAL |

　　ENCRYPT_OFF |

　　INI_CRED_FWD_OFF

　　DSS_TOKENBA

　　Sequence( TokenID, TokenBA )

　　IAC SE

　　Client (Party A) Server (Party B)

　　IAC SB AUTHENTICATION IS

　　DSS

　　AUTH_CLIENT_TO_SERVER |

　　AUTH_HOW_MUTUAL |

　　ENCRYPT_OFF |

　　INI_CRED_FWD_OFF

　　DSS_CERTA_TOKENAB

　　Sequence( TokenID, CertA, TokenAB )

　　IAC SE -->

　　<-- IAC SB AUTHENTICATION REPLY

DSS

AUTH_CLIENT_TO_SERVER |

AUTH_HOW_MUTUAL |

ENCRYPT_OFF |

INI_CRED_FWD_OFF

DSS_CERTB_TOKENBA2

Sequence( TokenID, CertB,

TokenBA2 )

IAC SE

---------------------------------------------------------------------