Subject: Internet draft

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 22 Oct 1999 08:25:52 -0700

Please publish the attached as an Internet-draft titled
"draft-leach-digest-sasl-05.txt". Please CC the LDAP extensions working
group ([email-masked]) on the announcement of its publication.

Thanks,

Paul
 <<draft-leach-digest-sasl-05.txt>>

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Tue, 26 Oct 1999 17:53:47 -0700

> -----Original Message-----
> From: Lawrence Greenfield [mailto:[email-masked]]
> Sent: Friday, October 22, 1999 9:45 AM
> To: Paul Leach (Exchange)
> Cc: [email-masked]'
> Subject: Re: Internet draft
> 
> 
> Can you post a quick summary of what changed in this draft versus the
> last one?
> 
> Thanks,
> Larry

1. Clarified that double quote characters are allowed in nonces if escaped,
as the nonce is just a quoted string, and escaping works in quoted strings.

2. Clarified that the "stale" directive can appear at most once.

3. Clarified that "digest-uri-value" needs to be quoted (because it contains
"/" which is a special character that needs to be quoted)

4. Clarified that "response-value" does not need to be quoted (as with other
hex values)

5. Clarified that "authzid-value" needs to be quoted (may contain special
characters that need to be quoted)

6. Clarified that the "nonce-count" directive can appear at most once.

7. Clarified that the "digest-uri" directive can appear at most once.

8. Updated examples (courtesy Chris Newman).

9. Clarified the "implied LWS" description (rules for optional white space)
and its use between double quotes.

10. Added a rule for CRLF -- was used but not defined.

Paul

From: "Paul Leach (Exchange)" <[email-masked]>
To: "'Lawrence Greenfield'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Internet draft
Date: Tue, 26 Oct 1999 17:53:47 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Lawrence Greenfield [mailto:[email-masked]]
> Sent: Friday, October 22, 1999 9:45 AM
> To: Paul Leach (Exchange)
> Cc: [email-masked]'
> Subject: Re: Internet draft
> 
> 
> Can you post a quick summary of what changed in this draft versus the
> last one?
> 
> Thanks,
> Larry

1. Clarified that double quote characters are allowed in nonces if escaped,
as the nonce is just a quoted string, and escaping works in quoted strings.

2. Clarified that the "stale" directive can appear at most once.

3. Clarified that "digest-uri-value" needs to be quoted (because it contains
"/" which is a special character that needs to be quoted)

4. Clarified that "response-value" does not need to be quoted (as with other
hex values)

5. Clarified that "authzid-value" needs to be quoted (may contain special
characters that need to be quoted)

6. Clarified that the "nonce-count" directive can appear at most once.

7. Clarified that the "digest-uri" directive can appear at most once.

8. Updated examples (courtesy Chris Newman).

9. Clarified the "implied LWS" description (rules for optional white space)
and its use between double quotes.

10. Added a rule for CRLF -- was used but not defined.

Paul

Date: 22 Oct 1999 12:44:32 -0400
From: Lawrence Greenfield <[email-masked]>
To: Paul Leach <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Internet draft
Sender: [email-masked]

Can you post a quick summary of what changed in this draft versus the
last one?

Thanks,
Larry

From: "Paul Leach (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Internet draft
Date: Fri, 22 Oct 1999 08:25:52 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BF1CA1.BA125820
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks,

Paul

------_=_NextPart_000_01BF1CA1.BA125820
Content-Type: text/plain;
	name="draft-leach-digest-sasl-05.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-leach-digest-sasl-05.txt"

                         Digest SASL Mechanism          September, 1999 =

Network Working Group               Paul J. Leach, Microsoft=20
INTERNET-DRAFT                        Chris Newman, Innosoft=20
draft-leach-digest-sasl-05.txt=20
Category: Standards Track=20
Expires April 21, 2000                      October 21, 1999=20
                                    =20

            Using Digest Authentication as a SASL Mechanism=20

                           Author's draft: 16=20

=20

STATUS OF THIS MEMO=20

This document is an Internet-Draft and is in full conformance with all=20
provisions of Section 10 of RFC2026. =20

Internet-Drafts are working documents of the Internet Engineering Task=20
Force (IETF), its areas, and its working groups. Note that other groups =

may also distribute working documents as Internet-Drafts.=20

Internet-Drafts are draft documents valid for a maximum of six months=20
and may be updated, replaced, or obsoleted by other documents at any=20
time. It is inappropriate to use Internet- Drafts as reference material =

or to cite them other than as "work in progress."=20

The list of current Internet-Drafts can be accessed at=20
    http://www.ietf.org/ietf/1id-abstracts.txt =20

The list of Internet-Draft Shadow Directories can be accessed at=20
    http://www.ietf.org/shadow.html. =20

Distribution of this document is unlimited.  Please send comments to =
the=20
authors or the SASL mailing list, [email-masked].=20

Copyright Notice: Copyright (C) The Internet Society (1998). All Rights =

Reserved. See section 8 for the full copyright notice.=20

ABSTRACT=20

This specification defines how HTTP Digest Authentication [Digest] can=20
be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL =

profile. It is intended both as an improvement over CRAM-MD5 [RFC2195]=20
and as a convenient way to support a single authentication mechanism =
for=20
web, mail, LDAP, and other protocols.=20

Leach, Newman         Standards Track              [Page 1] =0C

                         Digest SASL Mechanism          September, 1999 =

Table of Contents=20

1 INTRODUCTION........................................................3 =

 1.1 CONVENTIONS AND =
NOTATION..........................................3=20

 1.2 =
REQUIREMENTS......................................................4=20

2 AUTHENTICATION......................................................4 =

 2.1 INITIAL =
AUTHENTICATION............................................4=20

  2.1.1 Step One......................................................4 =

  2.1.2 Step Two......................................................7 =

  2.1.3 Step Three...................................................12 =

 2.2 SUBSEQUENT =
AUTHENTICATION........................................13=20

  2.2.1 Step one.....................................................13 =

  2.2.2 Step Two.....................................................13 =

 2.3 INTEGRITY =
PROTECTION.............................................14=20

 2.4 CONFIDENTIALITY =
PROTECTION.......................................14=20

3 SECURITY CONSIDERATIONS............................................15 =

 3.1 AUTHENTICATION OF CLIENTS USING DIGEST =
AUTHENTICATION............15=20

 3.2 COMPARISON OF DIGEST WITH PLAINTEXT =
PASSWORDS....................16=20

 3.3 REPLAY =
ATTACKS...................................................16=20

 3.4 ONLINE DICTIONARY =
ATTACKS........................................16=20

 3.5 OFFLINE DICTIONARY =
ATTACKS.......................................16=20

 3.6 MAN IN THE =
MIDDLE................................................17=20

 3.7 CHOSEN PLAINTEXT =
ATTACKS.........................................17=20

 3.8 SPOOFING BY COUNTERFEIT =
SERVERS..................................17=20

 3.9 STORING =
PASSWORDS................................................17=20

 3.10 MULTIPLE REALMS................................................18 =

