Gecko [ www.finalhopeacademy.com ]

Name	Size	Permission
draft-burdis-cat-srp-sasl-xx.t...	89.7 KB	-rw-r--r--
draft-ietf-sasl-anon-xx.txt	17.24 KB	-rw-r--r--
draft-ietf-sasl-crammd5-xx.txt	14.75 KB	-rw-r--r--
draft-ietf-sasl-gssapi-xx.txt	22.19 KB	-rw-r--r--
draft-ietf-sasl-plain-xx.txt	16.94 KB	-rw-r--r--
draft-ietf-sasl-rfc2222bis-xx....	47.13 KB	-rw-r--r--
draft-ietf-sasl-rfc2831bis-xx....	74.72 KB	-rw-r--r--
draft-ietf-sasl-saslprep-xx.tx...	11.2 KB	-rw-r--r--
draft-murchison-sasl-login-xx....	11.66 KB	-rw-r--r--
draft-newman-sasl-c-api-xx.txt	52.63 KB	-rw-r--r--
draft-newman-sasl-passdss-xx.t...	41.55 KB	-rw-r--r--
rfc1321.txt	34.4 KB	-rw-r--r--
rfc1939.txt	45.92 KB	-rw-r--r--
rfc2104.txt	21.77 KB	-rw-r--r--
rfc2195.txt	10.22 KB	-rw-r--r--
rfc2222.txt	34.19 KB	-rw-r--r--
rfc2243.txt	19.27 KB	-rw-r--r--
rfc2245.txt	9.74 KB	-rw-r--r--
rfc2289.txt	55.17 KB	-rw-r--r--
rfc2444.txt	13.09 KB	-rw-r--r--
rfc2595.txt	31.68 KB	-rw-r--r--
rfc2831.txt	56.76 KB	-rw-r--r--
rfc2945.txt	17.42 KB	-rw-r--r--
rfc3174.txt	34.69 KB	-rw-r--r--
testing.txt	3.2 KB	-rw-r--r--

Code Editor : draft-newman-sasl-passdss-xx.txt

Network Working Group                                          C. Newman
Internet Draft: PASSDSS-3DES-1 SASL Mechanism                   Innosoft
Document: draft-newman-sasl-passdss-01.txt                    March 1998
                                                   Expires in six months

DSS Secured Password Authentication Mechanism

Status of this memo

This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its areas,
     and its working groups.  Note that other groups may also distribute
     working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."

To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
     Coast), or ftp.isi.edu (US West Coast).

Abstract

Some system administrators are faced with a choice between
     deploying a new authentication infrastructure or sending
     unencrypted passwords in the clear over the Internet.  Deploying a
     new authentication infrastructure often involves modifying
     operating system services or keeping parallel authentication
     databases up to date and is thus unacceptable to many
     administrators.

Solutions which encrypt the entire session are often crippled with
     weak keys (due to government restrictions) which are unsuitable for
     passwords.  In addition, such solutions often reduce performance of
     the entire session to an unacceptable level.  This specification
     defines a SASL [SASL] mechanism which is compatible with existing
     password-based authentication databases and does not require a
     security layer for the remainder of the session.

[NOTE: Public discussion of this mechanism may take place on the

Newman                                                          [Page 1]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

ietf-sasl@imc.org mailing list with a subscription address of
     ietf-sasl-request@imc.org.  Private comments may be sent to the
     author].

1. How to Read This Document

This document is intended primarily for a programmer.  If
     successful, it should be possible for a competent programmer to
     write a client implementation using this specification, the SASL
     [SASL] specification, an understanding of how to generate random
     numbers [RANDOM], a description or implementation of the DES and
     SHA1 [SHA1] algorithms and a multi-precision integer math library.
     A cryptographic library or a copy of "Applied Cryptography"
     [SCHNEIER] or similar reference is helpful for any implementation
     and necessary for server DSS key generation.

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
     in this document are to be interpreted as defined in "Key words for
     use in RFCs to Indicate Requirement Levels" [KEYWORDS].

1.1. Data Types Used in this Document

A list of data types used in this document follows.  Note that the
     majority of this section is copied from the secure shell
     specification [SSH-ARCH].

octet   A basic 8-bit unit of data.

