TELNET Authentication Using DSA(3)

Figure 2

4. ASN.1 Syntax

As stated earlier, a conformant subset of the defined fields andubfields from FIPS PUB 196 have been selected. This sectionrovides the ASN.1 syntax for that conformant subset.igure 1 and Figure 2 include representations of the structures

defined in this section. Implementors should refer to the following table to determine the ASN.1 definitions that match the figure references:

Figure 1 Sequence( TokenID, TokenBA ) MessageBA

Sequence( TokenID, CertA, TokenAB ) MessageAB

Figure 2 Sequence( TokenID, TokenBA ) MessageBA

Sequence( TokenID, CertA, TokenAB ) MessageAB

Sequence( TokenID, CertB, TokenBA2 ) MessageBA2

The following ASN.1 definitions specify the conformant subset of FIPS196. For simplicity, no optional fields or subfields are included.

The ASN.1 definition for CertificationPath is imported from CCITT Recommendation X.509 [X.509], and The ASN.1 definition for Name is imported from CCITT Recommendation X.501 [X.501]. These ASN.1definitions are not repeated here. All DSA signature values are encoded as a sequence of two integers, employing the same conventions specified in RFC2459, section 7.2.2.

MessageBA ::= SEQUENCE {

tokenId [0] TokenId, tokenBA TokenBA }

TokenBA ::= SEQUENCE {ranB RandomNumber, timestampB TimeStamp }

MessageAB ::= SEQUENCE {

tokenId [0] TokenId,

certA [1] CertData,

tokenAB TokenAB }

TokenAB ::= SEQUENCE {

ranA RandomNumber,

ranB RandomNumber,

entityB EntityName,

timestampB TimeStamp,

absigValue OCTET STRING }

MessageBA2 ::= SEQUENCE {

tokenId [0] TokenId,

certB [1] CertData,

tokenBA2 TokenBA2 }

TokenBA2 ::= SEQUENCE {

ranB [0] RandomNumber,

ranA [1] RandomNumber,

entityA EntityName,

timestampB2 TimeStamp,

ba2sigValue OCTET STRING }

CertData ::= SEQUENCE {

certPath [0] CertificationPath } -- see X.509

EntityName ::= SEQUENCE OF CHOICE { -- only allow one!

directoryName [4] Name } -- see X.501

RandomNumber ::= INTEGER -- 20 octets

TokenId ::= SEQUENCE {

tokenType INTEGER, -- see table below

protoVerNo INTEGER } -- always 0x0001

TimeStamp ::= GeneralizedTime

The TokenId.TokenType is used to distinguish the message type and the authentication type (either unilateral or mutual). The following table provides the values needed to implement this specification:

Message Type Authentication Type TokenId.TokenType

MessageBA Unilateral 0x0001

Mutual 0x0011

MessageAB Unilateral 0x0002

Mutual 0x0012

MessageBA Mutual 0x0013

5. Security Considerations

This entire memo is about security mechanisms. For DSA to provide the authentication discussed, the implementation must protect the private key from disclosure.

Implementations must randomly generate DSS private keys, 'k' values used in DSS signatures, and nonces. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic values can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the values, searching the resulting small set of possibilities, rather than using a brute force search. The generation of quality random numbers is difficult.

RFC1750[RFC1750] offers important guidance in this area, and Appendix 3 of FIPS PUB 186 [FIPS186] provides one quality PRNG technique.

6. Acknowledgements

We would like to thank William Nace for support during implementation of this specification.

7. IANA Considerations

The authentication type DSS and its associated suboption values are registered with IANA. Any suboption values used to extend the protocol as described in this document must be registered with IANA before use. IANA is instructed not to issue new suboption values without submission of documentation of their use.

8. References

FIPS180-1 Secure Hash Standard. FIPS Pub 180-1. April 17, 1995.

<　　DSS

　　AUTH_CLIENT_TO_SERVER |

　　AUTH_HOW_MUTUAL |

　　ENCRYPT_OFF |

　　INI_CRED_FWD_OFF

　　DSS_CERTB_TOKENBA2

　　Sequence( TokenID, CertB,

　　TokenBA2 )

　　IAC SE

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

　　Figure 2

　　4. ASN.1 Syntax

　　As stated earlier, a conformant subset of the defined fields and subfields from FIPS PUB 196 have been selected. This section　provides the ASN.1 syntax for that conformant subset.

　　Figure 1 and Figure 2 include representations of the structures defined in this section. Implementors should refer to the following　table to determine the ASN.1 definitions that match the figure　　references:

　　Figure 1 Sequence( TokenID, TokenBA ) MessageBA

　　Sequence( TokenID, CertA, TokenAB ) MessageAB

　　Figure 2 Sequence( TokenID, TokenBA ) MessageBA

　　Sequence( TokenID, CertA, TokenAB ) MessageAB

　　Sequence( TokenID, CertB, TokenBA2 ) MessageBA2

　　The following ASN.1 definitions specify the conformant subset of FIPS

　　196. For simplicity, no optional fields or subfields are included.

　　The ASN.1 definition for CertificationPath is imported from CCITT

　　Recommendation X.509 [X.509], and The ASN.1 definition for Name is　imported from CCITT Recommendation X.501 [X.501]. These ASN.1　definitions are not repeated here. All DSA signature values are　encoded as a sequence of two integers, employing the same conventions　specified in RFC2459, section 7.2.2.

　　MessageBA ::= SEQUENCE {

　　tokenId [0] TokenId,

　　tokenBA TokenBA }

　　TokenBA ::= SEQUENCE {

　　ranB RandomNumber,

　　timestampB TimeStamp }

　　MessageAB ::= SEQUENCE {

　　tokenId [0] TokenId,

　　certA [1] CertData,

　　tokenAB TokenAB }

　　TokenAB ::= SEQUENCE {

　　ranA RandomNumber,

　　ranB RandomNumber,

　　entityB EntityName,

　　timestampB TimeStamp,

　　absigValue OCTET STRING }

　　MessageBA2 ::= SEQUENCE {

　　tokenId [0] TokenId,

　　certB [1] CertData,

　　tokenBA2 TokenBA2 }

　　TokenBA2 ::= SEQUENCE {

　　ranB [0] RandomNumber,

　　ranA [1] RandomNumber,

　　entityA EntityName,

　　timestampB2 TimeStamp,

　　ba2sigValue OCTET STRING }