Leach, Newman         Standards Track              [Page 2] =0C

                         Digest SASL Mechanism          September, 1999 =

 3.11 SUMMARY........................................................18 =

4 EXAMPLE............................................................18 =

5 REFERENCES.........................................................20 =

6 AUTHORS' ADDRESSES.................................................21 =

7 ABNF...............................................................21 =

 7.1 AUGMENTED =
BNF....................................................22=20

 7.2 BASIC =
RULES......................................................23=20

8 SAMPLE CODE........................................................25 =

9 FULL COPYRIGHT STATEMENT...........................................26 =

=20

1  Introduction=20

This specification describes the use of HTTP Digest Access=20
Authentication as a SASL mechanism. The authentication type associated=20
with the Digest SASL mechanism is "DIGEST-MD5".=20

This specification is intended to be upward compatible with the "md5-
sess" algorithm of HTTP/1.1 Digest Access Authentication specified in=20
[Digest]. The only difference in the "md5-sess" algorithm is that some=20
directives not needed in a SASL mechanism have had their values=20
defaulted.=20

There is one new feature for use as a SASL mechanism: integrity=20
protection on application protocol messages after an authentication=20
exchange.=20

Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext=20
attacks, and permits the use of third party authentication servers,=20
mutual authentication, and optimized reauthentication if a client has=20
recently authenticated to a server.=20

1.1   Conventions and Notation=20

This specification uses the same ABNF notation and lexical conventions=20
as HTTP/1.1 specification; see appendix A.=20

Let { a, b, ... } be the concatenation of the octet strings a, b, ...=20

Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s.=20

Leach, Newman         Standards Track              [Page 3] =0C

                         Digest SASL Mechanism          September, 1999 =

Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the string =
k,=20
a colon and the string s.=20

Let HEX(n) be the representation of the 16 octet MD5 hash n as a string =

of 32 hex digits (with alphabetic characters always in lower case, =
since=20
MD5 is case sensitive).=20

Let HMAC(k, s) be the 16 octet HMAC-MD5 [RFC 2104] of the octet string =
s=20
using the octet string k as a key.=20

The value of a quoted string constant as an octet string does not=20
include any terminating null character.=20

1.2   Requirements =20

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20
document are to be interpreted as described in RFC 2119 [RFC 2119]. =20

An implementation is not compliant if it fails to satisfy one or more =
of=20
the MUST level requirements for the protocols it implements. An=20
implementation that satisfies all the MUST level and all the SHOULD=20
level requirements for its protocols is said to be "unconditionally=20
compliant"; one that satisfies all the MUST level requirements but not=20
all the SHOULD level requirements for its protocols is said to be=20
"conditionally compliant."=20

2  Authentication=20

The following sections describe how to use Digest as a SASL=20
authentication mechanism.=20

2.1   Initial Authentication=20

If the client has not recently authenticated to the server, then it =
must=20
perform "initial authentication", as defined in this section. If it has =

recently authenticated, then a more efficient form is available, =
defined=20
in the next section.=20

2.1.1Step One=20

The server starts by sending a challenge. The data encoded in the=20
challenge contains a string formatted according to the rules for a=20
"digest-challenge" defined as follows: =20

digest-challenge  =3D=20
      1#( realm | nonce | qop-options | stale | maxbuf | charset=20
            algorithm | cipher-opts | auth-param )=20
=20

Leach, Newman         Standards Track              [Page 4] =0C

                         Digest SASL Mechanism          September, 1999 =

=20
     realm             =3D "realm" "=3D" <"> realm-value <">=20
     realm-value       =3D qdstr-val=20
     nonce             =3D "nonce" "=3D" <"> nonce-value <">=20
     nonce-value       =3D qdstr-val=20
     qop-options       =3D "qop" "=3D" <"> qop-list <">=20
     qop-list          =3D 1#qop-value=20
     qop-value         =3D "auth" | "auth-int" | "auth-conf" |=20
                          token=20
     stale             =3D "stale" "=3D" "true"=20
     maxbuf            =3D "maxbuf" "=3D" maxbuf-value=20
     maxbuf-value      =3D 1*DIGIT=20
     charset           =3D "charset" "=3D" "utf-8"=20
     algorithm         =3D "algorithm" "=3D" "md5-sess"=20
     cipher-opts       =3D "cipher" "=3D" <"> 1#cipher-value <">=20
     cipher-value      =3D "3des" | "des" | "rc4-40" | "rc4" |=20
                         "rc4-56" | token=20
     auth-param        =3D token "=3D" ( token | quoted-string )=20
=20
The meanings of the values of the directives used above are as follows: =

realm=20
  Mechanistically, a string which can enable users to know which=20
  username and password to use, in case they might have different ones=20
  for different servers. Conceptually, it is the name of a collection=20
  of accounts that might include the user's account. This string should =

  contain at least the name of the host performing the authentication=20
  and might additionally indicate the collection of users who might=20
  have access. An example might be=20
  "[email-masked]".  This directive is=20
  optional; if not present, the client SHOULD solicit it from the user=20
  or be able to compute a default; a plausible default might be the=20
  realm supplied by the user when they logged in to the client system.=20
  Multiple realm directives are allowed, in which case the user or=20
  client must choose one as the realm for which to supply to username=20
  and password.=20

nonce=20
  A server-specified data string which MUST be different each time a=20
  digest-challenge is sent as part of initial authentication.  It is=20
  recommended that this string be base64 or hexadecimal data. Note that =

  since the string is passed as a quoted string, the double-quote=20
  character is not allowed unless escaped (see section 7.2). The=20
  contents of the nonce are implementation dependent. The security of=20
  the implementation depends on a good choice. It is RECOMMENDED that=20
  it contain at least 64 bits of entropy. The nonce is opaque to the=20
  client. This directive is required and MUST appear exactly once; if=20
  not present, or if multiple instances are present, the client should=20
  abort the authentication exchange. =20

Leach, Newman         Standards Track              [Page 5] =0C

                         Digest SASL Mechanism          September, 1999 =

qop-options=20
  A quoted string of one or more tokens indicating the "quality of=20
  protection" values supported by the server.  The value "auth"=20
  indicates authentication; the value "auth-int" indicates=20
  authentication with integrity protection; the value "auth-conf"=20
  indicates authentication with integrity protection and encryption.=20
  This directive is optional; if not present it defaults to "auth". The =

  client MUST ignore unrecognized options; if the client recognizes no=20
  option, it should abort the authentication exchange.=20

stale=20
  The "stale" directive is not used in initial authentication. See the=20
  next section for its use in subsequent authentications. This=20
  directive may appear at most once; if multiple instances are present, =

  the client should abort the authentication exchange.=20

maxbuf=20
  A number indicating the size of the largest buffer the server is able =

  to receive when using "auth-int" or "auth-conf". If this directive is =

  missing, the default value is 65536. This directive may appear at=20
  most once; if multiple instances are present, the client should abort =

  the authentication exchange.=20

