Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Tue, 23 Oct 2007 11:08:01 -0400 (EDT)
List-Id: <ietf-sasl.imc.org>

On Mon, 22 Oct 2007, Nicolas Williams wrote:

> On Mon, Oct 22, 2007 at 07:26:04PM -0400, Sam Hartman wrote:
> > I just had a quick phone call with Nico.
> >
> >
> > He's still been thinking about this from the API standpoint.  I was
> > asking him why we wanted to support separate slots in the protocol for
> > channel binding type and channel binding data.I didn't understand the
> > complexity.  During the conversation it became clear that Nico
> > believed that at the end of the day you want to end up with a channel
> > binding type, a colon and some stuff.  I like that too.  I don't care
> > how it works in the API at all.
> >
> >
> > I propose  we accomplish this by adding the following requirement:
> >
> > "Under this framework, channel bindings MUST start with the channel
> > binding unique prefix followed by a colon (ASCII 0x3A).
> > "
>
> I second this.  Note: Sam's text should be added to either the third
> bullet item in page 7, or as a separate item below it.

Works for me.

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Nicolas Williams <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Date: Tue, 23 Oct 2007 09:17:22 -0400
Sender: [email-masked]

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

    Simon> Sam Hartman <[email-masked]> writes:
    >> I just had a quick phone call with Nico.
    >> 
    >> 
    >> He's still been thinking about this from the API standpoint.  I
    >> was asking him why we wanted to support separate slots in the
    >> protocol for channel binding type and channel binding data.I
    >> didn't understand the complexity.  During the conversation it
    >> became clear that Nico believed that at the end of the day you
    >> want to end up with a channel binding type, a colon and some
    >> stuff.  I like that too.  I don't care how it works in the API
    >> at all.
    >> 
    >> 
    >> I propose we accomplish this by adding the following
    >> requirement:
    >> 
    >> "Under this framework, channel bindings MUST start with the
    >> channel binding unique prefix followed by a colon (ASCII 0x3A).
    >> "

    Simon> I like it.

    Simon> Is it specified that the channel binding unique prefix
    Simon> cannot contain ASCII 0x3a?

Yes.
alphanum plus '.' and '-'

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Nicolas Williams <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 23 Oct 2007 11:40:32 +0200
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

> I just had a quick phone call with Nico.
>
>
> He's still been thinking about this from the API standpoint.  I was
> asking him why we wanted to support separate slots in the protocol for
> channel binding type and channel binding data.I didn't understand the
> complexity.  During the conversation it became clear that Nico
> believed that at the end of the day you want to end up with a channel
> binding type, a colon and some stuff.  I like that too.  I don't care
> how it works in the API at all.
>
>
> I propose  we accomplish this by adding the following requirement:
>
> "Under this framework, channel bindings MUST start with the channel
> binding unique prefix followed by a colon (ASCII 0x3A).
> "

I like it.

Is it specified that the channel binding unique prefix cannot contain
ASCII 0x3a?

/Simon

Date: Tue, 23 Oct 2007 09:48:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked], [email-masked], Nicolas Williams <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Sender: [email-masked]

Sam Hartman wrote:

>I just had a quick phone call with Nico.
>
>
>He's still been thinking about this from the API standpoint.  I was
>asking him why we wanted to support separate slots in the protocol for
>channel binding type and channel binding data.I didn't understand the
>complexity.  During the conversation it became clear that Nico
>believed that at the end of the day you want to end up with a channel
>binding type, a colon and some stuff.  I like that too.  I don't care
>how it works in the API at all.
>
>
>I propose  we accomplish this by adding the following requirement:
>
>"Under this framework, channel bindings MUST start with the channel
>binding unique prefix followed by a colon (ASCII 0x3A).
>"
>  
>
I like this.

Date: Mon, 22 Oct 2007 18:31:50 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Mail-Followup-To: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Mon, Oct 22, 2007 at 07:26:04PM -0400, Sam Hartman wrote:
> I just had a quick phone call with Nico.
> 
> 
> He's still been thinking about this from the API standpoint.  I was
> asking him why we wanted to support separate slots in the protocol for
> channel binding type and channel binding data.I didn't understand the
> complexity.  During the conversation it became clear that Nico
> believed that at the end of the day you want to end up with a channel
> binding type, a colon and some stuff.  I like that too.  I don't care
> how it works in the API at all.
> 
> 
> I propose  we accomplish this by adding the following requirement:
> 
> "Under this framework, channel bindings MUST start with the channel
> binding unique prefix followed by a colon (ASCII 0x3A).
> "

I second this.  Note: Sam's text should be added to either the third
bullet item in page 7, or as a separate item below it.

NOTE: draft-williams-on-channel-binding is now in AUTH48.

Nico
-- 

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Nicolas Williams <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Date: Mon, 22 Oct 2007 19:26:04 -0400
Sender: [email-masked]

I just had a quick phone call with Nico.

He's still been thinking about this from the API standpoint.  I was
asking him why we wanted to support separate slots in the protocol for
channel binding type and channel binding data.I didn't understand the
complexity.  During the conversation it became clear that Nico
believed that at the end of the day you want to end up with a channel
binding type, a colon and some stuff.  I like that too.  I don't care
how it works in the API at all.

I propose  we accomplish this by adding the following requirement:

"Under this framework, channel bindings MUST start with the channel
binding unique prefix followed by a colon (ASCII 0x3A).
"

From: Simon Josefsson <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: [email-masked]
Subject: Re: updated charter proposal
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 15 Oct 2007 11:50:47 +0200
Sender: [email-masked]

Tom Yu <[email-masked]> writes:

> This group will deliver a revised Technical Specification suitable for
> publication as Proposed Standard for the GSS-API family of SASL
> mechanisms. This work will be based upon draft-ietf-sasl-gs2.

There wasn't a milestone/goal for GS2, how about adding:

OCT 2007        GS2 to IESG

?

/Simon

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: updated charter proposal
Date:  Mon, 15 Oct 2007 10:37:32 +0200
Lines: 14
Sender: [email-masked]

Tom Yu wrote:
=20
> I think we mostly have consensus on the WG description

I miss the SASLPREP update / clarification for RFC 2195,
I-D.ietf-sasl-crammd5.

And I vaguely recall that there were three drafts in the
direction of "apr1" and "digest-md5 replacement", SCRAM
+ HEXA + YAP.  Apparently the proposed charter only covers
the future SCRAM + HEXA union, what about YAP ?

 Frank

To: [email-masked]
Subject: updated charter proposal
From: Tom Yu <[email-masked]>
Date: Fri, 12 Oct 2007 20:04:06 -0400
Lines: 80
Sender: [email-masked]

I think we mostly have consensus on the WG description, but the
milestones may require tweaking.  (We are slightly past due on at
least one of them.)  If people think it's ok to leave the milestones
along, I will issue a WG Last Call for the charter proposal.

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

Simple Authentication and Security Layer (sasl)

Additional information is available at tools.ietf.org/wg/sasl
Chair(s):
# Kurt Zeilenga <[email-masked]>
# Tom Yu <[email-masked]>

Security Area Director(s):
# Tim Polk <[email-masked]>
# Sam Hartman <[email-masked]>

Security Area Advisor:
# Sam Hartman <[email-masked]>

