Subject: Using a SM2 like framework to implement protection layers

From: Simon Josefsson <[email-masked]>
Date: Sun, 29 Sep 2002 05:12:09 +0200

Would it be possible, and a good idea, to use SM2 (or a similar
framework) to implement protection layers (integrity and/or
confidentiality) including key derivation for SASL mechanisms which
negotiates or share keys but do not describe a protection layer?

It could be a cheap way to get protection layers for SASL mechanisms
such as CRAM-MD5 or 9798-* that doesn't describe how the security
layer should be implemented, but negotiates or share keys that can be
used.  It would also reduce implementation pain when implementing
multiple SASL mechanisms with protection layers (it is rather daunting
to implement a protection layer for DIGEST-MD5, SRP etc which are
rather similar).  Perhaps SRP could be made to use the framework,
unless it is too late.  Or perhaps it is impossible to design a
generic framework for this due to too big differences in how different
SASL mechanisms works.

---

From: Keith Burdis <[email-masked]>
Date: Sun, 29 Sep 2002 19:26:57 +0000

On Sunday 29 September 2002 03:12, Simon Josefsson wrote:
> It could be a cheap way to get protection layers for SASL
> mechanisms such as CRAM-MD5 or 9798-* that doesn't describe how the
> security layer should be implemented, but negotiates or share keys
> that can be used.  It would also reduce implementation pain when
> implementing multiple SASL mechanisms with protection layers (it is
> rather daunting to implement a protection layer for DIGEST-MD5, SRP
> etc which are rather similar).  Perhaps SRP could be made to use
> the framework, unless it is too late.  Or perhaps it is impossible
> to design a generic framework for this due to too big differences
> in how different SASL mechanisms works.

It may be useful to have a means of adding a security layer to those 
mechanisms that do not provide one. I'd be interested is seeing a 
draft that proposes a means of doing this.

However, I don't think that it is a good idea to try to take the 
security layer out of those mechanisms that provide one. The 
negotiation of the features of the security layer is tied up in the 
workings of the mechanisms and it would not be easy to separate it 
out. 

As for SM2, I think that it should continue to just be a simple means 
of allowing the re-use of SASL sessions. Its existence is the main 
reason that the SRP-SASL mechanism does not provide any means for 
session reuse itself. I'd like to see other mechanisms adopting it 
for this purpose too.

  - Keith

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 29 Sep 2002 05:12:09 +0200

---

From: Keith Burdis <[email-masked]>
Date: Sun, 29 Sep 2002 19:26:57 +0000

- Keith

From: Keith Burdis <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Using a SM2 like framework to implement protection layers
Date: Sun, 29 Sep 2002 19:26:57 +0000
Sender: [email-masked]

  - Keith

To: [email-masked]
Subject: Using a SM2 like framework to implement protection layers
From: Simon Josefsson <[email-masked]>
Date: Sun, 29 Sep 2002 05:12:09 +0200
Lines: 15
Sender: [email-masked]

Date: Tue, 24 Sep 2002 15:29:38 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: CRAM-MD5 comments
Sender: [email-masked]

Simon Josefsson wrote:

[skip]

> >> 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.
> >
> > I wouldn't call this change incompatible, as RFC 2095 was underspecified in this
> > respect.
>
> I think it would be incompatible if someone is using CRAM-MD5 with
> 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.

> >> +     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.
> >
> > I don't think this comment belongs to CRAM-MD5. SASL document is a better place for it
> > (if at all).
>
> 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).

I like this better.

Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

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

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

To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: CRAM-MD5 comments
From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Sep 2002 12:53:21 +0200
Lines: 38
Sender: [email-masked]

Thanks for your feedback, answers inline below.

Alexey Melnikov <[email-masked]> writes:

>> 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.
>
> This change should be applied to all existing SASL mechanisms, so I would rather if
> somebody else can comment on this.

Yes, it seems it was a general comment.

