Subject: SASL GSSAPI to IETF Last Call

From: John Gardiner Myers <[email-masked]>
Date: Sun, 25 Mar 2001 14:30:16 -0800

In Minneapolis, some members of the GSSAPI community asked me if the
SASL GSSAPI document was ready to go.  I replied that in my opinion it
was.  Consequently, they will be with my approval sending a request for
that document to go to IETF Last Call for Proposed Standard.

As the document makes substantial changes to the GSSAPI section of RFC
2222, I believe it is important to get it to Proposed Standard as soon
as possible.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 Mar 2001 22:40:05 -0800

>that document to go to IETF Last Call for Proposed Standard.

I believe there are '[TODO]' which need some attention in the
document.  If nothing else, they need to be removed.

>2222, I believe it is important to get it to Proposed Standard as soon

In terms of getting SASL to Draft Standard, it makes
little difference on whether GSSAPI is updated before
or after we publish the revised SASL RFC... that's
because the revision document will likely not include
any GSSAPI mechanisms (due to dependencies on numerous
documents which are currently only at Proposed).

It's my view that we should publish a new SASL/GSSAPI
document which provides a complete specification of
GSSAPI and the GSS-* family of mechanisms.  This document
should be published at the same time we publish 2222bis.
If we were to publish GSSAPI/GSS-API first, then we'd
only have to update them again to refer to 2222bis instead
of 2222.

I note the current SASL mechanism registration policy does
not allow for prefixes (or family of mechanisms) to be
reserved.  Only complete mechanism names can be reserved.
While this I-D attempts to establish a GSS specific
consideration, that seems a bit odd.  I would suggest
that instead that RFC 2222bis update the IANA considerations
to support "families" of SASL mechanisms in general.  Besides
GSS-*, there are other families of mechanisms which should
be addressed (in general).

Other notes:
  SPKM reference has a "Siimple" typo.

---

From: Keith Burdis <[email-masked]>
Date: Tue, 27 Mar 2001 17:37:18 +0200 (SAST)

Quoting \"Kurt D. Zeilenga\" <[email-masked]>:

> to support \"families\" of SASL mechanisms in general.  Besides

I would support this change. Both SRP and SM2 specify families
of related mechanisms. They can not currently be registered
due to this fact.

  - Keith
--
Keith Burdis                        
---

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Mar 2001 23:17:41 -0700

> 2222, I believe it is important to get it to Proposed Standard as soon

Ok, here is the list of my comments (not in order of importance):

1). Page header says "SASL instead of "GSSAPI SASL mechanism":
Internet DRAFT                    SASL                 September 8, 2000

2). Section 2.1.  "How to Read This Document" should be removed, IMHO.

3). If you want to have any examples, I would suggest to move section 2.3
after the section that describes GSSAPI SASL. The same applies to section
4. SPNEGO.

4). Section 5."Base32 encoding" describes base32 in details. Is it really
so important to describe all particular cases of base32 (especially
padding) that are never used in the document, because MD5 hash is always 16
bytes?

5). Section 5:

>   Any characters outside of the base32 alphabet are to be ignored in
>   base32-encoded data.

I am not sure what a developer should do after reading this statement.
Characters outside of base32 alphabet can never appear in a valid base32
string.

6). In section 6.1:

[skipped]
>   The client passes this token to GSS_Unwrap and interprets
>   the first octet of resulting cleartext as a bit-mask specifying the
>   security layers supported by the server and the second through fourth
>   octets as the maximum size output_message to send to the server

Missing "in network byte order"

>   The client then constructs data, with the first octet containing the
>   bit-mask specifying the selected security layer, the second through
>   fourth octets containing in network byte order the maximum size
>   output_message the client is able to receive, and the remaining
>   octets

Suggestion to add "(if any)": it might be obvious, but it is better to
clarify that if authorization identity is empty, than nothing is appended
to the buffer unlike PLAIN mechanism (this is for all C programmers who are
used to NUL terminated strings :-)).

>   containing the UTF-8 encoded [UTF8] authorization identity.
>   The client passes the data to GSS_Wrap with conf_flag set to FALSE,
>   and responds with the generated output_message.  The client can then
>   consider the server authenticated.

7) In section 6.2.  "Server side of authentication protocol exchange":

>   The server passes the initial client response to
>   GSS_Accept_sec_context as input_token, setting input_context_handle
>   to 0 (initially),

Suggestion to add the following text:

mech_type of the GSSAPI mechanism for which this
SASL mechanism is registered, and an acceptor_cred_handle, equal to
output_cred_handle from gss_acquire_cred called with desired_name parameter
equal to output_name from gss_import_name called with input_name_type of
GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
"service@hostname" where "service" is the service name specified in
the protocol's profile, and "hostname" is the fully qualified host
name of the server.

(I am not sure what is the best way to explain this, the idea is to call
gss_import_name first and than gss_acquire_cred).

[skipped]
>   The server must then pass the resulting response to GSS_Unwrap and
>   interpret the first octet of resulting cleartext as the bit-mask for
>   the selected security layer, the second through fourth octets as the
>   maximum size output_message to send to the client

Missing "[in network byte order]"

> , and the remaining
>   octets as the authorization identity.  The server must verify that
>   the src_name is authorized to authenticate as the authorization
> identity.  After these verifications, the authentication process is
>   complete.

8). Appendix A lists two OIDs in use for Kerberos V5 GSSAPI mechanism. The
description of Kerberos V5 GSSAPI mechanism should probably list them.

General comments from implementation experience of Kerberos V5 GSSAPI:

1). It would be nice to have some discussion about error handling in
authentication exchange. For example, what if server sends an additional
data following the maximal block size it is able to accept?

2). GSSAPI allows for requesting of various protection flags in
gss_init_sec_context (req_flags parameter). The document doesn't describe
which flags should be passed to gss_init_sec_context (CMU implementation
uses GSS_C_MUTUAL_FLAG | GSS_C_SEQUENCE_FLAG, our implementation uses
GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG | GSS_C_SEQUENCE_FLAG, University of
Washington uses GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG) and what server side
should do if it is not satisfied with negotiated protection flags. This
obviously depends on GSSAPI implementation, but it would be beneficial to
have some recommendations.

3). Neither client side, nor server side specify chan_bindings that should
be used in gss_accept_sec_context/gss_init_sec_context. In all
implementations I've seen this parameter is specified as
GSS_C_NO_CHANNEL_BINDINGS.

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 29 Mar 2001 12:51:25 -0800

I'd previously submitted a revised GSSAPI SASL I-D which removed the
[TODO] items.  Looks like I'll have to do another.

Alexey Melnikov wrote:
> 4). Section 5."Base32 encoding" describes base32 in details. Is it
> really so important to describe all particular cases of base32
> (especially padding) that are never used in the document, because MD5
> hash is always 16 bytes?

I'm leaving open the possibility of base32 being reused in another
document.
 
> Characters outside of base32 alphabet can never appear in a valid
> base32 string.

Again, for the possibility of base32 being reused elsewhere.

> clarify that if authorization identity is empty, than nothing is
> appended to the buffer unlike PLAIN mechanism (this is for all C
> programmers who are used to NUL terminated strings :-)).

If a clarification is necessary, I think a clearer statement would be
"The authorization identity is not NUL-terminated."  This has nothing to
do with whether or not the authorization id is the empty string.

> 8). Appendix A lists two OIDs in use for Kerberos V5 GSSAPI mechanism.
> The description of Kerberos V5 GSSAPI mechanism should probably list
> them.

Which description were you referring to?

> authentication exchange. For example, what if server sends an
> additional data following the maximal block size it is able to accept?

One reading would seem to require the client to ignore the extra data. 
Another would state that in a security context anything not permitted
the sender is a security violation.  I don't think it matters either
way.  Do we have a consensus from implementors as to which way this
should go?

> gss_init_sec_context (req_flags parameter). The document doesn't
> describe which flags should be passed to gss_init_sec_context (CMU
> implementation uses GSS_C_MUTUAL_FLAG | GSS_C_SEQUENCE_FLAG, our
> implementation uses GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG |
> GSS_C_SEQUENCE_FLAG, University of Washington uses GSS_C_MUTUAL_FLAG |
> GSS_C_REPLAY_FLAG) and what server side should do if it is not
> satisfied with negotiated protection flags. This obviously depends on
> GSSAPI implementation, but it would be beneficial to have some
> recommendations.

mutual_req_flag clearly depends entirely upon the security policy of the
client.

The other two depend on the security policies of both client and
server.  As with any security negotiation, if both sides cannot agree on
a policy, the authentication should fail.  

When sequence_state is TRUE, it doesn't look like the value of
replay_det_state matters.

As SASL protocols are stream-based, I would have thought that
sequence_state would obviously been in the security policy of any client
requesting a security layer.  Should the document make it a requirement
of any peer willing to negotiate a security layer?

> 3). Neither client side, nor server side specify chan_bindings that
> should be used in gss_accept_sec_context/gss_init_sec_context. In all

Should the document explicitly specify a chan_bindings of
GSS_C_NO_CHANNEL_BINDINGS?

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Mar 2001 17:50:31 -0700

John Gardiner Myers wrote:

> "The authorization identity is not NUL-terminated."

I like that.

>  This has nothing to

You can't distinguish between two cases anyway.

>3.    Introduction and Overview
>
>   For backwards compatibility with existing implementations of Kerberos
>   V5 and SPNEGO under SASL, the SASL mechanism name for the Kerberos V5
>   GSSAPI mechanism [GSSAPI-KERBEROS] is "GSSAPI" and the SASL mechanism
>   for the SPNEGO GSSAPI mechanism [SPNEGO] is "GSS-SPNEGO".  The SASL
>   mechanism name for any other GSSAPI mechanism is the concatenation of
>   "GSS-" and the Base32 encoding of the first ten bytes of the MD5 hash
>   [MD5] of the ASN.1 DER encoding [ASN1] of the GSSAPI mechanism's OID.
>   Base32 encoding is described later in this document
>   SASL mechanism names starting with "GSS-" are reserved for SASL
>   mechanisms which conform to this document.

Just put corresponding OIDs after GSSAPI and GSS-SPNEGO.

> way.  Do we have a consensus from implementors as to which way this

The first allows for extensibility (do we need it in this case?), the second
allows for detecting buggy implementations. If the main goal is
extensibility, I will choose the first, otherwise the second.

> mutual_req_flag clearly depends entirely upon the security policy of the

For interoperability spec should either list default list of flags or allow
for negotiation. The latter doesn't work for GSSAPI, because option
negotiation happens after gss_init_sec_context/gss_accept_sec_context
exchange.

I suggest that GSSAPI says that all clients MUST specify mutual
authentication (and if underlying GSSAPI mechanism doesn't support mutual
authentication it will probably ignore this flag anyway).

> a policy, the authentication should fail.

Some implementations don't check whether the requested level of protection
was really achieved.

> of any peer willing to negotiate a security layer?

I would say "yes".

> GSS_C_NO_CHANNEL_BINDINGS?

For interoperability I would say yes! However Kerberos V4 makes use of local
and remote IP in authentication.
Is any implementation using no-NULL channel binding?

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 29 Mar 2001 18:58:40 -0800

> Just put corresponding OIDs after GSSAPI and GSS-SPNEGO.

I don't think it's appropriate for this document to define those OIDs. 
The normative references [GSSAPI-KERBEROS] and [SPNEGO] are responsible
for that.  It is only appropriate to put those OIDs in examples.

> extensibility, I will choose the first, otherwise the second.

I had (and have) no intent to allow for extensibility here.  You'll note
that the corresponding client-to-server message is not extensible.

> negotiation happens after gss_init_sec_context/gss_accept_sec_context

In this case, GSSAPI allows for negotiation.  If the client has mutual
authentication in its security policy, it can ask for it through
GSSAPI.  Mutual authentication is of no benefit to the server, so it
makes no sense for the server to ask for it.

> Some implementations don't check whether the requested level of protection

Either the security policy does not require that level of protection to
be present, in which case this is OK or the security policy does require
that level of protection, in which case this is an implementation error.

Implementations need to determine the security policy and then enforce
it.  This is a fundamental part of writing this kind of code.

Do you have any particular suggestions for improving the document?

> > of any peer willing to negotiate a security layer?

Any objections?

> Is any implementation using no-NULL channel binding?

In my implementation experience with Kerberos V4, I've found the channel
bindings to be far more trouble than they're worth.  You have to punch
all sorts of holes through your API layers just to get .rhosts-level
protection.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 31 Mar 2001 18:32:01 -0700

> for that.  It is only appropriate to put those OIDs in examples.

GSSAPI-KERBEROS probably list only one OID (new one).

It would be nice to have all information in one document. Although this has a
disadvantage that if mechanism OID changes, you have to update the document.

> that the corresponding client-to-server message is not extensible.

Good.

Do you want to say anything about canceling GSSAPI exchange (I mean what peer
should do if it receives cancellation request)?

> makes no sense for the server to ask for it.

You are right. Can you add the following sentence than:
"Client willing to perform mutual authentication MUST pass GSS_C_MUTUAL_FLAG flag
to gss_init_sec_context call".

> Do you have any particular suggestions for improving the document?

Actually you already wrote the paragraph that answer my question. I suggest you
add something like the following:
"When authentication exchange is complete both peers SHOULD check whether the
required protection level was achieved."

> > > of any peer willing to negotiate a security layer?

After looking through GSSAPI spec: GSS_C_REPLAY_FLAG & GSS_C_SEQUENCE_FLAG are
always discussed together, but a particular implementation may decide to implement
any one of them (or both).
I suggest that both client and server specify both flags when calling
gss_init_sec_context/gss_accept_sec_context.

> all sorts of holes through your API layers just to get .rhosts-level

I think there is a consensus that GSS_C_NO_CHANNEL_BINDINGS should be used.
Mark Crispin also agrees with that.

Another issue I forgot to mention before:

4). Both client and server specify the maximum **ciphertext** block size that they
are able to accept.
With particular GSSAPI implementation it is not always obvious what is the biggest
**cleartext** block size a
client/server should use. I suggest you mention that GSS_Wrap_size_limit can be
used (if available in GSSAPI implementation) to determine what cleartext buffer
size sender should use in order to produce ciphertext buffer not bigger than
receiver's maximal buffer.

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 Mar 2001 22:40:05 -0800

Other notes:

---

From: Keith Burdis <[email-masked]>
Date: Tue, 27 Mar 2001 17:37:18 +0200 (SAST)

- Keith
--
Keith Burdis                        
---

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Mar 2001 23:17:41 -0700

6). In section 6.1:

[skipped]

[skipped]

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 29 Mar 2001 12:51:25 -0800

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Mar 2001 17:50:31 -0700

I like that.

I would say "yes".

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 29 Mar 2001 18:58:40 -0800

Any objections?

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 31 Mar 2001 18:32:01 -0700

Good.

Alexey

Date: Sat, 31 Mar 2001 18:32:01 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: John Gardiner Myers <[email-masked]>
CC: [email-masked]
Subject: Re: SASL GSSAPI to IETF Last Call
Sender: [email-masked]

Good.

Alexey

Date: Sat, 31 Mar 2001 17:29:31 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: [Fwd: Re: SASL GSSAPI to IETF Last Call]
Sender: [email-masked]

I am forwarding a reply from Mark Crispin who implemented GSSAPI in UW.

Mark Crispin wrote:

> No, I don't read the IETF-SASL mailing list.  I didn't even know that such a
> thing existed.

> My primary concern is that the current UW IMAP implementation, which fully
> complies with GSSAPI as described in RFC 2222, is not broken in any way by any
> update to the GSSAPI SASL specification.  I would certainly oppose any update
> that did break UW IMAP.
>
> Since I haven't read the draft, I have no idea what the reference to "base32"
> is all about.  Here are my comments about the other issues in that message:
>
> I am not concerned about the authorization identity not being null terminated;
> I copy it to a buffer which I null-terminate.  I do assume that the
> authorization identity is everything after the 4 bytes of size/request.
>
> As far as protection flags in gss_init_sec_context(), I'll be happy to go with
> the flow.  I just picked a set of flags that seemed reasonable.
>
> It is probably a good idea to specify use of GSS_C_NO_CHANNEL_BINDINGS.

Date: Fri, 30 Mar 2001 14:30:04 -0500
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], Keith Burdis <[email-masked]>
Subject: Re: DIGEST-MD5: Family of mechanisms?
Sender: [email-masked]

I am generally NOT in favor of this change.  As Paul points out,
DIGEST-MD5 is not fully parametric over the choice of one-way
functions (it expects certain size results, etc.).  Doing this would
contribute to a glut of different mechanisms, with the corresponding
blow ups in code or interoperability problems.

If there's a security problem with the choice of a one-way function,
we should choose a different one-way function and issue a
specification for that, and encourage people to migrate.

Larry

   Date: Tue, 27 Mar 2001 17:58:21 +0200 (SAST)
   From: Keith Burdis <[email-masked]>

   Hi there

   One possible change to the Digest-MD5 specification could be to
   make it specify a family of mechanism, each using a different
   one-way function. This would mean that the same mechanism
   could be used with new and existing one-way functions, and would
   minimise the problems caused by a weakness being found in any
   particular one-way function.

   This specification would still be upwardly compatible with the
   HTTP \"md5-sess\" algorithm, since Digest-MD5 would be the same as
   before.

   Does anyone think that such a change would be useful? What are
   the potential drawbacks of this change?

     - Keith
   --
   Keith Burdis                        
   ---

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-myers-saslrev-00.txt
Date: Fri, 30 Mar 2001 07:30:22 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Simple Authentication and Security Layer (SASL)
	Author(s)	: J. Myers
	Filename	: draft-myers-saslrev-00.txt
	Pages		: 13
	Date		: 29-Mar-01
	
SASL provides a method for adding authentication support with an
optional security layer to connection-based protocols.  It also
describes a structure for authentication mechanisms.  The result is
an abstraction layer between protocols and authentication mechanisms
such that any SASL-compatible authentication mechanism can be used
with any SASL-compatible protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-myers-saslrev-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-myers-saslrev-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-myers-saslrev-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-myers-saslrev-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-myers-saslrev-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 29 Mar 2001 18:58:40 -0800
From: John Gardiner Myers <[email-masked]>
Subject: Re: SASL GSSAPI to IETF Last Call
To: [email-masked]
Sender: [email-masked]