Mailing Lists:
General Discussion: [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 [RFC4422] 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 work to progress the SASL Technical Specification
toward Draft Standard.

This group will produce a document moving DIGEST-MD5 to Historic
status.  This group will also deliver a Technical Specification for a
password-based SASL mechanism to replace DIGEST-MD5.  In particular,
this specification will not transmit plaintext passwords (even if
encrypted), but will require less infrastructure than typical GSS-API
mechanisms.  This group will attempt to specify this new mechanism so
that it is a valid member of the SASL GS2 family of mechanisms, but
lightweight enough to implement in the form of a native SASL mechanism
without requiring a full GSS-API implementation.

This group will deliver a revised Technical Specification suitable for
publication as Proposed Standard for the GSS-API family of SASL
mechanisms. This work will be based upon draft-ietf-sasl-gs2.

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:

Done            initial document moving DIGEST-MD5 to Historic
Sep 2007        WGLC document moving DIGEST-MD5 to Historic
Oct 2007        initial implementation report questionnaire
Oct 2007        initial RFC4422bis correcting references, etc.
Oct 2007        initial document for DIGEST-MD5 successor
Nov 2007        DIGEST-MD5 to Historic to IESG
Jan 2008        send out implementation report questionnaire
Feb 2008        compile implementation report questionnaire responses
Feb 2008        WGLC RFC4422bis
Feb 2008        WGLC DIGEST-MD5 successor
Mar 2008        discuss implementation report questionnaire results
Apr 2008        final implementation report
Apr 2008        RFC4422bis to IESG
Apr 2008        DIGEST-MD5 successor to IESG

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Sam Hartman <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 12 Oct 2007 12:06:38 +0200
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> On Thu, 11 Oct 2007, Nicolas Williams wrote:
>
>> On Thu, Oct 11, 2007 at 01:28:07PM -0400, Jeffrey Hutzelman wrote:
>> > This sort of assumes that the "obvious" thing to do is prfix the name to
>> > the data, rather than treating them separately.  That sssumption seems
>> > flawed to me, and the source of much confusion.
>>
>> Did you miss this part of my reply to Sam:
>>
>> Nico> I propose the following addition to that requirement:  "Where the
>> Nico> authentication interfaces provide a slot for channel binding data but no
>> Nico> slot for channel binfing type, then the application MUST prefix the
>> Nico> US-ASCII name of the channel binding type ("prefix"), and a separator
>> Nico> character, ':', to the channel binding data an octet string."
>
> I saw that; I just forgot to say anything.  That basically sounds like my
> option (2).  I think that's probably sufficient.  Simon?

It is a starting point, but the proposed text appears to use incorrect
terminology.  Section 7.1 in on-channel-binding says:

   o  Subject: Registration of channel binding X

   o  Channel binding unique prefix (name):

   o  Channel binding type: (One of "unique" or "end-point")

   o  Channel type: (E.g., TLS, IPsec, SSH, etc...)

>From that I infer that:

  channel binding unique prefix = channel binding name

  channel binding type = either 'unqiue' or 'end-point'

  channel type = not an octet string, but a reference to other
    authentication protocols (e.g., TLS RFC 4346).

The proposed text above seem to claim that the channel binding type is
the prefix, which seems incorrect.  I also wonder whether it doesn't
mean 'channel binding unique prefix' rather than 'channel binfing type'.
There is also a spurious 'an' at the end.

I suggest modified text:

  Where the authentication interfaces provide a slot for channel binding
  data but no slot for the channel binding name (i.e., the unique
  prefix), then the application MUST prefix the US-ASCII name of the
  channel binding name (i.e., the unique prefix), and a separator
  character, ':', to the channel binding data octet string.

However, I continue to doubt that anyone that did not read mailing list
discussions about these fine points will be able to do the right thing
when reading the on-channel-bindings document.  The terminology
definitions we are basing this discussion is in the IANA Considerations!
They aren't used earlier in the document.  I think they should be in
section 2, and used throughout the document.  That may be sufficient to
make things understandable.

/Simon

Date: Thu, 11 Oct 2007 13:51:23 -0400 (EDT)
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Sam Hartman <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Sender: [email-masked]

On Thu, 11 Oct 2007, Nicolas Williams wrote:

> On Thu, Oct 11, 2007 at 01:28:07PM -0400, Jeffrey Hutzelman wrote:
> > This sort of assumes that the "obvious" thing to do is prfix the name to
> > the data, rather than treating them separately.  That sssumption seems
> > flawed to me, and the source of much confusion.
>
> Did you miss this part of my reply to Sam:
>
> Nico> I propose the following addition to that requirement:  "Where the
> Nico> authentication interfaces provide a slot for channel binding data but no
> Nico> slot for channel binfing type, then the application MUST prefix the
> Nico> US-ASCII name of the channel binding type ("prefix"), and a separator
> Nico> character, ':', to the channel binding data an octet string."

I saw that; I just forgot to say anything.  That basically sounds like my
option (2).  I think that's probably sufficient.  Simon?

-- Jeff

Date: Thu, 11 Oct 2007 12:31:53 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, Oct 11, 2007 at 01:28:07PM -0400, Jeffrey Hutzelman wrote:
> This sort of assumes that the "obvious" thing to do is prfix the name to
> the data, rather than treating them separately.  That sssumption seems
> flawed to me, and the source of much confusion.

Did you miss this part of my reply to Sam:

Nico> I propose the following addition to that requirement:  "Where the
Nico> authentication interfaces provide a slot for channel binding data but no
Nico> slot for channel binfing type, then the application MUST prefix the
Nico> US-ASCII name of the channel binding type ("prefix"), and a separator
Nico> character, ':', to the channel binding data an octet string."

?

Date: Thu, 11 Oct 2007 13:28:07 -0400 (EDT)
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Sam Hartman <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Sender: [email-masked]

On Thu, 11 Oct 2007, Nicolas Williams wrote:

> > However we could be neutral on whether applications need one slot or
> > two.  If so, we need to at least say that we're neutral on this.  I
> > think we need to at least define a separator to use when you only have
> > one slot.
>
> That's my position.  However, if the consensus is that we should take a
> less neutral position on this then I would propose this text:

I'm fine with taking a neutral position, just not an unclear one. The
problem I see today is that an application protocol designer may assume
that the channel bindign data is self-identifying; that is, that the
base channel binding document describes a single octet string containing
the prefix.  But the present document does _not_ describe a single octet
string; it describes a prefix and an octet string separately, and does not
specify how to combine them, except by calling the one a "prefix", which
is just vague enough to convince the casual reader that it's obvious what
to do.  After all, we didn't notice the problem until Simon tried to
define an application, and he's probably more aware of the issue than
most.

So, I think we need to do one of three things:

(1) Require that the prefix and data always be combined in a particular
    way, resulting in a single octet string for the application to work
    with(*).

(2) Specify a particular way of combining the prefix and data, for use
    when the application wants or needs to work with a single octet
    string.  Indicate that it is up to the application whether to use
    this method or treat the prefix and data separately.

(3) Clearly indicate that the prefix and data are separate, and that
    it is up to the application whether to handle them separately or
    together.

Especially in case (3), I think a lot of the ambiguity can be removed by
not using the word "prefix", which implies a particular approach to
combining what are really two separate protocol elements.  This usage
seems to be an artifact of how channel bindings are expected to be
transported in GSS-API and not really something that belongs in a generic
document.

>    o In the interests of simplicity it is RECOMMENDED that
>      authentication framework/mechanism APIs provide a single slot for
>      channel binding data, and none for the name of channel binding
>      type.
>
> If we want to stay neutral on this issue we can always add this text:
>
>    o Authentication framework/mechanism APIs MAY provide a slot for name
>      of channel binding type that is distinct from a slot for channel
>      binding data.  In that case applications MUST NOT prefix the name
>      of the channel binding type to the channel binding data and MUST
>      instead provide the name of the channel binding type as an input in
>      the correct slot.

This sort of assumes that the "obvious" thing to do is prfix the name to
the data, rather than treating them separately.  That sssumption seems
flawed to me, and the source of much confusion.

-- Jeff

Date: Thu, 11 Oct 2007 12:10:12 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Mail-Followup-To: Sam Hartman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, Oct 11, 2007 at 12:33:21PM -0400, Sam Hartman wrote:
> I've become convinced that clarification is needed.
> I'll note that it's simpler if we say there is always one slot and that the
> 	challeng binding data includes the prefix and the separator.

Sure.

There already is a requirement that the name of the channel binding type
must be used to avoid ambiguity (3rd bullet, page 7).

I propose the following addition to that requirement:  "Where the
authentication interfaces provide a slot for channel binding data but no
slot for channel binfing type, then the application MUST prefix the
US-ASCII name of the channel binding type ("prefix"), and a separator
character, ':', to the channel binding data an octet string."

> I think that option is most likely to be interoperable.

The risk in not giving this guidance is that some apps/frameworks will
get this wrong.  I'm not sure that there's risk to interoperability, but
there's no need to argue about that.

> One down side of that option is that there may be people using channel
> bindings with GSS today in a manner that differs from that.

Tough.  But then, there aren't many of them.  Also, the ambiguity is
extremely unlikely to cause any problems, except in nested channel
circumstances.

> It probably is not a big deal since any given application will either
> use this framework or not.

Right.

> However we could be neutral on whether applications need one slot or
> two.  If so, we need to at least say that we're neutral on this.  I
> think we need to at least define a separator to use when you only have
> one slot.

That's my position.  However, if the consensus is that we should take a
less neutral position on this then I would propose this text:

   o In the interests of simplicity it is RECOMMENDED that
     authentication framework/mechanism APIs provide a single slot for
     channel binding data, and none for the name of channel binding
     type.

If we want to stay neutral on this issue we can always add this text:

   o Authentication framework/mechanism APIs MAY provide a slot for name
     of channel binding type that is distinct from a slot for channel
     binding data.  In that case applications MUST NOT prefix the name
     of the channel binding type to the channel binding data and MUST
     instead provide the name of the channel binding type as an input in
     the correct slot.

Nico
-- 

From: Sam Hartman <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Date: Thu, 11 Oct 2007 12:33:21 -0400
Sender: [email-masked]

    >> Provided we clarify in draft-williams-on-channel-bindings that
    >> channel binding data includes the prefix, there is no problem
    >> with the protocol bits in GS2.  However, you are missing a
    >> requirement to check that the channel binding data sent by the
    >> client and server is actually the same.  In fact, you provide
    >> virtually no information on what to do with the data elements
    >> related to channel binding.  I think this needs some work.

To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>,  [email-masked],  [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
References: <[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]>
X-Draft-From: ("inbox.ietf.personal" 24575)
    Nicolas> I now believe that no such clarification is needed.  We
    Nicolas> may want to clarify that application protocols using
    Nicolas> channel binding must specify how the prefix is used, and
    Nicolas> we may want to suggest using it as, well, a prefix (with
    Nicolas> a separator character), in those cases where a single
    Nicolas> string is accepted by the authentication
    Nicolas> framework/mechanism.

I've become convinced that clarification is needed.
I'll note that it's simpler if we say there is always one slot and that the
	challeng binding data includes the prefix and the separator.
I think that option is most likely to be interoperable.
One down side of that option is that there may be people using channel
	bindings with GSS today in a manner that differs from that.
It probably is not a big deal since any given application will either use this framework or not.

However we could be neutral on whether applications need one slot or two.
If so, we need to at least say that we're neutral on this.
I think we need to at least define a separator to use when you only have one
	slot.

Date: Thu, 11 Oct 2007 10:10:15 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Oct 10, 2007 at 01:52:20PM -0400, Jeffrey Hutzelman wrote:
> On Wednesday, October 10, 2007 06:38:11 PM +0200 Simon Josefsson 
> <[email-masked]> wrote:
> >No, it wasn't about APIs, it was about what is sent in the
> >"channel_binding_data" field over the wire.  If the current text in GS2
> >is not sufficient to build interoperable implementations, I'd appreciate
> >suggestions on what it has to say.

The on-channel-binding I-D doesn't say that the channel binding data is
sent -- there is not "channel_binding_data field" as such.  The
authentication mechanism must verify that the channel bindings match on
both ends, but that need not mean sending the channel binding data.

> Well, you brought up the question of whether the channel binding data 
> includes the prefix or not, and that's what we've been discussing.  So yes, 
> the document is insufficiently clear.  But the length of the ensuing 
> discussion does not mean that there is a major flaw; it just means that 
> we've examined the issue carefully before determining what it should say. 
> Now there will be additional discussion to determine how it should say it.

I'm not sure that there's any ambiguity:

      *  The name of the type of channel binding MUST be used by the
	 application and/or authentication protocol to avoid ambiguity
	 about which of several possible types of channels is being
	 bound.  If nested instances of the same type of channel are
	 available then the innermost channel MUST be used.

Now, GS2 *could* have a separate "slot" in the protocol for "channel
binding type name" and "channel binding data."  The GSS-API, OTOH, does
not provide such a slot, so GSS applications MUST prefix the channel
binding type name to the channel binding data in order to obtain a
single octet string that can be passed to GSS_Init_sec_context() or
GSS_Accept_sec_context().

So I think we really don't want to make any changes here.  Simon and the
SASL WG need to decide whether GS2 needs such a separate slot.  The
on-channel-bindings I-D is neutral on that issue.

Also, GS2 need not say who is responsible for determining the channel
binding data and type.  You could have a fully integrated channel and
authentication API that hides all these details from the application,
but you could also have disparate and unrelated channel and
authentication APIs, in which case the application is responsible for
determining the channel binding data and type.  Both are equally
acceptable, so on-channel-binding says nothing about them.

> Provided we clarify in draft-williams-on-channel-bindings that channel 
> binding data includes the prefix, there is no problem with the protocol 
> bits in GS2.  However, you are missing a requirement to check that the 
> channel binding data sent by the client and server is actually the same. 
> In fact, you provide virtually no information on what to do with the data 
> elements related to channel binding.  I think this needs some work.

I now believe that no such clarification is needed.  We may want to
clarify that application protocols using channel binding must specify
how the prefix is used, and we may want to suggest using it as, well, a
prefix (with a separator character), in those cases where a single
string is accepted by the authentication framework/mechanism.

Nico
-- 

Date: Wed, 10 Oct 2007 13:52:20 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Sam Hartman <[email-masked]>
cc: [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Originator-Info: login-token=Mulberry:01risBqxiTdh/6dnks4akxGkWdONY1X3oboC8Q5Ks=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, October 10, 2007 06:38:11 PM +0200 Simon Josefsson 
<[email-masked]> wrote:

> Nicolas Williams <[email-masked]> writes:
>
>> On Wed, Oct 10, 2007 at 10:55:52AM -0400, Sam Hartman wrote:
>>>     Nicolas> I believe the text of the I-D is clear on the above.
>>>     Nicolas> Thus your protocol issues are taken care of.
>>>
>>> Well, my reading of the ID is that the protocol needs two slots--one
>>> for a prefix and one for a channel binding octec string.  Simon is
>>> arguing that we only want to have one slot.
>>> I'm fine with that if we want to make that change.
>>
>> I don't agree.  The I-D is clear on channel bindings being a single
>> octet string.  The prefix is a US-ASCII string prefixed to the raw
>> channel binding octet string.  After the prefix is added you still have
>> a single octet string.
>
> Right.  However, I think the document is unclear that the channel
> binding name and the unique prefix must be the same string.  The only
> reason I am fairly certain that they are actually intended to be the
> same has been this discussion, not the document.

I think section 7.1 makes it fairly clear that a channel binding is named 
by its prefix:

   o  Channel binding unique prefix (name):

> No, it wasn't about APIs, it was about what is sent in the
> "channel_binding_data" field over the wire.  If the current text in GS2
> is not sufficient to build interoperable implementations, I'd appreciate
> suggestions on what it has to say.

Well, you brought up the question of whether the channel binding data 
includes the prefix or not, and that's what we've been discussing.  So yes, 
the document is insufficiently clear.  But the length of the ensuing 
discussion does not mean that there is a major flaw; it just means that 
we've examined the issue carefully before determining what it should say. 
Now there will be additional discussion to determine how it should say it.

I don't think draft-williams-on-channel-binding needs to specifically 
provide advice to frameworks, as opposed to applications.  Any user of 
channel bindings is an "application" as far as this document is concerned, 
and there are quite a number of requirements on those.  As designer of a 
framework, or at least part of one, it is up to you to determine which of 
these requirements to help applications meet and how best to do so.  For 
example, for SASL it is probably best to provide integrity-protected 
transport of channel bindings and verify that both ends agree on what the 
bindings are, but leave it up to the application to verify that the channel 
binding data describes the channel that is actually in use.

Provided we clarify in draft-williams-on-channel-bindings that channel 
binding data includes the prefix, there is no problem with the protocol 
bits in GS2.  However, you are missing a requirement to check that the 
channel binding data sent by the client and server is actually the same. 
In fact, you provide virtually no information on what to do with the data 
elements related to channel binding.  I think this needs some work.

-- Jeff

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 10 Oct 2007 18:58:45 +0200
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
>
>     Nicolas> On Wed, Oct 10, 2007 at 10:55:52AM -0400, Sam Hartman
>     Nicolas> wrote: I believe the text of the I-D is clear on the
>     Nicolas> above.  Thus your protocol issues are taken care of.
>     >>  Well, my reading of the ID is that the protocol needs two
>     >> slots--one for a prefix and one for a channel binding octec
>     >> string.  Simon is arguing that we only want to have one slot.
>     >> I'm fine with that if we want to make that change.
>
>     Nicolas> I don't agree.  The I-D is clear on channel bindings
>     Nicolas> being a single octet string.  The prefix is a US-ASCII
>     Nicolas> string prefixed to the raw channel binding octet string.
>     Nicolas> After the prefix is added you still have a single octet
>     Nicolas> string.
>
> O, I think Simon and I thought it was called a prefix because we
> expected it to be prefixed in a lot of protocols.  I don't read the
> current text that way at all.
>
> I think Simon, Jeff and I would be happy if the draft did actually say
> that.
> Simon, would you be willing to propose a change?

I'm confused by the on-channel-binding document and I'm not convinced
any minor change would have made the document clearer to me.

What I'm looking for is a recipe to reference on-channel-binding in an
authentication protocol like GS2.  GS2 wants to bind authentication to a
secure channel such as TLS.  That seems to be a fairly simple and common
way to use the on-channel-binding document (or?) so the length of this
discussion, and the lack of specific suggestions for GS2, suggest to me
that something is missing from the channel binding document.

What I'm looking for is something like this:

  X. Requirements On Frameworks That Use Channel Bindings

  Frameworks that wish to utilize a channel binding mechanism by
  referencing this document MUST transfer both the channel binding name
  (the unique prefix) and the channel binding data.  This MAY be done by
  concatenating the two strings.

/Simon

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 10 Oct 2007 18:38:11 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Oct 10, 2007 at 10:55:52AM -0400, Sam Hartman wrote:
>>     Nicolas> I believe the text of the I-D is clear on the above.
>>     Nicolas> Thus your protocol issues are taken care of.
>> 
>> Well, my reading of the ID is that the protocol needs two slots--one
>> for a prefix and one for a channel binding octec string.  Simon is
>> arguing that we only want to have one slot.
>> I'm fine with that if we want to make that change.
>
> I don't agree.  The I-D is clear on channel bindings being a single
> octet string.  The prefix is a US-ASCII string prefixed to the raw
> channel binding octet string.  After the prefix is added you still have
> a single octet string.

Right.  However, I think the document is unclear that the channel
binding name and the unique prefix must be the same string.  The only
reason I am fairly certain that they are actually intended to be the
same has been this discussion, not the document.

> Simon's issue, I thought, was about API slots.

No, it wasn't about APIs, it was about what is sent in the
"channel_binding_data" field over the wire.  If the current text in GS2
is not sufficient to build interoperable implementations, I'd appreciate
suggestions on what it has to say.

/Simon

Date: Wed, 10 Oct 2007 11:03:00 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Mail-Followup-To: Sam Hartman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Oct 10, 2007 at 11:58:10AM -0400, Sam Hartman wrote:
> If you want to send text that's fine.  I was asking Simon because I
> thought you were relatively busy.

True.  Yes, Simon, do suggest text please :)

From: Sam Hartman <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Date: Wed, 10 Oct 2007 11:58:10 -0400
Sender: [email-masked]

If you want to send text that's fine.  I was asking Simon because I
thought you were relatively busy.

From: Sam Hartman <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Date: Wed, 10 Oct 2007 11:53:50 -0400
Sender: [email-masked]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Oct 10, 2007 at 10:55:52AM -0400, Sam Hartman
    Nicolas> wrote: I believe the text of the I-D is clear on the
    Nicolas> above.  Thus your protocol issues are taken care of.
    >>  Well, my reading of the ID is that the protocol needs two
    >> slots--one for a prefix and one for a channel binding octec
    >> string.  Simon is arguing that we only want to have one slot.
    >> I'm fine with that if we want to make that change.

    Nicolas> I don't agree.  The I-D is clear on channel bindings
    Nicolas> being a single octet string.  The prefix is a US-ASCII
    Nicolas> string prefixed to the raw channel binding octet string.
    Nicolas> After the prefix is added you still have a single octet
    Nicolas> string.

O, I think Simon and I thought it was called a prefix because we
expected it to be prefixed in a lot of protocols.  I don't read the
current text that way at all.

I think Simon, Jeff and I would be happy if the draft did actually say
that.
Simon, would you be willing to propose a change?

Date: Wed, 10 Oct 2007 10:53:27 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Oct 10, 2007 at 11:51:03AM -0400, Jeffrey Hutzelman wrote:
> On Wed, 10 Oct 2007, Nicolas Williams wrote:
> > I don't agree.  The I-D is clear on channel bindings being a single
> > octet string.  The prefix is a US-ASCII string prefixed to the raw
> > channel binding octet string.  After the prefix is added you still have
> > a single octet string.
> 
> Ah, but the spec doesn't actually _say_ that.  It doesn't actually say
> anywhere that the prefix is prepended to the channel-specific binding
> data, resulting in a single octet string for the application to transport.
> On the other hand, it _does_ say that the application needs to distinguish
> channel types based on the prefix, which suggests (but only suggests) that
> they are treated as separate items.

Well, OK, we can clarify that.

> If it's a single string, then you need a separator, for two reasons:
> 
> - Without it, it's not good enough for prefixes to be unique; it must be
>   the case that no prefix is an initial substring of another.
> 
> - Without a separator, it is difficult for the application (or library)
>   to separate the prefix from the data, which it must do in order to
>   determine the channel type, which affects interpretation of the data.
> 
> Of course, one could use another approach, like a counted string, or a
> fixed-width field, or a fixed-size integer.  I don't care much.

Sure.

I'll send text this afternoon.

Nico
-- 

Date: Wed, 10 Oct 2007 11:51:03 -0400 (EDT)
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Sam Hartman <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Sender: [email-masked]

On Wed, 10 Oct 2007, Nicolas Williams wrote:

> On Wed, Oct 10, 2007 at 10:55:52AM -0400, Sam Hartman wrote:
> >     Nicolas> I believe the text of the I-D is clear on the above.
> >     Nicolas> Thus your protocol issues are taken care of.
> >
> > Well, my reading of the ID is that the protocol needs two slots--one
> > for a prefix and one for a channel binding octec string.  Simon is
> > arguing that we only want to have one slot.
> > I'm fine with that if we want to make that change.
>
> I don't agree.  The I-D is clear on channel bindings being a single
> octet string.  The prefix is a US-ASCII string prefixed to the raw
> channel binding octet string.  After the prefix is added you still have
> a single octet string.

Ah, but the spec doesn't actually _say_ that.  It doesn't actually say
anywhere that the prefix is prepended to the channel-specific binding
data, resulting in a single octet string for the application to transport.
On the other hand, it _does_ say that the application needs to distinguish
channel types based on the prefix, which suggests (but only suggests) that
they are treated as separate items.

If it's a single string, then you need a separator, for two reasons:

- Without it, it's not good enough for prefixes to be unique; it must be
  the case that no prefix is an initial substring of another.

- Without a separator, it is difficult for the application (or library)
  to separate the prefix from the data, which it must do in order to
  determine the channel type, which affects interpretation of the data.

Of course, one could use another approach, like a counted string, or a
fixed-width field, or a fixed-size integer.  I don't care much.

> Simon's issue, I thought, was about API slots.

I suppose we should let Simon speak for himself, but I believe his issue
was about supporting channel bindings in SASL-GS2.

Date: Wed, 10 Oct 2007 10:41:16 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Mail-Followup-To: Sam Hartman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Oct 10, 2007 at 10:55:52AM -0400, Sam Hartman wrote:
>     Nicolas> I believe the text of the I-D is clear on the above.
>     Nicolas> Thus your protocol issues are taken care of.
> 
> Well, my reading of the ID is that the protocol needs two slots--one
> for a prefix and one for a channel binding octec string.  Simon is
> arguing that we only want to have one slot.
> I'm fine with that if we want to make that change.

I don't agree.  The I-D is clear on channel bindings being a single
octet string.  The prefix is a US-ASCII string prefixed to the raw
channel binding octet string.  After the prefix is added you still have
a single octet string.

Simon's issue, I thought, was about API slots.

Nico
-- 

Date: Wed, 10 Oct 2007 10:39:18 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked], [email-masked], Sam Hartman <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked], Sam Hartman <[email-masked]>
Sender: [email-masked]

