Subject: rfc2222bis-08 comments

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 1 Oct 2004 15:59:44 +0200

These are rather rather hurried comments, since Kurt said reviews are
needed but soon.  So I have only made a cursory check if these issues
have been discussed before; I don't know how much they would have been
delayed if I were to check properly.  Sorry about that.

> Abstract

I had trouble getting into SASL the first time I read the draft - mostly
things that did not make sense to me at first, only when I got to a
closer explanation later in the draft.  I'm beginning to figure out why
now, though I'm guessing a bit about what it was I didn't get.  Starting
with the Abstract: I didn't get that at all, though I don't really see
why, given the second paragraph.  "So I have a protocol here, and an
authentication mechanism there, and somehow if I include SASL, the two
will be able to talk to each other.  Um...?"  It's better now, but I
still suggest:

>    The Simple Authentication and Security Layer (SASL) is a framework
>    for providing authentication and data security services in
>    connection-oriented protocols via replaceable

authentication

[nothing in the abstract says that's the kind of mechanisms it is
talking about.]

>    mechanisms.  It
>    provides structured interface between protocols and

such SASL

>    mechanisms.

Or maybe "...and mechanisms that adhere to SASL", but that's probably
more wordy than necessary.

The same change would be nice in the Introduction section, though of
course the diagram there helps.

Personally I would also have found an asymmetric definition easier to
relate to: SASL defines a common interface to authentication mechanisms
for protocols.  (Is that the right way to put it?)  But maybe that's not
at all the view SASL intends to convey.  Is the protocol profile the
common interface to protocols for authentication mechanisms?

> 2.    Introduction

>    The implementors will also need to understand a
>    specification of a

SASL

>    profile specific to the protocol,

> 3.1.  Authentication protocol exchange

This phrase looks to me like it is about an authentication protocol -
i.e. part of SASL - and not the protocol which uses SASL.  I don't see
anything in the following section to correct that notion.

Also,

>    A SASL mechanism is responsible for conducting an authentication
>    protocol exchange.

I don't think so.  It's the protocol which conducts the _exchange_,
and (below) which transmits anything.

>    During the authentication protocol exchange, the mechanism performs

I suggest s/performs/can perform/, since not all of them need be done.

>    authentication, transmits an authorization identity (frequently known
>    as a userid) from the client to server,

This sounds like the authorization identity is independent of the
authentication.  See below.

> 3.2.  Authorization and authentication identities

>    The processing model is as follows.  A server, upon completion of the
>    authentication mechanism, uses the results produced by the
>    authentication mechanism, the client-provided authorization identity
>    value (which may be the empty string), and local policy information
>    to derive an authorization identity.

As above.  As described, the authorization ID appears not to be part of
the 'results produced by the authentication mechanism', only something
which is grabbed after completion of the authentication.  When I first
read about this, I was left wondering when the server checks if the
authentication ID has the authorization ID's access.  Each time one
tries to access something after the authentication?

Please clarify that the authorization ID is checked during the
authentication (as section 3.2.1 says).  And local policy is used to
either derive the authorization identity or check it.  But it looks a
little strange to use that local policy during the exchange if the user
provides it, but after the exchange if it is derived.  Should both be
done during the exchange instead?

>    The authorization identity may be an empty (zero length) string.  In
>    this case, the server derives an authorization identity from the
>    client's authentication identity.

I wonder a little why the authorization ID is explicitly said to be
provided by the client, when the authentication ID is not.

>    Any normalization of the authentication identity is defined by a
>    particular SASL mechanism, the protocol profile doesn't influence it.

That's a bit misleading from the protocol's point of view.  From
discussions elsewhere I gather the protocol may normalize the ID as it
pleases for its own use, including when it locates the server-side
secret matching the authentication ID, as long as this does not affect
the ID which the authentication mechanism sees.

>    The mechanism MUST preserve Unicode codepoint when transferring
>    authorization identity (e.g. the mechanism cann't apply any form of
>    normalization).

The () part does not seem say the same as the preceding sentence: 'when
transferring...' sounds like only the client-side part of the mechanism
must preserve the ID, while the () sounds like the server side also must
preserve it.