Any objections?

Date: Thu, 29 Mar 2001 17:50:31 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: John Gardiner Myers <[email-masked]>
CC: [email-masked]
Subject: Re: SASL GSSAPI to IETF Last Call
Sender: [email-masked]

I like that.

I would say "yes".

Alexey

content-class: urn:content-classes:message
Subject: RE: DIGEST-MD5: Family of mechanisms?
Date: Thu, 29 Mar 2001 12:51:47 -0800
From: "Paul Leach" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>
Cc: "Keith Burdis" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Well, it's conceptually not hard, but:
1. The spec explicitly expects the length of the hash to be 128 bits in
many places, such as the definitions of H, KD, HEX
2. The key derivation explicitly uses MD5, not H or KD.
3. The key derivation only gets you 128 bits of keying material; it's
silly to use AES with that small a key. And that's why the 3DES is 2 key
3DES in the spec, for example.
4. The block size of the cipher is explicitly called out in the privacy
protection section

Also, if we add these, there will not exist two interopable
implementations; won't that guarantee a recycle?

Finally, if I were doing such an addition, I'd use PKCS#5 as part of the
derivation of the key (A1) from the password. It can generate arbitrary
length keys, and it is designed to take a long time (e.g., 100 ms, but
tunable) on the client, making attacks on challenge/response pairs much
harder. (The server can precompute, so it doesn't get loaded.)

As a result of all that, I'd be inclined to do this as "DigestV2".

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Wednesday, March 28, 2001 7:43 PM
> To: Kurt D. Zeilenga
> Cc: Keith Burdis; [email-masked]
> Subject: Re: DIGEST-MD5: Family of mechanisms?
> 
> 
> "Kurt D. Zeilenga" wrote:
> 
> > At 05:58 PM 3/27/01 +0200, Keith Burdis wrote:
> > >One possible change to the Digest-MD5 specification could 
> be to make 
> > >it specify a family of mechanism, each using a different one-way 
> > >function. This would mean that the same mechanism could be 
> used with 
> > >new and existing one-way functions, and would minimise the 
> problems 
> > >caused by a weakness being found in any particular one-way 
> function.
> > >
> > >This specification would still be upwardly compatible with 
> the HTTP 
> > >\"md5-sess\" algorithm, since Digest-MD5 would be the same 
> as before.
> > >
> > >Does anyone think that such a change would be useful?
> 
> I support the idea.
> 
> > What are
> > >the potential drawbacks of this change?
> >
> > We just need to be careful not to cause DIGEST-MD5 to unnecessarily 
> > recycle at Proposed.
> >
> > I did chat with JeffS and he thought we likely can add AES as an 
> > alternative cipher without recycling.  We might be able to 
> add SHA1, 
> > or at least the framework for additional hash functions, without 
> > recycling at Proposed.
> 
> I believe you are right. Section 1.1 of the RFC 2831 says:
> 
> >1.1  Conventions and Notation
> >
> [skipped]
> >   Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet 
> string s.
> 
> This seems like an intention of the authors to be able to use 
> different hashing algorithms.
> 
> Alexey
> 
> 
> 

Date: Thu, 29 Mar 2001 12:51:25 -0800
From: John Gardiner Myers <[email-masked]>
Subject: Re: SASL GSSAPI to IETF Last Call
To: [email-masked]
Sender: [email-masked]

 

Date: Wed, 28 Mar 2001 23:17:41 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: John Gardiner Myers <[email-masked]>
CC: [email-masked]
Subject: Re: SASL GSSAPI to IETF Last Call
Sender: [email-masked]

--------------2B745C02841C43ADC28F54FF
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit

6). In section 6.1:

[skipped]

[skipped]

Alexey

--------------2B745C02841C43ADC28F54FF
Content-Type: text/html; charset=koi8-r
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
John Gardiner Myers wrote:
<blockquote TYPE=CITE>In Minneapolis, some members of the GSSAPI community
asked me if the
<br>SASL GSSAPI document was ready to go.&nbsp; I replied that in my opinion
it
<br>was.&nbsp; Consequently, they will be with my approval sending a request
for
<br>that document to go to IETF Last Call for Proposed Standard.
<p>As the document makes substantial changes to the GSSAPI section of RFC
<br>2222, I believe it is important to get it to Proposed Standard as soon
<br>as possible.</blockquote>
Ok, here is the list of my comments (not in order of importance):
<p>1). Page header says "SASL instead of "GSSAPI SASL mechanism":
<br>Internet DRAFT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SASL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
September 8, 2000
<p>2). Section 2.1.&nbsp; "How to Read This Document" should be removed,
IMHO.
<p>3). If you want to have any examples, I would suggest to move section
2.3 after the section that describes GSSAPI SASL. The same applies to section
4. SPNEGO.
<p>4). Section 5."Base32 encoding" describes base32 in details. Is it really
so important to describe all particular cases of base32 (especially padding)
that are never used in the document, because MD5 hash is always 16 bytes?
<p>5). Section 5:
<p>>&nbsp;&nbsp; Any characters outside of the base32 alphabet are to be
ignored in
<br>>&nbsp;&nbsp; base32-encoded data.
<p>I am not sure what a developer should do after reading this statement.
Characters outside of base32 alphabet can never appear in a valid base32
string.
<p>6). In section 6.1:
<p>[skipped]
<br>>&nbsp;&nbsp; The client passes this token to GSS_Unwrap and interprets
<br>>&nbsp;&nbsp; the first octet of resulting cleartext as a bit-mask
specifying the
<br>>&nbsp;&nbsp; security layers supported by the server and the second
through fourth
<br>>&nbsp;&nbsp; octets as the maximum size output_message to send to
the server
<p>Missing <b>"in network byte order"</b>
<p>>&nbsp;&nbsp; The client then constructs data, with the first octet
containing the
<br>>&nbsp;&nbsp; bit-mask specifying the selected security layer, the
second through
<br>>&nbsp;&nbsp; fourth octets containing in network byte order the maximum
size
<br>>&nbsp;&nbsp; output_message the client is able to receive, and the
remaining
<br>>&nbsp;&nbsp; octets
<p>Suggestion to add <b>"(if any)"</b>: it might be obvious, but it is
better to clarify that if authorization identity is empty, than nothing
is appended to the buffer unlike PLAIN mechanism (this is for all C programmers
who are used to NUL terminated strings :-)).
<p>>&nbsp;&nbsp; containing the UTF-8 encoded [UTF8] authorization identity.
<br>>&nbsp;&nbsp; The client passes the data to GSS_Wrap with conf_flag
set to FALSE,
<br>>&nbsp;&nbsp; and responds with the generated output_message.&nbsp;
The client can then
<br>>&nbsp;&nbsp; consider the server authenticated.
<br>&nbsp;
<p>7) In section 6.2.&nbsp; "Server side of authentication protocol exchange":
<p>>&nbsp;&nbsp; The server passes the initial client response to
<br>>&nbsp;&nbsp; GSS_Accept_sec_context as input_token, setting input_context_handle
<br>>&nbsp;&nbsp; to 0 (initially)<b>,</b>
<p>Suggestion to add the following text:
<p><b>mech_type of the GSSAPI mechanism for which this</b>
<br><b>SASL mechanism is registered, and an acceptor_cred_handle, equal
to output_cred_handle from gss_acquire_cred called with desired_name parameter
equal to output_name from gss_import_name called with input_name_type of
GSS_C_NT_HOSTBASED_SERVICE and input_name_string of</b>
<br><b>"service@hostname" where "service" is the service name specified
in</b>
<br><b>the protocol's profile, and "hostname" is the fully qualified host</b>
<br><b>name of the server.</b>
<p>(I am not sure what is the best way to explain this, the idea is to
call gss_import_name first and than gss_acquire_cred).
<p>[skipped]
<br>>&nbsp;&nbsp; The server must then pass the resulting response to GSS_Unwrap
and
<br>>&nbsp;&nbsp; interpret the first octet of resulting cleartext as the
bit-mask for
<br>>&nbsp;&nbsp; the selected security layer, the second through fourth
octets as the
<br>>&nbsp;&nbsp; maximum size output_message to send to the client
<p>Missing<b> "[in network byte order]"</b>
<p>> , and the remaining
<br>>&nbsp;&nbsp; octets as the authorization identity.&nbsp; The server
must verify that
<br>>&nbsp;&nbsp; the src_name is authorized to authenticate as the authorization
<br>> identity.&nbsp; After these verifications, the authentication process
is
<br>>&nbsp;&nbsp; complete.
<p>8). Appendix A lists two OIDs in use for Kerberos V5 GSSAPI mechanism.
The description of Kerberos V5 GSSAPI mechanism should probably list them.
<br>&nbsp;
<p>General comments from implementation experience of Kerberos V5 GSSAPI:
<p>1). It would be nice to have some discussion about error handling in
authentication exchange. For example, what if server sends an additional
data following the maximal block size it is able to accept?
<p>2). GSSAPI allows for requesting of various protection flags in gss_init_sec_context
(req_flags parameter). The document doesn't describe which flags should
be passed to gss_init_sec_context (CMU implementation uses GSS_C_MUTUAL_FLAG
| GSS_C_SEQUENCE_FLAG, our implementation uses GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG
| GSS_C_SEQUENCE_FLAG, University of Washington uses GSS_C_MUTUAL_FLAG
| GSS_C_REPLAY_FLAG) and what server side should do if it is not satisfied
with negotiated protection flags. This obviously depends on GSSAPI implementation,
but it would be beneficial to have some recommendations.
<p>3). Neither client side, nor server side specify chan_bindings that
should be used in gss_accept_sec_context/gss_init_sec_context. In all implementations
I've seen this parameter is specified as GSS_C_NO_CHANNEL_BINDINGS.
<p>Alexey
<br>&nbsp;</html>

--------------2B745C02841C43ADC28F54FF--

Date: Wed, 28 Mar 2001 20:43:10 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Keith Burdis <[email-masked]>, [email-masked]
Subject: Re: DIGEST-MD5: Family of mechanisms?
Sender: [email-masked]

"Kurt D. Zeilenga" wrote:

> At 05:58 PM 3/27/01 +0200, Keith Burdis wrote:
> >One possible change to the Digest-MD5 specification could be to
> >make it specify a family of mechanism, each using a different
> >one-way function. This would mean that the same mechanism
> >could be used with new and existing one-way functions, and would
> >minimise the problems caused by a weakness being found in any
> >particular one-way function.
> >
> >This specification would still be upwardly compatible with the
> >HTTP \"md5-sess\" algorithm, since Digest-MD5 would be the same as
> >before.
> >
> >Does anyone think that such a change would be useful?

I support the idea.

> What are
> >the potential drawbacks of this change?
>
> We just need to be careful not to cause DIGEST-MD5 to unnecessarily
> recycle at Proposed.
>
> I did chat with JeffS and he thought we likely can add AES as an
> alternative cipher without recycling.  We might be able to add SHA1,
> or at least the framework for additional hash functions, without
> recycling at Proposed.

I believe you are right. Section 1.1 of the RFC 2831 says:

>1.1  Conventions and Notation
>
[skipped]
>   Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s.

This seems like an intention of the authors to be able to use different
hashing algorithms.

Alexey

Date: Tue, 27 Mar 2001 19:34:32 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: SASL WG formation recommended
Sender: [email-masked]

After reviewing the list comments and clarifying the positions
of select individuals who raised issues, Alexey and I have
concluded the consensus of this supported recommending the
"Proposed Charter".  Hence, I have submitted the following
charter (same as discussed excepting with less typos) for
consideration by our ADs.

I commend everyone for making this happen.

I note that while the formation of the WG is being considered,
we can continue making progress on work items.  Though we cannot
take any WG action (no WG I-Ds, no WG last calls, no WG
submissions to the IESG), we can continue to edit I-D submitted
by individuals and continue to make things happen.

Live long and standardize!

Regards, Kurt

Simple Authentication and Security Layer (SASL)

Chair(s):
  Kurt Zeilenga <[email-masked]>
  Alexey Melnikov <[email-masked]>

Security Area Advisor: <[email-masked]>
Applications Area Advisor: <[email-masked]>

Mailing Lists:
  General Discussions: <[email-masked]>
  To Subscribe: <[email-masked]>
  In Body: subscribe
  Archive: http://www.imc.org/ietf-sasl/mail-archive/

Description of Working Group

  The Simple Authentication and Security Layer [RFC2222] provides
  key security services to a number of application protocols
  including BEEP, IMAP, LDAP, POP, and SMTP.  The purpose of
  this working group is to shepherd SASL, including select SASL
  mechanisms, through the Internet Standards process.

  This group will deliver a revised SASL Technical Specification
  suitable for consideration as a Draft Standard.  This work
  will be based upon RFC 2222 and draft-myers-saslrev-00.txt.

  This group will deliver revised Technical Specifications
  suitable for consideration as Draft Standards for the following
  SASL mechanisms: CRAM-MD5, DIGEST-MD5, and EXTERNAL.  This work
  will be based upon RFC 2195, RFC 2222, and RFC 2831.

  This group will deliver a revised Technical Specification
  suitable for publication as Proposed Standard for the GSSAPI
  family of SASL mechanisms.  This work will be based upon
  RFC 2222 and draft-ietf-cat-sasl-gssapi-02.txt.

  This group will deliver a Technical Specification
  suitable for publication as Proposed Standard describing
  a family of SASL mechanisms using the Secure Remote
  Password [RFC2945] protocol.  This work will be based
  upon draft-burdis-cat-srp-sasl-04.txt.

  The following areas are not within the scope of work of this WG:
    - new features,
    - SASL Mechanisms not specifically mentioned above, and
    - SASL "profiles".

  However, the SASL WG is an acceptable forum for review of
  SASL-related submissions produced by others as long as such
  review does not impede progress on the WG objectives listed
  above.

Goals and Milestones
  Apr 01  Submit revised SASL (+ EXTERNAL) I-D
  May 01  Submit revised SASL CRAM-MD5 I-D
  May 01  Submit revised SASL DIGEST-MD5 I-D
  May 01  Submit revised SASL GSSAPI I-D
  May 01  Submit SASL SRP I-D
  Jul 01  Submit Implementation Report
  Aug 01  Submit revised SASL, CRAM-MD5, DIGEST-MD5 I-Ds with
          Implementation Report to IESG for consideration as
          a Draft Standard
  Nov 01  Submit revised SASL GSSAPI I-D to IESG for consideration
          as a Proposed Standard
  Nov 01  Submit SASL SRP I-D to IESG for consideration as a
          Proposed Standard
  Dec 01  Revise charter or conclude     

Date: Tue, 27 Mar 2001 19:37:35 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Raif S. Naffah" <[email-masked]>
CC: [email-masked]
Subject: Re: WG and SASL C API document
Sender: [email-masked]

"Raif S. Naffah" wrote:

> whatever the outcome of this discussion is, wrt. inclusion in the charter,
> i urge the authors of the C API to have a look at SM2 and the proposed
> extended interfaces (Java API) to support cache-and-re-use of cryptographic
> parameters of the/any SASL security layer.

Noted.

Date: Tue, 27 Mar 2001 16:12:16 -0800
From: Chris Newman <[email-masked]>
Subject: RE: DIGEST-MD5: fix ABNF to account for UTF-8/ISO-8859-1
To: Paul Leach <[email-masked]>, [email-masked]
Sender: [email-masked]

I've got a copy of the nroff source the RFC editor used.  If you don't grok 
nroff and would rather I do the editorial gruntwork on this round, that 
would be fine with me.

		- Chris

--On Monday, March 26, 2001 21:29 -0800 Paul Leach 
<[email-masked]> wrote:
> I've got a copy of -05 I-D that had an expiration date of April 21,
> 2000. That seems to be the latest I've got.

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: DIGEST-MD5: fix ABNF to account for UTF-8/ISO-8859-1
Date: Tue, 27 Mar 2001 13:29:59 -0800
Organization: Netscape Communications Corporation
Lines: 24
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

Chris Newman wrote:
> Actually, the ABNF does not restrict those values to US-ASCII:
> 
>        username-value   = qdstr-val
> ...
>        authzid-value    = qdstr-val
> ...
>        TEXT           = <any OCTET except CTLs,
>                         but including LWS>
> ...
>       qdstr-val      = *( qdtext | quoted-pair )
>       qdtext         = <any TEXT except <">>

Strangely:

       quoted-pair    = "\" CHAR

which is restricted to ASCII.  I would prefer to restrict it to CTLs,
<"> and "\".  Restricting to ASCII may be justifiable as \-quoted UTF-8
could be troublesome to parsers.

The grammar for qdstr-val is ambiguous as qdtext permits "\".

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: DIGEST-MD5: prohibit quoting in nonce and cnonce
Date: Tue, 27 Mar 2001 13:21:23 -0800
Organization: Netscape Communications Corporation
Lines: 13
NNTP-Posting-Host: 192.18.126.70
Sender: [email-masked]

Chris Newman wrote:
> That would break compatibility with RFC 2617 which is already draft
> standard.

This does not "break" compatibility with RFC 2617, it merely prohibits
the use of some RFC 2617 options.  It is similar to the requirement that
the "opaque" and "domain" options not be sent.

Are there any RFC 2617 implementations which actually send quoted nonces
or cnonces?  Do RFC 2617 implementations actually implement this
correctly?

Date: Wed, 28 Mar 2001 05:57:42 +1000
To: "Kurt D. Zeilenga" <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: WG and SASL C API document
Cc: Tony Hansen <[email-masked]>, Lyndon Nerenberg <[email-masked]>, [email-masked]
Sender: [email-masked]

At 11:15 AM 3/27/01 -0800, Kurt D. Zeilenga wrote:
>At 01:50 PM 3/27/01 -0500, Tony Hansen wrote:
> >Personally I'd rather define a C++ API. (I even have such an API
> >implemented.) :-)
>
>One could define the API using an interface definition language
>of some sort and then define language specific bindings as
>appropriate.  :-D