On Wed, Oct 10, 2007 at 11:16:00AM -0400, Jeffrey Hutzelman wrote:
> On Wed, 10 Oct 2007, Nicolas Williams wrote:
> 
> > The more I think about the who's-responsible-for-prefixing issue the
> > more I realize that the I-D shouldn't speak to that issue.  I could see
> > an operating system where all channels report channel bindings with the
> > prefix already included, another where only some do, and another where
> > none do -- but in all cases the applications can deal and interop
> > provided that the applications know which channels include the prefix
> > when and which don't.
> 
> Again, I don't care what the operating system or the library does.  Of
> course the document should not speak to that; focusing on API issues
> rather than protocol issues misses the point, which is that independent
> implementations be able to interoperate.

Part of the point of the e-mail to which you're replying was to take the
focus off APIs.

> What I _do_ care about is that it's clear in every case what the bits are
> supposed to look like on the wire and what the application protocol
> specification is responsible for doing.  If the application protocol is
> supposed to provide a single slot which will contain the prefix followed
> by the channel binding data, then say so, and specify exactly how they are
> combined.  If the application protocol is responsible for separately
> transporting the prefix and channel binding data, then say _that_, and
> make it clear that you need integrity protection for both.

Please re-read the bits you didn't quote.  I believe there's a guarantee
of non-ambiguity.

