Subject: Re: CRAM draft 7 pushed
From: Lyndon Nerenberg <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Date: Mon, 31 Jul 2006 16:02:57 -0600 (MDT)
List-Id: <ietf-sasl.imc.org>

> AS an individual, I'd definitely prefer not to introduce saslprep into
> cram-md5 at this point.  I also believe that is where the WG was
> headed.  But whatever we can get consensus on is good.

If the WG decides something I'll certainly write that in.  My read was 
that while there were a lot of opinions about saslprep, there was no 
consenus.  I could very well have been wrong.

--lyndon

From: Sam Hartman <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: CRAM draft 7 pushed
Date: Mon, 31 Jul 2006 17:55:47 -0400
Sender: [email-masked]

>>>>> "Lyndon" == Lyndon Nerenberg <[email-masked]> writes:

    >> I believe the WG reached consensus that we would document
    Lyndon> No, I thought we decided that the behaviour for non-ASCII
    Lyndon> was essentially random (mostly due to
    Lyndon> implementation-specific pass-thru behaviour WRT
    Lyndon> non-ASCII), therefore specifying something could no break
    Lyndon> existing practice any worse than it already was broken
    Lyndon> (since the only opportunity for interoperability at the
    Lyndon> time was sheer blind luck).

pass through has different interop behavior than saslprep.

AS an individual, I'd definitely prefer not to introduce saslprep into
cram-md5 at this point.  I also believe that is where the WG was
headed.  But whatever we can get consensus on is good.

Date: Mon, 31 Jul 2006 15:18:00 -0500
From: Nicolas Williams <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Consensus (Re: TLS channel bindings)
Mail-Followup-To: Eric Rescorla <[email-masked]>, Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Jul 31, 2006 at 01:13:57PM -0700, Eric Rescorla wrote:
> > > It had better not, since they're sent in the clear in the NULL_MD5
> > > and NULL_SHA1 cipher suites.
> > 
> > Also, it's supposed to be a one-way function, is it not?  
> 
> Yep.
> 
> It's just that that's a constructive argument. I thought a pseudo-reduction
> might be more uh... motivating.

So, can we declare consensus: that we'll use the [cleartext] TLS
finished messages as the channel bindings for TLS sessions?

Also, please reference draft-altman-tls-channel-bindings-00.txt.

Nico
-- 

To: Nicolas Williams <[email-masked]>
cc: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings 
Date: Mon, 31 Jul 2006 13:13:57 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Nicolas Williams <[email-masked]> wrote:

> On Mon, Jul 31, 2006 at 11:55:32AM -0700, Eric Rescorla wrote:
> > Sam Hartman <[email-masked]> wrote:
> > > Nico, it is clear that disclosing channel bindings is a reasonable
> > > thing to do.  What is unclear is whether disclosing TLS finish
> > > messages breaks TLS.
> 
> [I've not received this message yet...]
> 
> Sam, we are not talking about revealing channel bindings to anyone who
> isn't already privy or supposed to be privy to them.
> 
> We're talking about disclosing channel bindings to the application-layer
> peer, over the self-same channel named by those channel bindings.  The
> peer at the secure channel clearly knows these channel bindings already.
> 
> The peer at the application layer knows the channel bindings for the
> channel it observes.  If the two peers at the application layer observe
> different channel bindings then the may be a MITM between them and
> revealing the bindings for the two channels hurts noone; certainly not
> the application-layer peers, and the MITM knows both sets of bindings
> already.
> 
> > It had better not, since they're sent in the clear in the NULL_MD5
> > and NULL_SHA1 cipher suites.
> 
> Also, it's supposed to be a one-way function, is it not?  

Yep.

It's just that that's a constructive argument. I thought a pseudo-reduction
might be more uh... motivating.

-Ekr

Date: Mon, 31 Jul 2006 14:39:03 -0500
From: Nicolas Williams <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings
Mail-Followup-To: Eric Rescorla <[email-masked]>, Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Jul 31, 2006 at 11:55:32AM -0700, Eric Rescorla wrote:
> Sam Hartman <[email-masked]> wrote:
> > Nico, it is clear that disclosing channel bindings is a reasonable
> > thing to do.  What is unclear is whether disclosing TLS finish
> > messages breaks TLS.

[I've not received this message yet...]

Sam, we are not talking about revealing channel bindings to anyone who
isn't already privy or supposed to be privy to them.

We're talking about disclosing channel bindings to the application-layer
peer, over the self-same channel named by those channel bindings.  The
peer at the secure channel clearly knows these channel bindings already.

The peer at the application layer knows the channel bindings for the
channel it observes.  If the two peers at the application layer observe
different channel bindings then the may be a MITM between them and
revealing the bindings for the two channels hurts noone; certainly not
the application-layer peers, and the MITM knows both sets of bindings
already.

> It had better not, since they're sent in the clear in the NULL_MD5
> and NULL_SHA1 cipher suites.

Also, it's supposed to be a one-way function, is it not?  

To: Sam Hartman <[email-masked]>
cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings 
Date: Mon, 31 Jul 2006 11:55:32 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Sam Hartman <[email-masked]> wrote:
> Nico, it is clear that disclosing channel bindings is a reasonable
> thing to do.  What is unclear is whether disclosing TLS finish
> messages breaks TLS.

It had better not, since they're sent in the clear in the NULL_MD5
and NULL_SHA1 cipher suites.

-Ekr

From: Sam Hartman <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings
Date: Mon, 31 Jul 2006 14:54:43 -0400
Sender: [email-masked]

Nico, it is clear that disclosing channel bindings is a reasonable
thing to do.  What is unclear is whether disclosing TLS finish
messages breaks TLS.

Date: Mon, 31 Jul 2006 11:13:40 -0500
From: Nicolas Williams <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings
Mail-Followup-To: Eric Rescorla <[email-masked]>, Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

Apologies for the length of this reply.  I expand on Sam's comment about
hw acceleration, and then I expand on the channel binding process and
why privacy protection of the TLS finished messages in the GS2 channel
binding operation is not needed.  BTW, with a small change to GS2 we can
achieve privacy protection of the channel binding data without creating
hash agility issues.

On Sat, Jul 29, 2006 at 05:03:42PM -0700, Eric Rescorla wrote:
> Sam> TLS and IPsec have better hardware acceleration.  TLS and IPsec
> Sam> are better optimized for bulk encryption than most GSS mechs and
> Sam> all SASL mechs I know of.  [...]

Exactly.  The canonical example, for me, is RDDP, a technology intended
to be implemented in NICs so as to provide for zero-copy semantics on
reception.  RDDP is layered below the application protocol that it so
accelerates, and, crucially, this implies that the application protocol
has to be in the clear relative to the RDDP layer.  Additionally, the
RDDP layer has to be as far down the stack as possible in order for it
to be reasonable to implement it in silicon.  This means that when using
RDDP the only place we can do cryptographic session protection is at the
transport or lower layers.  We have this then:

      +---------------------+
      | Application layer   |
      +---------------------+
      | RDDP                |
      +---------------------+
      | TCP/SCTP            |
      +---------------------+
      | ESP/AH              |
      +---------------------+
      | IP                  |
      +---------------------+
      | ...                 |
      +---------------------+

But the authentication and authorization model for the application may
be radically different than that of IPsec.  NFSv4 comes to mind.

So, if RDDP is not to be a security XOR performance technology then we
have to leverage ESP/AH.  Channel binding helps.  We do need a way to
construct IPsec channels (the BTNS WG is working on that).

> OK.
> 
> I'd like to point out that carrying the channel bindings over the
> GSS/SASL channel is actually my option (1). The key X in question
> here is whatever keying material you established using GSS/SASL.
> And F is the GSS/SASL MAC. :)

Channel binding involves: a) a secure channel to bind to, b) a
cryptographic protocol for authentication and key exchange at a higher
network layer.  The channel binding happens in (b); without (b) there's
no channel binding.

By definition we have a situation where we're protecting the channel
binding operation cryptographically in whatever protocol (b) happens to
be, independently of whatever properties the channel (a) happens to
have.

If an attacker could gain much from observing (b), then one might not be
willing to use that protocol.  That one uses it is indicative that one
is not so concerned about passive attackers.

There's no reason, then, to worry that we're talking to an MITM at (a)
that might get some benefit from observing (b), because otherwise we'd
not be using the protocol in (b) at all.

(And, if there were some benefit for an attacker in observing (b), then
as long as the attacker could not realize this benefit in real-time then
one has a chance to detect the attcker, who must be an MITM, through
channel binding failure and then react accordingly.)

It is of no concern then whether a mechanism used in (b) provides
confidentiality protection for the channel binding operation (as long as
it provides integrity protection for it), since the channel binding
operation is intended to detect whether a peer at (a) is logically the
same as in (b) and the channel binding data used in (b) is derived from
(a), which means that the peer at (a) knows the same channel binding
data used in (b).