> 3.2.1.  Authorization identities and proxy authentication

>    The server SHOULD verify that a received authorization identity is in
>    the correct form. Protocol profiles whose authorization identities
>    are simple user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep"
>    profile [SASLprep] of the "stringprep" algorithm [StringPrep] to
>    prepare these names for matching. The profiles MAY use a stringprep
>    profile that is more strict than "SASLprep". 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.

In that case there can be authorization IDs which one can only get by
sending an empty authorization ID: IDs that are derived from the
authentication ID but would be invalid if specified explicitly.
Seems strange.

> 3.2.2.  Authorization Identity Format

>    An authorization identity is a string of zero or more Unicode
>    [Unicode] coded characters.  The NUL <U+0000> character is not
>    permitted in authorization identities.

But a NUL octet in a multibyte character is OK?
(Does not apply to UTF-8, of course.)

> 3.3.  Security layers

>    The security layer takes effect
>    immediately following the last response of the authentication
>    exchange for data sent by the client and the completion indication
>    for data sent by the server. The exact position MUST be defined by
>    the protocol profile (see section 4 part 5).

When does it stop having effect, if the protocol supports multiple
authentication?

>    Note that all SASL mechanisms that are unable to negotiate a security
>    layer automatically select no security layer.

Without checking up the 'selects no security layer' thread, I still
can't tell if this says that such a mechanism cancels an old security
layer or if it says that it doesn't affect it.  I'll check that later,
unless someone replies first.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Oct 2004 07:39:20 -0700

At 06:59 AM 10/1/2004, Hallvard B Furuseth wrote:
>needed but soon.

Thanks for responding to my late request for review!

To the WG,  Sam and I have some concerns regarding the depth
and breadth of the WG review of this I-D.  The chairs continue
to actively seek additional review. 

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Oct 2004 11:23:07 -0700

I have a few (initial) comments to inject here and there.

>>    connection-oriented protocols via replaceable

The sentence might be more clear if worded:
        The Simple Authentication and Security Layer (SASL) is
        a framework for providing authentication and data security
        services via replaceable mechanisms to connection-oriented
        protocols.

>[nothing in the abstract says that's the kind of mechanisms it is

Mechanisms provide authentication and data security services
to connection-oriented protocols through the SASL framework.

>>    provides structured interface between protocols and

I think its clear that both "protocols" and "mechanisms"
refer to those protocols and mechanisms which are utilizing
the SASL framework.  I don't think either needs to be
qualified here.  It would seem odd to qualify one and not
the other.  And as this is the Abstract, we should avoid
being too wordy.

>more wordy than necessary.

First, you'd have to say s/SASL/SASL technical specification/.
But, yes, too wordy.

>common interface to protocols for authentication mechanisms?

The "protocol profile" is the part of the protocol's
technical specification which details how it makes use
of the SASL framework.

>i.e. part of SASL - and not the protocol which uses SASL.
>I don't see anything in the following section to correct that notion.

I think the word "protocol' here should be dropped here
and elsewhere where we're referring to the mechanism
exchange.

>> 3.2.  Authorization and authentication identities

There was some discussion in this area during WGLC.  That
discussion was recently re-opened.  I suggest you read
my latest post in this area as well as the WGLC thread.

>But a NUL octet in a multibyte character is OK?

This sentence refers only to specific character, not
octets belonging to an encoding of other characters.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 5 Oct 2004 14:59:27 +0200

Fixes to my previous comments, and comments to the rest of the draft.

I wrote:
> Subject: rfc2222bis-08 comments

> (...)
> either derive the authorization identity or check it.

Sorry, s/check(ed)/authorize(d)/ is probably better.

> the ID which the authentication mechanism sees.

Or rather, the protocol or its implementation may do that.

> unless someone replies first.

...and Section 6.3 clarified it, now that I have gotten that far.

================================================================

> 3.    Authentication mechanisms

>    sasl-mech    = 1*20mech-char
>    mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
>                   ; mech-char is restricted to "A"-"Z", "0"-"9", "-",
>                   ; and "_" from ASCII character set.

In most standards, tokens like sasl-mech cannot start with a hyphen;
often they must start with a letter.  Prevents problems e.g. with
programs that are overeager about extracting command line arguments, or
utilities which notice token-like strings in general without an exact
idea of what kind of token it is (e.g. click&cut&paste).  Is there any
reason sasl-mech is different?

> 4.    Protocol profile requirements

>    Note that an additional data with success can't be empty.

I suggest
  "Note that if additional data is sent with success, it can't be empty."
to clarify that one can send success without additional data.  At least
that's what I assume it means.  The sentence as quoted above confused
me: I could see no reason why one must always send additional data with
success:-)