well;  there is IDL to Java bindings 
(http://www.omg.org/technology/documents/formal/omg_idl_to_java_language_mapping.htm), 
as well as Java to IDL bindings 
(http://www.omg.org/technology/documents/formal/java_language_mapping_to_omg_idl.htm). 
would that then qualify Java as such an API specifications langaugae ?  :-)

cheers;
rsn

Date: Tue, 27 Mar 2001 14:35:01 -0500
From: Tony Hansen <[email-masked]>
To: Paul Leach <[email-masked]>
CC: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: DIGEST-MD5: fix ABNF to account for UTF-8/ISO-8859-1
Sender: [email-masked]

Check with the rfc-editor ([email-masked]). They are
(usually) quite willing to provide the last source text used for the
actual RFC to authors working on a revision.

	Tony Hansen
	[email-masked]

Paul Leach wrote:
> 
> > -----Original Message-----
> > From: Chris Newman [mailto:[email-masked]]
> > Sent: Monday, March 26, 2001 7:45 PM
> 
> >
> > BTW, is the primary document editor for the digest revision
> > reading this list?
> > Or should I volunteer to be the primary editor for the revision?
> 
> Yes, I'm reading it.
> 
> Who has the last copy of the RFC text -- you or me?
> 
> I've got a copy of -05 I-D that had an expiration date of April 21,
> 2000. That seems to be the latest I've got.
> 
> Paul

Date: Tue, 27 Mar 2001 11:15:46 -0800
To: Tony Hansen <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: WG and SASL C API document
Cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
Sender: [email-masked]

At 01:50 PM 3/27/01 -0500, Tony Hansen wrote:
>Personally I'd rather define a C++ API. (I even have such an API
>implemented.) :-)

One could define the API using an interface definition language
of some sort and then define language specific bindings as
appropriate.  :-D

Date: Tue, 27 Mar 2001 10:56:24 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
Reply-To: "RL 'Bob' Morgan" <[email-masked]>
To: Steve Miller <[email-masked]>
cc: <[email-masked]>, IETF ldapbis WG <[email-masked]>
Subject: Re: DIGEST-MD5: conflict between RFC 2829 and RFC 2831
Sender: [email-masked]

Steve:

As Kurt mentioned, both RFCs 2829 and 2831 are in the process of being
rewritten to move to Draft Standard status (if possible) and discussion is
happening on the ietf-ldabis list.  The content of RFC 2829 in particular
will be reorganized for clarity, including the bind/sasl language
currently in RFC 2251.  This bug (thanks for the catch, Steve, and you
too, Larry) is an excellent example of why it is A Bad Thing to restate
specifics of SASL mechanisms in application-protocol SASL profiles, so we
should avoid making this mistake again as we rewrite.

 - RL "Bob"

---

> Since I've just started following these lists, I'm not clear on how to
> get this resolved; I'm certainly willing to help.  A possible re-wording
> is:
>
>
> RFC 2831
>   ...
>   The server receives and validates the "digest-response". The server
>   checks that the nonce-count is "00000001". It sends a message
> formatted as follows:
>
>   ...(description of rspauth )...
>
>   If the server supports subsequent authentication (see section 2.2), it
> saves the value of the nonce   and the nonce-count.
>   ...
>
> RFC 2829
>    ...
>    The server will respond with a bind response in which the resultCode
>    is either success, or an error indication.  If the authentication is
>    successful , then the credentials field contains the string defined
> by "response-auth"
>    in section 2.1.3 of [4].   Support for subsequent authentication is
>    OPTIONAL in clients and servers.
>    ...

Date: Wed, 28 Mar 2001 04:52:56 +1000
To: Alexey Melnikov <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: WG and SASL C API document
Cc: Claus Assmann <[email-masked]>, [email-masked], Rob Weltman <[email-masked]>
Sender: [email-masked]

At 12:23 AM 3/27/01 -0700, Alexey Melnikov wrote:
>Claus Assmann wrote:
>
> > On Mon, Mar 26, 2001, Kurt D. Zeilenga wrote:
> > > At 12:31 PM 3/26/01 -0700, Lyndon Nerenberg wrote:
> > > >So where do we sit wrt the WG issuing an informational C API
> > > >document?
> >
> > > >I think it's very important that an informational API document be
> > > >issued.  Having a common interface is critical if we are to see SASL
> > > >adopted widely in the community (especially the open source projects).
> > > >(IMO.)
> > >
> > > I disagree.  An API RFC is not critical to the wide adoption
> > > of SASL.
> >
> > Maybe not critical, but it would make life of the open source
> > developers (at least mine and possibly also Larry's) simpler.
>
>I agree with Lyndon and Claus, that C API is very important for deployment:
>you can write SASL mechanism plugin once and use it in every compatible
>system. (I wish I didn't have to change DIGEST-MD5 code when I converted it
>from CMU API to our own!).
>
>Saying that I vote to add C API to the Charter.

whatever the outcome of this discussion is, wrt. inclusion in the charter, 
i urge the authors of the C API to have a look at SM2 and the proposed 
extended interfaces (Java API) to support cache-and-re-use of cryptographic 
parameters of the/any SASL security layer.

>Alexey

cheers;
rsn

Date: Tue, 27 Mar 2001 13:50:21 -0500
From: Tony Hansen <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
CC: [email-masked]
Subject: Re: WG and SASL C API document
Sender: [email-masked]

Personally I'd rather define a C++ API. (I even have such an API
implemented.) :-)

	Tony Hansen
	[email-masked]

Lyndon Nerenberg wrote:
> 
> So where do we sit wrt the WG issuing an informational C API
> document? My scan of the list archives shows that four people
> (Larry Greenfield, Chris Newman, Raif Naffah, Leif Johansson)
> have explicitly come out in favour of this, although Chris
> prefers the document be an individual submission. You can
> add my name to this list, with a leaning towards this being
> a WG document. I don't see any specific opposition to the
> document.
> 
> I think it's very important that an informational API document be
> issued. Having a common interface is critical if we are to see SASL
> adopted widely in the community (especially the open source projects).
> (IMO.)
> 
> --lyndon

Date: Tue, 27 Mar 2001 10:47:19 -0800
To: "Paul Leach" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: DIGEST-MD5: fix ABNF to account for UTF-8/ISO-8859-1
Cc: "Chris Newman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 09:29 PM 3/26/01 -0800, Paul Leach wrote:
>> -----Original Message-----
>> From: Chris Newman [mailto:[email-masked]] 
>> Sent: Monday, March 26, 2001 7:45 PM
>
>> 
>> BTW, is the primary document editor for the digest revision 
>> reading this list?
>> Or should I volunteer to be the primary editor for the revision?
>
>Yes, I'm reading it.
>
>Who has the last copy of the RFC text -- you or me?

http://www.rfc-editor.org/

I would be very leery of using some old expired I-D as
a basis for this work as it may be different than the
actual published technical specification.   You should
start with RFC2831 (as found on the RFC editor website)
so that you sure not to introduce unintended changes. 
I note that each revised technical specification I-D
should contain an appendix detailing all substantive
changes since the existing RFC.

Kurt

Date: Tue, 27 Mar 2001 10:33:58 -0800
To: Keith Burdis <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: DIGEST-MD5: Family of mechanisms?
Cc: [email-masked]
Sender: [email-masked]

At 05:58 PM 3/27/01 +0200, Keith Burdis wrote:
>One possible change to the Digest-MD5 specification could be to
>make it specify a family of mechanism, each using a different
>one-way function. This would mean that the same mechanism
>could be used with new and existing one-way functions, and would
>minimise the problems caused by a weakness being found in any
>particular one-way function.
>
>This specification would still be upwardly compatible with the
>HTTP \"md5-sess\" algorithm, since Digest-MD5 would be the same as
>before.
>
>Does anyone think that such a change would be useful? What are
>the potential drawbacks of this change?

We just need to be careful not to cause DIGEST-MD5 to unnecessarily
recycle at Proposed.

I did chat with JeffS and he thought we likely can add AES as an
alternative cipher without recycling.  We might be able to add SHA1,
or at least the framework for additional hash functions, without
recycling at Proposed.

Kurt

Date: Tue, 27 Mar 2001 09:26:52 -0800
To: Steve Miller <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: DIGEST-MD5: conflict between RFC 2829 and RFC 2831
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Please cc [email-masked] on any issue pertaining
to the LDAP SASL profile (RFC 2251/2829).  I note that DIGEST-MD5
is actually on the LDAPbis charter as well... (at least until
a SASL WG is formed).

Kurt

At 11:22 AM 3/27/01 -0500, Steve Miller wrote:
>Hi,
>
>We are currently building our own ldap/SASL DIGEST-MD5 implementation,
>and have been testing against the Openldap (2.0.7) with the Cyrus
>(1.5.24) SASL implementation. We have source code for both.
>
>We ran into an interoperability problem between the OpenLdap/Cyrus
>client and our server. I tracked it down to a difference in step 3 of
>RFC2831, that is the second server response to the client. Section 2.1.3
>of that spec says:
>
>2.1.3  Step Three
>
>   The server receives and validates the "digest-response". The server
>   checks that the nonce-count is "00000001". If it supports subsequent
>   authentication (see section 2.2), it saves the value of the nonce and
>** the nonce-count. It sends a message formatted as follows:
>
>    response-auth = "rspauth" "=" response-value
>    ...
>
>   where response-value is calculated as above, using the values sent in
> 
>
>And RFC 2829, Authentication Methods for LDAP, section 6.1 says:
>
>   ...
>   The server will respond with a bind response in which the resultCode
>   is either success, or an error indication.  If the authentication is
>** successful and the server does not support subsequent authentication,
>** then the credentials field is absent.  If the authentication is
>   successful and the server supports subsequent authentication, then
>   the credentials field contains the string defined by "response-auth"
>   in section 2.1.3 of [4].   Support for subsequent authentication is
>   OPTIONAL in clients and servers.
>
>
>According to subsequent email discussions with Larry Greenfield
>(CMU/Cyrus), RFC 2829 is incorrect in this regard, and inconsistent with
>current practice, which always send the 'rspauth', even if the server
>does not support subsequent authentication.
>
>Since I've just started following these lists, I'm not clear on how to
>get this resolved; I'm certainly willing to help.  A possible re-wording
>is:
>
>
>RFC 2831
>  ...
>  The server receives and validates the "digest-response". The server
>  checks that the nonce-count is "00000001". It sends a message
>formatted as follows:
>
>  ...(description of rspauth )...
>
>  If the server supports subsequent authentication (see section 2.2), it
>saves the value of the nonce   and the nonce-count.
>  ...
>
>RFC 2829
>   ...
>   The server will respond with a bind response in which the resultCode
>   is either success, or an error indication.  If the authentication is
>   successful , then the credentials field contains the string defined
>by "response-auth"
>   in section 2.1.3 of [4].   Support for subsequent authentication is
>   OPTIONAL in clients and servers.
>   ...
>
>
>Steve

Date: Tue, 27 Mar 2001 11:22:13 -0500
From: Steve Miller <[email-masked]>
Organization: OPENWAVE
To: [email-masked]
Subject: DIGEST-MD5: conflict between RFC 2829 and RFC 2831
Sender: [email-masked]

Hi,

We are currently building our own ldap/SASL DIGEST-MD5 implementation,
and have been testing against the Openldap (2.0.7) with the Cyrus
(1.5.24) SASL implementation. We have source code for both.

We ran into an interoperability problem between the OpenLdap/Cyrus
client and our server. I tracked it down to a difference in step 3 of
RFC2831, that is the second server response to the client. Section 2.1.3
of that spec says:

2.1.3  Step Three

   The server receives and validates the "digest-response". The server
   checks that the nonce-count is "00000001". If it supports subsequent
   authentication (see section 2.2), it saves the value of the nonce and
** the nonce-count. It sends a message formatted as follows:

    response-auth = "rspauth" "=" response-value
    ...

   where response-value is calculated as above, using the values sent in

And RFC 2829, Authentication Methods for LDAP, section 6.1 says:

   ...
   The server will respond with a bind response in which the resultCode
   is either success, or an error indication.  If the authentication is
** successful and the server does not support subsequent authentication,
** then the credentials field is absent.  If the authentication is
   successful and the server supports subsequent authentication, then
   the credentials field contains the string defined by "response-auth"
   in section 2.1.3 of [4].   Support for subsequent authentication is
   OPTIONAL in clients and servers.

According to subsequent email discussions with Larry Greenfield
(CMU/Cyrus), RFC 2829 is incorrect in this regard, and inconsistent with
current practice, which always send the 'rspauth', even if the server
does not support subsequent authentication.

Since I've just started following these lists, I'm not clear on how to
get this resolved; I'm certainly willing to help.  A possible re-wording
is:

RFC 2831
  ...
  The server receives and validates the "digest-response". The server
  checks that the nonce-count is "00000001". It sends a message
formatted as follows:

  ...(description of rspauth )...

  If the server supports subsequent authentication (see section 2.2), it
saves the value of the nonce   and the nonce-count.
  ...

RFC 2829
   ...
   The server will respond with a bind response in which the resultCode
   is either success, or an error indication.  If the authentication is
   successful , then the credentials field contains the string defined
by "response-auth"
   in section 2.1.3 of [4].   Support for subsequent authentication is
   OPTIONAL in clients and servers.
   ...

Steve

To: [email-masked]
Subject: DIGEST-MD5: Family of mechanisms?
Date: Tue, 27 Mar 2001 17:58:21 +0200 (SAST)
From: Keith Burdis <[email-masked]>
Sender: [email-masked]

Hi there

One possible change to the Digest-MD5 specification could be to
make it specify a family of mechanism, each using a different
one-way function. This would mean that the same mechanism
could be used with new and existing one-way functions, and would
minimise the problems caused by a weakness being found in any
particular one-way function.

This specification would still be upwardly compatible with the
HTTP \"md5-sess\" algorithm, since Digest-MD5 would be the same as
before.

Does anyone think that such a change would be useful? What are
the potential drawbacks of this change?
 
  - Keith
--
Keith Burdis                        
---

To: [email-masked]
Subject: Re: SASL GSSAPI to IETF Last Call
Date: Tue, 27 Mar 2001 17:37:18 +0200 (SAST)
From: Keith Burdis <[email-masked]>
Sender: [email-masked]

  - Keith
--
Keith Burdis                        
---

Date: Tue, 27 Mar 2001 01:42:17 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: WG and SASL C API document
Cc: Claus Assmann <[email-masked]>, [email-masked]
Sender: [email-masked]

I think we're bitting off too much work.  We already
have 5 Standard Track documents to produce in a very
short period of time are will likely soon be discussing
an additional mechanism document.  It's been my experience
that working groups can only make significant progress on
a few documents at a time even when you have plenty of
editing resources.  It's also my experience that API
documents can be quite contentious and time consuming
(for the authors and the WG as a whole).

I don't argue that a common C API has potential benefits,
I argue that this WG efforts to produce a SASL Draft
Standard in a timely manner will likely be significantly
impeded if we take on this work.  I believe it best
that this work be undertaken individually for now.  I note
that once we complete the critical work to produce a Draft
Standard, we can and should revise our charter to take on
additional work.

-- Kurt

Date: Tue, 27 Mar 2001 00:23:08 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Claus Assmann <[email-masked]>
CC: [email-masked]
Subject: Re: WG and SASL C API document
Sender: [email-masked]

Claus Assmann wrote:

