< draft-newman-sasl-passdss-00.txt   draft-newman-sasl-passdss-01.txt >
Network Working Group C. Newman Network Working Group C. Newman
Internet Draft: PASS-DSS-SHA-3DES-1 SASL Mechanism Innosoft Internet Draft: PASSDSS-3DES-1 SASL Mechanism Innosoft
Document: draft-newman-sasl-passdss-00.txt January 1998 Document: draft-newman-sasl-passdss-01.txt March 1998
Expires in six months Expires in six months
DSS Secured Password Authentication Mechanism DSS Secured Password Authentication Mechanism
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
ietf-sasl-request@imc.org. Private comments may be sent to the ietf-sasl-request@imc.org. Private comments may be sent to the
author]. author].
1. How to Read This Document 1. How to Read This Document
This document is intended primarily for a programmer. If This document is intended primarily for a programmer. If
successful, it should be possible for a competent programmer to successful, it should be possible for a competent programmer to
write a client implementation using this specification, the SASL write a client implementation using this specification, the SASL
[SASL] specification, an understanding of how to generate random [SASL] specification, an understanding of how to generate random
numbers [RANDOM], a description or implementation of the DES and numbers [RANDOM], a description or implementation of the DES and
SHA1 [SHA1] algorithms and a multiprecision integer math library. SHA1 [SHA1] algorithms and a multi-precision integer math library.
A cryptographic library or a copy of "Applied Cryptography" A cryptographic library or a copy of "Applied Cryptography"
[SCHNEIER] or similar reference is helpful for any implementation [SCHNEIER] or similar reference is helpful for any implementation
and necessary for server DSS key generation. and necessary for server DSS key generation.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in "Key words for in this document are to be interpreted as defined in "Key words for
use in RFCs to Indicate Requirement Levels" [KEYWORDS]. use in RFCs to Indicate Requirement Levels" [KEYWORDS].
1.1. Data Types Used in this Document 1.1. Data Types Used in this Document
A list of data types used in this document follows. Note that the A list of data types used in this document follows. Note that the
majority of this section is copied from the secure shell majority of this section is copied from the secure shell
specification [SSH-ARCH]. specification [SSH-ARCH].
octet A basic 8-bit unit of data. octet A basic 8-bit unit of data.
uint32 A 32-bit unsigned integer. Stored as four octets in uint32 A 32-bit unsigned integer. Stored as four octets in
network byte order (also known as big endian or most network byte order (also known as big endian or most
significant byte [MSB] first). For example, the decimal significant byte [MSB] first). For example, the decimal
value 699921578 (hexidecimal 29b7f4aa) is represented with value 699921578 (hexadecimal 29b7f4aa) is represented with
the hexidecimal octet sequence 29 b7 f4 aa. the hexadecimal octet sequence 29 b7 f4 aa.
string A string is a length-prefixed octet string. The length is string A string is a length-prefixed octet string. The length is
represented as a uint32 with the data immediately represented as a uint32 with the data immediately
following. A length of 0 indicates an empty string. The following. A length of 0 indicates an empty string. The
string MAY contain NUL or 8-bit octets. When used to string MAY contain NUL or 8-bit octets. When used to
represent textual strings, the characters are interpreted represent textual strings, the characters are interpreted
in UTF-8 [UTF-8]. Other character encoding schemes MUST in UTF-8 [UTF-8]. Other character encoding schemes MUST
NOT be used. NOT be used.
mpint Represents multiple precision integers in two's complement mpint Represents multiple precision integers in two's complement
format, stored as a string, most signficant octet first. format, stored as a string, most significant octet first.
Negative numbers have one in the most significant bit of Negative numbers have one in the most significant bit of
the first octet of the string data. If the most significant the first octet of the string data. If the most significant
bit would be set for a positive number, the number MUST be bit would be set for a positive number, the number MUST be
preceded by a zero byte. Unnecessary leading zero or 255 preceded by a zero byte. Unnecessary leading zero or 255
bytes MUST NOT be included. The value zero MUST be stored bytes MUST NOT be included. The value zero MUST be stored
as a string with zero bytes of data. as a string with zero bytes of data.
By convention, a number that is used in modular By convention, a number that is used in modular
computations in the field of integers mod n SHOULD be computations in the field of integers mod n SHOULD be
represented in the range 0 <= x < n. represented in the range 0 <= x < n.
skipping to change at page 4, line 17 skipping to change at page 4, line 17
The ideal authentication mechanism would be simple, fast, fully The ideal authentication mechanism would be simple, fast, fully
secure, freely distributable without restrictions and backwards secure, freely distributable without restrictions and backwards
compatible with deployed back-end authentication databases. compatible with deployed back-end authentication databases.
Unfortunately, it is not possible to achieve all these goals so Unfortunately, it is not possible to achieve all these goals so
priorities and tradeoffs are necessary. This mechanism has priorities and tradeoffs are necessary. This mechanism has
compatibility with deployed back-end authentication databases and compatibility with deployed back-end authentication databases and
protection from passive and active attacks on the underlying protection from passive and active attacks on the underlying
connection as primary design goals. Simplicity and unrestricted connection as primary design goals. Simplicity and unrestricted
binary distribution are secondary design goals. binary distribution are secondary design goals.
Backwards compatibility is achived by using plaintext passphrases. Backwards compatibility is achieved by using plain-text
Protection from passive and active attacks is achieved by using passphrases. Protection from passive and active attacks is
public and symmetric key technology to encrypt the passphrase and achieved by using public and symmetric key technology to encrypt
optionally protect the remainder of the ession. Some simplicity is the passphrase and optionally protect the remainder of the session.
achieved by avoiding complicated public key certification issues Some simplicity is achieved by avoiding complicated public key
and formats as well as making the SASL session security layer and certification issues and formats as well as making the SASL session
certification by the client optional. Unrestricted binary security layer and certification by the client optional.
distribution is achieved by using unencumbered algorithms and Unrestricted binary distribution is hopefully achieved by using
making the SASL privacy layer optional. unencumbered algorithms and making the SASL privacy layer optional.
2.2. Intended Use 2.2. Intended Use
This is intended as a plug-and-play mechanism for services layered This is intended as a plug-and-play mechanism for services layered
on top of deployed passphrase-based back-end authentication on top of deployed passphrase-based back-end authentication
databases. When no security layer is implemented it can be added databases. When no security layer is implemented it can be added
to a SASL-based protocol without modifying or substituting network to a SASL-based protocol without modifying or substituting network
read and write APIs. When the optional session privacy protection read and write APIs. When the optional session privacy protection
is omitted, the author speculates that it may be possible to make a is omitted, the author speculates that it may be possible to make a
binary implementation which could be exportable from the United binary implementation which would be exportable from the United
States. States.
For cases where simplicity, speed or unrestricted source code For cases where simplicity, speed or unrestricted source code
distribution is more desirable than backwards compatibility or distribution is more desirable than backwards compatibility or
security, a mechanism such as CRAM-MD5 [CRAM-MD5] or SCRAM [SCRAM] security, a mechanism such as CRAM-MD5 [CRAM-MD5] or SCRAM [SCRAM]
is preferred. is preferred.
The optional SASL integrity and privacy protection is provided as a The optional SASL integrity and privacy protection is provided as a
simple alternative to full service security layers such as TLS simple alternative to full service security layers such as TLS
[TLS] or Secure Shell [SSH-ARCH]. However, there are many [TLS] or Secure Shell [SSH-ARCH]. However, there are many
advantages to full service security layers such as compression, advantages to full service security layers such as compression,
faster symmetric cipher options, and the ability to leverage other faster symmetric cipher options, and the ability to leverage other
public key infrastructures. An implementation which supports TLS public key infrastructures. An implementation which supports TLS
may have no incentive to support SASL security layers at all. The may have no incentive to support SASL security layers at all. The
complexity verses functionality tradeoff is significant enough that complexity verses functionality tradeoff is significant enough that
these mechanisms do not compete. these mechanisms do not compete.
2.3. Mechanism Overview 2.3. Mechanism Overview
The PASS-DSS-SHA-3DES-1 mechanism uses three components to perform The PASSDSS-3DES-1 mechanism uses three components to perform a
a secure authentication against a legacy passphrase database. secure authentication against a legacy passphrase database.
In order to protect against active attacks, a DSS public key in a In order to protect against active attacks, a DSS public key in a
format compatible with Secure Shell [SSH-TRANS] is used to format compatible with Secure Shell [SSH-TRANS] is used to
authenticate the server to the client. The client is presumed to authenticate the server to the client. The client is presumed to
have the server's public key or a SHA-1 hash thereof stored locally have the server's public key or a SHA-1 hash thereof stored locally
in a secure database. If the client is willing to risk exposure to in a secure database. If the client is willing to risk exposure to
active attacks, it may skip the public key certification step active attacks, it may skip the public key certification step
altogether or do a one-time initialization of its local database, altogether or do a one-time initialization of its local database,
perhaps with user interaction. perhaps with user interaction.
In addition to the DSS public key, a Diffie-Hellman key exchange is In addition to the DSS public key, a Diffie-Hellman key exchange is
used to generate a key for encrypting the passphrase. The "PASS- used to generate a key for encrypting the passphrase. The
DSS-SHA-3DES-1" variant of this mechanism uses the same fixed "PASSDSS-3DES-1" variant of this mechanism uses the same fixed
Diffie-Hellman group used by Secure Shell's diffie-hellman-group1- Diffie-Hellman group used by Secure Shell's diffie-hellman-group1-
sha1 key exchange [SSH-TRANS]. If more groups are necessary, they sha1 key exchange [SSH-TRANS]. If more groups are necessary, they
will be assigned to mechanism variants "PASS-DSS-SHA-3DES-2" and so will be assigned to mechanism variants "PASSDSS-3DES-2" and so
forth. forth.
Finally, the triple-DES algorithm is used to encrypt the client's Finally, the triple-DES algorithm is used to encrypt the client's
passphrase and send it to the server. passphrase and send it to the server.
2.4. Message Format Overview 2.4. Message Format Overview
This section provides a quick overview of the format of the This section provides a quick overview of the format of the
messages. The formal definition of the syntax for these messages messages. The formal definition of the syntax for these messages
is in section 6. A detailed discussion of their implementation on is in section 6. A detailed discussion of their implementation on
skipping to change at page 6, line 16 skipping to change at page 6, line 16
mpint r ; DSA signature parameters mpint r ; DSA signature parameters
mpint s mpint s
The client then sends the following message encrypted with The client then sends the following message encrypted with
triple-DES: triple-DES:
OCTET csecmask ; SASL security layer selection OCTET csecmask ; SASL security layer selection
3 OCTET cbuflen ; maximum client block size 3 OCTET cbuflen ; maximum client block size
string passphrase ; the user's passphrase string passphrase ; the user's passphrase
20 OCTET cli-hmac ; a client HMAC-SHA-1 signature 20 OCTET cli-hmac ; a client HMAC-SHA-1 signature
3. Client Implementation of PASS-DSS-SHA-3DES-1 3. Client Implementation of PASSDSS-3DES-1
This section includes a step-by-step guide for client implementors. This section includes a step-by-step guide for client implementors.
Although section 6 contains the formal definition of the syntax and Although section 6 contains the formal definition of the syntax and
is the authoritative reference in case of errors here, this section is the authoritative reference in case of errors here, this section
should be sufficient to build a correct implementation. should be sufficient to build a correct implementation.
The SASL mechanism name is "PASS-DSS-SHA-3DES-1". The SASL mechanism name is "PASSDSS-3DES-1".
The value of n used for the Diffie-Hellman exchange is as follows The value of n used for the Diffie-Hellman exchange is as follows
(represented as an unsigned hexidecimal integer): (represented as an unsigned hexadecimal integer):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF. FFFFFFFF FFFFFFFF.
When represented as an "mpint", this would have a prefix of When represented as an "mpint", this would have a prefix of
"0000008100." The value of g is 2. This group was taken from the "0000008100." The value of g is 2. This group was taken from the
ISAKMP/Oakley specification, and was originally generated by ISAKMP/Oakley specification, and was originally generated by
Richard Schroeppel at the University of Arizona. Properties of Richard Schroeppel at the University of Arizona. Properties of
this prime are described in [Orm96]. this prime are described in [Orm96].
The client begins by doing the following: The client begins by doing the following:
(A) Generate the Diffie-Hellman private value "x". This can be (A) Generate the Diffie-Hellman private value "x". This should be
generated as a random integer between (n - 1)/4 and (n - 1)/2. It less than (n - 1)/2. The number of bits of entropy to use in "x"
is important to generate a good random number [RANDOM]. is an important decision, as shorter lengths will be less secure
and longer lengths will noticeably reduce performance. At the time
this was written, 192 bits of entropy [RANDOM] is probably
sufficient. For more information on this topic, see [SHORT-EXP].
(B) Compute the Diffie-Hellman public value "X" as follows. If X (B) Compute the Diffie-Hellman public value "X" as follows. If X
has a value of 0, repeat step (A). has a value of 0, repeat step (A).
x x
X = 2 mod n X = 2 mod n
The client then sends the following three pieces of information to The client then sends the following three pieces of information to
the server: the server:
(1) An authorization identity represented as a string. When the (1) An authorization identity represented as a string. When the
skipping to change at page 7, line 29 skipping to change at page 7, line 34
information: information:
(4) An "ssh-dss" public key compatible with Secure Shell, including (4) An "ssh-dss" public key compatible with Secure Shell, including
the 32-bit length prefix in network byte order, the Secure Shell the 32-bit length prefix in network byte order, the Secure Shell
string "ssh-dss" and mpints for "p", "q", "g" and "y" (see Appendix string "ssh-dss" and mpints for "p", "q", "g" and "y" (see Appendix
A.1). A.1).
(5) The mpint "Y" as defined for the Diffie-Hellman key exchange (5) The mpint "Y" as defined for the Diffie-Hellman key exchange
(see Appendix A.2). (see Appendix A.2).
(6) A single octet bitmask representing the security layers (6) A single octet bit mask representing the security layers
available in the same format used by the KERBEROS_V4 mechanism available in the same format used by the KERBEROS_V4 mechanism
[SASL]. Bit 0 (value 1) indicates it is permissible to have no [SASL]. Bit 0 (value 1) indicates it is permissible to have no
security layer. Bit 1 (value 2) indicates integrity protection is security layer. Bit 1 (value 2) indicates integrity protection is
permissible. Bit 2 (value 4) indicates privacy protection for the permissible. Bit 2 (value 4) indicates privacy protection for the
rest of the session is available. The remaining bits are reserved rest of the session is available. The remaining bits are reserved
for future use. for future use.
(7) A three octet unsigned integer in network byte order (7) A three octet unsigned integer in network byte order
representing the maximum cipher-text buffer size the server is able representing the maximum cipher-text buffer size the server is able
to receive. If this is less than 32, it indicates that a SASL to receive. If this is less than 32, it indicates that a SASL
skipping to change at page 8, line 10 skipping to change at page 8, line 15
(D) Verify that the public key from step (4) belongs to the server. (D) Verify that the public key from step (4) belongs to the server.
This can be done either with a database of SSH public keys or with This can be done either with a database of SSH public keys or with
a database of SHA1 hashes of such public keys. If the client does a database of SHA1 hashes of such public keys. If the client does
not have a matching entry for the server or does not have a public not have a matching entry for the server or does not have a public
key database, it MAY skip this step although it SHOULD alert the key database, it MAY skip this step although it SHOULD alert the
user that the connection is susceptible to active attacks if it user that the connection is susceptible to active attacks if it
does so. It MAY also record the public key (or SHA1 hash thereof) does so. It MAY also record the public key (or SHA1 hash thereof)
in its database with permission from the user. in its database with permission from the user.
(E) Compute the Diffie-Hellman key K as follows: (E) Compute the Diffie-Hellman key K as follows. It may be
necessary to mask timing attacks [TIMING].
x x
K = Y mod n K = Y mod n
(F) Create a buffer containing data from steps (1) through (7) in (F) Create a buffer containing data from steps (1) through (7) in
order immediately followed by K represented as an mpint. order immediately followed by K represented as an mpint.
(G) Compute the SHA1 hash of the buffer from (F). This produces a (G) Compute the SHA1 hash of the buffer from (F). This produces a
20 octet result. 20 octet result.
(H) If the public key from step (4) was not certified, this step (H) If the public key from step (4) was not certified, this step
skipping to change at page 8, line 41 skipping to change at page 8, line 47
sc-encryption-iv = SHA1( K || "B" || H ) sc-encryption-iv = SHA1( K || "B" || H )
cs-encryption-key-1 = SHA1( K || "C" || H ) cs-encryption-key-1 = SHA1( K || "C" || H )
cs-encryption-key-2 = SHA1( K || cs-encryption-key-1 ) cs-encryption-key-2 = SHA1( K || cs-encryption-key-1 )
cs-encryption-key = cs-encryption-key-1 || cs-encryption-key-2 cs-encryption-key = cs-encryption-key-1 || cs-encryption-key-2
sc-encryption-key-1 = SHA1( K || "D" || H ) sc-encryption-key-1 = SHA1( K || "D" || H )
sc-encryption-key-2 = SHA1( K || sc-encryption-key-1 ) sc-encryption-key-2 = SHA1( K || sc-encryption-key-1 )
sc-encryption-key = sc-encryption-key-1 || sc-encryption-key-2 sc-encryption-key = sc-encryption-key-1 || sc-encryption-key-2
cs-integrity-key = SHA1( K || "E" || H ) cs-integrity-key = SHA1( K || "E" || H )
sc-integrity-key = SHA1( K || "F" || H ) sc-integrity-key = SHA1( K || "F" || H )
(J) Create a buffer beginning with a bitmask for the selected (J) Create a buffer beginning with a bit mask for the selected
security layer (it MUST be one offered in 6) followed by three security layer (it MUST be one offered in 6) followed by three
octets representing the maximum cipher-text buffer size (at least octets representing the maximum cipher-text buffer size (at least
32) the client can accept in network byte order. This is followed 32) the client can accept in network byte order. This is followed
by a string containing the passphrase. Note that integrity by a string containing the passphrase. Note that integrity
protection is pointless unless the public key was certified in protection is pointless unless the public key was certified in
step (D) and the signature was verified in step (H). step (D) and the signature was verified in step (H).
(K) Create a buffer containing items (1) through (7) immediately (K) Create a buffer containing items (1) through (7) immediately
followed by the first four octets of (J). followed by the first four octets of (J).
skipping to change at page 9, line 38 skipping to change at page 9, line 43
(starting from 0) immediately followed by the cs-integrity-key from (starting from 0) immediately followed by the cs-integrity-key from
step (I). step (I).
(P) Compute HMAC-SHA-1 with (O) as the key and the data to transmit (P) Compute HMAC-SHA-1 with (O) as the key and the data to transmit
as the data. as the data.
(Q) Create a buffer containing the data to transmit followed by the (Q) Create a buffer containing the data to transmit followed by the
20-octet output of (P). If privacy was negotiated on, this is 20-octet output of (P). If privacy was negotiated on, this is
followed by zero to seven padding octets followed by one more octet followed by zero to seven padding octets followed by one more octet
indicating the number of padding octets. The total size MUST be a indicating the number of padding octets. The total size MUST be a
multiple of the DES blocksize. multiple of the DES block size.
(R) The result of step (Q) is encrypted with triple-DES if privacy (R) The result of step (Q) is encrypted with triple-DES if privacy
was negotiated and is sent prefixed by a uint32 length, as required was negotiated and is sent prefixed by a uint32 length, as required
by SASL. by SASL.
If a SASL security layer was negotiated on, the following steps are If a SASL security layer was negotiated on, the following steps are
taken when receiving a message: taken when receiving a message:
(S) If privacy was negotiated on, the message is decrypted using (S) If privacy was negotiated on, the message is decrypted using
triple-DES with the first 24 octets of sc-encryption-key as the triple-DES with the first 24 octets of sc-encryption-key as the
skipping to change at page 10, line 13 skipping to change at page 10, line 19
used to initialize triple-DES state the first time this is done. used to initialize triple-DES state the first time this is done.
(T) Create a buffer containing a uint32 server packet number (T) Create a buffer containing a uint32 server packet number
(starting from 0) immediately followed by the sc-integrity-key. (starting from 0) immediately followed by the sc-integrity-key.
(U) Compute HMAC-SHA-1 with (T) as the key over the portion of the (U) Compute HMAC-SHA-1 with (T) as the key over the portion of the
data excluding the 20 octet signature and any encryption padding. data excluding the 20 octet signature and any encryption padding.
If this is the same as the 20 octet signature, then the data is not If this is the same as the 20 octet signature, then the data is not
corrupted. corrupted.
4. Server Implementation of PASS-DSS-SHA-3DES-1 4. Server Implementation of PASSDSS-3DES-1
The section includes a step-by-step guide for server implementors. The section includes a step-by-step guide for server implementors.
It is intended to be read in conjunction with section 3. It is intended to be read in conjunction with section 3.
The server MUST have a persistant DSS-SSH public key. Mechanisms The server MUST have a persistent DSS-SSH public key. Mechanisms
for generating such keys are described in [SCHNEIER] and [DSS]. for generating such keys are described in [SCHNEIER] and [DSS].
IMPORTANT NOTE: The server MUST be able to process any message from IMPORTANT NOTE: The server MUST be able to process any message from
the client, including messages of any size, messages with invalid the client, including messages of any size, messages with invalid
content and messages with NULs in the middle of strings. When content and messages with NULs in the middle of strings. When
input is illegal, the server MUST gracefully reject authentication input is illegal, the server MUST gracefully reject authentication
or in extreme cases gracefully terminate the connection. or in extreme cases gracefully terminate the connection.
Particular care to avoid buffer overruns is important if the user Particular care to avoid buffer overruns is important if the user
name or passphrase strings are copied. name or passphrase strings are copied.
The server performs the following computations prior to or during The server performs the following computations prior to or during
the connection by the client: the connection by the client:
(a) Select a random number k from (p - 1)/4 to (p - 1)/2. It is (a) Select a random number k less than (p - 1)/2. It is important
important to generate a good random number [RANDOM]. to generate a good random number [RANDOM].
(b) Compute signature component "r" as follows: (b) Compute signature component "r" as follows:
k k
r = (g mod p) mod q r = (g mod p) mod q
(c) Optionally pre-compute the group inverse of k, mod q and the (c) Optionally pre-compute the group inverse of k, mod q and the
value xr. value xr.
(d) Select a random number y from (n - 1)/4 to (n - 1)/2. It is (d) Select a random Diffie-Hellman private key y less than (n -
important to generate a good random number [RANDOM]. 1)/2. Follow the same guidance as in (A) above.
(e) Compute the Diffie-Hellman public value Y as follows: (e) Compute the Diffie-Hellman public value Y as follows. If Y has
a value of 0, repeat step (d) above.
y y
Y = 2 mod n Y = 2 mod n
(f) Verify that the value X from the client is between 1 and (n - (f) Verify that the value X from the client is between 1 and (n -
1). If it isn't, fail the authentication. 1). If it isn't, fail the authentication.
(g) Compute the Diffie-Hellman shared key K as follows: (g) Compute the Diffie-Hellman shared key K as follows. It may be
necessary to mask timing attacks [TIMING].
y y
K = X mod n K = X mod n
(h) Create a buffer containing items (1) through (7) above followed (h) Create a buffer containing items (1) through (7) above followed
by K represented as an mpint. by K represented as an mpint.
(i) Compute the SHA-1 hash of the buffer from (h). This produces a (i) Compute the SHA-1 hash of the buffer from (h). This produces a
20 octet result. 20 octet result.
(j) Generate a DSS signature of (i). The signature is made up of (j) Generate a DSS signature of (i). The signature is made up of
skipping to change at page 11, line 43 skipping to change at page 12, line 4
fails. fails.
(o) Verify that the selected security layer is permitted and the (o) Verify that the selected security layer is permitted and the
cipher text buffer size is at least 32. If not, fail the cipher text buffer size is at least 32. If not, fail the
authentication. authentication.
(p) Create a buffer containing steps (1) through (7) followed by (p) Create a buffer containing steps (1) through (7) followed by
the first four octets of the result from (m). the first four octets of the result from (m).
(q) Compute the HMAC-SHA-1 of (p) with cs-integrity-key as the key. (q) Compute the HMAC-SHA-1 of (p) with cs-integrity-key as the key.
This produces a 20-octet result. This produces a 20-octet result.
(r) Compare the output of (q) with the 20 octet signature after the (r) Compare the output of (q) with the 20 octet signature after the
passphrase in the output of (m). If they don't match, fail the passphrase in the output of (m). If they don't match, fail the
authentication. authentication.
If a SASL security layer is negotiated on, sending and receiving If a SASL security layer is negotiated on, sending and receiving
procedures are similar to steps (O)-(U), with client and server procedures are similar to steps (O)-(U), with client and server
roles exchanged (and thus sc-* values and cs-* value exchanged). roles exchanged (and thus sc-* values and cs-* value exchanged).
Note that triple-DES state from step (m) is not reset. Note that triple-DES state from step (m) is not reset.
5. Example 5. Example
The following is an example of the PASS-DSS-SHA-3DES-1 mechanism The following is an example of the PASSDSS-3DES-1 mechanism using
using the IMAP [IMAP4] profile of SASL. Note that base64 encoding the IMAP [IMAP4] profile of SASL. Note that base64 encoding and
and the lack of an initial client reponse with the first command the lack of an initial client response with the first command are
are characteristics of the IMAP profile of SASL and not characteristics of the IMAP profile of SASL and not characteristics
characteristics of SASL or this mechanism. of SASL or this mechanism.
In this example, "C:" represents lines sent from the client to the In this example, "C:" represents lines sent from the client to the
server and "S:" represents lines sent from the server to the server and "S:" represents lines sent from the server to the
client. The wrapped lines are for editorial clarity -- there are client. The wrapped lines are for editorial clarity -- there are
no actual newlines in the middle of the messages. no actual newlines in the middle of the messages.
C: a001 AUTHENTICATE PASS-DSS-SHA-3DES-1 C: a001 AUTHENTICATE PASSDSS-3DES-1
S: + S: +
C: AAAAAAAAAAVjaHJpcwAAAIByNdmAm3TWjyEeKfuyLoGUaojr5moPVU6p92/r C: AAAAAAAAAAVjaHJpcwAAAIEAhuVbMxdLxrAQVyUWbAp+X09h6QmZ2Jebz
5QDUAgO9A81wvQH5RbljV7DBONObjlkjfDGbQp3MsmUbtOiNDZrNczUMlCvd H7YhtcbQyLbB9AGi1eIdojZYtAuVeE+PYkKUANLHI9XzWSFliIGMeUvBc
oNsWtQQtU48WrTIL+UP6EQn2Xblw2TgPCFmSHS66p/VILI5BsQsrx31BHnnn bflHr+s9tZ5/5YZh9blb33km3tUYVKyB5XP530bDn+lY1lAv6tXHKZPrx
YVwKz6S7KkYyDA== b0zPhc+JGgpWGlmT5k9vx2Wk=
S: AAAA8gAAAAdzc2gtZHNzAAAAQQDPVlO6nFefrq6fA/dQKIoNj75JjppkVv3D S: + AAAA8gAAAAdzc2gtZHNzAAAAQQDPVlO6nFefrq6fA/dQKIoNj75Jjpp
kyILABCox2dMql0bnO48rHFuo167y6oukT/ocKupIw6bgKmdofgdAAAAFQDR kVv3DkyILABCox2dMql0bnO48rHFuo167y6oukT/ocKupIw6bgKmdofgd
pB6FrxemUGRuLjY/oiH/Qef14QAAAEEAkVr9rOlB58k5XoqmPNYTrVGZKWbC AAAAFQDRpB6FrxemUGRuLjY/oiH/Qef14QAAAEEAkVr9rOlB58k5XoqmP
PcYtaL92ANxgWyjyRo49+m0+fHPNhNibQoLddEZF8lHPKWgb7z7qz0QMdgAA NYTrVGZKWbCPcYtaL92ANxgWyjyRo49+m0+fHPNhNibQoLddEZF8lHPKW
AEARcIEiMz5jTZo8COf2njL3BTWRND5NGAgZY7s1YOm2BfjVyf1/MkOiQMiX gb7z7qz0QMdgAAAEARcIEiMz5jTZo8COf2njL3BTWRND5NGAgZY7s1YOm
eonrsfMc0sWQGgpRYRtJWpe56cc2AAAAgQDa/kF4dHlBpgYew6u/10sFJP8G 2BfjVyf1/MkOiQMiXeonrsfMc0sWQGgpRYRtJWpe56cc2AAAAgQDoV5Uk
QgSE4YdFUl2yJKW4S9azMmqSVsoiAHzeslZogV25yQE3vdsIjtqjVwhcCwu2 bcy3Gjf16MZwPLlJlvmjpSNv2dSSApoddd4+BgZr01zyt7hzb0yRruaN5
nb0kt/Rfu5gOTCygUWsRD0yuiKeOpbiakCLQe1jtjIS2tgLRKQ66Z+q7HI9R fG43DbJLkk7mtL1Hw8aYXBMQQzrPpHtx+anpCDoN2jlersCGFY2cnjxTf
YUqqxFUu53L/iGNf1cbVokepOgEAAAAAAAA7AAAAB3NzaC1kc3MAAAAUMkWf HqY139ohA8vVXYpapeXxKXR4//Ib/ApTGmwlOeIikKDrBmEGX/JgEAAAA
YSZlk0bJI4BKiA8Ju6Yh0DAAAAAUScKvxfqPCm2cdnNyzD7sgmUxC1E= AAAA8AAAAB3NzaC1kc3MAAAAVAI7j3HG8HyjCOxaGFOUTwZqe0xSHAAAA
C: XTs/rtmZ6uYpK8A90hRN5NrdoEAXrzWISOb080+EOFEDd6Gg2Ci720Pw8kRe FHSqU41vPHTCRTqmxNFwXqazPlJH
VY6I C: Obp6vQ83q1O/OnQDifZB1rWOci9LaSck8VxNB4UAFhRI56BAs4XPLqOWI
CoB3LYZ
S: a001 OK Authentication Completed S: a001 OK Authentication Completed
In this example, the client private "x" value, represented as an The following private values were used in this example. These
mpint in hexidecimal is: values are all represented as an mpint in hexadecimal (msb first).
00000080 4bb82066 70638c78 059368d3 8430006c 02e8a05b 708cb774 The client private Diffie-Hellman "x" value:
55b5263b 366f7825 4feaba0d 2e0191c0 411b8ca9 58421a61 26d5a1a1
246797de 7527d020 f0190df0 6939b4fd bf70ea68 4c7f7100 e930008e
4feaba0d 2e0191c0 411b8ca9 58421a61 4feaba0d 2e0191c0 411b8ca9
58421a61 4feaba0d 2e0191c0 411b8ca9 58421a61
The server private "y" value represented as an mpint in hexidecimal 00000018 666E35B4 3BF4BF2B 40E31359 7A5D3AD0 61FD4F6F 736A6114
is:
00000080 4340eba3 631a0fe9 224bdd5c 8d660535 6c290c1d 446e8122 The server private Diffie-Hellman "y" value:
768c6298 2cfa2d6c 057ab971 80cd57d1 c51ff528 0884cbf8 057ab971
80cd57d1 c51ff528 0884cbf8 057ab971 80cd57d1 c51ff528 0884cbf8
057ab971 80cd57d1 c51ff528 0884cbf8 057ab971 80cd57d1 c51ff528
0884cbf8 057ab971 80cd57d1 c51ff528 0884cbf8
The Diffie-Hellman shared secret represented as an mpint in 00000018 587BDFD6 800D101C 8E82E233 3B5A07AA DB87B8F1 68DC194D
hexidecimal is:
00000080 7a81b3c2 702168d8 cce24ccc ae0b938e 84cf27c9 2b192c20 The Diffie-Hellman shared secret:
4ab821f5 fa7b0120 26c45066 c8af8839 4ea186f9 0972d80e 2ff2341a
ba3e8f99 36c10574 c27989fe 719c42ff 2ec45d87 87bba1f5 e9bd2dbf
fbfdf72b b1eee8f3 109e9a3c 40168785 ed4f3ba7 118a864c ebd6dea3
96d93250 821197c4 40a3f13a d0f7ad5f cf22664b
The DSA private key value represented as an mpint in hexidecimal 00000080 3B46D3A8 D2163930 1C33D9FE EAFA528D F4B881CF DF906A03
is: 33249A88 42547FF6 49FDC149 1A5084B1 B425A105 CE571283 AC61D896
AF8F7AF7 F95643F3 00A91E57 BCB8CFD7 77A25CBD 35F59A9E 59E98BEA
EA866339 7F0F9AA0 2F0F335C 8C6AAFF7 76BDB668 DF4D51AF 5B4FB807
81A70901 F478FB86 BF42055C BAF46094 EC72E98A
00000040 11708122 333e634d 9a3c08e7 f69e32f7 05359134 3e4d1808 The DSA private key value (the public key is in the exchange):
1963bb35 60e9b605 f8d5c9fd 7f3243a2 40c8977a 89ebb1f3 1cd2c590
1a0a5161 1b495a97 b9e9c736 00000014 252bcbfa 5634d706 6ed43128
972e181e 66bf9c30
And the SHA-1 hash value used to compute the keys is: 00000014 252BCBFA 5634D706 6ED43128 972E181E 66BF9C30
a5567b02 0f5abe1a b8aa9040 08404432 71744e6a The SHA-1 hash value used to compute the keys:
6. Formal Syntax of PASS-DSS-SHA-3DES-1 Messages 26 75 97 06 EB FE E3 69 C9 03 7D 49 64 19 D5 D2 97 66 E8 CE
6. Formal Syntax of PASSDSS-3DES-1 Messages
This is the formal syntactic definition of the client and server This is the formal syntactic definition of the client and server
messages. This uses ABNF [ABNF] notation including the core rules. messages. This uses ABNF [ABNF] notation including the core rules.
The first three rules define the formal exchange. The later rules The first three rules define the formal exchange. The later rules
define the elements of the exchange. define the elements of the exchange.
client-msg-1 = [azname] authname diffie-hellman-X client-msg-1 = [azname] authname diffie-hellman-X
server-msg-1 = dss-public-key diffie-hellman-Y server-msg-1 = dss-public-key diffie-hellman-Y
ssecmask sbuflen dss-signature ssecmask sbuflen dss-signature
skipping to change at page 15, line 22 skipping to change at page 15, line 22
string = length *OCTET string = length *OCTET
;; the length determines the number of octets ;; the length determines the number of octets
;; OCTETs are interpreted as UTF-8 ;; OCTETs are interpreted as UTF-8
NUL = %x00 ;; US-ASCII NUL character NUL = %x00 ;; US-ASCII NUL character
7. Security Considerations 7. Security Considerations
Security considerations are discussed throughout this memo. Security considerations are discussed throughout this memo.
This mechanism supplies the server with the plaintext passphrase, This mechanism supplies the server with the plain-text passphrase,
so the server gains the ability to masquerade as the user to any so the server gains the ability to masquerade as the user to any
other services which share the same passphrase. other services which share the same passphrase.
If the public key certification step is skipped, then an active If the public key certification step is skipped, then an active
attacker can gain the client's passphrase and thus the ability to attacker can gain the client's passphrase and thus the ability to
masquerade as the user to any other services which share the same masquerade as the user to any other services which share the same
passphrase. Negotiating a security layer will fail to provide passphrase. Negotiating a security layer will fail to provide
protection from an active attacker in this case. protection from an active attacker in this case.
If no security layer is negotiated, the rest of the protocol If no security layer is negotiated, the rest of the protocol
skipping to change at page 15, line 45 skipping to change at page 15, line 45
If an integrity-only layer is negotiated, the rest of the protocol If an integrity-only layer is negotiated, the rest of the protocol
is subject to passive eavesdropping. is subject to passive eavesdropping.
The quality of this mechanism depends on the quality of the random The quality of this mechanism depends on the quality of the random
number generator used. See [RANDOM] for more information. number generator used. See [RANDOM] for more information.
8. Multinational Considerations 8. Multinational Considerations
As remote access is a crucial service, users are encouraged to As remote access is a crucial service, users are encouraged to
restrict user names and passphrases to the US-ASCII character set. restrict user names and passphrases to the US-ASCII character set.
However, if characters outside the US-ASCII chracter set are used However, if characters outside the US-ASCII character set are used
in user names and passphrases, then they are interpreted according in user names and passphrases, then they are interpreted according
to UTF-8 [UTF-8] and it is a protocol error to include any octet to UTF-8 [UTF-8] and it is a protocol error to include any octet
sequences not legal for UTF-8. Servers are encourged to enforce sequences not legal for UTF-8. Servers are encouraged to enforce
this restriction to discourage clients which use unlabelled this restriction to discourage clients from using non-interoperable
character sets in this context. local character sets in this context.
9. Intellectual Property Issues and Acknowledgments
9. Intellectual Property Issues and Acknowledgements
David Kravitz holds U.S. Patent #5,231,668 on the DSA algorithm. David Kravitz holds U.S. Patent #5,231,668 on the DSA algorithm.
NIST [NIST] has made this patent available world-wide on a NIST has made this patent available world-wide on a royalty-free
royalty-free basis. basis.
Diffie-Hellman was the first public-key algorithm ever invented. Diffie-Hellman was first published in 1976 [DIFFIE-HELLMAN]. U.S.
It was first published in 1976 [DIFFIE-HELLMAN]. U.S. Patent Patent #4,200,770 granted April 1980 has expired. Canada Patent
#4,200,770 granted April 1980 has expired. Canada Patent
#1,121,480 was granted April 6, 1982 and may still apply at this #1,121,480 was granted April 6, 1982 and may still apply at this
time. time.
DES is covered under U.S. Patent #3,962,539 granted June 1978, DES is covered under U.S. Patent #3,962,539 granted June 1978,
which has expired. which has expired.
The majority of the constructions in this specification were copied The majority of the constructions in this specification were copied
from the Secure Shell specifications [SSH-ARCH, SSH-TRANS]. from the Secure Shell specifications [SSH-ARCH, SSH-TRANS].
Additional information is paraphrased from "Applied Cryptography" Additional information is paraphrased from "Applied Cryptography"
[SCHNEIER]. [SCHNEIER].
skipping to change at page 17, line 5 skipping to change at page 17, line 5
[HMAC-TEST] Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", [HMAC-TEST] Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
RFC 2202, IBM, NIST, September 1997. RFC 2202, IBM, NIST, September 1997.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, University of Washington, December 1996. 4rev1", RFC 2060, University of Washington, December 1996.
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997. Requirement Levels", RFC 2119, Harvard University, March 1997.
[NIST] "Proposed Federal Information Processing Standard for Secure
Hash Standard," Federal Register, v. 57, n. 21, January 1992, pp.
3747-3749.
[Orm96] Orman, H., "The Oakley Key Determination Protocol", version [Orm96] Orman, H., "The Oakley Key Determination Protocol", version
1, TR97-92, Department of Computer Science Technical Report, 1, TR97-92, Department of Computer Science Technical Report,
University of Arizona. University of Arizona.
[RANDOM] Eastlake, Crocker, Schiller, "Randomness Recommendations [RANDOM] Eastlake, Crocker, Schiller, "Randomness Recommendations
for Security", RFC 1750, DEC, Cybercash, MIT, December 1994. for Security", RFC 1750, DEC, Cybercash, MIT, December 1994.
[SASL] Myers, "Simple Authentication and Security Layer (SASL)", [SASL] Myers, "Simple Authentication and Security Layer (SASL)",
RFC 2222, Netscape Communications, October 1997. RFC 2222, Netscape Communications, October 1997.
[SCHNEIER] Schneier, B., "Applied Cryptography: Protocols, [SCHNEIER] Schneier, B., "Applied Cryptography: Protocols,
Algorithms and Source Code in C," John Wiley and Sons, Inc., 1996. Algorithms and Source Code in C," John Wiley and Sons, Inc., 1996.
[SCRAM] Newman, "Salted Challenge Response Authentication Mechanism [SCRAM] Newman, "Salted Challenge Response Authentication Mechanism
(SCRAM)", work in progress, October 1997. (SCRAM)", work in progress, January 1998.
[SHA1] See [DSS]. [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of Commerce,
April 1995.
[SHORT-EXP] van Oorschot, P., Wiener, M., "On Diffie-Hellman Key
Agreement with Short Exponents", Advances in Cryptography --
EUROCRYPT Springer-Verlag, ISBN 3-540-61186-X, pp. 332-343.
[SSH-ARCH] Ylonen, Kivinen, Saarinen, "SSH Protocol Architecture", [SSH-ARCH] Ylonen, Kivinen, Saarinen, "SSH Protocol Architecture",
Work in progress, SSH, October 1997. Work in progress, SSH, October 1997.
[SSH-TRANS] Ylonen, Kivinen, Saarinen, "SSH Transport Layer [SSH-TRANS] Ylonen, Kivinen, Saarinen, "SSH Transport Layer
Protocol", Work in progress, SSH, October 1997. Protocol", Work in progress, SSH, October 1997.
[TIMING] Kocher, P., "Timing Attacks on Implementations of Diffie-
Hellman, RSA, DSS and Other Systems", Advances in Cryptography --
CRYPTO '96 Proceedings, Lecture Notes in Computer Science, Vol
1109, Springer-Verlag, ISBN 3-540-61512-1, pp. 104-113.
[TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in
progress. progress.
[UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and [UTF8] Yergeau, "UTF-8, a transformation format of ISO 10646",
ISO 10646", RFC 2044, Alis Technologies, October 1996. RFC 2279, Alis Technologies, January 1998.
11. Author's Address 11. Author's Address
Chris Newman Chris Newman
Innosoft International, Inc. Innosoft International, Inc.
1050 Lakes Drive 1050 Lakes Drive
West Covina, CA 91790 USA West Covina, CA 91790 USA
Email: chris.newman@innosoft.com Email: chris.newman@innosoft.com
skipping to change at page 19, line 4 skipping to change at page 19, line 14
-1 -1
s = (k (SHA1(m) + xr)) mod q s = (k (SHA1(m) + xr)) mod q
The signature is represented as r and s, and is verified as The signature is represented as r and s, and is verified as
follows: follows:
-1 -1
w = s mod q w = s mod q
u1 = (SHA1(m) * w) mod q u1 = (SHA1(m) * w) mod q
u2 = (rw) mod q u2 = (rw) mod q
u1 u2 u1 u2
v = ((g * y ) mod p) mod q v = ((g * y ) mod p) mod q
If v = r then the signature is verified. If v = r then the signature is verified.
Appendix A.2. Diffie-Hellman Algorithm Appendix A.2. Diffie-Hellman Algorithm
The Diffie-Hellman algorithm is a key-exchange algorithm. It The Diffie-Hellman algorithm is a key-exchange algorithm. It
allows two ends of a communications channel to establish a shared allows two ends of a communications channel to establish a shared
secret which a passive eavesdropper can not easily determine. This secret which a passive eavesdropper can not easily determine. This
key can then be used in a symmetric algorithm such as triple-DES. key can then be used in a symmetric algorithm such as triple-DES.
The two ends have a prior agreement on two numbers: The two ends have a prior agreement on two numbers:
n a large prime number n a large prime number
g a primiative mod n. g a primitive mod n.
The client chooses a random large integer x and computes: The client chooses a random large integer x and computes:
x x
X = g mod n X = g mod n
and sends X to the server. The server chooses a random large and sends X to the server. The server chooses a random large
integer y and computes: integer y and computes:
y y
skipping to change at page 20, line 7 skipping to change at page 20, line 16
Appendix A.3. Triple-DES Algorithm in EDE/outer-CBC Mode Appendix A.3. Triple-DES Algorithm in EDE/outer-CBC Mode
The DES algorithm uses an 8 octet (64 bit) key of which 56 bits are The DES algorithm uses an 8 octet (64 bit) key of which 56 bits are
significant. The triple-DES EDE algorithm uses a 24 octet (192 significant. The triple-DES EDE algorithm uses a 24 octet (192
bit) key of which roughly 112 bits are significant see [SCHNEIER] bit) key of which roughly 112 bits are significant see [SCHNEIER]
for more details. The "EDE" refers to encrypt-decrypt-encrypt, and for more details. The "EDE" refers to encrypt-decrypt-encrypt, and
the "CBC" refers to cipher-block-chaining where each cipher block the "CBC" refers to cipher-block-chaining where each cipher block
affects future cipher blocks. If E() is the DES encryption affects future cipher blocks. If E() is the DES encryption
function, D() is the DES decryption function, C is a cipher text function, D() is the DES decryption function, C is a cipher text
block and P is a plaintext block, then triple-DES EDE in CBC mode block and P is a plain-text block, then triple-DES EDE in CBC mode
with outer chaining is: with outer chaining is:
C = E (D (E (P XOR C ))) C = E (D (E (P XOR C )))
i K3 K2 K1 i i-1 i K3 K2 K1 i i-1
NOTE: C is the initialization vector NOTE: C is the initialization vector
0 0
and the decryption function is: and the decryption function is:
skipping to change at page 20, line 42 skipping to change at page 20, line 51
SHA-1 function to produce a 20 octet key. SHA-1 function to produce a 20 octet key.
(B) The key is exclusive-ored with a 64 octet buffer filled with (B) The key is exclusive-ored with a 64 octet buffer filled with
the octet value 0x36. the octet value 0x36.
(C) SHA-1 is computed over (B) followed by the input text. (C) SHA-1 is computed over (B) followed by the input text.
(D) The key is exclusive-ored with a 64 octet buffer filled with (D) The key is exclusive-ored with a 64 octet buffer filled with
the octet value 0x5C. the octet value 0x5C.
(E) SHA-1 is computed over (D) followed by (C). (E) SHA-1 is computed over (D) followed by the output of (C).
 End of changes. 53 change blocks. 
113 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/