>> 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.
>
> I wouldn't call this change incompatible, as RFC 2095 was underspecified in this
> respect.

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

>> +     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.
>
> I don't think this comment belongs to CRAM-MD5. SASL document is a better place for it
> (if at all).

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: "Raif S. Naffah" <[email-masked]>
To: SASL WG <[email-masked]>
Subject: UNICODE normalisation. was: CRAM-MD5 comments
Date: Tue, 24 Sep 2002 20:11:32 +1000
Sender: [email-masked]

On Tue, 24 Sep 2002 08:49, Alexey Melnikov wrote:
> Simon Josefsson wrote:
> > Alexey Melnikov <[email-masked]> writes:
> > > CRAM-MD5 is ready for last call...
> >
> > 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.
>
> 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

Date: Mon, 23 Sep 2002 16:49:43 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Simon Josefsson <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: CRAM-MD5 comments
Sender: [email-masked]

Simon Josefsson wrote:

> Alexey Melnikov <[email-masked]> writes:
>
> > CRAM-MD5 is ready for last call
>
> I don't think it is.

Ok, maybe I was a bit optimistic.

>  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.

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

> 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.

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

Some comments regarding your diff below:

> --- 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.

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

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

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

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

To: SASL WG <[email-masked]>
Subject: CRAM-MD5 comments
From: Simon Josefsson <[email-masked]>
Date: Mon, 23 Sep 2002 12:07:33 +0200
Lines: 139
Sender: [email-masked]

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.

Date: Fri, 20 Sep 2002 03:59:32 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Kurt D. Zeilenga" <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Meeting in Atlanta
Sender: [email-masked]

"Kurt D. Zeilenga" wrote:

> At 07:12 AM 2002-09-19, Alexey Melnikov wrote:
>
> >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).

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
> documents is far more important than formation of a WG.

It can be both, assuming people are interested.

> >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.
>
> 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)?

Sounds like a good idea.

Cheers,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK
Home Page: http://orthanc.ab.ca/mel

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

Date: Thu, 19 Sep 2002 12:52:03 -0700
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Meeting in Atlanta
Cc: SASL WG <[email-masked]>
Sender: [email-masked]

At 07:12 AM 2002-09-19, Alexey Melnikov wrote:

>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.

>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.

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: "Raif S. Naffah" <[email-masked]>
To: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Meeting in Atlanta
Date: Fri, 20 Sep 2002 05:35:37 +1000
Sender: [email-masked]

On Fri, 20 Sep 2002 00:12, Alexey Melnikov wrote:
> Is there enough interest to have a BOF meeting in Atlanta?
> ...
> Other documents of potential interest:
> ...
> 2). Add your item here.

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

cheers;
rsn

Date: Thu, 19 Sep 2002 08:12:46 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: Meeting in Atlanta
Sender: [email-masked]

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: "Trevor Perrin" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: draft-burdis-cat-srp-sasl-07.txt
Date: Sat, 14 Sep 2002 21:37:38 -0800
Sender: [email-masked]

>From: "Raif S. Naffah" <[email-masked]>
>
>QUOTE
>         Client                             Host
>        --------                           ------
>         U, A                        -->
>                                     <--    s, B
>         H(H(N) XOR H(g) | H(U) | s | A | B | K)
>                                     -->
>                                     <--    H(A | M | K)
>
>    The values of N and g used in this protocol must be agreed upon by
>    the two parties in question.  They can be set in advance, or the host
>    can supply them to the client.  In the latter case, the host should
>    send the parameters in the first message along with the salt...
>UNQUOTE
>
>if N and g are negotiated, as it is the case in our draft, then the 
>exchange
>becomes:
>
>    Client     Host
>    ------     ------
>    U     -->
>          <--  N,g,s
>    A     -->
>          <--  B
>    M1    -->
>          <--  M2
>

Right, which undoes the optimization the protocol diagram at the end of 
section 3 was demonstrating.  But this is a quibble, I'm sorry I brought it 
up, I think the text is fine as stands.

