Subject: CRAM editorial updates
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Date: Mon, 22 Aug 2005 20:19:06 -0700
List-Id: <ietf-sasl.imc.org>

Folks, I apologize for the delay in getting -05 out. I (thought I)  
sent it out in July, but apparently I'm not the e-mail wizard I claim  
to be :-)

Meanwhile I have been spending some time looking at the Plain draft,  
and I must say I like the way it is written and presented. I want to  
take the CRAM document and re-edit it into that same style. What's  
missing for me as editor is the 'applicability statement' that was  
talked about in Paris. Did anyone come up with snarf-and-barf text  
for this? If not, can someone give me a consensus overview of how  
that text should read?

--lyndon

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-crammd5-05.txt 
Date: Mon, 22 Aug 2005 15:50:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: The CRAM-MD5 SASL Mechanism
	Author(s)	: L. Nerenberg
	Filename	: draft-ietf-sasl-crammd5-05.txt
	Pages		: 11
	Date		: 2005-8-22
	
This document defines a simple challenge-response authentication
   mechanism, using a keyed MD5 digest, for use with the Simple
   Authentication and Security Layer (SASL).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-ietf-sasl-crammd5-05.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-ietf-sasl-crammd5-05.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-ietf-sasl-crammd5-05.txt

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

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

--OtherAccess--

--NextPart--

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Fwd: GNU SASL 0.2.6
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 12 Aug 2005 11:39:22 +0200
Sender: [email-masked]

FYI, the latest release of my SASL library (see below) implement PLAIN
and CRAM-MD5 according to draft-ietf-sasl-plain-08 and
draft-ietf-sasl-crammd5-04.  Actually, some variant of NFKC or
SASLPrep has been used in mechanisms since the first release back in
2002, so this is not a new feature in my library.

WG members may find the self test suite useful for generating test
vectors or experiment with non-ASCII username or passwords.

I'm making this announcement to get in contact with other implementers
on this list that would like to do interoperability testing.  I
believe it is a bad sign that there has been little implementation
feedback to this WG, not even now when we are approaching to finalize
the documents.

Regards,
Simon

-------------------- Start of forwarded message --------------------
From: Simon Josefsson <[email-masked]>
Newsgroups: gmane.org.fsf.announce
Subject: GNU SASL 0.2.6
Date: Wed, 10 Aug 2005 16:07:07 +0200
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:050810:[email-masked]::angyXCRbHVBVBrYs:8Gk
X-Hashcash: 1:21:050810:[email-masked]::Ul4yPENn02Bu82jN:UG6O
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

I am pleased to announce the availability of GNU SASL version 0.2.6!

GNU SASL is a modern C library that implement the standard network
security protocol Simple Authentication and Security Layer (SASL).
The framework and a couple of common SASL mechanisms are implemented.
GNU SASL can be used by network applications for IMAP, SMTP and
similar protocols to provide authentication services (and more).

Noteworthy changes since version 0.2.5:
- The SASL PLAIN server now permit unassigned code points in SASLprep.
  This aligns with draft-ietf-sasl-plain-08.txt which is in last call.
- The gsasl tool now try to connect to all addresses for a server name.
- Fix use of 'head -1' in configure script.
- The macro AX_CREATE_STDINT_H used to find uint8_t, uint32_t etc was updated.
- The license template in files were updated with the new FSF address.
- gsasl_check_version simplified and made more robust.
- Update of gnulib files.

Improving GNU SASL is costly, but you can help!  We are looking for
organizations that find GNU SASL useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, purchase
support contracts, or donate money or equipment.

Commercial support contracts for GNU SASL are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a
Stockholm based privately held company, is currently funding GNU SASL
maintenance.  We are always looking for interesting development
projects.

If you need help to use GNU SASL, or want to help others, you are
invited to join our help-gsasl mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gsasl>.

The project page of the library is available at:
  http://www.gnu.org/software/gsasl/
  http://josefsson.org/gsasl/

Here are the compressed sources of the entire package:
  http://josefsson.org/gsasl/releases/gsasl-0.2.6.tar.gz   (2.6MB)
  http://josefsson.org/gsasl/releases/gsasl-0.2.6.tar.gz.sig  (PGP signature)

