Subject: consensus call on full stop and private use for saslprep

From: Sam Hartman <[email-masked]>
Date: Fri, 14 Nov 2003 22:00:57 -0500

It was fairly obvious at Tuesday's meeting that we did not have a
rough consensus to change the saslprep document either to map full
stops to ASCII full stop or to allow private use characters.

The saslprep document has already passed working group last call. AS
such, there is a relatively high bar to propose changes to the
document from within the working group.

Since there is no consensus to change the document, the document will
remain as is for now.

I realize several people are still actively thinking about these
issues and people are still looking at what actual input methods do in
various situations.  If this ongoing discussion reaches a consensus
before the documents are sent to the IESG, then we can act on that
consensus.

Thanks,

--Sam

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 17 Nov 2003 15:13:32 -0800

>before the documents are sent to the IESG, then we can act on that

Echoing my comments in Minneapolis, I'm fine with leaving the 
document as it stands now.

- The ideographic full stop situation is somewhat of a no-win 
situation. If we map them to periods, some Asian users will be 
surprised when they try to type the right thing. If we don't map 
them, other users will be surprised. We mapped them to periods in 
IDNA because domain names consistently use periods as separators, but 
that is not the case in SASL or Kerberos names.

- Allowing private use characters in names requires specifying many 
things about them that is way, way out of scope for IETF activities 
(such as their normalization, their right-to-left properties, and so 
on). Organizations that use private-use characters often later regret 
that they did so, particularly when they try to communicate with 
other organizations who use the same characters for something else.

The saslprep document works fine as it is.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 17 Nov 2003 15:13:32 -0800

--Paul Hoffman, Director

Date: Mon, 17 Nov 2003 15:13:32 -0800
To: Sam Hartman <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: consensus call on full stop and private use for saslprep
Sender: [email-masked]

--Paul Hoffman, Director

Date: Fri, 14 Nov 2003 23:31:35 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms
Sender: [email-masked]

On Fri, 14 Nov 2003, Sam Hartman wrote:

> New protocol profiles SHOULd require servers to make the list of SASL
> mechanisms available for the initial authentication available to the
> client after security layers are established.  Some older protocols do
> not require this; for these protocols clients MUST NOT treat  an empty
> list of SASL mechanisms after authentication as a MITM attack.

This sort of warning seems better to me.

> This is valuable because people tend to have fairly lax security
> configurations on their clients and servers in the interest of
> interoperability.  If there are things we can do to make an attacker's
> life harder--like protecting negotiations--then we should do so unless
> doing so has sufficiently negative consequences.

I'm not really convinced there are truly strong benefits here, but since
it will mostly be a recommendation for new protocols (which can be
designed to negate any negative costs such as the extra round trip), I
won't oppose it either (given text along the lines of what you suggest
above).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

To: Rob Siemborski <[email-masked]>
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms
From: Sam Hartman <[email-masked]>
Date: Fri, 14 Nov 2003 22:16:15 -0500
Sender: [email-masked]

>>>>> "Rob" == Rob Siemborski <[email-masked]> writes:

    >>  No, I wouldn't call that defeated.  You get better protection
    >> by checking after the fact.

    Rob> I know we briefly discussed this in the meeting yesterday and
    Rob> we left it as "probably ok, with some modifications to the
    Rob> text"...

    Rob> I think for me to be happy with the addition of the text, it
    Rob> would need to both have the "if possible" fix, and a
    Rob> clarification that if a server advertises NO mechanisms after
    Rob> authentication, or the protocol does not support fetching
    Rob> capabilities after authentication -- as is the case with
    Rob> MUPDATE (though granted, it isn't standards track), then it
    Rob> MUST NOT act as if a MITM attack was detected.

One thing we need to keep in mind is that over time, we get a better
idea of what best practices for using SASL are.  Some of our older
protocols may not support these best practices.   I'd rather encourage
new protocols to implement the best practices.  So, rather than saying
that if the server  returns no mechanisms the client should not treat
it as  a MITM attack, I'd like to say something like the following.

New protocol profiles SHOULd require servers to make the list of SASL
mechanisms available for the initial authentication available to the
client after security layers are established.  Some older protocols do
not require this; for these protocols clients MUST NOT treat  an empty
list of SASL mechanisms after authentication as a MITM attack.

    Rob> But I'm still unclear why this is necessary when:

    Rob> a) it most likely adds an extra round trip to the
    Rob> authentication process b) it may not even work with all
    Rob> protocols/implementations -- so that round trip will be
    Rob> wasted

    Rob> What are we trying to prevent here, exactly?  The scenario
    Rob> where it applies seems to be something along the lines of:

This is valuable because people tend to have fairly lax security
configurations on their clients and servers in the interest of
interoperability.  If there are things we can do to make an attacker's
life harder--like protecting negotiations--then we should do so unless
doing so has sufficiently negative consequences.

To: [email-masked]
Subject: consensus call on full stop and private use for saslprep
From: Sam Hartman <[email-masked]>
Date: Fri, 14 Nov 2003 22:00:57 -0500
Sender: [email-masked]

Thanks,

--Sam

Date: Fri, 14 Nov 2003 17:00:01 -0700
From: Lyndon Nerenberg <[email-masked]>
To: Chris Newman <[email-masked]>
cc: [email-masked]
Subject: Re: CRAM-MD5 missing security consideration
Sender: [email-masked]

Thanks Chris, I've added the text. I will push a new (and final I hope) 
draft next week.

--lyndon

Date: Thu, 13 Nov 2003 14:56:16 -0600
From: Chris Newman <[email-masked]>
Subject: CRAM-MD5 missing security consideration
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

CRAM-MD5 does not authenticate the server and does not include a
client-supplied nonce.  As a result, it is possible to construct a server with
a fixed challenge string that has pre-computed the hashes for all possible
passwords up to a certain length (or from a dictionary).  Such a server could
then immediately determine the user's password if it is sufficiently short.

                - Chris

To: [email-masked]
Subject: ID Nit: Internet drafts cannot expire in six monthse
Date: Thu, 13 Nov 2003 15:53:49 -0500 (EST)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

Hi.  Just a reminder that Internet draft formatting requirements do
not allow you to say that the draft you are submitting expires in six
months; instead you are requested to include an explicit date.

I believe that this is a useful requirement even though it is not
enforced.  IT makes it more clear whether a draft is expired if it
escapes from the ID repository and is used in another context.  If it
is easy for you to have a real expiration date, please do so.

To: Russ Housley <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Summary for SASL
From: Sam Hartman <[email-masked]>
Date: Thu, 13 Nov 2003 15:45:03 -0500
Sender: [email-masked]

The SASL working group met for one hour Tuesday.  

As part of successful SASL authentication, you can set up a channel
security layer.  If you later have another successful authentication,
the security layer remains in place even if the new SASL mechanism
does not negotiate a security layer.  The There was some concern that
this might create problems for distributed server implementations
where two components trust each other, but do not trust a third
component.  The rough consensus of the working group was not to make
this change.

we had significant discussion of issues surrounding our stringprep
profile saslprep.  First, we discussed whether we wanted to map all
full stop characters to the ASCII full stop character.  We also
discussed whether we would allow private use characters.  The working
group failed to reach consensus on these issues at the session.

We had a presentation on implementation problems with SMTP
authentication.  We expect to be making various changes in our
specifications to make them more clear.  The incorrect behavior is
already a violation of the existing specs but there is a desire to add
better examples.

Alexey Melnikov has agreed to edit the GSSAPI mechanism draft because
the previous editor has not had time to edit the document.  We expect
an initial submission shortly after this meeting.

The chairs will get new milestones to the ADs shortly after the
meeting.  We hope to be done with base, saslprep, plain and anonymous
by the end of the year.

Date: Wed, 12 Nov 2003 10:02:13 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms
Sender: [email-masked]

On Sun, 9 Nov 2003, Sam Hartman wrote:

>     Rob> On Sun, 9 Nov 2003, Hallvard B Furuseth wrote:
>
>     >> If the client fetches a list of supported SASL mechanisms from
>     >> the server and bases its choice of SASL mechanism on the
>     >> result, it SHOULD fetch that list both before and after the
>     >> SASL security layer is negotiated.  This allows the client to
>     >> detect active attacks that remove mechanisms from the server's
>     >> list of supported mechanisms, and allows the client to ensure
>     >> that it is using the best mechanism supported by both client
>     >> and server.
>
>     Rob> Isn't this attack defeated simply by requiring the clients to
>     Rob> not pick a mechanism that does not meet their minimum
>     Rob> requirements for authentication?
>
> No, I wouldn't call that defeated.  You get better protection by
> checking after the fact.

I know we briefly discussed this in the meeting yesterday and we left
it as "probably ok, with some modifications to the text"...

I think for me to be happy with the addition of the text, it would need to
both have the "if possible" fix, and a clarification that if a server
advertises NO mechanisms after authentication, or the protocol does not
support fetching capabilities after authentication -- as is the case with
MUPDATE (though granted, it isn't standards track), then it MUST NOT act
as if a MITM attack was detected.

But I'm still unclear why this is necessary when:

a) it most likely adds an extra round trip to the authentication process
b) it may not even work with all protocols/implementations -- so that
   round trip will be wasted

What are we trying to prevent here, exactly?  The scenario where it
applies seems to be something along the lines of:

The server advertises GSSAPI and DIGEST-MD5.

The client, for whatever reason, decides only GSSAPI (with privacy layer)
is secure enough for it.

The attacker edits the advertised capabilites and removes GSSAPI, the
client sees that the server only supports DIGEST-MD5.  I argue that the
client should fail the authentication here and not even try to
authenticate -- the MITM attack has been defeated.  If instead it
authenticates, then that implies that it is okay with using DIGEST-MD5.
Even if it later discovers that GSSAPI was available, it should be ok with
using DIGEST for the session -- what is it going to tell the user "uh, I
sent your credentials with a mechanism you didn't want to use, and guess
what -- there's an attack in progress!".

Sure, the protection may be "better" (as in, you can detect that an attack
is in progress), but the costs are high (additional round trip, it might
not work anyway) for what seems to me to be a very small gain.

I'd be much happier either not adding this, or adding it as a "clients MAY
want to do this to detect MITM attacks"

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

From: Hallvard B Furuseth <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms
Date: Wed, 12 Nov 2003 16:17:15 +0100
Sender: [email-masked]

Rob Siemborski writes:
> I'd be much happier either not adding this, or adding it as a "clients MAY
> want to do this to detect MITM attacks"

Fine by me.  I don't feel strongly about it, I just saw it in LDAP and
thought it might be a good idea.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Date: Tue, 11 Nov 2003 22:24:45 +0100
Sender: [email-masked]

Alexey Melnikov writes:
> 
>>  "Only a successful reauthentication is able replace/remove the
>>  previously negotiated security layer."
>
> I was thinking specifically about SASL [re]authentication when writing
> this.  My point was that a failed reauthentication didn't remove a
> previously negotiated security layer.

Oh.  So... server and client may at any time agree to remove
the security layer, _except_ after failed reauthentication?

> This should apply to non-SASL reauthentications as well.

Except that in the message you quoted a few messages ago,
you didn't want SASL to know about non-SASL reauthentications,
so it shouldn't say anything about them.

-- 
Hallvard

Date: Tue, 11 Nov 2003 20:39:15 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
>>Hallvard B Furuseth wrote:
>>    
>>
>>>Your text does document that anything else than SASL authentication -
>>>and therefore also Simple Bind - may not remove the SASL security layer.
>>>      
>>>
>>I am not sure that I wrote this anywhere in the document.
>>Anyway, even if I did, that wasn't the intent.
>>    
>>
>
>You are right, it's not in the document.  It's in two explanatory
>messages from you in this thread:
>
>  Date: Wed, 15 Oct 2003 12:52:04 +0100
>  Message-ID: <[email-masked]>
>  URL: http://www.imc.org/ietf-sasl/mail-archive/msg01181.html
>
>  "No, the layer can only be cancelled/replaced after a subsequent 
>  authentication completes successfully."
>
>and
>
>  Date: Sat, 01 Nov 2003 14:22:06 +0000
>  Message-ID: <[email-masked]>
>  URL: http://www.imc.org/ietf-sasl/mail-archive/msg01241.html
>
>  "Only a successful reauthentication is able replace/remove the
>  previously negotiated security layer."
>
I was thinking specifically about SASL [re]authentication when writing this.
My point was that a failed reauthentication didn't remove a previously 
negotiated security layer. This should apply to non-SASL 
reauthentications as well.

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

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Tue, 11 Nov 2003 20:35:01 +0000
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: [Fwd: Keeping/dropping existing SASL security layer]
Sender: [email-masked]

Hopefully this clarifies things.

-------- Original Message --------
Subject: 	Keeping/dropping existing SASL security layer
Date: 	Tue, 11 Nov 2003 11:52:48 +0000
From: 	Alexey Melnikov <[email-masked]>
To: 	Rob Siemborski <[email-masked]>

The order of events is as follows (I will reference "Encryption endpoint 
box" as CC server):

1) The client connects to CC in order to request a resource FOO.
2) CC looks up its database to figure which server is managing FOO. It 
turns out to be server AA.
3). The client authenticates to AA (traffic is passing through CC).
The client and AA negotiate a security layer. Upon successful 
negotiation both ends have pointers to two function (encode/decode) and 
associated keys.
After that there might be 2 variations:
a). AA does encoding/decoding itself
or
b). AA passes encode/decode functions and associated state to CC. (CC is 
trusted)
4). The client exchanges some information with AA (regarding resource 
FOO), the exchange is recorded by BB (but at this stage BB can't decode it)

Than in case a):
5). The client requests access to resource BAR. Server AA decodes 
request and notifies CC about request to BAR.
6). CC looks up its database and determines that resource BAR is managed 
by BB.
7). The client reauthenticates to BB (encrypted traffic is going to AA 
through CC, than cleartext traffic is going from AA to BB through CC),
it negotiates no security layer. When the reauthentication is complete, 
the old layer is used.
8). The client requests access to resource BAR on the server BB (traffic 
flow is the same as in 7).
9). Evil server BB instead of responding to request BAR returns 
specially crafted response in order to verify some guesses about 
previously recorded data exchange between the client and AA. The 
response is traveling in clear from BB to AA (through CC), server AA 
encrypts the response and sends it to the client (through CC). The evil 
BB records the encrypted version of its response and by analyzing it, BB 
can try to break the previously recorded exchange between the client and AA.

