Subject: SASL session for IETF 70
From: Tom Yu <[email-masked]>
To: [email-masked]
Date: Sun, 30 Sep 2007 23:52:37 -0400
List-Id: <ietf-sasl.imc.org>

I have submitted a request for a 2-hour meeting session at IETF 70.
Please let me know if I should adjust the conflict lists.  Initial
request deadline is Oct. 1 at 17:00 US/Eastern.

Working Group Name: sasl
Area Name: Security Area
Session Requester: Tom Yu

Number of Sessions: 1
Length of Session(s):  2 hours

Number of Attendees: 45
Conflicts to Avoid:
  First Priority:  krb-wg pkix saag tls apparea imapext eap sieve kitten lemonade calsify emu ipr btns
  Second Priority:  dkim capwap

Special Requests:
  setup with second projection screen and extra wireless microphones like krb-wg and kitten have used in the past.

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Date:  Fri, 28 Sep 2007 19:12:01 +0200
Organization:  http://purl.net/xyzzy
Lines: 18
Sender: [email-masked]

Kurt Zeilenga wrote:
=20
> A single "for instance" might be okay, but I see no need
> to enumerate all known issues.

Likely not all, but the "md5-sess" issue deserves a detailed
technical explanation.  The I-D could state that 2617+erratum
and 2831 differ for "md5-sess", and it could use one of the
three published pairs of examples for 2831 "md5-sess" to show
the corresponding _different_ result with the 2617 algorithm.

IOW use HA1 either in its binary form (2831+4643), or in its
hex. form (2617+erratum, I-D.smith).  When 2831 is historic
I'd probably pick the 2617+erratum "md5-sess" algorithm as
the default, and I'd offer the 2831 "md5-sess" algorithm as
option.

 Frank

Date: Fri, 28 Sep 2007 22:01:12 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: SCRAM-04 questions
Sender: [email-masked]

At 2007-09-23 05:33:19 +0200, [email-masked] wrote:
>
> > I'm hoping it will merge with the HEXA proposal and add channel
> > bindings.
> 
> I'm looking forward to it.  

I've been a bit busy recently, but I'm working on it.

-- ams

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
Subject: Re: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Date: Fri, 28 Sep 2007 09:16:57 -0700
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Sep 11, 2007, at 3:52 AM, Frank Ellermann wrote:

> Maybe it should be a bit more specific
> about the interoperability issues:

Speaking as an individual, I rather the I-D not be too specific.  A  
single "for instance" might be okay, but I see no need to enumerate  
all known issues.

-- Kurt

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Date:  Fri, 28 Sep 2007 17:56:36 +0200
Organization:  http://purl.net/xyzzy
Lines: 41
Sender: [email-masked]

Alexey Melnikov wrote:
=20
>> For RFC 4590 and 4590bis I'm also not sure what
>> they implemented, is that some kind of DIGEST-MD5
>> without cnonce ?  How is it computed ?

> I need to reread RFC 4590 to answer this question.

Drop it, RFC 4590bis-02 fixed the examples, and one
of the authors told me that they'll fix the fixed
CNONCE in AUTH48. =20

That leaves two "md5-sess" examples in the expired
I-D.smith-sipping-auth-examples-01 as a source of
confusion.  The "md5-sess" issue also made it to
the outsourced RFC 2617 errata:

http://skrb.org/ietf/http_errata.html#md5sess_sample

If I-D.smith and this erratum are correct the other
md5-sess examples in published RFCs I'm aware of
would be incorrect, i.e. four examples in RFC 2831,
(IMAP + ACAP, response + rspauth) and two examples
in RFC 4643 (NNTPAUTH response + rspauth).

If it turns out that "md5-sess" in RFC 2617+errata
is in fact different from "md5-sess" in RFC 2831,
then I'm sure implementors will be fascinated to
learn this... <sigh>

 Frank

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: SCRAM-04 questions
Date:  Sun, 23 Sep 2007 05:33:19 +0200
Organization:  http://purl.net/xyzzy
Lines: 55
Sender: [email-masked]

