TELNET Authentication Using DSA
Extracted elements (20)
A single-octet sub-option identifier is carried immediately after the two-octet authentication type pair to uniquely identify each portion of the exchange. This simplifies implementation within the unbounded authentication exchange by making each message self-identifying.
Due to TELNET's character-by-character nature, it is not well-suited to integrity-only services; therefore the DSA profile provides authentication but does not provide session integrity. This explains why no message authentication code or integrity mechanism is defined.
This specification follows token and exchange definitions from NIST FIPS PUB 196, using a conformant subset with no optional fields or subfields. ASN.1 definitions for CertificationPath and Name are imported from CCITT X.509 and X.501 respectively and are not repeated in the RFC.
All data covered by a digital signature must be encoded using the Distinguished Encoding Rules (DER). Data not covered by a digital signature may use either BER or DER.
Any suboption values used to extend the DSS authentication protocol must be registered with IANA before use. IANA is instructed not to issue new suboption values without submission of documentation of their use.
The client must validate the server's certificate before using the DSA public key it contains. Both CertA and CertB are X.509 certificates containing DSS public keys as defined in RFC 2459.
The NAME sub-option must be sent after the server sends the list of supported authentication types and before the client finishes the authentication exchange, ensuring the server will not prompt for a user name and password in the clear.
DSS is assigned authentication type code 14 within the TELNET Authentication Option framework. The authentication type pair is a two-octet value combining the type with modifiers for direction, mutuality, encryption, and credential forwarding.
Four sub-option commands are defined for DSS authentication: DSS_INITIALIZE (1), DSS_TOKENBA (2), DSS_CERTA_TOKENAB (3), and DSS_CERTB_TOKENBA2 (4). These identifiers are carried as a single octet immediately after the two-octet authentication type pair to uniquely identify each exchange step.
Modifier flags are defined for the authentication type pair: AUTH_WHO_MASK (1), AUTH_HOW_MASK (2), ENCRYPT_MASK (20), and INI_CRED_FWD_MASK (8), with corresponding ON/OFF values. These combine to fully specify the authentication mode in the two-octet type pair.
The authentication type DSS (code 14) and its associated suboption values (DSS_INITIALIZE=1, DSS_TOKENBA=2, DSS_CERTA_TOKENAB=3, DSS_CERTB_TOKENBA2=4) are registered with IANA as part of the TELNET Authentication Option registry.
For DSA to provide the specified authentication, implementations must protect the DSS private key from disclosure. Compromise of the private key allows an attacker to forge authentication.
Implementations must randomly generate DSS private keys, 'k' values used in DSS signatures, and nonces. Use of inadequate pseudo-random number generators (PRNGs) can result in little or no security, as an attacker may reproduce the PRNG state and search a small set of possible values. RFC 1750 and FIPS PUB 186 Appendix 3 provide guidance.
Mutual DSA authentication adds a fifth step beyond unilateral: after the client sends DSS_CERTA_TOKENAB, the server replies with DSS_CERTB_TOKENBA2 containing Sequence(TokenID, CertB, TokenBA2). Authentication type pair uses AUTH_HOW_MUTUAL instead of AUTH_HOW_ONE_WAY.
Unilateral (client-to-server) DSA authentication proceeds through four steps: (1) server sends AUTHENTICATION SEND with supported types; (2) client sends NAME and DSS_INITIALIZE; (3) server replies with DSS_TOKENBA containing Sequence(TokenID, TokenBA); (4) client sends DSS_CERTA_TOKENAB containing Sequence(TokenID, CertA, TokenAB). Authentication type pair is DSS | AUTH_CLIENT_TO_SERVER | AUTH_HOW_ONE_WAY | ENCRYPT_OFF | INI_CRED_FWD_OFF.
MessageAB is an ASN.1 SEQUENCE containing tokenId ([0] TokenId), certA ([1] CertData), and tokenAB (TokenAB). TokenAB includes ranA, ranB, entityB (EntityName), timestampB (TimeStamp), and absigValue (OCTET STRING) covering the DSA signature.
MessageBA is an ASN.1 SEQUENCE containing tokenId (context [0] TokenId) and tokenBA (TokenBA with fields ranB RandomNumber and timestampB TimeStamp). Used in server-to-client DSS_TOKENBA exchanges for both unilateral and mutual authentication.
MessageBA2 is an ASN.1 SEQUENCE containing tokenId ([0] TokenId), certB ([1] CertData), and tokenBA2 (TokenBA2). TokenBA2 includes ranB ([0] RandomNumber), ranA ([1] RandomNumber), entityA (EntityName), timestampB2 (TimeStamp), and ba2sigValue (OCTET STRING) for the server's DSA signature in mutual authentication.
RandomNumber is defined as an ASN.1 INTEGER of exactly 20 octets. All DSA signature values are encoded as a SEQUENCE of two integers per the conventions in RFC 2459 section 7.2.2.
TokenId is an ASN.1 SEQUENCE with tokenType (INTEGER) and protoVerNo (INTEGER, always 0x0001). TokenType distinguishes message type and authentication mode: MessageBA unilateral=0x0001, mutual=0x0011; MessageAB unilateral=0x0002, mutual=0x0012; MessageBA2 mutual=0x0013.