or in case b):
5). The client requests access to resource BAR. Server CC decodes request.
6). CC looks up its database and determines that resource BAR is managed 
by BB.
7). The client reauthenticates to BB (encrypted traffic is going to CC, 
than cleartext traffic is going from CC to BB),
it negotiates no security layer. When the reauthentication is complete, 
the old layer is used.
8). The client requests access to resource BAR on the server BB (traffic 
flow is the same as in 7).
9). Evil server BB instead of responding to request BAR returns 
specially crafted response in order to verify some guesses about 
previously recorded data exchange between the client and AA. The 
response is traveling in clear from BB to CC, server CC encrypts the 
response and sends it to the client. The evil BB records the encrypted 
version of its response and by analyzing it, BB can try to break the 
previously recorded exchange between the client and AA.

(I think both cases are equivalent).

I am not a security export, but I think this attack allows for "CBC mode 
attack". TLS is being revised (TLS 1.1) to deal with this issue.

Alexey

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

Cell: +44 7753759732

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

To: Hallvard B Furuseth <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Replacing a SASL security layer
From: Sam Hartman <[email-masked]>
Date: Tue, 11 Nov 2003 15:23:52 -0500
Sender: [email-masked]

I'd like to second the lack of understanding here.  I have asked
several people to explain this attack to me and so far have failed to
understand it.  Hopefully we'll be able to clarify during the meeting
today.

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Date: Tue, 11 Nov 2003 21:06:54 +0100
Sender: [email-masked]

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
> 
>> Your text does document that anything else than SASL authentication -
>> and therefore also Simple Bind - may not remove the SASL security layer.
>
> I am not sure that I wrote this anywhere in the document.
> Anyway, even if I did, that wasn't the intent.

You are right, it's not in the document.  It's in two explanatory
messages from you in this thread:

  Date: Wed, 15 Oct 2003 12:52:04 +0100
  Message-ID: <[email-masked]>
  URL: http://www.imc.org/ietf-sasl/mail-archive/msg01181.html

  "No, the layer can only be cancelled/replaced after a subsequent 
  authentication completes successfully."

and

  Date: Sat, 01 Nov 2003 14:22:06 +0000
  Message-ID: <[email-masked]>
  URL: http://www.imc.org/ietf-sasl/mail-archive/msg01241.html

  "Only a successful reauthentication is able replace/remove the
  previously negotiated security layer."

> If the WG feels that this issue should be addressed, I will add some 
> clarifying text.

Well, I at least think it should be clarified.

-- 
Hallvard

Date: Tue, 11 Nov 2003 19:23:00 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
>>Hallvard B Furuseth wrote:
>>    
>>
>>>Alexey Melnikov writes:      
>>>
>>>>Whether Simple bind removes or keep a previous security layer has 
>>>>nothing to do with SASL, this is very LDAP specific.
>>>>        
>>>>
>>>If SASL allowed LDAP to do so, it would be LDAP specific.
>>>      
>>>
>>SASL can't (and must not) document something it is not aware of. SASL 
>>doesn't have no be aware about Simple bind.
>>    
>>
>
>Your text does document that anything else than SASL authentication -
>and therefore also Simple Bind - may not remove the SASL security layer.
>
I am not sure that I wrote this anywhere in the document.
Anyway, even if I did, that wasn't the intent.

>Even though it's not aware of Simple Bind.  All it is aware of is that
>whatever Simple Bind is, it's not SASL.
>  
>
>>Simple bind is NOT SASL PLAIN,
>>    
>>
>
>I know.  That's why I brought it up.
>
>  
>
>>>It doesn't, so it isn't.
>>>      
>>>
>>Why?
>>    
>>
>
>Maybe I should start over.
>
>I did not say that SASL should say whether or not LDAP Simple Bind
>should remove the layer.  I said that the current text does not allow
>_LDAP_ to say that Simple Bind should remove the layer.  If we want LDAP
>- or other protocols - to be _allowed_ to specify that something like
>non-SASL Simple Bind should remove the layer, rfc2222bis must say
>instead something like
>
>   the protocol profile may specify that authentication by other means
>   than SASL may remove the SASL security layer
>
>or if you don't want SASL to 'know about' non-SASL auth, that
>
>   ... the protocol may at any time decide by other means than SASL to
>   remove the security layer
>
>BTW, I'm not saying that we should do this.  Nor that we shouldn't.
>I simply wanted the issue to be deliberately decided rather than
>defaulted.  That's all.
>  
>
IMHO, something that is not explicitly prohibited is allowed.

If the WG feels that this issue should be addressed, I will add some 
clarifying text.

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

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Tue, 11 Nov 2003 11:05:02 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis: protocol profile?
Sender: [email-masked]

Hallvard B Furuseth wrote:

>What is the purpose of the protocol profile?  If a protocol spec has
>something to say about its SASL entities that are not mentioned in
>section 5 (Protocol profile requirements), should it go in the profile
>or elsewhere?  Could you say something about that in section 5?
>
>For example, the LDAP document draft-ietf-ldapbis-authmeth-08.txt says:
>
>   3.3.5. Rules for using SASL security layers 
>    
>   If a SASL security layer is negotiated, the client SHOULD discard 
>   information about the server fetched prior to the initiation of the 
>   SASL negotiation and not obtained through secure mechanisms.  
>
>   If the client is configured to support multiple SASL mechanisms, it 
>   SHOULD fetch the supportedSASLmechanisms list [An LDAP item] both
>   before and after the SASL security layer is negotiated.  (...)
>
>Does that belong in the protocol profile?
>
IMHO, this kind of information does belong to a protocol profile document.

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

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Mon, 10 Nov 2003 08:12:42 -0800 (PST)
From: Ienup Sung <[email-masked]>
Subject: Re: SASLPrep vs Full Stop code points
To: [email-masked], [email-masked]
Reply-to: Ienup Sung <[email-masked]>
Content-MD5: pV+zF7NBQ4144jebQniLiQ==
Sender: [email-masked]

It is an explicit flag value that need to be given to the SASLprep and
any other Stringprep profile to be more specific. Otherwise, people will be
confused and wondering what to do with it on the Unicode version issues and
also whether and how to use query string vs. storage string (for simple
user names and passwords).

Especially, having some version related remarks or at least explicitly
giving the flag and also mark the flag with a reference would greatly
help people, e.g., "SASLprep(authcid, AllowUnassigned)" or
"SASLprep(passwd, AllowUnassigned)" since the flag processing would/better
need to be done at the Stringprep protocol processing.

With regards,

Ienup

] Date: Sun, 09 Nov 2003 14:13:08 -0500
] From: Jeffrey Altman <[email-masked]>
] Subject: Re: SASLPrep vs Full Stop code points
] To: [email-masked], [email-masked]
] MIME-version: 1.0
] X-Accept-Language: en-us, en
] X-No-Spam-Score: Local
] X-Scanned-By: MIMEDefang 2.35
] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
frigga.ctd.anl.gov
] 
] Ienup Sung wrote:
] 
] >PS. By the way, on a bit different topic, reading the SALSprep and also the
] >PLAIN mechanism drafts, it appears there is no AllowUnassigned flag
] >setting or mentioning of it in the drafts. Has this issue been discussed
] >and/or if "Not Allowed" is implclitly meant in the SIMPLE mechanism draft?
] >If not, it seems either explicitly defining that the unassigned Unicode
] >characters are not allowed in the drafts, or, allow setting of the
] >AllowUnassigned flag as either True or False at the PLAIN draft appears
] >necesary so that the versioning issue is clearly stated... If this question
] >has been asked and answered, sorry, please let me know and I'll scan more of
] >the archived emails.
] >
] >  
] >
] Whether or not Unassigned Code Points are to be allowed or not is 
] dependent upon
] how the string being prepared is to be used.  As described in RFC 3454 
] section 7,
] if the use of the string is for storage in a database then Unassigned 
] Code Points
] are to be excluded.  However, if the string is to be used for the 
] purposed of
] querying a database, then the string may contain Unassigned Code Points.
] 
] I do not believe it is required for SASLprep to highlight this 
] distinction. 
] It should however be specified in the protocol documents which utilize 
] string
] preparation methods constructed within the framework of RFC 3454.
] 
] Jeffrey Altman
] 
] 

Date: Mon, 10 Nov 2003 07:54:51 -0800 (PST)
From: Ienup Sung <[email-masked]>
Subject: Re: SASLPrep vs Full Stop code points
To: [email-masked], [email-masked]
Reply-to: Ienup Sung <[email-masked]>
Content-MD5: BYCz81EfVfXsql4UdlhwOg==
Sender: [email-masked]

In my opinion, yes,that's correct and especially for user names and
passwords.

With regards,

Ienup

] Date: Sun, 09 Nov 2003 20:36:37 -0500
] From: Sam Hartman <[email-masked]>
] Subject: Re: SASLPrep vs Full Stop code points
] To: Ienup Sung <[email-masked]>
] Cc: [email-masked], [email-masked]
] MIME-version: 1.0
] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
frigga.ctd.anl.gov
] 
] >>>>> "Ienup" == Ienup Sung <[email-masked]> writes:
] 
]     Ienup> As U+002E is used as full stop as label separator (not as
]     Ienup> decimal point for number representations), the Asian full
]     Ienup> stops are used as full stop as label separator in the IDNA.
] 
]     Ienup> The IDNA's full stop mappings on the Internet domain style
]     Ienup> names are possible and rather desireable for convenience
]     Ienup> since we know that the full stops in that case are used as
]     Ienup> label separators and thus safely map the Asian full stops
]     Ienup> to the U+002E as the full stop.
] 
]     Ienup> With regards,
] 
] You believe there is not a similar convenience issue in usernames?
] 
] 
] 

From: Hallvard B Furuseth <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis: protocol profile?
Date: Mon, 10 Nov 2003 08:10:22 +0100
Sender: [email-masked]

Sam Hartman writes:
> I believe section 5 is a set of minimum requirements for protocol
> profiles; you should be able to specify additional details in the
> profile document.

OK, but why would I - or why would I not?  What belongs in the protocol
profile?

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Rob Siemborski <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms
Date: Mon, 10 Nov 2003 07:26:39 +0100
Sender: [email-masked]

Sam Hartman writes:
>>>>>> "Rob" == Rob Siemborski <[email-masked]> writes:
> 
>     Rob> There are also currently deployed servers that do not
>     Rob> continue to advertise their sasl mechanisms after
>     Rob> authentication, since in almost all current protocols it is
>     Rob> not valid to issue a second sasl authentication command.
> 
> That's why he said SHOULD not MUST;)

Well, it would have been if I had thought of it...
I guess I should have put an 'if possible' in there somewhere.

-- 
Hallvard

To: Ienup Sung <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
From: Sam Hartman <[email-masked]>
Date: Sun, 09 Nov 2003 20:36:37 -0500
Sender: [email-masked]

>>>>> "Ienup" == Ienup Sung <[email-masked]> writes:

    Ienup> As U+002E is used as full stop as label separator (not as
    Ienup> decimal point for number representations), the Asian full
    Ienup> stops are used as full stop as label separator in the IDNA.

    Ienup> The IDNA's full stop mappings on the Internet domain style
    Ienup> names are possible and rather desireable for convenience
    Ienup> since we know that the full stops in that case are used as
    Ienup> label separators and thus safely map the Asian full stops
    Ienup> to the U+002E as the full stop.

    Ienup> With regards,

You believe there is not a similar convenience issue in usernames?

To: Tony Hansen <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-sasl-rfc2222bis-02.txt section 4.2
From: Sam Hartman <[email-masked]>
Date: Sun, 09 Nov 2003 18:46:12 -0500
Sender: [email-masked]

>>>>> "Tony" == Tony Hansen <[email-masked]> writes:

    Tony> May I suggest that this section be rewritten so that it
    Tony> focusses on the two topics separately. For example,
    Tony> something like the following below might be considered.

This section certainly has been a subject of much discussion about
clarity here.

To: Rob Siemborski <[email-masked]>
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms
From: Sam Hartman <[email-masked]>
Date: Sun, 09 Nov 2003 18:44:13 -0500
Sender: [email-masked]

>>>>> "Rob" == Rob Siemborski <[email-masked]> writes:

    Rob> On Sun, 9 Nov 2003, Hallvard B Furuseth wrote:

    >> If the client fetches a list of supported SASL mechanisms from
    >> the server and bases its choice of SASL mechanism on the
    >> result, it SHOULD fetch that list both before and after the
    >> SASL security layer is negotiated.  This allows the client to
    >> detect active attacks that remove mechanisms from the server's
    >> list of supported mechanisms, and allows the client to ensure
    >> that it is using the best mechanism supported by both client
    >> and server.

    Rob> Isn't this attack defeated simply by requiring the clients to
    Rob> not pick a mechanism that does not meet their minimum
    Rob> requirements for authentication?

No, I wouldn't call that defeated.  You get better protection by
checking after the fact.

    Rob> There are also currently deployed servers that do not
    Rob> continue to advertise their sasl mechanisms after
    Rob> authentication, since in almost all current protocols it is
    Rob> not valid to issue a second sasl authentication command.

That's why he said SHOULD not MUST;)