charset=20
  This directive, if present, specifies that the server supports UTF-8=20
  encoding for the username and password. If not present, the username=20
  and password must be encoded in ISO 8859-1 (of which US-ASCII is a=20
  subset). The directive is needed for backwards compatibility with=20
  HTTP Digest, which only supports ISO 8859-1. This directive may=20
  appear at most once; if multiple instances are present, the client=20
  should abort the authentication exchange.=20

algorithm=20
  This directive is required for backwards compatibility with HTTP=20
  Digest., which supports other algorithms. . This directive is=20
  required and MUST appear exactly once; if not present, or if multiple =

  instances are present, the client should abort the authentication=20
  exchange.=20

cipher-opts=20
  A list of ciphers that the server supports. This directive must be=20
  present exactly once if "auth-conf" is offered in the "qop-options"=20
  directive, in which case the "3des" and "des" modes are mandatory-to-
  implement. The client MUST ignore unrecognized options; if the client =

  recognizes no option, it should abort the authentication exchange.=20

Leach, Newman         Standards Track              [Page 6] =0C

                         Digest SASL Mechanism          September, 1999 =

  des=20
     the Data Encryption Standard (DES) cipher [FIPS] in cipher block=20
     chaining (CBC) mode with a 56 bit key.=20

  3des=20
     the "triple DES" cipher in CBC mode with EDE with the same key for =

     each E stage (aka "two keys mode") for a total key length of 112=20
     bits.=20

  rc4, rc4-40, rc4-56=20
     the RC4 cipher with a 128 bit, 40 bit, and 56 bit key,=20
     respectively.=20

auth-param=20
  This construct allows for future extensions; it may appear more than=20
  once. The client MUST ignore any unrecognized directives.=20

For use as a SASL mechanism, note that the following changes are made =
to=20
"digest-challenge" from HTTP: the following Digest options (called=20
"directives" in HTTP terminology) are unused (i.e., MUST NOT be sent,=20
and MUST be ignored if received):=20

    opaque=20
    domain=20
    =20
The size of a digest-challenge MUST be less than 2048 bytes.=20

2.1.2Step Two=20

The client makes note of the "digest-challenge" and then responds with =
a=20
string formatted and computed according to the rules for a "digest-
response" defined as follows:=20

digest-response  =3D 1#( username | realm | nonce | cnonce |=20
                       nonce-count | qop | digest-uri | response |=20
                       maxbuf | charset | cipher | authzid |=20
                       auth-param )=20
=20
    username         =3D "username" "=3D" <"> username-value <">=20
    username-value   =3D qdstr-val=20
    cnonce           =3D "cnonce" "=3D" <"> cnonce-value <">=20
    cnonce-value     =3D qdstr-val=20
    nonce-count      =3D "nc" "=3D" nc-value=20
    nc-value         =3D 8LHEX=20
    qop              =3D "qop" "=3D" qop-value=20
    digest-uri       =3D "digest-uri" "=3D" <"> digest-uri-value <">=20
    digest-uri-value  =3D serv-type "/" host [ "/" serv-name ]=20
    serv-type        =3D 1*ALPHA=20
    host             =3D 1*( ALPHA | DIGIT | "-" | "." )=20

Leach, Newman         Standards Track              [Page 7] =0C

                         Digest SASL Mechanism          September, 1999 =

    serv-name        =3D host=20
    response         =3D "response" "=3D" response-value=20
    response-value   =3D 32LHEX=20
    LHEX             =3D "0" | "1" | "2" | "3" |=20
                       "4" | "5" | "6" | "7" |=20
                       "8" | "9" | "a" | "b" |=20
                       "c" | "d" | "e" | "f"=20
    cipher           =3D "cipher" "=3D" cipher-value=20
    authzid          =3D "authzid" "=3D" <"> authzid-value <">=20
    authzid-value    =3D qdstr-val=20
=20
=20

username=20
  The user's name in the specified realm, encoded according to the=20
  value of the "charset" directive. This directive is required and MUST =

  be present exactly once; otherwise, authentication fails.=20

realm=20
  The realm containing the user's account. This directive is required=20
  if the server provided any realms in the "digest-challenge", in which =

  case it may appear exactly once and its value SHOULD be one of those=20
  realms. If the directive is missing, "realm-value" will set to the=20
  empty string when computing A1 (see below for details).=20

nonce=20
  The server-specified data string received in the preceding digest-
  challenge. This directive is required and MUST be present exactly=20
  once; otherwise, authentication fails.=20

cnonce=20
  A client-specified data string which MUST be different each time a=20
  digest-response is sent as part of initial authentication. The=20
  cnonce-value is an opaque quoted string value provided by the client=20
  and used by both client and server to avoid chosen plaintext attacks, =

  and to provide mutual authentication. The security of the=20
  implementation depends on a good choice. It is RECOMMENDED that it=20
  contain at least 64 bits of entropy. This directive is required and=20
  MUST be present exactly once; otherwise, authentication fails.=20

nonce-count=20
  The nc-value is the hexadecimal count of the number of requests=20
  (including the current request) that the client has sent with the=20
  nonce value in this request.  For example, in the first request sent=20
  in response to a given nonce value, the client sends "nc=3D00000001". =
=20
  The purpose of this directive is to allow the server to detect=20
  request replays by maintaining its own copy of this count - if the=20
  same nc-value is seen twice, then the request is a replay.   See the=20

Leach, Newman         Standards Track              [Page 8] =0C

                         Digest SASL Mechanism          September, 1999 =

  description below of the construction of the response value. This=20
  directive may appear at most once; if multiple instances are present, =

  the client should abort the authentication exchange.=20

qop=20
  Indicates what "quality of protection" the client accepted. If=20
  present, it may appear exactly once and  its value MUST be one of the =

  alternatives in qop-options. If not present, it defaults to "auth".=20
  These values affect the computation of the response. Note that this=20
  is a single token, not a quoted list of alternatives.=20

serv-type=20
  Indicates the type of service, such as "www" for web service, "ftp"=20
  for FTP service, "smtp" for mail delivery service, etc. The service=20
  name as defined in the SASL profile for the protocol see section 4 of =

  [RFC 2222], registered in the IANA registry of "service" elements for =

  the GSSAPI host-based service name form [RFC 2078].  Regardless of=20
  case, they are lower cased when used in hash computations.=20

host=20
  The DNS host name or IP address for the service requested.  The DNS=20
  host name must be the fully-qualified canonical name of the host. =20
  The DNS host name is the preferred form; see notes on server=20
  processing of the digest-uri.=20

serv-name=20
  Indicates the name of the service if it is replicated. The service is =

  considered to be replicated if the client's service-location process=20
  involves resolution using standard DNS lookup operations, and if=20
  these operations involve DNS records (such as SRV, or MX) which=20
  resolve one DNS name into a set of other DNS names. In this case, the =

  initial name used by the client is the "serv-name", and the final=20
  name is the "host" component. For example, the incoming mail service=20
  for "example.com" may be replicated through the use of MX records=20
  stored in the DNS, one of which points at an SMTP server called=20
  "mail3.example.com"; it's "serv-name" would be "example.com", it's=20
  "host" would be "mail3.example.com". If the service is not=20
  replicated, or the serv-name is identical to the host, then the serv-
  name component MUST be omitted.=20