> On Mon, Mar 26, 2001, Kurt D. Zeilenga wrote:
> > At 12:31 PM 3/26/01 -0700, Lyndon Nerenberg wrote:
> > >So where do we sit wrt the WG issuing an informational C API
> > >document?
>
> > >I think it's very important that an informational API document be
> > >issued.  Having a common interface is critical if we are to see SASL
> > >adopted widely in the community (especially the open source projects).
> > >(IMO.)
> >
> > I disagree.  An API RFC is not critical to the wide adoption
> > of SASL.
>
> Maybe not critical, but it would make life of the open source
> developers (at least mine and possibly also Larry's) simpler.

I agree with Lyndon and Claus, that C API is very important for deployment:
you can write SASL mechanism plugin once and use it in every compatible
system. (I wish I didn't have to change DIGEST-MD5 code when I converted it
from CMU API to our own!).

Saying that I vote to add C API to the Charter.

Alexey

Date: Mon, 26 Mar 2001 22:40:05 -0800
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SASL GSSAPI to IETF Last Call
Cc: [email-masked]
Sender: [email-masked]

Other notes:

Date: Mon, 26 Mar 2001 21:40:04 -0800
To: Chris Newman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: DIGEST-MD5: fix ABNF to account for UTF-8/ISO-8859-1
Cc: [email-masked]
Sender: [email-masked]

At 07:44 PM 3/26/01 -0800, Chris Newman wrote:
>BTW, is the primary document editor for the digest revision reading this list? Or should I volunteer to be the primary editor for the revision?

Paul has volunteered to serve as document editor and I
believe he's on the list.

Subject: RE: DIGEST-MD5: fix ABNF to account for UTF-8/ISO-8859-1
Date: Mon, 26 Mar 2001 21:29:19 -0800
content-class: urn:content-classes:message
From: "Paul Leach" <[email-masked]>
To: "Chris Newman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Chris Newman [mailto:[email-masked]] 
> Sent: Monday, March 26, 2001 7:45 PM

> 
> BTW, is the primary document editor for the digest revision 
> reading this list?
> Or should I volunteer to be the primary editor for the revision?

Yes, I'm reading it.

Who has the last copy of the RFC text -- you or me?

I've got a copy of -05 I-D that had an expiration date of April 21,
2000. That seems to be the latest I've got.

Paul

Date: Mon, 26 Mar 2001 19:44:39 -0800
From: Chris Newman <[email-masked]>
Subject: Re: DIGEST-MD5: fix ABNF to account for UTF-8/ISO-8859-1
To: [email-masked]
Sender: [email-masked]

--On Monday, March 26, 2001 16:52 -0800 John Gardiner Myers 
<[email-masked]> wrote:

> The document prose allows UTF-8 in the authzid-value and either UTF-8 or
> ISO-8859-1 in the username-value, depending on the value of the charset
> directive.  The ABNF incorrectly restricts these values to US-ASCII.
> The ABNF needs to be corrected.

Actually, the ABNF does not restrict those values to US-ASCII:

       username-value   = qdstr-val
...
       authzid-value    = qdstr-val
...
       TEXT           = <any OCTET except CTLs,
                        but including LWS>
...
      qdstr-val      = *( qdtext | quoted-pair )
      qdtext         = <any TEXT except <">>

But the prose above "TEXT" is severely broken:

   The TEXT rule is only used for descriptive field contents and values
   that are not intended to be interpreted by the message parser. Words
   of *TEXT MAY contain characters from character sets other than
   ISO-8859-1 [ISO 8859] only when encoded according to the rules of RFC
   2047 [RFC 2047].

Ironically, when TEXT is used in double-quotes, RFC 2047 encoding isn't 
permitted, so this prose restricts it to 8859-1 which contradicts previous 
statements.  I recall raising this problem before 2831 was published, but I 
guess it got lost in the noise.  The HTTP baggage in DIGEST-MD5 is 
sometimes quite unpleasant.

BTW, is the primary document editor for the digest revision reading this 
list?
Or should I volunteer to be the primary editor for the revision?

		- Chris

Date: Mon, 26 Mar 2001 19:26:00 -0800
From: Chris Newman <[email-masked]>
Subject: Re: DIGEST-MD5: prohibit quoting in nonce and cnonce
To: John Gardiner Myers <[email-masked]>, [email-masked]
Sender: [email-masked]

That would break compatibility with RFC 2617 which is already draft 
standard.

		- Chris

--On Monday, March 26, 2001 16:46 -0800 John Gardiner Myers 
<[email-masked]> wrote:

> The nonce and cnonce currently can include backslash quoting.  This is
> needlessly complex and is unlikely to be correctly implemented.  I
> propose tightening the syntax to disallow quoting in these values:
>
>	 nonce-value = *qdtext
>	 cnonce-value = *qdtext

Date: Mon, 26 Mar 2001 17:20:48 -0800
From: Chris Newman <[email-masked]>
Subject: SRP and SM2
To: [email-masked]
Sender: [email-masked]

I think SRP fills a useful niche.  Relative to DIGEST-MD5, it trades speed 
and management flexability for a significant improvement in wire and 
server-side security.

However, Jeff Schiller has made it quite clear that slow PK-based 
algorithms (like SRP) need a fast restart mechanism before they're suitable 
for the standards track.  If I understand the proposal correct, SM2 is the 
fast-restart mechanism to go with SRP and thus SM2 needs to go to the 
standards track before or at the same time that SRP does.  If we only look 
at one of the two in the WG, it needs to be SM2 since that could have a 
broader scope than just SRP.

		- Chris

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: DIGEST-MD5: fix ABNF to account for UTF-8/ISO-8859-1
Date: Mon, 26 Mar 2001 16:52:06 -0800
Organization: Netscape Communications Corporation
Lines: 58
NNTP-Posting-Host: 192.18.127.196
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms2C2206CABE9671BBF67DF83A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The document prose allows UTF-8 in the authzid-value and either UTF-8 or
ISO-8859-1 in the username-value, depending on the value of the charset
directive.  The ABNF incorrectly restricts these values to US-ASCII. 
The ABNF needs to be corrected.
--------------ms2C2206CABE9671BBF67DF83A
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

--------------ms2C2206CABE9671BBF67DF83A--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: DIGEST-MD5: prohibit quoting in nonce and cnonce
Date: Mon, 26 Mar 2001 16:46:18 -0800
Organization: Netscape Communications Corporation
Lines: 60
NNTP-Posting-Host: 192.18.127.196
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msC3EF86BC65B38429E6B3F172
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The nonce and cnonce currently can include backslash quoting.  This is
needlessly complex and is unlikely to be correctly implemented.  I
propose tightening the syntax to disallow quoting in these values:

	nonce-value = *qdtext
	cnonce-value = *qdtext
--------------msC3EF86BC65B38429E6B3F172
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

--------------msC3EF86BC65B38429E6B3F172--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: DIGEST-MD5: missing versus empty authzid
Date: Mon, 26 Mar 2001 16:42:41 -0800
Organization: Netscape Communications Corporation
Lines: 73
NNTP-Posting-Host: 192.18.127.196
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms4A46701EE877DABB80C6BB57
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A reported DIGEST-MD5 implementation incompatibility is the ambiguity in
the specification for how to calculate A1 when the authzid-value is
explicitly specified as being the empty string.  When the
digest-response contains an explicit:

	authzid=""

does one include a trailing ":" in the computation of A1 or not?

I propose not.  I suggest changing the text in 2.1.2.1 to:

	If authzid is specified as a nonempty string, then A1 is

	If authzid is not specified or is the empty string, then A1 is

Additionally, we should disallow explicitly specifying the authiz-value
as the empty string.  To do that, we would change the ABNF as follows:

        authzid-value = 1*( qdtext | quoted-pair )
--------------ms4A46701EE877DABB80C6BB57
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

--------------ms4A46701EE877DABB80C6BB57--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: draft SASL base spec
Date: Mon, 26 Mar 2001 16:32:22 -0800
Organization: Netscape Communications Corporation
Lines: 62
NNTP-Posting-Host: 192.18.127.196
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msF762B3AF2479C4B844955F14
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> I think the IANA registration of family of mechanisms
> (e.g. GSS-*) may need special considerations.

Thank you, this had slipped my mind.  I have submitted a revised
document to the Internet Drafts editor.
--------------msF762B3AF2479C4B844955F14
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

--------------msF762B3AF2479C4B844955F14--

Date: Mon, 26 Mar 2001 16:11:43 -0800
From: Claus Assmann <[email-masked]>
To: [email-masked]
Subject: Re: WG and SASL C API document
Sender: [email-masked]

On Mon, Mar 26, 2001, Kurt D. Zeilenga wrote:
> At 12:31 PM 3/26/01 -0700, Lyndon Nerenberg wrote:
> >So where do we sit wrt the WG issuing an informational C API
> >document?

> >I think it's very important that an informational API document be
> >issued.  Having a common interface is critical if we are to see SASL
> >adopted widely in the community (especially the open source projects).
> >(IMO.)
> 
> I disagree.  An API RFC is not critical to the wide adoption
> of SASL.

Maybe not critical, but it would make life of the open source
developers (at least mine and possibly also Larry's) simpler.

Date: Mon, 26 Mar 2001 15:30:56 -0800
To: Lyndon Nerenberg <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: WG and SASL C API document
Cc: [email-masked]
Sender: [email-masked]

At 12:31 PM 3/26/01 -0700, Lyndon Nerenberg wrote:
>So where do we sit wrt the WG issuing an informational C API
>document?

Currently it is not listed as a work item.  It's my
belief that there is not wide support for adding a C API
work item.  The comments you note by being in favour of
this work I believe are dated (I have chatted with most
everyone you note about this very issue).  I believe there
is good consensus to recommend the latest proposed charter.

>I don't see any specific opposition to the document.

Please review the archives.  There was significant discussion
regarding the addition of APIs to the charter and the general
need for a narrow focus on critical issues.

>I think it's very important that an informational API document be
>issued.  Having a common interface is critical if we are to see SASL
>adopted widely in the community (especially the open source projects).
>(IMO.)

I disagree.  An API RFC is not critical to the wide adoption
of SASL.

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: WG and SASL C API document
Organization: ACI Worldwide
Date: Mon, 26 Mar 2001 12:31:02 -0700
Sender: [email-masked]

So where do we sit wrt the WG issuing an informational C API
document? My scan of the list archives shows that four people
(Larry Greenfield, Chris Newman, Raif Naffah, Leif Johansson)
have explicitly come out in favour of this, although Chris
prefers the document be an individual submission. You can
add my name to this list, with a leaning towards this being
a WG document. I don't see any specific opposition to the
document.

I think it's very important that an informational API document be
issued. Having a common interface is critical if we are to see SASL
adopted widely in the community (especially the open source projects).
(IMO.)

--lyndon

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: SASL GSSAPI to IETF Last Call
Date: Sun, 25 Mar 2001 14:30:16 -0800
Organization: Netscape Communications Corporation
Lines: 62
NNTP-Posting-Host: 205.217.228.76
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms33B2DBF6531CB2420F29E7F4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

As the document makes substantial changes to the GSSAPI section of RFC
2222, I believe it is important to get it to Proposed Standard as soon
as possible.
--------------ms33B2DBF6531CB2420F29E7F4
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

--------------ms33B2DBF6531CB2420F29E7F4--

Date: Sun, 25 Mar 2001 10:30:36 -0800
To: John Gardiner Myers <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft SASL base spec
Cc: [email-masked]
Sender: [email-masked]

John,

I think the IANA registration of family of mechanisms
(e.g. GSS-*) may need special considerations.

Kurt

Date: Sat, 24 Mar 2001 16:44:12 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Proposed charter of the SASL Working Group
Sender: [email-masked]

Here is the proposed charter I wish to recommend to the
IESG early next week.
  -- Kurt

Simple Authentication and Security Layer (SASL)

Area: Security

Chair(s):
  Kurt Zeilenga <[email-masked]>
  Alexey Melnikov <[email-masked]>

Security Area AD: <[email-masked]>
Applications Area Technical Advisor: <[email-masked]>

Mailing Lists:
  General Discussions: <[email-masked]>
  To Subscribe: <[email-masked]>
  In Body: subscribe
  Archive: http://www.imc.org/ietf-sasl/mail-archive/

Description of Working Group

  The Simple Authentication and Security Layer [RFC2222] provides
  key security services to a number of application protocols
  including BEEP, IMAP, LDAP, POP, and SMTP.  The purpose of
  this working group is to shepherd SASL, including select SASL
  mechanisms, though the Internet Standard process.

  This group will deliver a revised SASL Technical Specification
  suitable for consideration as a Draft Standard.  This work
  will be based upon RFC 2222 and draft-myers-saslrev-00.txt.

  This group will deliver revised Technical Specifications
  suitable considerations as Draft Standards for the following
  SASL mechanisms: CRAM-MD5, DIGEST-MD5, and EXTERNAL.  This work
  will be based upon RFC 2195, 2222, and 2831.

  This group will deliver a revised Technical Specification
  suitable for publication as Proposed Standard for the GSSAPI
  family of SASL mechanisms.  This work will be based upon
  RFC 2222 and draft-ietf-cat-sasl-gssapi-02.txt.

  This group will deliver a Technical Specification
  suitable for publication as Proposed Standard describing
  a family of SASL mechanisms using the Secure Remote
  Password [RFC2945] protocol.  This work will be based
  upon draft-burdis-cat-srp-sasl-04.txt.

  The following areas are not within the scope of work of this WG:
    - new features,
    - SASL Mechanisms not specifically mentioned above, and
    - SASL "profiles".

  However, the SASL WG is an acceptable forum for review of
  SASL-related submissions produced by others as long as such
  review does not impede progress on the WG objectives listed
  above.

Goals and Milestones
  Apr 01  Submit revised SASL (+ EXTERNAL) I-D
  May 01  Submit revised SASL CRAM-MD5 I-D
  May 01  Submit revised SASL DIGEST-MD5 I-D
  May 01  Submit revised SASL GSSAPI I-D
  May 01  Submit SASL SRP I-D
  Jul 01  Submit Implementation Report
  Aug 01  Submit revised SASL, CRAM-MD5, DIGEST-MD5 I-Ds with
          Implementation Report to IESG for consideration as
          a Draft Standard
  Nov 01  Submit revised SASL GSSAPI I-D to IESG for consideration
          as a Proposed Standard
  Nov 01  Submit SASL SRP I-D to IESG for consideration as a
          Proposed Standard
  Dec 01  Revise charter or conclude     

To: <[email-masked]>
Subject: Re: Draft charter of the SASL Working Group
Date: Sat, 24 Mar 2001 11:08:48 +0200
From: Keith Burdis <[email-masked]>
Sender: [email-masked]

Quoting \"Kurt D. Zeilenga\" <[email-masked]>:

> Assuming you and your co-authors are willing to relinquish
> technical and editorial \"control and ownership\" to this work
> to the IETF, I will not object to the addition of ONE additional
> mechanism (currently published as either RFC or I-D) to the
> proposed charter.  I will, however, continue to note my general
> reservations regarding the broadening of the proposed charter.
>
> In reviewing these,  I believe the SRP mechanism would be
> most appropriate to add.

We have no problem with relinquishing technical and editorial control and 
ownership of the SRP mechanism to the working group. In fact we would encourage 
this to ensure that the resulting mechanism is the consensus of the community 
on what an SRP-based mechanism should be.

> I offer the following text which could be added to proposed charter
> (just above the out-of-scope statement):
> 
>   This group will deliver a Technical Specification
>   suitable for publication as Proposed Standard describing
>   a family of SASL mechanisms using the Secure Remote
>   Password [RFC2945] protocol.  This work will be based
>   upon draft-burdis-cat-srp-sasl-04.txt.

This sounds fine.

> While the SM2 proposal is intriguing, I believe it best to
> leave it off the charter for now.  I encourage the authors
> to continue on an individual basis and to seek review as
> appropriate.

Perhaps it would be appropriate to bring up this topic as part 
of the process of revising the Digest SASL mechanism.

> Comments?
> Kurt

  - Keith
--
Keith Burdis                        
---

Date: Sat, 24 Mar 2001 19:27:16 +1100
To: "Kurt D. Zeilenga" <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: Draft charter of the SASL Working Group
Cc: Keith Burdis <[email-masked]>, <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Sender: [email-masked]

At 07:47 PM 3/23/01 -0800, Kurt D. Zeilenga wrote:
>Assuming you and your co-authors are willing to relinquish
>technical and editorial "control and ownership" to this work
>to the IETF, I will not object to the addition of ONE additional
>mechanism (currently published as either RFC or I-D) to the
>proposed charter.  I will, however, continue to note my general
>reservations regarding the broadening of the proposed charter.
>
>In reviewing these,  I believe the SRP mechanism would be
>most appropriate to add.  I offer the following text which
>could be added to proposed charter (just above the
>out-of-scope statement):
>
>   This group will deliver a Technical Specification
>   suitable for publication as Proposed Standard describing
>   a family of SASL mechanisms using the Secure Remote
>   Password [RFC2945] protocol.  This work will be based
>   upon draft-burdis-cat-srp-sasl-04.txt.
>
>While the SM2 proposal is intriguing, I believe it best to
>leave it off the charter for now.  I encourage the authors
>to continue on an individual basis and to seek review as
>appropriate.
>
>Comments?

the goal of the SM2 mechanism is to further the decoupling of the 
authorization phase from the security layer services of an SASL mechanism, 
thus reducing, and hopefully eliminating altogether, the need for SASL 
mechanism designers to address security parameters re-use within their 
mechanism.

mechanisms like SRP which offer strong confidentiality services are based 
on a secret key generated during the authentication phase.  the generation 
task within the authentication phase is a lengthy operation.  when wired 
underneath SM2, the SRP, and similar mechanisms have improved efficiency.

in conclusion: the sooner SM2 or similar mechanism, or even a SASL 
specifications that cater for session re-use, is adopted, the less need 
will be for designers of new mechanisms to address this issue on individual 
mechanisms basis.

cheers;
rsn

Date: Sat, 24 Mar 2001 18:59:22 +1100
To: John Gardiner Myers <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: Draft charter of the SASL Working Group
Cc: [email-masked]
Sender: [email-masked]

At 05:45 PM 3/23/01 -0800, John Gardiner Myers wrote:

>"Raif S. Naffah" wrote:
> > existing deployment?  SRP and SM2 mechanisms are currently used in
> > commercial products being developed!  does that constitute existing 
> deployment?
>
>Not quite.  The other mechanisms have significant production use.
>EXTERNAL, CRAM-MD5, and DIGEST-MD5 have demonstrated interoperability
>between multiple independent implementations, though there are issues
>with them that need to be dealt with before they can move to Draft
>Standard status.

noted.

>I think you underestimate the value of EXTERNAL.  It provides an
>important part in the use of TLS client certs in mail protocols and I
>know of at least three different products which implement it.

i am not denigrating the EXTERNAL mechanism;  i am only trying to compare 
its potential application areas to those of a mechanism like SRP.  a SASL 
SRP mechanism offers as much functionalities as TLS, and thus is a 
replacement candidate.

my statement was in regard to perceived usefulness.

>That said, I don't have any objection to addressing SRP and SM2 in the
>SASL WG.  It's just that the other documents (and the non-WG issue of
>HTTP/SASL) take precedence.

Date: Fri, 23 Mar 2001 19:47:59 -0800
To: Keith Burdis <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Draft charter of the SASL Working Group
Cc: <[email-masked]>
Sender: [email-masked]

Assuming you and your co-authors are willing to relinquish
technical and editorial "control and ownership" to this work
to the IETF, I will not object to the addition of ONE additional
mechanism (currently published as either RFC or I-D) to the
proposed charter.  I will, however, continue to note my general
reservations regarding the broadening of the proposed charter.

In reviewing these,  I believe the SRP mechanism would be
most appropriate to add.  I offer the following text which
could be added to proposed charter (just above the
out-of-scope statement):

  This group will deliver a Technical Specification
  suitable for publication as Proposed Standard describing
  a family of SASL mechanisms using the Secure Remote
  Password [RFC2945] protocol.  This work will be based
  upon draft-burdis-cat-srp-sasl-04.txt.

While the SM2 proposal is intriguing, I believe it best to
leave it off the charter for now.  I encourage the authors
to continue on an individual basis and to seek review as
appropriate.

Comments?

Kurt

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Draft charter of the SASL Working Group
Date: Fri, 23 Mar 2001 17:45:28 -0800
Organization: Netscape Communications Corporation
Lines: 73
NNTP-Posting-Host: 205.217.228.67
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msF9EBBFF2C6B30A662F2BE314
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Raif S. Naffah" wrote:
> existing deployment?  SRP and SM2 mechanisms are currently used in
> commercial products being developed!  does that constitute existing deployment?

Not quite.  The other mechanisms have significant production use. 
EXTERNAL, CRAM-MD5, and DIGEST-MD5 have demonstrated interoperability
between multiple independent implementations, though there are issues
with them that need to be dealt with before they can move to Draft
Standard status.

I think you underestimate the value of EXTERNAL.  It provides an
important part in the use of TLS client certs in mail protocols and I
know of at least three different products which implement it.

That said, I don't have any objection to addressing SRP and SM2 in the
SASL WG.  It's just that the other documents (and the non-WG issue of
HTTP/SASL) take precedence.
--------------msF9EBBFF2C6B30A662F2BE314
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

--------------msF9EBBFF2C6B30A662F2BE314--

Date: Fri, 23 Mar 2001 14:35:20 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Keith Burdis <[email-masked]>
CC: [email-masked]
Subject: Re: Draft charter of the SASL Working Group
Sender: [email-masked]