There may be ways to construct channel bindings operations which lack
this symmetry (both peers at (a) can construct the same "name" for the
channel at (a)), but they would not improve the analysis above, which
relies on an unrelated assumption: that the protocol at (b) is
sufficiently strong that one would not object to using it in the
presence of active attackers.  The construction of the channel binding
operation, you can see, is irrelevant, provided that the power of the
protocol at (b) is used to protect it.

Nico
-- 

Date: Sat, 29 Jul 2006 20:56:59 -0700
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Cc: [email-masked]
Sender: [email-masked]

At 03:40 PM 7/29/2006, Sam Hartman wrote:
>What happened to the spnego mechanism name (gss-spnego? or something
>like that?)  It is reasonably widely deployed and I thought was
>documented here.

It was removed after the Nov 2006 WG Review of the document
for reasons outlined in the list archives.
 http://www.imc.org/ietf-sasl/mail-archive/msg02159.html

In short, if the IETF is to assume change control for the
SASL/SPNEGO registration (the IETF currently does not have
change control) and produce a SASL/SPNEGO specification, it
seems appropriate to do so separately from the SASL/GSSAPI
(and SASL/GS2-*) specifications, especially given
SASL/SPNEGO's LIMITED applicability and distinct security
considerations.

Kurt 

Date: Sat, 29 Jul 2006 20:56:05 -0500
From: [email-masked]
Subject: Re: TLS channel bindings
To: Simon Josefsson <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

Simon Josefsson wrote:

>Sam> What is the harm in giving the attacker the finish message?
>  
>
>
>I don't know.
>
>However, generally, it seems that the finish messages are treated as
>confidential information today (they are sent over the encrypted
>channel) but now we propose to relax this classification -- unless we
>are ready to treat channel binding data as security sensitive
>information too -- meaning that it would not be a security violation
>to leak the finished messages.
>  
>

No, we are NOT relaxing anything.

You have a TLS channel, and the two end-points of it know the finished  
messages.  Channel binding happens in an authentication exchange 
protected by the channel being bound to.  If there's no MITM then 
there's no privacy concern w.r.t. channel bindings, and if there is an 
MITM, well, then there's still no such concern: the other end-point 
knows the bindings already.

To: Sam Hartman <[email-masked]>
cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings 
Date: Sat, 29 Jul 2006 17:03:42 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Sam Hartman <[email-masked]> wrote:
> TLS and IPsec have better hardware acceleration.  TLS and IPsec are
> better optimized for bulk encryption than most GSS mechs and all SASL
> mechs I know of.  Many applications support TLS for their traffic but
> make it rather difficult to support an alternative layer; while SASL
> has a concept of security layers they are not widely implemented.
> Doing confidentiality or integrity within the application protocol as
> required by GSS or SASL tends to be harder to implement and design
> than TLS; using the GSS or SASL channel to carry the channel bindings
> is not a big deal because it is all encapsulated within the
> authentication exchange, but using the GSS/SASL channel for all
> application data tends to be hard to implement.

OK.

I'd like to point out that carrying the channel bindings over the
GSS/SASL channel is actually my option (1). The key X in question
here is whatever keying material you established using GSS/SASL.
And F is the GSS/SASL MAC. :)

-Ekr

From: Sam Hartman <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings
Date: Sat, 29 Jul 2006 19:57:40 -0400
Sender: [email-masked]

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    Eric> Sam Hartman <[email-masked]> wrote:
    >> >>>>> "Eric" == Eric Rescorla <[email-masked]>
    >> writes:
    >> 
    Eric> The fix is to have the authentication protocol depend
    Eric> cryptographically on information from the underlying secure
    Eric> channel in such a way that a MITM attack on that channel
    Eric> will cause the authentication handshake to fail.  That's
    Eric> what I mean when I say "channel binding".
    >>
    Eric> There are two general (though closely related strategies)
    Eric> for producing this result:
    >> 
    >> 
    >> In practice neither strategy is used.  GSS tends to establish
    >> an integrity protected channel of its own, over which the
    >> channel binding (or a hash of the channel binding) is
    >> transported.  One side sends the channel binding, the other
    >> side aborts the authentication if the channel binding is wrong.
    >> Assuming things have been designed correctly, this is done in
    >> such a way that an MITM cannot make either party think the
    >> channel binding was successfully verified.
    >> 
    >> SASL tends to do something similar.

    Eric> Uh... What's the point of the TLS/IPsec channel, then?

TLS and IPsec have better hardware acceleration.  TLS and IPsec are
better optimized for bulk encryption than most GSS mechs and all SASL
mechs I know of.  Many applications support TLS for their traffic but
make it rather difficult to support an alternative layer; while SASL
has a concept of security layers they are not widely implemented.
Doing confidentiality or integrity within the application protocol as
required by GSS or SASL tends to be harder to implement and design
than TLS; using the GSS or SASL channel to carry the channel bindings
is not a big deal because it is all encapsulated within the
authentication exchange, but using the GSS/SASL channel for all
application data tends to be hard to implement.

To: Sam Hartman <[email-masked]>
cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings 
Date: Sat, 29 Jul 2006 16:42:36 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Sam Hartman <[email-masked]> wrote:

> >>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
> 
>     Eric> The fix is to have the authentication protocol depend
>     Eric> cryptographically on information from the underlying secure
>     Eric> channel in such a way that a MITM attack on that channel
>     Eric> will cause the authentication handshake to fail.  That's
>     Eric> what I mean when I say "channel binding".
> 
>     Eric> There are two general (though closely related strategies)
>     Eric> for producing this result:
> 
> 
> In practice neither strategy is used.  GSS tends to establish an
> integrity protected channel of its own, over which the channel binding
> (or a hash of the channel binding) is transported.  One side sends the
> channel binding, the other side aborts the authentication if the
> channel binding is wrong.  Assuming things have been designed
> correctly, this is done in such a way that an MITM cannot make either
> party think the channel binding was successfully verified.
> 
> SASL  tends to do something similar.

Uh... What's the point of the TLS/IPsec channel, then?

I've got some ideas, but I'd like to hear you say it...

-Ekr

From: Sam Hartman <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings
Date: Sat, 29 Jul 2006 19:30:39 -0400
Sender: [email-masked]

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    Eric> The fix is to have the authentication protocol depend
    Eric> cryptographically on information from the underlying secure
    Eric> channel in such a way that a MITM attack on that channel
    Eric> will cause the authentication handshake to fail.  That's
    Eric> what I mean when I say "channel binding".

    Eric> There are two general (though closely related strategies)
    Eric> for producing this result:

In practice neither strategy is used.  GSS tends to establish an
integrity protected channel of its own, over which the channel binding
(or a hash of the channel binding) is transported.  One side sends the
channel binding, the other side aborts the authentication if the
channel binding is wrong.  Assuming things have been designed
correctly, this is done in such a way that an MITM cannot make either
party think the channel binding was successfully verified.

SASL  tends to do something similar.

So, the channel binding does not directly influence the authentication
protocol but instead is carried in a protected channel within the
authentication protocol.

IN this approach it doesn't seem like there is a need to treat the
channel binding as confidential unless it would provide an attacker
some advantage in attempting to create a channel with the same channel
binding.

Your two approaches would of course work, but they end up being a bit
more tricky to implement in the existing frameworks.

To: Simon Josefsson <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings 
Date: Sat, 29 Jul 2006 16:17:34 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Eric Rescorla <[email-masked]> wrote:
> There are two general (though closely related strategies) for
> producing this result:

I should note that the below mechanisms provide one-way authentication,
but it's obvious how to extend them to two-way.

-Ekr

To: Simon Josefsson <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings 
Date: Sat, 29 Jul 2006 16:14:41 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Simon Josefsson <[email-masked]> wrote:

> Eric Rescorla <[email-masked]> writes:
> 
> >> > And since you're presumably planning to digest the finished messages
> >> > as part of your channel binding..
> >> 
> >> GS2 doesn't hash the channel binding.
> >
> > Hmmm... I haven't studied GS2, but I have to wonder if that's wise.
> 
> Why not?  Earlier I thought of channel binding as something you'd have
> to treat as sensitive information, but in several discussions, it
> seems as if channel bindings are treated only as a "name" of a
> particular channel, and not something that is necessarily security
> sensitive.
> 
> If channel bindings are security sensitive data, we should document
> that in whatever document discusses and defines channel bindings.
> 
> I think we should design channel bindings so they are not security
> sensitive data.
> 
> The TLS finish message border on being security sensitive (they are
> not available to attackers today), that's why I see an issue with
> using them (directly) as the channel binding data.

I wonder if we're not talking past each other here, in particular
that we don't have the same view of what a "channel binding" is.
It might help to go back to first principles.