digest-uri=20
  Indicates the principal name of the service with which the client=20
  wishes to connect, formed from the serv-type, host, and serv-name.=20
  For example, the FTP service on "ftp.example.com" would have a=20
  "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from the =

  example above would have a "digest-uri" value of=20
  "smtp/mail3.example.com/example.com".=20

Leach, Newman         Standards Track              [Page 9] =0C

                         Digest SASL Mechanism          September, 1999 =

   Servers SHOULD check that the supplied value is correct. This will=20
  detect accidental connection to the incorrect server. It is also so=20
  that clients will be trained to provide values that will work with=20
  implementations that use a shared back-end authentication service=20
  that can provide server authentication.=20

  The serv-type component should match the service being offered. The=20
  host component should match one of the host names of the host on=20
  which the service is running, or it's IP address. Servers SHOULD NOT=20
  normally support the IP address form, because server authentication=20
  by IP address is not very useful; they should only do so if the DNS=20
  is unavailable or unreliable. The serv-name component should match=20
  one of the service's configured service names. =20

  This directive may appear at most once; if multiple instances are=20
  present, the client should abort the authentication exchange.=20

  Note: In the HTTP use of Digest authentication, the digest-uri is the =

  URI (usually a URL) of the resource requested -- hence the name of=20
  the directive.=20

response =20
  A string of 32 hex digits computed as defined below, which proves=20
  that the user knows a password. This directive is required and MUST=20
  be present exactly once; otherwise, authentication fails.=20

maxbuf=20
  A number indicating the size of the largest buffer the client is able =

  to receive. If this directive is missing, the default value is 65536. =

  This directive may appear at most once; if multiple instances are=20
  present, the server should abort the authentication exchange.=20

charset=20
  This directive, if present, specifies that the client has used UTF-8=20
  encoding for the username and password. If not present, the username=20
  and password must be encoded in ISO 8859-1 (of which US-ASCII is a=20
  subset). The client should send this directive only if the server has =

  indicated it supports UTF-8. The directive is needed for backwards=20
  compatibility with HTTP Digest, which only supports ISO 8859-1.=20

LHEX=20
  32 hex digits, where the alphabetic characters MUST be lower case,=20
  because MD5 is not case insensitive.=20

cipher=20
  The cipher chosen by the client. This directive MUST appear exactly=20
  once if "auth-conf" is negotiated; if required and not present,=20
  authentication fails.=20

Leach, Newman         Standards Track             [Page 10] =0C

                         Digest SASL Mechanism          September, 1999 =

authzid=20
  The "authorization ID" as per RFC 2222, encoded in UTF-8. This=20
  directive is optional. If present, and the authenticating user has=20
  sufficient privilege, and the server supports it, then after=20
  authentication the server will use this identity for making all=20
  accesses and access checks. If the client specifies it, and the=20
  server does not support it, then the response-value will be=20
  incorrect, and authentication will fail.=20

The size of a digest-response MUST be less than 4096 bytes.=20

2.1.2.1   Response-value=20
The definition of "response-value" above indicates the encoding for its =

value -- 32 lower case hex characters. The following definitions show=20
how the value is computed.=20

   response-value  =3D =20
      HEX( KD ( HEX(H(A1)),=20
              { nonce-value, ":" nc-value, ":", =20
                cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))=20
 =20
If authzid is specified, then A1 is=20

=20
   A1 =3D { H( { username-value, ":", realm-value, ":", passwd } ), =20
        ":", nonce-value, ":", cnonce-value, ":", authzid-value }=20
=20
If authzid is not specified, then A1 is=20

=20
   A1 =3D { H( { username-value, ":", realm-value, ":", passwd } ), =20
        ":", nonce-value, ":", cnonce-value }=20
=20
where=20

      passwd   =3D *OCTET=20
=20
The "username-value", "realm-value" and "passwd" are encoded according=20
to the value of the "charset" directive. If "charset=3DUTF-8" is =
present,=20
and all the characters of either "username-value" or "passwd" are in =
the=20
ISO 8859-1 character set, then it must be converted to ISO 8859-1 =
before=20
being hashed. This is so that authentication databases that store the=20
hashed username, realm and password (which is common) can be shared=20
compatibly with HTTP, which specifies ISO 8859-1. A sample=20
implementation of this conversion is in section 8.=20

If the "qop" directive's value is "auth", then A2 is:=20

Leach, Newman         Standards Track             [Page 11] =0C

                         Digest SASL Mechanism          September, 1999 =

   A2       =3D { "AUTHENTICATE:", digest-uri-value }=20
=20
If the "qop" value is "auth-int" or "auth-conf" then A2 is:=20

   A2       =3D { "AUTHENTICATE:", digest-uri-value, =20
            ":00000000000000000000000000000000" }=20
=20
Note that "AUTHENTICATE:" must be in upper case, and the second string=20
constant is a string with a colon followed by 32 zeros.=20

These apparently strange values of A2 are for compatibility with HTTP;=20
they were arrived at by setting "Method" to "AUTHENTICATE" and the hash =

of the entity body to zero in the HTTP digest calculation of A2.=20

Also, in the HTTP usage of Digest, several directives in the "digest-
challenge" sent by the server have to be returned by the client in the=20
"digest-response". These are:=20

    opaque=20
    algorithm=20
    =20
These directives are not needed when Digest is used as a SASL mechanism =

(i.e., MUST NOT be sent, and MUST be ignored if received).=20

2.1.3Step Three=20

The server receives and validates the "digest-response". The server=20
checks that the nonce-count is "00000001". If it supports subsequent=20
authentication (see section 2.2), it saves the value of the nonce and=20
the nonce-count. It sends a message formatted as follows:=20

    response-auth =3D "rspauth" "=3D" response-value=20
    =20
where response-value is calculated as above, using the values sent in=20
step two, except that if qop is "auth", then A2 is=20

    A2 =3D { ":", digest-uri-value }=20
    =20
And if qop is "auth-int" or "auth-conf" then A2 is=20

    A2 =3D { ":", digest-uri-value, ":00000000000000000000000000000000" =
}=20
    =20
Compared to its use in HTTP, the following Digest directives in the=20
"digest-response" are unused:=20

Leach, Newman         Standards Track             [Page 12] =0C

                         Digest SASL Mechanism          September, 1999 =

    nextnonce=20
    qop=20
    cnonce=20
    nonce-count=20
    =20
2.2   Subsequent Authentication=20

If the client has previously authenticated to the server, and remembers =

the values of username, realm, nonce, nonce-count, cnonce, and qop that =

it used in that authentication, and the SASL profile for a protocol=20
permits an initial client response, then it MAY perform "subsequent=20
authentication", as defined in this section.=20

2.2.1Step one=20

The client uses the values from the previous authentication and sends =
an=20
initial response with a string formatted and computed according to the=20
rules for a "digest-response", as defined above, but with a nonce-count =

one greater than used in the last "digest-response".=20

2.2.2Step Two=20

The server receives the "digest-response". If the server does not=20
support subsequent authentication, then it sends a "digest-challenge",=20
and authentication proceeds as in initial authentication. If the server =

has no saved nonce and nonce-count from a previous authentication, then =

it sends a "digest-challenge", and authentication proceeds as in =
initial=20
authentication. Otherwise, the server validates the "digest-response",=20
checks that the nonce-count is one greater than that used in the=20
previous authentication using that nonce, and saves the new value of=20
nonce-count.=20

If the response is invalid, then the server sends a "digest-challenge", =

and authentication proceeds as in initial authentication  (and should =
be=20
configurable to log an authentication failure in some sort of security=20
audit log, since the failure may be a symptom of an attack). The nonce-
count MUST NOT be incremented in this case: to do so would allow a=20
denial of service attack by sending an out-of-order nonce-count.=20

If the response is valid, the server MAY choose to deem that=20
authentication has succeeded. However, if it has been too long since =
the=20
previous authentication, or for any other reason, the server MAY send a =

new "digest-challenge" with a new value for nonce. The challenge MAY=20
contain a "stale" directive with value "true", which says that the=20
client may respond to the challenge using the password it used in the=20
previous response; otherwise, the client must solicit the password anew =

from the user. This permits the server to make sure that the user has=20
presented their password recently. (The directive name refers to the=20
previous nonce being stale, not to the last use of the password.) =
Except=20

Leach, Newman         Standards Track             [Page 13] =0C

                         Digest SASL Mechanism          September, 1999 =

for the handling of "stale", after sending the "digest-challenge"=20
authentication proceeds as in the case of initial authentication.=20

2.3   Integrity Protection=20

If the server offered "qop=3Dauth-int" and the client responded =
"qop=3Dauth-
int", then subsequent messages, up to but not including the next=20
subsequent authentication, between the client and the server MUST be=20
integrity protected. Using as a base session key the value of H(A1) as=20
defined above the client and server calculate a pair of message=20
integrity keys as follows.=20

The key for integrity protecting messages from client to server is:=20

Kic =3D MD5({H(A1),=20
"Digest session key to client-to-server signing key magic constant"})=20
=20
The key for integrity protecting messages from server to client is:=20

Kis =3D MD5({H(A1),=20
"Digest session key to server-to-client signing key magic constant"})=20
=20
where MD5 is as specified in [RFC 1321]. If message integrity is=20
negotiated, a MAC block for each message is appended to the message. =
The=20
MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC 2104] of =