> Otherwise you're going to get into a situation where the base document
> expects the app to transport the two elements separately, but the author
> of an application protocol thinks he only gets one blob which contains
> both, and then you have a mess because implementors don't know what to do
> with the prefix (ignore it?  prepend it to the data?  how?) and either
> nothing interoperates or you end up with an application protocol that you
> can't implement correctly without making undocumented assumptions.
> 
> 
> 
> 
> 
> BTW, an environment in which some channels report data without a prefix,
> others report it with the prefix followed by ':', and still others report
> it with the prefix followed by NUL is about the worst thing I can think
> of.  Anyone actually designing an API for this should define a consistent
> way of doing it.

I wrote nothing about the separator being variable or the prefix being
optional.  The text about operating systems was to illustrate that we
need not say who is responsible, API-wise, for adding the prefix, as
long as it is added.  Please re-read carefully.

Nico
-- 

Date: Wed, 10 Oct 2007 11:16:00 -0400 (EDT)
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Sam Hartman <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Sender: [email-masked]

On Wed, 10 Oct 2007, Nicolas Williams wrote:

> The more I think about the who's-responsible-for-prefixing issue the
> more I realize that the I-D shouldn't speak to that issue.  I could see
> an operating system where all channels report channel bindings with the
> prefix already included, another where only some do, and another where
> none do -- but in all cases the applications can deal and interop
> provided that the applications know which channels include the prefix
> when and which don't.

