Subject: rfc2831bis issues

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 14 Oct 2003 22:41:33 +0200

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 26 Oct 2003 20:31:46 +0000

>>    3.8 CBC MODE ATTACKS.............................................
Yes, I was lazy.
I was changing text a lot, so I had to spend a lot of time fixing page 
numbers when doing each revision. So I just gave up.

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

>[For readers who don't know C, if any.]
IMHO, readers who don't know C will not care about this comment anyway, 
because it doesn't add any additional information.

>How does it know that it should do that?
The client always starts first (according to SASL). If the client 
doesn't includes an initial response, the server will  know.

Can you suggest any clarification text here?

>>      that since the string is passed as a quoted string, the
Actually, I've changed ABNF to disallow double-quotes or backslashes.
So, this should be removed.

>I think this applies to other quoted strings than the nonce.
Yes, but it is especially problematic for nonces, as people just 
generate binary data and than forget to quote it.

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

>_client_ MUST send them in UTF-8 if "charset" is given by the server?
Yes.

>I suggest you remove the "-"s in mandatory-to-implement.
This is a term used in SASL. By using "-" I am trying to emphasize this.

>Which corresponding SASL profile?
I meant that any protocol using SASL should verify authorization 
identity as specified in the SASL profile for the protocol. Any 
suggestion how to make this clear?

>with a _different_ username would be more interesting.
This is a case of fast reauthentication using a different TCP 
connection. This is similar to resuming a TLS session.

>I don't understand the text starting with "or from any o".
The text in my copy says:

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 other reason, the server MAY send a
new "digest-challenge" with a new value for nonce. The challenge MAY
contain a "stale" directive with value "true", which says that the
client may respond to the challenge using the password it used in the
previous response; otherwise, the client must solicit the password anew
from the user. This permits the server to make sure that the user has
presented their password recently. (The directive name refers to the
previous nonce being stale, not to the last use of the password.) Except
for the handling of "stale", after sending the "digest-challenge"
authentication proceeds as in the case of initial authentication.

So I am not sure where have you found this.

>>   Using as a base session key the value of H(A1)
Ok.

>>   received value; the message is discarded if they differ.
>>
>> The
This whole section talks about protecting data when authentication is 
already complete.

> ...
Fixed, thanks.

>... 
I can go for the last proposal. At least it seems to be the original intent.

>s/character/byte/, I think.
>
I actually disagree in this case. A byte has 8 bits by definition.

>  A byte in a multi-byte UTF-8 character
I am not talking about Unicode characters here.

Thank you for your comments. In the meantime I will work (and think 
more) on the rest of them.

Regards,

Alexey
__________________________________________
Isode Limited, http://www.isode.com
__________________________________________

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 27 Oct 2003 20:03:47 +0100

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

True.  Please add '...and named rules', though.  Those are not notation
or lexical conventions.

> because it doesn't add any additional information.

Disagree.  For such readers, this comment adds a confusing reference to
a null character which they can't find elsewhere in the draft.
It might be better to just delete the sentence, though.

> Can you suggest any clarification text here?

'The server starts by sending a challenge after the client indicates
that SASL negotiatin should start'?

> suggestion how to make this clear?

Using your words,

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

> connection. This is similar to resuming a TLS session.

Oh.  Could you add 'even after closing the connection and reopening a
new one' in section 2.2?

>>>2.2.2  Step Two
>>>    
>>>   If the response is valid, (...)
>>
> (...)

Thanks.

> So I am not sure where have you found this.

It's in
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-02.txt.

>>> (...)

Not in the published draft.  There, this sentence occurs in section
2.2.2.  But there is no section between 2.2.2 and 2.4, so I guess this
part of the published draft got garbled.

> I actually disagree in this case. A byte has 8 bits by definition.

No it hasn't.  That's why the term 'octet' was invented.  A byte is an
addressable machine unit, which is _usually_ 8 bits nowadays.

> I am not talking about Unicode characters here.

A 'character' is part of a character set.  Which character set is it
supposed to be part of here, if not UTF-8?

Maybe you are thinking of C, where the 'byte' type is called (unsigned)
char?

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 26 Oct 2003 20:31:46 +0000

Yes, I was lazy.

7 implies 7.2.

Ok.

Yes.

Ok.

Fixed, thanks.

Regards,

Alexey

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 27 Oct 2003 20:03:47 +0100

Using your words,

Thanks.

It's in

-- 
Hallvard