Trevor

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

From: "Raif S. Naffah" <[email-masked]>
To: "Trevor Perrin" <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-07.txt
Date: Sun, 15 Sep 2002 15:20:26 +1000
Cc: [email-masked], [email-masked]
Sender: [email-masked]

hello Trevor,

On Sun, 15 Sep 2002 12:32, Trevor Perrin wrote:
> From: "Raif S. Naffah" <[email-masked]>
>
> >nevertheless, since this wording in the draft is now clearly ambiguous,
> >i therefore suggest we remove it from the next iteration; i.e. the
> >paragraph in question in "1. Introduction" would then becomes:
> >
> >"The mechanism described herein is based on the SRP protocol described
> >at the end of section 3 in [RFC-2945]..."
>
> Hi Raif,
>
> I still think that's wrong.  The protocol described at the end of section 3
> in RFC 2945 is clearly "optimized" in the sense I decribed, which
> corresponds with Tom's use of the term "optimized" in the SRP paper (see
> Table 5 vs. Table 6):
> http://www-cs-students.stanford.edu/~tjw/srp/ndss.html
>
> The protocol in your draft is not optimized in this sense.  So the text in
> question should not refer to "the end of section 3".

the end of section 3 in RFC-2945 states:
QUOTE
        Client                             Host
       --------                           ------
        U, A                        -->
                                    <--    s, B
        H(H(N) XOR H(g) | H(U) | s | A | B | K)
                                    -->
                                    <--    H(A | M | K)

   The values of N and g used in this protocol must be agreed upon by
   the two parties in question.  They can be set in advance, or the host
   can supply them to the client.  In the latter case, the host should
   send the parameters in the first message along with the salt...
UNQUOTE

if N and g are negotiated, as it is the case in our draft, then the exchange
becomes:

   Client     Host
   ------     ------
   U     -->
         <--  N,g,s
   A     -->
         <--  B
   M1    -->
         <--  M2

given the above, does anybody else think that the new wording: "The mechanism
described herein is based on the SRP protocol described at the end of section
3 in [RFC-2945]..." is unclear, misleading or untrue?

cheers;
rsn

From: "Trevor Perrin" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: draft-burdis-cat-srp-sasl-07.txt
Date: Sat, 14 Sep 2002 18:32:42 -0800
Sender: [email-masked]

>From: "Raif S. Naffah" <[email-masked]>
>
>nevertheless, since this wording in the draft is now clearly ambiguous,
>i therefore suggest we remove it from the next iteration; i.e. the
>paragraph in question in "1. Introduction" would then becomes:
>
>"The mechanism described herein is based on the SRP protocol described
>at the end of section 3 in [RFC-2945]..."
>

Hi Raif,

I still think that's wrong.  The protocol described at the end of section 3 
in RFC 2945 is clearly "optimized" in the sense I decribed, which 
corresponds with Tom's use of the term "optimized" in the SRP paper (see 
Table 5 vs. Table 6):
http://www-cs-students.stanford.edu/~tjw/srp/ndss.html

The protocol in your draft is not optimized in this sense.  So the text in 
question should not refer to "the end of section 3".

Trevor

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Date: Sun, 15 Sep 2002 10:22:29 +1000
From: "Raif S. Naffah" <[email-masked]>
To: Trevor Perrin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-burdis-cat-srp-sasl-07.txt
Sender: [email-masked]

hello Trevor,

Trevor Perrin wrote:
|> From: "Raif S. Naffah" <[email-masked]>
|>> Trevor Perrin wrote:
|>>
|>> ...the Introduction says that this draft is based on the optimized
|>> SRP protocol from RFC 2945, but it isn't...
|>
|> it isn't?...
|
| The "optimized" SRP protocol in RFC 2945 has...
| Your protocol follows the "unoptimized" SRP protocol from RFC 2945...