>    Profiles whose
>    authorization identities are simple user names (e.g. IMAP [RFC 3501])
>    SHOULD use "SASLprep" profile [SASLprep] of the "stringprep"
>    algorithm [StringPrep] to prepare these names for matching. The
>    profiles MAY use a stringprep profile that is more strict than
>    SASLprep.

That uppercase "MAY" gives the impression that this is the only other
option:  It may not a more lax stringprep profile, or an entirely
different way to prepare.

> 5.    Mechanism profile guidelines

>    SASL mechanisms
>    must define which entity (or entities) must perform the preparation.
>    If preparation fails or results in an empty string, the entity doing
>    the preparation MUST fail the authentication exchange.

I expect preparation of an empty string should not fail, so:
s/results in/turns a non-empty string into/.

> 6.1.  Client sends data first

>    If the initial client response parameter is not given, or if a
>    protocol's profile does not permit the command which initiates an
>    authentication protocol exchange to contain an initial client
>    response, then the server issues a challenge with no data.  The
>    client's response to this challenge is then used as the initial
>    client response.  (The server then proceeds to send the next
>    challenge, indicates completion, or indicates failure.)

Then protocols that support an initial response must be clear on how to
distinguish an absent initial response from a present but empty initial
response.  I expect their protocol profiles must also specify whether or
not the protocol _can_ distinguish the two, so the mechanism can tell
whether or not to send empty initial responses.

Protocol example: A line-oriented protocol similar to SMTP where the
client sends commands with space-separated arguments, and servers strip
trailing spaces from client command lines.

Mechanism example: EXTERNAL with authorization ID = empty string.

> 6.2.  Server returns success with additional data

>    Client implementors should be aware of an additional failure case
>    that might occur when the profile supports sending the additional
>    data with success. Imagine that an active attacker is trying to
>    impersonate the server and sends faked data, which should be used to
>    authenticate the server to the client, with success.  (A similar
>    situation can happen when either the server and/or the client has a
>    bug and they calculate different responses.) After checking the data,
>    the client will think that the authentication exchange has failed,
>    however the server will think that the authentication exchange has
>    completed successfully.  At this point the client can not abort the
>    authentication exchange; it SHOULD close the connection instead.
>    However, if the profile did not support sending of additional data
>    with success, the client could have aborted the exchange at the very
>    last step of the authentication exchange.

I don't quite understand.  I would have thought that if an attacker can
do that, he can also wait for the final client response and then start
accessing the server, pretending to be the client.  Maybe that just
shows my ignorance of the subject, but many other readers will be
equally ignorant.

> 7.    The EXTERNAL mechanism

>    The client sends a single message containing the UTF-8 encoding of
>    the authorization identity. The message may be empty.

s/message/response/ the first time,
s/message/authorization identity/ the second time?
See my comments above about empty initial response.

> Appendix C. Changes since RFC 2222

>    The "KERBEROS_V4" mechanism defined in RFC 2222 is obsolete and has
>    been removed.

I just noticed that <http://www.iana.org/assignments/sasl-mechanisms>
has no pointer to the definition of the KERBEROS_V5 mechanism.  Its
registration only lists a person (Simon Josefsson).  The same is true
for some other mechanisms.  Why is that?

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 5 Oct 2004 16:33:02 +0200

>         services via replaceable mechanisms to connection-oriented

I don't think so; it looks a little strange to have the 'to...' after
the 'via...'.  Maybe s/in/to/ would improve the original sentence.

I've asked a coworker what he thought the Abstract meant: He got it more
or less right, but was somewhat vague about it and thought it was a bit
hard to get.  He did not think my suggested extra words would make a
difference.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 12 Oct 2004 16:52:10 +0100