To: Hallvard B Furuseth <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis: protocol profile?
From: Sam Hartman <[email-masked]>
Date: Sun, 09 Nov 2003 18:42:14 -0500
Sender: [email-masked]

>>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:

    Hallvard> What is the purpose of the protocol profile?  If a
    Hallvard> protocol spec has something to say about its SASL
    Hallvard> entities that are not mentioned in section 5 (Protocol
    Hallvard> profile requirements), should it go in the profile or
    Hallvard> elsewhere?  Could you say something about that in
    Hallvard> section 5?

I believe section 5 is a set of minimum requirements for protocol
profiles; you should be able to specify additional details in the
profile document.

Date: Sun, 9 Nov 2003 16:33:41 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
cc: [email-masked]
Subject: Re: rfc2222bis: suggested text about multiple SASL mechanisms
Sender: [email-masked]

On Sun, 9 Nov 2003, Hallvard B Furuseth wrote:

>    If the client fetches a list of supported SASL mechanisms from the
>    server and bases its choice of SASL mechanism on the result, it
>    SHOULD fetch that list both before and after the SASL security layer
>    is negotiated.  This allows the client to detect active attacks that
>    remove mechanisms from the server's list of supported mechanisms, and
>    allows the client to ensure that it is using the best mechanism
>    supported by both client and server.

Isn't this attack defeated simply by requiring the clients to not pick a
mechanism that does not meet their minimum requirements for
authentication?

There are also currently deployed servers that do not continue to
advertise their sasl mechanisms after authentication, since in almost
all current protocols it is not valid to issue a second sasl
authentication command.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

Date: Sun, 09 Nov 2003 14:13:08 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Columbia University in the City of New York
To: [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms050803040500090503080500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ienup Sung wrote:

>PS. By the way, on a bit different topic, reading the SALSprep and also the
>PLAIN mechanism drafts, it appears there is no AllowUnassigned flag
>setting or mentioning of it in the drafts. Has this issue been discussed
>and/or if "Not Allowed" is implclitly meant in the SIMPLE mechanism draft?
>If not, it seems either explicitly defining that the unassigned Unicode
>characters are not allowed in the drafts, or, allow setting of the
>AllowUnassigned flag as either True or False at the PLAIN draft appears
>necesary so that the versioning issue is clearly stated... If this question
>has been asked and answered, sorry, please let me know and I'll scan more of
>the archived emails.
>
>  
>
Whether or not Unassigned Code Points are to be allowed or not is 
dependent upon
how the string being prepared is to be used.  As described in RFC 3454 
section 7,
if the use of the string is for storage in a database then Unassigned 
Code Points
are to be excluded.  However, if the string is to be used for the 
purposed of
querying a database, then the string may contain Unassigned Code Points.

I do not believe it is required for SASLprep to highlight this 
distinction. 
It should however be specified in the protocol documents which utilize 
string
preparation methods constructed within the framework of RFC 3454.

Jeffrey Altman

--------------ms050803040500090503080500
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050803040500090503080500--

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: rfc2222bis: suggested text about multiple SASL mechanisms
Date: Sun, 9 Nov 2003 20:31:56 +0100
Sender: [email-masked]

I suggest this text is added to rfc2222bis, probably in the Security
Considerations.  I stole it from draft-ietf-ldapbis-authmeth-08.txt and
de-LDAPified it.

   If the client fetches a list of supported SASL mechanisms from the
   server and bases its choice of SASL mechanism on the result, it
   SHOULD fetch that list both before and after the SASL security layer
   is negotiated.  This allows the client to detect active attacks that
   remove mechanisms from the server's list of supported mechanisms, and
   allows the client to ensure that it is using the best mechanism
   supported by both client and server.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: rfc2222bis: protocol profile?
Date: Sun, 9 Nov 2003 19:48:07 +0100
Sender: [email-masked]

What is the purpose of the protocol profile?  If a protocol spec has
something to say about its SASL entities that are not mentioned in
section 5 (Protocol profile requirements), should it go in the profile
or elsewhere?  Could you say something about that in section 5?

For example, the LDAP document draft-ietf-ldapbis-authmeth-08.txt says:

   3.3.5. Rules for using SASL security layers 
    
   If a SASL security layer is negotiated, the client SHOULD discard 
   information about the server fetched prior to the initiation of the 
   SASL negotiation and not obtained through secure mechanisms.  

   If the client is configured to support multiple SASL mechanisms, it 
   SHOULD fetch the supportedSASLmechanisms list [An LDAP item] both
   before and after the SASL security layer is negotiated.  (...)

Does that belong in the protocol profile?

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Date: Sun, 9 Nov 2003 19:32:52 +0100
Sender: [email-masked]

I wrote:
>Alexey Melnikov writes:
>> (...) Only a successful reauthentication is able replace/remove the
>> previously negotiated security layer.
> 
> Just to make sure it has been mentioned:
> 
> This also means that non-SASL authentication must keep any old SASL
> layer.  I expect that's intended, including for LDAPv4?

Perhaps I should clarify a bit:

The current text does not allow protocols - e.g. LDAP - to say that
non-SASL authentication (in LDAP, that's "Simple Bind") should remove
the layer.  If we want protocols to be allowed to specify that,
rfc2222bis must say instead something like

   the protocol profile may specify that authentication by other means
   than SASL may remove the SASL security layer

or if we don't want SASL to 'know about' non-SASL auth at all, that

   ... the protocol may at any time decide by other means than SASL to
   remove the security layer

BTW, I'm not saying that we should do this.  Nor that we shouldn't.  I
simply want the issue to be deliberately decided rather than defaulted.

-- 
Hallvard

Date: Sat, 08 Nov 2003 17:48:21 -0800 (PST)
From: Ienup Sung <[email-masked]>
Subject: Re: SASLPrep vs Full Stop code points
To: [email-masked], [email-masked]
Reply-to: Ienup Sung <[email-masked]>
Content-MD5: RC9tYTcDM4zCLW+l5msq/w==
Sender: [email-masked]

As U+002E is used as full stop as label separator (not as decimal point for
number representations), the Asian full stops are used as full stop as
label separator in the IDNA.

The IDNA's full stop mappings on the Internet domain style names are possible
and rather desireable for convenience since we know that the full stops in
that case are used as label separators and thus safely map the Asian full stops
to the U+002E as the full stop.

With regards,

Ienup

] Date: Sat, 08 Nov 2003 17:11:47 -0500
] From: Sam Hartman <[email-masked]>
] Subject: Re: SASLPrep vs Full Stop code points
] To: Ienup Sung <[email-masked]>
] Cc: [email-masked], [email-masked]
] MIME-version: 1.0
] Content-transfer-encoding: 8BIT
] 
] >>>>> "Ienup" == Ienup Sung <[email-masked]> writes:
] 
]     Ienup> Actually that's exactly the problem that I was also talking
]     Ienup> about since people will treat the Asian full stops and
]     Ienup> U+002E differently at Asian countries and when people tried
]     Ienup> to register a new user account with let say 3。14
]     Ienup> (where it is three, Asian full-stop, and fourteen), the
]     Ienup> PLAIN based user account system could say, sorry, we
]     Ienup> already have 3.14 (that is three point one four) which is
]     Ienup> totally different user account name and would deny the new
]     Ienup> user account name which will be quite confusing for Asian
]     Ienup> people.
] 
] OK, then why would people use the Asian full stop in domain names?
] What's different about the world of DNS and the world of user names?
] 
] Yours in confusion,
] 
] --Sam
] 
] 

To: Ienup Sung <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
From: Sam Hartman <[email-masked]>
Date: Sat, 08 Nov 2003 17:11:47 -0500
Sender: [email-masked]

>>>>> "Ienup" == Ienup Sung <[email-masked]> writes:

    Ienup> Actually that's exactly the problem that I was also talking
    Ienup> about since people will treat the Asian full stops and
    Ienup> U+002E differently at Asian countries and when people tried
    Ienup> to register a new user account with let say 3。14
    Ienup> (where it is three, Asian full-stop, and fourteen), the
    Ienup> PLAIN based user account system could say, sorry, we
    Ienup> already have 3.14 (that is three point one four) which is
    Ienup> totally different user account name and would deny the new
    Ienup> user account name which will be quite confusing for Asian
    Ienup> people.

OK, then why would people use the Asian full stop in domain names?
What's different about the world of DNS and the world of user names?

Yours in confusion,

--Sam

Date: Fri, 07 Nov 2003 13:07:04 -0800 (PST)
From: Ienup Sung <[email-masked]>
Subject: Re: SASLPrep vs Full Stop code points
To: [email-masked], [email-masked]
Reply-to: Ienup Sung <[email-masked]>
Sender: [email-masked]

--Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ)
Content-type: TEXT/plain; charset=UTF-8
Content-transfer-encoding: QUOTED-PRINTABLE
Content-MD5: xiCw1QO9AzRAFXH/mDmrFA==

I believe the question is whether to (incorrectly) generalize/map or not in=
 my
opinion.

Actually the confusion will also and sure to occur if you map the all full
stops to the U+002E since Asian people distinguish the U+002E and the U+300=
2
even without any thinking if you wrongly use the full stops in the place of
decimal point.

The point that I can make further is that people have been using various
Asian codesets/codepages that have different code point values and differen=
t
input mechanisms for each of those Asian full stops and the ASCII decimal
points many years; they see them and use them differently.

The NFKC used in SASLprep will map the U+FF0E to the U+002E since they are
equivalent and should be normalized. On the other hands, the U+3002 and
the U+FF61 are not equivalent to the U+002E but only to themselves, i.e.,
the U+FF61 will map to the U+3002 after the NFKC.

Here is also another practical example: the ATOK is, arguably, the most pop=
ular
Japanese input system in my understanding. When you use ATOK to input
Japanese, what happens is that when you type with numbers, you will get '.'
automatically if you press dot key from your keyboard. When a sentense is
ending, used by itself alone, or surrounded with non-gidits, the dot key
will be interpreted as the ideographic/Asian full-stop of U+3002. In other
words, to input ideographic/Asian full stop (U+3002) with number isn't that
easy and when that happened, i.e., a user typed in the U+3002 among numbers=
,
that means it is most definitely not the full stop. Furthermore, you can as=
k
any Asian people around you if you can use full stop in a number/numeric
notation; most likely almost 100% of them will say, No Way.

(Also and at the same time, just as for info, Asian people will absolutely
accept and tolerate '.' being used in the place of U+3002 iff it is
used as the full stop. Usually, formal documents don't use '.' by the way a=
s
you know.)

I also attached a sample screen shot in JPEG showing the ATOK12 based
Japanese input with numbers and would like to demonstrate how Asian input
system works in the SASL WG meeting at Tuesday.

And so once again my suggestion is that the mappings of all full stops shou=
ld
be done as similary as defined in the IDNA for Internet style domain names
but outside and before the SASLprep if such mappings are needed for Interne=
t
domain style names.

With regards,

Ienup

] Date: Fri, 07 Nov 2003 15:16:25 -0500
] From: Jeffrey Altman <[email-masked]>
] Subject: Re: SASLPrep vs Full Stop code points
] To: [email-masked], [email-masked]
] MIME-version: 1.0
] X-Accept-Language: en-us, en
] X-No-Spam-Score: Local
] X-Scanned-By: MIMEDefang 2.35
]=20
] It is absolutely a trade off.  Avoidance of end user confusion because th=
ey
] could not tell the difference between the full stops and the ability to
] specify them as different strings.
]=20
] By choosing to fold the full stops we are saying that we believe that the=
re
] will be more confusion by users who try to use one form of full stop when
] they should be using another than the confusion which will be caused for
] system administrators who desire to create accounts which only differ by
] the type of full stop used.
]=20
] Jeffrey Altman
]=20
]=20
] Ienup Sung wrote:
]=20
] >Actually that's exactly the problem that I was also talking about since
] >people will treat the Asian full stops and U+002E differently at Asian
] >countries and when people tried to register a new user account with let =
say
] >3=E3=80=8214 (where it is three, Asian full-stop, and fourteen), the PLA=
IN based user
] >account system could say, sorry, we already have 3.14 (that is three poi=
nt
] >one four) which is totally different user account name and would deny
] >the new user account name which will be quite confusing for Asian people=
.
] >
] >With regards,
] >
] >Ienup
] >
] > =20
] >

--Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ)
Content-type: IMAGE/jpeg; name=ATOK12-Japanese.jpg; x-unix-mode=0644
Content-transfer-encoding: BASE64
Content-disposition: attachment; filename=ATOK12-Japanese.jpg
Content-description: ATOK12-Japanese.jpg
Content-MD5: 35UO0f6/F0u2PYtWXN9K+w==

--Boundary_(ID_M9JQmtEiz0qldAo12wPoNQ)--