Chris Newman wrote (2007-06-28):

>> IMO you could just use hex. instead B64 for s=3D, c=3D, p=3D, and
>> v=3D (at least for p=3D and v=3D the encoded length is irrelavant).
=20
> The examples are placeholders and don't contain valid data yet.

Sure, but I'd still say that using hex. encoding is better than
B64.  With hex. all that could go wrong is upper vs. lower vs.
mixed case, and that's obvious.  There are more B64 variants,
and the differences between say UTF-7 and RFC 4648 B64 are not
so obvious.

> I'm hoping it will merge with the HEXA proposal and add=20
> channel bindings.

I'm looking forward to it. =20
=20
> The server should
[...]
> store the quad { username, salt, H(ClientKey), ServerKey}=20
> (ServerKey is only necessary if mutual authentication is
> performed).  The ClientKey can't be derived from that quad so
> the stored information can't be used to impersonate the client
> by itself.  This is a difference from DIGEST-MD5 where the
> server stored information is plaintext equivalent and=20
> sufficient to impersonate the client in that realm.

Thanks, I missed that point.
=20
>> Before I try to tackle v=3D I'd like to know if the following
>> result for p=3D is still correct (using MD5 as hash):
=20
> MD5 is sufficiently broken that it's unwise to use in new
> protocols.

It's still nice for educational purposes, e.g. if a protocol
doesn't work with MD5 I'd wonder how long it works with say
SHA-256.  And everybody and his dog have MD5 implementations,
also in scripting languages used for prototypes.  And it's
still good enough as hash for various applications like the
NOMCOM lottery, media feature tags, etc.

OTOH I'm not aware that MD5 or better hash functions are good
random number generators.  Your algorithm uses something in
the direction of Hi( x ) :=3D H( Hi-1( x )).   That's not the
same idea as in the otherwise weird "apr1" algorithm, where
they use 1000 iterations of MD5 calculations, but at least
they mix in different parts of the original input in each
iteration.

In other words, are there any known short "cycles" or even
fix points in Hi for H =3D MD5 or better hash functions ? =20

 Frank

Date: Wed, 12 Sep 2007 17:00:09 +0100
From: Tony Finch <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
cc: [email-masked]
Subject: Re: draft-zeilenga-sasl-yap-01
Sender: [email-masked]

On Tue, 11 Sep 2007, Kurt Zeilenga wrote:
> On Sep 11, 2007, at 9:36 PM, Tony Finch wrote:
> >
> > The security considerations section says "Use of the autchid as a salt was
> > considered, but rejected as it would tie the password equivalent to a
> > particular authcid." I don't understand why that is an objection:
>
> A single user might be known by different autchid strings.  For instance, I
> might be both kurt and KURT (and maybe even kdz and KDZ).  If you salt with
> the authcid, then the stored password equivalent is only useful with a single
> authcid for that user.
>
> Adding a "For instance" here might be useful...
>
> > isn't such a tie the whole point of salting in that way, so that users
> > with the same password have different authentication information in
> > the database?
>
> The primary reason for salting is hinder dictionary attacks against the
> equivalent by dramatically increasing the size of pre-computed dictionaries of
> commonly used passwords.
>
> A secondary reason is so that each user is more likely to have a different
> equivalent.  That is, if one is able to discover user A's password and A's and
> B's equivalent, salting obscures the fact that B's passwords is the same as
> A's from the attacker.

I understand the benefits of salting. What I don't understand is why the
draft says that you rejected (a particular type of) salting for a reason
that I think is a benefit of salting not a disadvantage.

The final two sentences in that paragraph do give a plausible reason for
not salting.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-zeilenga-sasl-yap-01
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 12 Sep 2007 14:32:23 +0200
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>     Simon> Would dependence on TLS, similar as in PLAIN, satisfy your
>     Simon> concern?  Then you'll have server authentication.
>
> If I have concerns they are assuming that this mechanism is only used
> with channel binding.  So, TLS or something similar.  I have huge
> concerns about the use of this mechanism outside of TLS, but I think
> Kurt does too.