The objective is to have a cryptographically secure (integrity
protected, possibly confidential) channel in which one or both sides are
authenticated. TLS and IKE/IPsec provide this capability but have a
fairly limited number of authentication mechanisms.  It would be nice to
be able to use the authentication mechanisms provided by frameworks such
as SASL or GSS with such channels.

The naive thing to do is simply to establish an unauthenticated TLS or
IKE/IPsec channel and then run your ordinary authentication protocol
over top of that channel. This has the problem that a MITM can attack
the unauthenticated secure channel and then proxy the authentication
handshake, thus gaining control of the communication with a successful
authentication result on either side.

The fix is to have the authentication protocol depend cryptographically
on information from the underlying secure channel in such a way that a
MITM attack on that channel will cause the authentication handshake to
fail.  That's what I mean when I say "channel binding".

There are two general (though closely related strategies) for
producing this result:

1. Alice and Bob share a secret X. Alice computes a function that
   depends on both X and the properties of the underlying channel
   and sends the result to Bob. (This is typically done using
   some kind of MAC).
2. Alice has a secret key X and Bob knows her public key Y.
   Alice computes a function that depends on both X and the
   properties of the underlying channel and sends the result
   to Bob. (This is typically done using some kind of digital
   signature.)

So, either way you have Alice computing F(X, CP) where CP is the channel
properties. Bob verifies with F(X, CP) or F^-1(Y, CP). Note first that
in either case, the output of the function can't be assumed to be
confidential because the entire premise of the attack is that the
attacker can capture it. Note second that in general Alice and Bob
will both know CP. This means that there's no need to carry it
over the channel. It merely needs to be fed into F. Finally, note
that whether F is a MAC or a signature, it's most likely going to
involve something like hashing, so I think you've got a hash
agility problem in any case.

-Ekr

From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Recommendations for gs2
Date: Sat, 29 Jul 2006 18:55:45 -0400
Sender: [email-masked]

One think I didn't like very much about draft-ietf-sasl-gssapi-xx is
that it was focused on how to call GSS-API, not so much on the wire
format messages.

I think it is important to remember that we're specifying a protocol
not an API here, and that the important thing of the gss-related
mechanisms is to describe which tokens to send over the wire.

I'm not asking the gssapi draft to change, but I'd ask that we do a
better job of this in gs2.  The current gs2 text seems reasonable in
this regard; I'm just writing to say that I think this is a good thing
and we should keep it.  Similarly RFC 4462 strikes a reasonable
balance here.  I mention that as another example of a good solution to
this problem.

--Sam

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: TLS channel bindings
Date: Sat, 29 Jul 2006 18:49:41 -0400
Sender: [email-masked]

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

    Simon> Sam Hartman <[email-masked]> writes:
    >>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
    >>
    Simon> This has the property that we don't re-use the TLS finish
    Simon> messages, which are sent encrypted and presumed unknown by
    Simon> attackers, as the channel binding data token, something
    Simon> which we don't regard as security sensitive and
    Simon> consequently don't make sure to necessarily protect.
    >>  What is the harm in giving the attacker the finish message?

    Simon> I don't know.

I suggest you or someone find out.:-)

--Sam

From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: AD Review for draft-ietf-sasl-gssapi-xx.txt
Date: Sat, 29 Jul 2006 18:40:46 -0400
Sender: [email-masked]

Hi.

In general draft-ietf-sasl-gssapi-xx looks reasonably good, although a
few issues need to be fixed and the document reissued before I can
last call it.

What happened to the spnego mechanism name (gss-spnego? or something
like that?)  It is reasonably widely deployed and I thought was
documented here.

The document fails to meet a few requirements of section 5 of RFC 4422:

      b) An indication of whether the server is expected to provide
         additional data when indicating a successful outcome.  If so,
         if the server sends the additional data as a challenge, the

   5) If the underlying cryptographic technology used by a mechanism
         supports data integrity, then the mechanism specification MUST
         integrity protect the transmission of an authorization identity
         and the negotiation of the security layer.

I think the resolution here is to always require the integrity flag be
set.

I believe the following text may be generally false for gssapi
mechanisms and is certainly false for RFC 4121.  I think it is false
for 1964 if a client asserts a subkey.

   The integrity protection provided by the GSSAPI security layer is
   useless to the client unless the client also requests mutual
   authentication.  Therefore, a client wishing to benefit from the
   integrity protection of a security layer MUST pass to the
   GSS_Init_sec_context call a mutual_req_flag of TRUE.

In particular I think SASL's use of gssapi will get it mutual auth
regardless of whether it requests mutual auth.

The text in section 3 recommends that servers check the name the
client authenticated to.  If the server passes in GSS_C_NO_CREDENTIAL
(or acquires credentials with no name) this seems desirable.  However
I don't understand why it is desirable if the server passed in a name
for its credentials.

To: Simon Josefsson <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings 
Date: Sat, 29 Jul 2006 15:15:12 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Simon Josefsson <[email-masked]> wrote:

> Eric Rescorla <[email-masked]> writes:
> 
> > Simon Josefsson <[email-masked]> wrote:
> >> Hashing the finish messages seems fine, but it generates hash agility
> >> concerns.
> >
> > Why's that?
> 
> Which hash function would you chose? 

But this is true for ANY cryptographic algorithm you choose.
That's why you need agility.

> Do we know that it will be
> sufficiently difficult to invert the function during the foreseeable
> future?  If not, we'd might as well not hash the finished messages, or
> make it possible to replace a weak hash function.

Right. The second is what's appropriate practice.

-Ekr

Date: Sat, 29 Jul 2006 18:11:36 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Eric Rescorla <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: TLS channel bindings
Originator-Info: login-token=Mulberry:015Xg7jU/gsAExw7MOGPZr/HzqcrhsrLRS7WnyG/g=; token_authority=[email-masked]
Sender: [email-masked]

On Sunday, July 30, 2006 12:01:03 AM +0200 Simon Josefsson 
<[email-masked]> wrote:

>
> Eric Rescorla <[email-masked]> writes:
>
>>> > And since you're presumably planning to digest the finished messages
>>> > as part of your channel binding..
>>>
>>> GS2 doesn't hash the channel binding.
>>
>> Hmmm... I haven't studied GS2, but I have to wonder if that's wise.
>
> Why not?  Earlier I thought of channel binding as something you'd have
> to treat as sensitive information, but in several discussions, it
> seems as if channel bindings are treated only as a "name" of a
> particular channel, and not something that is necessarily security
> sensitive.
>
> If channel bindings are security sensitive data, we should document
> that in whatever document discusses and defines channel bindings.
>
> I think we should design channel bindings so they are not security
> sensitive data.

So do I.  This can be accomplished by using a hash when defining the 
bindings for a particular channel type.  Higher-layer protocols like SASL 
mechanisms should be free to transport the channel binding data in whatever 
fashion is most useful.

> The TLS finish message border on being security sensitive (they are
> not available to attackers today)

There's a difference between something that happens not to be available to 
attackers and something that MUST not be available to attackers.  The 
phrase "security sensitive" describes the latter, but not the former, and 
one does not imply the other.  To know which category the TLS finish 
messages fall into, you'd have to consult a TLS expert.

-- Jeff

From: Simon Josefsson <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sun, 30 Jul 2006 00:11:28 +0200
Sender: [email-masked]

Eric Rescorla <[email-masked]> writes:

> Simon Josefsson <[email-masked]> wrote:
>> Hashing the finish messages seems fine, but it generates hash agility
>> concerns.
>
> Why's that?

Which hash function would you chose?  Do we know that it will be
sufficiently difficult to invert the function during the foreseeable
future?  If not, we'd might as well not hash the finished messages, or
make it possible to replace a weak hash function.

/Simon

From: Simon Josefsson <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sun, 30 Jul 2006 00:01:03 +0200
Sender: [email-masked]

Eric Rescorla <[email-masked]> writes:

>> > And since you're presumably planning to digest the finished messages
>> > as part of your channel binding..
>> 
>> GS2 doesn't hash the channel binding.
>
> Hmmm... I haven't studied GS2, but I have to wonder if that's wise.

Why not?  Earlier I thought of channel binding as something you'd have
to treat as sensitive information, but in several discussions, it
seems as if channel bindings are treated only as a "name" of a
particular channel, and not something that is necessarily security
sensitive.

If channel bindings are security sensitive data, we should document
that in whatever document discusses and defines channel bindings.

I think we should design channel bindings so they are not security
sensitive data.

The TLS finish message border on being security sensitive (they are
not available to attackers today), that's why I see an issue with
using them (directly) as the channel binding data.

/Simon

To: Simon Josefsson <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings 
Date: Sat, 29 Jul 2006 14:40:33 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Simon Josefsson <[email-masked]> wrote:
> Hashing the finish messages seems fine, but it generates hash agility
> concerns.