uint32  A 32-bit unsigned integer.  Stored as four octets in
             network byte order (also known as big endian or most
             significant byte [MSB] first).  For example, the decimal
             value 699921578 (hexadecimal 29b7f4aa) is represented with
             the hexadecimal octet sequence 29 b7 f4 aa.

string  A string is a length-prefixed octet string.  The length is
             represented as a uint32 with the data immediately
             following.  A length of 0 indicates an empty string.  The
             string MAY contain NUL or 8-bit octets.  When used to
             represent textual strings, the characters are interpreted
             in UTF-8 [UTF-8].  Other character encoding schemes MUST
             NOT be used.

mpint   Represents multiple precision integers in two's complement
             format, stored as a string, most significant octet first.
             Negative numbers have one in the most significant bit of
             the first octet of the string data. If the most significant
             bit would be set for a positive number, the number MUST be
             preceded by a zero byte.  Unnecessary leading zero or 255

Newman                                                          [Page 2]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

bytes MUST NOT be included.  The value zero MUST be stored
             as a string with zero bytes of data.

By convention, a number that is used in modular
             computations in the field of integers mod n SHOULD be
             represented in the range 0 <= x < n.

Examples:

value (hex)        representation (hex)
              -----------------------------------------------------------
              0                  00 00 00 00
              9a378f9b2e332a7    00 00 00 08 09 a3 78 f9 b2 e3 32 a7
              80                 00 00 00 02 00 80
              -1234              00 00 00 02 ed cc
              -deadbeef          00 00 00 05 ff 21 52 41 11

1.2. Glossary

This section includes some acronyms used in this document.

DES  The U.S. Government Data Encryption Standard is a symmetric
          encryption algorithm introduced in 1975 which uses a 56 bit
          key.  The algorithm is documented in [SCHNEIER].

DSA  The U.S. Government Digital Signature Algorithm standard.  A
          public key signature algorithm available for unrestricted use
          without a license.

DSS  The U.S. Government Digital Signature Standard [DSS] which
          employs the DSA algorithm.

HMAC A hash-based message authentication code [HMAC] summarized in
          Appendix A.4.  Test cases are available in [HMAC-TEST].

SHA  The Secure Hash Algorithm (version 1) which is part of the DSS
          standard.

triple-DES
          Use of the DES algorithm three times in an encrypt-decrypt-
          encrypt mode with three independent keys as described in
          appendix A.3.

2. Overview

This section includes a brief discussion of design goals, intended
     use and an overview for this SASL mechanism.  An overview of some
     of the algorithms used is in Appendix A.

Newman                                                          [Page 3]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

2.1. Design Goals

The ideal authentication mechanism would be simple, fast, fully
     secure, freely distributable without restrictions and backwards
     compatible with deployed back-end authentication databases.
     Unfortunately, it is not possible to achieve all these goals so
     priorities and tradeoffs are necessary.  This mechanism has
     compatibility with deployed back-end authentication databases and
     protection from passive and active attacks on the underlying
     connection as primary design goals.  Simplicity and unrestricted
     binary distribution are secondary design goals.

Backwards compatibility is achieved by using plain-text
     passphrases.  Protection from passive and active attacks is
     achieved by using public and symmetric key technology to encrypt
     the passphrase and optionally protect the remainder of the session.
     Some simplicity is achieved by avoiding complicated public key
     certification issues and formats as well as making the SASL session
     security layer and certification by the client optional.
     Unrestricted binary distribution is hopefully achieved by using
     unencumbered algorithms and making the SASL privacy layer optional.

2.2. Intended Use

This is intended as a plug-and-play mechanism for services layered
     on top of deployed passphrase-based back-end authentication
     databases.  When no security layer is implemented it can be added
     to a SASL-based protocol without modifying or substituting network
     read and write APIs.  When the optional session privacy protection
     is omitted, the author speculates that it may be possible to make a
     binary implementation which would be exportable from the United
     States.

For cases where simplicity, speed or unrestricted source code
     distribution is more desirable than backwards compatibility or
     security, a mechanism such as CRAM-MD5 [CRAM-MD5] or SCRAM [SCRAM]
     is preferred.