Ok.  Then I don't understand the concern -- what risks are there in
running a hash-based authentication mechanism like YAP under TLS?

Assuming the channel binding is properly designed, it seems that the
"server challenge" is implicit in the channel binding that is input to
the HMAC in YAP.

My concern with YAP is the abuse of the HMAC construct: YAP puts the
password in the 'text' position rather in the 'key' position, and that
makes it more weird to analyze theoretically.  I think it would be
useful to get feedback from the crypto community on this (at least to
me) new way of using HMAC for authentication.

>     Simon> I believe we need a simple mechanism that doesn't transfer
>     Simon> passwords in the clear.  Since we've managed to kill both
>     Simon> DIGEST-MD5 and CRAM-MD5, there seems to be no option left
>     Simon> but to specify a new mech to achieve this.
>
> I think that mechanism should be scram or your password draft or
> something like that.  I consider yap to be a very specialized
> mechanism for cases where round trips are to be avoided at all costs.

I thought about incorporating the YAP idea of using a one-half-roundtrip
into the password draft, and didn't understand that there may be
concerns with the approach.

/Simon

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-zeilenga-sasl-yap-01
Date: Wed, 12 Sep 2007 07:31:50 -0400
Sender: [email-masked]

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

    Simon> Sam Hartman <[email-masked]> writes:
    >> Hi.  I just wanted to register that as an individual I'm having
    >> a really difficult time coming up with an opinion about the
    >> advisability of this mechanism.
    >> 
    >> It's all tied up in not having room for a server challenge.
    >> 
    >> I understand why you might want this mechanism as well.
    >> 
    >> So far, I have not been able to come up with an opinion on the
    >> balance of these tradeoffs.  It turns out that this same
    >> question is one I'm struggling with while working on revising
    >> my web phishing draft.
    >> 
    >> It is likely that if I decide that this draft is a bad idea,
    >> I'll have that opinion quite strongly.  I just wanted to give
    >> people a heads up that I might end up with strong objections.
    >> I hate to be surprised by negative reviews of my work and I
    >> would not want to do that to Kurt.

    Simon> Would dependence on TLS, similar as in PLAIN, satisfy your
    Simon> concern?  Then you'll have server authentication.

If I have concerns they are assuming that this mechanism is only used
with channel binding.  So, TLS or something similar.  I have huge
concerns about the use of this mechanism outside of TLS, but I think
Kurt does too.

    Simon> I believe we need a simple mechanism that doesn't transfer
    Simon> passwords in the clear.  Since we've managed to kill both
    Simon> DIGEST-MD5 and CRAM-MD5, there seems to be no option left
    Simon> but to specify a new mech to achieve this.

I think that mechanism should be scram or your password draft or
something like that.  I consider yap to be a very specialized
mechanism for cases where round trips are to be avoided at all costs.

Date: Wed, 12 Sep 2007 12:01:20 +0100
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Sender: [email-masked]

Frank Ellermann wrote:

>Alexey Melnikov wrote:
>  
>
>>Should the next revision be a WG document?
>>    
>>
>I like it.
>
Thanks.

>Maybe it should be a bit more specific
>about the interoperability issues:
>
>The (expired) I-D.smith-sipping-auth-examples-01
>discussed some of this.  And I _think_ that this
>I-D got its "md5-sess" examples wrong, compare
>http://purl.net/xyzzy/src/md5.cmd 
>  
>
I was debating with myself if the document should catalogue every 
possible issue, but decided against it. The main reason is that it in 
order to obsolete an RFC it is sufficient to name only major reasons why 
it is broken

Do other people think that the document should be more detailed?

>For RFC 4590 and 4590bis I'm also not sure what
>they implemented, is that some kind of DIGEST-MD5
>without cnonce ?  How is it computed ?
>  
>
I need to reread RFC 4590 to answer this question.

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-zeilenga-sasl-yap-01
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 12 Sep 2007 08:38:37 +0200
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