the message, a 2-byte message type number in network byte order with=20
value 1, and the 4-byte sequence number in network byte order. The=20
message type is to allow for future extensions such as rekeying.=20

MAC(Ki, SeqNum, msg) =3D (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001, =
SeqNum)=20
=20
where Ki is Kic for messages sent by the client and Kis for those sent=20
by the server. The sequence number is initialized to zero, and=20
incremented by one for each message sent.=20

Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the=20
received value; the message is discarded if they differ.=20

2.4   Confidentiality Protection=20

If the server sent a "cipher-opts" directive and the client responded=20
with a "cipher" directive, then subsequent messages between the client=20
and the server MUST be confidentiality protected. Using as a base=20
session key the value of H(A1) as defined above the client and server=20
calculate a pair of message integrity keys as follows.=20

The key for confidentiality protecting messages from client to server=20
is:=20

Kcc =3D MD5({H(A1)[0..n],=20

Leach, Newman         Standards Track             [Page 14] =0C

                         Digest SASL Mechanism          September, 1999 =

"Digest H(A1) to client-to-server sealing key magic constant"})=20
=20
The key for confidentiality protecting messages from server to client=20
is:=20

Kcs =3D MD5({H(A1)[0..n],=20
"Digest H(A1) to server-to-client sealing key magic constant"})=20
=20
where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5; =
for=20
"rc4-56" n is 7; for the rest n is 16. The key for the "rc-*" ciphers =
is=20
all 16 bytes of Kcc or Kcs; the key for "des" is the first 7 bytes; the =

key for "3des" is the first 14 bytes. The IV for "des" and "3des" is =
the=20
last 8 bytes of Kcc or Kcs.=20

If message confidentiality is negotiated, each message is encrypted =
with=20
the chosen cipher and a MAC block is appended to the message.=20

The MAC block is a variable length padding prefix followed by 16 bytes=20
formatted as follows: the first 10 bytes of the HMAC-MD5 [RFC 2104] of=20
the message, a 2-byte message type number in network byte order with=20
value 1, and the 4-byte sequence number in network byte order. If the=20
blocksize of the chosen cipher is not 1 byte, the padding prefix is one =

or more octets each containing the number of padding bytes, such that=20
total length of the encrypted part of the message is a multiple of the=20
blocksize. The padding and first 10 bytes of the MAC block are =
encrypted=20
along with the message.=20

SEAL(Ki, Kc, SeqNum, msg) =3D =20
      {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9])}), 0x0001,=20
       SeqNum}=20
=20
where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for=20
messages sent by the client and Kis and Kcs for those sent by the=20
server. The sequence number is initialized to zero, and incremented by=20
one for each message sent.=20

Upon receipt, the message is decrypted, HMAC(Ki, {SeqNum, msg}) is=20
computed and compared with the received value; the message is discarded =

if they differ.=20

3  Security Considerations=20

3.1   Authentication of Clients using Digest Authentication=20

Digest Authentication does not provide a strong authentication=20
mechanism, when compared to public key based mechanisms, for example.=20
However, since it prevents chosen plaintext attacks, it is stronger =
than=20
(e.g.) CRAM-MD5, which has been proposed for use with LDAP [10], POP =
and=20
IMAP (see RFC 2195 [9]).   It is intended to replace the much weaker =
and=20

Leach, Newman         Standards Track             [Page 15] =0C

                         Digest SASL Mechanism          September, 1999 =

even more dangerous use of plaintext passwords; however, since it is=20
still a password based mechanism it avoids some of the potential=20
deployabilty issues with public-key, OTP or similar mechanisms.=20

Digest Authentication offers no confidentiality protection beyond=20
protecting the actual password. All of the rest of the challenge=20
and response are available to an eavesdropper, including the=20
user's name and authentication realm.=20

3.2   Comparison of Digest with Plaintext Passwords=20

The greatest threat to the type of transactions for which these=20
protocols are used is network snooping. This kind of transaction=20
might involve, for example, online access to a mail service whose=20
use is restricted to paying subscribers. With plaintext password=20
authentication an eavesdropper can obtain the password of the=20
user. This not only permits him to access anything in the=20
database, but, often worse, will permit access to anything else=20
the user protects with the same password.=20

3.3   Replay Attacks=20

Replay attacks are defeated if the client or the server chooses a=20
fresh nonce for each authentication, as this specification=20
requires.=20

3.4   Online dictionary attacks=20

If the attacker can eavesdrop, then it can test any overheard=20
nonce/response pairs against a (potentially very large) list of common=20
words. Such a list is usually much smaller than the total number of=20
possible passwords. The cost of computing the response for each =
password=20
on the list is paid once for each challenge.=20

The server can mitigate this attack by not allowing users to select=20
passwords that are in a dictionary.=20