The optional SASL integrity and privacy protection is provided as a
     simple alternative to full service security layers such as TLS
     [TLS] or Secure Shell [SSH-ARCH].  However, there are many
     advantages to full service security layers such as compression,
     faster symmetric cipher options, and the ability to leverage other
     public key infrastructures.  An implementation which supports TLS
     may have no incentive to support SASL security layers at all.  The
     complexity verses functionality tradeoff is significant enough that
     these mechanisms do not compete.

Newman                                                          [Page 4]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

2.3. Mechanism Overview

The PASSDSS-3DES-1 mechanism uses three components to perform a
     secure authentication against a legacy passphrase database.

In order to protect against active attacks, a DSS public key in a
     format compatible with Secure Shell [SSH-TRANS] is used 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
     in a secure database.  If the client is willing to risk exposure to
     active attacks, it may skip the public key certification step
     altogether or do a one-time initialization of its local database,
     perhaps with user interaction.

In addition to the DSS public key, a Diffie-Hellman key exchange is
     used to generate a key for encrypting the passphrase.  The
     "PASSDSS-3DES-1" variant of this mechanism uses the same fixed
     Diffie-Hellman group used by Secure Shell's diffie-hellman-group1-
     sha1 key exchange [SSH-TRANS].  If more groups are necessary, they
     will be assigned to mechanism variants "PASSDSS-3DES-2" and so
     forth.

Finally, the triple-DES algorithm is used to encrypt the client's
     passphrase and send it to the server.

2.4. Message Format Overview

This section provides a quick overview of the format of the
     messages.  The formal definition of the syntax for these messages
     is in section 6.  A detailed discussion of their implementation on
     clients and servers is in sections 3 and 4 respectively.

First message from client to server:
       string azname       ; the user name to login as, may be empty if
                             same as authentication name
       string authname     ; the authentication name
       mpint  X            ; Diffie-Hellman parameter X

The challenge from server to client is as follows:
       uint32   pklength   ; length of SSH-style DSA server public key
         string "ssh-dss"  ; constant string "ssh-dss" (lower case)
         mpint  p          ; DSA public key parameters
         mpint  q
         mpint  g
         mpint  y
       mpint    Y          ; Diffie-Hellman parameter Y
       OCTET    ssecmask   ; SASL security layers offered
       3 OCTET  sbuflen    ; maximum server security layer block size

Newman                                                          [Page 5]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

uint32   siglength  ; length of SSH-style dss signature
         string "ssh-dss"  ; constant string "ssh-dss" (lower case)
         mpint  r          ; DSA signature parameters
         mpint  s

The client then sends the following message encrypted with
     triple-DES:
       OCTET    csecmask   ; SASL security layer selection
       3 OCTET  cbuflen    ; maximum client block size
       string   passphrase ; the user's passphrase
       20 OCTET cli-hmac   ; a client HMAC-SHA-1 signature

3. Client Implementation of PASSDSS-3DES-1

This section includes a step-by-step guide for client implementors.
     Although section 6 contains the formal definition of the syntax and
     is the authoritative reference in case of errors here, this section
     should be sufficient to build a correct implementation.

The SASL mechanism name is "PASSDSS-3DES-1".

The value of n used for the Diffie-Hellman exchange is as follows
     (represented as an unsigned hexadecimal integer):

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
           29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
           EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
           E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
           EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
           FFFFFFFF FFFFFFFF.

When represented as an "mpint", this would have a prefix of
     "0000008100."  The value of g is 2.  This group was taken from the
     ISAKMP/Oakley specification, and was originally generated by
     Richard Schroeppel at the University of Arizona.  Properties of
     this prime are described in [Orm96].

The client begins by doing the following:

(A) Generate the Diffie-Hellman private value "x".  This should be
     less than (n - 1)/2.  The number of bits of entropy to use in "x"
     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].

Newman                                                          [Page 6]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

(B) Compute the Diffie-Hellman public value "X" as follows.  If X
     has a value of 0, repeat step (A).
                x
           X = 2  mod n

The client then sends the following three pieces of information to
     the server:

(1) An authorization identity represented as a string.  When the
     empty string is used, this defaults to the authentication identity.
     This is used by system administrators or proxy servers to login
     with a different user identity.

(2) An authentication identity represented as a string.  This is
     the identity whose passphrase will be used.

(3) The "X" result from step (B) represented as an mpint.

The server responds by sending a message containing the following
     information:

(4) An "ssh-dss" public key compatible with Secure Shell, including
     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
     A.1).