Here are the compressed sources of the LGPL library (included above):
  http://josefsson.org/gsasl/releases/libgsasl-0.2.6.tar.gz   (572KKB)
  http://josefsson.org/gsasl/releases/libgsasl-0.2.6.tar.gz.sig  (PGP sig)

Here are the MD5/SHA-1 checksums:

5e527147cea5cc776240f6d7a6820955  gsasl-0.2.6.tar.gz
d465b55f75349f2fa9ec05ed5cf66e40  gsasl-0.2.6.tar.gz.sig
8297876efe007dfe641626836500751dbe331e6e  gsasl-0.2.6.tar.gz
fa18a5e1aea6308526860556c83501924c03a8d1  gsasl-0.2.6.tar.gz.sig

23cd84742a08c7ef7fb5c9b60c4755e0  libgsasl-0.2.6.tar.gz
438c2cb6d8193e85a2669b5bc57878c0  libgsasl-0.2.6.tar.gz.sig
86e3a425ef353978c1143074999ff30953190c97  libgsasl-0.2.6.tar.gz
13897748f9c89fce5b71d6b786a75df58b4f0815  libgsasl-0.2.6.tar.gz.sig

Here are the build reports for various platforms:
  http://josefsson.org/autobuild-logs/gsasl.html

Enjoy,
Simon

_______________________________________________
GNU Announcement mailing list <[email-masked]>
http://lists.gnu.org/mailman/listinfo/info-gnu

-------------------- End of forwarded message --------------------

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Some DIGEST-MD5 nits
From: Sam Hartman <[email-masked]>
Date: Wed, 10 Aug 2005 09:43:00 -0400
Sender: [email-masked]

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> This is a reply to an old thread, regarding the choice of
    Simon> RC4 as the mandatory to implement encryption algorithm in
    Simon> DIGEST-MD5...  If we are discussing dropping DIGEST-MD5
    Simon> altogether, this point may be moot, but the paper below may
    Simon> be interesting to some anyway.

    Simon> Sam Hartman <[email-masked]> writes:

    >> rc4 is the mandatory to implement cipher because it is the one
    >> for which we have interoperable implementations.  It's strong
    >> in this application--or at least we don't know about any
    >> attacks--and it is correctly implemented in existing
    >> implementations.

    Simon> RC4 appear to have weak keys:

    Simon> http://eprint.iacr.org/2005/233.pdf On the Entropy of
    Simon> Arcfour Keys

    Simon> This particular result is not practical, though.  Merely
    Simon> something to consider when thinking about which mandatory
    Simon> cipher to chose..

I don't think we need to worry about the key scheduling problems
because I believe we handle that correctly.  I or someone else should
double check that though.

One thing we do need to worry about is that there is a distinguisher
for RC4 which means it is not an ideal PRNG.  I think that might cause
us to want to consider AES as a MUST and RC4 as a strong SHOULD for
interop.

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: Some DIGEST-MD5 nits
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 10 Aug 2005 11:53:03 +0200
Sender: [email-masked]

This is a reply to an old thread, regarding the choice of RC4 as the
mandatory to implement encryption algorithm in DIGEST-MD5...  If we
are discussing dropping DIGEST-MD5 altogether, this point may be moot,
but the paper below may be interesting to some anyway.

Sam Hartman <[email-masked]> writes:

> rc4 is the mandatory to implement cipher because it is the one for
> which we have interoperable implementations.  It's strong in this
> application--or at least we don't know about any attacks--and it is
> correctly implemented in existing implementations.

RC4 appear to have weak keys:

http://eprint.iacr.org/2005/233.pdf
On the Entropy of Arcfour Keys

This particular result is not practical, though.  Merely something to
consider when thinking about which mandatory cipher to chose..

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: IETF63 SASL WG Summary
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 05 Aug 2005 15:23:00 +0200
Sender: [email-masked]

Tom Yu <[email-masked]> writes:

> Simon points out that CRAM-MD5 uses HMAC and has provable
> security, while DIGEST-MD5 doesn't.

