[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
Network Working Group                                          C. Newman
Internet Draft: PASS-DSS-SHA-3DES-1 SASL Mechanism              Innosoft
Document: draft-newman-sasl-passdss-00.txt                  January 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     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 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 multiprecision 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 (hexidecimal 29b7f4aa) is represented with
             the hexidecimal 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 signficant 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     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 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     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 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 achived by using plaintext 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 ession.  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 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 could 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     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 1998


2.3. Mechanism Overview

     The PASS-DSS-SHA-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 "PASS-
     DSS-SHA-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 "PASS-DSS-SHA-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     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 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 PASS-DSS-SHA-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 "PASS-DSS-SHA-3DES-1".

     The value of n used for the Diffie-Hellman exchange is as follows
     (represented as an unsigned hexidecimal 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 can be
     generated as a random integer between (n - 1)/4 and (n - 1)/2. It
     is important to generate a good random number [RANDOM].

     (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




Newman                                                          [Page 6]


Internet Draft     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 1998


     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 bitmask 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:

     (C) Verify that "Y" is between 1 and n - 1 inclusive.  If "Y" is
     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



Newman                                                          [Page 7]


Internet Draft     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 1998


     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:
                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 bitmask 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
     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).




Newman                                                          [Page 8]


Internet Draft     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 1998


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

     (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:

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




Newman                                                          [Page 9]


Internet Draft     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 1998


     (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 PASS-DSS-SHA-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 persistant 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 from (p - 1)/4 to (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

     (c) Optionally pre-compute the group inverse of k, mod q and the
     value xr.

     (d) Select a random number y from (n - 1)/4 to (n - 1)/2.  It is
     important to generate a good random number [RANDOM].

     (e) Compute the Diffie-Hellman public value Y as follows:
                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:



Newman                                                         [Page 10]


Internet Draft     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 1998


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



Newman                                                         [Page 11]


Internet Draft     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 1998


5. Example

     The following is an example of the PASS-DSS-SHA-3DES-1 mechanism
     using the IMAP [IMAP4] profile of SASL.  Note that base64 encoding
     and the lack of an initial client reponse 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 PASS-DSS-SHA-3DES-1
       S: +
       C: AAAAAAAAAAVjaHJpcwAAAIByNdmAm3TWjyEeKfuyLoGUaojr5moPVU6p92/r
          5QDUAgO9A81wvQH5RbljV7DBONObjlkjfDGbQp3MsmUbtOiNDZrNczUMlCvd
          oNsWtQQtU48WrTIL+UP6EQn2Xblw2TgPCFmSHS66p/VILI5BsQsrx31BHnnn
          YVwKz6S7KkYyDA==
       S: AAAA8gAAAAdzc2gtZHNzAAAAQQDPVlO6nFefrq6fA/dQKIoNj75JjppkVv3D
          kyILABCox2dMql0bnO48rHFuo167y6oukT/ocKupIw6bgKmdofgdAAAAFQDR
          pB6FrxemUGRuLjY/oiH/Qef14QAAAEEAkVr9rOlB58k5XoqmPNYTrVGZKWbC
          PcYtaL92ANxgWyjyRo49+m0+fHPNhNibQoLddEZF8lHPKWgb7z7qz0QMdgAA
          AEARcIEiMz5jTZo8COf2njL3BTWRND5NGAgZY7s1YOm2BfjVyf1/MkOiQMiX
          eonrsfMc0sWQGgpRYRtJWpe56cc2AAAAgQDa/kF4dHlBpgYew6u/10sFJP8G
          QgSE4YdFUl2yJKW4S9azMmqSVsoiAHzeslZogV25yQE3vdsIjtqjVwhcCwu2
          nb0kt/Rfu5gOTCygUWsRD0yuiKeOpbiakCLQe1jtjIS2tgLRKQ66Z+q7HI9R
          YUqqxFUu53L/iGNf1cbVokepOgEAAAAAAAA7AAAAB3NzaC1kc3MAAAAUMkWf
          YSZlk0bJI4BKiA8Ju6Yh0DAAAAAUScKvxfqPCm2cdnNyzD7sgmUxC1E=
       C: XTs/rtmZ6uYpK8A90hRN5NrdoEAXrzWISOb080+EOFEDd6Gg2Ci720Pw8kRe
          VY6I
       S: a001 OK Authentication Completed

     In this example, the client private "x" value, represented as an
     mpint in hexidecimal is:

       00000080 4bb82066 70638c78 059368d3 8430006c 02e8a05b 708cb774
       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
     is:

       00000080 4340eba3 631a0fe9 224bdd5c 8d660535 6c290c1d 446e8122
       768c6298 2cfa2d6c 057ab971 80cd57d1 c51ff528 0884cbf8 057ab971
       80cd57d1 c51ff528 0884cbf8 057ab971 80cd57d1 c51ff528 0884cbf8



Newman                                                         [Page 12]


Internet Draft     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 1998


       057ab971 80cd57d1 c51ff528 0884cbf8 057ab971 80cd57d1 c51ff528
       0884cbf8 057ab971 80cd57d1 c51ff528 0884cbf8

     The Diffie-Hellman shared secret represented as an mpint in
     hexidecimal is:

       00000080 7a81b3c2 702168d8 cce24ccc ae0b938e 84cf27c9 2b192c20
       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
     is:

       00000040 11708122 333e634d 9a3c08e7 f69e32f7 05359134 3e4d1808
       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:

       a5567b02 0f5abe1a b8aa9040 08404432 71744e6a

6. Formal Syntax of PASS-DSS-SHA-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     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 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     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 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 plaintext 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 chracter 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 encourged to enforce
     this restriction to discourage clients which use unlabelled
     character sets in this context.

9. Intellectual Property Issues and Acknowledgements



Newman                                                         [Page 15]


Internet Draft     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 1998


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

     Diffie-Hellman was the first public-key algorithm ever invented.
     It 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     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 1998


     [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
     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, October 1997.

     [SHA1] See [DSS].

     [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.

     [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in
     progress.

     [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and
     ISO 10646", RFC 2044, Alis Technologies, October 1996.


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



Newman                                                         [Page 17]


Internet Draft     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 1998


     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

              -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




Newman                                                         [Page 18]


Internet Draft     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 1998


        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 primiative 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

     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



Newman                                                         [Page 19]


Internet Draft     PASS-DSS-SHA-3DES-1 SASL Mechanism       January 1998


     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 plaintext 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.

     (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
     the octet value 0x5C.

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











Newman                                                         [Page 20]