> Hi.  I just wanted to register that as an individual I'm having a
> really difficult time coming up with an opinion about the advisability
> of this mechanism.
>
> It's all tied up in not having room for a server challenge.
>
> I understand why you might want this mechanism  as well.
>
> So far, I have not been able to come up with an opinion on the balance
> of these tradeoffs.  It turns out that this same question is one I'm
> struggling with while working on revising my web phishing draft.
>
> It is likely that if I decide that this draft is a bad idea, I'll have
> that opinion quite strongly.  I just wanted to give people a heads up
> that I might end up with strong objections.  I hate to be surprised by
> negative reviews of my work and I would not want to do that to Kurt.

Would dependence on TLS, similar as in PLAIN, satisfy your concern?
Then you'll have server authentication.

I believe we need a simple mechanism that doesn't transfer passwords in
the clear.  Since we've managed to kill both DIGEST-MD5 and CRAM-MD5,
there seems to be no option left but to specify a new mech to achieve
this.

/Simon

From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: draft-zeilenga-sasl-yap-01
Date: Tue, 11 Sep 2007 21:26:38 -0400
Sender: [email-masked]

Hi.  I just wanted to register that as an individual I'm having a
really difficult time coming up with an opinion about the advisability
of this mechanism.

It's all tied up in not having room for a server challenge.

I understand why you might want this mechanism  as well.

So far, I have not been able to come up with an opinion on the balance
of these tradeoffs.  It turns out that this same question is one I'm
struggling with while working on revising my web phishing draft.

It is likely that if I decide that this draft is a bad idea, I'll have
that opinion quite strongly.  I just wanted to give people a heads up
that I might end up with strong objections.  I hate to be surprised by
negative reviews of my work and I would not want to do that to Kurt.

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
Subject: Re: draft-zeilenga-sasl-yap-01
Date: Tue, 11 Sep 2007 22:27:32 +0200
To: Tony Finch <[email-masked]>
Sender: [email-masked]

Thanks for the review.  Though I all double check things later (on  
the road now), your suggested changes all seem appropriate.  Just a  
couple of quick comments...

On Sep 11, 2007, at 9:36 PM, Tony Finch wrote:
>
> The security considerations section says "Use of the autchid as a  
> salt was
> considered, but rejected as it would tie the password equivalent to a
> particular authcid." I don't understand why that is an objection:

A single user might be known by different autchid strings.  For  
instance, I might be both kurt and KURT (and maybe even kdz and  
KDZ).  If you salt with the authcid, then the stored password  
equivalent is only useful with a single authcid for that user.

Adding a "For instance" here might be useful...

> isn't
> such a tie the whole point of salting in that way, so that users  
> with the
> same password have different authentication information in the  
> database?

The primary reason for salting is hinder dictionary attacks against  
the equivalent by dramatically increasing the size of pre-computed  
dictionaries of commonly used passwords.

A secondary reason is so that each user is more likely to have a  
different equivalent.  That is, if one is able to discover user A's  
password and A's and B's equivalent, salting obscures the fact that  
B's passwords is the same as A's from the attacker.  Of course,  
attackers are generally smart enough to just try A's password with  
against all users because password reuse is common enough.

>
> Am I allowed to pronounce is "yap-shah-two-five-six"? :-)

Sure.

Date: Tue, 11 Sep 2007 20:36:50 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: draft-zeilenga-sasl-yap-01
Sender: [email-masked]

The syntax in the draft is:

   message = authzid separator [ authcid ] separator data

Shouldn't it be the following?

   message = [authzid] separator authcid separator data

This is more consistent with PLAIN, and the subsequent text implies that
the authzid is optional and the authcid is not.

The security considerations section says "Use of the autchid as a salt was
considered, but rejected as it would tie the password equivalent to a
particular authcid." I don't understand why that is an objection: isn't
such a tie the whole point of salting in that way, so that users with the
same password have different authentication information in the database?
[It's a moot point since I agree with the other arguments against
salting.]

Typos:

"There exists multiple password-based methods"
-> "There exist multiple password-based mechanisms"

