Subject: Meeting in Atlanta

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Sep 2002 08:12:46 -0600

Is there enough interest to have a BOF meeting in Atlanta?
Proposed items of interest (from the top of my head):

1). DIGEST-MD5 remaining issues and AES cipher document
2). [the very last round] of GSSAPI talks.
2). SRP

CRAM-MD5 is ready for last call, I don't think there is much to discuss
about PLAN and ANONYMOUS mechanisms.

Other documents of potential interest:
1). HTTP SASL (I hope there will be no more than two iterations on this
document before it is ready for last call. HTTP expert feedback is
required urgently!)
2). Add your item here.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel

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

---

From: "Raif S. Naffah" <[email-masked]>
Date: Fri, 20 Sep 2002 05:35:37 +1000

On Fri, 20 Sep 2002 00:12, Alexey Melnikov wrote:
> ...
> ...

i would've added SM2, but i won't be there to present/promote/defend it :-(

cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 19 Sep 2002 12:52:03 -0700

>Is there enough interest to have a BOF meeting in Atlanta?

I assume you mean a Bar BOF since the proposed agenda looks
to be technical discussion and not a charter discussion (which
is what BOFs are for).  That's fine...  progress with the
documents is far more important than formation of a WG.

>document before it is ready for last call. HTTP expert feedback is

RFC 2222bis issues?  Or, if no issues, maybe we should have a
mailing list last call before recommending it (as an individual
submission) to the IESG (and subsequent 4-week IETF-wide last
call)?

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 20 Sep 2002 03:59:32 -0600

"Kurt D. Zeilenga" wrote:

> is what BOFs are for).

I don't care if it is bar BOF or not, but I want to have an allocated slot
(or just time) so people can plan to attend.

>  That's fine...  progress with the

It can be both, assuming people are interested.

> submission) to the IESG (and subsequent 4-week IETF-wide last

Sounds like a good idea.

Cheers,
Alexey Melnikov
Watford, UK

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 23 Sep 2002 12:07:33 +0200

Alexey Melnikov <[email-masked]> writes:

> CRAM-MD5 is ready for last call

I don't think it is.  I'm reposting my suggestions for CRAM-MD5, and
adding a couple more.  As I am not that familiar with CRAM-MD5, I
would appreciate if more knowledgable eyes looked at my suggested
changes (some might be controversal).

The use of normalized Unicode may also be achieved by referencing
draft-hoffman-stringprep-05 instead.  To me, it seems like a better
approach, but it may hold up the document waiting for that document to
be published.

0) It is not clear that the document obsoletes parts of RFC 2095
   (which is registered on the IANA SASL page as the reference for
   CRAM-MD5).  This should be noted and the incompatible changes
   should too.  One of the incompatible changes is that usernames nor
   passwords can be arbitrary binary strings anymore.

--- draft-nerenberg-sasl-crammd5-02.txt.orig	2002-06-17 20:01:40.000000000 +0200
+++ draft-nerenberg-sasl-crammd5-02.txt	2002-09-23 11:55:03.000000000 +0200
@@ -49,6 +49,14 @@
      This document defines a simple challenge-response [SASL] authenti-
      cation mechanism, using a [KEYED-MD5] digest.
 
+     This document obsoletes CRAM-MD5 as described in [IMAP-AUTH].
+     The change requires that the username and password must be
+     represented and processed in a certain way.  This is backwards
+     compatible for ASCII username and passwords, and makes the
+     standard interoperable for non-ASCII username and passwords.
+     However, as a consequence the use of binary clear usernames or
+     passwords are effectively prohibited.
+
 3.  CRAM-MD5 Authentication Mechanism
 
      The mechanism name associated with CRAM-MD5 is 'CRAM-MD5'.
@@ -227,6 +237,10 @@
      [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
      4rev1," RFC 2060, University of Washington, December 1996.
 
+     [IMAP-AUTH] Klensin, J., Catoe, R., Krumviede, P., "IMAP/POP
+     AUTHorize Extension for Simple Challenge/Response,", RFC 2095,
+     MCI, January 1997.
+
 5.  Security Considerations 
@@ -310,7 +324,12 @@
 Internet Draft           CRAM-MD5 SASL Mechanism               June 2002

-6.  Authors' Addresses
+6.  IANA Considerations
+
+     The IANA is asked to update the reference for the CRAM-MD5
+     SASL mechanism to point at this document.
+
+7.  Authors' Addresses
 
      John C. Klensin
      MCI Telecommunications

      It is conjectured that use of the CRAM-MD5 authentication mechanism

1) It can be made more clear that using other normalization tables
   than the one referenced may result in interoperability problems:

--- draft-nerenberg-sasl-crammd5-02.txt.orig	Mon Jun 17 20:01:40 2002
+++ draft-nerenberg-sasl-crammd5-02.txt	Sun Jun 23 16:21:13 2002
@@ -87,7 +87,11 @@
      The user name and shared secret MUST be represented in the Unicode
      character set [UNICODE], and MUST be normalised using the Unicode
      Normalisation Form KC [NFKC]. The resulting values MUST be encoded
-     as UTF-8 [UTF8].
+     as UTF-8 [UTF8].  An application MUST NOT use newer normalization
+     tables even when such are available because it is not possible to
+     know if the other protocol entity also utilizes these newer tables.
+     This includes any Unicode normalization erratas that may be issued
+     in the future.

 3.1.  Formal Syntax

2) Update CRAM-MD5 to use Unicode 3.2. According to
   http://www.imc.org/idn/mail-archive/msg06650.html there was one
   backwards incompatible change in the NFKC normalization tables
   between 3.1 and 3.2, it could be good to use the latest version to
   support that character properly.