Again, I don't care what the operating system or the library does.  Of
course the document should not speak to that; focusing on API issues
rather than protocol issues misses the point, which is that independent
implementations be able to interoperate.

What I _do_ care about is that it's clear in every case what the bits are
supposed to look like on the wire and what the application protocol
specification is responsible for doing.  If the application protocol is
supposed to provide a single slot which will contain the prefix followed
by the channel binding data, then say so, and specify exactly how they are
combined.  If the application protocol is responsible for separately
transporting the prefix and channel binding data, then say _that_, and
make it clear that you need integrity protection for both.

Otherwise you're going to get into a situation where the base document
expects the app to transport the two elements separately, but the author
of an application protocol thinks he only gets one blob which contains
both, and then you have a mess because implementors don't know what to do
with the prefix (ignore it?  prepend it to the data?  how?) and either
nothing interoperates or you end up with an application protocol that you
can't implement correctly without making undocumented assumptions.

BTW, an environment in which some channels report data without a prefix,
others report it with the prefix followed by ':', and still others report
it with the prefix followed by NUL is about the worst thing I can think
of.  Anyone actually designing an API for this should define a consistent
way of doing it.

Date: Wed, 10 Oct 2007 11:05:34 -0400 (EDT)
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: <[email-masked]>, <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Sender: [email-masked]

On Wed, 10 Oct 2007, Sam Hartman wrote:

> Well, if I have a prefix tls and a prefix t with a channel binding
> starting ls I may have a problem.

Right; that's why you need an unambiguous separator if they're going to go
in the same slot.

> Well, my reading of the ID is that the protocol needs two slots--one
> for a prefix and one for a channel binding octec string.  Simon is
> arguing that we only want to have one slot.
> I'm fine with that if we want to make that change.
>
>
> I think Jeff is arguing for the same.  I think you ande I don't care
> much.

I don't much care; I'm fine with requiring two separate slots.  As far as
I'm concerned, the document as it stands right now is not sufficiently
clear; it could be interpreted in either way.  As evidence of this I offer
the existance of the present discussion.

