Subject: Re: FW: SASL base spec WGLC

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Aug 2004 11:23:50 -0400

Scott Hollenbeck wrote:

> I sent a request to the apps discuss list a while back and didn't receive
> any responses.  OK, time for a more pointed request: would at least one of
> you PLEASE take some time to review draft-ietf-sasl-rfc2222bis-08 from an
> applications perspective?  It's in WGLC and the SASL WG chair is asking for
> review help.

I just spent an hour or so reviewing the -08 draft.  I have a couple of 
comments and questions below.  Other than these, I don't see anything 
which breaks any of the existing mechanisms, libraries, or applications 
that I'm familiar with.  I have a few editorial nits which I'll send 
separately to Alexey.

Section 4, requirement 2)  -  The draft says that "the protocol profile 
SHOULD also describe how an empty initial response is encoded."  I 
believe that this should be required of the profile and therefore is a 
MUST, not a SHOULD.

Section 4, requirement 3)  -  Should we explicitly state that the 
profile also needs to describe how *empty* server challenges and client 
responses as encoded?

Section 7, paragraph 3  -  The draft says "The server uses information, 
external to SASL, to determine whether the client is permitted to 
authenticate as the authorization identity."  Presumably, the client has 
*already* been authenticated by external means and we're just 
determining if the client can proxy.  Unless I'm completely missing the 
meaning of the existing text, I'd suggest replacing "authenticate as" 
with "have the access privileges of".

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Aug 2004 11:17:51 +0100

Ken Murchison wrote:

> I just spent an hour or so reviewing the -08 draft.  I have a couple 
> of comments and questions below.  Other than these, I don't see 
> anything which breaks any of the existing mechanisms, libraries, or 
> applications that I'm familiar with.  I have a few editorial nits 
> which I'll send separately to Alexey.
>
> Section 4, requirement 2)  -  The draft says that "the protocol 
> profile SHOULD also describe how an empty initial response is 
> encoded."  I believe that this should be required of the profile and 
> therefore is a MUST, not a SHOULD. 

You are probably right.
The initial response is a SHOULD feature of SASL, that is why, I think,
SHOULD is used here.

So basically the document should say: "if the initial response is
supported by the protocol profile, the profile MUST specify how an empty
response is encoded".

> profile also needs to describe how *empty* server challenges and 
> client responses as encoded?

Not really, as empty challenge/response is a 0-length string, which all
profiles should be able to handle already.
But I am Ok with clarifying that all protocol profiles MUST be able to
exchange 0-length challenges/responses.

> Section 7, paragraph 3  -  The draft says "The server uses 
> information, external to SASL, to determine whether the client is 
> permitted to authenticate as the authorization identity."  Presumably, 
> the client has *already* been authenticated by external means and 
> we're just determining if the client can proxy.  Unless I'm completely 
> missing the meaning of the existing text, I'd suggest replacing 
> "authenticate as" with "have the access privileges of". 

I agree, but I suggest to replace "to authenticate as" with "to act as".

Alexey

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Aug 2004 11:23:50 -0400

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Aug 2004 11:17:51 +0100

You are probably right.

Alexey