3.5   Offline dictionary attacks=20

If the attacker can choose the challenge, then it can precompute the=20
possible responses to that challenge for a list of common words. Such a =

list is usually much smaller than the total number of possible=20
passwords. The cost of computing the response for each password on the=20
list is paid just once.=20

Offline dictionary attacks are defeated if the client chooses a fresh=20
nonce for each authentication, as this specification requires.=20

Leach, Newman         Standards Track             [Page 16] =0C

                         Digest SASL Mechanism          September, 1999 =

3.6   Man in the Middle=20

Digest authentication is vulnerable to "man in the middle" (MITM)=20
attacks. Clearly, a MITM would present all the problems of=20
eavesdropping. But it also offers some additional opportunities to the=20
attacker.=20

A possible man-in-the-middle attack would be to substitute a weaker qop =

scheme for the one(s) sent by the server; the server will not be able =
to=20
detect this attack. For this reason, the client should always use the=20
strongest scheme that it understands from the choices offered, and=20
should never choose a scheme that does not meet its minimum=20
requirements.=20

3.7   Chosen plaintext attacks=20

A chosen plaintext attack is where a MITM or a malicious server can=20
arbitrarily choose the challenge that the client will use to compute =
the=20
response. The ability to choose the challenge is known to make=20
cryptanalysis much easier [8].=20

However, Digest does not permit the attack to choose the challenge as=20
long as the client chooses a fresh nonce for each authentication, as=20
this specification requires.=20

3.8   Spoofing by Counterfeit Servers=20

If a user can be led to believe that she is connecting to a host=20
containing information protected by a password she knows, when in fact=20
she is connecting to a hostile server, then the hostile server can=20
obtain challenge/response pairs where it was able to partly choose the=20
challenge. There is no known way that this can be exploited.=20

3.9   Storing passwords=20

Digest authentication requires that the authenticating agent (usually=20
the server) store some data derived from the user's name and password =
in=20
a "password file" associated with a given realm. Normally this might=20
contain pairs consisting of username and H({ username-value, ":", =
realm-
value, ":", passwd }), which is adequate to compute H(A1) as described=20
above without directly exposing the user's password.=20

The security implications of this are that if this password file is=20
compromised, then an attacker gains immediate access to documents on =
the=20
server using this realm. Unlike, say a standard UNIX password file, =
this=20
information need not be decrypted in order to access documents in the=20
server realm associated with this file. On the other hand, decryption,=20
or more likely a brute force attack, would be necessary to obtain the=20
user's password. This is the reason that the realm is part of the=20
digested data stored in the password file. It means that if one Digest=20

Leach, Newman         Standards Track             [Page 17] =0C

                         Digest SASL Mechanism          September, 1999 =

authentication password file is compromised, it does not automatically=20
compromise others with the same username and password (though it does=20
expose them to brute force attack).=20

There are two important security consequences of this. First the=20
password file must be protected as if it contained plaintext passwords, =

because for the purpose of accessing documents in its realm, it=20
effectively does.=20

A second consequence of this is that the realm string should be unique=20
among all realms that any single user is likely to use. In particular a =

realm string should include the name of the host doing the=20
authentication. =20

3.10  Multiple realms=20

Use of multiple realms may mean both that compromise of a the security=20
database for a single realm does not compromise all security, and that=20
there are more things to protect in order to keep the whole system=20
secure.=20

3.11  Summary=20

By modern cryptographic standards Digest Authentication is weak,=20
compared to (say) public key based mechanisms. But for a large range of =

purposes it is valuable as a replacement for plaintext passwords. Its=20
strength may vary depending on the implementation.=20

4  Example=20

This example shows the use of the Digest SASL mechanism with the IMAP4=20
AUTHENTICATE command [RFC 2060].=20

In this example, "C:" and "S:" represent a line sent by the client or=20
server respectively including a CRLF at the end.  Linebreaks and=20
indentation within a "C:" or "S:" are editorial and not part of the=20
protocol. The password in this example was "secret".  Note that the=20
base64 encoding of the challenges and responses is part of the IMAP4=20
AUTHENTICATE command, not part of the Digest specification itself.=20

Leach, Newman         Standards Track             [Page 18] =0C

                         Digest SASL Mechanism          September, 1999 =

    S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9=20
    C: c CAPABILITY=20
    S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA=20
                UIDPLUS AUTH=3DCRAM-MD5 AUTH=3DDIGEST-MD5 AUTH=3DPLAIN=20
    S: c OK Completed=20
    C: a AUTHENTICATE DIGEST-MD5=20
    S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0=20
         RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh=20
         cnNldD11dGYtOA=3D=3D=20
    C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2=20
       QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw=20
       MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im=20
       ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw=20
       ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=3D=20
    S: + cnNwYXV0aD00YjJiYjM3ZjA0OTEwNTA1Nzc3YzJmNjM4YzkyMjcyNQ=3D=3D=20
    C:=20
    S: a OK User logged in=20
    ---=20
    =20
    The base64-decoded version of the SASL exchange is:=20
    =20
    S: =
realm=3D"elwood.innosoft.com",nonce=3D"OA6MG9tEQGm2hh",qop=3D"auth",=20
       algorithm=3Dmd5-sess,charset=3Dutf-8=20
    C: =
charset=3Dutf-8,username=3D"chris",realm=3D"elwood.innosoft.com",=20
       =
nonce=3D"OA6MG9tEQGm2hh",nc=3D00000001,cnonce=3D"OA6MHXh6VqTrRk",=20
       digest-uri=3D"imap/elwood.innosoft.com",=20
       response=3Dd388dad90d4bbd760a152321f2143af7,qop=3Dauth=20
    S: rspauth=3D4b2bb37f04910505777c2f638c922725=20
    =20
    The password in this example was "secret".=20
    =20
This example shows the use of the Digest SASL mechanism with the ACAP,=20
using the same notational conventions and password as in the previous=20
example. Note that ACAP does not base64 encode and uses fewer round=20
trips that IMAP4.=20

Leach, Newman         Standards Track             [Page 19] =0C

                         Digest SASL Mechanism          September, 1999 =

    S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5"=20
               "DIGEST-MD5" "PLAIN")=20
    C: a AUTHENTICATE "DIGEST-MD5"=20
    S: + {94}=20
    S: =
realm=3D"elwood.innosoft.com",nonce=3D"OA9BSXrbuRhWay",qop=3D"auth",=20
       algorithm=3Dmd5-sess,charset=3Dutf-8=20
    C: {206}=20
    C: =
charset=3Dutf-8,username=3D"chris",realm=3D"elwood.innosoft.com",=20
       =
nonce=3D"OA9BSXrbuRhWay",nc=3D00000001,cnonce=3D"OA9BSuZWMSpW8m",=20
       digest-uri=3D"acap/elwood.innosoft.com",=20
       response=3D6084c6db3fede7352c551284490fd0fc,qop=3Dauth=20
    S: a OK (SASL {40}=20
    S: rspauth=3Dd84489141f9d86605c6a77b95cb5365a) "AUTHENTICATE=20
    Completed"=20
    ---=20