>reason sasl-mech is different?
I see your point, but at this time I would rather not change this. Just 
in case somebody has designed and deployed a mechanism that starts with 
"_" or "-".

>me: I could see no reason why one must always send additional data with
Ok and fixed.

>different way to prepare.
This MAY is just fine according to [KEYWORDS] (RFC 2119).
I am not sure how this can be improved.

The reason for having the MAY is to emphasize that this is actually 
considered a reasonable thing to do.

>s/results in/turns a non-empty string into/.
This text is talking about authentication identities and passwords. I am 
not sure whether the empty string should be allowed.

>whether or not to send empty initial responses.
This is described in Section 4, bullet # 2.

>shows my ignorance of the subject, but many other readers will be
What you are saying might be true, but I don't think it is relevant for 
the section you've quoted. By the time the server has sent a fake (or 
wrong) "additional data with success", it is too late: the client has 
already provided its credentials to the server.

>s/message/authorization identity/ the second time?
I actually prefer to keep the informal term message here.

>for some other mechanisms.  Why is that?
There is no reference, because there is no RFC. I think one can ask IANA 
to add one.

Alexey

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Oct 2004 13:12:51 -0400

> considered a reasonable thing to do.

Try this:

Profiles MAY use a stringprep profile other than SASLprep, or none at all.

> already provided its credentials to the server.

But the same is true even if you don't support "additional data with 
success".  By the time the server sends the last data, the client has 
_still_ already sent its credentials to the server.  In either case the 
client cannot abort the exchange, because the MitM attacker simply won't 
forward that part.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 12 Oct 2004 18:39:17 +0100

> Profiles MAY use a stringprep profile other than SASLprep, or none at 

I actually want to say that SASLPrep or stronger profile (i.e. SASLPrep 
+ additional restrictions) is a common case.

> _still_ already sent its credentials to the server.  In either case 
> the client cannot abort the exchange, because the MitM attacker simply 
> won't forward that part.

I agree with you.
The point of the paragraph is to say that with additional data with 
success the client is *not able* to abort SASL exchange, thus it has to 
disconnect.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Oct 2004 14:17:58 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> On Tuesday, October 12, 2004 16:52:10 +0100 Alexey
    Jeffrey> Melnikov
    Jeffrey> <[email-masked]> wrote:

    >>>> Profiles whose authorization identities are simple user names
    >>>> (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile
    >>>> [SASLprep] of the "stringprep" algorithm [StringPrep] to
    >>>> prepare these names for matching. The profiles MAY use a
    >>>> stringprep profile that is more strict than SASLprep.
    >>>> 
    >>>> 
    >>>  That uppercase "MAY" gives the impression that this is the
    >>> only other option: It may not a more lax stringprep profile,
    >>> or an entirely different way to prepare.
    >>> 
    >> This MAY is just fine according to [KEYWORDS] (RFC 2119).  I am
    >> not sure how this can be improved.
    >> 
    >> The reason for having the MAY is to emphasize that this is
    >> actually considered a reasonable thing to do.

    Jeffrey> Try this:

    Jeffrey> Profiles MAY use a stringprep profile other than
    Jeffrey> SASLprep, or none at all.

I prefer the text currently in the draft to your proposed text.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 12 Oct 2004 23:39:08 +0200

>  in case somebody has designed and deployed a mechanism that starts with

OK.

>  not sure whether the empty string should be allowed.

I can see nothing which forbids it, neither in rfc2222 nor 2222bis.

I have certainly set empty passwords on Unix boxes (off the net); if
there is a SASL library which allows empty passwords then I assume
people have found use for them with SASL too.

I expect an empty authentication IDs would be messier, unless the
authorization ID which is derived from that ID is non-empty.

>  This is described in Section 4, bullet # 2.

No...  First, it's only a SHOULD:

   If the protocol allows for the initial response, the protocol profile
   SHOULD also describe how an empty initial response is encoded.

Second, if that sentence is intended to address this issue, I can think
of two different things it can imply in order to do so.  It is not at
all clear to me that it means either:

1) "If the protocol profile does not say how an initial response is
   encoded, then empty but present initial responses are not supported."