(5) The mpint "Y" as defined for the Diffie-Hellman key exchange
     (see Appendix A.2).

(6) A single octet bit mask representing the security layers
     available in the same format used by the KERBEROS_V4 mechanism
     [SASL].  Bit 0 (value 1) indicates it is permissible to have no
     security layer.  Bit 1 (value 2) indicates integrity protection is
     permissible.  Bit 2 (value 4) indicates privacy protection for the
     rest of the session is available.  The remaining bits are reserved
     for future use.

(7) A three octet unsigned integer in network byte order
     representing the maximum cipher-text buffer size the server is able
     to receive.  If this is less than 32, it indicates that a SASL
     security layer is not supported.

(8) A DSA signature, including a 32-bit length, the Secure Shell
     string "ssh-dss" and mpints for "r" and "s".

The client then does the following:

Newman                                                          [Page 7]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

outside this range, the client MUST cancel the authentication.

(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
     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
     key database, it MAY skip this step although it SHOULD alert the
     user that the connection is susceptible to active attacks if it
     does so.  It MAY also record the public key (or SHA1 hash thereof)
     in its database with permission from the user.

(E) Compute the Diffie-Hellman key K as follows.  It may be
     necessary to mask timing attacks [TIMING].
                x
           K = Y  mod n

(F) Create a buffer containing data from steps (1) through (7) in
     order immediately followed by K represented as an mpint.

(G) Compute the SHA1 hash of the buffer from (F).  This produces a
     20 octet result.

(H) If the public key from step (4) was not certified, this step
     MAY be skipped.  Otherwise, verify that the DSS signature is a
     signature of (G).  This computation is done as defined in appendix
     A.1 where the output of step (G) represents the message "m" (note
     that this results in SHA1 being applied twice).

(I) Compute the following 20-octet values.  K represents the output
     of step (E) in mpint format.  H represents the output of step (G).
     The || symbol represents string concatenation.  "A" represents a
     single octet containing the US-ASCII value of capital letter A.
         cs-encryption-iv    = SHA1( K || "A" || H )
         sc-encryption-iv    = SHA1( K || "B" || H )
         cs-encryption-key-1 = SHA1( K || "C" || H )
         cs-encryption-key-2 = SHA1( K || cs-encryption-key-1 )
         cs-encryption-key   = cs-encryption-key-1 || cs-encryption-key-2
         sc-encryption-key-1 = SHA1( K || "D" || H )
         sc-encryption-key-2 = SHA1( K || sc-encryption-key-1 )
         sc-encryption-key   = sc-encryption-key-1 || sc-encryption-key-2
         cs-integrity-key    = SHA1( K || "E" || H )
         sc-integrity-key    = SHA1( K || "F" || H )

(J) Create a buffer beginning with a bit mask for the selected
     security layer (it MUST be one offered in 6) followed by three
     octets representing the maximum cipher-text buffer size (at least
     32) the client can accept in network byte order.  This is followed
     by a string containing the passphrase.  Note that integrity

Newman                                                          [Page 8]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

protection is pointless unless the public key was certified in
     step (D) and the signature was verified in step (H).

(K) Create a buffer containing items (1) through (7) immediately
     followed by the first four octets of (J).

(L) Compute HMAC-SHA-1 with (K) as the data and the cs-integrity-
     key from step (I) as the key.  This produces a 20 octet result.  A
     summary of the HMAC-SHA-1 algorithm [HMAC] is in appendix A.4.

(M) Create a buffer containing (J) followed by (L) followed by an
     arbitrary number of zero octets as necessary to reach the block
     size of DES and conceal the passphrase length from an eavesdropper.

(N) Apply the triple-DES algorithm to (M) with the first 8 octets
     of cs-encryption-iv from step (I) as the initialization vector and
     the first 24 octets of cs-encryption-key as the key.  If optional
     privacy protection is negotiated on, the triple-DES state is not
     reset.

The client then sends a message to the server containing the
     following:

(9) The output of step (N).

If a SASL security layer is negotiated on, the following steps are
     used when sending a message:

(O) Create a buffer containing a uint32 client packet number
     (starting from 0) immediately followed by the cs-integrity-key from
     step (I).

(P) Compute HMAC-SHA-1 with (O) as the key and the data to transmit
     as the data.

(Q) Create a buffer containing the data to transmit followed by the
     20-octet output of (P).  If privacy was negotiated on, this is
     followed by zero to seven padding octets followed by one more octet
     indicating the number of padding octets.  The total size MUST be a
     multiple of the DES block size.

(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
     by SASL.

If a SASL security layer was negotiated on, the following steps are
     taken when receiving a message:

Newman                                                          [Page 9]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

(S) If privacy was negotiated on, the message is decrypted using
     triple-DES with the first 24 octets of sc-encryption-key as the
     key.  The value of the last octet plus one indicates the number of
     octets to ignore at the end of the output.  The sc-encryption-iv is
     used to initialize triple-DES state the first time this is done.

(T) Create a buffer containing a uint32 server packet number
     (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
     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
     corrupted.

4. Server Implementation of PASSDSS-3DES-1

The section includes a step-by-step guide for server implementors.
     It is intended to be read in conjunction with section 3.

The server MUST have a persistent DSS-SSH public key.  Mechanisms
     for generating such keys are described in [SCHNEIER] and [DSS].

IMPORTANT NOTE: The server MUST be able to process any message from
     the client, including messages of any size, messages with invalid
     content and messages with NULs in the middle of strings.  When
     input is illegal, the server MUST gracefully reject authentication
     or in extreme cases gracefully terminate the connection.
     Particular care to avoid buffer overruns is important if the user
     name or passphrase strings are copied.

The server performs the following computations prior to or during
     the connection by the client:

(a) Select a random number k less than (p - 1)/2.  It is important
     to generate a good random number [RANDOM].

(b) Compute signature component "r" as follows:
                 k
           r = (g  mod p) mod q

(d) Select a random Diffie-Hellman private key y less than (n -
     1)/2.  Follow the same guidance as in (A) above.

Newman                                                         [Page 10]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

(e) Compute the Diffie-Hellman public value Y as follows.  If Y has
     a value of 0, repeat step (d) above.
                y
           Y = 2  mod n

(f) Verify that the value X from the client is between 1 and (n -
     1).  If it isn't, fail the authentication.

(g) Compute the Diffie-Hellman shared key K as follows.  It may be
     necessary to mask timing attacks [TIMING].
                y
           K = X  mod n

(h) Create a buffer containing items (1) through (7) above followed
     by K represented as an mpint.

(i) Compute the SHA-1 hash of the buffer from (h).  This produces a
     20 octet result.

(j) Generate a DSS signature of (i).  The signature is made up of
     "r" from step (b) and the result following computation (partially
     completed in step c):
                 -1
           s = (k  (SHA1(h) + xr)) mod q

(k) Create a buffer containing items (4) through (8) and send it to
     the client.

(l) Perform the computations as described in step (I) where K is
     the result of step (g) in mpint format and H is the result of step
     (i).

(m) Decrypt message (9) from the client using triple-DES with cs-
     encryption-iv as the initialization vector and the first 24 octets
     of cs-encryption-key as the key.

(n) Verify the passphrase from the output of step (m) against the
     authentication database.  Fail the authentication if verification
     fails.

(o) Verify that the selected security layer is permitted and the
     cipher text buffer size is at least 32.  If not, fail the
     authentication.

(p) Create a buffer containing steps (1) through (7) followed by
     the first four octets of the result from (m).

(q) Compute the HMAC-SHA-1 of (p) with cs-integrity-key as the key.

Newman                                                         [Page 11]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

This produces a 20-octet result.

(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
     authentication.

If a SASL security layer is negotiated on, sending and receiving
     procedures are similar to steps (O)-(U), with client and server
     roles exchanged (and thus sc-* values and cs-* value exchanged).
     Note that triple-DES state from step (m) is not reset.

5. Example

The following is an example of the PASSDSS-3DES-1 mechanism using
     the IMAP [IMAP4] profile of SASL.  Note that base64 encoding and
     the lack of an initial client response with the first command are
     characteristics of the IMAP profile of SASL and not characteristics
     of SASL or this mechanism.

In this example, "C:" represents lines sent from the client to the
     server and "S:" represents lines sent from the server to the
     client.  The wrapped lines are for editorial clarity -- there are
     no actual newlines in the middle of the messages.

C: a001 AUTHENTICATE PASSDSS-3DES-1
       S: +
       C: AAAAAAAAAAVjaHJpcwAAAIEAhuVbMxdLxrAQVyUWbAp+X09h6QmZ2Jebz
          H7YhtcbQyLbB9AGi1eIdojZYtAuVeE+PYkKUANLHI9XzWSFliIGMeUvBc
          bflHr+s9tZ5/5YZh9blb33km3tUYVKyB5XP530bDn+lY1lAv6tXHKZPrx
          b0zPhc+JGgpWGlmT5k9vx2Wk=
       S: + AAAA8gAAAAdzc2gtZHNzAAAAQQDPVlO6nFefrq6fA/dQKIoNj75Jjpp
          kVv3DkyILABCox2dMql0bnO48rHFuo167y6oukT/ocKupIw6bgKmdofgd
          AAAAFQDRpB6FrxemUGRuLjY/oiH/Qef14QAAAEEAkVr9rOlB58k5XoqmP
          NYTrVGZKWbCPcYtaL92ANxgWyjyRo49+m0+fHPNhNibQoLddEZF8lHPKW
          gb7z7qz0QMdgAAAEARcIEiMz5jTZo8COf2njL3BTWRND5NGAgZY7s1YOm
          2BfjVyf1/MkOiQMiXeonrsfMc0sWQGgpRYRtJWpe56cc2AAAAgQDoV5Uk
          bcy3Gjf16MZwPLlJlvmjpSNv2dSSApoddd4+BgZr01zyt7hzb0yRruaN5
          fG43DbJLkk7mtL1Hw8aYXBMQQzrPpHtx+anpCDoN2jlersCGFY2cnjxTf
          HqY139ohA8vVXYpapeXxKXR4//Ib/ApTGmwlOeIikKDrBmEGX/JgEAAAA
          AAAA8AAAAB3NzaC1kc3MAAAAVAI7j3HG8HyjCOxaGFOUTwZqe0xSHAAAA
          FHSqU41vPHTCRTqmxNFwXqazPlJH
       C: Obp6vQ83q1O/OnQDifZB1rWOci9LaSck8VxNB4UAFhRI56BAs4XPLqOWI
          CoB3LYZ
       S: a001 OK Authentication Completed

The following private values were used in this example.  These
     values are all represented as an mpint in hexadecimal (msb first).

Newman                                                         [Page 12]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

The client private Diffie-Hellman "x" value:

00000018 666E35B4 3BF4BF2B 40E31359 7A5D3AD0 61FD4F6F 736A6114

The server private Diffie-Hellman "y" value:

00000018 587BDFD6 800D101C 8E82E233 3B5A07AA DB87B8F1 68DC194D

The Diffie-Hellman shared secret:

00000080 3B46D3A8 D2163930 1C33D9FE EAFA528D F4B881CF DF906A03
       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

The DSA private key value (the public key is in the exchange):

00000014 252BCBFA 5634D706 6ED43128 972E181E 66BF9C30

The SHA-1 hash value used to compute the keys:

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
     messages.  This uses ABNF [ABNF] notation including the core rules.
     The first three rules define the formal exchange.  The later rules
     define the elements of the exchange.

client-msg-1     = [azname] authname diffie-hellman-X

server-msg-1     = dss-public-key diffie-hellman-Y
                        ssecmask sbuflen dss-signature

client-msg-2     = client-blob

authname         = string
                        ;; interpreted as UTF-8 [UTF-8]

azname           = string
                        ;; interpreted as UTF-8 [UTF-8]

cbuflen          = 3OCTET
                        ;; Big endian binary unsigned integer
                        ;; max length of client read buffer

Newman                                                         [Page 13]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

cli-hmac         = 20OCTET

client-blob      = 8*OCTET
                        ;; encrypted version of client-encrypted

client-encrypted = csecmask cbuflen passphrase cli-hmac *NUL
                        ;; MUST be multiple of DES block size

csecmask         = OCTET
                        ;; client selected protection layer

diffie-hellman-X = mpint

diffie-hellman-Y = mpint

dss-g            = mpint

dss-p            = mpint

dss-public-key   = length NUL NUL NUL %x07 "ssh-dss"
                        dss-p dss-q dss-g dss-y
                        ;; length is total length of remainder
                        ;; as defined in [SSH-TRANS]

dss-q            = mpint

dss-r            = mpint

dss-signature    = length NUL NUL NUL %x07 "ssh-dss"
                        dss-r dss-s
                        ;; length is total length of remainder

dss-s            = mpint

dss-y            = mpint

length           = 4OCTET
                        ;; binary number, big endian format (MSB first)

mpint            = length *OCTET
                        ;; length specifies number of octets
                        ;; see section 1 for detailed mpint definition

passphrase       = string
                        ;; At least 64 octets MUST be supported

Newman                                                         [Page 14]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

sbuflen          = 3OCTET
                        ;; Big endian binary unsigned integer
                        ;; max length of server read buffer

ssecmask         = OCTET
                        ;; server protection layer mask

string           = length *OCTET
                        ;; the length determines the number of octets
                        ;; OCTETs are interpreted as UTF-8

NUL              = %x00  ;; US-ASCII NUL character

7. Security Considerations

Security considerations are discussed throughout this memo.

This mechanism supplies the server with the plain-text passphrase,
     so the server gains the ability to masquerade as the user to any
     other services which share the same passphrase.

If the public key certification step is skipped, then an active
     attacker can gain the client's passphrase and thus the ability to
     masquerade as the user to any other services which share the same
     passphrase.  Negotiating a security layer will fail to provide
     protection from an active attacker in this case.

If no security layer is negotiated, the rest of the protocol
     session is subject to active and passive attacks.

If an integrity-only layer is negotiated, the rest of the protocol
     is subject to passive eavesdropping.

The quality of this mechanism depends on the quality of the random
     number generator used.  See [RANDOM] for more information.

8. Multinational Considerations

As remote access is a crucial service, users are encouraged to
     restrict user names and passphrases to the US-ASCII character set.
     However, if characters outside the US-ASCII character set are used
     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
     sequences not legal for UTF-8.  Servers are encouraged to enforce
     this restriction to discourage clients from using non-interoperable
     local character sets in this context.

Newman                                                         [Page 15]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

9. Intellectual Property Issues and Acknowledgments

David Kravitz holds U.S. Patent #5,231,668 on the DSA algorithm.
     NIST has made this patent available world-wide on a royalty-free
     basis.

Diffie-Hellman was first published in 1976 [DIFFIE-HELLMAN].  U.S.
     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
     time.

DES is covered under U.S. Patent #3,962,539 granted June 1978,
     which has expired.

The majority of the constructions in this specification were copied
     from the Secure Shell specifications [SSH-ARCH, SSH-TRANS].
     Additional information is paraphrased from "Applied Cryptography"
     [SCHNEIER].

10. References

[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
     ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
     November 1997.

[CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
     for Simple Challenge/Response", RFC 2195, MCI, September 1997.

[DIFFIE-HELLMAN] Diffie, W., Hellman, M.E., "Privacy and
     Authentication: An introduction to Cryptography," Proceedings of
     the IEEE, v. 67, n. 3, March 1979, pp. 397-427.

[DSS] National Institute of Standards and Technology, "Digital
     Signature Standard," NIST FIPS PUB 186, U.S. Department of
     Commerce, May 1994.

[HMAC] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message
     Authentication", RFC 2104, IBM, UCSD, February 1997.

[HMAC-TEST] Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
     RFC 2202, IBM, NIST, September 1997.

[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
     4rev1", RFC 2060, University of Washington, December 1996.

[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
     Requirement Levels", RFC 2119, Harvard University, March 1997.

Newman                                                         [Page 16]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

[Orm96] Orman, H., "The Oakley Key Determination Protocol", version
     1, TR97-92, Department of Computer Science Technical Report,
     University of Arizona.

[RANDOM] Eastlake, Crocker, Schiller, "Randomness Recommendations
     for Security", RFC 1750, DEC, Cybercash, MIT, December 1994.

[SASL] Myers, "Simple Authentication and Security Layer (SASL)",
     RFC 2222, Netscape Communications, October 1997.

[SCHNEIER] Schneier, B., "Applied Cryptography: Protocols,
     Algorithms and Source Code in C," John Wiley and Sons, Inc., 1996.

[SCRAM] Newman, "Salted Challenge Response Authentication Mechanism
     (SCRAM)", work in progress, January 1998.

[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",
     Work in progress, SSH, October 1997.

[SSH-TRANS] Ylonen, Kivinen, Saarinen, "SSH Transport Layer
     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
     progress.

[UTF8] Yergeau, "UTF-8, a transformation format of ISO 10646",
     RFC 2279, Alis Technologies, January 1998.

Newman                                                         [Page 17]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

11. Author's Address

Chris Newman
     Innosoft International, Inc.
     1050 Lakes Drive
     West Covina, CA 91790 USA

Email: chris.newman@innosoft.com

Appendix A. Algorithm Overview

This section provides a quick overview of the algorithms used.  For
     a full understanding, the reader is encouraged to read "Applied
     Cryptography" [SCHNEIER].  The follow descriptions are paraphrased
     from that source.

Note that an overview of the DES algorithm is not included as
     publicly available implementations and descriptions are very
     common.

Appendix A.1. DSA Algorithm

The DSA algorithm is a public key algorithm which can be used to
     sign messages such that the source can be verified using a public
     key.  The algorithm has the following parameters:

p is a prime number L bits long.  Implementations MUST support L
     between 512 and 1024 bits.

q is a 160-bit prime factor of (p - 1).

(p - 1)/q
     g = h          mod p  where h is any number less than p - 1 such

(p - 1)/q
        that h           is greater than 1.

x is a number less than q and represents the private key.

x
     y = g  mod p  and represents the public key.

To sign a message m, the client generates a random number k less
     than q and computes:

k
        r = (g  mod p) mod q

Newman                                                         [Page 18]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

-1
        s = (k  (SHA1(m) + xr)) mod q

The signature is represented as r and s, and is verified as
     follows:

-1
        w  = s   mod q

u1 = (SHA1(m) * w) mod q

u2 = (rw) mod q

u1    u2
        v  = ((g   * y  ) mod p) mod q

If v = r then the signature is verified.

Appendix A.2. Diffie-Hellman Algorithm

The Diffie-Hellman algorithm is a key-exchange algorithm.  It
     allows two ends of a communications channel to establish a shared
     secret which a passive eavesdropper can not easily determine.  This
     key can then be used in a symmetric algorithm such as triple-DES.
     The two ends have a prior agreement on two numbers:

n a large prime number

g a primitive mod n.

The client chooses a random large integer x and computes:

x
       X = g  mod n

and sends X to the server.  The server chooses a random large
     integer y and computes:

y
      Y = g  mod n

y
      K = X  mod n

The server sends Y to the client.  The client computes:

x
      K = Y  mod n

Newman                                                         [Page 19]

Internet Draft       PASSDSS-3DES-1 SASL Mechanism            March 1998

At this point, the client and server share the same secret K.

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
     significant.  The triple-DES EDE algorithm uses a 24 octet (192
     bit) key of which roughly 112 bits are significant see [SCHNEIER]
     for more details.  The "EDE" refers to encrypt-decrypt-encrypt, and
     the "CBC" refers to cipher-block-chaining where each cipher block
     affects future cipher blocks.  If E() is the DES encryption
     function, D() is the DES decryption function, C is a cipher text
     block and P is a plain-text block, then triple-DES EDE in CBC mode
     with outer chaining is:

C  = E  (D  (E  (P  XOR C   )))
         i    K3  K2  K1  i      i-1

NOTE: C  is the initialization vector
            0

and the decryption function is:

P  = C    XOR D  (E  (D  (C )))
         i    i-1      K3  K2  K1  i

K1 is the first 8 octets of the triple-DES key, K2 is the second 8
     octets and K3 is the final 8 octets.

Appendix A.4. HMAC-SHA-1 Keyed hash function

HMAC-SHA-1 uses the SHA-1 hash function to create a keyed hash
     function suitable for use as an integrity protection function.  A
     more complete description is in [HMAC].  A brief summary of the
     algorithm follows:

(A) If the key is longer than 64 octets, it is run through the
     SHA-1 function to produce a 20 octet key.

(B) The key is exclusive-ored with a 64 octet buffer filled with
     the octet value 0x36.

(D) The key is exclusive-ored with a 64 octet buffer filled with
     the octet value 0x5C.

(E) SHA-1 is computed over (D) followed by the output of (C).

Newman                                                         [Page 20]

${this.title}

Code Editor : draft-newman-sasl-passdss-xx.txt