Keith Burdis wrote:

> Quoting Alexey Melnikov <[email-masked]>:
>
> > \"Raif S. Naffah\" wrote:
> >
> > > i still don\'t understand the principle, if there is one, behind the
> > > \"select\" mechanisms included in the proposed charter.  surely a mechanism
> > > based on SRP (Secure Remote Password) is more useful than EXTERNAL included
> > > among those \"select\" mechanisms.
> > >
> > > if this charter is approved as it is, where would designers of new
> > > mechanisms go to get their work discussed, adopted and promoted?
> > >
> > > cheers;
> > > rsn
> >
> > SASL working group is THE RIGHT place to discuss all SASL mechanism. But
> > we can\'t include ALL of them in the Charter, because in this case WG will
> > never conclude. After all milestones are achieved WG will review milestones
> > and will decide whether the charter should be updated or not.
>
> We are not talking about an infinite number of SASL mechanisms here. Since we
> are starting a new working group it makes sense to include the EXISTING set of
> proposed mechanisms that are likely to have common usage in its charter. Any
> mechanisms proposed after the charter has been set can wait until the charter
> is updated.

I really scared that SASL WG will become one of the WGs that takes forever to
finish.
Have a look at the list of SASL mechanisms at
http://www.sendmail.org/~ca/email/mel/SASL_info.html
and you will understand why.

Just to make there is no misunderstanding: I am not judging the quality and
usefulness of the mechanism you are proposing to add to the Charter.

Alexey

Date: Sat, 24 Mar 2001 05:48:10 +1100
To: "RL 'Bob' Morgan" <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: Draft charter of the SASL Working Group
Cc: <[email-masked]>, Keith Burdis <[email-masked]>, "Raif S. Naffah" <[email-masked]>
Sender: [email-masked]

At 04:12 AM 3/23/01 -0800, RL 'Bob' Morgan wrote:

>On Fri, 23 Mar 2001, Raif S. Naffah wrote:
>
> > if this charter is approved as it is, where would designers of new
> > mechanisms go to get their work discussed, adopted and promoted?
>
>It is important to understand that it is quite reasonable and quite common
>for documents to become Proposed Standard RFCs without being the product
>of a Working Group.  RFC 2222 itself is an example of this.  There are
>many protocols now that have extensibility provisions, and new extensions
>come along all the time.  Documents specifying them can be created as
>individual submissions and move forward without having a Working Group
>active in that protocol area at the time.  Typically this involves review
>of the document, to the satisfaction of the IESG, by folks who
>participated in the original protocol standardization.  Some veterans of
>the WG process would say that the individual-submission approach is better
>than going through a WG.  This is all covered in section 6.1 of RFC 2026.
>
>That said, I for one think it's reasonable to include WG charter items for
>SASL mechanisms that currently have internet-drafts in place (and whose
>authors want this to happen).  The perceived urgency of moving things to
>Draft Standard shouldn't preclude orderly progression of useful new work.

thank you.  as co-author, i nominate the following two mechanisms to be 
included in the list of the new WG:

1. Secure Remote Password SASL Mechanism, described in 
draft-burdis-cat-srp-sasl-04
2. SM2 -- A Session Management Capable SASL Mechanism, described in 
draft-naffah-cat-sasl-sm2-00

the above mechanisms have already been implemented in Java (the Cryptix 
library; http://sourceforge.net/projects/cryptix-sasl) according to another 
proposed draft (The Java SASL Application Program Interface: 
draft-weltman-java-sasl-04.txt).

cheers;
rsn

To: <[email-masked]>
Subject: Re: Draft charter of the SASL Working Group
Date: Fri, 23 Mar 2001 20:44:42 +0200
From: Keith Burdis <[email-masked]>
Sender: [email-masked]

Quoting \"Kurt D. Zeilenga\" <[email-masked]>:
> I note we are trying to balance here the concerns of the
> Applications folks who really need SASL and EXTERNAL, CRAM,
> DIGEST mechanisms progressed to Draft Standard as soon as
> possible and the concerns of the Security folks who would
> like refine existing mechanisms and introduce new mechanisms.
> The current proposal reflects a comprise between these
> factions in our community.
>
> To move this discussion forward, I suggest that instead of
> discussing generalities, we talk specifics.  That is, please
> state which mechanism you believe the IETF should produce
> and why.

SM2

>From one point of view you can see SM2 as a generalisation of the \"Subsequent 
Authentication\" described in section 2.2 of RFC 2831 (Digest SASL mechanism). 
Session reuse is beneficial when used with any SASL mechanism that provides a 
security layer or spends a relatively long time generating and exchanging 
session parameters. Currently this is applicable to the Digest, SRP and GSS-API 
mechanisms.

SRP

The SRP SASL mechanism is based on the Secure Remote Password protocol 
described in RFC2945. SRP is a password-based, zero-knowledge, authentication 
and key-exchange protocol developed by Thomas Wu. It has good performance, is 
not plaintext-equivalent and maintains perfect forward secrecy. It provides 
authentication (optionally mutual authentication) and the negotiation of a 
session key.

Personally I believe that it is important to have a strong password-based SASL 
mechanism. I don\'t think that the use of long-term public/private keypairs 
should be a requirement for having strong authentication, integrity protection 
and privacy protection. Currently the only password-based mechanism with a 
reasonable level of security is Digest.

Features shared with Digest authentication
 - protection against offline dictionary attacks and chosen plaintext attacks
 - password-based
 - mutual authentication
 - a security layer with protection against reply attacks and providing   
   integrity protection

Additional features compared to Digest authentication:
- forward secrecy
- protection against online dictionary attacks
- stored passwords are not plaintext-equivalent
- a security layer providing confidentiality protection
- security comparative to public-key based technology like TLS

Although GSS-API mechanisms may provide this functionality, they are 
comparitively more complex to implement (especially due to the use of ASN.1) or 
deploy (due to infrastructure requirements, LIPKEY excluded).

I don\'t think that this mechanism has yet undergone a sufficient level of 
community review for it to be taken to the IESG. Therefore I would like for 
this mechanism to be included in the working group\'s charter so that the SASL 
community can make a decision whether or not it has merits for progression 
along the standards track.

> Thanks, Kurt
 
  - Keith
--
Keith Burdis                        
---

Date: Sat, 24 Mar 2001 04:55:02 +1100
To: John Gardiner Myers <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: Draft charter of the SASL Working Group
Cc: [email-masked]
Sender: [email-masked]

At 01:45 PM 3/22/01 -0800, John Gardiner Myers wrote:

>"Raif S. Naffah" wrote:
> > i still don't understand the principle, if there is one, behind the
> > "select" mechanisms included in the proposed charter.
>
>The principle is that these are existing mechanisms, with existing
>deployment, which need to be advanced along the standards track.

existing deployment?  SRP and SM2 mechanisms are currently used in 
commercial products being developed!  does that constitute existing deployment?

cheers;
rsn

Date: Sat, 24 Mar 2001 04:52:43 +1100
To: Alexey Melnikov <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: Draft charter of the SASL Working Group
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked], "Raif S. Naffah" <[email-masked]>
Sender: [email-masked]

At 01:42 PM 3/22/01 -0700, Alexey Melnikov wrote:
>"Raif S. Naffah" wrote:
>
> > i still don't understand the principle, if there is one, behind the
> > "select" mechanisms included in the proposed charter.  surely a mechanism
> > based on SRP (Secure Remote Password) is more useful than EXTERNAL included
> > among those "select" mechanisms.
> >
> > if this charter is approved as it is, where would designers of new
> > mechanisms go to get their work discussed, adopted and promoted?
> >
> > cheers;
> > rsn
>
>SASL working group is THE RIGHT place to discuss all SASL mechanism. But we
>can't include ALL of them in the Charter, because in this case WG will never
>conclude. After all milestones are achieved WG will review milestones and will
>decide whether the charter should be updated or not.

why not then include all currently proposed mechanisms then? there are at 
least two other mechanisms: SRP and SM2 that, even if i say so myself, are 
more useful than EXTERNAL.  why aren't these included?

cheers;
rsn

Date: Fri, 23 Mar 2001 09:32:01 -0600
To: Keith Burdis <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Draft charter of the SASL Working Group
Cc: <[email-masked]>
Sender: [email-masked]

At 11:43 AM 3/23/01 +0200, Keith Burdis wrote:
>Any mechanisms proposed after the charter has been set can
>wait until the charter is updated.

Nothing has to wait!  Just because a work item is not a charter
item does not preclude the work from getting done... nor from
being discussed on the list and at WG sessions.  What a charter
does is give the WG a tool to focus the attention on critical
issues if this work were to become a distraction.

I note we are trying to balance here the concerns of the
Applications folks who really need SASL and EXTERNAL, CRAM,
DIGEST mechanisms progressed to Draft Standard as soon as
possible and the concerns of the Security folks who would
like refine existing mechanisms and introduce new mechanisms.
The current proposal reflects a comprise between these
factions in our community.

To move this discussion forward, I suggest that instead of
discussing generalities, we talk specifics.  That is, please
state which mechanism you believe the IETF should produce
and why.

Thanks, Kurt

Date: Fri, 23 Mar 2001 04:12:34 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
Reply-To: "RL 'Bob' Morgan" <[email-masked]>
To: "Raif S. Naffah" <[email-masked]>
cc: <[email-masked]>
Subject: Re: Draft charter of the SASL Working Group
Sender: [email-masked]

On Fri, 23 Mar 2001, Raif S. Naffah wrote:

> if this charter is approved as it is, where would designers of new
> mechanisms go to get their work discussed, adopted and promoted?

It is important to understand that it is quite reasonable and quite common
for documents to become Proposed Standard RFCs without being the product
of a Working Group.  RFC 2222 itself is an example of this.  There are
many protocols now that have extensibility provisions, and new extensions
come along all the time.  Documents specifying them can be created as
individual submissions and move forward without having a Working Group
active in that protocol area at the time.  Typically this involves review
of the document, to the satisfaction of the IESG, by folks who
participated in the original protocol standardization.  Some veterans of
the WG process would say that the individual-submission approach is better
than going through a WG.  This is all covered in section 6.1 of RFC 2026.

That said, I for one think it's reasonable to include WG charter items for
SASL mechanisms that currently have internet-drafts in place (and whose
authors want this to happen).  The perceived urgency of moving things to
Draft Standard shouldn't preclude orderly progression of useful new work.

 - RL "Bob"

To: <[email-masked]>
Subject: Re: Draft charter of the SASL Working Group
Date: Fri, 23 Mar 2001 11:43:24 +0200
From: Keith Burdis <[email-masked]>
Sender: [email-masked]

Quoting Alexey Melnikov <[email-masked]>:

> \"Raif S. Naffah\" wrote:
> 
> > i still don\'t understand the principle, if there is one, behind the
> > \"select\" mechanisms included in the proposed charter.  surely a mechanism
> > based on SRP (Secure Remote Password) is more useful than EXTERNAL included
> > among those \"select\" mechanisms.
> >
> > if this charter is approved as it is, where would designers of new
> > mechanisms go to get their work discussed, adopted and promoted?
> >
> > cheers;
> > rsn
> 
> SASL working group is THE RIGHT place to discuss all SASL mechanism. But
> we can\'t include ALL of them in the Charter, because in this case WG will
> never conclude. After all milestones are achieved WG will review milestones
> and will decide whether the charter should be updated or not.

We are not talking about an infinite number of SASL mechanisms here. Since we
are starting a new working group it makes sense to include the EXISTING set of
proposed mechanisms that are likely to have common usage in its charter. Any 
mechanisms proposed after the charter has been set can wait until the charter
is updated.

 - Keith
--
Keith Burdis                        
---

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Draft charter of the SASL Working Group
Date: Thu, 22 Mar 2001 13:45:45 -0800
Organization: Netscape Communications Corporation
Lines: 62
NNTP-Posting-Host: 205.217.228.225
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms13B4D2687088E9C4D3F55444
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Raif S. Naffah" wrote:
> i still don't understand the principle, if there is one, behind the
> "select" mechanisms included in the proposed charter.

The principle is that these are existing mechanisms, with existing
deployment, which need to be advanced along the standards track.
--------------ms13B4D2687088E9C4D3F55444
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

--------------ms13B4D2687088E9C4D3F55444--

Date: Thu, 22 Mar 2001 13:42:56 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Raif S. Naffah" <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: Draft charter of the SASL Working Group
Sender: [email-masked]

"Raif S. Naffah" wrote:

> i still don't understand the principle, if there is one, behind the
> "select" mechanisms included in the proposed charter.  surely a mechanism
> based on SRP (Secure Remote Password) is more useful than EXTERNAL included
> among those "select" mechanisms.
>
> if this charter is approved as it is, where would designers of new
> mechanisms go to get their work discussed, adopted and promoted?
>
> cheers;
> rsn

SASL working group is THE RIGHT place to discuss all SASL mechanism. But we
can't include ALL of them in the Charter, because in this case WG will never
conclude. After all milestones are achieved WG will review milestones and will
decide whether the charter should be updated or not.

Alexey

Date: Fri, 23 Mar 2001 07:12:17 +1100
To: "Kurt D. Zeilenga" <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: Draft charter of the SASL Working Group
Cc: [email-masked]
Sender: [email-masked]

i still don't understand the principle, if there is one, behind the 
"select" mechanisms included in the proposed charter.  surely a mechanism 
based on SRP (Secure Remote Password) is more useful than EXTERNAL included 
among those "select" mechanisms.

if this charter is approved as it is, where would designers of new 
mechanisms go to get their work discussed, adopted and promoted?

cheers;
rsn

At 01:36 PM 3/20/01 -0600, Kurt D. Zeilenga wrote:
>In the next few days, I would like to recommend a
>charter for the SASL WG to the ADs.  I propose the
>following charter for your review and comment.  In
>particular, I ask those who intend to serve as
>document editors to check the milestones.
>
>  -- Kurt
>
>Simple Authentication and Security Layer (SASL)
>
>Chair(s):
>   Kurt Zeilenga <[email-masked]>
>   Alexey Melnikov <[email-masked]>
>
>Security Area AD: TBD
>Applications Area AD: <[email-masked]>
>
>Mailing Lists:
>   General Discussions: <[email-masked]>
>   To Subscribe: <[email-masked]>
>   In Body: subscribe
>   Archive: http://www.imc.org/ietf-sasl/mail-archive/
>
>Description of Working Group
>
>   The Simple Authentication and Security Layer [RFC2222] provides
>   key security services to a number of application protocols
>   including BEEP, IMAP, LDAP, POP, and SMTP.  The purpose of
>   this working group is to shepherd SASL, including select SASL
>   mechanisms, though the Internet Standard process.
>
>   This group will deliver a revised SASL Technical Specification
>   suitable for consideration as a Draft Standard.  This work
>   will be based upon RFC 2222.
>
>   This group will deliver revised Technical Specifications
>   suitable considerations as Draft Standards for the following
>   SASL mechanisms: CRAM-MD5, DIGEST-MD5, and EXTERNAL.  This work
>   will be based upon RFC 2195, 2222, and 2831.
>
>   This group will deliver a revised Technical Specification
>   suitable for publication as Proposed Standard for the GSSAPI
>   family of SASL mechanisms.  This work will be based upon
>   RFC 2222 and draft-ietf-cat-sasl-gssapi-02.txt.
>
>   The following areas are not within the scope of work of this WG:
>     - new features,
>     - SASL Mechanisms not specifically mentioned above, and
>     - SASL "profiles".
>
>   However, the SASL WG is an acceptable forum for review of
>   SASL-related submissions produced by others as long as such
>   review does not impede progress on the WG objectives listed
>   above.
>
>Goals and Milestones
>   Apr 01  Submit revised SASL (+ EXTERNAL) I-D
>   May 01  Submit revised SASL CRAM-MD5 I-D
>   May 01  Submit revised SASL DIGEST-MD5 I-D
>   May 01  Submit revised SASL GSSAPI I-D
>   Jul 01  Submit Implementation Report as I-D
>   Aug 01  Submit revised SASL, CRAM-MD5, DIGEST-MD5 I-Ds with
>           Implementation Report to IESG for consideration as
>           a Draft Standard
>   Nov 01  Submit revised GSSAPI I-D to IESG for consideration
>           as a Proposed Standard
>   Dec 01  Revise charter or conclude
>
>

Date: Thu, 22 Mar 2001 01:10:58 +0200
From: Keith Burdis <[email-masked]>
To: [email-masked]
Subject: Re: Draft charter of the SASL Working Group
Mail-Followup-To: Keith Burdis <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue 2001-03-20 (13:36), Kurt D. Zeilenga wrote:
> In the next few days, I would like to recommend a
> charter for the SASL WG to the ADs.  I propose the
> following charter for your review and comment.  In
> particular, I ask those who intend to serve as
> document editors to check the milestones.
> 
>  -- Kurt
> 
> Simple Authentication and Security Layer (SASL)
> 
>[SNIP]
> 
>   This group will deliver a revised SASL Technical Specification
>   suitable for consideration as a Draft Standard.  This work
>   will be based upon RFC 2222.
> 
>   This group will deliver revised Technical Specifications
>   suitable considerations as Draft Standards for the following
>   SASL mechanisms: CRAM-MD5, DIGEST-MD5, and EXTERNAL.  This work
>   will be based upon RFC 2195, 2222, and 2831.
> 
>   This group will deliver a revised Technical Specification
>   suitable for publication as Proposed Standard for the GSSAPI
>   family of SASL mechanisms.  This work will be based upon
>   RFC 2222 and draft-ietf-cat-sasl-gssapi-02.txt.
> 
>   The following areas are not within the scope of work of this WG:
>     - new features,
>     - SASL Mechanisms not specifically mentioned above, and
>     - SASL "profiles".

I understand that it is important that the core SASL specification be
advanced to Draft Standard as soon as possible. However, since all SASL
mechanisms besides EXTERNAL are being removed from the core specification,
what is the motivation for not including additional mechanisms other than
those listed in the Working Group's charter? Working on these mechanisms
will not impede the advancement of the core standard or any of the listed
mechanisms.

  - Keith