i went and re-read carefully both rfc-2945 and Tom's paper (the [SRP]
reference in the draft).  the _optimisation_ is related to the
computation _and_ sending of the parameter "u," not the negotiation /
sending of the "N" and "g" parameters.

nevertheless, since this wording in the draft is now clearly ambiguous,
i therefore suggest we remove it from the next iteration; i.e. the
paragraph in question in "1. Introduction" would then becomes:

"The mechanism described herein is based on the SRP protocol described
at the end of section 3 in [RFC-2945]..."

which was the original intent.

cheers;
rsn

From: "Trevor Perrin" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: draft-burdis-cat-srp-sasl-07.txt
Date: Sat, 14 Sep 2002 13:49:08 -0800
Sender: [email-masked]

>From: "Raif S. Naffah" <[email-masked]>
>
>>Also, the Introduction says that this draft is based on the optimized SRP 
>>protocol from RFC 2945, but it isn't, that statement is probably just left 
>>over from a previous draft and should be struck.
>
>it isn't?  could you be more specific and point out where it is
>misleading/ambiguous; TIA.
>

The "optimized" SRP protocol in RFC 2945 has the client send the A value in 
the same message as U, and has the server send the B value in the same 
message as s:

C->S: U,A
C<-S: s,B

Your protocol follows the "unoptimized" SRP protocol from RFC 2945:

C->S: U
S<-C: s
C->S: A
S<-C: B

Nothing wrong with that, just adds a round trip, and in fact since you 
assume that g,N aren't known by prior agreement, but must be sent along with 
s, you probably need to use the unoptimized version, since the Client 
doesn't yet know the g,N to use for computing A when sending U.

An alternative would be to allow the client to guess at a default value of 
g,N and send a tentative A value along with g,N, on its U message.  If the 
server accepts the client's g,N than it returns B on its next message, thus 
using the optimized version, otherwise the server ignores the client's A and 
returns its choice for g,N, thus using the unoptimized version..

Whether trimming a roundtrip in some cases is worth this much effort, I 
dunno, but its something I proposed to the TLS/SRP effort as well.

Trevor

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Date: Sat, 14 Sep 2002 13:35:27 +1000
From: "Raif S. Naffah" <[email-masked]>
To: Trevor Perrin <[email-masked]>
Cc: [email-masked], Keith Burdis <[email-masked]>
Subject: Re: draft-burdis-cat-srp-sasl-07.txt
Sender: [email-masked]

hello Trevor,

Trevor Perrin wrote:
|
| Hi Keith and Raif,
|
| couple comments on this draft.  From RFC 2945:
|   The client MUST abort authentication if B % N is zero.
|   The host MUST abort the authentication attempt if A % N is zero...

noted.  we'll add these in the next iteration of the document.

| Also, the Introduction says that this draft is based on the optimized
| SRP protocol from RFC 2945, but it isn't, that statement is probably
| just left over from a previous draft and should be struck.

it isn't?  could you be more specific and point out where it is
misleading/ambiguous; TIA.

| Trevor

thanks for taking the time to review and help clarify the specifications
+ cheers;
rsn

From: "Trevor Perrin" <[email-masked]>
To: [email-masked]
Subject: draft-burdis-cat-srp-sasl-07.txt
Date: Fri, 13 Sep 2002 15:54:02 -0800
Sender: [email-masked]

Hi Keith and Raif,

couple comments on this draft.  From RFC 2945:
   The client MUST abort authentication if B % N is zero.
   The host MUST abort the authentication attempt if A % N is zero.

These checks are extremely important (see the "Constraint checks" section of 
Tom Wu's SRP paper).  You should mention them in your draft, and give them 
some emphasis, cause this is a likely thing for implementors to omit.

Also, the Introduction says that this draft is based on the optimized SRP 
protocol from RFC 2945, but it isn't, that statement is probably just left 
over from a previous draft and should be struck.

Trevor

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com