Subject: Important of Good Server Nonces in Digest

From: Randall Gellens <[email-masked]>
Date: Tue, 9 Jul 2002 18:06:47 -0700

Can someone explain the importance of good server nonces in the 
DIGEST mechanism?  Assuming the client will be selecting a good 
client nonce (say, 128 bits of entropy from physical sources), what 
are the risks of the server nonce being simply a 32-bit timestamp (or 
an MD5 hash of a 32-bit timestamp)?

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 22 Jul 2002 15:28:53 -0400

Date: Tue, 9 Jul 2002 18:06:47 -0700
   From: Randall Gellens <[email-masked]>

If the server doesn't choose a good nonce (one that is unpredictable
and won't be reused) then it is vulnerable to a replay attack. (If I
can anticipate the server's nonce and I masquerade as the server to
the client and send that nonce, I'll be able to authenticate as that
client to the server when it sends that nonce.)

The client nonce is there to prevent various chosen plaintext attacks
on the client and to force the server to prove that it knows the
password.

Larry

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 22 Jul 2002 13:58:49 -0700

>on the client and to force the server to prove that it knows the

It is important that the nonce changes with each authentication to prevent 
a replay attack. Both server generated and time-based methods fullfill this.

It is important that the client not get to pick the nonce themselves or 
they could pick the same one every time. Both server generated and 
time-based methods fullfill this.

In terms of attacking the client man-in-middle-style by getting it to do 
the auth step on some nonce contrived to help reveal the password, I think 
there's nothing that can be done about that.

You're right that a m-i-t-m attack allows the m-i-t-m to impersonate the 
client, but it's basically the same as an IP hijack attack. The only 
prevention for that is digitally signing the data transferred.

It does NOT seem important that the nonce be unpredictable. The nonce is in 
the clear in the first place, so it isn't secret. So even though the 
time-based mode gives a predictable nonce, I don't see any problem with it.

LL

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 22 Jul 2002 18:01:08 -0400

Date: Mon, 22 Jul 2002 13:58:49 -0700
   From: Laurence Lundblade <[email-masked]>
[...]
   It is important that the client not get to pick the nonce themselves or 
   they could pick the same one every time. Both server generated and 
   time-based methods fullfill this.

You seem to be confusing DIGEST-MD5 with a different
protocol. DIGEST-MD5 has both a server chosen nonce and a client
chosen nonce.

The client chosen nonce helps to resist this attack.

[...]

As Paul Leach explained, a predictable server nonce allows for a
greater variety of active and passive attacks.

Larry

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 23 Jul 2002 10:41:14 -0700

>protocol. DIGEST-MD5 has both a server chosen nonce and a client

Yes, at least one of us was confused :-). I was thinking more about a new 
protocol design where using a time-based nonce saves half a round trip 
because if the client and server clocks are in sync both sides can know the 
nonce without it being sent.

Yes, the risks of time skew and small timing attack windows are a possible 
problem, but the risk may be acceptable for certain systems. No, this would 
not be a good thing for an IETF protocol.

Apologies for the confusion.

>The client chosen nonce helps to resist this attack.

Actually the time-based nonce helps with this too. In the time-based nonce 
the server doesn't even get to pick it.

>greater variety of active and passive attacks.

Yes, understood. Seems like it's not a horrible problem and for some 
services predictability in the nonce is an acceptable risk.

Certainly for a protocol like DIGEST where nonces are sent it protocol 
messages, using a good random number is not very hard and a good idea.

Thanks, LL

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 22 Jul 2002 15:28:53 -0400

Larry

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 22 Jul 2002 13:58:49 -0700

LL

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 22 Jul 2002 18:01:08 -0400

[...]

Larry

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 23 Jul 2002 10:41:14 -0700

Thanks, LL

Date: Tue, 23 Jul 2002 10:41:14 -0700
To: Lawrence Greenfield <[email-masked]>, Randall Gellens <[email-masked]>, [email-masked]
From: Laurence Lundblade <[email-masked]>
Subject: Re: Important of Good Server Nonces in Digest
Sender: [email-masked]

Thanks, LL

Date: Mon, 22 Jul 2002 18:01:08 -0400
From: Lawrence Greenfield <[email-masked]>
To: Randall Gellens <[email-masked]>, [email-masked], Laurence Lundblade <[email-masked]>
Subject: Re: Important of Good Server Nonces in Digest
Sender: [email-masked]

[...]

Larry

Content-Class: urn:content-classes:message
Subject: RE: Important of Good Server Nonces in Digest
Date: Mon, 22 Jul 2002 14:36:23 -0700
From: "Paul Leach" <[email-masked]>
To: "Laurence Lundblade" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>, <[email-masked]>, "Randall Gellens" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C2318D.2530CC60
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0011_01C2318D.2530CC60"

