Subject: Comments about draft-myers-saslrev-00.txt

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Apr 2001 22:38:12 -0600

Mostly editorial stuff:

1).
>1.    Abstract
>
>   This document describes a method for adding authentication support
to
>   connection-based protocols.  To use this specification, a protocol
>   includes a command for identifying and authenticating a user to a
>   server and for optionally negotiating protection of subsequent
>   protocol interactions.  If its use is negotiated, a security layer
is
>   inserted between the protocol and the connection.  This document
>   describes how a protocol specifies such a command, defines several
------------------------------------------------------------------^
only EXTERNAL left, this should be "a mechanism"
>   mechanisms for use by the command, and defines the protocol used for

>   carrying a negotiated security layer over the connection.

2).
>4.3.  Security layers
[skipped]
>   The length of the security encoded data buffer must be no
>   larger than the maximum size that was either defined in the
mechanism
>   specification or negotiated by the other side during the
>   authentication protocol exchange.

Implementers warning: Several implementations don't check whether size
of encoded SASL block exceed their maximum acceptable block size.

3). I think the existence of 6.2. (Server returns success with
additional data) and 6.3. (Multiple authentications) should be mentioned
in section 5, because people will use section 5 as a checklist:

"Protocol profile SHOULD allow server to return additional data with
success (see section 6.2)."
  and
"Unless specified by protocol profile, multiple authentications are not
allowed (see section 6.3)"

4).
>7.    Registration procedures
>
>   Registration of a SASL mechanism is done by filling in the template
>   in section 7.4 and sending it in to [email-masked].  IANA has the
right
>   to reject obviously bogus registrations, but will perform no review
>   of clams made in the registration form.
-------^ claims?

More substantial comments:

1). I remember there was a discussion during some IETF meeting about
adding initial server challenge (for example, CRAM-MD5 can take
advantage of that).

2). DIGEST-MD5 has various number of authentication steps. Either SASL
spec should explicitly allow that or DIGEST-MD5 spec should define 2
separate mechanisms.

3). SASL spec should say how SASL security layer interacts with TLS
encryption. If SASL allows, for example, to negotiate DIGEST-MD5
confidentiality on top of TLS encryption (or other way around) then the
document should specify in which order they should be encoded/decoded.

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 19 Apr 2001 14:58:39 -0700

> >   describes how a protocol specifies such a command, defines several

That text does not appear in draft-myers-saslrev-00.txt.  Are you sure
you're reviewing the right document?

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Apr 2001 16:33:31 -0600

> you're reviewing the right document?

I was referencing the version you've sent in email message.

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 19 Apr 2001 15:56:00 -0700

> I was referencing the version you've sent in email message.

That has been superseded by the version in the internet-drafts
repository.

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 24 Apr 2001 17:14:57 -0700

> in section 5, because people will use section 5 as a checklist:

I'd really rather not go there.  Any implementation checklist needs to
include all of section 6.  Section 5 should only mention things which
affect the definition of protocol profiles.

> adding initial server challenge (for example, CRAM-MD5 can take

This is a difficult change, as there are already two other optimizations
optional to protocol profiles.  I'd prefer to just say we have enough.

> spec should explicitly allow that or DIGEST-MD5 spec should define 2

What exactly would you change?  I believe the spec already allows the
behavior of DIGEST-MD5.  Section 4.1 permits a server mechanism to
indicate successful completion after any authentication command or
client response.

The one issue I see is that 4.1 doesn't allow for the possibility of
returning additional data with successful completion.  I will clarify
this.

> document should specify in which order they should be encoded/decoded.

I disagree that we should specify this.  We can only get it wrong. 
Without additional wording, the ordering is obvious from the layering.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Apr 2001 20:26:52 -0600

> affect the definition of protocol profiles.

But section 6 *does* affect a protocol profile.

> optional to protocol profiles.  I'd prefer to just say we have enough.

Understood.

> Without additional wording, the ordering is obvious from the layering.

One of the reasons I've asked was because BEEP explicitly prohibits that.

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 19 Apr 2001 14:58:39 -0700

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Apr 2001 16:33:31 -0600

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 19 Apr 2001 15:56:00 -0700

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 24 Apr 2001 17:14:57 -0700

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Apr 2001 20:26:52 -0600

Understood.

Alexey