Date: Fri, 07 Nov 2003 15:16:25 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Columbia University in the City of New York
To: [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms060403050102060802000005
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

It is absolutely a trade off.  Avoidance of end user confusion because they
could not tell the difference between the full stops and the ability to
specify them as different strings.

By choosing to fold the full stops we are saying that we believe that there
will be more confusion by users who try to use one form of full stop when
they should be using another than the confusion which will be caused for
system administrators who desire to create accounts which only differ by
the type of full stop used.

Jeffrey Altman

Ienup Sung wrote:

>Actually that's exactly the problem that I was also talking about since
>people will treat the Asian full stops and U+002E differently at Asian
>countries and when people tried to register a new user account with let say
>3。14 (where it is three, Asian full-stop, and fourteen), the PLAIN based user
>account system could say, sorry, we already have 3.14 (that is three point
>one four) which is totally different user account name and would deny
>the new user account name which will be quite confusing for Asian people.
>
>With regards,
>
>Ienup
>
>  
>

--------------ms060403050102060802000005
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060403050102060802000005--

Date: Fri, 07 Nov 2003 11:35:46 -0800 (PST)
From: Ienup Sung <[email-masked]>
Subject: Re: SASLPrep vs Full Stop code points
To: [email-masked], [email-masked]
Reply-to: Ienup Sung <[email-masked]>
Content-MD5: cvDLdFlktZQJJSr4KNqsHw==
Sender: [email-masked]

Actually that's exactly the problem that I was also talking about since
people will treat the Asian full stops and U+002E differently at Asian
countries and when people tried to register a new user account with let say
3。14 (where it is three, Asian full-stop, and fourteen), the PLAIN based user
account system could say, sorry, we already have 3.14 (that is three point
one four) which is totally different user account name and would deny
the new user account name which will be quite confusing for Asian people.

With regards,

Ienup

] Date: Thu, 06 Nov 2003 21:21:08 -0500
] From: Jeffrey Altman <[email-masked]>
] Subject: Re: SASLPrep vs Full Stop code points
] To: [email-masked], [email-masked]
] MIME-version: 1.0
] X-Accept-Language: en-us, en
] X-No-Spam-Score: Local
] X-Scanned-By: MIMEDefang 2.35
] 
] The question is not whether or not the different full stops are used by
] different people in different ways at the user interface level.  The 
] transformations
] we are discussing for use with SASLPrep are specific to the use of the 
] strings
] as Storage and Query strings; not as Display strings.  When a string is 
] to be used
] as a username or a password is there a reason why we should be concerned 
] with
] distinguishing the differences?  If there is not a good reason to 
] preserve the
] differences then there is a reasonable argument to fold them similar to 
] the arguments
] for folding spacing characters.
] 
] Users will always be free to choose one representation over another.  It 
] is only
] on the wire that there should be a distinction.
] 
] Jeffrey Altman
] 
] 
] Ienup Sung wrote:
] 
] >I think there will be problems if we treat the Asian full stops as equivalents
] >to the ASCII decimal point/dot/full stop character simply because the Asian
] >full stops are not equivalent to the ASCII decimal points all the time.
] >In other words, Asian people are and will distinguish (almost implicitly) when
] >to use the Asian/ASCII full stops and when to use the decimal point character;
] >if coerced at the protocol level that the Asian full stops are all
] >mapped to the U+002E for all the cases, people will be, sometimes, confused.
] >
] >I do see the pros of convenience but that will, in my opinion, come in with
] >the price of denying the fact that the Asian full stops are only and
] >conditionally equivalent to the U+002E (when the U+002E means the full stop).
] >In other words, by having the general full stop mappings, we are denying
] >the possibility of Asian people using the full stops and decimal points
] >differently in their user names and passwords.
] >
] >  
] >

Date: Thu, 06 Nov 2003 21:21:08 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Columbia University in the City of New York
To: [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms020500020203020202030107
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The question is not whether or not the different full stops are used by
different people in different ways at the user interface level.  The 
transformations
we are discussing for use with SASLPrep are specific to the use of the 
strings
as Storage and Query strings; not as Display strings.  When a string is 
to be used
as a username or a password is there a reason why we should be concerned 
with
distinguishing the differences?  If there is not a good reason to 
preserve the
differences then there is a reasonable argument to fold them similar to 
the arguments
for folding spacing characters.

Users will always be free to choose one representation over another.  It 
is only
on the wire that there should be a distinction.

Jeffrey Altman

Ienup Sung wrote:

>I think there will be problems if we treat the Asian full stops as equivalents
>to the ASCII decimal point/dot/full stop character simply because the Asian
>full stops are not equivalent to the ASCII decimal points all the time.
>In other words, Asian people are and will distinguish (almost implicitly) when
>to use the Asian/ASCII full stops and when to use the decimal point character;
>if coerced at the protocol level that the Asian full stops are all
>mapped to the U+002E for all the cases, people will be, sometimes, confused.
>
>I do see the pros of convenience but that will, in my opinion, come in with
>the price of denying the fact that the Asian full stops are only and
>conditionally equivalent to the U+002E (when the U+002E means the full stop).
>In other words, by having the general full stop mappings, we are denying
>the possibility of Asian people using the full stops and decimal points
>differently in their user names and passwords.
>
>  
>

--------------ms020500020203020202030107
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020500020203020202030107--

Date: Thu, 6 Nov 2003 20:47:08 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: 'selects no security layer'
Sender: [email-masked]

On Thu, 6 Nov 2003, Kurt D. Zeilenga wrote:

> If the layers are active between the client and server AA,
> then the middlebox could not normally insert a re-authenication to
> server BB without coordination from AA.  That is, the middle
> box would need to know how to decrypt/encrypt the exchanges
> (before, during, after reauthentication).  If AA doesn't trust
> the middlebox (and its relations with the likes of BB), then AA
> simply need not provide the secrets to the middlebox necessary
> to support reauthentication with others.  If AA does trust
> the middlebox, then it implicitly accepts the risk of that trust.
>
> If the layers are active between the client and middlebox,
> the middlebox likely would need cooperation from AA to
> support reauthentication to BB.  (In this case, it would be
> better to call the middlebox the SASL server and AA and BB
> "external systems" (not servers).)  If AA doesn't trust the
> middlebox, then it should not cooperate with it.   But if it
> does, even if layers are dropped, it (AA) would be vulnerable
> to attack from BB because the subsequent exchange (which
> BB has knowledge of) is protected by those layers.

Ah, I think I misunderstood the example slightly [didn't understand how
the middlebox was playing with the rest of the system].  However, I still
agree with Kurt -- this is a minimal case that can be dismissed with a
Security Consideration about the trust relationships involved.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

Date: Thu, 06 Nov 2003 16:28:38 -0800 (PST)
From: Ienup Sung <[email-masked]>
Subject: Re: SASLPrep vs Full Stop code points
To: [email-masked], [email-masked]
Reply-to: Ienup Sung <[email-masked]>
Content-MD5: rzDg7/uVrejlQtuahVpKbg==
Sender: [email-masked]

Yes, the POSIX/SUS/XPG specifies that the poratble user names be in
the portable file name character set and it includes [A-Za-z._-] with some
additional rules. I also have seen many people using the 0x2e in their user
names and passwords.

And, while I believe I do understand that the SASLprep is intended for
simple user names and passowrds at the moment, I believe I'm seeing
the full stops vs decimal point issue a bit differently... (and maybe in
that way, I'm wrong about it...)

I think there will be problems if we treat the Asian full stops as equivalents
to the ASCII decimal point/dot/full stop character simply because the Asian
full stops are not equivalent to the ASCII decimal points all the time.
In other words, Asian people are and will distinguish (almost implicitly) when
to use the Asian/ASCII full stops and when to use the decimal point character;
if coerced at the protocol level that the Asian full stops are all
mapped to the U+002E for all the cases, people will be, sometimes, confused.

I do see the pros of convenience but that will, in my opinion, come in with
the price of denying the fact that the Asian full stops are only and
conditionally equivalent to the U+002E (when the U+002E means the full stop).
In other words, by having the general full stop mappings, we are denying
the possibility of Asian people using the full stops and decimal points
differently in their user names and passwords.

I personally can live with such general mappings and so thus many other Asians
in my opinion but when we do know about the fact that the characters are
different and virtually and practically we are not capable of distinguishing
when the two groups of characters can be treated equal or not with the
Stringprep and SALSprep, it seems to me that it is not really a good idea to
have a generic, simple table-driven mappings at the SASLprep (even for
the simple user names and passwords)...

Should more opinions needed and if the WG folks agree and assign to me,
I can bring this exactly the same question of whether we can
treat the Asian full stops as the decimal point to the Unicode Technical
Committee and get the opinion of the UTC back to the WGs. 

With regards,

Ienup

PS. By the way, on a bit different topic, reading the SALSprep and also the
PLAIN mechanism drafts, it appears there is no AllowUnassigned flag
setting or mentioning of it in the drafts. Has this issue been discussed
and/or if "Not Allowed" is implclitly meant in the SIMPLE mechanism draft?
If not, it seems either explicitly defining that the unassigned Unicode
characters are not allowed in the drafts, or, allow setting of the
AllowUnassigned flag as either True or False at the PLAIN draft appears
necesary so that the versioning issue is clearly stated... If this question
has been asked and answered, sorry, please let me know and I'll scan more of
the archived emails.

] Date: Thu, 06 Nov 2003 16:35:13 -0500
] From: Sam Hartman <[email-masked]>
] Subject: Re: SASLPrep vs Full Stop code points
] To: Ienup Sung <[email-masked]>
] Cc: [email-masked], [email-masked]
] MIME-version: 1.0
] 
] >>>>> "Ienup" == Ienup Sung <[email-masked]> writes:
] 
]     Ienup> I agree that the SASLprep is more suitable and applicable
]     Ienup> for simple user names and passwords and if the additional
]     Ienup> mappings such as the full stops are needed, they are more
]     Ienup> suitable and correct to be done at the outside of any
]     Ienup> Stringprep/Stringprep profiles and most preferrably before
]     Ienup> the application of the Stringprep profile(s). <-- These are
]     Ienup> also my points all along.
] 
] I think Kurt's point was that since saslprep was for usernames and
] passwords, it is more appropriate to do full-stop mappings there than
] in some more general context.  Do we expect people to need decimal
] points in their usernames?  Do we think it a problem if someone uses a
] decimal point in a password, but can later use one of the other
] full-stop characters and have it work?
] 
] --Sam
] 

Date: Thu, 06 Nov 2003 15:33:03 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: rfc2222bis: 'selects no security layer'
Cc: [email-masked]
Sender: [email-masked]

At 01:14 PM 11/6/2003, Alexey Melnikov wrote:
>Actually, I am not sure I understand what are you saying here Kurt. 

Part of the problem here is that I am (and maybe others are) having
trouble making sense of your scenario.   After further examination,
I think your text and picture don't match up.  The text implies
the layers are active between the client and the Realm A server
called AA, but your picture implies the layers are active between
the client and the middlebox ("proxy/frontend").

If the layers are active between the client and server AA,
then the middlebox could not normally insert a re-authenication to
server BB without coordination from AA.  That is, the middle
box would need to know how to decrypt/encrypt the exchanges
(before, during, after reauthentication).  If AA doesn't trust
the middlebox (and its relations with the likes of BB), then AA
simply need not provide the secrets to the middlebox necessary
to support reauthentication with others.  If AA does trust
the middlebox, then it implicitly accepts the risk of that trust.

If the layers are active between the client and middlebox,
the middlebox likely would need cooperation from AA to
support reauthentication to BB.  (In this case, it would be
better to call the middlebox the SASL server and AA and BB
"external systems" (not servers).)  If AA doesn't trust the
middlebox, then it should not cooperate with it.   But if it
does, even if layers are dropped, it (AA) would be vulnerable
to attack from BB because the subsequent exchange (which
BB has knowledge of) is protected by those layers.

In either case, this risk is quite limited and can be
managed as part of the trust relationship between AA and
the middlebox.

I think these scenarios are part of a larger class of
vulnerabilities: attacks from 3rd parties which have
limited knowledge of information protected by the SASL.
I think this class of vulnerabilities is best addressed
by stating a broad security consideration (possibly
supported by one or two specific examples).

Kurt