From: Sam Hartman <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Date: Wed, 10 Oct 2007 10:55:52 -0400
Sender: [email-masked]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Oct 09, 2007 at 05:44:47PM -0400, Jeffrey
    Nicolas> Hutzelman wrote:
    >> Really, I don't care what the API looks like or what part of
    >> the implementation is responsible for adding the prefix.  What
    >> I care about is who is responsible for specifying how the
    >> prefix is encoded and transported.  Does the application
    >> protocol specification do this, possibly by transporting two
    >> protocol fields (a name and an octet string)?  Or is the prefix
    >> part of the octet-string channel binding data?

    Nicolas> The channel binding octet string and the prefix US-ASCII
    Nicolas> string are both *just* that.  Prefixing the latter to the
    Nicolas> former is feasible without ambiguity provided that: the
    Nicolas> prefixes are unique and that they are always used.  

Well, if I have a prefix tls and a prefix t with a channel binding
starting ls I may have a problem.

    Nicolas> No
    Nicolas> separator character is needed (but if one was needed I'd
    Nicolas> prefer ':' over NUL).

    Nicolas> I believe the text of the I-D is clear on the above.
    Nicolas> Thus your protocol issues are taken care of.

Well, my reading of the ID is that the protocol needs two slots--one
for a prefix and one for a channel binding octec string.  Simon is
arguing that we only want to have one slot.
I'm fine with that if we want to make that change.

I think Jeff is arguing for the same.  I think you ande I don't care
much.

Date: Wed, 10 Oct 2007 09:36:50 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Tue, Oct 09, 2007 at 05:44:47PM -0400, Jeffrey Hutzelman wrote:
> Really, I don't care what the API looks like or what part of the
> implementation is responsible for adding the prefix.  What I care
> about is who is responsible for specifying how the prefix is encoded
> and transported.  Does the application protocol specification do this,
> possibly by transporting two protocol fields (a name and an octet
> string)?  Or is the prefix part of the octet-string channel binding
> data?