=20
The server uses the values of all the directives, plus knowledge of the =

users password (or the hash of the user's name, server's realm and the=20
user's password) to verify the computations above. If they check, then=20
the user has authenticated.=20

5   References=20

[Digest] Franks, J., et. al., "HTTP Authentication: Basic and Digest=20
  Access Authentication", <draft-ietf-http-authentication-03>, Work in=20
  Progress of the HTTP Working Group, August, 1998=20

[ISO-8859] ISO-8859. International Standard -- Information Processing =
--=20
  8-bit Single-Byte Coded Graphic Character Sets --=20
  Part 1: Latin alphabet No. 1, ISO-8859-1:1987.=20
  Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.=20
  Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.=20
  Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.=20
  Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.=20
  Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.=20
  Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.=20
  Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.=20
  Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. =20

 [RFC 822] D. H. Crocker, "Standard for The Format of ARPA Internet =
Text=20
  Messages," STD 11, RFC 822, UDEL, August 1982. =20

[RFC 1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,=20
  April 1992=20

Leach, Newman         Standards Track             [Page 20] =0C

                         Digest SASL Mechanism          September, 1999 =

[RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) =
Part=20
  Three: Message Header Extensions for Non-ASCII Text", RFC 2047,=20
  University of Tennessee, November 1996. =20

[RFC 2052] A. Gulbrandsen, P. Vixie, A DNS RR for specifying the=20
  location of services (DNS SRV). October 1996.=20

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

 [RFC 2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing=20
  for  Message Authentication", RFC 2104, 02/05/1997=20

[RFC2195] Klensin, J., et. al., "IMAP/POP AUTHorize Extension for =
Simple=20
  Challenge/Response", RFC 2195, September, 1997.=20

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

[USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard Code=20
  for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. =20

6  Authors' Addresses=20

Paul Leach=20
Microsoft=20
1 Microsoft Way=20
Redmond, WA  98052=20
[email-masked]=20

Chris Newman=20
Innosoft International, Inc.=20
1050 Lakes Drive=20
West Covina, CA 91790 USA=20
[email-masked]=20

7  ABNF=20

What follows is the definition of the notation as is used in the=20
HTTP/1.1 specification (RFC 2616) and the HTTP authentication=20
specification (RFC 2617); it is reproduced here for ease of reference.=20
Since it is intended that a single Digest implementation can support=20
both HTTP and SASL-based protocols, the same notation is used in both =
to=20
facilitate comparison and prevention of unwanted differences. Since it=20
is cut-and-paste from the HTTP specifications, not all productions may=20

Leach, Newman         Standards Track             [Page 21] =0C

                         Digest SASL Mechanism          September, 1999 =

be used in this specification. It is also not quite legal ABNF; again,=20
the errors were copied from the HTTP specifications.=20

7.1   Augmented BNF =20

All of the mechanisms specified in this document are described in both=20
prose and an augmented Backus-Naur Form (BNF) similar to that used by=20
RFC 822 [RFC 822]. Implementers will need to be familiar with the=20
notation in order to understand this specification.=20

The augmented BNF includes the following constructs:=20

name =3D definition=20
  The name of a rule is simply the name itself (without any enclosing=20
  "<" and ">") and is separated from its definition by the equal "=3D"=20
  character. White space is only significant in that indentation of=20
  continuation lines is used to indicate a rule definition that spans=20
  more than one line. Certain basic rules are in uppercase, such as SP, =

  LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within=20
  definitions whenever their presence will facilitate discerning the=20
  use of rule names.=20

"literal"=20
  Quotation marks surround literal text. Unless stated otherwise, the=20
  text is case-insensitive.=20

rule1 | rule2=20
  Elements separated by a bar ("|") are alternatives, e.g., "yes | no"=20
  will accept yes or no.=20

(rule1 rule2)=20
  Elements enclosed in parentheses are treated as a single element.=20
  Thus, "(elem (foo | bar) elem)" allows the token sequences=20
  "elem foo elem" and "elem bar elem".=20

*rule=20
  The character "*" preceding an element indicates repetition. The full =

  form is "<n>*<m>element" indicating at least <n> and at most <m>=20
  occurrences of element. Default values are 0 and infinity so that=20
  "*(element)" allows any number, including zero; "1*element" requires=20
  at least one; and "1*2element" allows one or two.=20

[rule]=20
  Square brackets enclose optional elements; "[foo bar]" is equivalent=20
  to "*1(foo bar)".=20

N rule =20
  Specific repetition: "<n>(element)" is equivalent to=20

Leach, Newman         Standards Track             [Page 22] =0C

                         Digest SASL Mechanism          September, 1999 =

  "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).=20
  Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three=20
  alphabetic characters.=20

#rule=20
  A construct "#" is defined, similar to "*", for defining lists of=20
  elements. The full form is "<n>#<m>element" indicating at least <n>=20
  and at most <m> elements, each separated by one or more commas (",")=20
  and OPTIONAL linear white space (LWS). This makes the usual form of=20
  lists very easy; a rule such as=20
    ( *LWS element *( *LWS "," *LWS element ))  =20
  can be shown as =20
    1#element =20
  Wherever this construct is used, null elements are allowed, but do=20
  not contribute to the count of elements present. That is, "(element), =

  , (element) " is permitted, but counts as only two elements.=20
  Therefore, where at least one element is required, at least one non-
  null element MUST be present. Default values are 0 and infinity so=20
  that "#element" allows any number, including zero; "1#element"=20
  requires at least one; and "1#2element" allows one or two.=20

; comment=20
  A semi-colon, set off some distance to the right of rule text, starts =

  a comment that continues to the end of line. This is a simple way of=20
  including useful notes in parallel with the specifications.=20

=20
   implied *LWS =20
   The grammar described by this specification is word-based. Except=20
  where noted otherwise, linear white space (LWS) can be included=20
  between any two adjacent words (token or quoted-string), and between=20
  adjacent words and separators, without changing the interpretation of =

  a field. At least one delimiter (LWS and/or separators) MUST exist=20
  between any two tokens (for the definition of "token" below), since=20
  they would otherwise be interpreted as a single token.=20

=20
7.2   Basic Rules =20

The following rules are used throughout this specification to describe=20
basic parsing constructs. The US-ASCII coded character set is defined =
by=20
ANSI X3.4-1986 [USASCII].=20

       OCTET          =3D <any 8-bit sequence of data>=20
       CHAR           =3D <any US-ASCII character (octets 0 - 127)>=20
       UPALPHA        =3D <any US-ASCII uppercase letter "A".."Z">=20
       LOALPHA        =3D <any US-ASCII lowercase letter "a".."z">=20
       ALPHA          =3D UPALPHA | LOALPHA=20
       DIGIT          =3D <any US-ASCII digit "0".."9">=20

Leach, Newman         Standards Track             [Page 23] =0C

                         Digest SASL Mechanism          September, 1999 =

       CTL            =3D <any US-ASCII control character=20
                        (octets 0 - 31) and DEL (127)>=20
       CR             =3D <US-ASCII CR, carriage return (13)>=20
       LF             =3D <US-ASCII LF, linefeed (10)>=20
       SP             =3D <US-ASCII SP, space (32)>=20
       HT             =3D <US-ASCII HT, horizontal-tab (9)>=20
       <">            =3D <US-ASCII double-quote mark (34)>=20
       CRLF           =3D CR LF=20
=20
All linear white space, including folding, has the same semantics as =
SP.=20
A recipient MAY replace any linear white space with a single SP before=20
interpreting the field value or forwarding the message downstream.=20

       LWS            =3D [CRLF] 1*( SP | HT )=20
=20
The TEXT rule is only used for descriptive field contents and values=20
that are not intended to be interpreted by the message parser. Words of =

*TEXT MAY contain characters from character sets other than ISO-8859-1=20
[ISO 8859] only when encoded according to the rules of RFC 2047 [RFC=20
2047].=20

       TEXT           =3D <any OCTET except CTLs,=20
                        but including LWS>=20
=20
A CRLF is allowed in the definition of TEXT only as part of a header=20
field continuation. It is expected that the folding LWS will be =
replaced=20
with a single SP before interpretation of the TEXT value.=20

Hexadecimal numeric characters are used in several protocol elements.=20

       HEX            =3D "A" | "B" | "C" | "D" | "E" | "F"=20
                      | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT=20
=20
Many HTTP/1.1 header field values consist of words separated by LWS or=20
special characters. These special characters MUST be in a quoted string =

to be used within a parameter value.=20

       token          =3D 1*<any CHAR except CTLs or separators>=20
       separators     =3D "(" | ")" | "<" | ">" | "@"=20
                      | "," | ";" | ":" | "\" | <">=20
                      | "/" | "[" | "]" | "?" | "=3D"=20
                      | "{" | "}" | SP | HT=20
=20
A string of text is parsed as a single word if it is quoted using=20
double-quote marks.=20

      quoted-string  =3D ( <"> qdstr-val <"> )=20
      qdstr-val      =3D *( qdtext | quoted-pair )=20
      qdtext         =3D <any TEXT except <">>=20
=20

Leach, Newman         Standards Track             [Page 24] =0C

                         Digest SASL Mechanism          September, 1999 =

Note that LWS is NOT implicit between the double-quote marks (<">)=20
surrounding a qdstr-val and the qdstr-val; any LWS will be considered=20
part of the qdstr-val.  This is also the case for quotation marks=20
surrounding any other construct.=20

 The backslash character ("\") MAY be used as a single-character =
quoting=20
mechanism only within qdstr-val and comment constructs.=20

       quoted-pair    =3D "\" CHAR=20
=20
The value of this construct is CHAR. Note that an effect of this rule =
is=20
that backslash must be quoted.=20

8  Sample Code=20

The sample implementation in [Digest] also applies to DIGEST-MD5.=20

The following code implements the conversion from UTF-8 to 8859-1 if=20
necessary.=20

Leach, Newman         Standards Track             [Page 25] =0C

                         Digest SASL Mechanism          September, 1999 =

    /* if the string is entirely in the 8859-1 subset of UTF-8, then=20
     * translate to 8859-1 prior to MD5=20
     */=20
    void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base,=20
        int len)=20
    {=20
        const unsigned char *scan, *end;=20
        unsigned char cbuf;=20
     =20
        end =3D base + len;=20
        for (scan =3D base; scan < end; ++scan) {=20
            if (*scan > 0xC3) break; /* abort if outside 8859-1 */=20
            if (*scan >=3D 0xC0 && *scan <=3D 0xC3) {=20
                if (++scan =3D=3D end || *scan < 0x80 || *scan > 0xBF)=20
                    break;=20
            }=20
        }=20
        /* if we found a character outside 8859-1, don't alter string=20
         */=20
        if (scan < end) {=20
            MD5Update(ctx, base, len);=20
            return;=20
        }=20
     =20
        /* convert to 8859-1 prior to applying hash=20
         */=20
        do {=20
            for (scan =3D base; scan < end && *scan < 0xC0; ++scan)=20
                ;=20
            if (scan !=3D base) MD5Update(ctx, base, scan - base);=20
            if (scan + 1 >=3D end) break;=20
            cbuf =3D ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f);=20
            MD5Update(ctx, &cbuf, 1);=20
            base =3D scan + 2;=20
        } while (base < end);=20
    }=20
    =20

9  Full Copyright Statement=20

Copyright (C) The Internet Society (1998). All Rights Reserved.=20

This document and translations of it may be copied and furnished to=20
others, and derivative works that comment on or otherwise explain it or =

assist in its implementation may be prepared, copied, published and=20
distributed, in whole or in part, without restriction of any kind,=20
provided that the above copyright notice and this paragraph are =
included=20
on all such copies and derivative works. However, this document itself=20
may not be modified in any way, such as by removing the copyright =
notice=20
or references to the Internet Society or other Internet organizations,=20

Leach, Newman         Standards Track             [Page 26] =0C

                         Digest SASL Mechanism          September, 1999 =

except as needed for the purpose of developing Internet standards in=20
which case the procedures for copyrights defined in the Internet=20
Standards process must be followed, or as required to translate it into =

languages other than English.=20

The limited permissions granted above are perpetual and will not be=20
revoked by the Internet Society or its successors or assigns.=20

This document and the information contained herein is provided on an =
"AS=20
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=20
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT=20
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT =

INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=20
FITNESS FOR A PARTICULAR PURPOSE. =20

=20

Leach, Newman         Standards Track             [Page 27] =0C
------_=_NextPart_000_01BF1CA1.BA125820--

Date: Tue, 12 Oct 1999 00:15:20 +0200
From: Keith Burdis <[email-masked]>
To: [email-masked]
Subject: SRP-SASL
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi there

  I've published an Internet Draft about "the Secure Remote Password SASL
  mechanism". It describes an SASL mechanism based on the Secure Remote
  Password protocol developed by Thomas Wu at Stanford University. My goal is
  to develop a mechanism that makes full use of the security and
  functionality of SRP, yet is also simple to implement.

  I'd like some feedback on what people think of this mechanism. In
  particular I'd like to know what you think about confidentiality
  protection. Should I just use a mandatory algorithm like DES?

  There is some alpha1 code that implements this mechanism that will shortly
  be available on the Cryptix site (http://www.cryptix.org/).

  Thanks.

    - Keith
-- 
Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa  
Email   : [email-masked]
WWW     : http://www.rucus.ru.ac.za/~keith/
IRC     : Panthras                                          JAPH

"Any technology sufficiently advanced is indistinguishable from a perl script"

Standard disclaimer.
---

Date: 11 Oct 1999 13:19:24 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: Cyrus SASL 1.5.10 released
Sender: [email-masked]

Hi,

I'm happy to announce the release of the Cyrus SASL library, version
1.5.10.  This version brings our implementation up to the latest
DIGEST-MD5 draft specification, including layers.

We'd be interested in testing interoperability of DIGEST (or any other
mechanisms) with other implementations.

Download Cyrus SASL from:
ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/cyrus-sasl-1.5.10.tar.gz

Send any & all feedback to [email-masked].

Larry