"YAP mechanisms reply on services"
-> "YAP mechanisms rely on services"

"YAP mechanisms requires"
-> "YAP mechanisms require"

"The YAP-* Family of mechanism"
-> "The YAP-* Family of mechanisms"

Should "unique channel binding" be singular or plural?

"utilize" -> "use"

"designed to reply on security services"
-> "designed to rely on security services"

"the client is to verify the server"
-> "the client must verify the server"

"autchid" -> authcid"

Am I allowed to pronounce is "yap-shah-two-five-six"? :-)

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Date:  Tue, 11 Sep 2007 12:52:05 +0200
Lines: 21
Sender: [email-masked]

Alexey Melnikov wrote:

> I've submitted the document I've promised to do.

Thanks.
=20
> Should the next revision be a WG document?

I like it.  Maybe it should be a bit more specific
about the interoperability issues:

The (expired) I-D.smith-sipping-auth-examples-01
discussed some of this.  And I _think_ that this
I-D got its "md5-sess" examples wrong, compare
http://purl.net/xyzzy/src/md5.cmd=20

For RFC 4590 and 4590bis I'm also not sure what
they implemented, is that some kind of DIGEST-MD5
without cnonce ?  How is it computed ?

Frank

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: cram-09 final(?) review
Date:  Tue, 11 Sep 2007 12:36:05 +0200
Lines: 45
Sender: [email-masked]

Lyndon Nerenberg wrote:
=20
> the CRAM v9 draft has been out for a couple of weeks now.
> If anyone has any remaining substantive comments on it,=20
> please speak now.

Hi, I've posted three objections back in March (2007-03-14):

<[email-masked]>=20
"prone to interoperability problem"=20

<[email-masked]>
"limited use"

<[email-masked]>
"MUST NOT interpret or attempt to validate the [...] challenge"

The first two objections could be resolved by simply removing
the last paragraph in the introduction.  The "MUST NOT" is at
odds with the idea of "challenge in the format of a Message-ID".

I've no clue why this new "non-interpretation" should be a MUST.

> I would like to see the document pushed to an IETF last call.

Yes, the interest here (=3D SASL) appears to be somewhat limited.
In section 5 (security considerations) you write "SHOULD NOT be
used unless".  If this upper case SHOULD NOT in the security
considerations is okay you could also use it in the preceding
paragraph:

s/should not allow both methods/SHOULD NOT allow both methods/

Or maybe it's better to avoid 2119 keywords in the security
considerations putting them elsewhere (?). =20

How about adding some kind of informtive reference for "CERT
Advisory CA-95:01", giving an URL ?

> It has been lingering for over five years now, and it's =20
> time we put it to bed.

+1, it's a stable and mature standard, easy to implement.

Frank