2) If you s/SHOULD/MUST/: "If initial responses are supported, then it
   MUST be possible to send an empty initial response which can be
   distinguished from no initial response."

>  I actually prefer to keep the informal term message here.

Well, I'll see how empty initial responses turn out...

>  There is no reference, because there is no RFC. I think one can ask IANA

If there is a standard or "official document" or something for a
mechanism, RFC or not, my vote is to at least mention it.  When I'm
walking through standards and definitions of something I'm working with,
it's always annoying when there is suddenly no reference to where to go
from there.  As with Kerberos5, Googling around will often find
competing texts that may or may not be or reflect the "official"
standard.  Or I can ask (if I knows where), but then I have to sit and
wait for someone to answer, and sometimes there is no telling how
reliable the respondent is.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 12 Oct 2004 23:49:39 +0200

Alexey Melnikov writes:
>>>>>   (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep" profile [SASLprep]
>>>>>   of the "stringprep" algorithm [StringPrep] to prepare these
>>>>>   names for matching. The profiles MAY use a stringprep profile
>>>>>   that is more strict than SASLprep.
>>>>

Profiles whose (...) SHOULD use SASLPrep or a stricter stringprep
profile, but MAY use other stringprep profiles or none at all?

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Oct 2004 18:39:24 -0400

I'm not really sure it's OK for a protocol to use no stringprep
profile at all.

Especially for an IETF protocol I'm not sure I can think of situations
where the right technical solution would not involve stringprep of
some kind.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Oct 2004 10:56:42 +0100

>   SHOULD also describe how an empty initial response is encoded.
I've already changed SHOULD to MUST. This issue was raised during WGLC.

>   distinguished from no initial response."
The intention was to say #2. I am not aware of any protocol profile that 
supports initial response, but doesn't allow for it being empty.

>reliable the respondent is.
For KERBEROS_V5 registration you need to send a email to Simon, he is 
the authoritative source of information. It would be even better if you 
ask him to update the registration.

Alexey

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Oct 2004 10:11:13 -0400

> where the right technical solution would not involve stringprep of

What an application's SASL profile says about the form and preparation of 
authorization names will always depend on what the application protocol 
does in a broader sense.  For applications which use some sort of string 
for identity and authorization, the SASL profile should specify use of the 
same string, with the same behaviours and semantics.  That means if the 
application does not use stringprep on authorization ID's used, say, in 
manipulating ACL's, then it should not use it on SASL authorization ID's 
either.

Also, I can think of a scenario in which the right solution does not 
involve any form of stringprep.  Consider an application which does 
identity and access control using UUID's rather than strings.  I do not 
believe there is anything in SASL that would prevent this use.

I agree that when applications use strings to identify users, they should 
use some form of stringprep.  I agree that in many such cases, it would be 
appropriate to use SASLprep rather than constructing a separate stringprep 
profile for that application.  However, mandating the use of stringprep in 
application protocols is out of scope for this working group, and I believe 
that it is more important that SASL authorization ID's have the same 
semantics as those used elsewhere in the application than that they have 
the same semantics as other strings used in SASL.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Oct 2004 10:22:48 -0400

On Tuesday, October 12, 2004 23:39:08 +0200 Hallvard B Furuseth 
<[email-masked]> wrote:

> mechanism, RFC or not, my vote is to at least mention it.

In the case of KERBEROS_V5, there is not.  There may be an internet-draft, 
though I expect it has expired by now if Simon is not still actively 
working on the mechanism.  Internet-drafts are by their nature ephemeral 
and therefore do not make stable references.  Published RFC's may not 
contain references to internet-drafts.

>  When I'm
> from there.

It is not necessary, appropriate, or even possible for the SASL base 
document to include an exhaustive list of SASL mechanisms.  This is hardly 
the first "framework" document to include support for multiple mechanisms, 
and the normal practice is to make reference to specific mechanisms only 
when they are REQUIRED or RECOMMENDED, or when such a reference is needed 
to illustrate a concept described in the framework.

It is worth noting that as with any "framework" defined by the IETF, there 
_is_ an exhaustive list of all mechanisms, which is maintained by the IANA. 
IANA registries generally include a pointer to a contact person and/or to a 
published specification, if there is one.

There is no "official" standard KERBEROS_V5 mechanism.  I refer you to the 
following paragraph, which appears as part of the boilerplate at the top of 
every internet-draft:

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups.  Note that
   other groups may also distribute working documents as Internet
   Drafts. Internet Drafts are draft documents valid for a maximum of
   six months.  Internet Drafts may be updated, replaced, or obsoleted
   by other documents at any time.  It is not appropriate to use
   Internet Drafts as reference material or to cite them other than as
   ``work in progress''.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Oct 2004 10:42:38 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> On Tuesday, October 12, 2004 18:39:24 -0400 Sam Hartman
    Jeffrey> <[email-masked]> wrote:

    >>  I'm not really sure it's OK for a protocol to use no
    >> stringprep profile at all.
    >> 
    >> Especially for an IETF protocol I'm not sure I can think of
    >> situations where the right technical solution would not involve
    >> stringprep of some kind.

    Jeffrey> What an application's SASL profile says about the form
    Jeffrey> and preparation of authorization names will always depend
    Jeffrey> on what the application protocol does in a broader sense.
    Jeffrey> For applications which use some sort of string for
    Jeffrey> identity and authorization, the SASL profile should
    Jeffrey> specify use of the same string, with the same behaviours
    Jeffrey> and semantics.  That means if the application does not
    Jeffrey> use stringprep on authorization ID's used, say, in
    Jeffrey> manipulating ACL's, then it should not use it on SASL
    Jeffrey> authorization ID's either.

    Jeffrey> Also, I can think of a scenario in which the right
    Jeffrey> solution does not involve any form of stringprep.
    Jeffrey> Consider an application which does identity and access
    Jeffrey> control using UUID's rather than strings.  I do not
    Jeffrey> believe there is anything in SASL that would prevent this
    Jeffrey> use.

True.  But what you can do is somewhat constrained by the IESG for
standards-track documents.  I believe that MAY use no stringprep is
technically true but is also too strong of a statement.

--Sam

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 13 Oct 2004 17:08:33 +0200

Jeffrey Hutzelman writes:
>> (...internet-draft KERBEROS_V5...)
>>
>> When I'm
> document to include an exhaustive list of SASL mechanisms.

You have lost the context.  I was talking about a reference - formal or
informal - in the IANA registry, not rfc2222bis.

But back to rfc2222bis:

> There is no "official" standard KERBEROS_V5 mechanism.

Then it seems strange to me to remove KERBEROS_V4 without further
comment when there is no standard replacement - in particular since SASL
was born around Kerberos and S/Key, according to the mailinglist
archive.  I suggest to add a purely informational sentence or two about
why this was done and that an informal Kerberos5 exists.  And if V4-
support was removed because of a security flaw in that version, warn
that one really shouldn't keep support for it.  (Maybe the same applies
to S/Key, but I know even less about that than about Kerberos.)

