rfc2831bis issues

[Hallvard B Furuseth <[e-mail]>]

Here are various editorial and non-editorial comments for
draft-ietf-sasl-rfc2831bis-02.txt.

> Table of Contents

>     3.8 CBC MODE ATTACKS.............................................

Missing page number.

> 1.1  Conventions and Notation

>    This specification uses the same ABNF notation and lexical
>    conventions as HTTP/1.1 specification; see section 7.

...as well as some named rules defined there (section 7.2).

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

...which the C language adds.

[For readers who don't know C, if any.]

> 2.1.1  Step One
>
>    The server starts by sending a challenge.

How does it know that it should do that?

>    nonce
>       Note
>       that since the string is passed as a quoted string, the
>       double-quote

and backslash?

>       character is not allowed unless escaped (see section
>       7.2).

I think this applies to other quoted strings than the nonce.

>    server_maxbuf ("maximal ciphertext buffer size")

>       Let call "maximal cleartext buffer size" (or "maximal sender
>       size") the maximal size of a cleartext buffer that, after being

"Let call"?  Should be "Call", or "Let .... be", I think.

>    charset
>       This directive, if present, specifies that the server supports
>       UTF-8 [UTF-8] encoding for the username, realm and password. If
>       present, the username, realm and password are in Unicode, prepared
>       using the "SASLPrep" profile [SASLPrep] of the "stringprep"
>       algorithm [StringPrep] and than encoded as UTF-8 [UTF-8].  If not
>       present, the username, realm and password MUST be encoded in ISO
>       8859-1 [ISO-8859] (of which US-ASCII [USASCII] is a subset).

There is no username and password sent by the server.  Do you mean the
_client_ MUST send them in UTF-8 if "charset" is given by the server?

>    cipher-opts

>       "qop-options" directive, in which case the "3des" cipher is
>       mandatory-to-implement.

I suggest you remove the "-"s in mandatory-to-implement.

> 2.1.2  Step Two

>    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.example.com" would have a
>       "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from
>       the example above would have a "digest-uri" value of
>       "SMTP/mail3.example.com/example.com".
>
>    Servers SHOULD check that the supplied value is correct. This will
>    detect accidental connection to the incorrect server, as well as some
>    redirection attacks. It is also so that clients will be trained to
>    provide values that will work with implementations that use a shared
>    back-end authentication service that can provide server
>    authentication.
>
>    The serv-type component should match the service being offered. The
>    host component should match one of the host names of the host on
>    which the service is running, or it's IP address. Servers SHOULD NOT
>    normally support the IP address form, because server authentication
>    by IP address is not very useful; they should only do so if the DNS
>    is unavailable or unreliable. The serv-name component should match
>    one of the service's configured service names.
>
>    This directive may appear at most once; if multiple instances are
>    present, the client should abort the authentication exchange.
>
>    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
>    the directive.

Is this entire section about digest-uri?  If so, most of it should be
indented.

>    authzid

>       The server SHOULD verify the correctness of an authzid as
>       specified by the corresponding SASL protocol profile.

Which corresponding SASL profile?

> 2.2  Subsequent Authentication
>
>    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 permits an initial client response, then it MAY perform
>    "subsequent authentication", as defined in this section.

What's the point of authenticating again with the same username?  Auth
with a _different_ username would be more interesting.

> 2.2.2  Step Two

>    If the response is valid, the server MAY choose to deem that
>    authentication has succeeded. However, if it has been too long since
>    the previous authentication, or for any o including the next
>    subsequent authentication, between the client and the server MUST be
>    integrity protected.

I don't understand the text starting with "or from any o".

>    Using as a base session key the value of H(A1)
>    as defined above

need a "," here

>    Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the
>    received value; the message is discarded if they differ. The
>    receiver's sequence counter is incremented if they match.

Doesn't the server send a response?  How does the client know that the
authentication is completed?

> 2.4   Confidentiality Protection
>
>    If the server sent a "cipher-opts" directive and the client responded
>    with a "cipher" directive, then subsequent messages between the
>    client and the server MUST be confidentiality protected.

What is confidentiality protection?

>    The IV used to send/receive the initial buffer

You might say "Initialization Vector (IV)" again here, it's been a while
since you mentined what an IV is.

>    SEAL(Ki, Kc, SeqNum, msg) =
>          {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9]}), 0x0001,
>           SeqNum}

SEAL?  That is never used in this document.

> 5.1   Normative references

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

Should be [SASL] draft-ietf-sasl-rfc2222bis-02.txt.

>    [Unicode] The Unicode Consortium, "The Unicode Standard, Version

Indent "The".

>    [UTF-8] Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
>               2279, Janyary 1998.

Indent "Yergeau".

>    [RFC 2732]  Hinden, R., Carpenter, B., Masinter, L., "Format for

Unindent "Hinden".

>    [FIPS] National Institute of Standards and Technology, "DES Modes of

Indent "National".

>    [AES] Daemen, J., Rijmen, V., "The Rijndael Block Cipher",

Indent "Daemen".

> 5.2   Informative references

>    [MD5]  Kaliski, B.,Robshaw, M., "Message Authentication with MD5",

Indent "Kaliski".

>    [TLS-CBC] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:

Indent "Moeller".

> 7.1   Augmented BNF

Since <"> means to enclose a literal, you might replace other <">s with
<'>s in this section.  E.g.

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

        Elements separated by a bar ('|') are alternatives, e.g., 'yes |
        no' will accept yes or no.

>    #rule

>         ( *LWS element *( *LWS "," *LWS element ))

Should this really be asymmetric, or should it be
          (      element *( *LWS "," *LWS element ))
or
          ( *LWS element *( *LWS "," *LWS element ) *LWS )
?

> 7.2   Basic Rules

>        OCTET          = <any 8-bit character>

s/character/byte/, I think.  A byte in a multi-byte UTF-8 character
is not normally considered a character.

> 8  Sample Code

>         for (scan = base; scan < end; ++scan) {
>             if (*scan > 0xC3) break; /* abort if outside 8859-1 */
>             if (*scan >= 0xC0 && *scan <= 0xC3) {
>                 if (++scan == end || *scan < 0x80 || *scan > 0xBF)
>                     break;

                  /*
                   * Handle invalid UTF-8-like sequences, e.g. '\0'
                   * encoded as "\xC0\x80".   Accepting such sequences
                   * is a security risk, according to [UTF-8].
                   */
                  if (*scan < 0xC2)
                      return an error or something;

Error return also requires the return type of the function to be
changed, and a 'return success' at the end.  Maybe another way is to
simply not translate invalid UTF-8 strings to iso8859-1.

This should also be discussed in the section which says that UTF-8
should be converted to iso8859-1 when possible.

>             }
>         }

-- 
Hallvard