Why's that?

-Ekr

To: Simon Josefsson <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings 
Date: Sat, 29 Jul 2006 14:39:34 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Simon Josefsson <[email-masked]> wrote:
> Eric Rescorla <[email-masked]> writes:
> 
> >> The finish messages are generated by the PRF, so I'm not sure I follow
> >> this.  RFC 4346:
> >> 
> >>       struct {
> >>           opaque verify_data[12];
> >>       } Finished;
> >> 
> >>       verify_data
> >>           PRF(master_secret, finished_label, MD5(handshake_messages) +
> >>           SHA-1(handshake_messages)) [0..11];
> >> 
> >>       finished_label
> >>           For Finished messages sent by the client, the string "client
> >>           finished".  For Finished messages sent by the server, the
> >>           string "server finished".
> >> 
> >> Did Eric mean that MD5(h)+SHA(h) as seed, instead of
> >> client_random+server_random as seed, was the critical aspect?
> >
> > Yes.
> >
> > The key point is that you need to build the peer's DH shares into
> > the integrity check.
> 
> I see.  Then the use of the TLS PRF in some EAP mechanism to generate
> keying material seem problematic.  If I recall correctly, the TLS/IA
> extension also uses the TLS PRF with the client/server random as seed.
>
> I wonder how practical this attack is.  Does it work for server
> authenticated sessions?  Server+client authenticated sessions?

AFAIK, no.

The key to this attack is that you're using un-authenticated DH
to form the TLS connection and then authenticating the client
*and* server at the layer above. However, that said, the
primary reason you need a channel binding is that you can't
use ordinary TLS mechanisms to authenticate the server. If you
can, then the integrity of the channel is generally enough.

> >> This has the property that we don't re-use the TLS finish messages,
> >> which are sent encrypted and presumed unknown by attackers, as the
> >> channel binding data token, something which we don't regard as
> >> security sensitive and consequently don't make sure to necessarily
> >> protect.
> >
> > But this requires access to the master secret, which is also
> > sensitive.
> 
> The SASL_channel_binding token could be exported through a similar
> mechanism as the finished messages.  That would seem to have the same
> level of master secret exposure.

Right, but now you're adding yet another place where you're examining
TLS's internals. Maybe it will come to that, but I think it's worth
trying to avoid.

> > And since you're presumably planning to digest the finished messages
> > as part of your channel binding..
> 
> GS2 doesn't hash the channel binding.

Hmmm... I haven't studied GS2, but I have to wonder if that's wise.

-Ekr

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: TLS channel bindings
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 29 Jul 2006 23:20:38 +0200
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>     Simon> This has the property that we don't re-use the TLS finish
>     Simon> messages, which are sent encrypted and presumed unknown by
>     Simon> attackers, as the channel binding data token, something
>     Simon> which we don't regard as security sensitive and
>     Simon> consequently don't make sure to necessarily protect.
>
> What is the harm in giving the attacker the finish message?

I don't know.

However, generally, it seems that the finish messages are treated as
confidential information today (they are sent over the encrypted
channel) but now we propose to relax this classification -- unless we
are ready to treat channel binding data as security sensitive
information too -- meaning that it would not be a security violation
to leak the finished messages.

There is flip side of your question: Can you prove that there is no
harm in giving the attacker the finish messages of a TLS session?

I cannot prove that, therefore I lean towards the approach to assume
that it is a bad idea to (potentially) leak them.

Hashing the finish messages seems fine, but it generates hash agility
concerns.

/Simon

From: Simon Josefsson <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 29 Jul 2006 23:04:27 +0200
Sender: [email-masked]

Eric Rescorla <[email-masked]> writes:

>> The finish messages are generated by the PRF, so I'm not sure I follow
>> this.  RFC 4346:
>> 
>>       struct {
>>           opaque verify_data[12];
>>       } Finished;
>> 
>>       verify_data
>>           PRF(master_secret, finished_label, MD5(handshake_messages) +
>>           SHA-1(handshake_messages)) [0..11];
>> 
>>       finished_label
>>           For Finished messages sent by the client, the string "client
>>           finished".  For Finished messages sent by the server, the
>>           string "server finished".
>> 
>> Did Eric mean that MD5(h)+SHA(h) as seed, instead of
>> client_random+server_random as seed, was the critical aspect?
>
> Yes.
>
> The key point is that you need to build the peer's DH shares into
> the integrity check.

I see.  Then the use of the TLS PRF in some EAP mechanism to generate
keying material seem problematic.  If I recall correctly, the TLS/IA
extension also uses the TLS PRF with the client/server random as seed.

I wonder how practical this attack is.  Does it work for server
authenticated sessions?  Server+client authenticated sessions?

>> If so, we can use the following as the SASL channel binding:
>> 
>>          SASL_channel_binding =
>>             PRF(SecurityParameters.master_secret,
>>                 "SASL channel binding",
>>                 MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11]
>> 
>> This has the property that we don't re-use the TLS finish messages,
>> which are sent encrypted and presumed unknown by attackers, as the
>> channel binding data token, something which we don't regard as
>> security sensitive and consequently don't make sure to necessarily
>> protect.
>
> But this requires access to the master secret, which is also
> sensitive.

The SASL_channel_binding token could be exported through a similar
mechanism as the finished messages.  That would seem to have the same
level of master secret exposure.

> And since you're presumably planning to digest the finished messages
> as part of your channel binding..

GS2 doesn't hash the channel binding.

/Simon

From: Sam Hartman <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings
Date: Sat, 29 Jul 2006 15:32:01 -0400
Sender: [email-masked]

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    Eric> Simon Josefsson <[email-masked]> wrote:
    >> Sam Hartman <[email-masked]> writes:
    >> 
    >> > He said that we should definitely use the finish messages not
    >> the PRF.  > He pointed to cases where an attacker could force
    >> the PRF to have a > limited range, but where the finish
    >> messages would still be secure.  > For example, he pointed to
    >> the pathalogical case where an attacker > forces you into the
    >> group of size 1 in the DH mechanism.  Clearly in > such a case,
    >> the key of the TLS channel is going to be weak and TLS > will
    >> not provide the protections we wish it would.  The whole point
    >> of > channel bindings though is to allow us to use a strong
    >> authentication > at a higher level to give us assurance about
    >> TLS.  Binding to the > finish message will do that, but binding
    >> to the PRF will not.
    >> 
    >> The finish messages are generated by the PRF, so I'm not sure I
    >> follow this.  RFC 4346:
    >> 
    >> struct { opaque verify_data[12]; } Finished;
    >> 
    >> verify_data PRF(master_secret, finished_label,
    >> MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11];
    >> 
    >> finished_label For Finished messages sent by the client, the
    >> string "client finished".  For Finished messages sent by the
    >> server, the string "server finished".
    >> 
    >> Did Eric mean that MD5(h)+SHA(h) as seed, instead of
    >> client_random+server_random as seed, was the critical aspect?

    Eric> Yes.

    Eric> The key point is that you need to build the peer's DH shares
    Eric> into the integrity check.

    >> If so, we can use the following as the SASL channel binding:
    >> 
    >> SASL_channel_binding = PRF(SecurityParameters.master_secret,
    >> "SASL channel binding", MD5(handshake_messages) +
    >> SHA-1(handshake_messages)) [0..11]
    >> 
    >> This has
    Eric> And since you're presumably planning to digest
    Eric> the finished messages as part of your channel binding..

I don't think we currently guarantee that we'll hash the channel
bindings.  digest-md5 does.

I do agree that we will often hash the channel bindings.  I cannot
think of cases where you wouldn't want to hash the channel bindings.
So if there is a compelling reason to make that a requirement, we can.

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: TLS channel bindings
Date: Sat, 29 Jul 2006 15:29:53 -0400
Sender: [email-masked]

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

    Simon> This has the property that we don't re-use the TLS finish
    Simon> messages, which are sent encrypted and presumed unknown by
    Simon> attackers, as the channel binding data token, something
    Simon> which we don't regard as security sensitive and
    Simon> consequently don't make sure to necessarily protect.

What is the harm in giving the attacker the finish message?

To: Simon Josefsson <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: TLS channel bindings 
Date: Sat, 29 Jul 2006 11:39:11 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Simon Josefsson <[email-masked]> wrote:

> Sam Hartman <[email-masked]> writes:
> 
> > He said that we should definitely use the finish messages not the PRF.
> > He pointed to cases where an attacker could force the PRF to have a
> > limited range, but where the finish messages would still be secure.
> > For example, he pointed to the pathalogical case where an attacker
> > forces you into the group of size 1 in the DH mechanism.  Clearly in
> > such a case, the key of the TLS channel is going to be weak and TLS
> > will not provide the protections we wish it would.  The whole point of
> > channel bindings though is to allow us to use a strong authentication
> > at a higher level to give us assurance about TLS.  Binding to the
> > finish message will do that, but binding to the PRF will not.
> 
> The finish messages are generated by the PRF, so I'm not sure I follow
> this.  RFC 4346:
> 
>       struct {
>           opaque verify_data[12];
>       } Finished;
> 
>       verify_data
>           PRF(master_secret, finished_label, MD5(handshake_messages) +
>           SHA-1(handshake_messages)) [0..11];
> 
>       finished_label
>           For Finished messages sent by the client, the string "client
>           finished".  For Finished messages sent by the server, the
>           string "server finished".
> 
> Did Eric mean that MD5(h)+SHA(h) as seed, instead of
> client_random+server_random as seed, was the critical aspect?

Yes.

The key point is that you need to build the peer's DH shares into
the integrity check.

> If so, we can use the following as the SASL channel binding:
> 
>          SASL_channel_binding =
>             PRF(SecurityParameters.master_secret,
>                 "SASL channel binding",
>                 MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11]
> 
> This has the property that we don't re-use the TLS finish messages,
> which are sent encrypted and presumed unknown by attackers, as the
> channel binding data token, something which we don't regard as
> security sensitive and consequently don't make sure to necessarily
> protect.

But this requires access to the master secret, which is also
sensitive. And since you're presumably planning to digest the finished
messages as part of your channel binding..

-Ekr

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: TLS channel bindings
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 29 Jul 2006 20:33:49 +0200
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

> He said that we should definitely use the finish messages not the PRF.
> He pointed to cases where an attacker could force the PRF to have a
> limited range, but where the finish messages would still be secure.
> For example, he pointed to the pathalogical case where an attacker
> forces you into the group of size 1 in the DH mechanism.  Clearly in
> such a case, the key of the TLS channel is going to be weak and TLS
> will not provide the protections we wish it would.  The whole point of
> channel bindings though is to allow us to use a strong authentication
> at a higher level to give us assurance about TLS.  Binding to the
> finish message will do that, but binding to the PRF will not.

The finish messages are generated by the PRF, so I'm not sure I follow
this.  RFC 4346:

      struct {
          opaque verify_data[12];
      } Finished;

      verify_data
          PRF(master_secret, finished_label, MD5(handshake_messages) +
          SHA-1(handshake_messages)) [0..11];

      finished_label
          For Finished messages sent by the client, the string "client
          finished".  For Finished messages sent by the server, the
          string "server finished".

Did Eric mean that MD5(h)+SHA(h) as seed, instead of
client_random+server_random as seed, was the critical aspect?

If so, we can use the following as the SASL channel binding:

         SASL_channel_binding =
            PRF(SecurityParameters.master_secret,
                "SASL channel binding",
                MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11]

This has the property that we don't re-use the TLS finish messages,
which are sent encrypted and presumed unknown by attackers, as the
channel binding data token, something which we don't regard as
security sensitive and consequently don't make sure to necessarily
protect.

/Simon

From: Sam Hartman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: TLS channel bindings
Date: Sat, 29 Jul 2006 12:14:27 -0400
Sender: [email-masked]

Hi, folks.  At IETf 66, we had a long discussion of whether the TLS
PRF or the TLS finish messages would be a better basis for the TLS
channel bindings.

The conclusion of that discussion was that deciding on TLS channel
bindings is not in scope for SASL.  We should normatively reference
some other document.  That conclusion is rather unsatisfying since the
people participating in the SASL discussion are almost certainly the
people driving the other document.

After the meeting I asked Eric to comment on the question: I'd heard
he knew a bit about TLS.

He said that we should definitely use the finish messages not the PRF.
He pointed to cases where an attacker could force the PRF to have a
limited range, but where the finish messages would still be secure.
For example, he pointed to the pathalogical case where an attacker
forces you into the group of size 1 in the DH mechanism.  Clearly in
such a case, the key of the TLS channel is going to be weak and TLS
will not provide the protections we wish it would.  The whole point of
channel bindings though is to allow us to use a strong authentication
at a higher level to give us assurance about TLS.  Binding to the
finish message will do that, but binding to the PRF will not.

(Eric did not say, but it is my understanding that in cases where
things are working normally, the PRF should be sufficient.  However we
care about the cases where we are under attack too.)

Eric also said that TLS applications know when they are involved in a
rekey.  So, the OpenSSL APIs should be sufficient for our needs.  It
is reasonable for the application or SASL library to expect to be able
to grab the first finish message in a predictable manner.

--Sam

From: [email-masked]
To: [email-masked]
Subject: Good day
Date: Thu, 27 Jul 2006 21:06:46 +0900
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0005_0DEBD96B.C08C9D7E
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

Mail transaction failed. Partial message is available.

------=_NextPart_000_0005_0DEBD96B.C08C9D7E
Content-Type: application/octet-stream;
	name="body.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="body.zip"

------=_NextPart_000_0005_0DEBD96B.C08C9D7E--

Date: Fri, 21 Jul 2006 11:12:38 -0700
From: Chris Newman <[email-masked]>
Subject: Re: CRAM draft 7 pushed
To: Lyndon Nerenberg <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Lyndon Nerenberg wrote on 7/14/06 10:54 -0600:
> I don't think Chris was in favour of the SASLprep solution, but I distinctly
> remember him saying "in the absence of WG agreement, let the editor pick a
> solution."  So I did, and in doing so, chose the option that aligned CRAM-MD5
> with the direction the other text-based mechanisms were going.

Whatever moves the draft forward fastest is fine with me at this point.

                - Chris

Date: Fri, 14 Jul 2006 10:04:26 -0700
From: Chris Newman <[email-masked]>
Subject: Re: CRAM draft 7 pushed
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
Sender: [email-masked]

Sounds right to me.

Of course, the interoperability ramifications of introducing SASLprep to 
several SASL mechanisms after they were deployed without it probably should 
have been documented in the SASLprep specification.  But it's too late to fix 
that.

                - Chris

Kurt D. Zeilenga wrote on 7/14/06 8:51 -0400:
> I believe the WG reached consensus that we would document
> existing implementation practice with regards to CRAM-MD5,
> document existing limitations, etc.., and submit for
> publication as Informational.
>
> If we have one set of implementations doing X and one set
> doing Y, I would suggest we document both X and Y and
> the interoperability (and other) implications of this.
>
> Kurt
>
> At 11:24 PM 7/13/2006, Chris Newman wrote:
>
>> Sorry I didn't notice this until now...
>>
>> There was discussion of whether we are documenting current practice (which
>> does not use SASLprep) or proposing a new incompatible mechanism (which uses
>> SASLprep).  I believe the WG rough consensus at the meeting (or perhaps WG
>> apathy in response to a suggestion :-) was that there is more value
>> documenting current interoperable practice since we don't intend to put this
>> on the standards track.
>>
>> So what I'd like to see is to remove the discussion of SASLprep but keep it
>> as an informative reference and mention that CRAM-MD5 as deployed is
>> vulnerable to the security risks of UTF-8 which SASLprep might partially
>> reduce if it had been used.
>>
>> Also, the term "well-formed UTF-8" is not defined in RFC 3629, so I don't
>> think it's appropriate as part of a MUST.  You could be more explicit by
>> referencing the RFC 3629 ABNF instead as follows:
>>
>> username   = 1*(%20-7F / UTF-2 / UTF-3 / UTF-4)
>>            ; UTF-2, UTF-3 and UTF-4 are defined in RFC 3629
>>
>>               - Chris
>>
>> Lyndon Nerenberg wrote on 6/12/06 16:38 -0600:
>>
>>>
>>> The updated draft is in the ID editors hands.  Until it's officially out you
>>> can find it at http://orthanc.ca/.
>>>
>>> This update is just some minor editorial cleanup.
>>>
>>> I recall Chris Newman bringing up a point about something needing to be
>>> clarified (related to normalization IIRC), but I can no longer find my
>>> Jabber notes, and I couldn't spot anything in the list archives.  Chris (or
>>> anyone), do you recall the specifics?  If I can get a memory refresher
>>> there's still time to push another update before the cutoff.
>>>
>>> --lyndon
>>>
>>
>>
>>
>

Date: Fri, 14 Jul 2006 10:54:57 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: CRAM draft 7 pushed
Sender: [email-masked]

> I believe the WG reached consensus that we would document
> existing implementation practice with regards to CRAM-MD5,
> document existing limitations, etc.., and submit for
> publication as Informational.

My recollection is that this was discussed in Dallas, and consensus was 
that there was no existing practice.

> If we have one set of implementations doing X and one set
> doing Y, I would suggest we document both X and Y and
> the interoperability (and other) implications of this.

No, I thought we decided that the behaviour for non-ASCII was essentially 
random (mostly due to implementation-specific pass-thru behaviour WRT 
non-ASCII), therefore specifying something could no break existing 
practice any worse than it already was broken (since the only opportunity 
for interoperability at the time was sheer blind luck).