------=_NextPart_001_0011_01C2318D.2530CC60
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

TIme-based nonces allow an attacker to predict the future value of a
nonce, and attack the protocol for that value of the nonce (or ones
nearby).
 
It's easy enough to make them unpredictable: MD5(time,
host-specific-secret).

-----Original Message-----
From: Laurence Lundblade [mailto:[email-masked]] 
Sent: Monday, July 22, 2002 1:59 PM
To: Lawrence Greenfield; [email-masked]; Randall Gellens
Subject: Re: Important of Good Server Nonces in Digest

It is important that the nonce changes with each authentication to
prevent a replay attack. Both server generated and time-based methods
fullfill this.

In terms of attacking the client man-in-middle-style by getting it to do
the auth step on some nonce contrived to help reveal the password, I
think there's nothing that can be done about that. 

It does NOT seem important that the nonce be unpredictable. The nonce is
in the clear in the first place, so it isn't secret. So even though the
time-based mode gives a predictable nonce, I don't see any problem with
it.

LL

Larry

------=_NextPart_001_0011_01C2318D.2530CC60
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.3660.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D062533321-22072002><FONT face=3DArial color=3D#0000ff =

size=3D2>TIme-based nonces allow an attacker to predict the future value =
of a=20
nonce, and attack the protocol for that value of the nonce (or ones=20
nearby).</FONT></SPAN></DIV>
<DIV><SPAN class=3D062533321-22072002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D062533321-22072002><FONT face=3DArial color=3D#0000ff =
size=3D2>It's=20
easy enough to make them unpredictable: MD5(time,=20
host-specific-secret).</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Laurence=20
  Lundblade [mailto:[email-masked]] <BR><B>Sent:</B> Monday, July 22, =
2002=20
  1:59 PM<BR><B>To:</B> Lawrence Greenfield; [email-masked]; Randall=20
  Gellens<BR><B>Subject:</B> Re: Important of Good Server Nonces in=20
  Digest<BR><BR></FONT></DIV>At 03:28 PM 7/22/2002 -0400, Lawrence =
Greenfield=20
  wrote:<BR><BR>
  <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite">&nbsp;&nbsp; Date: =
Tue, 9 Jul=20
    2002 18:06:47 -0700<BR>&nbsp;&nbsp; From: Randall Gellens=20
    &lt;[email-masked]&gt;<BR><BR>&nbsp;&nbsp; Can someone explain =
the=20
    importance of good server nonces in the <BR>&nbsp;&nbsp; DIGEST=20
    mechanism?&nbsp; Assuming the client will be selecting a good=20
    <BR>&nbsp;&nbsp; client nonce (say, 128 bits of entropy from =
physical=20
    sources), what <BR>&nbsp;&nbsp; are the risks of the server nonce =
being=20
    simply a 32-bit timestamp (or <BR>&nbsp;&nbsp; an MD5 hash of a =
32-bit=20
    timestamp)?<BR><BR>If the server doesn't choose a good nonce (one =
that is=20
    unpredictable<BR>and won't be reused) then it is vulnerable to a =
replay=20
    attack. (If I<BR>can anticipate the server's nonce and I masquerade =
as the=20
    server to<BR>the client and send that nonce, I'll be able to =
authenticate as=20
    that<BR>client to the server when it sends that nonce.)<BR><BR>The =
client=20
    nonce is there to prevent various chosen plaintext attacks<BR>on the =
client=20
    and to force the server to prove that it knows=20
  the<BR>password.</BLOCKQUOTE><BR><BR>It is important that the nonce =
<I>changes=20
  </I>with each authentication to prevent a replay attack. Both server =
generated=20
  and time-based methods fullfill this.<BR><BR>It is important that the=20
  <I>client not get to pick the nonce</I> themselves or they could pick =
the same=20
  one every time. Both server generated and time-based methods fullfill=20
  this.<BR><BR>In terms of attacking the client man-in-middle-style by =
getting=20
  it to do the auth step on some nonce contrived to help reveal the =
password, I=20
  think there's nothing that can be done about that. <BR><BR>You're =
right that a=20
  m-i-t-m attack allows the m-i-t-m to impersonate the client, but it's=20
  basically the same as an IP hijack attack. The only prevention for =
that is=20
  digitally signing the data transferred.<BR><BR>It does NOT seem =
important that=20
  the nonce be unpredictable. The nonce is in the clear in the first =
place, so=20
  it isn't secret. So even though the time-based mode gives a =
predictable nonce,=20
  I don't see any problem with it.<BR><BR>LL<BR><BR>
  <BLOCKQUOTE class=3Dcite cite=3D""=20
type=3D"cite">Larry</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_0011_01C2318D.2530CC60--

------=_NextPart_000_0010_01C2318D.2530CC60
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0010_01C2318D.2530CC60--