To: Lyndon Nerenberg <[email-masked]>
Cc: Ienup Sung <[email-masked]>, [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
From: Sam Hartman <[email-masked]>
Date: Thu, 06 Nov 2003 17:56:57 -0500
Sender: [email-masked]

>>>>> "Lyndon" == Lyndon Nerenberg <[email-masked]> writes:

    Lyndon> firstname.lastname is a very common scheme for forming
    Lyndon> identifiers, so yes we do need to support decimal points
    Lyndon> (and their equivalent mappings) in usernames.
But it seems like in this case mapping all the full stops together
would be desirable.

Date: Thu, 06 Nov 2003 15:37:32 -0700
From: Lyndon Nerenberg <[email-masked]>
To: Sam Hartman <[email-masked]>, Ienup Sung <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
Sender: [email-masked]

> I think Kurt's point was that since saslprep was for usernames and
> passwords, it is more appropriate to do full-stop mappings there than
> in some more general context.  Do we expect people to need decimal
> points in their usernames?

firstname.lastname is a very common scheme for forming identifiers, so yes 
we do need to support decimal points (and their equivalent mappings) in 
usernames.

--lyndon

Date: Thu, 6 Nov 2003 17:29:54 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: "Kurt D. Zeilenga" <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: 'selects no security layer'
Sender: [email-masked]

On Thu, 6 Nov 2003, Alexey Melnikov wrote:

> >>I think one of the problems we have adding this profile option
> >>is that the specification is now much more complex and
> >>framework implementations, especially those which support both
> >>options, will need to be much more complex.  We need to keep
> >>SASL and the specification of SASL simple.
> >
> >I have to agree with Kurt here.  One of the major benefits of SASL is that
> >the framework layer has been historically simple.  Allowing both modes
> >(dropping the layer or continuing under the old layer) needlessly
> >complicates the implementation
>
> Which implementation are you talking about?

I'll use the CMU SASL implementation as an example, but I don't think it
really matters.

Using RFC2222, if you had a re-authentication and the new session didn't
have a security layer, you would need to keep the old SASL context around
and continue to use it for security layer purposes (from an API
standpoint, this sucks, granted).

In 2222bis-03, you no longer have to do this, but it breaks LDAP as
deployed (which is bad).

In your suggested text, there's no longer a set way of handling this -- it
varies from protocol to protocol (as long as they allow reauthentication).
And its yet another thing that can be gotten wrong in an implementation.

In any case though, I suppose this is application layer not framework
layer.

Due to the related nature of many of the protocols that implement SASL, we
often see one product using SASL for many protocols at once (a mail client
can implement POP3, IMAP, SMTP, LDAP and IMSP/ACAP without breaking a
sweat, and a mail server can come close to twice that).  Subtle
differences between these protocols can be a nightmare for implementors
(just look at how similar the new POP3 and SMTP profiles are, yet how they
both have subtle differences).

I fear what will happen when we have another protocol that allows
reauthentication but does it in a different way from LDAP.

Then again, maybe you're right and the benefits of allowing it both ways
outweigh the implementation complexity -- especially given the (somewhat
inevitable, I think) upcoming "SASL Implementation Recommendations"
document.

> True. But it is more difficult to implement an attack during
> reauthentication. And servers should drop connection after some number
> of failed authentications.

Are we both talking about the vulnerability discussed at the bottom of
section 6.3?

I may be misunderstanding the problem -- as I read it, we don't want the
initial realm to be able to read traffic going to the newly-authenticated
realm.   But if the new authentication doesn't have a security layer, how
is dropping the old security layer any benefit?  We're moving from a
tunneled layer (which, granted, can be read/modified by the initial realm)
to one that can be read/modified by anyone!

I definitely see a win with forcing a change when the new authentication
creates a new security layer, but in the absence of a new security layer,
I'm not seeing the benefit.

> >>  The
> >>information sent under the subsequent layers is still contains
> >>information known by those involved in the reauthentication.
> >>
> Actually, I am not sure I understand what are you saying here Kurt.

Now that I re-read this, I'm not sure it applies to the vulnerability
discussed in 6.3.

However, it is true that if I know a good deal of the plaintext that you
are sending encrypted (e.g. I am a backend server and you are a proxy), I
have a huge advantage in trying to break your session key with a client.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

To: Ienup Sung <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: SASLPrep vs Full Stop code points
From: Sam Hartman <[email-masked]>
Date: Thu, 06 Nov 2003 16:35:13 -0500
Sender: [email-masked]

>>>>> "Ienup" == Ienup Sung <[email-masked]> writes:

    Ienup> I agree that the SASLprep is more suitable and applicable
    Ienup> for simple user names and passwords and if the additional
    Ienup> mappings such as the full stops are needed, they are more
    Ienup> suitable and correct to be done at the outside of any
    Ienup> Stringprep/Stringprep profiles and most preferrably before
    Ienup> the application of the Stringprep profile(s). <-- These are
    Ienup> also my points all along.

I think Kurt's point was that since saslprep was for usernames and
passwords, it is more appropriate to do full-stop mappings there than
in some more general context.  Do we expect people to need decimal
points in their usernames?  Do we think it a problem if someone uses a
decimal point in a password, but can later use one of the other
full-stop characters and have it work?

--Sam

Date: Thu, 06 Nov 2003 21:14:26 +0000
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: 'selects no security layer'
Sender: [email-masked]

Rob Siemborski wrote:

>On Thu, 6 Nov 2003, Kurt D. Zeilenga wrote:
>  
>
>>At 02:52 AM 11/6/2003, Alexey Melnikov wrote:
>>    
>>
>>>I would welcome any suggestions to make this clearer.
>>>      
>>>
>>I think one of the problems we have adding this profile option
>>is that the specification is now much more complex and
>>framework implementations, especially those which support both
>>options, will need to be much more complex.  We need to keep
>>SASL and the specification of SASL simple.
>>    
>>
>
>I have to agree with Kurt here.  One of the major benefits of SASL is that
>the framework layer has been historically simple.  Allowing both modes
>(dropping the layer or continuing under the old layer) needlessly
>complicates the implementation
>
Which implementation are you talking about?

> and breaks backwards compatibility for
>minimal gain.
>
A protocol profile is not allowed to do both. It has to document a choice.
This is a checkbox.

There is only a single protocol that currently allows for reauthentication.

>>I don't see the risk from the described threat being so high
>>to warrant the insertion of this option ESPECIALLY given that
>>the option doesn't not fully address the vulnerability.
>>
True. But it is more difficult to implement an attack during 
reauthentication. And servers should drop connection after some number 
of failed authentications.

>>  The
>>information sent under the subsequent layers is still contains
>>information known by those involved in the reauthentication.
>>
Actually, I am not sure I understand what are you saying here Kurt.

>I tend to agree with this assessment.
>  
>
Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Thu, 6 Nov 2003 13:57:14 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: 'selects no security layer'
Sender: [email-masked]

On Thu, 6 Nov 2003, Kurt D. Zeilenga wrote:

> At 02:52 AM 11/6/2003, Alexey Melnikov wrote:
> >I would welcome any suggestions to make this clearer.
>
> I think one of the problems we have adding this profile option
> is that the specification is now much more complex and
> framework implementations, especially those which support both
> options, will need to be much more complex.  We need to keep
> SASL and the specification of SASL simple.

I have to agree with Kurt here.  One of the major benefits of SASL is that
the framework layer has been historically simple.  Allowing both modes
(dropping the layer or continuing under the old layer) needlessly
complicates the implementation and breaks backwards compatibility for
minimal gain.

> I don't see the risk from the described threat being so high
> to warrant the insertion of this option ESPECIALLY given that
> the option doesn't not fully address the vulnerability.  The
> information sent under the subsequent layers is still contains
> information known by those involved in the reauthentication.

I tend to agree with this assessment.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

Date: Thu, 06 Nov 2003 12:02:22 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2
Sender: [email-masked]

Section "4.2.  Authorization identities and proxy authentication", appears to be
mixing two totally different discussions together in a slightly confusing mess.

The first discussion is about there being two IDs being passed through the
mechanism (the authorization identity and the authentication identity) and how
they are used, including what it means for the authorization identity to be
empty and non-empty.

The second discussion that's intermingled with the first discussion is about the
  format of the two identities.

For example, consider this sentence:

    While some legacy
    mechanisms are incapable of transmitting an authorization identity
    other than the empty string, newly defined mechanisms are expected to
    be capable of carrying the entire Unicode repertoire (with the
    exception of the NUL character).

This sentence starts by saying that some legacy mechanisms don't provide an
authorization identity, but newly defined mechanisms are expected to. But it
never finishes saying that. Instead, it diverts the sentence into discussing
what the authorization identity should look like.

May I suggest that this section be rewritten so that it focusses on the two
topics separately. For example, something like the following below might be
considered.

	Tony Hansen
	[email-masked]

4.2.  Authorization and authentication identities, and proxy authentication

    SASL authentication deals with two identities: the authorization identity and
    the authentication identity. The transmitted authorization identity may be an
    empty string (zero length), but the transmitted authentication identity may
    not be an empty string.

    (While some legacy mechanisms are incapable of transmitting an authorization
    identity other than the empty string, newly defined mechanisms SHOULD be
    capable of transmiting a non-empty authorization identity.)

    The authorization identity is used by the server as the primary identity for
    making access policy decisions.

    With any mechanism, transmitting an authorization identity of the empty
    string directs the server to derive the authorization identity from the
    client's authentication identity.

    If the authorization identity transmitted during the authentication protocol
    exchange is not the empty string, this is typically referred to as "proxy
    authentication".  This feature permits agents such as proxy servers to
    authenticate using their own credentials, yet request the access privileges
    of the identity for which they are proxying.

    The server makes an implementation defined policy decision as to whether the
    authentication identity is permitted to have the access privileges of the
    authorization identity and whether the authorization identity is permitted to
    receive service.  If it is not, the server indicates failure of the
    authentication protocol exchange.

    As a client might not have the same information as the server, clients SHOULD
    NOT themselves try to derive authorization identities from authentication
    identities when clients could instead transmit an authorization identity of
    the empty string.

    The server SHOULD verify the correctness of a received authorization
    identity. Profiles whose authorization identities are simple user names (e.g.
    IMAP [RFC 3501]) are encouraged to employ [SASLPrep] profile [SASLPrep] of
    the "stringprep" algorithm [StringPrep] to prepare these names for matching.
    If the preparation of the authorization identity fails or results in an empty
    string, the server MUST fail the authentication exchange. The only exception
    to this rule is when the received authorization identity is already the empty
    string.

4.x Authorization Identity and Authentication Identity Formats

    An authorization identity and an authentication identity are strings of ISO
    10646 [ISO-10646] coded characters.  The NUL (U+0000) character is not
    permitted in authorization or authentication identities.

    The character encoding scheme used for transmitting an authorization identity
    over a protocol is specified in each authentication mechanism (with the
    authentication mechanism's blob being further restricted/encoded by the
    protocol profile). Per IETF character set policy [CHARSET-POLICY],
    authentication mechanisms SHOULD encode these and other strings in UTF-8
    [UTF-8]. Mechanisms are expected to be capable of carrying the entire Unicode
    repertoire (with the exception of the NUL character). An authorization
    identity of the empty string and and an absent authorization identity MUST be
    treated as equivalent.  However, mechanisms SHOULD NOT allow both (i.e. if an
    authorization identity is allowed to be absent, but one is transferred, it
    SHOULD NOT be an empty string).

Date: Thu, 06 Nov 2003 16:07:51 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis: 'selects no security layer'
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
>>Hallvard B Furuseth wrote:
>>    
>>
>>>rfc2222bis says:
>>>      
>>>
>>>>If a security layer is in effect and a subsequent SASL negotiation
>>>>selects no security layer, (...)
>>>>        
>>>>
>>>Please rephrase as either 'does not select a security layer' (like
>>>PLAIN) or '(explicitly) selects that there should be no security layer'
>>>(which PLAIN does _not_ do).  I presume it's the former.
>>>      
>>>
>>No, I actually mean both.
>>    
>>
>
>Now I'm confused.  If a SASL security layer is active and I authenticate
>with PLAIN, is the layer removed or not?  If it is removed, my first
>suggested text above clarifies that.  If it is not, my second text.  Are
>there other alternatives?
>
Using your own words: PLAIN (implicitly) selects that there should be no 
security layer, as it is unable to negotiate any.

>>DIGEST-MD5 has a mode when you can explicitly 
>>negotiate no security layer.
>>    
>>
>
>Where?  A search for 'layer' in rfc2831bis-02 only turns up the
>reference
>
>   [RFC 2222] Myers, J., "Simple Authentication and Security Layer
>              (SASL)", RFC 2222, October 1997.
>
Sections 2.3 and 2.4.

Also search for  "qop-options"

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

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

From: Hallvard B Furuseth <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: unauthenticated access without SASL layer
Date: Thu, 6 Nov 2003 16:37:53 +0100
Sender: [email-masked]

Kurt D. Zeilenga writes:
>At 02:58 AM 11/6/2003, Alexey Melnikov wrote:
>
>> IMHO, there is no point in a layer with a null cipher, it just adds
>> unnecessary SASL framing. Unless of course the layer does something
>> else.
> 
> It replaces the previous layers.  Hallvard wanted a way to do that,
> I assume for application protocols which only replace layers (don't
> deinstall them).

Yes.  It was a mistake to mention this in relation to an ANONYMOUS-like
auth, though.  It belongs in the 'selects no security layer' thread.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: unauthenticated access without SASL layer
Date: Thu, 6 Nov 2003 16:35:54 +0100
Sender: [email-masked]

Alexey Melnikov writes:
>Kurt D. Zeilenga wrote:
>>At 04:45 PM 11/5/2003, Hallvard B Furuseth wrote:
>>
>>> Looking over the various SASL drafts, I miss one piece of functionality:
>>> To authenticate anonymously, removing any SASL layer, but still
>>> providing an unauthenticated ID (e.g. for logging purposes).
>>> 
> How is this different from ANONYMOUS (except for @ sign requirement).

That's the difference.  If there is nothing special about the '@'
character in the underlying auth IDs, then the exclusion of names with
'@' in them is unnatural.  Though one could of course introduce a
private hack like using \ for a quote character and type @ as \40, or
something.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Date: Thu, 6 Nov 2003 16:22:20 +0100
Sender: [email-masked]

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
>>Alexey Melnikov writes:
>>  
>>>Also note, that if a subsequent authentication fails,
>>>the protocol profile MAY allow the connection state to return to
>>>non-authenticated,
>>
>>I can't find anything about that in section 5.  Is it this text?
>>
>>   "A protocol profile MAY further refine the definition of an
>>   authorization identity by adding additional syntactic restrictions
>>   and protocol-specific semantics."
>>
> No.
> This is a new text added to allow for LDAP behaviour.

That it allows for LDAP is fine, but I'm wondering about the text 'the
protocol profile MAY allow the connection state to return to
non-authenticated'.  If it's not the text I quoted, allowing the
connection state to return to non-authenticated has nothing to do with
the protocol profile at all.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis: 'selects no security layer'
Date: Thu, 6 Nov 2003 16:18:50 +0100
Sender: [email-masked]

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
>>rfc2222bis says:
>>
>>>If a security layer is in effect and a subsequent SASL negotiation
>>>selects no security layer, (...)
>>
>>Please rephrase as either 'does not select a security layer' (like
>>PLAIN) or '(explicitly) selects that there should be no security layer'
>>(which PLAIN does _not_ do).  I presume it's the former.
>>
> No, I actually mean both.

Now I'm confused.  If a SASL security layer is active and I authenticate
with PLAIN, is the layer removed or not?  If it is removed, my first
suggested text above clarifies that.  If it is not, my second text.  Are
there other alternatives?

> DIGEST-MD5 has a mode when you can explicitly 
> negotiate no security layer.

Where?  A search for 'layer' in rfc2831bis-02 only turns up the
reference

   [RFC 2222] Myers, J., "Simple Authentication and Security Layer
              (SASL)", RFC 2222, October 1997.

-- 
Hallvard

Date: Thu, 06 Nov 2003 07:14:25 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: rfc2222bis: 'selects no security layer'
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:52 AM 11/6/2003, Alexey Melnikov wrote:
>I would welcome any suggestions to make this clearer. 

I think one of the problems we have adding this profile option
is that the specification is now much more complex and
framework implementations, especially those which support both
options, will need to be much more complex.  We need to keep
SASL and the specification of SASL simple.

I don't see the risk from the described threat being so high
to warrant the insertion of this option ESPECIALLY given that
the option doesn't not fully address the vulnerability.  The
information sent under the subsequent layers is still contains
information known by those involved in the reauthentication.

Kurt 

Date: Thu, 06 Nov 2003 07:09:57 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: unauthenticated access without SASL layer
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:58 AM 11/6/2003, Alexey Melnikov wrote:
>>No.  If someone really wants this, they should define a new
>>mechanism which allowed for an unauthenticated identity and
>>a layer with a null cipher.
>IMHO, there is no point in a layer with a null cipher, it just adds unnecessary SASL framing. Unless of course the layer does something else. 

It replaces the previous layers.  Hallvard wanted a way to do that,
I assume for application protocols which only replace layers (don't
deinstall them).

This points out a serious problem with your suggestion that some
protocols can deinstall layers will others can leave them installed,
the applicability of the mechanism may be highly dependent on whether
all layers can be removed once established or not.

The more I think about adding the option to remove layers on
reauthentication, the more I think it is a bad idea.

Kurt

Date: Thu, 06 Nov 2003 11:14:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: unauthenticated access without SASL layer
Sender: [email-masked]

>
>
>>> Looking over the various SASL drafts, I miss one piece of 
>>> functionality:
>>> To authenticate anonymously, removing any SASL layer, but still
>>> providing an unauthenticated ID (e.g. for logging purposes).
>>>
> How is this different from ANONYMOUS (except for 

... @ sign requirement).

Alexey

Date: Thu, 06 Nov 2003 10:58:04 +0000
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: unauthenticated access without SASL layer
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>At 04:45 PM 11/5/2003, Hallvard B Furuseth wrote:
>  
>
>>Looking over the various SASL drafts, I miss one piece of functionality:
>>To authenticate anonymously, removing any SASL layer, but still
>>providing an unauthenticated ID (e.g. for logging purposes).
>>
How is this different from ANONYMOUS (except for

>>Am I missing something?  Should one of the mechanisms above be changed to allow this?
>>    
>>
>
>No.  If someone really wants this, they should define a new
>mechanism which allowed for an unauthenticated identity and
>a layer with a null cipher.
>
IMHO, there is no point in a layer with a null cipher, it just adds 
unnecessary SASL framing. Unless of course the layer does something else.

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

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Thu, 06 Nov 2003 10:52:30 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis: 'selects no security layer'
Sender: [email-masked]

Hallvard B Furuseth wrote:

>rfc2222bis says:
>  
>
>>If a security layer is in effect and a subsequent SASL negotiation
>>selects no security layer, (...)
>>    
>>
>
>Please rephrase as either 'does not select a security layer' (like
>PLAIN) or '(explicitly) selects that there should be no security layer'
>(which PLAIN does _not_ do).  I presume it's the former.
>  
>
No, I actually mean both. DIGEST-MD5 has a mode when you can explicitly 
negotiate no security layer.

I would welcome any suggestions to make this clearer.

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

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.ht

___________________________________________

Date: Thu, 06 Nov 2003 10:35:10 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
>>Ok, the new text reads:
>>    
>>
>>(...)
>>If a security layer
>>is in effect and a subsequent SASL negotiation selects no security layer,
>>the protocol profile has to specify a choice between:
>>
>>1) keeping the original security layer.
>>2) removing the original security layer (replacing with no layer).
>>    
>>
>
>This belongs in section 5 (Protocol Profile Requirements).
>
Yes, this is also mentioned in section 5 [in my copy].