Date: Mon, 10 Sep 2007 15:47:46 -0700
From: Chris Newman <[email-masked]>
Subject: Re: [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

As a procedure nit, the document explaining why something is going to historic 
status is traditionally informational rather than proposed standard.

                - Chris

Alexey Melnikov wrote on 9/9/07 20:39 +0100:

> I've submitted the document I've promised to do.
>
> Should the next revision be a WG document?
>
>

To: [email-masked]
From: Lyndon Nerenberg <[email-masked]>
Subject: cram-09 final(?) review
Date: Mon, 10 Sep 2007 11:56:57 -0700
Sender: [email-masked]

Folks, the CRAM v9 draft has been out for a couple of weeks now.  If  
anyone has any remaining substantive comments on it, please speak  
now.  Otherwise I would like to see the document pushed to an IETF  
last call.  It has been lingering for over five years now, and it's  
time we put it to bed.

--lyndon

Date: Sun, 09 Sep 2007 20:39:03 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Sender: [email-masked]

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

I've submitted the document I've promised to do.

Should the next revision be a WG document?

--------------090609000207070005020602
Content-Type: message/rfc822;
 name="I-D Action:draft-melnikov-digest-to-historic-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D Action:draft-melnikov-digest-to-historic-00.txt"

To: [email-masked]
Cc: 
From: [email-masked]
Date: Sat, 08 Sep 2007 14:30:02 -0400
Subject: I-D Action:draft-melnikov-digest-to-historic-00.txt 
Reply-To: [email-masked]

--NextPart

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

	Title           : Moving DIGEST-MD5 to Historic
	Author(s)       : A. Melnikov
	Filename        : draft-melnikov-digest-to-historic-00.txt
	Pages           : 7
	Date            : 2007-09-08

This memo documents problems with the DIGEST-MD5 Simple
Authentication and Security Layer (SASL) mechanism, as specified in
RFC 2831.  This document recommends DIGEST-MD5 to be marked as
OBSOLETE in the IANA Registry of SASL mechanims and RFC 2831 to be
moved to Historic status.Note

A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community.  Discussion
and suggestions for improvement are requested, and should be sent to
[email-masked].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-digest-to-historic-00.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-melnikov-digest-to-historic-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-melnikov-digest-to-historic-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-melnikov-digest-to-historic-00.txt

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

Content-Type: text/plain
Content-ID: <2007-09-08142143.I-D\@ietf.org>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--------------090609000207070005020602--

Date: Fri, 07 Sep 2007 14:51:32 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>, [email-masked]
cc: Jeffrey Hutzelman <[email-masked]>
Subject: Re: draft-ietf-sasl-gs2 AD review comments
Originator-Info: login-token=Mulberry:01cmXRntzNRhK+sEkfpeMBDQnXCMn5mUrf2v8DqOU=; token_authority=[email-masked]
Sender: [email-masked]

On Thursday, September 06, 2007 09:08:49 PM -0400 Sam Hartman 
<[email-masked]> wrote:

> Section 14 recommends specification of SPNEGO for SASL but section 12
> forbids that mechanism.
> Please clarify.

Section 12 prohibits the use of SPNEGO with GS2 for good reason.  The 
multi-level negotiation problem is at this point well-understood, and in 
fac that section does a reasonable job of explaining it.

While the use of SPNEGO protects negotiation among several GSS-API 
mechanisms, it does not protect negotiation between GSS-API and non-GSS-API 
SASL mechanisms, or "GSSAPI" vs GS2, or the selection of SPNEGO itself.  In 
fact, not only does it introduce a multi-level negotation problem; that 
problem effectively prevents the use of SPNEGO from resolving the problem 
for which section 14 recommends it.

As Sam points out, the preferred solution to this problem is the one 
recommended by RFC4422; namely, obtaining a list of supported mechanisms 
after a security layer has been established, and verifying that the 
integrity-protected list does not contain a stronger mutually-supported 
mechanism than was selected.  This is functionally equivalent to what 
SPNEGO does, except that it applies directly to the SASL mechanism 
negotation, rather than to some sub-negotiation, thus avoiding the 
multi-level negotation problem described in section 12.

-- Jeff

From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: draft-ietf-sasl-gs2 AD review comments
Date: Thu, 06 Sep 2007 21:08:49 -0400
Sender: [email-masked]

The draft looks quite good, but there are a few things that need to be
resolved before I can last call it.

Section 5:
This violates the requirement from draft-williams-on-channel-binding section 2 that applications be notified  of channel binding failure.

It also appears to violate the requirement that the name of the
channel type be used in the channel binding data.

Section 4 claims that one of the context_token or wrap_token lengths
will be non-null.  Section 6 gives an example of a case where the
server sends a message with empty wrap and context tokens.  Is this
perhaps intended to be an empty challenge?  Perhaps examining section
3.6 in RFC 4422 and aligning gs2 with itself is a good next step.

Section 6 seems to include examples where server last gs2_wrap includes a channel binding length.
I don't see that in section 4.

Section 7 says the minimum token length is 4 octets; section 4 says 8.
Please align.

Section 14 recommends specification of SPNEGO for SASL but section 12
forbids that mechanism.
Please clarify.

Section 14 leaves out the preferred solution to avoid bid-down attacks
in SASL; see section 6.1.2 of RFC 4422.
 I await a revised draft addressing these concerns.