-- 
Hallvard

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Oct 2004 11:19:04 -0400

On Wednesday, October 13, 2004 17:08:33 +0200 Hallvard B Furuseth 
<[email-masked]> wrote:

> comment when there is no standard replacement

Note that there is a distinct difference between SASL mechanisms and the 
underlying authentication technology.  The SASL KERBEROS_V4 mechanism is 
obsolete because the underlying technology is obsolete.  It is worth noting 
that Kerberos V4 is not and never has been an IETF standard.

If you want to use Kerberos V5 with SASL, the mechanism you are looking for 
is named 'GSSAPI'.  It is described in draft-ietf-sasl-gssapi-01, which 
defines a family of SASL mechanisms based on GSSAPI mechanisms (note that 
the SASL mechanism name "GSSAPI" refers specifically to GSS krb5).

By contrast, the KERBEROS_V4 mechanism was defined _in the SASL base 
document_, which is why it is mentioned in the changelog.

-- Jeff

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 13 Oct 2004 17:34:07 +0200

Jeffrey Hutzelman writes:
> Note that there is a distinct difference between SASL mechanisms and
> the underlying authentication technology.  The SASL KERBEROS_V4
> mechanism is obsolete because the underlying technology is obsolete.
> It is worth noting that Kerberos V4 is not and never has been an IETF
> standard.
>
> If you want to use Kerberos V5 with SASL, the mechanism you are
> looking for is named 'GSSAPI'.  It is described in
> draft-ietf-sasl-gssapi-01, which defines a family of SASL mechanisms
> based on GSSAPI mechanisms (note that the SASL mechanism name "GSSAPI"
> refers specifically to GSS krb5).