>I suggest to indent (1) and (2), BTW.
>  
>
>>Also note, that if a subsequent authentication fails,
>>the protocol profile MAY allow the connection state to return to
>>non-authenticated,
>>    
>>
>
>I can't find anything about that in section 5.  Is it this text?
>
>   "A protocol profile MAY further refine the definition of an
>   authorization identity by adding additional syntactic restrictions
>   and protocol-specific semantics."
>
No.
This is a new text added to allow for LDAP behaviour.

>If so, maybe that sentence should be clarified to explicitly allow the
>protocol profile to say something about the effect of authentication on
>authentication/authorization IDs.
>  
>
Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Wed, 05 Nov 2003 17:40:07 -0800
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: unauthenticated access without SASL layer
Cc: [email-masked]
Sender: [email-masked]

At 04:45 PM 11/5/2003, Hallvard B Furuseth wrote:
>Looking over the various SASL drafts, I miss one piece of functionality:
>To authenticate anonymously, removing any SASL layer, but still
>providing an unauthenticated ID (e.g. for logging purposes).

>Am I missing something?  Should one of the mechanisms above be changed to allow this?

No.  If someone really wants this, they should define a new
mechanism which allowed for an unauthenticated identity and
a layer with a null cipher.

Kurt 

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: rfc2222bis: 'selects no security layer'
Date: Thu, 6 Nov 2003 02:00:33 +0100
Sender: [email-masked]

rfc2222bis says:
> If a security layer is in effect and a subsequent SASL negotiation
> selects no security layer, (...)

Please rephrase as either 'does not select a security layer' (like
PLAIN) or '(explicitly) selects that there should be no security layer'
(which PLAIN does _not_ do).  I presume it's the former.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: unauthenticated access without SASL layer
Date: Thu, 6 Nov 2003 01:45:58 +0100
Sender: [email-masked]

Looking over the various SASL drafts, I miss one piece of functionality:
To authenticate anonymously, removing any SASL layer, but still
providing an unauthenticated ID (e.g. for logging purposes).

LDAP provides this with the 'simple' non-SASL authentication choice,
except for the part about removing the SASL layer.

The ANONYMOUS mechanism (draft-ietf-sasl-anon-02.txt) can be used for
this - except if the desired ID contains '@', which means the ID is an
e-mail address.

The PLAIN mechanism (draft-ietf-sasl-plain-03.txt) could be used if an
empty password was allowed, but it isn't.

Am I missing something?
Should one of the mechanisms above be changed to allow this?

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: SASL WG <[email-masked]>
Subject: Re: Replacing a SASL security layer
Date: Thu, 6 Nov 2003 00:46:30 +0100
Sender: [email-masked]

Alexey Melnikov wrote:

> Ignore for a moment any relationship of realm to DIGEST-MD5,
> GSSAPI or any other SASL mechanism. Let's use the definition I
> have in the document:
>
> Conceptually, realm is the name of a collection of user's accounts.
> Realms allow the protected resources on a server to be partitioned into
> a set of protection spaces, each with its own authentication mechanisms
> and/or authorization database. For example, a proxy/frontend can use
> different realms for different servers/backends it represents.
>
> So, each "realm" ("a protection space") is served by a separate
> server (proxy example above) or a separate process/plugin
> (frontend-backend example). Does it make more sense now?

Not to me.  The client authenticates to server AA with realm A, and to
server BB with realm B.  So why does server BB see the traffic to server
AA?  Or if it doesn't, why does it know the realm A traffic, since that
belongs on server AA?  And why does the client send the same text to
server AA as to server BB, sans realm differences, so that server BB
can compare them?

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Date: Wed, 5 Nov 2003 22:32:30 +0100
Sender: [email-masked]

Alexey Melnikov writes:
> Ok, the new text reads:

> (...)
> If a security layer
> is in effect and a subsequent SASL negotiation selects no security layer,
> the protocol profile has to specify a choice between:
> 
> 1) keeping the original security layer.
> 2) removing the original security layer (replacing with no layer).

This belongs in section 5 (Protocol Profile Requirements).
I suggest to indent (1) and (2), BTW.

> Also note, that if a subsequent authentication fails,
> the protocol profile MAY allow the connection state to return to
> non-authenticated,

I can't find anything about that in section 5.  Is it this text?

   "A protocol profile MAY further refine the definition of an
   authorization identity by adding additional syntactic restrictions
   and protocol-specific semantics."

If so, maybe that sentence should be clarified to explicitly allow the
protocol profile to say something about the effect of authentication on
authentication/authorization IDs.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Date: Wed, 5 Nov 2003 20:49:53 +0100
Sender: [email-masked]

Alexey Melnikov writes:
> (...) Only a successful reauthentication is able replace/remove the
> previously negotiated security layer.

Just to make sure it has been mentioned:

This also means that non-SASL authentication must keep any old SASL
layer.  I expect that's intended, including for LDAPv4?

-- 
Hallvard

Date: Wed, 05 Nov 2003 19:39:19 +0000
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: SASL Working group agenda for IETF 58
Sender: [email-masked]

Sam Hartman wrote:

>               Simple Authentication and Security Layer
>                          Tuesday 1545-1645
>
>
>  0) Preliminaries - chairs - 10 min
>        Agenda / WG Status / etc.
>  1) Removing security layers on re-authentication discussion - editor - 10 min
>        (draft-ietf-sasl-rfc2222bis)
>
I think I've addressed the issue to satisfy both sides (see the message 
I've just sent to the mailing list).
Buf feel free to discuss this and let me know the outcome. Rob 
Siemborski is my "designed proxy" :-).

>  2) SASLprep "Full Stop" discussion - editor - 15 min
>        (draft-ietf-sasl-saslprep)
>  3) SMTP SASL issues affecting draft-ietf-sasl-* - editor - 10 minutes
>        (draft-siemborski-rfc2554bis)
>  4) Next steps / Milestones - chairs - 10 minutes
>  5) Open Mic - floor - remaining time
>  
>
Is it worth sending updated versions of SASL-base and DIGEST-MD5 
documents for the people to review during the meeting?

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

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Wed, 05 Nov 2003 19:32:17 +0000
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Sender: [email-masked]

Alexey Melnikov wrote:

> Alexey Melnikov wrote:
>
>>> The primary reason why this is better is because the change will cause
>>> significant interoperability problems.  Existing implementations expect
>>> those layers to remain in effect.
>>
>> How about changing MUST to SHOULD to allow for backward compatibility 
>> for LDAP? 
>
> Thinking more about this. What I didn't like about the original text 
> is that it was kind of MUST.
> What if I rephrase to allow a protocol profile to have a choice: 
> either keep the original layer if none was negotiated during 
> reauthentication (and have a security consideration about the issue) 
> or remove the original layer.
> If the protocol profile chooses to do the former, it should recommend 
> to always negotiate a new security layer during reauthentication. 

Ok, the new text reads:

If a profile explicitly permits multiple successful SASL
negotiations to occur, then in no case may multiple security layers be
simultaneously in effect.  If a security layer is in effect
and a subsequent SASL negotiation selects a second security layer,
then the second security layer replaces the first. If a security layer
is in effect and a subsequent SASL negotiation selects no security layer,
the protocol profile has to specify a choice between:

1) keeping the original security layer.
2) removing the original security layer (replacing with no layer).

RFC 2222 only allowed for the first choice, however it was later 
discovered that the choice is vulnerable to a security attack described 
later in this section. Thus, new protocol profiles should use the second 
choice. The protocol profiles that depend on RFC 2222 behaviour should 
recommend to always negotiate another security layer, once a security 
layer was installed.

Also note, that if a subsequent authentication fails,
the protocol profile MAY allow the connection state to return to
non-authenticated, however the previously negotiated security layer MUST NOT
be removed. Only a successful reauthentication is able replace/remove the
previously negotiated security layer.

Hopefully this will make everybody happy.

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

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

To: [email-masked]
Cc: [email-masked]
Subject: SASL Working group agenda for IETF 58
From: Sam Hartman <[email-masked]>
Date: Wed, 05 Nov 2003 11:33:11 -0500
Sender: [email-masked]

               Simple Authentication and Security Layer
                          Tuesday 1545-1645

  0) Preliminaries - chairs - 10 min
        Agenda / WG Status / etc.
  1) Removing security layers on re-authentication discussion - editor - 10 min
        (draft-ietf-sasl-rfc2222bis)
  2) SASLprep "Full Stop" discussion - editor - 15 min
        (draft-ietf-sasl-saslprep)
  3) SMTP SASL issues affecting draft-ietf-sasl-* - editor - 10 minutes
        (draft-siemborski-rfc2554bis)
  4) Next steps / Milestones - chairs - 10 minutes
  5) Open Mic - floor - remaining time

Date: Wed, 05 Nov 2003 10:30:24 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2831bis issues
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
>>Hallvard B Furuseth wrote:
>>    
>>
>>>draft-ietf-sasl-rfc2831bis-02.txt:
>>>      
>>>
>>>>       ( *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 )
>>>
>>>      
>>>
>>I can go for the last proposal. At least it seems to be the original intent.
>>    
>>
>
>I just realized that this was copied from rfc2616.
>
Correct.

>So it's probably
>better to leave it alone for compatibility's sake, or ask rfc2616's
>author.
>
I've already fixed several minor ABNF bugs. But it would be a good idea 
to keep DIGEST-MD5 and RFC 2616 in sync.

Alexey
__________________________________________

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

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

From: Hallvard B Furuseth <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2831bis issues
Date: Tue, 4 Nov 2003 22:16:11 +0100
Sender: [email-masked]

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
>>draft-ietf-sasl-rfc2831bis-02.txt:
>>>
>>>        ( *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 )
>>
>I can go for the last proposal. At least it seems to be the original intent.

I just realized that this was copied from rfc2616.  So it's probably
better to leave it alone for compatibility's sake, or ask rfc2616's
author.

-- 
Hallvard

Date: Mon, 03 Nov 2003 11:51:56 -0800 (PST)
From: Ienup Sung <[email-masked]>
Subject: Re: SASLPrep vs Full Stop code points
To: [email-masked], [email-masked]
Reply-to: Ienup Sung <[email-masked]>
Content-MD5: SfGydn3QK25i2FE+TDdj5Q==
Sender: [email-masked]

I agree that the SASLprep is more suitable and applicable for simple
user names and passwords and if the additional mappings such as the full
stops are needed, they are more suitable and correct to be done at
the outside of any Stringprep/Stringprep profiles and most preferrably before
the application of the Stringprep profile(s). <-- These are also my points
all along.