I may recall incorrectly, but I believe I only said that we have seen
feedback from real cryptographers with (positive) opinions on HMAC,
but no review for DIGEST-MD5.  There are no proofs at all, as far as I
know.  I don't believe HMAC is provable secure, unless you assume
certain properties of the hash function that we know doesn't hold for
MD5.  Pointers or references to any work in this area would be
appreciated.

Thanks,
Simon

To: [email-masked]
Subject: IETF63 SASL WG draft minutes
From: Tom Yu <[email-masked]>
Date: Fri, 05 Aug 2005 05:18:49 -0400
Lines: 111
Sender: [email-masked]

Below are the draft minutes for the IETF63 SASL WG session.  Please
let me know if you have any comments or corrections.

---Tom

Simple Authentication and Security Layer (SASL) WG
Tuesday, August 2, 2005
16:30-18:00

Chairs:
Tom Yu <[email-masked]>
Kurt Zeilenga <[email-masked]>

Thanks to Love Hornquist-Astrand, Jeffrey Altman, and Jeffrey
Hutzelman for scribing.

Document status:

Tom somehow forgets that anon was already approved.

CRAM-MD5 expired.  Sam Hartman desires to publish it as Historic.  In
any case, the document needs a better applicability statement.  Some
discussion ensues about whether Historic or Informational status is
more appropriate.  There is consensus to take the document off of the
standards track.

Simon Josefsson brings up the question of whether SASLprep can be
added to the protocol (for migration support) and still have the
document issued as Historic.  Tony Hansen indicates that existing
implementations already do SASLprep on CRAM-MD5, so adding saslprep
support would be documenting existing practice.  Sam thinks it needs
to go Informational if internationalization support is added.  Someone
points out that we could publish as Informational and immediately move
to Historic, whereupon Sam withdraws his comment.

Alexey has updated the GSSAPI mech document.  SASLprep needs to be
addressed.  Some discussion ensues about roundtrip optimization.  It
is pointed out that there are actually two specifications in the
GSSAPI mech document: the legacy mechanisms krb5 and SPNEGO, and the
family of mechansims whose names are produced by hashing.  jhutz
suggests removing the non-legacy mechanisms from this document.
Consensus that optimization is important.  Consensus for performing
the document split.

PLAIN mechanism revised; Kurt and Sam still need to talk about some
issues.

SASL base:

SASL base specification (rfc2222bis) has been to WGLC.  It received
some responses, many editorial.  Some misunderstandings about
Stringprep remain.  Kurt acknowledges that the text still has clarity
issues.  jhutz indicates that people reading the document, as well as
other SASL documents, get really confused about the distinction
between authentication and authorization names, and about whether
responsibility for handling each of these names lies with the
application implementation or with the mechanism implementation.
A straw poll indicates that about 7 people find SASL names confusing,
while about 2 don't.

DIGEST-MD5:

DIGEST-MD5 re-issued recently.  Alexey sent mail to the list
requesting comment on recent changes, and about where SASLprep is
done.  Discussion ensues about CBC mode vs counter mode.  We believe
counter mode is good.  Alexey wants help with describing counter mode.
Consensus exists to drop CBC that does not send random IV in every
packet (proposal #2).  Simon Josefsson proposes using a mode with
combined integrity checking such as CCM/GCM.  Sam recommends checking
IPR carefully.  Sam also suggests putting the combined mode in a
separate document, and to just complete the work.

Phillip Guenther brings up Christian Huitema's presentation to the
Applications Area about CRAM-MD5 and other challenge-response
protocols being insecure due to offline attacks.  Question of whether
we should recommend running DIGEST-MD5 over TLS.  Nico describes how
channel bindings might be useful for this purpose.  Some discussion of
whether extending DIGEST-MD5 to use channel bindings is within our
charter.

Sam notes DIGEST-MD5 is relatively extensible.  digest-md5 or
digest-sha1?  It's great if digest-md5 is done, but will it be secure?
If digest-md5 is delayed, plain passwords may win.

Roger Harrison indicates that LDAP community wants a strong
mandatory-to-implement security mechanism, and that they have some
uncertainty about whether algorithms are secure given recent
discoveries about hashes.  Sam points out that the challenge-response
issues are separate from the hash issues, and the recent attacks are
specifically against hash algorithms; we know how to protect against
dictionary attacks.  Kurt notes that Applications Area has had
discussions whether it's time to deprecate challenge-response sent in
the clear.

ACTION ITEMS
============

SASL-base to iesg by end of Aug.

discuss future of DIGEST-MD5

discuss future of CRAM-MD5

text for CRAM-MD5 applicability

split GSSAPI SASL mech -> legacy (krb5 & spnego) vs other GSSAPI
mechanisms

GSSAPI SASL legacy mech ready by Oct.

other revised milestones to be discussed on list

Date: Thu, 4 Aug 2005 11:15:07 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Channel bindings in GSSAPI
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Aug 04, 2005 at 05:42:23PM +0200, Jeffrey Hutzelman wrote:
> 
> 
> 
> On Thursday, August 04, 2005 14:44:04 +0200 Simon Josefsson 
> <[email-masked]> wrote:
> 
> >
> >The "GSSAPI" mech currently require the channel bindings to be NULL.
> >
> >How about permitting using the GSS-B32(MD5(KRB5-OID)) mechanism for
> >those application that wants channel bindings with Kerberos 5?
> >
> >Currently the GSSAPI mech document imply that if you do Kerberos 5,
> >you must use "GSSAPI". GSS-B32(MD5(KRB5-OID)) is effectively
> >forbidden.
> 
> We just agreed in the WG meeting to drop the GSS-* from this document.  The 
> idea is to define only 'GSSAPI' and 'GSS-SPNEGO' today, so we can get it 
> done and document what is widely deployed.  Then we can do a new document 
> describing a complete family of GSSAPI-based SASL mechanisms with fewer 
> round trips, channel bindings, etc.

So?

> I believe the GSS-* names should be reserved, and a different class of 
> names (perhaps GSS2-*) defined for the family of mechanisms to be defined 
> in the new document.  This way, we avoid any possibility of confusion with 
> existing implementations which claim to support the corresponding SASL 
> mechs for every GSS mech provided by their GSSAPI implementation.

Hmmm, maybe, but we all seemed to agree that there are no
implementations of GSS-B32(MD5(KRB5-OID)).

Nico
-- 

Date: Thu, 04 Aug 2005 17:42:23 +0200
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Channel bindings in GSSAPI
Originator-Info: login-token=Mulberry:016EChXVKoFtE0ixneG77RzH+y2IhvdBpVtc/CHsA=; token_authority=[email-masked]
Sender: [email-masked]

On Thursday, August 04, 2005 14:44:04 +0200 Simon Josefsson 
<[email-masked]> wrote:

>
> The "GSSAPI" mech currently require the channel bindings to be NULL.
>
> How about permitting using the GSS-B32(MD5(KRB5-OID)) mechanism for
> those application that wants channel bindings with Kerberos 5?
>
> Currently the GSSAPI mech document imply that if you do Kerberos 5,
> you must use "GSSAPI". GSS-B32(MD5(KRB5-OID)) is effectively
> forbidden.

We just agreed in the WG meeting to drop the GSS-* from this document.  The 
idea is to define only 'GSSAPI' and 'GSS-SPNEGO' today, so we can get it 
done and document what is widely deployed.  Then we can do a new document 
describing a complete family of GSSAPI-based SASL mechanisms with fewer 
round trips, channel bindings, etc.

I believe the GSS-* names should be reserved, and a different class of 
names (perhaps GSS2-*) defined for the family of mechanisms to be defined 
in the new document.  This way, we avoid any possibility of confusion with 
existing implementations which claim to support the corresponding SASL 
mechs for every GSS mech provided by their GSSAPI implementation.

In addition, I think it would be really bad to use GSS-B32(MD5(KRB5-OID)) 
to mean something different than GSSAPI, on the grounds that there might be 
implementations out there that treat them as synonyms, either accidentally 
or in order to be liberal in what they accept from buggy peers.

-- Jeff

Date: Thu, 04 Aug 2005 14:07:14 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: Channel bindings in GSSAPI
Sender: [email-masked]

Simon Josefsson wrote:

>The "GSSAPI" mech currently require the channel bindings to be NULL.
>  
>
Yes, existing K5 GSS implementation don't allow for any channel bindings.

>How about permitting using the GSS-B32(MD5(KRB5-OID)) mechanism for
>those application that wants channel bindings with Kerberos 5?
>
>Currently the GSSAPI mech document imply that if you do Kerberos 5,
>you must use "GSSAPI". GSS-B32(MD5(KRB5-OID)) is effectively
>forbidden.
>
>It seems some more text on channel bindings in general would be
>useful.
>  
>
Speaking as an individual, I will have no problems with allowing 
optimized K5 GSS mechanism as a part of family of GSS mechanisms (new 
GSS draft). The new draft should also allow for non-NULL channel bindings.

Alexey

Date: Thu, 4 Aug 2005 08:07:04 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Channel bindings in GSSAPI
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Aug 04, 2005 at 02:44:04PM +0200, Simon Josefsson wrote:
> 
> The "GSSAPI" mech currently require the channel bindings to be NULL.
> 
> How about permitting using the GSS-B32(MD5(KRB5-OID)) mechanism for
> those application that wants channel bindings with Kerberos 5?

Absolutely.

> Currently the GSSAPI mech document imply that if you do Kerberos 5,
> you must use "GSSAPI". GSS-B32(MD5(KRB5-OID)) is effectively
> forbidden.
> 
> It seems some more text on channel bindings in general would be
> useful.

In SASL?  Yes, emphatically.

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Channel bindings in GSSAPI
Date: Thu, 04 Aug 2005 14:44:04 +0200
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Sender: [email-masked]

The "GSSAPI" mech currently require the channel bindings to be NULL.

How about permitting using the GSS-B32(MD5(KRB5-OID)) mechanism for
those application that wants channel bindings with Kerberos 5?

Currently the GSSAPI mech document imply that if you do Kerberos 5,
you must use "GSSAPI". GSS-B32(MD5(KRB5-OID)) is effectively
forbidden.

It seems some more text on channel bindings in general would be
useful.

Thanks,
Simon

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: IETF63 SASL WG Summary
From: Tom Yu <[email-masked]>
Date: Thu, 04 Aug 2005 07:28:21 -0400
Lines: 52
Sender: [email-masked]

SASL WG
Tuesday, August 2, 2005
16:30-18:00

SUMMARY
=======

CRAM-MD5 is expired; Sam suggests that it be published as historic or
informational.  Consensus to take it off the standards track.  It also
needs a better applicability statement.  The GSSAPI mech draft has
been refreshed; it has two sorts of mechanisms: the generic family and
legacy (krb5 and SPNEGO).  Roundtrip optimizations are only available
for legacy mechanisms.  Consensus to work on roundtrip optimization of
generic family and split out legacy mechanisms.  PLAIN revised, and
got some replies.  Sam will talk with Kurt regarding some issues.

SASL base specification (rfc2222bis) went to WGLC, got some responses,
mostly editorial, and some misunderstandings about stringprep.  We
appreciate the outside review.  Confusion remains about authentication
vs authorization names; additional clarity is needed in the text here.

DIGEST-MD5 (rfc2831bis) re-issued recently.  Alexey sent mail
requesting comment; none yet.  Discussion of AES cipher mode: CBC mode
vs counter mode.  Agreement that counter mode is good.  Consensus to
drop CBC that does not send random IV in every packet ("proposal #2").
Lengthy discussion of whether to use CCM/GCM or other combined
encryption & integrity modes.  Phillip notes Christian's presentation
to Applications Area re security of challenge response; raised
concerns that DIGEST-MD5 is not much better than CRAM-MD5, thus must
be used under TLS.  Nico explains how channel bindings to TLS would be
useful.  Simon points out that CRAM-MD5 uses HMAC and has provable
security, while DIGEST-MD5 doesn't.  Roger says LDAP community is
concerned.  Apps area is nervous about lack of security community
consensus re hash breaks, including how DIGEST-MD5 is affected.

ACTION ITEMS
============

SASL-base to iesg by end of Aug.

discuss future of DIGEST-MD5

discuss future of CRAM-MD5

text for CRAM-MD5 applicability

split GSSAPI SASL mech -> legacy (krb5 & spnego) vs other GSSAPI
mechanisms

GSSAPI SASL legacy mech ready by Oct.

other revised milestones to be discussed on list

To: Alexey Melnikov <[email-masked]>
Cc: Jeffrey Altman <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Changes in DIGEST-MD5 -06
From: Tom Yu <[email-masked]>
Date: Wed, 03 Aug 2005 05:00:16 -0400
Lines: 26
Sender: [email-masked]

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

Alexey> Jeffrey Altman wrote:

>> Alexey:
>> 
>> Can you explain to me the reference to RFC 2821 in this draft?
>> 
>> Did you really mean "Simple Mail Transport Protocol"?  If so, you
>> should add it to the references section.  If not, it should be
>> corrected.

Alexey> The document is using HTTP-style ABNF, which has an additional
Alexey> construct, not present in ABNF. ABNF has originated from RFC 822, thus
Alexey> the reference.
Alexey> I am planning to update the document to reference ABNF RFC properly.

So the only references I see to RFC 2821 in the draft are some
references involving nonces.  Are you sure you didn't mean RFC 2831?

Also, I think it should be made more clear that the ABNF used in the
draft is different from the one defined in RFC 2234.  Some of the
syntax described in the draft confused me until I realized that
different ABNF was being used.

---Tom

Date: Wed, 03 Aug 2005 08:55:50 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Changes in DIGEST-MD5 -06
Sender: [email-masked]

Nicolas Williams wrote:

>I've text on channel bindings using Jeff Altman's idea of overloading
>the nonce/cnonce fields, but I think we could use a new item in the
>challenge and response messages to fully disambiguate from non-channel
>bindings cases, though it's not absolutely necessary.  Can new things be
>added?
>
DIGEST-MD5 is extensible, if this is your question.

>  If not, then I'll send the text I have.
>  
>

Date: Wed, 3 Aug 2005 02:54:12 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Changes in DIGEST-MD5 -06
Mail-Followup-To: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

I've text on channel bindings using Jeff Altman's idea of overloading
the nonce/cnonce fields, but I think we could use a new item in the
challenge and response messages to fully disambiguate from non-channel
bindings cases, though it's not absolutely necessary.  Can new things be
added?  If not, then I'll send the text I have.

Nico
-- 

Date: Wed, 03 Aug 2005 08:26:28 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Altman <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Changes in DIGEST-MD5 -06
Sender: [email-masked]

Jeffrey Altman wrote:

>Alexey:
>
>Can you explain to me the reference to RFC 2821 in this draft?
>
>Did you really mean "Simple Mail Transport Protocol"?  If so, you
>should add it to the references section.  If not, it should be
>corrected.
>  
>
The document is using HTTP-style ABNF, which has an additional 
construct, not present in ABNF. ABNF has originated from RFC 822, thus 
the reference.
I am planning to update the document to reference ABNF RFC properly.

Date: Tue, 02 Aug 2005 19:23:59 +0200
From: Jeffrey Altman <[email-masked]>
Organization: No Longer Affiliated with Columbia University in the City of New York
To: Alexey Melnikov <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Changes in DIGEST-MD5 -06
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Alexey:

Can you explain to me the reference to RFC 2821 in this draft?

Did you really mean "Simple Mail Transport Protocol"?  If so, you
should add it to the references section.  If not, it should be
corrected.

Jeffrey Altman

--------------ms000604010508030802000509
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

--------------ms000604010508030802000509--

From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: [(nowhere)] Review: Simple Authentication and Security Layer  (SASL)
Date: Tue, 2 Aug 2005 10:14:10 -0400 
Sender: [email-masked]

Kurt,

The meta-point underlying all of this is that while what you've
written is doubtless correct, it is not obvious from the draft.
I was asked to review the draft as a non-expert in SASL, and this
stuff is not obvious to a non-expert.

There should be a draft section on Unicode, including both encoding
and normalization that explains what's going on clearly, concisely,
and in one place, given the difficulty we're having in this email
exchange in teasing out the structure and responsibilities of
Unicode support in SASL.

Thanks,
--David 
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]] 
> Sent: Tuesday, August 02, 2005 9:41 AM
> To: Black, David
> Cc: [email-masked]; Black, David; [email-masked]
> Subject: RE: [(nowhere)] Review: Simple Authentication and 
> Security Layer (SASL)
> 
> Sorry for the delayed response... I've been in vacation mode...  :-)
> 
> At 10:00 PM 7/26/2005, [email-masked] wrote:
> >        When designing a SASL mechanism for which the syntax of
> >authorization
> >        identities is known,
> 
> A SASL mechanism should be designed to be neutral of application
> protocol specifics including the particular syntax and matching
> semantics of authorization identities.
> 
> >using a character normalization mechanism
> >        appropriate to those identities for all character 
> data in the SASL
> >        mechanism avoids the need for two different normalizations,
> 
> Mechanisms should use (in challenges and responses)
> authorization identity strings as presented, expecting possibly
> transformation to the mechanism-specific character encoding
> format.
> 
> >potentially
> >        simplifying implementations.
> 
> Implementations that appropriately separate mechanism processing
> from application-protocol processing are reasonable simple.
> 
> >For example, for a PKI SASL mechanism
> >        where X.509 DN's are expected as authorization identities, a
> >stringprep
> >        variant appropriate for X.509 DN's could be 
> specified for all other
> >        character data in the SASL mechanism (e.g., LDAP stringprep
> >        [draft-ietf-ldapbis-strprep], as applied to X.509 DN's in
> >        [draft-hoffman-pkix-stringmatch], thereby avoiding 
> the need to
> >        implement both LDAP stringprep and SASLprep). 
> 
> I note that given that DNs are not strings but a complex data 
> structure
> (which may be represented using strings), using them here
> would be confusing.  A better example **might be** an International
> Domain Name.
> 
> 