Date: Mon, 22 Jul 2002 13:58:49 -0700
To: Lawrence Greenfield <[email-masked]>, [email-masked], Randall Gellens <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: Important of Good Server Nonces in Digest
Sender: [email-masked]

--=====================_-1888558794==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

LL

>Larry

--=====================_-1888558794==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 03:28 PM 7/22/2002 -0400, Lawrence Greenfield wrote:<br><br>
<blockquote type=cite class=cite cite>&nbsp;&nbsp; Date: Tue, 9 Jul 2002
18:06:47 -0700<br>
&nbsp;&nbsp; From: Randall Gellens &lt;[email-masked]&gt;<br><br>
&nbsp;&nbsp; Can someone explain the importance of good server nonces in
the <br>
&nbsp;&nbsp; DIGEST mechanism?&nbsp; Assuming the client will be
selecting a good <br>
&nbsp;&nbsp; client nonce (say, 128 bits of entropy from physical
sources), what <br>
&nbsp;&nbsp; are the risks of the server nonce being simply a 32-bit
timestamp (or <br>
&nbsp;&nbsp; an MD5 hash of a 32-bit timestamp)?<br><br>
If the server doesn't choose a good nonce (one that is 
unpredictable<br>
and won't be reused) then it is vulnerable to a replay attack. (If 
I<br>
can anticipate the server's nonce and I masquerade as the server to<br>
the client and send that nonce, I'll be able to authenticate as 
that<br>
client to the server when it sends that nonce.)<br><br>
The client nonce is there to prevent various chosen plaintext
attacks<br>
on the client and to force the server to prove that it knows the<br>
password.</blockquote><br><br>
It is important that the nonce <i>changes </i>with each authentication to
prevent a replay attack. Both server generated and time-based methods
fullfill this.<br><br>
It is important that the <i>client not get to pick the nonce</i>
themselves or they could pick the same one every time. Both server
generated and time-based methods fullfill this.<br><br>
In terms of attacking the client man-in-middle-style by getting it to do
the auth step on some nonce contrived to help reveal the password, I
think there's nothing that can be done about that. <br><br>
You're right that a m-i-t-m attack allows the m-i-t-m to impersonate the
client, but it's basically the same as an IP hijack attack. The only
prevention for that is digitally signing the data transferred.<br><br>
It does NOT seem important that the nonce be unpredictable. The nonce is
in the clear in the first place, so it isn't secret. So even though the
time-based mode gives a predictable nonce, I don't see any problem with
it.<br><br>
LL<br><br>
<blockquote type=cite class=cite cite>Larry</blockquote></html>

--=====================_-1888558794==_.ALT--

Date: Mon, 22 Jul 2002 15:28:53 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], Randall Gellens <[email-masked]>
Subject: Re: Important of Good Server Nonces in Digest
Sender: [email-masked]

Larry