--
Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa
IRC: Panthras					JAPH 	QEFH
---

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Draft charter of the SASL Working Group
Date: Wed, 21 Mar 2001 10:38:38 -0800
Organization: Netscape Communications Corporation
Lines: 57
NNTP-Posting-Host: 205.217.228.196
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msB8916999BDC9F5445C7578C8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Klensin referred me to a potential CRAM-MD5 document editor.  I'm
following up on this.
--------------msB8916999BDC9F5445C7578C8
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

--------------msB8916999BDC9F5445C7578C8--

Date: Wed, 21 Mar 2001 00:09:46 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Lyndon Nerenberg <[email-masked]>
CC: John Gardiner Myers <[email-masked]>, [email-masked]
Subject: Re: Draft charter of the SASL Working Group
Sender: [email-masked]

Lyndon Nerenberg wrote:

> > Do we have a document editor for CRAM-MD5?
>
> I'll volunteer for this if Chris doesn't want it.

Chris didn't write it. You should ask John Klensin.

Alexey

From: Lyndon Nerenberg <[email-masked]>
Organization: ACI / Messagingdirect
To: John Gardiner Myers <[email-masked]>
cc: [email-masked]
Subject: Re: Draft charter of the SASL Working Group 
Date: Tue, 20 Mar 2001 23:45:49 -0700
Sender: [email-masked]

> Do we have a document editor for CRAM-MD5?

I'll volunteer for this if Chris doesn't want it.

--lyndon

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: draft SASL base spec
Date: Tue, 20 Mar 2001 19:36:20 -0800
Organization: Netscape Communications Corporation
Lines: 726
NNTP-Posting-Host: 205.217.228.111
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msC55EE4501A074326084C5735
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Network Working Group                                           J. Myers
Internet Draft                                                March 2001
Document: draft-myers-saslrev-XX.txt

            Simple Authentication and Security Layer (SASL)

Status of this Memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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''.

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
   munnari.oz.au.

   A revised version of this draft document will be submitted to the RFC
   editor as a Draft Standard for the Internet Community.  Discussion
   and suggestions for improvement are requested.  Distribution of this
   draft is unlimited.

J. Myers                                                        [Page i]

Internet DRAFT                    SASL                    March 19, 2001

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
   mechanisms for use by the command, and defines the protocol used for
   carrying a negotiated security layer over the connection.

2.    Organization of this document

2.1.  How to read this document

   This document is written to serve two different audiences, protocol
   designers using this specification to support authentication in their
   protocol, and implementors of clients or servers for those protocols
   using this specification.

   The sections "Overview", "Authentication Mechanisms", "Protocol
   Profile Requirements", "Specific Issues", and "Security
   Considerations" cover issues that protocol designers need to
   understand and address in profiling this specification for use in a
   specific protocol.

   Implementors of a protocol using this specification need the
   protocol-specific profiling information in addition to the
   information in this document.

2.2.  Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in "Key words for
   use in RFCs to Indicate Requirement Levels" [KEYWORDS].

2.3.  Examples

   Examples in this document are for the IMAP profile [IMAP4] of this
   specification.  The base64 encoding of challenges and responses, as
   well as the "+ " preceding the responses are part of the IMAP4
   profile, not part of the SASL specification itself.

J. Myers                                                        [Page 2]

Internet DRAFT                    SASL                    March 19, 2001

3.    Overview

   The Simple Authentication and Security Layer (SASL) is a method for
   adding authentication support to connection-based protocols.

   The SASL specification has three layers, as indicated in the diagram
   below.  At the top, a protocol definition using SASL specifies a
   profile, including a command for identifying and authenticating a
   user to a server and for optionally negotiating a security layer for
   subsequent protocol interactions.  At the bottom, a SASL mechanism
   definition specifies an authentication mechanism.  The SASL
   framework, specified by this document, constrains the behavior of
   protocol profiles and mechanisms, separating protocol from mechanism
   and defining how they interact.

                SMTP Protocol     LDAP Protocol          Etc
                   Profile           Profile            . . .
                          \-----        |       -----/
                                \       |      /
                                 SASL framework
                                /       |      \
                          /-----        |       -----\
                   EXTERNAL         DIGEST-MD5           Etc
                SASL mechanism    SASL mechanism        . . .

   This separation between the definition of protocols and the
   definition of authentication mechanisms is crucial.  It permits an
   authentication mechanism to be defined once, making it usable by any
   SASL protocol profiles.  In many implementations, the same SASL
   mechanism code is used for multiple protocols.

4.    Authentication mechanisms

   SASL mechanisms are named by strings, from 1 to 20 characters in
   length, consisting of upper-case letters, digits, hyphens, and/or
   underscores.  SASL mechanism names must be registered with the IANA.
   Procedures for registering new SASL mechanisms are given in the
   section "Registration procedures"

4.1.  Authentication protocol exchange

   A SASL mechanism is responsible for conducting an authentication
   protocol exchange.  This consists of a series of server challenges
   and client responses, the contents of which are specific to and
   defined by the mechanism.  To the protocol, the challenges and
   responses are opaque binary tokens of arbitrary length.  The
   protocol's profile then specifies how these binary tokens are then
   encoded for transfer over the connection.

J. Myers                                                        [Page 3]

Internet DRAFT                    SASL                    March 19, 2001

   After receiving an authentication command or any client response, a
   server mechanism may issue a challenge, indicate failure, or indicate
   completion.  The protocol's profile specifies how each of these is
   then represented over the connection.

   After receiving a challenge, a client mechanism may issue a response
   or abort the exchange.  The protocol's profile specifies how each of
   these is then represented over the connection.

   During the authentication protocol exchange, the mechanism performs
   authentication, transmits an authorization identity (frequently known
   as a userid) from the client to server, and negotiates the use of a
   mechanism-specific security layer.  If the use of a security layer is
   agreed upon, then the mechanism must also define or negotiate the
   maximum security layer buffer size that each side is able to receive.

4.2.  Proxy authentication

   The authorization identity transmitted during the authentication
   protocol exchange may be different than the identity derived from the
   client's authentication credentials.  When the two are different,
   this is typically referred to as "proxy authentication".  The
   identity derived from the client's authentication credentials is
   known as the "authentication identity".

   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.  With any mechanism,
   transmitting an authorization identity of the empty string directs
   the server to derive an authorization identity from the client's
   authentication identity.

4.3.  Security layers

   If use of a security layer is negotiated by the authentication
   protocol exchange, the security layer is applied to all subsequent
   data sent over the connection.  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.

   Once the security layer is in effect, the protocol stream is
   processed by the security layer into buffers of security encoded
   data.  Each buffer of security encoded data is transferred over the
   connection as a stream of octets prepended with a four octet field in
   network byte order that represents the length of the following
   buffer.  The length of the security encoded data buffer must be no
   larger than the maximum size that was either defined in the mechanism

J. Myers                                                        [Page 4]

Internet DRAFT                    SASL                    March 19, 2001

   specification or negotiated by the other side during the
   authentication protocol exchange.

5.    Protocol profile requirements

   In order to use this specification, a protocol definition must supply
   the following information:

   1. A service name, to be selected from the IANA registry of "service"
      elements for the GSSAPI host-based service name form. [GSSAPI]
      This service name is made available to the authentication
      mechanism.

   2. A definition of the command to initiate the authentication
      protocol exchange.  This command must have as a parameter the name
      of the mechanism being selected by the client.

      The command SHOULD have an optional parameter giving an initial
      response.  This optional parameter allows the client to avoid a
      round trip when using a mechanism which is defined to have the
      client send data first.  When this initial response is sent by the
      client and the selected mechanism is defined to have the server
      start with an initial challenge, the command fails.  See section
      6.1 of this document for further information.

   3. A definition of the method by which the authentication protocol
      exchange is carried out, including how the challenges and
      responses are encoded, how the server indicates completion or
      failure of the exchange, how the client aborts an exchange, and
      how the exchange method interacts with any line length limits in
      the protocol.

   4. Identification of the octet where any negotiated security layer
      starts to take effect, in both directions.

   5. A specification of how the authorization identity passed from the
      client to the server is to be interpreted.

6.    Specific issues

6.1.  Client sends data first

   Some mechanisms specify that the first data sent in the
   authentication protocol exchange is from the client to the server.

   If a protocol's profile permits the command which initiates an
   authentication protocol exchange to contain an initial client

J. Myers                                                        [Page 5]

Internet DRAFT                    SASL                    March 19, 2001

   response, this parameter SHOULD be used with such mechanisms.

   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.)

6.2.  Server returns success with additional data

   Some mechanisms may specify that server challenge data be sent to the
   client along with an indication of successful completion of the
   exchange.  This data would, for example, authenticate the server to
   the client.

   If a protocol's profile does not permit this server challenge to be
   returned with a success indication, then the server issues the server
   challenge without an indication of successful completion.  The client
   then responds with no data.  After receiving this empty response, the
   server then indicates successful completion.

6.3.  Multiple authentications

   Unless otherwise stated by the protocol's profile, only one
   successful SASL negotiation may occur in a protocol session.  In this
   case, once an authentication protocol exchange has successfully
   completed, further attempts to initiate an authentication protocol
   exchange fail.

   In the case that 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 no security layer, the
   original security layer remains 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.

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.

   There is no naming convention for SASL mechanisms; any name that
   conforms to the syntax of a SASL mechanism name can be registered.

J. Myers                                                        [Page 6]

Internet DRAFT                    SASL                    March 19, 2001

   While the registration procedures do not require it, authors of SASL
   mechanisms are encouraged to seek community review and comment
   whenever that is feasible.  Authors may seek community review by
   posting a specification of their proposed mechanism as an internet-
   draft.  SASL mechanisms intended for widespread use should be
   standardized through the normal IETF process, when appropriate.

7.1.  Comments on SASL mechanism registrations

   Comments on registered SASL mechanisms should first be sent to the
   "owner" of the mechanism.  Submitters of comments may, after a
   reasonable attempt to contact the owner, request IANA to attach their
   comment to the SASL mechanism registration itself.  If IANA approves
   of this the comment will be made accessible in conjunction with the
   SASL mechanism registration itself.

7.2.  Location of registered SASL mechanism list

   SASL mechanism registrations will be posted in the anonymous FTP
   directory
   "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-mechanisms/" and
   all registered SASL mechanisms will be listed in the periodically
   issued "Assigned Numbers" RFC [currently RFC-1700].  The SASL
   mechanism description and other supporting material may also be
   published as an Informational RFC by sending it to
   "[email-masked]" (please follow the instructions to RFC authors
   [RFC-1543]).

7.3.  Change control

   Once a SASL mechanism registration has been published by IANA, the
   author may request a change to its definition.  The change request
   follows the same procedure as the registration request.

   The owner of a SASL mechanism may pass responsibility for the SASL
   mechanism to another person or agency by informing IANA; this can be
   done without discussion or review.

   The IESG may reassign responsibility for a SASL mechanism. The most
   common case of this will be to enable changes to be made to
   mechanisms where the author of the registration has died, moved out
   of contact or is otherwise unable to make changes that are important
   to the community.

   SASL mechanism registrations may not be deleted; mechanisms which are
   no longer believed appropriate for use can be declared OBSOLETE by a
   change to their "intended use" field; such SASL mechanisms will be
   clearly marked in the lists published by IANA.

J. Myers                                                        [Page 7]

Internet DRAFT                    SASL                    March 19, 2001

   The IESG is considered to be the owner of all SASL mechanisms which
   are on the IETF standards track.

7.4.  Registration template

     To: [email-masked]
     Subject: Registration of SASL mechanism X

     SASL mechanism name:

     Security considerations:

     Published specification (optional, recommended):

     Person & email address to contact for further information:

     Intended usage:

     (One of COMMON, LIMITED USE or OBSOLETE)

     Owner/Change controller:

     (Any other information that the author deems interesting may be
     added below this line.)