I don't think Chris was in favour of the SASLprep solution, but I 
distinctly remember him saying "in the absence of WG agreement, let the 
editor pick a solution."  So I did, and in doing so, chose the option that 
aligned CRAM-MD5 with the direction the other text-based mechanisms were 
going.

--lyndon

Date: Fri, 14 Jul 2006 08:51:29 -0400
To: Chris Newman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: CRAM draft 7 pushed
Cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
Sender: [email-masked]

I believe the WG reached consensus that we would document
existing implementation practice with regards to CRAM-MD5,
document existing limitations, etc.., and submit for
publication as Informational.

If we have one set of implementations doing X and one set
doing Y, I would suggest we document both X and Y and
the interoperability (and other) implications of this.

Kurt

At 11:24 PM 7/13/2006, Chris Newman wrote:

>Sorry I didn't notice this until now...
>
>There was discussion of whether we are documenting current practice (which does not use SASLprep) or proposing a new incompatible mechanism (which uses SASLprep).  I believe the WG rough consensus at the meeting (or perhaps WG apathy in response to a suggestion :-) was that there is more value documenting current interoperable practice since we don't intend to put this on the standards track.
>
>So what I'd like to see is to remove the discussion of SASLprep but keep it as an informative reference and mention that CRAM-MD5 as deployed is vulnerable to the security risks of UTF-8 which SASLprep might partially reduce if it had been used.
>
>Also, the term "well-formed UTF-8" is not defined in RFC 3629, so I don't think it's appropriate as part of a MUST.  You could be more explicit by referencing the RFC 3629 ABNF instead as follows:
>
> username   = 1*(%20-7F / UTF-2 / UTF-3 / UTF-4)
>            ; UTF-2, UTF-3 and UTF-4 are defined in RFC 3629
>
>               - Chris
>
>Lyndon Nerenberg wrote on 6/12/06 16:38 -0600:
>
>>
>>The updated draft is in the ID editors hands.  Until it's officially out you
>>can find it at http://orthanc.ca/.
>>
>>This update is just some minor editorial cleanup.
>>
>>I recall Chris Newman bringing up a point about something needing to be
>>clarified (related to normalization IIRC), but I can no longer find my Jabber
>>notes, and I couldn't spot anything in the list archives.  Chris (or anyone),
>>do you recall the specifics?  If I can get a memory refresher there's still
>>time to push another update before the cutoff.
>>
>>--lyndon
>>
>
>
>

From: Simon Josefsson <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: CRAM draft 7 pushed
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 14 Jul 2006 10:00:42 +0200
Sender: [email-masked]

Chris Newman <[email-masked]> writes:

> Sorry I didn't notice this until now...
>
> There was discussion of whether we are documenting current practice
> (which does not use SASLprep)

I'm using SASLprep in CRAM-MD5.

> or proposing a new incompatible mechanism (which uses SASLprep).

SASLprep is not incompatible, as far as I know.  RFC 2195 is broken
regarding non-ASCII.  The SASLprep approach is compatible for the
ASCII sub-set.

> I believe the WG rough consensus at the meeting (or perhaps WG
> apathy in response to a suggestion :-) was that there is more value
> documenting current interoperable practice since we don't intend to
> put this on the standards track.

I don't remember this discussion, but I disagree.

> So what I'd like to see is to remove the discussion of SASLprep but
> keep it as an informative reference and mention that CRAM-MD5 as
> deployed is vulnerable to the security risks of UTF-8 which SASLprep
> might partially reduce if it had been used.

Why not solve the security risk instead?  It seems to be possible to
do it in an backwards compatible way to me.

CRAM-MD5 over TLS is a useful protocol, and I prefer it over RFC
2831-style DIGEST-MD5.

Regards,
Simon

Date: Thu, 13 Jul 2006 20:24:30 -0700
From: Chris Newman <[email-masked]>
Subject: Re: CRAM draft 7 pushed
To: Lyndon Nerenberg <[email-masked]>, [email-masked]
Sender: [email-masked]

Sorry I didn't notice this until now...

There was discussion of whether we are documenting current practice (which does 
not use SASLprep) or proposing a new incompatible mechanism (which uses 
SASLprep).  I believe the WG rough consensus at the meeting (or perhaps WG 
apathy in response to a suggestion :-) was that there is more value documenting 
current interoperable practice since we don't intend to put this on the 
standards track.

So what I'd like to see is to remove the discussion of SASLprep but keep it as 
an informative reference and mention that CRAM-MD5 as deployed is vulnerable to 
the security risks of UTF-8 which SASLprep might partially reduce if it had 
been used.

Also, the term "well-formed UTF-8" is not defined in RFC 3629, so I don't think 
it's appropriate as part of a MUST.  You could be more explicit by referencing 
the RFC 3629 ABNF instead as follows:

  username   = 1*(%20-7F / UTF-2 / UTF-3 / UTF-4)
             ; UTF-2, UTF-3 and UTF-4 are defined in RFC 3629

                - Chris

Lyndon Nerenberg wrote on 6/12/06 16:38 -0600:

>
> The updated draft is in the ID editors hands.  Until it's officially out you
> can find it at http://orthanc.ca/.
>
> This update is just some minor editorial cleanup.
>
> I recall Chris Newman bringing up a point about something needing to be
> clarified (related to normalization IIRC), but I can no longer find my Jabber
> notes, and I couldn't spot anything in the list archives.  Chris (or anyone),
> do you recall the specifics?  If I can get a memory refresher there's still
> time to push another update before the cutoff.
>
> --lyndon
>
>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-gs2-02.txt 
Date: Thu, 13 Jul 2006 15:50: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-02.txt
	Pages		: 21
	Date		: 2006-7-13
	
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.

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

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

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

--OtherAccess--

--NextPart--

To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: IETF66 SASL summary
From: Tom Yu <[email-masked]>
Date: Thu, 13 Jul 2006 12:45:14 -0400
Lines: 49
Sender: [email-masked]

SASL WG
Monday, July 10, 2006, at 1520-1720

SUMMARY
=======

Thanks to Jeffrey Hutzelman for scribing.

Document status:

CRAM-MD5 - needs applicability statement
GS2 - some open issues
GSSAPI - sent to IESG
PLAIN - approved
rfc2831bis (DIGEST-MD5) - some open issues

Discussion on DIGEST-MD5 open issues first because Alexey needs to
leave early.  Reuse same client nonce on fast re-auth?  Probably OK,
will check with ekr.  "Server SHOULD verify authentication ID"?
Really an issue for application profiles and base spec; use
non-normative language.  AES vs RC4 as mandatory-to-implement - no
apparent objections to changing to AES.  Some discussion about how
changes in stringprep might affect things.

Sam sees no applicability statement in latest CRAM-MD5 draft; Kurt
will write one.

GS2 - main open issue is channel bindings.  Sam and others feel that
channel bindings to TLS should be specified in a general way and not
in this document.  Nico kind of has an individual submission relating
to this.  TLS PRF is probably the way to handle channel bindings.
Lengthy discussion about whether TLS implementations provide access to
PRF.

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

* Kurt will write applicability statement for CRAM-MD5

* Milestones:

Aug 2006 WGLC for CRAM-MD5
Aug 2006 WGLC for GS2
Aug 2006 WGLC for DIGEST-MD5
Sep 2006 CRAM-MD5 to IESG
Sep 2006 GS2 to IESG
Sep 2006 DIGEST-MD5 to IESG
Oct 2006 Implementation report plan
Nov 2006 Revise charter or conclude

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 13 Jul 2006 15:44:47 +0200
Sender: [email-masked]

Hi All,

I've asked for GS2 -02 to be published, review it here until it shows
up in the repository:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt

The changes are in:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-02-from-1.diff.html

In particular:

 * Simplified channel bindings, new section 5 below.

   - This moves the (still) open issue of how to define channel
     binding syntax to Nico's draft

 * Added example of channel binding connection

 * Clarified how the security layer bit mask works

Can I ask that somebody independently compute the example GS2
mechanism name for SPKM?  This is what I got:

   For example, the OID for the SPKM-1 mechanism [13] is
   1.3.6.1.5.5.1.1.  The ASN.1 DER encoding of the OID is 06 07 2b 06 01
   05 05 01 01.  The SHA-1 hash of the ASN.1 DER encoding is
   1cf8f42b5a9f80fae9f831226d5d9d56278661ad.  The Base32 encoding of the
   first ten bytes of this is "DT4PIK22T6EPV2PY".  Thus the SASL
   mechanism name for the SPKM-1 GSSAPI mechanism is "GS2-
   DT4PIK22T6EPV2PY".

I believe this version is ready for WGLC.

/Simon

