[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Comments on draft-leach-digest-sasl-01.txt
>
> This specification uses the same ABNF notation and lexical conventions
> as HTTP/1.1 specification; see appendix A.
> * ^^^^^^^^
> *
> * I'd strongly suggest rewriting this to be rfc
> 2234-compliant, since this
> * is for SASL and should be independent of HTTP.
> *
It is and isn't supposed to be independent of HTTP. It is supposed to be
possible to write a single implementation that works for both. I.e., they
are supposed to be compatible. In order to better check that, the same ABNF
notation is used in both. In order to make the specs independent, the ABNF
in use is completely defined in appendix A.
> 2.1 Initial Authentication
>
> If the client has not recently authenticated to the server,
> then it must
> perform "initial authentication", as defined in this section.
> If it has
> recently authenticated, then a more efficient form is
> available, defined
> *^^^^^^^
> * What's the range of magnitudes of "recently"? Is it
> entirely configurable,
> or
> * are there any preconceived bounds? Should say explicitly say which.
This is just a reference to the next section. The word "recently" is to be
understood in it's common English usage.
>
>
> in the next section.
>
>
> 2.1.1 Step One
>
> The server starts by sending a challenge.
>
> * The assumption is that the client initially contacted the server?
> * Should be explicit.
Isn't that the definition of "client"?
RFC 2222, section 3, gives the framework for this and all SASL
specifications. I'll put in a reference.
>
>
> The data encoded in the
> challenge contains a string formatted according to the rules for a
> "digest-challenge" defined as follows:
>
> digest-challenge = 1#( realm | nonce | qop-options | stale |
> maxbuf | charset | cipher-opts | auth-param )
>
> * Is the above BNF strictly correct in the case of "nonce",
> which is later
> defined
> * as occuring exactly once? IMHO such a restriction should be written
> explicitly
> * into the BNF. Also, the BNF doesn't take into account other
> restrictions on
> the
> * various options that are defined in the text below.
> *
> * e.g...
> *
> * digest-challenge = nonce [maxbuf] | 1#( realm | qop-options |
> * charset | cipher-opts | auth-param )
>
This says that the nonce has to come first, which is not true. The notation
I chose seemed to be the most economical one for saying that it has to
appear once but can be in any order. The "only once" requirement I consider
to be like the requirement in a programming language that a variable can
only be declared once in a scope -- in both cases, this isn't enforced in
the BNF, but in the semantic checking.
>
> * This BNF effectively replaces the one given in [Digest]
> section 3.2.1,
> right?
> * It should be explicitly denoted as such if so.
>
> realm = "realm" "=" <"> realm-value <">
> realm-value = qdstr-val
> nonce = "nonce" "=" <"> nonce-value <">
> nonce-value = qdstr-val
> qop-options = "qop" "=" <"> qop-list <">
> qop-list = 1#qop-value
> qop-value = "auth" | "auth-int" | "auth-conf" |
> token
> stale = "stale" "=" "true"
> maxbuf = "maxbuf" "=" maxbuf-value
> maxbuf-value = 1*DIGIT
> charset = "charset" "=" "utf-8"
> algorithm = "algorithm" "=" "md5-sess"
> cipher-opts = "cipher" "=" 1#cipher-value
> cipher-value = "3des" | "des" | "rc4-40" | "rc4" |
> "rc4-56" | token
> auth-param = token "=" ( token | quoted-string )
>
>
> * productions based on below suggestions...
> *
> * realm = "realm" "=" <"> realm-value <">
> * realm-value = qdstr-val
> * nonce = "nonce" "=" <"> nonce-value <">
> * nonce-value = qdstr-val
> * qop-options = "qop" "=" <"> qop-list <">
> * qop-list = 1#qop-value
> * qop-value = "auth" | "auth-int" | "auth-conf" |
> * token
> * <stale -- deleted>
> * maxbuf = "maxbuf" "=" maxbuf-value
> * maxbuf-value = 1*DIGIT
> * charset = "charset" "=" "utf-8"
> * algorithm = "algorithm" "=" "md5-sess"
> * cipher-opts = "cipher" "=" 1#cipher-value
> * cipher-value = "3des" | "des" | "rc4-40" | "rc4" |
> "rc4-56" | token
> * auth-param = token "=" ( token | quoted-string )
>
It appears that the only change is the removal of "stale". Is that true?
> qop-options
> A quoted string of one or more tokens indicating the "quality of
> protection" values supported by the server. The value "auth"
> indicates authentication; the value "auth-int" indicates
> authentication with integrity protection; the value "auth-conf"
> indicates authentication with integrity protection and encryption.
> The client MUST ignore unrecognized options; if the client
> recognizes
> no option, it should abort the authentication exchange.
> *
> * What if no "qop-options" is provided? Abort?
> *
>
Yes. I'll add that.
> stale
> The "stale" directive is not used in initial authentication. See the
> next section for its use in subsequent authentications.
> *
> * "stale" shouldn't appear in the above BNF if it isn't used.
> *
>
> maxbuf
> A number indicating the size of the largest buffer the
> server is able
> to receive when using "auth-int". If this directive is missing, the
> default value is 65536. This directive may appear at most once; if
> multiple instances are present, the client should abort the
> authentication exchange.
> *
> * what about when using "auth-conf"? Same thing? Need to say
> so if so.
> *
Yes. I'll fix it.
> For use as a SASL mechanism, note that the following changes
> are made to
> "digest-challenge" from HTTP: the following Digest options (called
> * ^^^^
> * [Digest] Section 3.2.1
> *
OK.
> "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent,
> and MUST be ignored if received):
>
> opaque
> domain
> *
> * If these options aren't explicitly included in the BNF in this doc,
> * then do we really need this blurb here? What is the default behavior
> * if the server sends any old garbage option that the client doesn't
> * understand (i.e. isn't in the BNF)? Ignore it or abort?
It is in the BNF -- it is an "auth-param", which are to be ignored.
> * If abort, then if we want to gracefully ignore these two guys, they
> * should be in the BNF, and we should say something about them.
> * If the default behavior is ignore, then we don't
> * need to mention these two options here.
I want to be explicit about the differences, to make the requirements of a
single implementation clearer. I.e., to avoid questions of the form "what
about the XXXX directive from HTTP digest".
>
>
> The size of a digest-challenge MUST be less than 2048 bytes.
>
>
> 2.1.2 Step Two
>
> The client makes note of the "digest-challenge" and then
> responds with a
> string formatted and computed according to the rules for a "digest-
> response" defined as follows:
> *
> * should explicitly mention that productions not defined here
> are taken from
> * collections of BNF in this doc (e.g. the preceeding one in
> section 3.2.1)
> *
OK.
>
>
>
> * digest-response = username nonce cnonce nonce-count response
> * *1(maxbuf) 1#( realm |
> * qop | digest-uri |
> * charset | cipher | auth-param )
Doesn't permit them to appear in any order.
>
> nonce
> The server-specified data string received in the preceding digest-
> challenge.
> *
> * Presummably nonce must be present for auth to
> * succeed.
Yes. I'll add that.
>
> nonce-count
> The nc-value is the hexadecimal count of the number of requests
> (including the current request) that the client has sent with the
> nonce value in this request. For example, in the first request sent
> in response to a given nonce value, the client sends "nc=00000001".
> The purpose of this directive is to allow the server to detect
> request replays by maintaining its own copy of this count - if the
> same nc-value is seen twice, then the request is a replay. See the
> description below of the construction of the response value.
> *
> * Presummably nonce must be present for auth to
> * succeed.
Yes. I'll add it.
> qop
> Indicates what "quality of protection" the client accepted. If
> present, its value MUST be one of the alternatives the server
> indicated it supports in digest-challenge. If not present, it
> defaults to "auth". These values affect the computation of the
> response. Note that this is a single token, not a quoted list of
> alternatives.
> *
> * It's unclear whether this option is required to be present
> or not, because
> * it's unclear whether qop-options is required in the challenge.
> * Needs to be resolved.
> *
> digest-uri
> Indicates the principal name of the service with which the client
> wishes to connect, formed from the serv-type, host, and serv-name.
> For example, the FTP service on "ftp.xyz.com" would have a "digest-
> uri" value of "ftp/ftp.xyz.com"; the SMTP server from the example
> above would have a "digest-uri" value of
> "smtp/mail3.xyz.com/xyz.com"
> *
> * what does it mean if the client omits this option?
> *
I'll have to think about it.
> maxbuf
> 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
> present, the server should abort the authentication exchange.
> *
> * this explicitness should be in the BNF.
> *
>
> charset
> This directive, if present, specifies that the client has used UTF-8
> encoding for the username and password. If not present, the username
> and password must be encoded in ISO 8859-1 (of which US-ASCII is a
> subset). The client should send this directive only if the
> server has
> indicated it supports UTF-8. The directive is needed for backwards
> compatibility with HTTP Digest, which only supports ISO 8859-1.
> * ^^^^^^^^^^^
> * [Digest]
> *
OK.
>
> LHEX
> 32 hex digits, where the alphabetic characters MUST be lower case,
> because MD5 is not case insensitive.
> * ^^^ ^^
> * (double negative?)
> *
> * is md5 "case insensitive" or is it "case sensitive"?
> *
"case sensitive"
>
>
> cipher
> The cipher chosen by the client. This directive MUST appear exactly
> once if "auth-conf" is negotiated; if required and not present,
> authentication fails.
> *
> * is there any way to express this requirement in the BNF itself?
Nope. Sorry.
> 2.1.3 Step Three
>
> The server receives and validates the "digest-response". The server
> checks that the nonce-count is "00000001". If it supports subsequent
> authentication, it saves the value of the nonce and the
> nonce-count. It
> sends a message formatted as follows:
>
> response-auth = "rspauth" "=" response-value
>
> where response-value is calculated as above, using the values sent in
> step three, except that if qop is "auth", then A2 is
> * ^^^^^
> * two?
> *
> *
Yes.
> If the response is invalid, then the server sends a
> "digest-challenge",
> and authentication proceeds as in initial authentication
> (and should be
> configurable to log an authentication failure in some sort of security
> audit log, since the failure may be a symptom of an attack).
>
> If the response is valid, the server MAY choose to deem that
> authentication has succeeded. However, if it has been too
> long since the
> * ^^^^^^^^
> *
> * What constitutes "too long"? Is there any notion of range
> of magnitude
> * of this? Or SHOULD it be configurable?
> *
Since it goes on to say "or for any other reason", it should be clear that
the server can choose any value for "too long" it likes. The only downside
to making this short is that it will cost a few bytes on the wire that the
client sent believing it could do re-auth.
> 3.1 Authentication of Clients using Digest Authentication
>
> Digest Authentication does not provide a strong authentication
> mechanism, when compared to public key based mechanisms, for example.
> However, since it prevents chosen plaintext attacks, it is
> stronger than
> (e.g.) CRAM-MD5, which has been proposed for use with LDAP
> [10], POP and
> IMAP (see RFC 2195 [9]). It is intended to replace the much
> weaker and
> even more dangerous use of plaintext passwords; however, since it is
> still a password based mechanism it avoids some of the potential
> deployabilty issues with public-key, OTP or similar mechanisms.
> * ^^^
> * One-Time Password?
Yes.
>
> Digest Authentication offers no confidentiality protection beyond
> * ^
> * itself
> *
OK.
>
> However, Digest does not permit the attack to choose the challenge as
> long as the client chooses a fresh nonce for each authentication, as
> * ^^^^^
> * actually "cnonce", right?
> *
Yes.
> this specification requires.
>
>
> 3.8 Spoofing by Counterfeit Servers
>
> If a user can be led to believe that she is connecting to a host
> containing information protected by a password she knows, when in fact
> she is connecting to a hostile server, then the hostile server can
> obtain challenge/response pairs where it was able to partly choose the
> challenge. There is no known way that this can be exploited.
> * ^^^^^^^^^
> * Do you really mean to say "prevented"?
> *
I meant to say "exploited". It can be prevented with DNS-SEC.
>
> "literal"
> Quotation marks surround literal text. Unless stated otherwise, the
> text is case-insensitive.
> *
> * need to explicitly declare the charset that is used to
> construct literals.
> * USASCII?
Yes.