The channel binding octet string and the prefix US-ASCII string are both
*just* that.  Prefixing the latter to the former is feasible without
ambiguity provided that: the prefixes are unique and that they are
always used.  No separator character is needed (but if one was needed
I'd prefer ':' over NUL).

I believe the text of the I-D is clear on the above.  Thus your protocol
issues are taken care of.

The more I think about the who's-responsible-for-prefixing issue the
more I realize that the I-D shouldn't speak to that issue.  I could see
an operating system where all channels report channel bindings with the
prefix already included, another where only some do, and another where
none do -- but in all cases the applications can deal and interop
provided that the applications know which channels include the prefix
when and which don't.

Thus, I'm inclined to believe that the issue in question requires no
clarfication beyond saying that the ambiguity is intentional.

Nico
-- 

From: Sam Hartman <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Date: Wed, 10 Oct 2007 09:03:34 -0400
Sender: [email-masked]

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

    Jeffrey> Fine; I don't have any particular reason to prefer nul.
    Jeffrey> But, why not; what problem are you concerned about?

C strings.
Yes, a correct implementation will not have this problem.
I see no reason to make it harder though.

From: "Jeffrey Hutzelman" <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Date: 09 Oct 2007 21:07:00 -0400
To: <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Fine; I don't have any particular reason to prefer nul.  But, why not; what problem are you concerned about?

-----Original Message-----
From: Sam Hartman <[email-masked]>
Date: Tuesday, Oct 9, 2007 8:48 pm
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
To: Jeffrey Hutzelman <[email-masked]>
CC: Nicolas Williams <[email-masked]>, [email-masked],        [email-masked]

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:
>
>    Jeffrey> On Tuesday, October 09, 2007 04:25:16 PM -0500 Nicolas
>
>    Jeffrey> I'm inclined to specify that all protocols should work
>    Jeffrey> the same way, transporting a single octet string which
>    Jeffrey> consists of the prefix, followed by a NUL octet, followed
>    Jeffrey> by the actual binding data.
>
>Please don't use nul; use : or something like that and forbid that
>character from prefixes.
>
>
>

From: Sam Hartman <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Date: Tue, 09 Oct 2007 20:48:01 -0400
Sender: [email-masked]

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

    Jeffrey> On Tuesday, October 09, 2007 04:25:16 PM -0500 Nicolas

    Jeffrey> I'm inclined to specify that all protocols should work
    Jeffrey> the same way, transporting a single octet string which
    Jeffrey> consists of the prefix, followed by a NUL octet, followed
    Jeffrey> by the actual binding data.

Please don't use nul; use : or something like that and forbid that
character from prefixes.

Date: Tue, 09 Oct 2007 17:44:47 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Sam Hartman <[email-masked]>
cc: [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Originator-Info: login-token=Mulberry:01556goFEGFRQz6RghGhzQD34Q18tu0hlUE84FHR4=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, October 09, 2007 04:25:16 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

> On Tue, Oct 09, 2007 at 05:15:28PM -0400, Sam Hartman wrote:
>>     Nicolas> In any case, I don't think the channel
>>     Nicolas> providing the bindings should be providing the prefix.
>>
>> I don't see why this is true.  I'm with Nico; could go either way.
>
> Heh!
>
> OK, let's decide either way, shall we?  Because in some cases apps will
> be responsible for constructing the channel binding in the first place,
> and to minimize API impact on secure channels, I'd rather make the app
> responsible for adding the prefix.
>
> The primary consequence of doing so is: apps must know what type of
> channel they are binding to, and if they don't know then the implication
> is that some channel abstraction layer exists which does know and can be
> made responsible for adding the prefix.

Really, I don't care what the API looks like or what part of the 
implementation is responsible for adding the prefix.  What I care about is 
who is responsible for specifying how the prefix is encoded and 
transported.  Does the application protocol specification do this, possibly 
by transporting two protocol fields (a name and an octet string)?  Or is 
the prefix part of the octet-string channel binding data?

I'm inclined to specify that all protocols should work the same way, 
transporting a single octet string which consists of the prefix, followed 
by a NUL octet, followed by the actual binding data.

-- Jeff

Date: Tue, 9 Oct 2007 16:25:16 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Mail-Followup-To: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Tue, Oct 09, 2007 at 05:15:28PM -0400, Sam Hartman wrote:
>     Nicolas> In any case, I don't think the channel
>     Nicolas> providing the bindings should be providing the prefix.
> 
> I don't see why this is true.  I'm with Nico; could go either way.

Heh!

OK, let's decide either way, shall we?  Because in some cases apps will
be responsible for constructing the channel binding in the first place,
and to minimize API impact on secure channels, I'd rather make the app
responsible for adding the prefix.

The primary consequence of doing so is: apps must know what type of
channel they are binding to, and if they don't know then the implication
is that some channel abstraction layer exists which does know and can be
made responsible for adding the prefix.

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-sasl-gs2 AD review comments
Date: Tue, 09 Oct 2007 17:15:28 -0400
Sender: [email-masked]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Oct 09, 2007 at 03:59:31PM -0400, Sam Hartman
    Nicolas> wrote:
    Simon> I thought that channel binding data had to contain a unique
    Simon> prefix which would appears to solve that problem, without
    Simon> having to require that protocols encode the channel binding
    Simon> type too.  If my assumption is correct, it would be useful
    Simon> to clarify this in d-w-on-channel-binding.  No change in
    Simon> GS2 seems necessary.  Nico?
    >>  I thought it was the responsibility of the
    >> application|framework to add the unique prefix.  The channel
    >> binding base draft provides a registry for this prefix, but I
    >> thought that the channel binding description did not include
    >> this prefix and left it up to the application.  If the channel
    >> binding format must include the prefix then I think we need to
    >> change the channel binding base draft.

    Nicolas> Sam is correct.  

Ah, good.
It's always reassuring when I understand drafts I sponsor.

    Nicolas> In any case, I don't think the channel
    Nicolas> providing the bindings should be providing the prefix.

I don't see why this is true.  I'm with Nico; could go either way.

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-sasl-gs2 AD review comments
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 09 Oct 2007 22:51:44 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Oct 09, 2007 at 03:59:31PM -0400, Sam Hartman wrote:
>>     Simon> I thought that channel binding data had to contain a unique
>>     Simon> prefix which would appears to solve that problem, without
>>     Simon> having to require that protocols encode the channel binding
>>     Simon> type too.  If my assumption is correct, it would be useful
>>     Simon> to clarify this in d-w-on-channel-binding.  No change in
>>     Simon> GS2 seems necessary.  Nico?
>> 
>> I thought it was the responsibility of the application|framework to
>> add the unique prefix.  The channel binding base draft provides a
>> registry for this prefix, but I thought that the channel binding
>> description did not include this prefix and left it up to the
>> application.  If the channel binding format must include the prefix
>> then I think we need to change the channel binding base draft.
>
> Sam is correct.  In any case, I don't think the channel providing the
> bindings should be providing the prefix.

Could you suggest some text that would be appropriate in GS2 section 5?

It would help if on-channel-binding discussed its interface to
authentication protocols.  For example, what should GS2 say about
channel bindings that need confidentiality protection?  Can GS2 use such
a channel binding at all?

/Simon

Date: Tue, 9 Oct 2007 15:37:31 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Tue, Oct 09, 2007 at 04:26:59PM -0400, Jeffrey Hutzelman wrote:
> I think the base draft is almost perfectly unclear on this issue.  The 

:(

> requirement Simon quotes makes it clear that the channel type must be 
> communicated and that the application must use it to determine which 
> channel's bindings are acutally in use, but says nothing about whether the 
> communication is up to the application or by virtue of the channel binding 
> data being self-identifying.
> 
> Another listed requirements is this:
> 
>   o  The channel bindings for a given type of secure channel MUST be
>      constructed in such a way that an MITM could not easily force the
>      channel bindings of a given channel to match those of another.
> 
> On the one hand, this suggests that channel bindings are _not_ inherently 
> self-identifying, but at the same time, it imposes a requirement that is 
> most easily met by making them so.  In addition, there are many places 
> where the base document refers to the channel type name as a "prefix", 
> implying that all channel bindings would start with a channel type name.

The intention was for the applications to add the prefix (channel
bindings being an octet string there's no need for an additional
"slot").

> So, I think we need to update the base document to be clear on what should 
> happen here.  I believe that correct behavior requires that channel types 
> be identified in a consistent way for all channels, so this cannot be up to 
> the individual channel type specifications.  It could be done on a 
> per-application basis, but I see no benefit to doing so rather than using 
> the same method for all applications.

Hmmm, OK, I could go either way.  But in some cases the application may
be in charge of constructing the channel binding from things like
end-point identities, so the application will be responsible, at least
in some cases, for knowing the prefix and adding it in.

> -- Jeff
> 
> PS: IIRC, draft-williams-on-channel-bindings has already been approved and 
> is awaiting publication as an RFC.  If it needs to change in order to 
> address this issue, maybe someone should give the RFC Editor a heads up?

We're not in AUTH48 yet, so we can still make a clarification here.

Nico
-- 

Date: Tue, 9 Oct 2007 15:34:06 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-ietf-sasl-gs2 AD review comments
Mail-Followup-To: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Tue, Oct 09, 2007 at 03:59:31PM -0400, Sam Hartman wrote:
>     Simon> I thought that channel binding data had to contain a unique
>     Simon> prefix which would appears to solve that problem, without
>     Simon> having to require that protocols encode the channel binding
>     Simon> type too.  If my assumption is correct, it would be useful
>     Simon> to clarify this in d-w-on-channel-binding.  No change in
>     Simon> GS2 seems necessary.  Nico?
> 
> I thought it was the responsibility of the application|framework to
> add the unique prefix.  The channel binding base draft provides a
> registry for this prefix, but I thought that the channel binding
> description did not include this prefix and left it up to the
> application.  If the channel binding format must include the prefix
> then I think we need to change the channel binding base draft.

Sam is correct.  In any case, I don't think the channel providing the
bindings should be providing the prefix.

Nico
-- 

Date: Tue, 09 Oct 2007 16:26:59 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>
cc: [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Originator-Info: login-token=Mulberry:01g2bmP+3OW7PPsV7AtuQWrhrYHWoKml/w2xSkueY=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, October 09, 2007 03:59:31 PM -0400 Sam Hartman 
<[email-masked]> wrote:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>     Simon> Sam Hartman <[email-masked]> writes:
>     >> The draft looks quite good, but there are a few things that
>     >> need to be resolved before I can last call it.
>
>     Simon> Thanks for your review!
>
> Your proposed fixes look good except for the following:
>     >> It also appears to violate the requirement that the name of the
>     >> channel type be used in the channel binding data.
>
>     Simon> I believe you are referring to this requirement:
>
>     Simon>       * The name of the type of channel binding MUST be
>     Simon> used by the application and/or authentication protocol to
>     Simon> avoid ambiguity about which of several possible types of
>     Simon> channels is being bound.  If nested instances of the same
>     Simon> type of channel are available then the innermost channel
>     Simon> MUST be used.
>
>     Simon> I thought that channel binding data had to contain a unique
>     Simon> prefix which would appears to solve that problem, without
>     Simon> having to require that protocols encode the channel binding
>     Simon> type too.  If my assumption is correct, it would be useful
>     Simon> to clarify this in d-w-on-channel-binding.  No change in
>     Simon> GS2 seems necessary.  Nico?
>
> I thought it was the responsibility of the application|framework to
> add the unique prefix.  The channel binding base draft provides a
> registry for this prefix, but I thought that the channel binding
> description did not include this prefix and left it up to the
> application.  If the channel binding format must include the prefix
> then I think we need to change the channel binding base draft.
>
> Comments?

I think the base draft is almost perfectly unclear on this issue.  The 
requirement Simon quotes makes it clear that the channel type must be 
communicated and that the application must use it to determine which 
channel's bindings are acutally in use, but says nothing about whether the 
communication is up to the application or by virtue of the channel binding 
data being self-identifying.

Another listed requirements is this:

   o  The channel bindings for a given type of secure channel MUST be
      constructed in such a way that an MITM could not easily force the
      channel bindings of a given channel to match those of another.

On the one hand, this suggests that channel bindings are _not_ inherently 
self-identifying, but at the same time, it imposes a requirement that is 
most easily met by making them so.  In addition, there are many places 
where the base document refers to the channel type name as a "prefix", 
implying that all channel bindings would start with a channel type name.

So, I think we need to update the base document to be clear on what should 
happen here.  I believe that correct behavior requires that channel types 
be identified in a consistent way for all channels, so this cannot be up to 
the individual channel type specifications.  It could be done on a 
per-application basis, but I see no benefit to doing so rather than using 
the same method for all applications.

-- Jeff

PS: IIRC, draft-williams-on-channel-bindings has already been approved and 
is awaiting publication as an RFC.  If it needs to change in order to 
address this issue, maybe someone should give the RFC Editor a heads up?

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-sasl-gs2 AD review comments
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 09 Oct 2007 22:23:50 +0200
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>     Simon> Sam Hartman <[email-masked]> writes:
>     >> The draft looks quite good, but there are a few things that
>     >> need to be resolved before I can last call it.
>
>     Simon> Thanks for your review!
>
> Your proposed fixes look good except for the following:
>     >> It also appears to violate the requirement that the name of the
>     >> channel type be used in the channel binding data.
>
>     Simon> I believe you are referring to this requirement:
>
>     Simon>       * The name of the type of channel binding MUST be
>     Simon> used by the application and/or authentication protocol to
>     Simon> avoid ambiguity about which of several possible types of
>     Simon> channels is being bound.  If nested instances of the same
>     Simon> type of channel are available then the innermost channel
>     Simon> MUST be used.
>
>     Simon> I thought that channel binding data had to contain a unique
>     Simon> prefix which would appears to solve that problem, without
>     Simon> having to require that protocols encode the channel binding
>     Simon> type too.  If my assumption is correct, it would be useful
>     Simon> to clarify this in d-w-on-channel-binding.  No change in
>     Simon> GS2 seems necessary.  Nico?
>
> I thought it was the responsibility of the application|framework to
> add the unique prefix.  The channel binding base draft provides a
> registry for this prefix, but I thought that the channel binding
> description did not include this prefix and left it up to the
> application.  If the channel binding format must include the prefix
> then I think we need to change the channel binding base draft.
>
> Comments?

It appears simpler to me if channel binding data would always contain
the unique prefix, properly delimited.

Otherwise each protocol using channel binding need to have one slot for
the "name of the type of channel binding" and one for the channel
binding data.  That is difficult to do properly if there are no guidance
on the properties of these fields in williams-on-channel-binding.  It is
not clear to me what "name of the type of channel binding" refers to.
Is it the unique prefix?  Or the binding type?  Or the channel type?
All three fields are present in the channel binding IANA section.

For example, would concatenating the unique prefix with channel binding
data be sufficient?  How can unique prefixes look like, [a-zA-Z0-9]?  I
couldn't find anything in williams-on-channel-binding that discuss this.

/Simon

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-sasl-gs2 AD review comments
Date: Tue, 09 Oct 2007 15:59:31 -0400
Sender: [email-masked]

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

    Simon> Sam Hartman <[email-masked]> writes:
    >> The draft looks quite good, but there are a few things that
    >> need to be resolved before I can last call it.

    Simon> Thanks for your review!

Your proposed fixes look good except for the following:
    >> It also appears to violate the requirement that the name of the
    >> channel type be used in the channel binding data.

    Simon> I believe you are referring to this requirement:

    Simon>       * The name of the type of channel binding MUST be
    Simon> used by the application and/or authentication protocol to
    Simon> avoid ambiguity about which of several possible types of
    Simon> channels is being bound.  If nested instances of the same
    Simon> type of channel are available then the innermost channel
    Simon> MUST be used.

    Simon> I thought that channel binding data had to contain a unique
    Simon> prefix which would appears to solve that problem, without
    Simon> having to require that protocols encode the channel binding
    Simon> type too.  If my assumption is correct, it would be useful
    Simon> to clarify this in d-w-on-channel-binding.  No change in
    Simon> GS2 seems necessary.  Nico?

I thought it was the responsibility of the application|framework to
add the unique prefix.  The channel binding base draft provides a
registry for this prefix, but I thought that the channel binding
description did not include this prefix and left it up to the
application.  If the channel binding format must include the prefix
then I think we need to change the channel binding base draft.

Comments?

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-sasl-gs2 AD review comments
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 09 Oct 2007 20:15:50 +0200
Sender: [email-masked]

Simon Josefsson <[email-masked]> writes:

>>  I await a revised draft addressing these concerns.
>
> I'm submitting it now.

The document is published:

http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-09.txt

To review all changes since the last revision see:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-09-from-8.diff.html

/Simon

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-sasl-gs2-09.txt 
Date: Tue, 09 Oct 2007 14:10:02 -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           : Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	Author(s)       : S. Josefsson
	Filename        : draft-ietf-sasl-gs2-09.txt
	Pages           : 32
	Date            : 2007-10-09

This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework.  This is done by
defining a new SASL mechanism family, called GS2.  This mechanism
family offers a number of improvements over the previous SASL/GSS-API
mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports a SASL-specific
notion of channel binding.

See <http://josefsson.org/sasl-gs2-*/> for more information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-09.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-gs2-09.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-gs2-09.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-gs2-09.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: IETF I-D Submission Tool <[email-masked]>
Subject: New Version Notification for draft-ietf-sasl-gs2-09 
Date: Tue, 09 Oct 2007 14:06:26 -0400
Sender: [email-masked]

A new version of I-D, draft-ietf-sasl-gs2-09.txt has been successfuly submitted by Simon Josefsson and posted to the IETF repository.

Filename:	 draft-ietf-sasl-gs2
Revision:	 09
Title:		 Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
Creation_date:	 2007-10-09
WG ID:		 sasl
Number_of_pages: 32

Abstract:
This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework.  This is done by
defining a new SASL mechanism family, called GS2.  This mechanism
family offers a number of improvements over the previous SASL/GSS-API
mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports a SASL-specific
notion of channel binding.

See <http://josefsson.org/sasl-gs2-*/> for more information.

The IETF Secretariat.

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-sasl-gs2 AD review comments
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 09 Oct 2007 19:54:59 +0200
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

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

Thanks for your review!

> Section 5:

The channel binding documents have been updated several times after GS2
was published.  Generally, more review for consistency between the two
documents would be useful.

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

Would adding the following text satisfy your concern?

   In order to accomodate the requirement in [16] "Authentication
   frameworks and mechanisms that support channel binding MUST
   communicate channel binding failure to applications" implementations
   MUST provide a way to communicate channel binding failures to
   applications.

I've made this change.

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

I believe you are referring to this requirement:

      *  The name of the type of channel binding MUST be used by the
         application and/or authentication protocol to avoid ambiguity
         about which of several possible types of channels is being
         bound.  If nested instances of the same type of channel are
         available then the innermost channel MUST be used.

I thought that channel binding data had to contain a unique prefix which
would appears to solve that problem, without having to require that
protocols encode the channel binding type too.  If my assumption is
correct, it would be useful to clarify this in d-w-on-channel-binding.
No change in GS2 seems necessary.  Nico?

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

Yes, an empty challenge was intended.  I've made the following change.

OLD:

An authentication exchange using GS2 may look like:

         C: Request authentication exchange
         S: Send ["", ""] token
...
   Because GSS-API authentication is initiated by the client, the length
   field will be 0 in the initial token from the server to the client
   when the protocol profile does not support additional information to
   be sent together with the authentication request.

NEW:

   An authentication exchange using GS2 may look like:

         C: Request authentication exchange
         S: Empty Challenge
...

   GSS-API authentication is always initiated by the client.  The SASL
   framework allows either the client and server to initiate
   authentication.  In GS2 the server will send an initial empty
   challenge (zero byte string) if it has not yet received a token from
   the client.  See section 3 of [2].

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

It is in section 4.3.2.

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

I've changed the text in section 7 to say:

    <t>An invalid SASL token is received (e.g., length field checks
      discussed in section 4.1 fail).</t>

Also improved the paragraph in 4.1 to say:

    <t>Messages shorter than or equal to 8 octets are invalid.  (The
      only exception is the initial empty challenge sent by the server
      which may be 0 octets.)  ...

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

I've removed SPNEGO from section 14.

> Section 14 leaves out the preferred solution to avoid bid-down attacks
> in SASL; see section 6.1.2 of RFC 4422.

I've added a reference, and some text to suggest that the solutions
given in GS2 are only beyond that which is already given in 6.1.2.

>  I await a revised draft addressing these concerns.

I'm submitting it now.

/Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 01 Oct 2007 22:28:12 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Should the next revision be a WG document?

I would support that.

/Simon