8.    The external mechanism

   The mechanism name associated with external authentication is
   "EXTERNAL".

   The client sends an initial response with the authorization identity.

   The server uses information, external to SASL, to determine whether
   the client is authorized to authenticate as the authorization
   identity.  If the client is so authorized, the server indicates
   successful completion of the authentication exchange; otherwise the
   server indicates failure.

   The system providing this external information may be, for example,
   IPsec or TLS.

   If the client sends the empty string as the authorization identity
   (thus requesting the authorization identity be derived from the
   client's authentication credentials), the authorization identity is
   to be derived from authentication credentials which exist in the
   system which is providing the external authentication.

J. Myers                                                        [Page 8]

Internet DRAFT                    SASL                    March 19, 2001

9.    References

   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
   RFC 1730, University of Washington, December 1994.

   [GSSAPI] Linn, J., "Generic Security Service Application Program
   Interface, Version 2", RFC 2078, January 1997

   [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997

   [RFC-1543] Postel, J., "Instructions to RFC Authors", RFC 1543,
   October 1993

   [SASL-GSSAPI] Myers, J., "SASL GSSAPI mechanisms", draft-ietf-cat-
   sasl-gssapi-XX.txt, September 2000

   [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC
   2444, October 1998

10.   Security considerations

   Security issues are discussed throughout this memo.

   The mechanisms that support integrity protection are designed such
   that the negotiation of the security layer and authorization identity
   is integrity protected.  When the client selects a security layer
   with at least integrity protection, this protects against an active
   attacker hijacking the connection and modifying the authentication
   exchange to negotiate a plaintext connection.

   When a server or client supports multiple authentication mechanisms,
   each of which has a different security strength, it is possible for
   an active attacker to cause a party to use the least secure mechanism
   supported.  To protect against this sort of attack, a client or
   server which supports mechanisms of different strengths should have a
   configurable minimum strength that it will use.  It is not sufficient
   for this minimum strength check to only be on the server, since an
   active attacker can change which mechanisms the client sees as being
   supported, causing the client to send authentication credentials for
   its weakest supported mechanism.

   The client's selection of a SASL mechanism is done in the clear and
   may be modified by an active attacker.  It is important for any new
   SASL mechanisms to be designed such that an active attacker cannot
   obtain an authentication with weaker security properties by modifying
   the SASL mechanism name and/or the challenges and responses.

J. Myers                                                        [Page 9]

Internet DRAFT                    SASL                    March 19, 2001

   Any protocol interactions prior to authentication are performed in
   the clear and may be modified by an active attacker.  In the case
   where a client selects integrity protection, it is important that any
   security-sensitive protocol negotiations be performed after
   authentication is complete.  Protocols should be designed such that
   negotiations performed prior to authentication should be either
   ignored or revalidated once authentication is complete.

11.   Author's address

   John G. Myers
   Netscape Communications
   501 E. Middlefield Road
   Mail Stop SCA 15:201
   Mountain View, CA 94043-4042

   Email: [email-masked]

Appendix A. Relation of SASL to transport security

   Questions have been raised about the relationship between SASL and
   various services (such as IPsec and TLS) which provide a secured
   connection.

   Two of the key features of SASL are:

   1. The separation of the authorization identity from the identity in
      the client's credentials.  This 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.

   2. Upon successful completion of an authentication exchange, the
      server knows the authorization identity the client wishes to use.
      This allows servers to move to a "user is authenticated" state in
      the protocol.

   These features are extremely important to some application protocols,
   yet Transport Security services do not always provide them.  To
   define SASL mechanisms based on these services would be a very messy
   task, as the framing of these services would be redundant with the
   framing of SASL and some method of providing these important SASL
   features would have to be devised.

   Sometimes it is desired to enable within an existing connection the
   use of a security service which does not fit the SASL model.  (TLS is
   an example of such a service.)  This can be done by adding a command,
   for example "STARTTLS", to the protocol.  Such a command is outside

J. Myers                                                       [Page 10]

Internet DRAFT                    SASL                    March 19, 2001

   the scope of SASL, and should be different from the command which
   starts a SASL authentication protocol exchange.

   In certain situations, it is reasonable to use SASL underneath one of
   these Transport Security services.  The transport service would
   secure the connection, either service would authenticate the client,
   and SASL would negotiate the authorization identity.  The SASL
   negotiation would be what moves the protocol from "unauthenticated"
   to "authenticated" state.  The "EXTERNAL" SASL mechanism is
   explicitly intended to handle the case where the transport service
   secures the connection and authenticates the client and SASL
   negotiates the authorization identity.

   When using SASL underneath a sufficiently strong Transport Security
   service, a SASL security layer would most likely be redundant.  The
   client and server would thus probably want to negotiate off the use
   of a SASL security layer.

Appendix B. IANA considerations

   The IANA is directed to modify the SASL mechanisms registry as
   follows:

   1. Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
      registrations to OBSOLETE.

   2. Change the "Published specification" of the EXTERNAL mechanism to
      this document.

Appendix C. Changes since RFC 2222

   The GSSAPI mechanism was removed.  It is now specified in a separate
   document [SASL-GSSAPI].

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

   The "SKEY" mechanism described in RFC 2222 is obsolete and has been
   removed.  It has been replaced by the OTP mechanism [SASL-OTP].

   The overview has been substantially reorganized and clarified.

J. Myers                                                       [Page 11]

Internet DRAFT                    SASL                    March 19, 2001

                           Table of Contents

Status of this Memo ...............................................    i
1.    Abstract ....................................................    2
2.    Organization of this document ...............................    2
2.1.  How to read this document ...................................    2
2.2.  Conventions used in this document ...........................    2
2.3.  Examples ....................................................    2
3.    Overview ....................................................    3
4.    Authentication mechanisms ...................................    3
4.1.  Authentication protocol exchange ............................    3
4.2.  Proxy authentication ........................................    4
4.3.  Security layers .............................................    4
5.    Protocol profile requirements ...............................    5
6.    Specific issues .............................................    5
6.1.  Client sends data first .....................................    5
6.2.  Server returns success with additional data .................    6
6.3.  Multiple authentications ....................................    6
7.    Registration procedures .....................................    6
7.1.  Comments on SASL mechanism registrations ....................    7
7.2.  Location of registered SASL mechanism list ..................    7
7.3.  Change control ..............................................    7
7.4.  Registration template .......................................    8
8.    The external mechanism ......................................    8
9.    References ..................................................    9
10.   Security considerations .....................................    9
11.   Author's address ............................................   10
Appendix A. Relation of SASL to transport security ................   10
Appendix B. IANA considerations ...................................   11
Appendix C. Changes since RFC 2222 ................................   11

J. Myers                                                       [Page ii]
--------------msC55EE4501A074326084C5735
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

--------------msC55EE4501A074326084C5735--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Draft charter of the SASL Working Group
Date: Tue, 20 Mar 2001 19:33:29 -0800
Organization: Netscape Communications Corporation
Lines: 83
NNTP-Posting-Host: 205.217.228.111
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msFA2C2F92C1E800270C5B5C2F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> In
> particular, I ask those who intend to serve as
> document editors to check the milestones.

I believe the GSSAPI I-D to be done, it just needs to go through IETF
Last Call.  I think it would be best to do that at the same time as the
base spec.

I have written a first draft of the revised base specification and will
post it as my next message.  I'll submit it as an I-D as soon as the
IETF is over.

I've recently heard reports of our passing the two independent
implementations requirement for security layers.  I've asked Lawrence
Greenfield to start compiling an implementation report.  I don't believe
the implementation report needs to be an I-D.

Assuming there is no great controversy with my revised base
specification, we could get both that and GSSAPI submitted for IETF Last
Call by the time the working group could get formed.  In that case, the
question becomes whether we would want to hold up those two documents
until we can finish CRAM-MD5 and DIGEST-MD5.  I know there are
substantive problems with DIGEST-MD5, namely with the 3DES security
layer.

Do we have a document editor for CRAM-MD5?
--------------msFA2C2F92C1E800270C5B5C2F
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

--------------msFA2C2F92C1E800270C5B5C2F--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: Thoughts on SASL
Date: Tue, 20 Mar 2001 19:18:25 -0800
Organization: Netscape Communications Corporation
Lines: 71
NNTP-Posting-Host: 205.217.228.111
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msB243928AB341F0B57AAFD01E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Keith Burdis wrote:
> I believe that it would make sense to remove section 7 from RFC 2222
> (or rather its successor) and put it into one or more separate
> documents. The core of SASL should be distinct from individual SASL
> mechanisms and should evolve differently. Changes in mechanisms (say
> from S/KEY to OTP) should not require a revision of the core standard.
> This will also make it easier to progress RFC 2222 to Draft Standard.

My draft revision of RFC 2222 removes all mechanisms except EXTERNAL. 
GSSAPI goes to a separate document to recycle at Proposed and the other
two are marked OBSOLETE.

EXTERNAL belongs in the core specification as it is necessary for
integrating SASL and TLS.  Besides, it is too trivial to justify a
separate document.
--------------msB243928AB341F0B57AAFD01E
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

--------------msB243928AB341F0B57AAFD01E--

Date: Tue, 20 Mar 2001 13:36:39 -0600
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Draft charter of the SASL Working Group
Sender: [email-masked]

In the next few days, I would like to recommend a
charter for the SASL WG to the ADs.  I propose the
following charter for your review and comment.  In
particular, I ask those who intend to serve as
document editors to check the milestones.

 -- Kurt

Simple Authentication and Security Layer (SASL)

Chair(s):
  Kurt Zeilenga <[email-masked]>
  Alexey Melnikov <[email-masked]>

Security Area AD: TBD
Applications Area AD: <[email-masked]>

Mailing Lists:
  General Discussions: <[email-masked]>
  To Subscribe: <[email-masked]>
  In Body: subscribe
  Archive: http://www.imc.org/ietf-sasl/mail-archive/

Description of Working Group

  The Simple Authentication and Security Layer [RFC2222] provides
  key security services to a number of application protocols
  including BEEP, IMAP, LDAP, POP, and SMTP.  The purpose of
  this working group is to shepherd SASL, including select SASL
  mechanisms, though the Internet Standard process.

  This group will deliver a revised SASL Technical Specification
  suitable for consideration as a Draft Standard.  This work
  will be based upon RFC 2222.

  This group will deliver revised Technical Specifications
  suitable considerations as Draft Standards for the following
  SASL mechanisms: CRAM-MD5, DIGEST-MD5, and EXTERNAL.  This work
  will be based upon RFC 2195, 2222, and 2831.

  This group will deliver a revised Technical Specification
  suitable for publication as Proposed Standard for the GSSAPI
  family of SASL mechanisms.  This work will be based upon
  RFC 2222 and draft-ietf-cat-sasl-gssapi-02.txt.

  The following areas are not within the scope of work of this WG:
    - new features,
    - SASL Mechanisms not specifically mentioned above, and
    - SASL "profiles".

  However, the SASL WG is an acceptable forum for review of
  SASL-related submissions produced by others as long as such
  review does not impede progress on the WG objectives listed
  above.

Goals and Milestones
  Apr 01  Submit revised SASL (+ EXTERNAL) I-D
  May 01  Submit revised SASL CRAM-MD5 I-D
  May 01  Submit revised SASL DIGEST-MD5 I-D
  May 01  Submit revised SASL GSSAPI I-D
  Jul 01  Submit Implementation Report as I-D
  Aug 01  Submit revised SASL, CRAM-MD5, DIGEST-MD5 I-Ds with
          Implementation Report to IESG for consideration as
          a Draft Standard
  Nov 01  Submit revised GSSAPI I-D to IESG for consideration
          as a Proposed Standard
  Dec 01  Revise charter or conclude

Date: Tue, 20 Mar 2001 07:14:03 +1100
To: [email-masked]
From: "Raif S. Naffah" <[email-masked]>
Subject: SASL integrated with an open source HTTP server (Jetty)
Sender: [email-masked]

hi there,

i am pleased to announce the availability of a first release of the open 
source HTTP server and Java Servlet Engine Jetty 
(http://sourceforge.net/projects/jetty/) capable of handling SASL 
authentication (Jetty-3.1RC1 + Jetty3Extra downloads) through the use of 
the SM2-SRP mechanisms.

this release of Jetty uses the latest Cryptrix library as advertised in 
earlier announcements on this list 
(http://sourceforge.net/projects/cryptix-sasl).

cheers;
rsn

Date: Mon, 19 Mar 2001 09:40:54 -0600
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Draft description of the SASL Working Group
Sender: [email-masked]

The ADs have given their consent to pursue the formation
of a SASL WG.  I propose the following as the description
to be used in the proposed charter.

Description of Working Group

  The Simple Authentication and Security Layer [RFC2222] provides
  key security services to a number of application protocols
  including BEEP, IMAP, LDAP, POP, and SMTP.  The purpose of
  this working group is to shepherd SASL, including select SASL
  mechanisms, though the Internet Standard process.

  This group will deliver a revised SASL Technical Specification
  suitable for consideration as a Draft Standard.  This work
  will be based upon RFC 2222.

  This group will deliver revised Technical Specifications
  suitable considerations as Draft Standards for the following
  SASL mechanisms: CRAM-MD5, DIGEST-MD5, and EXTERNAL.  This work
  will be based upon RFC 2195, 2222, and 2831.

  This group will deliver a revised Technical Specification
  suitable for publication as Proposed Standard for the GSSAPI
  family of SASL mechanisms.  This work will be based upon
  RFC 2222 and draft-ietf-cat-sasl-gssapi-02.txt.

  The following areas are not within the scope of work of this WG:
    - new features,
    - SASL Mechanisms not specifically mentioned above, and
    - SASL "profiles".

  However, the SASL WG is an acceptable forum for review of
  SASL-related submissions produced by others as long as such
  review does not impede progress on the WG objectives listed
  above. 

To: <[email-masked]>
Subject: Thoughts on SASL
Date: Sun, 18 Mar 2001 13:20:33 +0200
From: Keith Burdis <[email-masked]>
Sender: [email-masked]

Hi everyone

I\'d like to share some of my thoughts on SASL and the working group,
for what they\'re worth.

---

I believe that it would make sense to remove section 7 from RFC 2222 
(or rather its successor) and put it into one or more separate 
documents. The core of SASL should be distinct from individual SASL 
mechanisms and should evolve differently. Changes in mechanisms (say 
from S/KEY to OTP) should not require a revision of the core standard. 
This will also make it easier to progress RFC 2222 to Draft Standard.

On this list suggestions have been individually made to split out GSS-API, 
KERBEROS 4 and CRAM-MD5. Why not the rest too?

---

Too often I have seen it recommended that SASL mechanisms be used with
TLS providing the underlying security because the SASL mechanisms are
not able to provide sufficient security themselves.
In future, SASL should be a possible alternative to TLS. In order for
this to happen, mechanisms with strong security and a security layer
that provides protection against known attacks must be available for
use with SASL. To compete, other features that TLS has, such as session
reuse, also become important.

---

I think that the work done by the CAT working group on low infrastructure
GSS-API mechanisms (such as LIPKEY) fits nicely with SASL, so I think it
would be important to work on a means of using these mechanisms with SASL.

---

Is John Myers still listening on this list and involved with SASL?
Being the original architect of SASL, I think that it is important
that we get his input on this topic.

  - Keith
--
Keith Burdis                        
---

Date: Sat, 17 Mar 2001 22:59:58 -0600
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: WG formation: AD advice and consent 
Cc: [email-masked]
Sender: [email-masked]

At 04:49 PM 3/17/01 -0800, [email-masked] wrote:
>What's your thoughts on this Kurt'n'Chris?

I suggest we focus on critical work for now.

I believe there is consensus that the primary objective
should be to take SASL and a few select mechanisms to Draft
Standard (without any recycling at Proposed).  There is some
debate as to which mechanisms are suitable, but I think we
will converge upon the specific list of select mechanisms
soon.

I note that while GSSAPI cannot be immediately progressed
to Draft Standard, this should likely be a charter item as
well.

Beyond this, I would prefer not to take on additional work
items until the primary objective (SASL to DS) is completed.
This, of course, would not preclude individual work nor the
WG from review other works.

Kurt

Date: Sun, 18 Mar 2001 13:25:19 +1100
To: "Kurt D. Zeilenga" <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: WG formation: AD advice and consent
Cc: [email-masked]
Sender: [email-masked]

At 08:50 AM 3/17/01 -0800, Kurt D. Zeilenga wrote:
>I've taken the first formal step in the formation of a
>SASL WG.  I have sent a request for advice and consent
>to the appropriate ADs (security and applications).
>
>As Chris noted, besides hammering out a description,
>we also need chair(s). I am willing to serve as chair
>or co-chair.  I would prefer the latter.  Are there
>others who are willing and able to take on a role as
>a chair or co-chair?...

before all that, shouldn't we talk more about the mission
statement of this WG?

cheers;
rsn

Subject: Re: WG formation: AD advice and consent 
To: [email-masked]
Reply-to: [email-masked]
From: [email-masked]
Date: Sat, 17 Mar 2001 16:49:50 -0800
Sender: [email-masked]

I think forming a SASL working group is the right way to get it progressed to 
Draft Standard.

It seems to me from this thread, tho, that there's still an open question as 
to whether we're forming one working group to (a) take SASL and selected SASL 
mechanisms to Draft Standard maturity level, (b) progress other existing SASL 
mechanisms to Draft Standard (or recycle at Proposed, as needed), and (C) 
develop new SASL mechanisms. Or whether we're forming one working group now to 
exclusively do (a), and then figure out later (or maybe in parallel if someone 
has the cycles) to do (b) and/or (c).

What's your thoughts on this Kurt'n'Chris?

thanks,

JeffH

Date: Sat, 17 Mar 2001 08:50:45 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: WG formation: AD advice and consent
Sender: [email-masked]

I've taken the first formal step in the formation of a
SASL WG.  I have sent a request for advice and consent
to the appropriate ADs (security and applications).

As Chris noted, besides hammering out a description,
we also need chair(s). I am willing to serve as chair
or co-chair.  I would prefer the latter.  Are there
others who are willing and able to take on a role as
a chair or co-chair?

For a mailing list, I assume we can just hijack this
list (after obtaining permission from the list owners,
of course).

We also need milestones.  I would suggest that those
willing to serve as document editors to key documents
should offer when you think you can a) submit an
initial I-D and b) when you believe the WG will be
able to progress the I-D to the IESG (allowing enough
time for a WG last call).  I suggest ambitious (but
realistically achievable) milestones so that we push
ourselves to getting the work done in a timely manner.

Based upon list discussions and input from the ADs,
I propose to draft a proposed charter for bashing as
soon as possible.  [it may be a few days before the
ADs have time to advise].

Regards, Kurt

Date: Sat, 17 Mar 2001 01:09:34 -0800
From: Chris Newman <[email-masked]>
Subject: Re: a dedicated SASL WG
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

--On Thursday, March 15, 2001 21:05 -0800 "Kurt D. Zeilenga" 
<[email-masked]> wrote:
>> draft-ietf-cat-sasl-gssapi-02.txt work needs to be done in parallel to
>> advancing 2222 since 2222 includes GSSAPI mechanism.
>
> GSSAPI is PS and that might be gate.  I was thinking of
> splitting it out from the "core" SASL specification.

Yes.  I propose charter include task to recycle separate sasl-gssapi spec 
at proposed and drop gssapi text from SASL base spec.  This should be done 
at the same time as moving base spec to draft, since we want to continue 
forward with gssapi in the future.

		- Chris

Date: Fri, 16 Mar 2001 14:15:11 -0500
From: Lawrence Greenfield <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: SASL <[email-masked]>
Subject: Re: a dedicated SASL WG
Sender: [email-masked]

   Date: Thu, 15 Mar 2001 20:15:17 -0800
   From: Chris Newman <[email-masked]>

   [...]
   I suggest we try to get it chartered as joint security and apps area WG 
   (one AD from each area as area advisor).

I think this is a really good idea.

   [...]
   I disagree.  CRAM-MD5 has wide implementation in the email community. 
   There's no reason not to advance it to full standard with an appropriate 
   caveat about the relative security, interoperability and complexity issues 
   with respect to DIGEST-MD5.  But the WG shouldn't spend time on CRAM-MD5, 
   since DIGEST-MD5 is the better choice for mandatory-to-implement mechanism.

It would be nice to get a document that actually refers to CRAM-MD5
as it's used in SASL, but this doesn't have to be done in a working
group.

   Leif Johansson wrote:
   > I hate to say this (imagine me taking cover at this point :-) but
   > I would actually like (imho!) to see the sasl c api get done in the wg.

   I volunteer to be document editor or co-editor for C API.  The caveat is 
   that I believe APIs hold a different place in the world from protocols. 
   Protocols provide interoperability, while APIs provide depolyment.  Having 
   a publically documented API with an open-source implementation is 
   sufficiently beneficial to deployment of a protocol that I think it is well 
   worth WG effort.  But there's nothing wrong with multiple APIs, so I'd 
   prefer to see the SASL C API as an informational RFC.

Yes, having an informational document would be nice.  We've already
seen some convergence in the SASL APIs available (we'd see even more
if CMU had more programmer resources) and it would be nice to
encourage others, too.

Larry

Date: Thu, 15 Mar 2001 21:05:34 -0800
To: Chris Newman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: a dedicated SASL WG
Cc: [email-masked]
Sender: [email-masked]

Chris,

>I suggest we try to get it chartered as joint security and apps area WG (one AD from each area as area advisor).

That a good suggestion.  We should chat with the ADs at IETF#50.

>I'd be inclined to drop PLAIN from that list.  I don't think it needs formal WG attention, and the normative reference to TLS is likely the gating factor on advancement.

A very good point.

>>Though this WG could also take on engineering of new
>>mechanisms (including a replacement for GSSAPI), I believe
>>this should be viewed as secondary to the above objective.
>
>draft-ietf-cat-sasl-gssapi-02.txt work needs to be done in parallel to advancing 2222 since 2222 includes GSSAPI mechanism.

GSSAPI is PS and that might be gate.  I was thinking of
splitting it out from the "core" SASL specification.

>>inclusion in a "select set of mechanisms".  In particular,
>>ANONYMOUS and OTP may also be suitable for progression.
>
>I wouldn't include any mechanisms other than EXTERNAL, GSSAPI (from 2222) and DIGEST-MD5 in WG charter.

DIGEST-MD5 is the mandatory-to-implement SASL mechanism for LDAP.
LDAPbis currently has it on their charter, but they do not have
the expertise.  Hence, I'd prefer it shift to a SASL WG.

>>KERBEROS_V4 has it own set of issues which make it not
>>suitable for progression to Draft Standard... namely its
>>dependency upon Kerberos IV.
>
>I suggest we just take it out of the revision, so when 2222 is obsoleted by revision, KERBv4 goes historic.

I concur.

>>CRAM-MD5 should be viewed as deprecated by
>>DIGEST-MD5 and likely shouldn't be progressed.
>
>I disagree.  CRAM-MD5 has wide implementation in the email community. There's no reason not to advance it to full standard with an appropriate caveat about the relative security, interoperability and complexity issues with respect to DIGEST-MD5.

I have no objection to this approach.

>Leif Johansson wrote:
>>I hate to say this (imagine me taking cover at this point :-) but
>>I would actually like (imho!) to see the sasl c api get done in the wg.
>
>I volunteer to be document editor or co-editor for C API.  The caveat is that I believe APIs hold a different place in the world from protocols. 

I concur.  I'd prefer such be done as individual effort and
published as an Informational RFC.  I note that Informational
RFCs can have a significant unifying effect upon the community,
evidence RFC 1823 (the LDAPv2 C API).

Date: Thu, 15 Mar 2001 20:15:17 -0800
From: Chris Newman <[email-masked]>
Subject: Re: a dedicated SASL WG
To: "Kurt D. Zeilenga" <[email-masked]>, "Raif S. Naffah" <[email-masked]>, Leif Johansson <[email-masked]>
Cc: SASL <[email-masked]>
Sender: [email-masked]

--On Saturday, March 10, 2001 13:53 -0800 "Kurt D. Zeilenga" 
<[email-masked]> wrote:
> I believe the IETF needs to undertake the revision of
> SASL [RFC2222] and select SASL mechanisms to Draft
> Standard status as soon as possible so as not to
> impede the progress of IETF work dependent on RFC2222.

Benefits of a SASL WG:
* Chair or appointee has task to document feature interoperability for
  advancement
* Chair to nag document editors so work gets done
* Some engineering concensus needed on GSSAPI update and SASL C API issues.

I'd say it just worth it for those reasons.  But we need a volunteer (or 
volunteers) for chair (or co-chairs).

I suggest we try to get it chartered as joint security and apps area WG 
(one AD from each area as area advisor).

> Hence, I would be supportive of chartering the
> a working group to take SASL and a few select mechanisms
> to Draft Standard status, in particular EXTERNAL, PLAIN,
> and DIGEST-MD5.

I'd be inclined to drop PLAIN from that list.  I don't think it needs 
formal WG attention, and the normative reference to TLS is likely the 
gating factor on advancement.

> Though this WG could also take on engineering of new
> mechanisms (including a replacement for GSSAPI), I believe
> this should be viewed as secondary to the above objective.

draft-ietf-cat-sasl-gssapi-02.txt work needs to be done in parallel to 
advancing 2222 since 2222 includes GSSAPI mechanism.

> inclusion in a "select set of mechanisms".  In particular,
> ANONYMOUS and OTP may also be suitable for progression.

I wouldn't include any mechanisms other than EXTERNAL, GSSAPI (from 2222) 
and DIGEST-MD5 in WG charter.

> KERBEROS_V4 has it own set of issues which make it not
> suitable for progression to Draft Standard... namely its
> dependency upon Kerberos IV.

I suggest we just take it out of the revision, so when 2222 is obsoleted by 
revision, KERBv4 goes historic.  Other option is to split it out into 
informational RFC with explicit "LIMITED USE" label on the mechanism.

> SKEY was replaced by OTP, so it likely shouldn't be
> progressed.

Yup.  I wrote the OTP SASL spec so we wouldn't have to worry about SKEY 
when advancing 2222.

> CRAM-MD5 should be viewed as deprecated by
> DIGEST-MD5 and likely shouldn't be progressed.

I disagree.  CRAM-MD5 has wide implementation in the email community. 
There's no reason not to advance it to full standard with an appropriate 
caveat about the relative security, interoperability and complexity issues 
with respect to DIGEST-MD5.  But the WG shouldn't spend time on CRAM-MD5, 
since DIGEST-MD5 is the better choice for mandatory-to-implement mechanism.

Leif Johansson wrote:
> I hate to say this (imagine me taking cover at this point :-) but
> I would actually like (imho!) to see the sasl c api get done in the wg.

I volunteer to be document editor or co-editor for C API.  The caveat is 
that I believe APIs hold a different place in the world from protocols. 
Protocols provide interoperability, while APIs provide depolyment.  Having 
a publically documented API with an open-source implementation is 
sufficiently beneficial to deployment of a protocol that I think it is well 
worth WG effort.  But there's nothing wrong with multiple APIs, so I'd 
prefer to see the SASL C API as an informational RFC.

		- Chris

Date: Thu, 15 Mar 2001 13:01:52 -0800
To: "Raif S. Naffah" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: a dedicated SASL WG 
Cc: SASL <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 06:50 AM 3/16/01 +1100, Raif S. Naffah wrote:
>At 03:23 PM 3/12/01 +0100, Leif Johansson wrote:
>
>>I hate to say this (imagine me taking cover at this point :-) but
>>I would actually like (imho!) to see the sasl c api get done in the wg.
>>...For the java api I absolutely agree with Kurt
>>that it should go into the JCP.
>
>the JCP and the IETF use two different processes for elaborating what would eventually become a "standard."

There should only be one standard and since the JCP is
already working in this area and is the recognized standards
area for Java and Java Extensions, I feel the IETF should
avoid competing with it.

>jsr itself makes reference to the I-D listed in the original
>message of this thread (at least to an earlier version of it).

Which one of the reasons we have RFC 2026, 7.1.  Luckily, it
this conflict is only between a JSR and an I-D... and not
between a Java Standard Extension and a Standard Track RFC.

>i agree that the first item on the SASL WG when it is created should be the advancement of RFC-2222 to standard status.

Noted.

>the reference to "select" mechanism(s), on the other hand, begs the following:
>
>1. should the SASL WG publish a list of criteria for mechanisms worthy of consideration?

I think it would be appropriate for a revised SASL specification
to include security considerations for a SASL profile author to
take into account when it selects mechanisms.  I note that currently
it's the SASL profile author who selects the mechanisms which
are required, recommended, or optional to implement to provide
the desired security services for the protocol.

>2. even if the answer to the previous question is no, is it worth publishing some "guidelines" for designers to consider before submitting a new mechanism?

I would think it appropriate for the revised specification to
at least provide security issues which a developer should
consider.

>3. in any case it may be beneficial to include a statment on the (SASL) WG's position with regard to new mechanisms in a SASL WG Mission Statement.

I would think it appropriate for the charter to say what was in
scope and wasn't.

>[Earlier, at 01:53 PM 3/10/01 -0800, Kurt D. Zeilenga wrote:
>>...
>>I also believe the use of SASL by application protocol
>>should be left to Application Area working groups.
>
>this is a situation where overlap between WGs may, and probably should, occur.  the rationale, considering for example SASL/HTTP, being that it's an area where Domain Knowledge of both SASL and HTTP is required.

As I have little knowledge as to the particulars of HTTP's SASL
profile, so I'll comment in general.

I would assume that application area WG will have or obtain
appropriate security expertise needed.  The application area WG
"owns" the application protocol including specification of use
of SASL or other security frameworks.

>since i do not know if the ietf has, or not, such a collaboration mechanism in place, i'll stop here.

I would say there are established processes in place to
promote development of suitable specifications.

Date: Fri, 16 Mar 2001 06:50:49 +1100
To: Leif Johansson <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: Re: a dedicated SASL WG 
Cc: "Kurt D. Zeilenga" <[email-masked]>, SASL <[email-masked]>, [email-masked], [email-masked], [email-masked], "Raif S. Naffah" <[email-masked]>
Sender: [email-masked]

At 03:23 PM 3/12/01 +0100, Leif Johansson wrote:

>I hate to say this (imagine me taking cover at this point :-) but
>I would actually like (imho!) to see the sasl c api get done in the wg.
>...For the java api I absolutely agree with Kurt
>that it should go into the JCP.

the JCP and the IETF use two different processes for elaborating what would 
eventually become a "standard."  most notably, the specifications 
life-cycle, the access of the public at large to those specifications, and 
the make+cost of participation.

one does not preclude the other.  the Java API for SASL is an excellent 
example.  the API is subject of a JSR (Java Specification Request): 
JSR-28.  the jsr itself makes reference to the I-D listed in the original 
message of this thread (at least to an earlier version of it).

a programming language, or programming-language neutral (e.g. IDL) API, is 
an engineering solution (implementation) of a (for lack of a better word) 
abstract or algorithmic problem.  one place to discuss, at least the 
correctness and completness of the solution, is where the algorithm/method 
is being shredded to pieces (read scrutinised).

i am for including SASL APIs in a SASL WG when one is created.

>However I am not sure why other mechanisms beyond the basic ones
>would not be suitable for a sasl wg... What are your arguments for
>that Kurt?

[Later, at 08:53 AM 3/12/01 -0800, Kurt D. Zeilenga wrote:

>...I believe we
>really need to focus on getting SASL and a select set of
>mechanisms to Draft Standard (so as not to impede other
>IETF work)...

i agree that the first item on the SASL WG when it is created should be the 
advancement of RFC-2222 to standard status.

the reference to "select" mechanism(s), on the other hand, begs the following:

1. should the SASL WG publish a list of criteria for mechanisms worthy of 
consideration?

2. even if the answer to the previous question is no, is it worth 
publishing some "guidelines" for designers to consider before submitting a 
new mechanism?

3. in any case it may be beneficial to include a statment on the (SASL) 
WG's position with regard to new mechanisms in a SASL WG Mission Statement.

[Earlier, at 01:53 PM 3/10/01 -0800, Kurt D. Zeilenga wrote:
>...
>I also believe the use of SASL by application protocol
>should be left to Application Area working groups.

this is a situation where overlap between WGs may, and probably should, 
occur.  the rationale, considering for example SASL/HTTP, being that it's 
an area where Domain Knowledge of both SASL and HTTP is required.

since i do not know if the ietf has, or not, such a collaboration mechanism 
in place, i'll stop here.

cheers;
rsn

Date: Fri, 16 Mar 2001 04:38:14 +1100
To: "SASL" <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: new SASL Java implementation release
Cc: Keith Burdis <[email-masked]>
Sender: [email-masked]

hi there,

a new release of the cryptix SASL library is available for download from 
<http://www.cryptix.org/products/sasl/index.html>.

the library includes an implementation of the Java language bindings 
described in draft-weltman-java-sasl-04.txt. it also includes 
implementations of the following mechanisms:

* ANONYMOUS (RFC 2245)
* CRAM-MD5 (RFC 2195)
* PLAIN (RFC 2595)
* SRP (draft-burdis-cat-srp-sasl-04.txt)
* SM2 (draft-naffah-cat-sasl-sm2-00.txt)

cheers;
rsn

Date: Mon, 12 Mar 2001 10:15:00 -0800
To: "Paul Leach" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: a dedicated SASL WG 
Cc: "SASL" <[email-masked]>
Sender: [email-masked]

At 10:02 AM 3/12/01 -0800, Paul Leach wrote:
>I've heard of no redeisign for SASL-GSS. What are the issues?

See http://www.ietf.org/internet-drafts/draft-ietf-cat-sasl-gssapi-02.txt

Even if this work makes no substantive change to the existing
SASL/GSSAPI mechanism, I note that SASL/GSSAPI cannot be
progressed immediately due to other standard track maturity issues
(GSSAPI is currently at Proposed).  Though I believe GSSAPI
mechanism work should continue, I'd prefer to treat GSSAPI work
as secondary to a primary goal of getting SASL and other
select mechanisms to Draft Standard status.

Kurt

content-class: urn:content-classes:message
Subject: RE: a dedicated SASL WG 
Date: Mon, 12 Mar 2001 10:02:00 -0800
From: "Paul Leach" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: "SASL" <[email-masked]>
Sender: [email-masked]

I've heard of no redeisign for SASL-GSS. What are the issues?

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]] 
> Sent: Monday, March 12, 2001 8:54 AM
> To: Leif Johansson
> 
<snip>

> The fact that the GSSAPI mechanism is being redesigned
> implies it is not suitable for progression. 

Date: Mon, 12 Mar 2001 08:53:59 -0800
To: Leif Johansson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: a dedicated SASL WG 
Cc: "Raif S. Naffah" <[email-masked]>, SASL <[email-masked]>, [email-masked], [email-masked], [email-masked], "Raif S. Naffah" <[email-masked]>
Sender: [email-masked]

At 03:23 PM 3/12/01 +0100, Leif Johansson wrote:
>However I am not sure why other mechanisms beyond the basic ones
>would not be suitable for a sasl wg... What are your arguments for
>that Kurt?

I was primarily attempting to narrow focus so that we could
better assure the critical work was completed in a timely
manner.  I would prefer initially that a SASL WG avoided
(re)designing mechanisms and focused on getting the "core"
of SASL to Draft Standard.  This is not to say that other work
should not continue (as it does today), but I believe we
really need to focus on getting SASL and a select set of
mechanisms to Draft Standard (so as not to impede other
IETF work).

Besides DIGEST-MD5, EXTERNAL, and PLAIN, there may be others
which are suitable for progression and appropriate for
inclusion in a "select set of mechanisms".  In particular,
ANONYMOUS and OTP may also be suitable for progression.

The fact that the GSSAPI mechanism is being redesigned
implies it is not suitable for progression. 

KERBEROS_V4 has it own set of issues which make it not
suitable for progression to Draft Standard... namely its
dependency upon Kerberos IV.

SKEY was replaced by OTP, so it likely shouldn't be
progressed.  CRAM-MD5 should be viewed as deprecated by
DIGEST-MD5 and likely shouldn't be progressed.

Kurt

To: "Kurt D. Zeilenga" <[email-masked]>
cc: "Raif S. Naffah" <[email-masked]>, SASL <[email-masked]>, [email-masked], [email-masked], [email-masked], "Raif S. Naffah" <[email-masked]>
Subject: Re: a dedicated SASL WG 
Date: Mon, 12 Mar 2001 15:23:30 +0100
From: Leif Johansson <[email-masked]>
Sender: [email-masked]

I hate to say this (imagine me taking cover at this point :-) but 
I would actually like (imho!) to see the sasl c api get done in the wg. 
Yes I know all the arguments against doing apis in the ietf but I 
believe that this _may_ be one of those times, much like the gssapi, 
when it  is apropriate. For the java api I absolutely agree with Kurt 
that it should go into the JCP.

However I am not sure why other mechanisms beyond the basic ones
would not be suitable for a sasl wg... What are your arguments for
that Kurt?

	Cheers Leif

Date: Sat, 10 Mar 2001 13:53:03 -0800
To: "Raif S. Naffah" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: a dedicated SASL WG
Cc: SASL <[email-masked]>, [email-masked], [email-masked], [email-masked], "Raif S. Naffah" <[email-masked]>
Sender: [email-masked]

I actually intended to chat with JeffS and JohnM regarding
rechartering of the (concluded) SASL WG at IETF#50...  here
are my thoughts.

I believe the IETF needs to undertake the revision of
SASL [RFC2222] and select SASL mechanisms to Draft
Standard status as soon as possible so as not to
impede the progress of IETF work dependent on RFC2222.
I firmly believe that SASL itself and select mechanisms
are suitable for publication as a Draft Standard.

Hence, I would be supportive of chartering the
a working group to take SASL and a few select mechanisms
to Draft Standard status, in particular EXTERNAL, PLAIN,
and DIGEST-MD5.

Though this WG could also take on engineering of new
mechanisms (including a replacement for GSSAPI), I believe
this should be viewed as secondary to the above objective.
I believe specification of many mechanisms should be done
by other working groups or on an individual basis.

I would recommend against taking on the Java SASL API work.
The Java Community Program is working in this area and the
IETF should avoid competing with the JCP.

I also believe the use of SASL by application protocol
should be left to Application Area working groups.

        Kurt

At 06:39 AM 3/11/01 +1100, Raif S. Naffah wrote:
>hi there,
>
>There are currently many SASL-related drafts other than the one (SASL GSS-API mechanisms <http://search.ietf.org/internet-drafts/draft-ietf-cat-sasl-gssapi-02.txt>) listed under the Common Authentication Technology WG drafts, namely:
>
>A. new SASL mechanisms:
>
>   1. Secure Remote Password SASL Mechanism
>   <http://search.ietf.org/internet-drafts/draft-burdis-cat-srp-sasl-04.txt>
>
>   2. SM2 -- A Session Management Capable SASL Mechanism
>   <http://search.ietf.org/internet-drafts/draft-naffah-cat-sasl-sm2-00.txt>
>
>   3. X.509 Authentication SASL Mechanism
>   <http://search.ietf.org/internet-drafts/draft-ietf-ldapext-x509-sasl-03.txt>
>
>   4. ISO/IEC 9798-3 Authentication SASL Mechanism
>   <http://search.ietf.org/internet-drafts/draft-zuccherato-9798-3-sasl-02.txt>
>
>B. Java SASL API:
>
>   5. The Java SASL Application Program Interface
>   <http://search.ietf.org/internet-drafts/draft-weltman-java-sasl-04.txt>
>
>C. Using SASL with other protocols:
>
>   6. Upgrading to SASL Within HTTP/1.1
>   <http://search.ietf.org/internet-drafts/draft-burdis-http-sasl-00.txt>
>
>   7. SASL in HTTP/1.1
>   <http://search.ietf.org/internet-drafts/draft-nystrom-http-sasl-00.txt>
>
>   8. LDAP Authentication Response Control
>   <http://search.ietf.org/internet-drafts/draft-weltman-ldapv3-auth-response-03.txt>
>
>
>As clarified by the Common Authentication Technology (CAT) WG Chair, John Linn, SASL mechanisms, APIs, and SASL/protocol integration documents have not been work items of the CAT-WG, and CAT has itself been placed in an idle state, pending on possible advancement of its existing RFCs but not undertaking new work.
>
>My question to the list is: how ready, and/or willing, is the SASL community to charter a new WG dedicated to SASL?
>
>
>TIA + cheers;
>rsn
>
>cc: John Linn, Jeffrey Schiller, Marcus Leech.

Date: Sun, 11 Mar 2001 06:39:55 +1100
To: SASL <[email-masked]>
From: "Raif S. Naffah" <[email-masked]>
Subject: a dedicated SASL WG
Cc: [email-masked], [email-masked], [email-masked], "Raif S. Naffah" <[email-masked]>
Sender: [email-masked]

hi there,

There are currently many SASL-related drafts other than the one (SASL 
GSS-API mechanisms 
<http://search.ietf.org/internet-drafts/draft-ietf-cat-sasl-gssapi-02.txt>) 
listed under the Common Authentication Technology WG drafts, namely:

A. new SASL mechanisms:

    1. Secure Remote Password SASL Mechanism
    <http://search.ietf.org/internet-drafts/draft-burdis-cat-srp-sasl-04.txt>

    2. SM2 -- A Session Management Capable SASL Mechanism
    <http://search.ietf.org/internet-drafts/draft-naffah-cat-sasl-sm2-00.txt>

    3. X.509 Authentication SASL Mechanism
    <http://search.ietf.org/internet-drafts/draft-ietf-ldapext-x509-sasl-03.txt>

    4. ISO/IEC 9798-3 Authentication SASL Mechanism
    <http://search.ietf.org/internet-drafts/draft-zuccherato-9798-3-sasl-02.txt>

B. Java SASL API:

    5. The Java SASL Application Program Interface
    <http://search.ietf.org/internet-drafts/draft-weltman-java-sasl-04.txt>

C. Using SASL with other protocols:

    6. Upgrading to SASL Within HTTP/1.1
    <http://search.ietf.org/internet-drafts/draft-burdis-http-sasl-00.txt>

    7. SASL in HTTP/1.1
    <http://search.ietf.org/internet-drafts/draft-nystrom-http-sasl-00.txt>

    8. LDAP Authentication Response Control
    <http://search.ietf.org/internet-drafts/draft-weltman-ldapv3-auth-response-03.txt>

As clarified by the Common Authentication Technology (CAT) WG Chair, John 
Linn, SASL mechanisms, APIs, and SASL/protocol integration documents have 
not been work items of the CAT-WG, and CAT has itself been placed in an 
idle state, pending on possible advancement of its existing RFCs but not 
undertaking new work.

My question to the list is: how ready, and/or willing, is the SASL 
community to charter a new WG dedicated to SASL?

TIA + cheers;
rsn

cc: John Linn, Jeffrey Schiller, Marcus Leech.