Subject: Personal notes from unofficial SASL meeting at Salt-Lake City

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Dec 2001 22:47:34 -0700

Comments/corrections/additions are welcome.
====
6 of us gathered at Salt-Lake to discuss outstanding issues.

Base SASL spec:

1). John showed a new text that should address the issue of character
set for authentication/authorization ids and passwords.
He proposed: Unicode with NUL character excluded. SASL mechanisms SHOULD
use UTF-8 to encode Unicode.

Also John noted that there is an issue of how to encode passwords with
characters from Unicode (that is likely to be an issue for Europe). John
will include new text in the next revision of SASL draft.

John also suggested that clients MUST use Unicode Normalization Form KC
and servers MAY check this.
This probably requires more discussion on the mailing list.

The question of binary authentication/authorization id (e.g. BER
encoding of a name) was also discussed, but the group agreed that a
protocol profile can describe how to encode them before passing to a
SASL mechanism.

2). John added more text about authorization id and proxy
authentication.

3). I've asked John to add non-normative reference to SM2.
John should add some text that says that a future document may define
how to write mechanisms that support reauthentication.

======================================
CRAM-MD5:

1). Specify that Unicode Normalization Form KC is used for userids and
password (NUL character is not allowed), encoded as UTF-8.

2). ABNF for challenge string: can we relax syntax to be a random string
from 0..9,a..z,... repertoire?
John agreed that client has no reason to verify the syntax of challenge,
so this is probably Ok.
We have to double check with ADs.
======================================
DIGEST-MD5:

[Chris Newman wasn't present, but I talked to him later during the IETF
week .]

1). Chris Newman promised to submit a revision in a couple of weeks.
Collected set of issues [attached] from John, Larry and myself was sent
to Chris.

2). Add AES cipher as separate document.
 I will submit the new draft shortly after IETF.

======================================
GSSAPI:

1). Move base-32 out of the document?

 John agreed to do that

2). Why generation of GSSAPI mechanism name is so complex?

 Do we really need ASN1?

 From GSSAPI C-Binding:

   typedef struct gss_OID_desc_struct {
      OM_uint32   length;
      void        *elements;
   } gss_OID_desc, *gss_OID;

   The elements field of this structure points to the ***first byte of
an
   octet string containing the ASN.1 BER encoding*** of the value
portion
   of the normal BER TLV encoding of the gss_OID.

3). How to list of GSSAPI mechanisms using GSSAPI?
 Server either has to know SASL names of all GSSAPI mechanisms it
supports or it can use gss_indicate_mechs that returns list of OIDs for
supported mechanisms.
John will add a reference to this function.

4). We've spent some time talking about the correct list of OIDs that
correspond to Kerberos V5 mechanism. Also Larry raised a question about
cipher negotiation and Kerberos V5.
Tom Yu from MIT clarified things by explaining that K5 mechanism allows
for DES and 3DES ciphers and that any new cipher (like AES) will force a
new OID. Tom also pointed out that there is a bug in OID for Kerberos
described in one of the Kerberos V5 RFCs [I forgot which one].

GSSAPI document should be ready for Last Call.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

1). Security considerations:
 How does DIGEST-MD5 protect against downgrade of maxbuf, qop, qop-options?

2). Security considerations? :
  Ciphers can't have keys longer than 128 bit (i.e. length of MD5 output) [e.g. aes-192]
  128 bit key is probably fine.

3). DES and 3DES are mandatory to implement for privacy layer, change to 3DES?

4). 
>   Kcc = MD5({H(A1)[0..n],
>   "Digest H(A1) to client-to-server sealing key magic constant"})

Change "[0..n]" to "[0..n-1]" or "[1..n]".

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

>   Kcs = MD5({H(A1)[0..n],
>   "Digest H(A1) to server-to-client sealing key magic constant"})

Change "[0..n]" to "[0..n-1]" or "[1..n]".

>   where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5;
>   for "rc4-56" n is 7; for the rest n is 16. The key for the "rc-*"

Typo "rc4-*"

>   ciphers is 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 last 8 bytes of Kcc or Kcs.

5). is the quoted or unquoted version of the username, etc. used in calculating A1?

 Unquoted!

6). Tighten the syntax of the nonce and cnonce to prohibit quoted characters.  Should be:
    nonce-value = *qdtext
    cnonce-value = *qdtext

7). fix ABNF to allow utf-8 username-value and authzid-value
    the formal syntax restricts this to TEXT or "\" CHAR.
    the charset thing makes this difficult, as iso-8859-1 can be
    allowed in the username.

 ABNF is not strict enough, because it allows any 8bit data!

8). nc-value: shouldn't it be the server aborting the exchange?

======================================
Implementation:

1). des/3des doesn't interoperate

======================================
Editorial:

1). Issues with reauthentication step:
 Put into separate draft in order not to delay base mechanism?
(i.e. Do we have two independent implementations that interoperate?).