The reasons are like the following that the U+002E (full stop and dot/decimal
point) isn't the same or equivalent to the ideographic/Asian full stops
all the time; if they were, the Unicode itself would define them as
equivalent forms/characters and show canonical/compatiblity decomposition(s)
at each characters so that the Unicode normalizations would normalize
those characters into a (normalized) character.

Also, if everyone would agree on the fact that the ideopgraphic/Asian
full stops are not equivalent to the U+002E and yet we still need to support
the mappings described in the IDNA for the compatibility/interoperability on
the Internet domain style names (only), then, I'm also thinking that everyone
would agree this conditional mappings should be done outside of the Stringprep
and any of the Stringprep profiles (since the Stringprep itself doesn't
really allow conditional mappings at the mapping step as of today even though
a profile *possibly and maybe* could define such conditional mappings).

Re user provided strings, I have the following example that shouldn't match
as the same thing:

	3.14
	３。１４
	3。14

The first one is the pi, three point one four, in ASCII and the second is
three, ideographic full-stop, and fourteen in Asian full-width digit characters
and with ideographic full stop in UTF-8. (The third one is a variation of the
second one, three, ideographic full-stop, and fourteen in ASCII digits and
with ideographic full stop in UTF-8; and the second and the third can be
seen as equivalent.)

With regards,

Ienup

] Date: Fri, 31 Oct 2003 20:52:15 -0800
] From: "Kurt D. Zeilenga" <[email-masked]>
] Subject: Re: SASLPrep vs Full Stop code points
] X-Sender: [email-masked]
] To: Ienup Sung <[email-masked]>
] Cc: [email-masked], [email-masked]
] MIME-version: 1.0
] 
] At 05:42 PM 10/31/2003, Ienup Sung wrote:
] >Regarding the full stops, while I do understand the point of display vs.
] >storage/query string in my opinion, I think the issue boils down onto
] >the followign two things in my view:
] >1. Should/can we treat ideographic/Asian full stops as equivalent characters
] >   of the ASCII full stop (U+002E) in 100% of the possible cases/usages?
] 
] SASLprep is only applicable to two use cases: simple user names and password.
] 
] >   The answer is no since the U+002E is not only a full stop character but
] >   it is also a period and dot/decimal point character; CJK speakers do not 
use
] >   the ideographic/Asian full stops as the dot/decimal point character and
] >   hence some use of the ideographic/Asian full stops rather be preserved as
] >   they are to be distingushed. And in that cases, can we distinguish what to
] >   preserve and what not to preserve and map?
] 
] SASLprep scope is limited to preparation of user input strings for matching.
] Issues such as how to preserving the (unprepared) user input is simply beyond
] our scope as matching and hence SASLprep.
] 
] >2. Should/can we keep the compatiblity with the IDNA's additional and
] >   pre-processing on the label separators, i.e., mappings of all full stops 
to
] >   the U+002E, for the domain style (IDN) names before they are used?
] >   I think the answer should be yes.
] 
] SASLprep can define one preparation algorithm for simple user names and
] passwords.  Simple here implies the input has no structure.  That is,
] names have no particular style in respect to the algorithm.
] 
] It is possible that specification using SASLprep could apply additional
] transformations be done.  However, such transforms are beyond the scope
] of SASLprep.
] 
] >I know the above two sound conflicting and the example shown at the argument
] >#1 could be considered as a case that may not need to be really supported.
] >But I thought presenting them might be a valuable thing to do.
] 
] I would be interested in hearing whether you think the additional suggested
] mapping is appropriate or not for matching of simple user names or passwords,
] and why.
] 
] I think this issue boils down to whether the user provided strings:
]         <STRING1><U+002E><STRING2>
]         <STRING1><U+3003><STRING2>
]         <STRING1><U+FF0E><STRING2>
]         <STRING1><U+FF61><STRING2>
] 
] should match or not.  Because user names are often constructed from domain
] names, and IDNA says these stops are to be treated as equivalent, I believe
] they should match.
] 
] Kurt 
] 

Date: Sun, 02 Nov 2003 20:09:39 -0800
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt)
Cc: [email-masked]
Sender: [email-masked]

At 07:03 PM 11/2/2003, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>> I note that this issue is likely not unique to ANONYMOUS.  So, maybe
>> it should be dealt with in base SASL specification.
>> 
>> I'm thinking a malformed message should be treated as a protocol
>> error in the application protocol.

Note that application protocols generally give great freedom in
how protocol errors are treated.   And, the principle of "be liberal
in what you accept but strict in what your send" applies as well.

>How detailed should the checking for malformed messages be?

I think, in general, protocol peers should check each component
of the PDU which they make use of and then some.  For ANONYMOUS,
a server which uses the message should check that it is properly
encoded UTF-8 but a server which didn't make use of the message
could simply ignore the message.

>For example, is it a protocol error to send a latin-1 string when the
>protocol requires UTF-8?

Yes.

>How about sending an invalid UTF-8-like
>sequence, e.g. "\xC0\x80" which would encode '\0' if it was valid?

Yes.

Kurt 

From: Hallvard B Furuseth <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: malformed messages (Re: draft-ietf-sasl-anon-01.txt)
Date: Mon, 3 Nov 2003 04:03:48 +0100
Sender: [email-masked]

Kurt D. Zeilenga writes:
> I note that this issue is likely not unique to ANONYMOUS.  So, maybe
> it should be dealt with in base SASL specification.
> 
> I'm thinking a malformed message should be treated as a protocol
> error in the application protocol.

How detailed should the checking for malformed messages be?  For
example, is it a protocol error to send a latin-1 string when the
protocol requires UTF-8?  How about sending an invalid UTF-8-like
sequence, e.g. "\xC0\x80" which would encode '\0' if it was valid?

-- 
Hallvard

Date: Sat, 01 Nov 2003 20:43:09 +0000
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Sender: [email-masked]

Alexey Melnikov wrote:

>> The primary reason why this is better is because the change will cause
>> significant interoperability problems.  Existing implementations expect
>> those layers to remain in effect.
>>
> How about changing MUST to SHOULD to allow for backward compatibility 
> for LDAP? 

Thinking more about this. What I didn't like about the original text is 
that it was kind of MUST.
What if I rephrase to allow a protocol profile to have a choice: either 
keep the original layer if none was negotiated during reauthentication 
(and have a security consideration about the issue) or remove the 
original layer.
If the protocol profile chooses to do the former, it should recommend to 
always negotiate a new security layer during reauthentication.

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

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Sat, 01 Nov 2003 20:42:39 +0000
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Sender: [email-masked]

>>>The primary reason why this is better is because the change will cause
>>>significant interoperability problems.  Existing implementations expect
>>>those layers to remain in effect.
>>>      
>>>
>>How about changing MUST to SHOULD to allow for backward compatibility for LDAP?
>>    
>>
>A SHOULD would be inappropriate as interoperability mandates that either all
>implementations keep the layer or all implementations drop the layer.
>  
>
SHOULD in protocol profile, not "SHOULD keep/drop the old layer".

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

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Sat, 01 Nov 2003 12:35:06 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Cc: [email-masked]
Sender: [email-masked]

At 10:55 AM 11/1/2003, Alexey Melnikov wrote:
>The draft describes a potential security vulnerability.

I don't disagree that there is a potential security vulnerability.
I disagree that we should address it by changing the protocol.  The
issue can be (and, in my opinion, should be) addressed through statement
of appropriate security considerations.

I think we're talking about the same class of attacks.  There are
numerous cases where a third party (such as BB in your discussion)
have limited knowledge of protected content and could use that knowledge
to mount an attack.

Note that your solution doesn't complete eliminate this particular
case as the old layers are in-effect during the reauthentication.
Server BB could still use its knowledge of the reauthentication process
to attack the encryption of previously sent information.

I think the risk of this class of attack is not sufficient to warrant
changing the protocol especially considering the interoperability
(and security?) problems the change would cause.

I say "and security?" as now traffic which an old client expected to be
protected by old layers would not be protected.  We have to consider that
as well.

>I understand your concern about LDAP backward compatibility (as LDAP is the only protocol I know that allows for reauthentication),  but there is no point of propagating something which is known to be broken to new protocols.

I don't consider SASL broken in this respect.  It just that there are
security concerns to be considered.

>>The primary reason why this is better is because the change will cause
>>significant interoperability problems.  Existing implementations expect
>>those layers to remain in effect.
>How about changing MUST to SHOULD to allow for backward compatibility for LDAP?

A SHOULD would be inappropriate as interoperability mandates that either all
implementations keep the layer or all implementations drop the layer.

Kurt 

Date: Sat, 01 Nov 2003 19:41:35 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
>>>>>>>In
>>>>>>>order to avoid noninteroperability due to differing normalizations,
>>>>>>>when a mechanism specifies that a string authentication identity or
>>>>>>>password used as input to a cryptographic function (or used for
>>>>>>>comparison) it SHOULD specify that the string first be prepared using
>>>>>>>the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm
>>>>>>>[StringPrep].
>>>>>>>              
>>>>>>>
>>The new text after that reads:
>>
>>There are three entities that has to deal with this issue: a client
>>(upon getting user input or retrieving a value from configuration), a server
>>(upon receiving the value from the client) and a utility that is able to 
>>store
>>passwords/hashes in a database that can be later used by the server.
>>The preparation must be done by the client and the utility and may be 
>>done by the
>>server. If preparation fails or results in an empty string, the entity doing
>>the preparation SHALL fail the authentication exchange.    
>>
>
>I like Kurt's suggestion better: The mechanism must define where
>preparation is done.  That way clients using mechanisms like PLAIN can
>leave as much work as possible to the server.
>
I've updated the draft to say that each mechanism must describe where 
preparation takes place.

Alexey

Date: Sat, 01 Nov 2003 18:55:46 +0000
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>Alexey,
>
>RFC 2222 said:
>  If a security layer is in effect and a subsequent SASL negotiation
>  selects no security layer, the original security layer remains in effect.
>
>I think changing this is bad.
>
>The primary reason posted on the list for the change was: "Applications
>should be allowed to remove layers."   I argue that this is, effective,
>adding a new feature to SASL.  Adding new features is beyond our scope.
>
I never said that and I don't believe this is an important feature.

>The primary reason given in the draft is to address a security concern.
>I would suspect that there are numerous other cases, including where
>re-authentication is not involved, where another party may have direct
>knowledge of information being encrypted.  For example, the same concern
>arises when an LDAP server provides results obtained through chaining.
>Or by an LDAP client is chasing a referral.  This concerns, I think,
>would be better addressed by stating security consideration.
>
Kurt, I think you are missing the point. You are describing authorized 
disclosure (or something similar to a situation when one end of the 
connection is broadcasting decrypted data over the network in the 
clear). The draft describes a potential security vulnerability.
I understand your concern about LDAP backward compatibility (as LDAP is 
the only protocol I know that allows for reauthentication),
but there is no point of propagating something which is known to be 
broken to new protocols.

>The primary reason why this is better is because the change will cause
>significant interoperability problems.  Existing implementations expect
>those layers to remain in effect.
>
How about changing MUST to SHOULD to allow for backward compatibility 
for LDAP?

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

Cell: +44 7753759732

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

Date: Sat, 01 Nov 2003 10:15:42 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

Alexey,

RFC 2222 said:
  If a security layer is in effect and a subsequent SASL negotiation
  selects no security layer, the original security layer remains in effect.

I think changing this is bad.

The primary reason posted on the list for the change was: "Applications
should be allowed to remove layers."   I argue that this is, effective,
adding a new feature to SASL.  Adding new features is beyond our scope.

The primary reason given in the draft is to address a security concern.
I would suspect that there are numerous other cases, including where
re-authentication is not involved, where another party may have direct
knowledge of information being encrypted.  For example, the same concern
arises when an LDAP server provides results obtained through chaining.
Or by an LDAP client is chasing a referral.  This concerns, I think,
would be better addressed by stating security consideration.

The primary reason why this is better is because the change will cause
significant interoperability problems.  Existing implementations expect
those layers to remain in effect.

Kurt

At 06:22 AM 11/1/2003, Alexey Melnikov wrote:

>>>>rfc2222bis section 6.3 "Multiple authentications" says:
>>>>
>>>> If a security layer is in effect
>>>> and a subsequent SASL negotiation selects a second security layer,
>>>> then the second security layer replaces the first. If a security
>>>> layer is in effect and a subsequent SASL negotiation selects no
>>>> security layer, the original security layer must be removed.
>>>>
>>>>Exactly when is the old layer canceled?
>>>>
>>>>If an old layer is active and the client starts to negotiate a new
>>>>layer, it may not know when to expect the response from the server.
>>>>So the layer can't be canceled by starting a new negotiation.
>>>>     
>>>No, the layer can only be canceled/replaced after a subsequent authentication completes successfully.    
>>
>>OK.  Please mention that explicitly.
>After rereading the LDAP document that discusses SASL I finally realised why this is not obvious :-). The new text reads:
>
>If a profile explicitly permits multiple successful SASL
>negotiations to occur, then in no case may multiple security layers be
>simultaneously in effect.  If a security layer is in effect
>and a subsequent SASL negotiation selects a second security layer,
>then the second security layer replaces the first. If a security layer
>is in effect and a subsequent SASL negotiation selects no security layer,
>the original security layer MUST be removed. The rest of this section explain
>why this is important. Also note, that if a subsequent authentication fails,
>the protocol profile MAY allow the connection state to return to non-authenticated,
>however the previously negotiated security layer MUST NOT be removed. Only
>a successful reauthentication is able replace/remove the previously negotiated
>security layer.
>
>>>Each profile document must document exactly when this takes place.    
>>
>>'this' = 'it completed successfully', I take it.
>> 
>Yes.
>
>Alexey
>__________________________________________
>Isode Limited, http://www.isode.com
>
>IETF standard related pages:
>http://orthanc.ab.ca/mel/devel/Links.html
>__________________________________________
>