5.  Channel Bindings

   The GS2 mechanism provide its own channel binding mechanism, instead
   of using the "chan_binding" parameter in the GSS-API context
   functions.  The reason for this is that the GS2 mechanism provide an
   option to proceed even if the channel bindings does not match.  The
   GSS-API framework specifies that authentication cannot proceed if
   channel bindings does not match.

   Client and servers MUST set the "chan_binding" parameter in the calls
   to GSS_Init_sec_context to GSS_Accept_sec_context, respectively, to
   NULL.

   Implementations SHOULD set the "client_cbqops" and "server_cbqops" to
   no security layer and instead depend on the session security afforded
   by the bound-in channel.

   Use of no SASL security layers in combination with channel binding
   should provide better performance than using SASL security layers
   over secure channels, and better security characteristics than using
   no SASL security layers over secure channels without channel binding.

   For more discussions of channel bindings, and the syntax of the
   channel binding data for various security protocols, see [7].

Date: Mon, 10 Jul 2006 19:28:55 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: IETF66 SASL - open issues for DIGEST-MD5
Sender: [email-masked]

Tom Yu wrote:

>* rfc2831bis - 40 min
>  
>
Several people (Sam Hartman, Jeffrey Hutzelman, Kurt Zeilenga, Tom Yu, 
Nico Williams and myself) got together on Sunday for informal meeting to 
discuss outstanding issues with the DIGEST-MD5 document. Some results of 
the discussions we had are below.

>  - AES cipher IV
>  
>
DIGEST-MD5 suffers from MITM attack on "qop" directive, as it is not 
included in the hash calculated by both ends.
I've suggested to include qop value into the IV calculated for the AES 
cipher in counter mode.
Sam pointed out that this is actually meaningless, because use of AES 
cipher already means use of confidentiality protection, which is already 
the strongest mode of operation.

Sam also suggested to include "qop" into new channel binding field. I 
will try to produce an update to DIGEST-MD5 that does this.

>  - SASLprep vs other prep
>  
>
Discussion about use of SASLPrep versa no preparation lead to the 
following proposal:
1). server should include a new flag saying that it supports SASLPrep. 
All server compliant with the updated DIGEST-MD5 spec would be required 
to send this flag.
2). client that sees this flag would be required to send 2 hashes: one 
calculated with SASLPrep, the other calculated with no preparation. 
Authentication succeeds if the server can match any one of the two hashes.

(I am pretty sure there are some holes in this proposal, but I need to 
think more about this. Any comments are welcomed).

>  - cnonce same on fast re-auth
>  
>
This issue is about difference between HTTP Digest and DIGEST-MD5 spec: 
the latter requires cnonce to be the same on reauthentication, why the 
former doesn't have this restriction.

Two questions were raised in relationship to this issue:
1). Does it matter if DIGEST-MD5 differs in this respect from HTTP Digest
  No.
2). Are there any security implications of one approach over another
  It doesn't look this way, but need to check with Eric Rescorla.

>  - SHOULD vs MUST verify authzid
>  
>
The text specifying requirement to verify authorization identity belongs 
to SASL protocol profiles. Currently the document says "server SHOULD 
verify". I was not clear why this SHOULD is not a MUST.

The suggestion is to reword the text not to use normative language, i.e. 
"server verifies authorization id ...".

>  - RC4 vs AES as mandatory to implement
>  
>
I think there was no objection to Simon & Sam to make AES in counter 
mode mandatory to implement. If you have any objections, please speak up 
now.

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: GS2 meeting material
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 10 Jul 2006 11:53:45 +0200
Sender: [email-masked]

Hi All,

Here are slides to guide discussions regarding GS2:

http://josefsson.org/sasl-gs2/ietf66-sasl-gs2.odp
http://josefsson.org/sasl-gs2/ietf66-sasl-gs2.pdf

The open issue is channel bindings.  I'm including the proposed new
section 5 that attempts to resolve this below.  Ideally, I'd like to
reference draft-ietf-nfsv4-channel-bindings-04.txt instead to define
channel bindings in GS2.  However, d-i-n-c-b is not ready and propose
to use the client/server finished messages -- this is discussed in my
presentation, and this seem to be the main open issue.

As always, more background is available from:

http://josefsson.org/sasl-gs2/

I hope to be available in the Jabber room during the meeting.

Thanks,
Simon

5.  Channel Bindings

   The GS2 mechanism provide its own channel binding mechanism, instead
   of using the "chan_binding" parameter in the GSS-API context
   functions.  The reason for this is that the GS2 mechanism provide an
   option to proceed even if the channel bindings does not match.  The
   GSS-API framework specifies that authentication cannot proceed if
   channel bindings does not match.

   Client and servers MUST set the "chan_binding" parameter in the calls
   to GSS_Init_sec_context to GSS_Accept_sec_context, respectively, to
   NULL.

   Implementations SHOULD set the "client_cbqops" and "server_cbqops" to
   no security layer and instead depend on the session security afforded
   by the bound-in channel.

   Use of no SASL security layers in combination with channel binding
   should provide better performance than using SASL security layers
   over secure channels, and better security characteristics than using
   no SASL security layers over secure channels without channel binding.
   For more discussions of channel bindings, see [16].

   For TLS, the channel binding data is specified below.  For other
   security layers, channel binding data will have to specified
   elsewhere, and this specification will have to be updated with
   explicit considerations.

5.1.  Name Of TLS Channel For Use As Channel Binding

   The TLS Pseudo-Random Function (PRF) generate, using the constant
   string "TLS channel binding", and based on the master secret and the
   random values established during a TLS handshake, a 64 octet string
   that make up the SASL channel binding data.

   Using the terminology of TLS [13], the channel binding data is
   computed as follows:

          ChannelBinding =
             PRF(SecurityParameters.master_secret,
                "TLS channel binding",
                SecurityParameters.server_random +
                SecurityParameters.client_random) [0..64];

   The derived ChannelBinding is intended to be used as a name of the
   TLS channel that is cryptographically bound to the channel, for use
   in authentication mechanisms tunneled over TLS.

Date: Mon, 10 Jul 2006 01:02:53 -0400
From: Jeffrey Altman <[email-masked]>
Organization: No Longer Affiliated with Columbia University in the City of New York
To: Kerberos WG <[email-masked]>, SASL WG <[email-masked]>, Kitten <[email-masked]>
Subject: Please participate in IETF66 [Corrected Jabber Server Info]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms080608010200000403080709
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

At IETF66 the Kerberos, Kitten and SASL Working Groups will be
experimenting with a new means of incorporating remote participants into
the meeting discussion.  In order to ensure that the comments of remote
participants as communicated via the Jabber Rooms will be seen by those
physically present, the Jabber Room will be projected onto a second
video screen.

The Kerberos Working Group will be meeting on Monday, July 10th during
the Morning Session (0900-1130 EDT) in Room 519A.

The Kitten Working Group will be meeting on Monday, July 10th during
the first Afternoon Session (1300-1500 EDT) in Room 519A.

The SASL Working Group will be meeting on Monday, July 10th during
the second Afternoon Session (1520-1720 EDT) in Room 519A.

The Audio Stream for these three sessions can accessed via

  http://videolab.uoregon.edu/events/ietf/ietf667.m3u

Use the following link to test your audio setup prior to the meetings:

  http://videolab.uoregon.edu/events/ietf/test.m3u

The Jabber Room Server is "jabber.ietf.org".  The room names are
"krb-wg", "kitten" and "sasl".

We look forward to your participation.

Jeffrey Altman

--------------ms080608010200000403080709
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms080608010200000403080709--

Date: Mon, 10 Jul 2006 01:02:53 -0400
From: Jeffrey Altman <[email-masked]>
Organization: No Longer Affiliated with Columbia University in the City of New York
To: Kerberos WG <[email-masked]>, SASL WG <[email-masked]>, Kitten <[email-masked]>
Subject: Please participate in IETF66 [Corrected Jabber Server Info]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms080608010200000403080709
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

At IETF66 the Kerberos, Kitten and SASL Working Groups will be
experimenting with a new means of incorporating remote participants into
the meeting discussion.  In order to ensure that the comments of remote
participants as communicated via the Jabber Rooms will be seen by those
physically present, the Jabber Room will be projected onto a second
video screen.

The Kerberos Working Group will be meeting on Monday, July 10th during
the Morning Session (0900-1130 EDT) in Room 519A.

The Kitten Working Group will be meeting on Monday, July 10th during
the first Afternoon Session (1300-1500 EDT) in Room 519A.

The SASL Working Group will be meeting on Monday, July 10th during
the second Afternoon Session (1520-1720 EDT) in Room 519A.

The Audio Stream for these three sessions can accessed via

  http://videolab.uoregon.edu/events/ietf/ietf667.m3u

Use the following link to test your audio setup prior to the meetings:

  http://videolab.uoregon.edu/events/ietf/test.m3u