OK.  Still, it might still be worth mentioning this the draft.  I expect
what you say is well known to someone who comes to SASL via Kerberos,
but it would not be known to someone (like me) who comes to Kerberos via
SASL.  OTOH, if such a brief sentence could not be sufficiently helpful
to a 'kerberos newbie' for there to be any point to it, forget it.

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Oct 2004 22:23:34 +0100

>authorization ID which is derived from that ID is non-empty.
Ok, I have done the proposed change. Can anybody suggest a better wording?

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 21 Oct 2004 15:43:58 +0200

> supports initial response, but doesn't allow for it being empty.

Me neither, which is why I used an imaginary example.  But I've just
realized that your answer opens for a third possibility: Protocols that
do allow empty initial responses, but not absent initial responses.
(Again, an SMTP-like protocol which strips trailing whitespace could be
an example.)

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Oct 2004 15:36:09 +0100

>hard to get.  He did not think my suggested extra words would make a
Unless somebody objects, I am leaving the sentence as is.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Oct 2004 16:23:08 +0100

>and (below) which transmits anything.
What about

A SASL mechanism is responsible for conducting an authentication exchange.

?
The mechanism is clearly "conducting" the exchange, but the protocols
carries it.

>[...] 

The text in () only talks about transfer (actually it also applies to
hashing and other similar uses). For the purposes of looking up
credentials, access control, etc. the server can do as it pleases. This
is out of scope for SASL.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 Oct 2004 19:27:39 +0100

>to connection-oriented protocols through the SASL framework.
IMHO, this just follows from:

The Simple Authentication and Security Layer (SASL) is a framework
for providing authentication and data security services in
connection-oriented protocols via replaceable mechanisms.

So I think nothing has to be added/changed.

>technical specification which details how it makes use
The Introduction section currently have the following paragraph:

To use SASL, a protocol includes a command for identifying and
authenticating a user to a server and for optionally negotiating a
security layer for subsequent protocol interactions.  If the use
of a security layer is negotiated, that security layer is inserted
between the protocol and the connection.  Section 4 ("Protocol profile
requirements") profiles the requirements that a protocol specification
must fulfill to make use of SASL.

I've added the following sentence to the end:

A SASL protocol profile is a part of the protocol specification that 
satisfies the requirements of Section 4.

Comments?

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Oct 2004 07:39:20 -0700

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Oct 2004 11:23:07 -0700

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 5 Oct 2004 14:59:27 +0200

I suggest

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 5 Oct 2004 16:33:02 +0200

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 12 Oct 2004 16:52:10 +0100

Ok and fixed.

Alexey

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Oct 2004 13:12:51 -0400

Try this:

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 12 Oct 2004 18:39:17 +0100

I agree with you.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Oct 2004 14:17:58 -0400

Jeffrey> Try this:

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 12 Oct 2004 23:39:08 +0200

OK.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 12 Oct 2004 23:49:39 +0200

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Oct 2004 18:39:24 -0400

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Oct 2004 10:56:42 +0100

Alexey

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Oct 2004 10:11:13 -0400

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Oct 2004 10:22:48 -0400

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Oct 2004 10:42:38 -0400

--Sam

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 13 Oct 2004 17:08:33 +0200

-- 
Hallvard

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Oct 2004 11:19:04 -0400

-- Jeff

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 13 Oct 2004 17:34:07 +0200

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Oct 2004 22:23:34 +0100

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 21 Oct 2004 15:43:58 +0200

-- 
Hallvard

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Oct 2004 15:36:09 +0100

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Oct 2004 16:23:08 +0100

What about

?

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 Oct 2004 19:27:39 +0100

Comments?

Alexey