Date: Tue, 02 Aug 2005 15:50:53 +0200
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: [(nowhere)] Review: Simple Authentication and Security Layer  (SASL)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 07:53 AM 7/19/2005, [email-masked] wrote:
>IMHO, the description of EXTERNAL should contain a sentence saying
>that the client is responsible for any Unicode character
>normalization of the authorization identity string required by the
>protocol that uses the EXTERNAL mechanism. 

Where normalization of the authorization identity is necessary,
its up to the application protocol's specification to state
where its done.  Its not necessarily done on the client side.
For instance, LDAP authzIds are not required to be normalized
prior to transfer by the client.  Instead, the protocol incorporates
normalization into the authzId matching algorithm (performed
by the server).

Kurt 

Date: Tue, 02 Aug 2005 15:40:55 +0200
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: [(nowhere)] Review: Simple Authentication and Security Layer  (SASL)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Sorry for the delayed response... I've been in vacation mode...  :-)

At 10:00 PM 7/26/2005, [email-masked] wrote:
>        When designing a SASL mechanism for which the syntax of
>authorization
>        identities is known,

A SASL mechanism should be designed to be neutral of application
protocol specifics including the particular syntax and matching
semantics of authorization identities.

>using a character normalization mechanism
>        appropriate to those identities for all character data in the SASL
>        mechanism avoids the need for two different normalizations,

Mechanisms should use (in challenges and responses)
authorization identity strings as presented, expecting possibly
transformation to the mechanism-specific character encoding
format.

>potentially
>        simplifying implementations.

Implementations that appropriately separate mechanism processing
from application-protocol processing are reasonable simple.

>For example, for a PKI SASL mechanism
>        where X.509 DN's are expected as authorization identities, a
>stringprep
>        variant appropriate for X.509 DN's could be specified for all other
>        character data in the SASL mechanism (e.g., LDAP stringprep
>        [draft-ietf-ldapbis-strprep], as applied to X.509 DN's in
>        [draft-hoffman-pkix-stringmatch], thereby avoiding the need to
>        implement both LDAP stringprep and SASLprep). 

I note that given that DNs are not strings but a complex data structure
(which may be represented using strings), using them here
would be confusing.  A better example **might be** an International
Domain Name.