--- draft-nerenberg-sasl-crammd5-02.txt.orig	Mon Jun 17 20:01:40 2002
+++ draft-nerenberg-sasl-crammd5-02.txt	Sun Jun 23 16:04:43 2002
@@ -200,8 +200,8 @@
      [NFKC]
           Davis, M., M. Durst, "Unicode Standard Annex #15: Unicode Nor-
           malisation Forms", An integral part of The Unicode Standard,
-          Version 3.1.1 (http://www.uni-
-          code.org/reports/tr15/tr15-21.html).
+          Version 3.2.0 (http://www.uni-
+          code.org/reports/tr15/tr15-22.html).

      [SASL]
@@ -210,12 +210,11 @@

      [UNICODE]
-          The Unicode Consortium, "The Unicode Standard, Version 3.1.1",
+          The Unicode Consortium, "The Unicode Standard, Version 3.2.0",
           defined by: The Unicode Standard, Version 3.0 (Reading, MA,
           Addison-Wesley, 2000.  ISBN 0-201-61633-5), as amended by the
-          Unicode Standard Annex #27: Unicode 3.1 (http://www.uni-
-          code.org/reports/tr27/) and the Unicode 3.1.1 Update Notice
-          (http://www.unicode.org/versions/ Unicode3.1.1.html).
+          Unicode Standard Annex #28: Unicode 3.2 (http://www.uni-
+          code.org/reports/tr28/tr28-3.html).

      [UTF8]

3) Perhaps one also can discuss the problem of using different
transcoding tables to convert from legacy character sets to Unicode in
clients and servers, since such tables aren't standardized.

--- draft-nerenberg-sasl-crammd5-02.txt.orig	2002-06-17 20:01:40.000000000 +0200
+++ draft-nerenberg-sasl-crammd5-02.txt	2002-09-23 11:44:23.000000000 +0200
@@ -288,11 +290,11 @@
      attacks.  An example of an increasingly common active attack is
      'TCP Session Hijacking' as described in CERT Advisory CA-95:01.
 
-
-
-
-
-
+     This framework does not describe how data is transcoded from
+     other character sets into Unicode. In systems that uses
+     non-Unicode character sets, the transcoding algorithm is a
+     critical part of enabling secure and "correct" operation of
+     CRAM-MD5.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Sep 2002 16:49:43 -0600

Simon Josefsson wrote:

> I don't think it is.

Ok, maybe I was a bit optimistic.

>  I'm reposting my suggestions for CRAM-MD5, and

This change should be applied to all existing SASL mechanisms, so I would rather if
somebody else can comment on this.

>    passwords can be arbitrary binary strings anymore.

I wouldn't call this change incompatible, as RFC 2095 was underspecified in this
respect.

> +++ draft-nerenberg-sasl-crammd5-02.txt 2002-09-23 11:44:23.000000000 +0200

I don't think this comment belongs to CRAM-MD5. SASL document is a better place for it
(if at all).

Regards,
Alexey Melnikov

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

---

From: "Raif S. Naffah" <[email-masked]>
Date: Tue, 24 Sep 2002 20:11:32 +1000

On Tue, 24 Sep 2002 08:49, Alexey Melnikov wrote:
> > > CRAM-MD5 is ready for last call...
> >
> > approach, but it may hold up the document waiting for that document
> > to be published.
>
> This change should be applied to all existing SASL mechanisms, so I
> would rather if somebody else can comment on this.

i agree with Alexey.  at least in both the SRP and the SM2 drafts the 
same change will also be applicable.

does it make sense to include, in the SASL framework, what UNICODE 
mechanisms would use _by default_ unless their authors decide 
otherwise?

draft-myers-saslrev-02.txt, section 4.4 seems to be the right place for 
this.

cheers;
rsn

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Sep 2002 12:53:21 +0200

Thanks for your feedback, answers inline below.

> somebody else can comment on this.

Yes, it seems it was a general comment.

> I wouldn't call this change incompatible, as RFC 2095 was underspecified in this

I think it would be incompatible if someone is using CRAM-MD5 with
randomly generated binary strings for username or passwords.

> I don't think this comment belongs to CRAM-MD5. SASL document is a better place for it

Agreed. Wherever the text describing Unicode processing is placed,
text such as the above should at least be considered for the security
consideration section (the text is borrowed from the IDN drafts).

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Sep 2002 15:29:38 +0100

Simon Josefsson wrote:

[skip]

> randomly generated binary strings for username or passwords.

Correct. But you can't break something that was already broken. Original CRAM-MD5 didn't
specify that binary data was allowed in the first place.

> consideration section (the text is borrowed from the IDN drafts).

I like this better.

Alexey

---

From: "Raif S. Naffah" <[email-masked]>
Date: Fri, 20 Sep 2002 05:35:37 +1000

cheers;
rsn

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 19 Sep 2002 12:52:03 -0700

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 20 Sep 2002 03:59:32 -0600

Sounds like a good idea.

Cheers,
Alexey Melnikov

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 23 Sep 2002 12:07:33 +0200

-6.  Authors' Addresses
+6.  IANA Considerations
+
 
      John C. Klensin
      MCI Telecommunications

 3.1.  Formal Syntax

      [SASL]
@@ -210,12 +210,11 @@

      [UNICODE]

      [UTF8]

 
-
-
-
-
-

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Sep 2002 16:49:43 -0600

Regards,
Alexey Melnikov

---

From: "Raif S. Naffah" <[email-masked]>
Date: Tue, 24 Sep 2002 20:11:32 +1000

cheers;
rsn

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Sep 2002 12:53:21 +0200

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Sep 2002 15:29:38 +0100

Simon Josefsson wrote:

[skip]

I like this better.

Alexey