The Jabber Room Server is "jabber.ietf.org".  The room names are
"krb-wg", "kitten" and "sasl".

We look forward to your participation.

Jeffrey Altman

--------------ms080608010200000403080709
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms080608010200000403080709--

Date: Sun, 09 Jul 2006 12:29:56 -0400
From: Jeffrey Altman <[email-masked]>
Organization: No Longer Affiliated with Columbia University in the City of New York
To: Kerberos WG <[email-masked]>, SASL WG <[email-masked]>, Kitten <[email-masked]>
Subject: Please participate in IETF66
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090504060505020901020108
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

At IETF66 the Kerberos, Kitten and SASL Working Groups will be
experimenting with a new means of incorporating remote participants into
the meeting discussion.  In order to ensure that the comments of remote
participants as communicated via the Jabber Rooms will be seen by those
physically present, the Jabber Room will be projected onto a second
video screen.

The Kerberos Working Group will be meeting on Monday, July 10th during
the Morning Session (0900-1130 EDT) in Room 519A.

The Kitten Working Group will be meeting on Monday, July 10th during
the first Afternoon Session (1300-1500 EDT) in Room 519A.

The SASL Working Group will be meeting on Monday, July 10th during
the second Afternoon Session (1520-1720 EDT) in Room 519A.

The Audio Stream for these three sessions can accessed via

  http://videolab.uoregon.edu/events/ietf/ietf667.m3u

Use the following link to test your audio setup prior to the meetings:

  http://videolab.uoregon.edu/events/ietf/test.m3u

The Jabber Room Server is "rooms.jabber.ietf.org".  The room names are
"krb-wg", "kitten" and "sasl".

We look forward to your participation.

Jeffrey Altman

--------------ms090504060505020901020108
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090504060505020901020108--

Date: Mon, 03 Jul 2006 16:25:46 +0100
From: Alexey Melnikov <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: IETF66 SASL - draft agenda
Sender: [email-masked]

Tom Yu wrote:

>This is a rough draft which I've uploaded to the meeting materials web
>page.  Please comment if you have suggestions.
>
>---Tom
>
>Simple Authentication And Security Layer (SASL)
>
>Monday, July 10, 2006, at 1520-1720
>===================================
>
>Chairs:
>
>Tom Yu <[email-masked]>
>Kurt Zeilenga <[email-masked]>
>
>DRAFT AGENDA: (2 hours)
>
>* intro, scribe appointment, agenda bashing - 5 min
>
>* document status - 5 min
>
>  - draft-ietf-sasl-crammd5-07.txt
>  - draft-ietf-sasl-gs2-01.txt
>  - draft-ietf-sasl-gssapi-06.txt
>  - draft-ietf-sasl-plain-09.txt
>  - draft-ietf-sasl-rfc2831bis-09.txt
>
>* rfc2831bis - 40 min
>
>  - AES cipher IV
>  - SASLprep vs other prep
>  - cnonce same on fast re-auth
>  - SHOULD vs MUST verify authzid
>  - RC4 vs AES as mandatory to implement
>  
>
I don't think we need to discuss the last item, unless people object to 
making AES mandatory to implement

Note that I have a conflict with Lemonade WG, where I am editing several 
documents, I would really appreciate if we can sort the issues in less 
than 40 minutes.

>* crammd5 - 10 min
>
>  - saslprep
>  - applicability
>
>* gs2 - 40 min
>
>  - channel bindings?
>
>* discuss milestones - 10 min
>
>* open mike - remaining time
>  
>

To: [email-masked]
Subject: IETF66 SASL - draft agenda
From: Tom Yu <[email-masked]>
Date: Sun, 02 Jul 2006 22:14:47 -0400
Lines: 47
Sender: [email-masked]

This is a rough draft which I've uploaded to the meeting materials web
page.  Please comment if you have suggestions.

---Tom

Simple Authentication And Security Layer (SASL)

Monday, July 10, 2006, at 1520-1720
===================================

Chairs:

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

DRAFT AGENDA: (2 hours)

* intro, scribe appointment, agenda bashing - 5 min

* document status - 5 min

  - draft-ietf-sasl-crammd5-07.txt
  - draft-ietf-sasl-gs2-01.txt
  - draft-ietf-sasl-gssapi-06.txt
  - draft-ietf-sasl-plain-09.txt
  - draft-ietf-sasl-rfc2831bis-09.txt

* rfc2831bis - 40 min

  - AES cipher IV
  - SASLprep vs other prep
  - cnonce same on fast re-auth
  - SHOULD vs MUST verify authzid
  - RC4 vs AES as mandatory to implement

* crammd5 - 10 min

  - saslprep
  - applicability

* gs2 - 40 min

  - channel bindings?

* discuss milestones - 10 min

* open mike - remaining time

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: Update of GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 01 Jul 2006 10:23:25 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Fri, Jun 30, 2006 at 12:43:04PM +0200, Simon Josefsson wrote:
>> Is this approach regarding channel binding OK with everyone?
>
> Yes.  We can probably last call this soon, though we'll want to resolve
> the matter of who specifies the TLS channel bindings.  That'll have to
> wait until we firm up our sense of the state of the other channel
> bindings I-Ds.  We can always keep your text and not reference any
> channel bindings documents.

Yup.  I'll keep it as-is for now.

>> There is one more issue, maybe we can resolve it on-list:
>> 
>> * Should the document say that integrity/privacy layers
>>   MAY/SHOULD/MUST be negotiated?  If channel binding negotiation
>>   succeeds, it currently says:
>> 
>>    Implementations MAY set the "client_cbqops" and "server_cbqops" to no
>>    security layer to improve performance by using only one security
>>    layer.
>
> MAY is fine, but I'd prefer SHOULD.
>
> And I'd re-write that sentence like so:
>
>    Implementations SHOULD set the "client_cbqops" and "server_cbqops" to
>    no security layer and instead depend on the session security afforded
>    by the bound-in channel.
>
>    Use of no SASL security layers in combination with channel binding
>    should have provide performance than using SASL security layers over
>    secure channels, and better security characteristics than using no
>    SASL security layers over secure channels without channel binding.
>
>    [Here a reference to the NFSv4 WG channel bindings I-D would be
>    useful, both for formal definitions and for discussion of the
>    security benefits of channel binding hinter at above.]

I've added this, new section below.

>>   This seems acceptable to me, but we may also require that a security
>>   layer must always be negotiated if there is no channel binding.
>
> RFC4422 doesn't require the use of security layers, therefore neither
> should GS2.

Right.

>>   There is a complication when the GSS-API mechanism doesn't provide
>>   security layers.  Should we say anything about this?
>
> That point is moot.  Note that if the client wants to negotiate
> confidentiality protection then it MUST set the conf_req_flag for
> GSS_Init_sec_context() (GSS_C_CONF_FLAG).

Right.  It would be a complication if we want to require privacy
layers to be negotiated, though.

>
>> The only remaining item, that I am aware of, is to add example
>> connections for channel bindings, but I'll work on that separately.
>
> Example connections?

I meant more examples for section 6.

/Simon

5.  Channel Bindings

   The GS2 mechanism provide its own channel binding mechanism, instead
   of using the "chan_binding" parameter in the GSS-API context
   functions.  The reason for this is that the GS2 mechanism provide an
   option to proceed even if the channel bindings does not match.  The
   GSS-API framework specifies that authentication cannot proceed if
   channel bindings does not match.

   Client and servers MUST set the "chan_binding" parameter in the calls
   to GSS_Init_sec_context to GSS_Accept_sec_context, respectively, to
   NULL.

   Implementations SHOULD set the "client_cbqops" and "server_cbqops" to
   no security layer and instead depend on the session security afforded
   by the bound-in channel.

   Use of no SASL security layers in combination with channel binding
   should provide better performance than using SASL security layers
   over secure channels, and better security characteristics than using
   no SASL security layers over secure channels without channel binding.
   For more discussions of channel bindings, see [16].

   For TLS, the channel binding data is specified below.  For other
   security layers, channel binding data will have to specified
   elsewhere, and this specification will have to be updated with
   explicit considerations.

5.1.  Name Of TLS Channel For Use As Channel Binding

   The TLS Pseudo-Random Function (PRF) generate, using the constant
   string "TLS channel binding", and based on the master secret and the
   random values established during a TLS handshake, a 64 octet string
   that make up the SASL channel binding data.

   Using the terminology of TLS [13], the channel binding data is
   computed as follows:

          ChannelBinding =
             PRF(SecurityParameters.master_secret,
                "TLS channel binding",
                SecurityParameters.server_random +
                SecurityParameters.client_random) [0..64];

   The derived ChannelBinding is intended to be used as a name of the
   TLS channel that is cryptographically bound to the channel, for use
   in authentication mechanisms tunneled over TLS.