Subject: Moving to rfc2222bis last call

From: [email-masked] (Sam Hartman)
Date: Mon, 1 Dec 2003 12:44:09 -0500 (EST)

What are we still waiting on before the next last call of this
document?

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 2 Dec 2003 10:20:55 +0100

> What are we still waiting on before the next last call of this

I think this document needs another version before it is ready for last
call.  Here is the unfinished business I'm aware of:

------------------------------------------------------------------------

The 'suggested text about multiple SASL mechanisms' thread.

------------------------------------------------------------------------

Subject: [Fwd: Keeping/dropping existing SASL security layer]
From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Nov 2003 20:35:01 +0000
Message-ID: <[email-masked]>
URL: http://www.imc.org/ietf-sasl/mail-archive/msg01312.html

Alexey's attack when keeping an old security layer.  He sent it to Rob
and me before the list, and I replied that I still did not understand,
with a list of where I got lost.

------------------------------------------------------------------------

Subject: Re: rfc2222bis: re-negotiating SASL security layer
From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 11 Nov 2003 22:24:45 +0100
Message-Id: <[email-masked]>
URL: http://www.imc.org/ietf-sasl/mail-archive/msg01313.html

When can a security layer be removed?  What I said in this message seems
to reflect what Alexey said last, but I don't quite think that's what he
meant...

------------------------------------------------------------------------

Subject: Re: rfc2222bis: protocol profile?
From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 10 Nov 2003 08:10:22 +0100
Message-Id: <[email-masked]>
URL: http://www.imc.org/ietf-sasl/mail-archive/msg01304.html

What belongs in the protocol profile?

------------------------------------------------------------------------

Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2
From: Tony Hansen <[email-masked]>
Date: Thu, 06 Nov 2003 12:02:22 -0500
Message-ID: <[email-masked]>
URL: http://www.imc.org/ietf-sasl/mail-archive/msg01278.html

Split section 4.2 (Authorization identities and proxy authentication).
It appears to be mixing two totally different discussions together in a
slightly confusing mess.

------------------------------------------------------------------------

The 'selects no security layer' thread.  I've lost track of this one and
will have to reread it.  But originally all I wanted was to clarify that
specific phrase: either to 'does not select a security layer' or
'selects that there shall be no security layer', or whatever else is
meant.  That has not been done yet.

------------------------------------------------------------------------

-- 
Hallvard

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 3 Dec 2003 16:36:33 -0500 (EST)

>From the minutes, we need to see an updated security considerations
section (for the MITM attack), and we need examples for the initial client
response and server last sends.

-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: Alexey Melnikov <[email-masked]>
Date: Fri, 05 Dec 2003 12:19:23 +0000

>What are we still waiting on before the next last call of this
Rob's assessment is right.
I also need to work on some issues raised by Hallvard.

I am a bit busy at the moment. I will try to push a new revision in a 
week or so.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 14 Dec 2003 16:13:15 +0000

>call.  Here is the unfinished business I'm aware of:
I think this is done.

<some issues skipped, will reply to them separately>

I will ignore this one, unless you have a specific suggestion/text.
I am not sure I can give you a generic future proof advice.

This is done. I had to merge my recent changes with the proposed text.

I think I've addressed the particular issue by saying that mechanism 
that are incapable of negotiating a security layer always select "no layer".

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]>
Date: Mon, 15 Dec 2003 10:56:00 +0100

> I am not sure I can give you a generic future proof advice.

I can't offer any suggestions because I don't know what belongs there.
I think what I'm really missing is a description of the purpose of the
protocol profile.  What will it be used for?  What is it _not_ intended
to be used for?  Knowing that, the reader (and I) can judge for himself
what should go in it, besides the mandatory items.

> that are incapable of negotiating a security layer always select "no layer".

OK, if the quotes are in place, or otherwise the new wording can't be
interpreted as "doesn't select a (new) layer".

-- 
Hallvard

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 Dec 2003 13:22:00 -0500

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

    Hallvard> I can't offer any suggestions because I don't know what
    Hallvard> belongs there.  I think what I'm really missing is a
    Hallvard> description of the purpose of the protocol profile.
    Hallvard> What will it be used for?  What is it _not_ intended to
    Hallvard> be used for?  Knowing that, the reader (and I) can judge
    Hallvard> for himself what should go in it, besides the mandatory
    Hallvard> items.

Does anyone else feel this issue requires additional clarification?

---

From: Rob Siemborski <[email-masked]>
Date: Mon, 15 Dec 2003 14:41:17 -0500 (EST)

> What are we still waiting on before the next last call of this

I just noticed that the EXTERNAL mechanism doesn't have any limits on how
big the client response can be.

Are servers expected to handle responses of arbitrary length here, or can
they get away with saying "we don't support authorization identifiers
longer than x"?

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Dec 2003 12:12:08 -0800

At 11:41 AM 12/15/2003, Rob Siemborski wrote:

>Are servers expected to handle responses of arbitrary length here,

I assume they should be able to 'handle' (not choke) authzid of
any length but can refuse to accept any authzid for any reason
(including it just being unreasonably long).

>or can

They just generally should fail the exchange if the asserted
authzid is too long (whatever that means to them).  Of course,
if the server believes the client to be rouge, it can (and
likely should) just drop the protocol steam.

I do not think we should impose any artificial limit here
as reasonable lengths.  Where absolutely needed, they should
be stated in application-level profiles (as they own the
form of the authzid).

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 2 Dec 2003 10:20:55 +0100

-- 
Hallvard

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 3 Dec 2003 16:36:33 -0500 (EST)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 05 Dec 2003 12:19:23 +0000

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 14 Dec 2003 16:13:15 +0000

I think this is done.

Alexey

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 15 Dec 2003 10:56:00 +0100

-- 
Hallvard

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 Dec 2003 13:22:00 -0500

---

From: Rob Siemborski <[email-masked]>
Date: Mon, 15 Dec 2003 14:41:17 -0500 (EST)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Dec 2003 12:12:08 -0800

Kurt