Date: Tue, 9 Jul 2002 18:06:47 -0700
To: [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Important of Good Server Nonces in Digest
Sender: [email-masked]

Date: Fri, 05 Jul 2002 06:05:29 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Simon Josefsson <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION: draft-nerenberg-sasl-crammd5-02.txt
Sender: [email-masked]

Simon Josefsson wrote:

> Alexey Melnikov <[email-masked]> writes:
>
> > Simon Josefsson wrote:
> >
> >> I also note that the use of Unicode NFKC normalization in the
> >> specification makes it incompatible with all existing CRAM-MD5
> >> implementations I've looked at.
> >
> > Can you tell more about these implementations? How do they send non-ASCII
> > usernames and/or passwords?
>
> They encode them using the local character set, it seems.

...and as CRAM-MD5 didn't specify a charset, they don't (and will not)
interoperate anyway.
So this is not an issue. (Note, that this is not an argument for NFKC in
particular).

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

To: Alexey Melnikov <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION: draft-nerenberg-sasl-crammd5-02.txt
From: Simon Josefsson <[email-masked]>
Date: Fri, 05 Jul 2002 13:01:32 +0200
Lines: 12
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Simon Josefsson wrote:
>
>> I also note that the use of Unicode NFKC normalization in the
>> specification makes it incompatible with all existing CRAM-MD5
>> implementations I've looked at.
>
> Can you tell more about these implementations? How do they send non-ASCII
> usernames and/or passwords?

They encode them using the local character set, it seems.

Date: Fri, 05 Jul 2002 04:48:59 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Simon Josefsson <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION: draft-nerenberg-sasl-crammd5-02.txt
Sender: [email-masked]

Simon Josefsson wrote:

> I also note that the use of Unicode NFKC normalization in the
> specification makes it incompatible with all existing CRAM-MD5
> implementations I've looked at.

Can you tell more about these implementations? How do they send non-ASCII
usernames and/or passwords?

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

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION: draft-nerenberg-sasl-crammd5-02.txt
From: Simon Josefsson <[email-masked]>
Date: Fri, 05 Jul 2002 12:21:38 +0200
Lines: 24
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:

> At 07:32 AM 2002-07-04, Simon Josefsson wrote:
>
>>This leads to having words like "Masse" and "Maße" treated as the same
>>user identity or password, I'm not sure that is a good idea.
>
> IMO, It's better than having them treated as being different...
> (considering that the user may switch to input devices
> not capable of generating the ß.

ß is a special case, most non-ASCII characters are not normalized into
ASCII characters in stringprep.  E.g., å is not.

> Anyways, we have a significant interoperability problem with
> different implementations comparing identities and passwords
> differently.  We must explicitly define how this is to be done
> for each mechanism.  My suggestion is that we define a SASL
> string profile which mechanisms should utilize.

I guess it is the way most protocol are heading, so perhaps it is a
good idea.  Wouldn't this prohibit binary authentication/authorization
identities and passwords though?  I remember some discussions earlier
if identities and passwords were supposed to be binary clean or not.

Date: Thu, 04 Jul 2002 21:57:42 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION: draft-nerenberg-sasl-crammd5-02.txt
Cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
Sender: [email-masked]

At 07:32 AM 2002-07-04, Simon Josefsson wrote:

>This leads to having words like "Masse" and "Maße" treated as the same
>user identity or password, I'm not sure that is a good idea.

IMO, It's better than having them treated as being different...
(considering that the user may switch to input devices
not capable of generating the ß.

Anyways, we have a significant interoperability problem with
different implementations comparing identities and passwords
differently.  We must explicitly define how this is to be done
for each mechanism.  My suggestion is that we define a SASL
string profile which mechanisms should utilize.

Kurt

>I also note that the use of Unicode NFKC normalization in the
>specification makes it incompatible with all existing CRAM-MD5
>implementations I've looked at.
>
>"Kurt D. Zeilenga" <[email-masked]> writes:
>
>> It might be appropriate for 2222bis to provide a SASL
>> string profile(s) [draft-hoffman-stringprep] for
>> authentication identities, authorization identities,
>> and passwords which mechanisms can reference as needed.
>>
>> Kurt
>>
>>
>> At 07:28 AM 2002-06-23, Simon Josefsson wrote:
>>
>>>Lyndon Nerenberg <[email-masked]> writes:
>>>
>>>> This version was pushed to replace the about-to-expire -01 draft;
>>>> there are no changes to the content from the -01 version.
>>>>
>>>> I haven't received any comments since the publication of -01,
>>>> therefore I plan to submit this for last call a few days after the
>>>> upcoming IETF meeting ends.
>>>
>>>I have two comments regarding the use of Unicode NFKC normalization:
>>>
>>>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]
>>>
>>>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, but
>>>hopefully that is mostly academic.

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION: draft-nerenberg-sasl-crammd5-02.txt
From: Simon Josefsson <[email-masked]>
Date: Thu, 04 Jul 2002 16:32:15 +0200
Lines: 89
Sender: [email-masked]

This leads to having words like "Masse" and "Maße" treated as the same
user identity or password, I'm not sure that is a good idea.

I also note that the use of Unicode NFKC normalization in the
specification makes it incompatible with all existing CRAM-MD5
implementations I've looked at.

"Kurt D. Zeilenga" <[email-masked]> writes:

> It might be appropriate for 2222bis to provide a SASL
> string profile(s) [draft-hoffman-stringprep] for
> authentication identities, authorization identities,
> and passwords which mechanisms can reference as needed.
>
> Kurt
>
>
> At 07:28 AM 2002-06-23, Simon Josefsson wrote:
>
>>Lyndon Nerenberg <[email-masked]> writes:
>>
>>> This version was pushed to replace the about-to-expire -01 draft;
>>> there are no changes to the content from the -01 version.
>>>
>>> I haven't received any comments since the publication of -01,
>>> therefore I plan to submit this for last call a few days after the
>>> upcoming IETF meeting ends.
>>
>>I have two comments regarding the use of Unicode NFKC normalization:
>>
>>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]
>>
>>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, but
>>hopefully that is mostly academic.

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nystrom-http-sasl-03.txt
Date: Wed, 03 Jul 2002 06:29:47 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SASL in HTTP/1.1
	Author(s)	: M. Nystrom, R. Zuccherato, A. Melnikov
	Filename	: draft-nystrom-http-sasl-03.txt
	Pages		: 20
	Date		: 02-Jul-02
	
This memo suggest the use of SASL [RFC2222] as a framework to enable
the use of strong authentication mechanisms in http/1.1 [RFC2616],
and defines one approach to accomplish this.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nystrom-http-sasl-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-nystrom-http-sasl-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-nystrom-http-sasl-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-nystrom-http-sasl-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--