Date: Sat, 01 Nov 2003 09:34:54 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Consensus call: changing examples from ACAP to SMTP
Cc: Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

At 06:06 AM 11/1/2003, Alexey Melnikov wrote:

>Sam Hartman wrote:
>
>>Hi.  The discussion seems to have died down on the issue of replacing
>>the ACAP example with an SMTP example in the plain draft.
>>
>>The rough consensus of this working group is that we will not change
>>to an SMTP-based example.  We seem to believe that the examples in the
>>plain document should illustrate that mechanisms, not illustrate common
>>implementation errors in other related protocols.
>>
>>I think that we have something approaching a consensus that we will be
>>better served by encouraging implementers to read all the appropriate
>>documents than to include information designed to make sure that
>>implementers will not make mistakes even if they do not read the
>>appropriate documents.  That's not as clear as the consensus against
>>changing the example to SMTP; there may be more room for discussion on
>>this issue.
>>
>>Personally I believe that we may want to consider ways in which we can
>>make it clear to implementers what documents they want to read.
>I suggest the following:
>1). Don't change examples in PLAIN

As I previously noted, I intend to offer another example illustrating
another aspect of the PLAIN feature for WG consideration.  But I am going
to be very careful to avoid getting into the details more appropriately
discussed in referencing documents.

>2). Implementation consideration section is added to the base SASL document.

I am a bit leery of adding another section to the base SASL document
(especially at this late stage).  It may be better, as was suggested by
someone else, to instead write an "SASL Implementation Guide" as a separate
document.  I think, however, most of the problems and their solutions are
application protocol specific and, hence, should be addressed in documents
specific to application protocol.

>It will list commonly misimplemented features and will give some protocol examples.
>I will make sure that SMTP PLAIN example is one of the examples.

Depending on what you intend to illustrate, SMTP may not be the best
protocol for the example.  (See prior discussion.)

>Reference to PLAIN will be informative. (Or this can be a separate document as discussed recently).

Again, we need to avoid trumping application profile documents in documents
they reference.  We need to ensure that any example (and as well as prose) is
properly placed in the right document.

Now, depending on example what kind of examples you had in mind, they may or
may not be appropriate.

For instance, examples showing the initial response (without challenge) and
final challenge (without response) would likely be useful.  But we need to
be careful not to specify how exchanges are to be implemented in any
particular application-level protocol.

I suggest you offer specific text to the list for WG consideration.

>3). I am thinking about [co-]authoring a document that is "protocol profile designer guide". It will compare existing protocols and how different features are implemented in them. This can be the same document as in 2, or a separate document.

As a separate document, I think this is a good idea.

Kurt 

Date: Sat, 01 Nov 2003 08:17:41 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Fwd: Re: draft-ietf-sasl-rfc2222bis-02 comments
Cc: [email-masked]
Sender: [email-masked]

>Date: Sat, 01 Nov 2003 15:33:40 +0000
>From: Alexey Melnikov <[email-masked]>
>To: Hallvard B Furuseth <[email-masked]>
>CC: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
>Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
>List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
>
>
>Hallvard B Furuseth wrote:
>>>>>We should not suggest that mechanisms should do both (1) and
>>>>>(2).  (1) and (3) OR (2) or (3) are sufficient to ensure
>>>>>proper matching.
>>>>>       
>>>>IMHO, this is a responsibility of the client,
>>>>     
>>
>>Disagree.  It's the responsibility of the mechanism definition to say
>>where it should happen.
>Ok.
>But in all SASL mechanisms I know the client end sends username or retrieves-hashes-sends something derived from a password.
>So, so far this is the same thing ;-).

There are certainly mechanisms which don't transfer a username (authentication
identity in simple form) and/or don't transfer a value derived from a simple
password.  (For example, EXTERNAL.)  And for those which do, it should be left
up to the mechanism to state where preparation of those strings is to be done.

The framework specification should avoid getting details which are mechanism-specific.

Kurt 

Date: Sat, 01 Nov 2003 15:33:40 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
Sender: [email-masked]

Hallvard B Furuseth wrote:

>>>>We should not suggest that mechanisms should do both (1) and
>>>>(2).  (1) and (3) OR (2) or (3) are sufficient to ensure
>>>>proper matching.
>>>>        
>>>>
>>>IMHO, this is a responsibility of the client,
>>>      
>>>
>
>Disagree.  It's the responsibility of the mechanism definition to say
>where it should happen.
>
Ok.
But in all SASL mechanisms I know the client end sends username or 
retrieves-hashes-sends something derived from a password.
So, so far this is the same thing ;-).

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

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

Date: Sat, 01 Nov 2003 15:09:20 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2831bis issues
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
>>>>2.1.1  Step One
>>>>
>>>>  The server starts by sending a challenge.
>>>>        
>>>>
>>>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?
>>    
>>
>
>'The server starts by sending a challenge after the client indicates
>that SASL negotiatin should start'?
>  
>
SASL framework doesn't support the case when the server initiate 
authentication exchange.
The only way to do that is for the server to return some kind of 
"authentication required" error code when the client tries to issue 
other commands.

> ...
>
>>>>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.
>>>      
>>>
>>This is a case of fast reauthentication using a different TCP 
>>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?
>  
>
Actually, this can be done on the same connection, if the protocol 
supports reauthentication.

I've added the following:
Note, that a subsequent authentication can be done on a different 
connection, or on the same connection, if the protocol profile also
permits multiple authentications.

I've also added some clarification text at the beginning of section 2.

Alexey

Date: Sat, 01 Nov 2003 14:41:30 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2831bis: A2 when qop-value=token
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
>>Hallvard B Furuseth wrote:    
>>
>>>rfc2831bis 2.1.1 "Step One" says:
>>>
>>>       qop-options       = "qop" "=" <"> qop-list <">
>>>       qop-list          = 1#qop-value
>>>       qop-value         = "auth" | "auth-int" | "auth-conf" |
>>>                            token
>>>
>>>2.1.2.1 "Response-value" and 2.1.3 "Step Three" define A2 when qop is
>>>"auth", "auth-int" and "auth-conf", but not when it is <token>.
>>>      
>>>
>>Token is specifically for future extensions, if you see a qop value you 
>>don't recognize - you have to ignore it.
>>If you recognize nothing, you have to fail the authentication exchange.
>>
>>Do you want any clarifications on this to be added to the document.
>>    
>>
>
>Not sure.  I think it would be good to mention that 'token is for future
>extensions' somewhere.  And perhaps that these extensions must define
>A2, since rfc2831bis does not.
>
Ok, I've clarified this.

Alexey

Date: Sat, 01 Nov 2003 14:22:06 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2222bis: re-negotiating SASL security layer
Sender: [email-masked]

>
>
>>>rfc2222bis section 6.3 "Multiple authentications" says:
>>>
>>>  If a security layer is in effect
>>>  and a subsequent SASL negotiation selects a second security layer,
>>>  then the second security layer replaces the first. If a security
>>>  layer is in effect and a subsequent SASL negotiation selects no
>>>  security layer, the original security layer must be removed.
>>>
>>>Exactly when is the old layer canceled?
>>>
>>>If an old layer is active and the client starts to negotiate a new
>>>layer, it may not know when to expect the response from the server.
>>>So the layer can't be canceled by starting a new negotiation.
>>>      
>>>
>>No, the layer can only be canceled/replaced after a subsequent 
>>authentication completes successfully.    
>>
>
>OK.  Please mention that explicitly.
>
After rereading the LDAP document that discusses SASL I finally realised 
why this is not obvious :-). The new text reads:

If a profile explicitly permits multiple successful SASL
negotiations to occur, then in no case may multiple security layers be
simultaneously in effect.  If a security layer is in effect
and a subsequent SASL negotiation selects a second security layer,
then the second security layer replaces the first. If a security layer
is in effect and a subsequent SASL negotiation selects no security layer,
the original security layer MUST be removed. The rest of this section 
explain
why this is important. Also note, that if a subsequent authentication fails,
the protocol profile MAY allow the connection state to return to 
non-authenticated,
however the previously negotiated security layer MUST NOT be removed. Only
a successful reauthentication is able replace/remove the previously 
negotiated
security layer.

>>Each profile document must document exactly when this takes place.    
>>
>
>'this' = 'it completed successfully', I take it.
>  
>
Yes.

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

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________

Date: Sat, 01 Nov 2003 14:06:37 +0000
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: Consensus call: changing examples from ACAP to SMTP
Sender: [email-masked]

Sam Hartman wrote:

>Hi.  The discussion seems to have died down on the issue of replacing
>the ACAP example with an SMTP example in the plain draft.
>
>The rough consensus of this working group is that we will not change
>to an SMTP-based example.  We seem to believe that the examples in the
>plain document should illustrate that mechanisms, not illustrate common
>implementation errors in other related protocols.
>
>I think that we have something approaching a consensus that we will be
>better served by encouraging implementers to read all the appropriate
>documents than to include information designed to make sure that
>implementers will not make mistakes even if they do not read the
>appropriate documents.  That's not as clear as the consensus against
>changing the example to SMTP; there may be more room for discussion on
>this issue.
>
>Personally I believe that we may want to consider ways in which we can
>make it clear to implementers what documents they want to read.
>
I suggest the following:
1). Don't change examples in PLAIN
2). Implementation consideration section is added to the base SASL 
document. It will list commonly misimplemented features and will give 
some protocol examples. I will make sure that SMTP PLAIN example is one 
of the examples. Reference to PLAIN will be informative.
(Or this can be a separate document as discussed recently).
3). I am thinking about [co-]authoring a document that is "protocol 
profile designer guide". It will compare existing protocols and how 
different features are implemented in them. This can be the same 
document as in 2, or a separate document.

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

Cell: +44 7753759732

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

Date: Sat, 01 Nov 2003 13:39:57 +0000
From: Alexey Melnikov <[email-masked]>
To: Hallvard B Furuseth <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-sasl-rfc2222bis-02 comments
Sender: [email-masked]

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
>>Hallvard B Furuseth wrote:
>>    
>>
>>>Alexey Melnikov writes:
>>>      
>>>
>>>>Hallvard B Furuseth wrote:
>>>>        
>>>>
>>>>>>4.1.  Authentication protocol exchange
>>>>>>            
>>>>>>
>>>Anyway, I think I found the answer in section 6.1.  The initial auth
>>>command from the client is not part of the exchange, but the optional
>>>"response" in the auth command is.
>>>      
>>>
>>Sorry, this makes little sense to me.
>>Semantically the initial response *is* part of an authentication 
>>exchange.
>>    
>>
>
>That's what I wrote.
>
Ok, but I think arguing whether the initial auth command is part of an 
exchange or not is not worth the time.

>>>>>>4.2.  Authorization identities and proxy authentication
>>>>>>
>>>>>> (...)
>>>>>> The character encoding scheme used for transmitting an authorization
>>>>>> identity over protocol is specified in each authentication mechanism
>>>>>> (with the authentication mechanism's blob being further
>>>>>>            
>>>>>>
>>>>>                                       ^^^^
>>>>>
>>>>>What's a blob?  I don't think it's 'something ill-defined or amorphous',
>>>>>like the dictionary says:-)
>>>>>
>>>>>          
>>>>>
>>>>I've changed this to "data".
>>>>        
>>>>
>>>I still don't know _which_ data you are talking about.
>>>
>>>      
>>>
>>Data is defined (and specific to) by each SASL mechanism.
>>    
>>
>
>Is the text in the ()'s just saying that the SASL mechanism restricts
>the data sent between client and server to more than just being random
>strings in the character encoding scheme?
>
No, it talks about encoding data. The data itself is arbitrary binary 
data as far as the protocol is concerned.

>  Well, of course.  Why mention
>that at all?  If not, I still don't understand what this () is saying.
>
>  
>
>>>>>And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the
>>>>>top.
>>>>>
>>>>>          
>>>>>
>>>>I've added a sentence about this in the introduction section.
>>>>        
>>>>
>>>I'm pretty sure you will still need to insert the words "Obsoletes: rfc
>>>2222" in the header sometime, though I don't remember where this is
>>>stated.
>>>
>>>      
>>>
>>I think this is going to be added by a RFC editor.
>>    
>>
>I couldn't find anything saying so.  I did find rfc2223 (Instructions
>to RFC Authors) section 4, which lists 'Obsoletes:' as things it asks
>you to insert.  rfc2223 does say that the RFC Editor may make some
>changes, but preferably as few as possible, and it doesn't mention
>that one.
>
Ok, I will make sure that Obsoletes: will be inserted.

Alexey

Date: Sat, 01 Nov 2003 13:34:41 +0000
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: Agenda items to discuss
Sender: [email-masked]

Sam Hartman wrote:

>There has been a lot of discussion on the list since the last IETF and
>I'm curious which issues actually need meeting time.  I'd appreciate
>it if people could suggest issues that still seem to be open.
>
>Thing I think may be open or need discussion are:
>
>* Initial server challenges especially as they interact with SMTP
>
I think there is nothing to discuss here. There are bugs in existing 
implementation and this need to be clarified with additional examples.

>* Security layer replacement in the base SASL spec
>* Authorization ID text (data vs blob, confusion about restriction, etc)
>* There was some discussion of multiple layers of encryption (TLS vs security layers) in XMPP; do we want
>to develop guidance for protocol designers on this issue?
>
>I think most of the other changes that have been brought forward have
>been resolved; please correct me if I'm wrong.  I think Greg's
>comments on implementing SASL have not suggested any specific changes
>to documents that need discussion.
>
>
>There's also been a lot of IDN related discussion in the Kerberos
>working group.  So far, I don't think any of that discussion affects
>saslprep.  If any of those issues do end up affecting saslprep, we may
>at least want to be aware of them.  I'll review those discussion
>within the next week.
>
>  
>
Cheers,

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

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html
__________________________________________