Subject: Re: Identifying channel bindings
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Date: Thu, 30 Nov 2006 13:57:19 -0600
List-Id: <ietf-sasl.imc.org>

On Thu, Nov 30, 2006 at 06:50:57PM +0000, Alexey Melnikov wrote:
> >so this prefix thing doesn't make
> >something possible that would otherwise be impossible here.
> > 
> >
> Impossible - no. But it can serve as a hint.
> If  the other end tells which channel binding it is using, it makes 
> verification easier.

I think the argument is pointless as we agree that we should have that
prefix, but for different reasons.

I think the API design issue will be a non-issue in practice.  And for
something like the GSS-API, where the is prefix won't make it across
from initiator to acceptor, the interfaces will have to look like what I
suggested anyways, whether you like it or not).

The security reason that Sam proffers is much more interesting because a
broken protocol is much less pleasant than an API that you find
unpleasant.

Nico
-- 

Date: Thu, 30 Nov 2006 18:50:57 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: Identifying channel bindings
Sender: [email-masked]

Nicolas Williams wrote:

>>I believe one property this unique channel binding type prefix, that
>>Alexey proposed, should have, is that implementations can look at it
>>and find out which security channel API (TLS vs IPSEC etc) should be
>>responsible for telling the application/SASL library/GS2 the channel
>>binding data.
>>
>>I note that this approach enable future negotiation of the kind of TLS
>>channel binding data to be used -- e.g., if TLS finished messages no
>>longer work as a channel binding in a future version of TLS, we can
>>define a new channel binding prefix for this future TLS version.
>>    
>>
>I object to this rationale: the app can always give the library ALL of
>the possible channel bindings,
>
I am not sure this will result in a good API.

Are you saying that the endpoint can just calculate all possible channel 
bindings and compare each one of them with the one received from the 
other end?
That would work, but this doesn't strike me as good design.

>so this prefix thing doesn't make
>something possible that would otherwise be impossible here.
>  
>
Impossible - no. But it can serve as a hint.
If  the other end tells which channel binding it is using, it makes 
verification easier.

Date: Thu, 30 Nov 2006 11:06:55 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Nov 30, 2006 at 11:35:44AM -0500, Jeffrey Hutzelman wrote:
> On Thu, 30 Nov 2006, Simon Josefsson wrote:
> > RFC 4462 section 2.3 doesn't seem explicit about whether the tag and
> > length is included in the DER encoding or not, is it?
> 
> No; it's not as explicit as it should be.  I thought we had fixed that,
> but I reread it in preparing my last message, and it could be better.

Perhaps you should submit an erratum on this.

Date: Thu, 30 Nov 2006 11:01:59 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Identifying channel bindings
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Nov 30, 2006 at 11:39:02AM -0500, Jeffrey Hutzelman wrote:
> On Thu, 30 Nov 2006, Nicolas Williams wrote:
> 
> > I object to this rationale: the app can always give the library ALL of
> > the possible channel bindings, so this prefix thing doesn't make
> > something possible that would otherwise be impossible here.
> 
> Have we established that channel bindings are always something that can be
> compared bit-for-bit, rather than requiring decoding and interpretation?

That's how the GSS-API views channel bindings (don't let the C bindings
structure fool you into thinking that there's actually a decoding step
in verifying channel binding), and it's what
draft-williams-on-channel-binding defines.

Nico
-- 

Date: Thu, 30 Nov 2006 11:39:02 -0500 (EST)
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, <[email-masked]>
Subject: Re: Identifying channel bindings
Sender: [email-masked]

On Thu, 30 Nov 2006, Nicolas Williams wrote:

> I object to this rationale: the app can always give the library ALL of
> the possible channel bindings, so this prefix thing doesn't make
> something possible that would otherwise be impossible here.

Have we established that channel bindings are always something that can be
compared bit-for-bit, rather than requiring decoding and interpretation?

Date: Thu, 30 Nov 2006 11:37:59 -0500 (EST)
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, <[email-masked]>
Subject: Re: GS2 update
Sender: [email-masked]

On Thu, 30 Nov 2006, Nicolas Williams wrote:

> On Thu, Nov 30, 2006 at 02:26:45PM +0100, Simon Josefsson wrote:
> > Jeffrey Hutzelman <[email-masked]> writes:
> > RFC 4462 section 2.3 doesn't seem explicit about whether the tag and
> > length is included in the DER encoding or not, is it?
>
> Hmmm.  Our implementation includes the DER length and tag:

Yeah; IIRC, we discussed this on the ietf-ssh mailing list and picked a
representation, but apparently it was never made sufficiently clear in the
document.  I edited that, so I guess you can blame me.

Date: Thu, 30 Nov 2006 11:35:44 -0500 (EST)
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, <[email-masked]>
Subject: Re: GS2 update
Sender: [email-masked]

On Thu, 30 Nov 2006, Simon Josefsson wrote:

> RFC 4462 section 2.3 doesn't seem explicit about whether the tag and
> length is included in the DER encoding or not, is it?

No; it's not as explicit as it should be.  I thought we had fixed that,
but I reread it in preparing my last message, and it could be better.

-- Jeff

Date: Thu, 30 Nov 2006 09:30:59 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Identifying channel bindings
Mail-Followup-To: Simon Josefsson <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Nov 30, 2006 at 02:04:27PM +0100, Simon Josefsson wrote:
> Jeffrey Hutzelman <[email-masked]> writes:
> > Out of scope for GS2, but not for the channel bindings documents, and
> > I do think it's a good idea, for a variety of reasons.
> 
> I agree that it would be a good idea to add.

I don't object.

> I believe one property this unique channel binding type prefix, that
> Alexey proposed, should have, is that implementations can look at it
> and find out which security channel API (TLS vs IPSEC etc) should be
> responsible for telling the application/SASL library/GS2 the channel
> binding data.
> 
> I note that this approach enable future negotiation of the kind of TLS
> channel binding data to be used -- e.g., if TLS finished messages no
> longer work as a channel binding in a future version of TLS, we can
> define a new channel binding prefix for this future TLS version.

I object to this rationale: the app can always give the library ALL of
the possible channel bindings, so this prefix thing doesn't make
something possible that would otherwise be impossible here.

Nico
-- 

Date: Thu, 30 Nov 2006 09:28:53 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Mail-Followup-To: Simon Josefsson <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Nov 30, 2006 at 02:26:45PM +0100, Simon Josefsson wrote:
> Jeffrey Hutzelman <[email-masked]> writes:
> RFC 4462 section 2.3 doesn't seem explicit about whether the tag and
> length is included in the DER encoding or not, is it?

Hmmm.  Our implementation includes the DER length and tag:

http://src.opensolaris.org/source/xref/loficc/crypto/usr/src/cmd/ssh/libssh/common/ssh-gss.c#196

and there's this comment in there too:

        /*
         * NOTE:  If we need to support SSH_BUG_GSSAPI_BER this is where
         * we'd do it.
         *
         * That means using "Se3H81ismmOC3OE+FwYCiQ==" for the Kerberos
         * V mech and "N3+k7/4wGxHyuP8Yxi4RhA==" for the GSI mech.  Ick.
         */

:)

> I made that explicit in GS2, and the entire paragraph now reads:

Excellent.

> > So, I didn't care much when this issue came up in SSH, and I don't
> > care much now.  However, I do believe there is something to be said
> > for consistency.
> 
> Agreed.  Despite that the C bindings doesn't include tag+length, I
> believe GS2 should remain as it is written now, i.e., include
> tag+length in the DER encoding that goes into the GS2 name
> computation.  The proposed new section above make that explicit as
> well.

+1

Nico
-- 

Date: Thu, 30 Nov 2006 14:42:23 +0000
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Sender: [email-masked]

Simon Josefsson wrote:

>Jeffrey Hutzelman <[email-masked]> writes:
>  
>
>>>>RFC2743 deliberately doesn't specify the exact form of OID's or any
>>>>other data type, because it is an abstract interface.  Those details
>>>>are left up to the particular language bindings.
>>>>        
>>>>
>>>That is unfortunate since it means GS2 cannot assume implementation
>>>have the OID in any particular form.
>>>      
>>>
>>Well, you can't make assumptions about implementations, but you can
>>look at what the language bindings specifications say.  Also, as Nico
>>points out, the standard framing specified by RFC2743 does use encoded
>>OID's on the wire.  I think it's pretty clear that's the right form to
>>use here.  If you don't think the existing text is clear enough (and
>>it might not be), I encourage you to extract the text from RFC4462
>>section 2.3, and modify it as needed (IIRC, you will need to change
>>base64 to base32, since SASL mech names are case-insensitive).
>>    
>>
>RFC 4462 section 2.3 doesn't seem explicit about whether the tag and
>length is included in the DER encoding or not, is it?
>
>I made that explicit in GS2, and the entire paragraph now reads:
>
>  <t>The SASL mechanism name for a GSS-API mechanism is the
>    concatenation of the string "GS2-" and
>    the <xref target="RFC4648">Base32 encoding</xref> (with an upper
>    case alphabet) of the first ten bytes of the
>    binary <xref target="RFC3174">SHA-1 hash</xref> string computed
>    over the <xref target="ISO.8824.1990">ASN.1 DER encoding</xref>,
>    including the tag and length octets, of the GSS-API mechanism's
>    Object Identifier.  The Base32 rules on padding characters and
>    characters outside of the base32 alphabet are not relevant to this
>    use of Base32.  If any padding or non-alphabet characters are
>    encountered, the name is not a GS2 family mechanism name.</t>
>
>Opinions?
>  
>
This looks good to me.

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 30 Nov 2006 14:26:45 +0100
Sender: [email-masked]

I think we have reached a good compromise with regards to
non-integrity mechanisms, so I skip that part of your mail.

Jeffrey Hutzelman <[email-masked]> writes:

>>> RFC2743 deliberately doesn't specify the exact form of OID's or any
>>> other data type, because it is an abstract interface.  Those details
>>> are left up to the particular language bindings.
>>
>> That is unfortunate since it means GS2 cannot assume implementation
>> have the OID in any particular form.
>
> Well, you can't make assumptions about implementations, but you can
> look at what the language bindings specifications say.  Also, as Nico
> points out, the standard framing specified by RFC2743 does use encoded
> OID's on the wire.  I think it's pretty clear that's the right form to
> use here.  If you don't think the existing text is clear enough (and
> it might not be), I encourage you to extract the text from RFC4462
> section 2.3, and modify it as needed (IIRC, you will need to change
> base64 to base32, since SASL mech names are case-insensitive).

RFC 4462 section 2.3 doesn't seem explicit about whether the tag and
length is included in the DER encoding or not, is it?

I made that explicit in GS2, and the entire paragraph now reads:

  <t>The SASL mechanism name for a GSS-API mechanism is the
    concatenation of the string "GS2-" and
    the <xref target="RFC4648">Base32 encoding</xref> (with an upper
    case alphabet) of the first ten bytes of the
    binary <xref target="RFC3174">SHA-1 hash</xref> string computed
    over the <xref target="ISO.8824.1990">ASN.1 DER encoding</xref>,
    including the tag and length octets, of the GSS-API mechanism's
    Object Identifier.  The Base32 rules on padding characters and
    characters outside of the base32 alphabet are not relevant to this
    use of Base32.  If any padding or non-alphabet characters are
    encountered, the name is not a GS2 family mechanism name.</t>

Opinions?

>> Is it BER/DER?  I thought for BER/DER you'll need the tag 0x06 and
>> length 0x07.  I call the OID without the DER/BER tag+length "raw".
>
> Call it what you want, but there is no such thing as a "raw" OID.  An
> OID is a structured value, and must be represented in some form.  The
> form we're talking about is defined in the ASN.1 encoding rules as the
> encoded form of an OBJECT IDENTIFIER.

Sure, but there are still two alternatives: include the tag+length or
not.  The C language bindings of GSS-API does not include tag+length
in their OID representation (section 3.3):

   The elements field of this structure points to the first byte of an
   octet string containing the ASN.1 BER encoding of the value portion
   of the normal BER TLV encoding of the gss_OID.  The length field
   contains the number of bytes in this value.  For example, the gss_OID
   value corresponding to {iso(1) identified-organization(3) icd-
   ecma(12) member-company(2) dec(1011) cryptoAlgorithms(7) DASS(5)},
   meaning the DASS X.509 authentication mechanism, has a length field
   of 7 and an elements field pointing to seven octets containing the
   following octal values: 53,14,2,207,163,7,5.

Thus, C language applications that use GSS-API will have to add the
tag and length manually before they can compute the GS2 mechanism
name.  Assuming OID don't grow too large, that is rather simple (add
0x06 and number of octets), though.

>> The lowest-common denominator here seem to be DER encoded OID's
>> without the tag+length, which isn't what GS2 is using now.
>
> So, I didn't care much when this issue came up in SSH, and I don't
> care much now.  However, I do believe there is something to be said
> for consistency.

Agreed.  Despite that the C bindings doesn't include tag+length, I
believe GS2 should remain as it is written now, i.e., include
tag+length in the DER encoding that goes into the GS2 name
computation.  The proposed new section above make that explicit as
well.

/Simon

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 30 Nov 2006 14:10:54 +0100
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> On Monday, November 27, 2006 11:46:55 AM -0600 Nicolas Williams
> <[email-masked]> wrote:
>
>> On Mon, Nov 27, 2006 at 10:19:06AM -0600, Nicolas Williams wrote:
>>> On Thu, Nov 23, 2006 at 12:42:40AM +0100, Simon Josefsson wrote:
>>> >
>>> > Nicolas Williams <[email-masked]> writes:
>>> >
>>> > > I vote for not supporting GSS mechanisms that don't provide
>>> > > GSS_Wrap().
>>> >
>>> > +1.
>>> >
>>> > How about mechanisms that provide GSS_Wrap without integrity
>>> > protection?  That is allowed by RFC 2743 section 1.2.2.  I'm not sure
>>> > whether you assumed that GSS_Wrap always provide integrity or not.
>>>
>>> That's what I meant, GSS_Wrap() with integrity protection should be a
>>> requirement for GS2.
>>
>> Er, no, I think I can live with mechs that provide GSS_Wrap() but no
>> conf/integ protection.
>
> And I, in turn, am happy with requiring mechs that don't provide
> confidentiality or integrity protection to nonetheless support
> GSS_Wrap, as described in RFC2743 section 1.2.2.  That means that
> supporting these mechanisms requires no wire protocol changes to GS2;
> all that is required is text about checking that integ_avail is true
> if the app wanted a security layer or channel binding (and in general,
> we need text about checking statuses and context feature flags if we
> don't already have it).

Nice!  That approach seems much better than what was proposed in:
<http://article.gmane.org/gmane.ietf.sasl/2582>.  The earlier proposal
effectively created two protocol inside GS2, both in the protocol
syntax and its semantics, and that is why I suggested moving that
functionality to a "GS0".

However, if we can assume that non-integrity mechanisms provide
GSS_Wrap, that will make the GS2 protocol syntax the same for both
alternatives, and then I have no problem with supporting those
mechanisms in GS2.

Some additional text is still required, though..

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Identifying channel bindings
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 30 Nov 2006 14:04:27 +0100
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> On Monday, November 27, 2006 11:13:43 AM -0600 Nicolas Williams
> <[email-masked]> wrote:
>
>>
>> I just spoke to Sam about this.
>>
>> One the one hand he believes that this is out of scope for GS2.  On the
>> other hand he believes that it will be easier to ensure that channel
>> bindings for *different* channel types cannot be confused if we add this
>> channel binding type prefix to the channel bindings strings.
>>
>> Basically, if the unique channel bindings for two different channel
>> types are such that an MITM could control a prefix of one and a suffix
>> of the other then the MITM could substitute chhanel types and cause the
>> channel bindings to match.
>>
>> While I believe that we can and should make sure that the definition of
>> unique channel bindings does not allow such contructions where an MITM
>> controls a sub-string of the channel bindings, I do agree with Sam that
>> adding a type prefix is a very simple change.  But again, this is out of
>> scope for GS2 (though GS2 might not progress until the normative
>> reference for channel bindings stabilizes and/or progresses.
>
> Out of scope for GS2, but not for the channel bindings documents, and
> I do think it's a good idea, for a variety of reasons.

I agree that it would be a good idea to add.

I believe one property this unique channel binding type prefix, that
Alexey proposed, should have, is that implementations can look at it
and find out which security channel API (TLS vs IPSEC etc) should be
responsible for telling the application/SASL library/GS2 the channel
binding data.

I note that this approach enable future negotiation of the kind of TLS
channel binding data to be used -- e.g., if TLS finished messages no
longer work as a channel binding in a future version of TLS, we can
define a new channel binding prefix for this future TLS version.

/Simon

From: Simon Josefsson <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Calculation of SASL GS2 mechanism names
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 30 Nov 2006 13:42:38 +0100
Sender: [email-masked]

Tom Yu <[email-masked]> writes:

> On a related note, I will need to double-check, but it seems that the
> base32-encoded hash for the SPKM OID should be "DT4PIK22T6APV2PY" not
> "DT4PIK22T6EPV2PY" as shown in the draft, i.e., the 11th character is
> "A", not "E".  Can anyone else confirm?

Nice catch.  I re-computed the SPKM OID by hand, I can confirm that.
Below is the new text in GS2 for SPKM.

3.3.  Examples

   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, including the tag and length, is (in hex) 06
   07 2b 06 01 05 05 01 01.  The SHA-1 hash of the ASN.1 DER encoding is
   (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad.
   Convert the first ten octets to binary, and re-group them in groups
   of 5, and convert them back to decimal, which results in these
   computations:

   hex:
   1c f8 f4 2b 5a 9f 80 fa e9 f8

   binary:
   00011100 11111000 11110100 00101011 01011010
   10011111 10000000 11111010 11101001 11111000

   binary in groups of 5:
   00011 10011 11100 01111 01000 01010 11010 11010
   10011 11110 00000 01111 10101 11010 01111 11000

   decimal of each group:
   3 19 28 15 8 10 26 26 19 30 0 15 21 26 15 24

   Translating each decimal value using table 3 in Base32 [6] yields the
   character sequence DT4PIK22T6APV2PY.  Thus the SASL mechanism name
   for the SPKM-1 GSSAPI mechanism is "GS2-DT4PIK22T6APV2PY".

Thanks,
Simon

To: [email-masked]
Subject: volunteer for text on non-integrity mechanisms in GS2?
From: Tom Yu <[email-masked]>
Date: Wed, 29 Nov 2006 20:51:28 -0500
Lines: 7
Sender: [email-masked]

During the SASL WG session at IETF67, there was a suggestion that
people who want support for non-integrity GSS-API mechanisms in GS2 be
the ones to write the text.  If you are interested and are willing to
write the text, please respond before Friday of next week (December
8).

---Tom

Date: Wed, 29 Nov 2006 10:28:13 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Request for feedback: use of HTTP-style BNF in DIGEST-MD5?
Cc: SASL WG <[email-masked]>
Sender: [email-masked]

My personal opinion is that RFC 4234 ABNF should generally be used
instead of other ABNFs unless there is a good reason not to.  A
good reason, in this particular case, would be consistency with
RFC 2617.  That is, I think it reasonable to keep the current
ABNF here.

-- Kurt

At 12:43 PM 11/24/2006, Alexey Melnikov wrote:

>Hi everybody.
>
>Frank has requested to replace #rule construct with RFC 4234 ABNF in the DIGEST-MD5 document. This is not a trivial change (and I can inadvertently introduce new errors), so I would like to poll the WG about doing this.
>Opinions please!
>
>Regards,
>Alexey

Date: Tue, 28 Nov 2006 15:01:05 -0800
To: [email-masked], [email-masked]
Subject:  RFC 4752 on The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism
From: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4752

        Title:      The Kerberos V5 ("GSSAPI") Simple 
                    Authentication and Security Layer (SASL) Mechanism 
        Author:     A. Melnikov, Ed.
        Status:     Standards Track
        Date:       November 2006
        Mailbox:    [email-masked]
        Pages:      10
        Characters: 22133
        Obsoletes:  RFC2222
        See-Also:   

        I-D Tag:    draft-ietf-sasl-gssapi-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4752.txt

The Simple Authentication and Security Layer (SASL) is a
framework for adding authentication support to connection-based
protocols.  This document describes the method for using the Generic
Security Service Application Program Interface (GSS-API) Kerberos V5
in the SASL.

This document replaces Section 7.2 of RFC 2222, the definition of the
"GSSAPI" SASL mechanism.  This document, together with RFC 4422,
obsoletes RFC 2222.  [STANDARDS TRACK]

This document is a product of the Simple Authentication and Security Layer
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

Date: Mon, 27 Nov 2006 18:45:52 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
cc: Jeffrey Hutzelman <[email-masked]>
Subject: Re: Identifying channel bindings
Originator-Info: login-token=Mulberry:01dvGbi+BZEP/CPBMMqW/L+g1j0rb9JRTjZsnwrHE=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, November 27, 2006 11:13:43 AM -0600 Nicolas Williams 
<[email-masked]> wrote:

>
> I just spoke to Sam about this.
>
> One the one hand he believes that this is out of scope for GS2.  On the
> other hand he believes that it will be easier to ensure that channel
> bindings for *different* channel types cannot be confused if we add this
> channel binding type prefix to the channel bindings strings.
>
> Basically, if the unique channel bindings for two different channel
> types are such that an MITM could control a prefix of one and a suffix
> of the other then the MITM could substitute chhanel types and cause the
> channel bindings to match.
>
> While I believe that we can and should make sure that the definition of
> unique channel bindings does not allow such contructions where an MITM
> controls a sub-string of the channel bindings, I do agree with Sam that
> adding a type prefix is a very simple change.  But again, this is out of
> scope for GS2 (though GS2 might not progress until the normative
> reference for channel bindings stabilizes and/or progresses.

Out of scope for GS2, but not for the channel bindings documents, and I do 
think it's a good idea, for a variety of reasons.

-- Jeff

Date: Mon, 27 Nov 2006 18:36:02 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: GS2 update
Originator-Info: login-token=Mulberry:01n//pcglnXubrSmHz0n0Z4TZxIJ0mM2IMdBfX1X8=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, November 27, 2006 04:18:55 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

>    conf_req_flag     boolean, read
>                      Non-zero - Both confidentiality and integrity
>                                 services are requested
>                      Zero - Only integrity service is requested
>
> How do we square this with RFC2743 section 1.2.2?

Reintrepret "only integrity service is requested" as "confidentiality 
service is not requested".

This is probably something it would be good to ask Martin about, since he 
not only was probably there when that text was written, but is probably the 
world's foremost authority on bizarre GSS mechanisms that no one else has 
ever seen.  Perhaps he can give us an idea of whether mechs that don't 
provide integrity are likely to support GSS_Wrap at all.

>> Right.  Such an interface will exist in the not-too-distant future, and
>> there's no reason SASL/GS2 implementors can't use it when it becomes
>> available.
>
> Note that what you're proposing changes nothing on the wire for GS2,
> it just adds text requiring that implementations check the return flags
> from GSS_Init/Accept_sec_context() and text about what to do when
> neither conf_avail nor integ_avail are set.

Correct.

-- Jeff

Date: Mon, 27 Nov 2006 16:18:55 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Nov 27, 2006 at 05:00:10PM -0500, Jeffrey Hutzelman wrote:
> On Monday, November 27, 2006 11:46:55 AM -0600 Nicolas Williams 
> <[email-masked]> wrote:
> >Er, no, I think I can live with mechs that provide GSS_Wrap() but no
> >conf/integ protection.
> 
> And I, in turn, am happy with requiring mechs that don't provide 
> confidentiality or integrity protection to nonetheless support GSS_Wrap, as 
> described in RFC2743 section 1.2.2.

I'm confused by the text in RFC2743, 2.2.7, and RFC2744, section 5.33,
specifically the latter, in relation to RFC2743 section 1.2.2:

   OM_uint32 gss_wrap (
     OM_uint32          *minor_status,
     const gss_ctx_id_t context_handle,
     int               conf_req_flag,
     gss_qop_t          qop_req
     const gss_buffer_t input_message_buffer,
     int                *conf_state,
     gss_buffer_t       output_message_buffer )
...
   conf_req_flag     boolean, read
                     Non-zero - Both confidentiality and integrity
                                services are requested
                     Zero - Only integrity service is requested

How do we square this with RFC2743 section 1.2.2?

I guess that's another clarification that we need:  if the security
context did not have GSS_C_INTEG_FLAG (integ_avail) set then gss_wrap()
with conf_req_flag == 0 -> identity function (plus, possibly, some
header?).

Of course, some mechanisms would never fail to provide integrity
protection (e.g., krb5).  And there's no way to request no integrity
protection when that is offered by the mechanism.

>                                      That means that supporting these 
> mechanisms requires no wire protocol changes to GS2; all that is required 
> is text about checking that integ_avail is true if the app wanted a 
> security layer or channel binding (and in general, we need text about 
> checking statuses and context feature flags if we don't already have it).

Yes.

> >There should be an implementation note explaining that the GSS-API does
> >not (yet) provide an interface through which the app can discover what
> >mechanisms support confidentiality or integrity protection, so that
> >naive apps may negotiate mechanisms that offer neither.  As long as such
> >apps did not need a security layer and were not doing any channel
> >binding then all is fine.
> 
> Right.  Such an interface will exist in the not-too-distant future, and 
> there's no reason SASL/GS2 implementors can't use it when it becomes 
> available.

Note that what you're proposing changes nothing on the wire for GS2,
it just adds text requiring that implementations check the return flags
from GSS_Init/Accept_sec_context() and text about what to do when
neither conf_avail nor integ_avail are set.

Nico
-- 

Date: Mon, 27 Nov 2006 17:00:10 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
cc: Jeffrey Hutzelman <[email-masked]>
Subject: Re: GS2 update
Originator-Info: login-token=Mulberry:01b8MczdkrkUG7DpROokFMPAY1U/j295XcOEoypUM=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, November 27, 2006 11:46:55 AM -0600 Nicolas Williams 
<[email-masked]> wrote:

> On Mon, Nov 27, 2006 at 10:19:06AM -0600, Nicolas Williams wrote:
>> On Thu, Nov 23, 2006 at 12:42:40AM +0100, Simon Josefsson wrote:
>> >
>> > Nicolas Williams <[email-masked]> writes:
>> >
>> > > I vote for not supporting GSS mechanisms that don't provide
>> > > GSS_Wrap().
>> >
>> > +1.
>> >
>> > How about mechanisms that provide GSS_Wrap without integrity
>> > protection?  That is allowed by RFC 2743 section 1.2.2.  I'm not sure
>> > whether you assumed that GSS_Wrap always provide integrity or not.
>>
>> That's what I meant, GSS_Wrap() with integrity protection should be a
>> requirement for GS2.
>
> Er, no, I think I can live with mechs that provide GSS_Wrap() but no
> conf/integ protection.

And I, in turn, am happy with requiring mechs that don't provide 
confidentiality or integrity protection to nonetheless support GSS_Wrap, as 
described in RFC2743 section 1.2.2.  That means that supporting these 
mechanisms requires no wire protocol changes to GS2; all that is required 
is text about checking that integ_avail is true if the app wanted a 
security layer or channel binding (and in general, we need text about 
checking statuses and context feature flags if we don't already have it).

> There should be an implementation note explaining that the GSS-API does
> not (yet) provide an interface through which the app can discover what
> mechanisms support confidentiality or integrity protection, so that
> naive apps may negotiate mechanisms that offer neither.  As long as such
> apps did not need a security layer and were not doing any channel
> binding then all is fine.

Right.  Such an interface will exist in the not-too-distant future, and 
there's no reason SASL/GS2 implementors can't use it when it becomes 
available.

-- Jeff

Date: Mon, 27 Nov 2006 11:46:55 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Mail-Followup-To: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Nov 27, 2006 at 10:19:06AM -0600, Nicolas Williams wrote:
> On Thu, Nov 23, 2006 at 12:42:40AM +0100, Simon Josefsson wrote:
> > 
> > Nicolas Williams <[email-masked]> writes:
> > 
> > > I vote for not supporting GSS mechanisms that don't provide GSS_Wrap().
> > 
> > +1.
> > 
> > How about mechanisms that provide GSS_Wrap without integrity
> > protection?  That is allowed by RFC 2743 section 1.2.2.  I'm not sure
> > whether you assumed that GSS_Wrap always provide integrity or not.
> 
> That's what I meant, GSS_Wrap() with integrity protection should be a
> requirement for GS2.

Er, no, I think I can live with mechs that provide GSS_Wrap() but no
conf/integ protection.

Jeff's reply just now makes me happy with this.

There should be an implementation note explaining that the GSS-API does
not (yet) provide an interface through which the app can discover what
mechanisms support confidentiality or integrity protection, so that
naive apps may negotiate mechanisms that offer neither.  As long as such
apps did not need a security layer and were not doing any channel
binding then all is fine.

Nico
-- 

Date: Mon, 27 Nov 2006 11:13:43 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Identifying channel bindings
Mail-Followup-To: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

I just spoke to Sam about this.

One the one hand he believes that this is out of scope for GS2.  On the
other hand he believes that it will be easier to ensure that channel
bindings for *different* channel types cannot be confused if we add this
channel binding type prefix to the channel bindings strings.

Basically, if the unique channel bindings for two different channel
types are such that an MITM could control a prefix of one and a suffix
of the other then the MITM could substitute chhanel types and cause the
channel bindings to match.

While I believe that we can and should make sure that the definition of
unique channel bindings does not allow such contructions where an MITM
controls a sub-string of the channel bindings, I do agree with Sam that
adding a type prefix is a very simple change.  But again, this is out of
scope for GS2 (though GS2 might not progress until the normative
reference for channel bindings stabilizes and/or progresses.

Nico
-- 

Date: Mon, 27 Nov 2006 11:55:09 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: GS2 update
Originator-Info: login-token=Mulberry:01J3fcu5HfUS9zwlQ8WvUMKr7pE+auq1WU7AogXfc=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, November 22, 2006 08:35:26 PM +0100 Simon Josefsson 
<[email-masked]> wrote:

>> I don't see how this follows, either.  You permit the non-integrity
>> mode only for mechanisms which are known not to support integrity
>> protection.
>
> With that approach GS2 doesn't seem to be able to handle GSS-API
> mechanisms that supports integrity but let it be up to the credentials
> whether integrity is enabled or not.  See:

It can certainly handle such mechanisms, provided the only uses are those 
which provide integrity protection.  Basically, the idea is that if you 
have a mech which can do integrity, you don't allow a downgrade to a mode 
which doesn't support it.  But if you have a mech which never supports 
integrity, then you do allow its use, under the theory that if a client or 
service was unwilling to accept that, it wouldn't use that mechanism at all 
(just like it wouldn't use PLAIN).

> http://article.gmane.org/gmane.ietf.sasl/2615
> http://article.gmane.org/gmane.ietf.sasl/2617

In fact, rereading these, it is clear from Nico's text (quoted in 2615) 
what needs to happen - you _can_ support mechanisms in which integrity is 
only available some of the time, but SASL authentication must fail if the 
application wanted channel bindings or a security layer, since you can't 
provide those if the GSS mech doesn't provide integrity.

>> RFC2743 deliberately doesn't specify the exact form of OID's or any
>> other data type, because it is an abstract interface.  Those details
>> are left up to the particular language bindings.
>
> That is unfortunate since it means GS2 cannot assume implementation
> have the OID in any particular form.

Well, you can't make assumptions about implementations, but you can look at 
what the language bindings specifications say.  Also, as Nico points out, 
the standard framing specified by RFC2743 does use encoded OID's on the 
wire.  I think it's pretty clear that's the right form to use here.  If you 
don't think the existing text is clear enough (and it might not be), I 
encourage you to extract the text from RFC4462 section 2.3, and modify it 
as needed (IIRC, you will need to change base64 to base32, since SASL mech 
names are case-insensitive).

> Is it BER/DER?  I thought for BER/DER you'll need the tag 0x06 and
> length 0x07.  I call the OID without the DER/BER tag+length "raw".

Call it what you want, but there is no such thing as a "raw" OID.  An OID 
is a structured value, and must be represented in some form.  The form 
we're talking about is defined in the ASN.1 encoding rules as the encoded 
form of an OBJECT IDENTIFIER.

> The lowest-common denominator here seem to be DER encoded OID's
> without the tag+length, which isn't what GS2 is using now.

So, I didn't care much when this issue came up in SSH, and I don't care 
much now.  However, I do believe there is something to be said for 
consistency.

-- Jeff

Date: Mon, 27 Nov 2006 10:51:41 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: TLS channel bindings, again (Re: GS2 update)
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Nov 23, 2006 at 12:35:16AM +0100, Simon Josefsson wrote:
> Nicolas Williams <[email-masked]> writes:
> > On Wed, Nov 22, 2006 at 08:30:56PM +0100, Simon Josefsson wrote:
> >> Nicolas Williams <[email-masked]> writes:
> >> > On Wed, Nov 22, 2006 at 06:10:38PM +0100, Simon Josefsson wrote:
> > Most likely there will be nothing for us to do because noone will care
> > to update draft-altman-tls-channel-bindings because the TLS 1.2 proposal
> > does not radically change the TLS handshake sequence, which will still
> > end with finished message exchanges whose cryptographic construction
> > will not differ fundamentally from TLS 1.1.
> 
> Right.
> 
> An alternative to avoid this entire situation, and to use a more
> abstract interface to TLS, is to use the TLS PRF to compute a unique
> channel binding for this purpose.  This is something several EAP
> mechanisms already do.  That is what I propose in
> draft-josefsson-sasl-tls-cb.

If we can imagine TLS 1.2 dropping the finished messages then we can
imagine TLS 1.2 dropping the PRF.

Since TELNET w/ StartTLS already depends on the TLS finished messages as
a channel binding, and since other protocols (EAP-TLS) depend on the TLS
PRF and session keys, I think it behooves the TLS WG to keep from
breaking these protocols.

Of course, the TLS WG charter is very specific as to what TLS 1.2 will
entail and it does not mention radical protocol changes.  A future TLS
1.3 might make such changes though, so the problem doesn't go away.

So, I think draft-altman-tls-channel-bindings needs text like I
proposed.

Finally, we've had the PRF vs. finished msgs discussion.  I'm not
changing my mind on use of the TLS finished messages.

One of the arguments for using the finished msgs instead of the PRF was
that the finished msgs bind more of the TLS handshake than just the PRF
does.  And I find this a very solid argument.

> Thanks, this seems very good to me.  Together with my suggested text
> to provide a default TLS channel binding for any application protocol,
> I believe this would solve my technical concerns with the draft.

Sure.

> (I think your paragraph becomes slightly more clear if the
> qualification 'passive' is dropped from the start of b)...  the
> property must hold for any kind of attacker.)

Well, OK.

> > The TLS PRF had better be a one way function.  Eric acknowledges this.
> > I believe his nervousness notwithstanding nothing more needs to be done
> > here.
> 
> What is accomplished by your paragraph above seems sufficient to me.

Good.

Nico
-- 

Date: Mon, 27 Nov 2006 10:19:07 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Mail-Followup-To: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Nov 23, 2006 at 12:42:40AM +0100, Simon Josefsson wrote:
> 
> Nicolas Williams <[email-masked]> writes:
> 
> > I vote for not supporting GSS mechanisms that don't provide GSS_Wrap().
> 
> +1.
> 
> How about mechanisms that provide GSS_Wrap without integrity
> protection?  That is allowed by RFC 2743 section 1.2.2.  I'm not sure
> whether you assumed that GSS_Wrap always provide integrity or not.

That's what I meant, GSS_Wrap() with integrity protection should be a
requirement for GS2.

Nico
-- 

Date: Mon, 27 Nov 2006 10:17:31 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Identifying channel bindings
Mail-Followup-To: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Nov 23, 2006 at 12:21:26AM +0100, Simon Josefsson wrote:
> I agree with this -- from an implementation point of view, a SASL
> library may implement channel binding by invoking a callback to the
> application requesting the channel binding for a particular protocol.
> The application will need to know which protocol to find out the
> channel binding for.

There's ways around this.  If there's more than one possible channel to
bind to then have the app furnish the bindings for all of them, then
SASL/GS2 can check each one.

> Without this information, the application won't know whether to ask
> the TLS vs IPSec etc layer for the channel binding.

Or which type of channel binding (unique vs. end-point).  But, see
above.

Date: Mon, 27 Nov 2006 10:15:17 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: Identifying channel bindings
Mail-Followup-To: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 22, 2006 at 10:39:15PM +0000, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >Your concern then is that applications could be fooled into using the
> >channel bindings of a different channel than they actually use, right?
> > 
> >
> Partly, from an application point of view, a channel binding is just a 
> random sequence of bytes.

Pretty much, yes.

> But I also want give applications ability to know which type of channel 
> binding (e.g. TLS versa SSH versa IPSec) the other end is sending. This 
> will enable applications to lookup/verify the corresponding channel 
> binding on their end.

In the GSS-API world there's no negotiation of channel binding by the
GSS-API mechanisms, so apps have to know a priori or negotiate in the
app protocol.

In the SASL/GS2 conception of channel binding the mechanism (GS2)
negotiates whether to use channel bindings, and this affects the
negotiation of security layers.

What you're saying is that if there is more than one possible channel to
bind to then GS2 needs to be able to negotiate which channel to bind to.

Besides being a rare occurrence, I think in general apps should bind to
the highest layer secure channel available so that in practice no
negotiation of which channel to bind to should be necessary.  And if
SASL/GS2 channel binding fails due to confusion about which channel to
bind to, well, there should be no harm since this failure should only
affect the security layer negotiation.

A more likely scenario might be where the channel being bound to has
both, unique and end-point channel bindings, and the app has to pick
one.  But here the peer of whichever node sends the channel bindings
first can just check both.

This is Simon's cue to bring up multi-channel binding.  But note that I
will continue to insist that if we want to finish any time soon then
multi-channel binding is way out of scope for GS2.

If we believe that channel binding type negotiation is going to be a
problem, and I'm not sure that it is, then a channel binding type
identifier would be useful.

Nico
-- 

Date: Fri, 24 Nov 2006 20:43:05 +0000
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Request for feedback: use of HTTP-style BNF in DIGEST-MD5?
Sender: [email-masked]

Hi everybody.

Frank has requested to replace #rule construct with RFC 4234 ABNF in the 
DIGEST-MD5 document. This is not a trivial change (and I can 
inadvertently introduce new errors), so I would like to poll the WG 
about doing this.
Opinions please!

Regards,
Alexey

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 23 Nov 2006 00:42:40 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> I vote for not supporting GSS mechanisms that don't provide GSS_Wrap().

+1.

How about mechanisms that provide GSS_Wrap without integrity
protection?  That is allowed by RFC 2743 section 1.2.2.  I'm not sure
whether you assumed that GSS_Wrap always provide integrity or not.

> I vote for allowing GSS mechanisms that don't provide GSS_Wrap() with
> confidentiality, but only when the application doesn't want
> confidentiality protection or when it is doing channel binding and
> doesn't want a confidentiality security layer if channel binding
> succeeds.

+1.

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 23 Nov 2006 00:35:16 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Nov 22, 2006 at 08:30:56PM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[email-masked]> writes:
>> > On Wed, Nov 22, 2006 at 06:10:38PM +0100, Simon Josefsson wrote:
>> >> Nicolas Williams <[email-masked]> writes:
>> 
>> >> There are also two problems that I brought up long time ago: re-using
>> >> the TLS finished messages create a hard-coded dependency on MD5 and
>> >> SHA1 which is a bad idea.
>> >
>> > This is nonsense.  This is a TLS hash agility issue, not a GS2 hash
>> > agility issue.  And TLS 1.2 will fix this (as long as it doesn't remove
>> > or fundamentally change the notion of finished messages).
>> 
>> The draft-altman-tls-channel-bindings document reference TLS 1.1.  If
>> it the document is intended to automatically work with TLS 1.2 --
>> which isn't clear to me -- I believe some additional discussion about
>> that needs to be added.  Here is a strawman, although it is quite
>> abstract on the requirements that is placed on TLS:
>
> While I can imagine TLS 1.2 changing the TLS handshake model in a
> sufficiently radical fashion that draft-altman-tls-channel-bindings
> cannot apply to TLS 1.2, I doubt it will.
>
> In the absolute worst case scenario we have to work the channel bindings
> for TLS 1.2 from scratch.  I don't think it will come to that, so...
>
> ...the worst case scenario is that we need to update
> draft-altman-tls-channel-bindings later (presumably and RFC by then) to
> say "and this works for TLS 1.2 as well."
>
> Most likely there will be nothing for us to do because noone will care
> to update draft-altman-tls-channel-bindings because the TLS 1.2 proposal
> does not radically change the TLS handshake sequence, which will still
> end with finished message exchanges whose cryptographic construction
> will not differ fundamentally from TLS 1.1.

Right.

An alternative to avoid this entire situation, and to use a more
abstract interface to TLS, is to use the TLS PRF to compute a unique
channel binding for this purpose.  This is something several EAP
mechanisms already do.  That is what I propose in
draft-josefsson-sasl-tls-cb.

> Input from our AD on process issues relating to protocol versioning may
> be useful here.

Sure.

>>   This channel binding specification can support any TLS version that
>>   have the same notion of finished messages.  In particular, if the
>>   hash agility concern inherent in TLS 1.1 finished messages is solved
>>   within the finished message, this channel binding specification
>>   automatically uses it.
>
> I would phrase it differently.
>
>    This channel binding specification depends on the cryptographic
>    construction of TLS finished messages as tokens that bind the TLS
>    handshake messages and TLS secrets, such as the master secret, in
>    such a cryptographically strong manner such that: a) active attackers
>    cannot influence the computation of the finished messages for a given
>    handshake equally at the TLS client and server and get any benefit
>    (such as discovering all of part of the session's TLS master secret),
>    b) passive attackers cannot reconstruct any of the session's secrets
>    from the finished messages, whether sent encrypted or otherwise.
>
>    Future versions of TLS might change the handshake protocol such that
>    this channel binding construction is no longer valid for such
>    versions of TLS.

Thanks, this seems very good to me.  Together with my suggested text
to provide a default TLS channel binding for any application protocol,
I believe this would solve my technical concerns with the draft.

(I think your paragraph becomes slightly more clear if the
qualification 'passive' is dropped from the start of b)...  the
property must hold for any kind of attacker.)

>From a design point of view, I still prefer to use the TLS PRF
directly rather than relying on TLS finished messages.

>> >>                            It has also not been proven that revealing
>> >> the TLS finished messages, the first messages to be encrypted over a
>> >> TLS channel, to attackers is a safe thing.  It feels like a
>> >> sub-optimal solution to me.
>> >
>> > Simon, this is getting annoying.  Eric answered this solidly.  Besides,
>> > providing confidentiality protection for these in GS2 is no sweat (isn't
>> > it even the default?).
>> 
>> Whether GS2 provides confidentiality for this is irrelevant.
>> draft-altman-tls-channel-bindings is intended for other purposes too.
>> 
>> Eric wrote in http://article.gmane.org/gmane.ietf.sasl/2364 that he'd
>> rather see the finished messages hashed to avoid any possibility of a
>> problem here.
>
> The TLS PRF had better be a one way function.  Eric acknowledges this.
> I believe his nervousness notwithstanding nothing more needs to be done
> here.

What is accomplished by your paragraph above seems sufficient to me.

/Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: Identifying channel bindings
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 23 Nov 2006 00:21:26 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Nicolas Williams wrote:
>
>>>Is there a way to uniquely identify a channel binding type from the
>>>"canonical octet string"? If there is none, then a separate registry
>>>for channel binding names is needed, as different channel binding types
>>>can end up producing the same sequence of octets. Also a SASL mechanism
>>>implementation might need to know which channel binding type is used
>>>by an application level protocol, in case multiple are available.
>>>    
>>>
>>draft-williams-on-channel-binding describes two types of channel
>>bindings: "unique" and "end-point" channel bindings.
>>
>>"Unique" channel bindings had better be just that, unique.  No two
>>channels of any kind should produce the same unique channel bindings,
>>else something is very badly broken.
>>
>>The same is not true of "end-point" channel bindings.
>>
>>Your concern then is that applications could be fooled into using the
>>channel bindings of a different channel than they actually use, right?
>>  
>>
> Partly, from an application point of view, a channel binding is just a
> random sequence of bytes.
>
> But I also want give applications ability to know which type of
> channel binding (e.g. TLS versa SSH versa IPSec) the other end is
> sending. This will enable applications to lookup/verify the
> corresponding channel binding on their end.

I agree with this -- from an implementation point of view, a SASL
library may implement channel binding by invoking a callback to the
application requesting the channel binding for a particular protocol.
The application will need to know which protocol to find out the
channel binding for.

Without this information, the application won't know whether to ask
the TLS vs IPSec etc layer for the channel binding.

/Simon

Date: Wed, 22 Nov 2006 22:39:15 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: [email-masked]
Subject: Identifying channel bindings
Sender: [email-masked]

Nicolas Williams wrote:

>>Is there a way to uniquely identify a channel binding type from the
>>"canonical octet string"? If there is none, then a separate registry
>>for channel binding names is needed, as different channel binding types
>>can end up producing the same sequence of octets. Also a SASL mechanism
>>implementation might need to know which channel binding type is used
>>by an application level protocol, in case multiple are available.
>>    
>>
>draft-williams-on-channel-binding describes two types of channel
>bindings: "unique" and "end-point" channel bindings.
>
>"Unique" channel bindings had better be just that, unique.  No two
>channels of any kind should produce the same unique channel bindings,
>else something is very badly broken.
>
>The same is not true of "end-point" channel bindings.
>
>Your concern then is that applications could be fooled into using the
>channel bindings of a different channel than they actually use, right?
>  
>
Partly, from an application point of view, a channel binding is just a 
random sequence of bytes.

But I also want give applications ability to know which type of channel 
binding (e.g. TLS versa SSH versa IPSec) the other end is sending. This 
will enable applications to lookup/verify the corresponding channel 
binding on their end.

>I don't think this concern is realistic, but I don't mind this prefix
>either (in fact, some of my I-Ds have used such prefixes).
>  
>

Date: Wed, 22 Nov 2006 22:33:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: [email-masked]
Subject: IANA registry for channel bindings
Sender: [email-masked]

Nicolas Williams wrote:

> Having such prefixes does not mean we need an IANA registry. 

Why not? IANA registries are easy to define.

Remember, IANA is also for developers searching for specs defining 
channel bindings.
Currently, I can find pretty much any spec type on IANA. E.g. I can find 
SASL mechanism, MIME headers, etc.

> The set of

> channel types for which we need channel bindings is very small.

Date: Wed, 22 Nov 2006 22:30:43 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Sender: [email-masked]

Nicolas Williams wrote:

>On Wed, Nov 22, 2006 at 09:37:25PM +0000, Alexey Melnikov wrote:
>  
>
>>Nicolas Williams wrote:
>>    
>>
>>>On Wed, Nov 22, 2006 at 06:10:38PM +0100, Simon Josefsson wrote:
>>>      
>>>
>>[Nico, I've sent the message on this to you and got vacation autoreply]
>>    
>>
>
>A while back?  OK, I'll look.
>  
>
Last week.

>>Here what I wrote regarding draft-altman-tls-channel-bindings-00:
>>
>>Additional requirements for channel bindings (add to section 2.1):
>>
>> o  Specifications of channel bindings for any secure channels MUST
>>    provide for a single, canonical octet string encoding of the
>>    channel bindings.
>>
>>Add to the end of this sentence:
>> Each encoding MUST have a registered name.
>>
>>(And the name should be registered with IANA)
>>    
>>
>I am guessing that what you mean is that you want a well-known *prefix*
>to all channel binding octet strings that identifies the type of channel
>named.
>  
>
Either prefix or a separate label.

Date: Wed, 22 Nov 2006 16:28:16 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Mail-Followup-To: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 22, 2006 at 09:37:25PM +0000, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >On Wed, Nov 22, 2006 at 06:10:38PM +0100, Simon Josefsson wrote:
> [Nico, I've sent the message on this to you and got vacation autoreply]

A while back?  OK, I'll look.

> Here what I wrote regarding draft-altman-tls-channel-bindings-00:
> 
> Additional requirements for channel bindings (add to section 2.1):
> 
>  o  Specifications of channel bindings for any secure channels MUST
>     provide for a single, canonical octet string encoding of the
>     channel bindings.
> 
> Add to the end of this sentence:
>  Each encoding MUST have a registered name.
> 
> (And the name should be registered with IANA)

I am guessing that what you mean is that you want a well-known *prefix*
to all channel binding octet strings that identifies the type of channel
named.

Is that so?  See below.

> Is there a way to uniquely identify a channel binding type from the
> "canonical octet string"? If there is none, then a separate registry
> for channel binding names is needed, as different channel binding types
> can end up producing the same sequence of octets. Also a SASL mechanism
> implementation might need to know which channel binding type is used
> by an application level protocol, in case multiple are available.

draft-williams-on-channel-binding describes two types of channel
bindings: "unique" and "end-point" channel bindings.

"Unique" channel bindings had better be just that, unique.  No two
channels of any kind should produce the same unique channel bindings,
else something is very badly broken.

The same is not true of "end-point" channel bindings.

Your concern then is that applications could be fooled into using the
channel bindings of a different channel than they actually use, right?
I don't think this concern is realistic, but I don't mind this prefix
either (in fact, some of my I-Ds have used such prefixes).

Having such prefixes does not mean we need an IANA registry.  The set of
channel types for which we need channel bindings is very small.

Nico
-- 

Date: Wed, 22 Nov 2006 21:37:25 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Sender: [email-masked]

Nicolas Williams wrote:

>On Wed, Nov 22, 2006 at 06:10:38PM +0100, Simon Josefsson wrote:
>  
>
>>Nicolas Williams <[email-masked]> writes:
>>    
>>
>>>Could you remind us what the issues are with Jeff's I-D?
>>>
>>>I thought we were done with the TLS channel binding specification.
>>>      
>>>
>>[...]
>>There is another potential problems with Jeff's draft: ambiguity
>>between channel bindings for two different security protocols.  The
>>IANA registry that Alexey proposed would solve it.
>>    
>>
>I don't follow.
>  
>
[Nico, I've sent the message on this to you and got vacation autoreply]

Here what I wrote regarding draft-altman-tls-channel-bindings-00:

Additional requirements for channel bindings (add to section 2.1):

  o  Specifications of channel bindings for any secure channels MUST
     provide for a single, canonical octet string encoding of the
     channel bindings.

Add to the end of this sentence:
  Each encoding MUST have a registered name.

(And the name should be registered with IANA)

Is there a way to uniquely identify a channel binding type from the
"canonical octet string"? If there is none, then a separate registry
for channel binding names is needed, as different channel binding types
can end up producing the same sequence of octets. Also a SASL mechanism
implementation might need to know which channel binding type is used
by an application level protocol, in case multiple are available.

Date: Wed, 22 Nov 2006 15:16:29 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 22, 2006 at 12:35:02PM -0500, Jeffrey Hutzelman wrote:
> RFC2743 deliberately doesn't specify the exact form of OID's or any other 
> data type, because it is an abstract interface.  Those details are left up 
> to the particular language bindings.

But in the specific cases of the initial context token header and
exported name tokens RFC2743 is quite clear.

>                                       For C, RFC2744 specifies the same 
> encoding use for the "value" part of an OID tag in BER; perhaps this is 
> what you mean by "raw"?  It is easy enough to add the tag and length when 
> required.

The C bindings don't use the tag and length.  SSHv2 does use the tag and
length in computing the kex alg name of GSS mech OIDs.

> Given that implementations which use hard-coded values need compute them 
> only once, while implementations which construct a list of mech names based 
> on the result of GSS_Indicate_mechs() need to compute them every time, it 
> would seem appropriate to optimize for the latter.  This is also consistent 
> with the current document and with what has already been done in places 
> like SSH.

Yes.  If need be copy-paste text from the SSHv2/GSS spec (RFC4462).

Date: Wed, 22 Nov 2006 15:05:07 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Mail-Followup-To: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 22, 2006 at 05:46:12PM +0100, Simon Josefsson wrote:
> On Wed, 2006-11-22 at 14:39 +0000, Alexey Melnikov wrote:
> > Are we settled on NOT using BER encoding or not?
> 
> Oh, that's an interesting question.  I don't care strongly either way.
> There are some considerations though.

I do care.  The GSS-API itself deals in encoded OIDs.  Therefore it's
easier to use the encoded OIDs.

> First, if we assume that implementers will compute GS2 mech names for
> the mechanisms they support by hand, and hard-code that name in the
> implementation, the difference seem marginal.  An ASCII-encoding is
> easier to get right than a DER-encoding, but not significantly.
> 
> If on the other hand we assume that implementers will dynamically
> translate GSS-API mechanism OIDs to GS2 mech names, the situation is
> different.  Some GSS-API interfaces return mech names as OIDs, e.g.
> GSS_Init_sec_context.  To me right now RFC 2743 is unclear whether they
> are intended to be raw, DER-, or BER-encoded.  (RFC 2744 section 3.3
> suggests they are raw?)  But most certainly they are in one of those
> formats, and definitely not in ASCII format.

The BER, DER, CER, PER encodings of OBJECT IDENTIFIER are ALL the same.

The GSS-API deals in encoded OIDs *always* (earlier versions of it had
utility functions for parsing ASCII OID strings and for displaying
OIDs).

Nico
-- 

Date: Wed, 22 Nov 2006 15:02:35 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Mail-Followup-To: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Sender: [email-masked]

I vote for not supporting GSS mechanisms that don't provide GSS_Wrap().

I vote for allowing GSS mechanisms that don't provide GSS_Wrap() with
confidentiality, but only when the application doesn't want
confidentiality protection or when it is doing channel binding and
doesn't want a confidentiality security layer if channel binding
succeeds.

Nico
-- 

Date: Wed, 22 Nov 2006 14:58:24 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: GS2 update
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 22, 2006 at 08:30:56PM +0100, Simon Josefsson wrote:
> Nicolas Williams <[email-masked]> writes:
> > On Wed, Nov 22, 2006 at 06:10:38PM +0100, Simon Josefsson wrote:
> >> Nicolas Williams <[email-masked]> writes:
> 
> >> There are also two problems that I brought up long time ago: re-using
> >> the TLS finished messages create a hard-coded dependency on MD5 and
> >> SHA1 which is a bad idea.
> >
> > This is nonsense.  This is a TLS hash agility issue, not a GS2 hash
> > agility issue.  And TLS 1.2 will fix this (as long as it doesn't remove
> > or fundamentally change the notion of finished messages).
> 
> The draft-altman-tls-channel-bindings document reference TLS 1.1.  If
> it the document is intended to automatically work with TLS 1.2 --
> which isn't clear to me -- I believe some additional discussion about
> that needs to be added.  Here is a strawman, although it is quite
> abstract on the requirements that is placed on TLS:

While I can imagine TLS 1.2 changing the TLS handshake model in a
sufficiently radical fashion that draft-altman-tls-channel-bindings
cannot apply to TLS 1.2, I doubt it will.

In the absolute worst case scenario we have to work the channel bindings
for TLS 1.2 from scratch.  I don't think it will come to that, so...

...the worst case scenario is that we need to update
draft-altman-tls-channel-bindings later (presumably and RFC by then) to
say "and this works for TLS 1.2 as well."

Most likely there will be nothing for us to do because noone will care
to update draft-altman-tls-channel-bindings because the TLS 1.2 proposal
does not radically change the TLS handshake sequence, which will still
end with finished message exchanges whose cryptographic construction
will not differ fundamentally from TLS 1.1.

Input from our AD on process issues relating to protocol versioning may
be useful here.

>   This channel binding specification can support any TLS version that
>   have the same notion of finished messages.  In particular, if the
>   hash agility concern inherent in TLS 1.1 finished messages is solved
>   within the finished message, this channel binding specification
>   automatically uses it.

I would phrase it differently.

   This channel binding specification depends on the cryptographic
   construction of TLS finished messages as tokens that bind the TLS
   handshake messages and TLS secrets, such as the master secret, in
   such a cryptographically strong manner such that: a) active attackers
   cannot influence the computation of the finished messages for a given
   handshake equally at the TLS client and server and get any benefit
   (such as discovering all of part of the session's TLS master secret),
   b) passive attackers cannot reconstruct any of the session's secrets
   from the finished messages, whether sent encrypted or otherwise.

   Future versions of TLS might change the handshake protocol such that
   this channel binding construction is no longer valid for such
   versions of TLS.

> >>                            It has also not been proven that revealing
> >> the TLS finished messages, the first messages to be encrypted over a
> >> TLS channel, to attackers is a safe thing.  It feels like a
> >> sub-optimal solution to me.
> >
> > Simon, this is getting annoying.  Eric answered this solidly.  Besides,
> > providing confidentiality protection for these in GS2 is no sweat (isn't
> > it even the default?).
> 
> Whether GS2 provides confidentiality for this is irrelevant.
> draft-altman-tls-channel-bindings is intended for other purposes too.
> 
> Eric wrote in http://article.gmane.org/gmane.ietf.sasl/2364 that he'd
> rather see the finished messages hashed to avoid any possibility of a
> problem here.

The TLS PRF had better be a one way function.  Eric acknowledges this.
I believe his nervousness notwithstanding nothing more needs to be done
here.

Nico
-- 

Date: Wed, 22 Nov 2006 20:51:51 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked], Jeffrey Altman <[email-masked]>
Subject: Re: GS2 update
Sender: [email-masked]

Nicolas Williams wrote:

>On Wed, Nov 22, 2006 at 06:56:41PM +0000, Alexey Melnikov wrote:
>  
>
>>Nicolas Williams wrote:
>>    
>>
>>>I read this differently.  My reading of this is that GS2 has include the
>>>specification called for in that last sentence quoted above.  I don't
>>>see the harm in that.
>>>
>>>This has nothing to do with implementation, and everything to do with
>>>specification.  The TLS CB I-D leaves one detail open and says "the app
>>>protocol specs must fill this in" and GS2 is the spec that has to do
>>>that.
>>>      
>>>
>>Which is kind of defeat the purpose of specifying channel bindings in 
>>separate documents. Are you saying that GS2 has to be updated every time 
>>a new channel binding spec gets published?
>>
>>I don't think that the GS2 spec or a SASL profile document (.e.g. SMTP 
>>AUTH document) is a good place for this kind of information.
>>    
>>
>There was a good reason for wanting to leave part of the specification
>in draft-altman-tls-cb open, but I forget what it was (IIRC it had
>something to do with TELNET's use of finished messages with StartTLS).
>  
>
In this case the Telnet spec should define a new TLS channel binding, as 
it is an exception from the common case.

Date: Wed, 22 Nov 2006 14:40:22 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked], Jeffrey Altman <[email-masked]>
Subject: Re: GS2 update
Mail-Followup-To: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked], Jeffrey Altman <[email-masked]>
Sender: [email-masked]

On Wed, Nov 22, 2006 at 06:56:41PM +0000, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >I read this differently.  My reading of this is that GS2 has include the
> >specification called for in that last sentence quoted above.  I don't
> >see the harm in that.
> >
> >This has nothing to do with implementation, and everything to do with
> >specification.  The TLS CB I-D leaves one detail open and says "the app
> >protocol specs must fill this in" and GS2 is the spec that has to do
> >that.
> 
> Which is kind of defeat the purpose of specifying channel bindings in 
> separate documents. Are you saying that GS2 has to be updated every time 
> a new channel binding spec gets published?
> 
> I don't think that the GS2 spec or a SASL profile document (.e.g. SMTP 
> AUTH document) is a good place for this kind of information.

There was a good reason for wanting to leave part of the specification
in draft-altman-tls-cb open, but I forget what it was (IIRC it had
something to do with TELNET's use of finished messages with StartTLS).

> >I think an improvement would be to change that MUST in the last sentence
> >quoted to a MAY and provide a default for app protocol specs that don't.
> 
> Yes, please!

I believe this should be no big deal.  Jeff?

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 22 Nov 2006 20:35:26 +0100
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> On Wednesday, November 22, 2006 05:46:12 PM +0100 Simon Josefsson
> <[email-masked]> wrote:
>
>> Also don't forget that we cannot support all non-integrity capable
>> variants anyway...
>
> Hm?  Why not?  We certainly should be able to support any GSS-API
> mechanism as a means of authentication.  It might not be any better
> than PLAIN or CRAM-MD5, except for the part about working with some
> people's existing infrastructures.  As I said at the WG meeting, I've
> spent too long fighting to get applications that support _my_ existing
> authentication infrastructure not to be sympathetic to the problems of
> others in the same situation.

I agree that this is a good principle.

>> I don't see any way to support non-integrity capable credentials in GS2
>> without opening up to a downgrade attack of any mechanism.  At least
>> without new GSS API's.
>
> I don't see how this follows, either.  You permit the non-integrity
> mode only for mechanisms which are known not to support integrity
> protection.

With that approach GS2 doesn't seem to be able to handle GSS-API
mechanisms that supports integrity but let it be up to the credentials
whether integrity is enabled or not.  See:

http://article.gmane.org/gmane.ietf.sasl/2615
http://article.gmane.org/gmane.ietf.sasl/2617

Do you feel it is worth the time to support both (1) and (2)?
Suggested text (and, for (2), drafts) would be appreciated.. ;-)

>>> Are we settled on NOT using BER encoding or not?
>>
>> Oh, that's an interesting question.  I don't care strongly either way.
>> There are some considerations though.
>>
>> First, if we assume that implementers will compute GS2 mech names for
>> the mechanisms they support by hand, and hard-code that name in the
>> implementation, the difference seem marginal.  An ASCII-encoding is
>> easier to get right than a DER-encoding, but not significantly.
>>
>> If on the other hand we assume that implementers will dynamically
>> translate GSS-API mechanism OIDs to GS2 mech names, the situation is
>> different.  Some GSS-API interfaces return mech names as OIDs, e.g.
>> GSS_Init_sec_context.  To me right now RFC 2743 is unclear whether they
>> are intended to be raw, DER-, or BER-encoded.  (RFC 2744 section 3.3
>> suggests they are raw?)  But most certainly they are in one of those
>> formats, and definitely not in ASCII format.
>
> RFC2743 deliberately doesn't specify the exact form of OID's or any
> other data type, because it is an abstract interface.  Those details
> are left up to the particular language bindings.

That is unfortunate since it means GS2 cannot assume implementation
have the OID in any particular form.

> For C, RFC2744 specifies the same encoding use for the "value" part
> of an OID tag in BER; perhaps this is what you mean by "raw"?  It is
> easy enough to add the tag and length when required.

Is it BER/DER?  I thought for BER/DER you'll need the tag 0x06 and
length 0x07.  I call the OID without the DER/BER tag+length "raw".

> Given that implementations which use hard-coded values need compute
> them only once, while implementations which construct a list of mech
> names based on the result of GSS_Indicate_mechs() need to compute them
> every time, it would seem appropriate to optimize for the latter.
> This is also consistent with the current document and with what has
> already been done in places like SSH.

I agree.  However, as you've explained, the syntax of the mechanism
output by GSS_Indicate_mechs is language-dependent.  So we should
probably optimize for those language bindings out there that we care
mostly about, and let others do additional conversion.  Let's see:

C: Uses BER/DER encoded OID without tag+length.

Java: See section 6.7 of RFC 2853.  Supports both ASCII and DER
encoded OIDs _with_ tag+length.

The lowest-common denominator here seem to be DER encoded OID's
without the tag+length, which isn't what GS2 is using now.

/Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 22 Nov 2006 20:30:56 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Nov 22, 2006 at 06:10:38PM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[email-masked]> writes:
>> > Could you remind us what the issues are with Jeff's I-D?
>> >
>> > I thought we were done with the TLS channel binding specification.
>
>> [...]
>> There is another potential problems with Jeff's draft: ambiguity
>> between channel bindings for two different security protocols.  The
>> IANA registry that Alexey proposed would solve it.
>
> I don't follow.

Perhaps Alexey can post the original e-mail that included some
discussion.  I don't think this has been mentioned here before.
Alexey?

>> There are also two problems that I brought up long time ago: re-using
>> the TLS finished messages create a hard-coded dependency on MD5 and
>> SHA1 which is a bad idea.
>
> This is nonsense.  This is a TLS hash agility issue, not a GS2 hash
> agility issue.  And TLS 1.2 will fix this (as long as it doesn't remove
> or fundamentally change the notion of finished messages).

The draft-altman-tls-channel-bindings document reference TLS 1.1.  If
it the document is intended to automatically work with TLS 1.2 --
which isn't clear to me -- I believe some additional discussion about
that needs to be added.  Here is a strawman, although it is quite
abstract on the requirements that is placed on TLS:

  This channel binding specification can support any TLS version that
  have the same notion of finished messages.  In particular, if the
  hash agility concern inherent in TLS 1.1 finished messages is solved
  within the finished message, this channel binding specification
  automatically uses it.

Otherwise the channel binding document seem stuck on TLS <= 1.1.  See
also http://article.gmane.org/gmane.ietf.sasl/2384

>>                            It has also not been proven that revealing
>> the TLS finished messages, the first messages to be encrypted over a
>> TLS channel, to attackers is a safe thing.  It feels like a
>> sub-optimal solution to me.
>
> Simon, this is getting annoying.  Eric answered this solidly.  Besides,
> providing confidentiality protection for these in GS2 is no sweat (isn't
> it even the default?).

Whether GS2 provides confidentiality for this is irrelevant.
draft-altman-tls-channel-bindings is intended for other purposes too.

Eric wrote in http://article.gmane.org/gmane.ietf.sasl/2364 that he'd
rather see the finished messages hashed to avoid any possibility of a
problem here.

/Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 22 Nov 2006 20:12:38 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Nov 22, 2006 at 06:10:38PM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[email-masked]> writes:
>> > Could you remind us what the issues are with Jeff's I-D?
>> >
>> > I thought we were done with the TLS channel binding specification.
>> 
>> Alexey has explained the critical problem in private mail.  The
>> problem is that the TLS draft doesn't describe the syntax of TLS
>> channel bindings.  The document says:
>> 
>>    The channel bindings for TLS connections consist of one, the other or
>>    both of the initial client or server "finished" TLS messages section
>>    7.4.9 [RFC4346] (note: the unencrypted messages).  The initial TLS
>>    finished messages are the first pair of TLS finished messages
>>    exchanged after TLS channel establishment.  It is irrelevant whether
>>    the TLS channel was established with a previous SessionID section
>>    7.4.1.2 [RFC4346] or not.
>> 
>>    Application protocols MUST specify which of the two initial finished
>>    messages, or combination of both of them, to use.
>> 
>> That isn't useful for an implementer.  According to the SASL WG
>> minutes, the people at the meeting thought it would be a bad idea to
>> insert the statements that I proposed, required by the TLS channel
>> binding document, into GS2.
>
> I read this differently.  My reading of this is that GS2 has include the
> specification called for in that last sentence quoted above.  I don't
> see the harm in that.

That is what I initially proposed.  As far as I can tell, that was
rejected at the meeting.  My proposal in
http://article.gmane.org/gmane.ietf.sasl/2623 was to replace:

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

with

   For more discussions of channel bindings, see [7].  For the syntax
   of channel bindings for TLS, see
   [draft-altman-tls-channel-bindings]; GS2 uses the concatenation of
   the initial client and the initial server "finished" TLS messages
   as the channel binding.

However, the SASL minutes says:

 Extended discussion ensues about GS2 and channel bindings.  Simon
 Josefsson has some concerns about implementability of TLS channel
 bindings due to lack of adequate specification.  Explicitly reference
 Jeff Altman's TLS channel bindings draft?  Consensus that this is a
 bad idea; leave GS2 alone for now (referencing
 draft-williams-on-channel-binding).

I didn't see any other way to implement GS2 without that new text.  It
is a sub-optimal solution though -- it is better to fix Jeff's draft.

> This has nothing to do with implementation, and everything to do with
> specification.  The TLS CB I-D leaves one detail open and says "the app
> protocol specs must fill this in" and GS2 is the spec that has to do
> that.

Right.

> I think an improvement would be to change that MUST in the last sentence
> quoted to a MAY and provide a default for app protocol specs that don't.

Yes, please!  Here is suggested new section, replace:

    Application protocols MUST specify which of the two initial finished
    messages, or combination of both of them, to use.

with

    Application protocols MAY specify which of the two initial
    finished messages, or combination of both of them, to use.  If
    this is not specified, the concatenation of the client and the
    server finished TLS messages are used.

I recall that we reached the same conclusion over jabber a few months
ago...

/Simon

Date: Wed, 22 Nov 2006 14:10:38 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>
cc: [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: GS2 update
Originator-Info: login-token=Mulberry:0186ElyF0Jmjw/7J1JJh9VN4oTXPN61Z5gFlMtKSE=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, November 22, 2006 12:32:47 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

>
> On Wed, Nov 22, 2006 at 06:10:38PM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[email-masked]> writes:
>> > Could you remind us what the issues are with Jeff's I-D?
>> >
>> > I thought we were done with the TLS channel binding specification.
>
>> [...]
>> There is another potential problems with Jeff's draft: ambiguity
>> between channel bindings for two different security protocols.  The
>> IANA registry that Alexey proposed would solve it.
>
> I don't follow.

Me either.

>> There are also two problems that I brought up long time ago: re-using
>> the TLS finished messages create a hard-coded dependency on MD5 and
>> SHA1 which is a bad idea.
>
> This is nonsense.  This is a TLS hash agility issue, not a GS2 hash
> agility issue.  And TLS 1.2 will fix this (as long as it doesn't remove
> or fundamentally change the notion of finished messages).

Agree.  We're not creating a dependency on MD5 or SHA1, but on whatever 
bits TLS actually transmits over the wire.

> Besides,
> providing confidentiality protection for these in GS2 is no sweat (isn't
> it even the default?).

This shouldn't be relevant, since the TLS channel bindings document has 
applicability beyond GS2.  However, I do think the question of whether it's 
safe to use the TLS finished messages for this purpose has been beaten 
quite to death.

-- Jeff

Date: Wed, 22 Nov 2006 14:05:12 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Nicolas Williams <[email-masked]>
cc: Simon Josefsson <[email-masked]>, [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: GS2 update
Originator-Info: login-token=Mulberry:01yt3zvjRFaDIWKGs//VsjLWFPKulREWw3UiEjAF0=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, November 22, 2006 06:56:41 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>> This has nothing to do with implementation, and everything to do with
>> specification.  The TLS CB I-D leaves one detail open and says "the app
>> protocol specs must fill this in" and GS2 is the spec that has to do
>> that.
>>
>>
> Which is kind of defeat the purpose of specifying channel bindings in
> separate documents. Are you saying that GS2 has to be updated every time
> a new channel binding spec gets published?
>
> I don't think that the GS2 spec or a SASL profile document (.e.g. SMTP
> AUTH document) is a good place for this kind of information.

Neither do I.  This was discussed at the WG meeting, and I think we came to 
tne conclusion that the TLS channel bindings document really should specify 
exactly one way to do channel bindings for TLS, instead of three.

-- Jeff

Date: Wed, 22 Nov 2006 18:56:41 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Sender: [email-masked]

Nicolas Williams wrote:

>On Wed, Nov 22, 2006 at 06:10:38PM +0100, Simon Josefsson wrote:
>  
>
>>Nicolas Williams <[email-masked]> writes:
>>    
>>
>>>Could you remind us what the issues are with Jeff's I-D?
>>>
>>>I thought we were done with the TLS channel binding specification.
>>>      
>>>
>>Alexey has explained the critical problem in private mail.  The
>>problem is that the TLS draft doesn't describe the syntax of TLS
>>channel bindings.  The document says:
>>
>>   The channel bindings for TLS connections consist of one, the other or
>>   both of the initial client or server "finished" TLS messages section
>>   7.4.9 [RFC4346] (note: the unencrypted messages).  The initial TLS
>>   finished messages are the first pair of TLS finished messages
>>   exchanged after TLS channel establishment.  It is irrelevant whether
>>   the TLS channel was established with a previous SessionID section
>>   7.4.1.2 [RFC4346] or not.
>>
>>   Application protocols MUST specify which of the two initial finished
>>   messages, or combination of both of them, to use.
>>
>>That isn't useful for an implementer.  According to the SASL WG
>>minutes, the people at the meeting thought it would be a bad idea to
>>insert the statements that I proposed, required by the TLS channel
>>binding document, into GS2.
>>    
>>
>I read this differently.  My reading of this is that GS2 has include the
>specification called for in that last sentence quoted above.  I don't
>see the harm in that.
>
>This has nothing to do with implementation, and everything to do with
>specification.  The TLS CB I-D leaves one detail open and says "the app
>protocol specs must fill this in" and GS2 is the spec that has to do
>that.
>  
>
Which is kind of defeat the purpose of specifying channel bindings in 
separate documents. Are you saying that GS2 has to be updated every time 
a new channel binding spec gets published?

I don't think that the GS2 spec or a SASL profile document (.e.g. SMTP 
AUTH document) is a good place for this kind of information.

>I think an improvement would be to change that MUST in the last sentence
>quoted to a MAY and provide a default for app protocol specs that don't.
>  
>
Yes, please!

Date: Wed, 22 Nov 2006 12:32:47 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: GS2 update
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 22, 2006 at 06:10:38PM +0100, Simon Josefsson wrote:
> Nicolas Williams <[email-masked]> writes:
> > Could you remind us what the issues are with Jeff's I-D?
> >
> > I thought we were done with the TLS channel binding specification.

> [...]
> There is another potential problems with Jeff's draft: ambiguity
> between channel bindings for two different security protocols.  The
> IANA registry that Alexey proposed would solve it.

I don't follow.

> There are also two problems that I brought up long time ago: re-using
> the TLS finished messages create a hard-coded dependency on MD5 and
> SHA1 which is a bad idea.

This is nonsense.  This is a TLS hash agility issue, not a GS2 hash
agility issue.  And TLS 1.2 will fix this (as long as it doesn't remove
or fundamentally change the notion of finished messages).

>                            It has also not been proven that revealing
> the TLS finished messages, the first messages to be encrypted over a
> TLS channel, to attackers is a safe thing.  It feels like a
> sub-optimal solution to me.

Simon, this is getting annoying.  Eric answered this solidly.  Besides,
providing confidentiality protection for these in GS2 is no sweat (isn't
it even the default?).

Nico
-- 

Date: Wed, 22 Nov 2006 12:22:30 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: GS2 update
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 22, 2006 at 06:10:38PM +0100, Simon Josefsson wrote:
> Nicolas Williams <[email-masked]> writes:
> > Could you remind us what the issues are with Jeff's I-D?
> >
> > I thought we were done with the TLS channel binding specification.
> 
> Alexey has explained the critical problem in private mail.  The
> problem is that the TLS draft doesn't describe the syntax of TLS
> channel bindings.  The document says:
> 
>    The channel bindings for TLS connections consist of one, the other or
>    both of the initial client or server "finished" TLS messages section
>    7.4.9 [RFC4346] (note: the unencrypted messages).  The initial TLS
>    finished messages are the first pair of TLS finished messages
>    exchanged after TLS channel establishment.  It is irrelevant whether
>    the TLS channel was established with a previous SessionID section
>    7.4.1.2 [RFC4346] or not.
> 
>    Application protocols MUST specify which of the two initial finished
>    messages, or combination of both of them, to use.
> 
> That isn't useful for an implementer.  According to the SASL WG
> minutes, the people at the meeting thought it would be a bad idea to
> insert the statements that I proposed, required by the TLS channel
> binding document, into GS2.

I read this differently.  My reading of this is that GS2 has include the
specification called for in that last sentence quoted above.  I don't
see the harm in that.

This has nothing to do with implementation, and everything to do with
specification.  The TLS CB I-D leaves one detail open and says "the app
protocol specs must fill this in" and GS2 is the spec that has to do
that.

I think an improvement would be to change that MUST in the last sentence
quoted to a MAY and provide a default for app protocol specs that don't.

Nico
-- 

Date: Wed, 22 Nov 2006 12:35:02 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: GS2 update
Originator-Info: login-token=Mulberry:0110Uro0GtoBcjkKMkCsNbEm63Ys5eeaREulkIDcU=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, November 22, 2006 05:46:12 PM +0100 Simon Josefsson 
<[email-masked]> wrote:

> Also don't forget that we cannot support all non-integrity capable
> variants anyway...

Hm?  Why not?  We certainly should be able to support any GSS-API mechanism 
as a means of authentication.  It might not be any better than PLAIN or 
CRAM-MD5, except for the part about working with some people's existing 
infrastructures.  As I said at the WG meeting, I've spent too long fighting 
to get applications that support _my_ existing authentication 
infrastructure not to be sympathetic to the problems of others in the same 
situation.

> I don't see any way to support non-integrity capable credentials in GS2
> without opening up to a downgrade attack of any mechanism.  At least
> without new GSS API's.

I don't see how this follows, either.  You permit the non-integrity mode 
only for mechanisms which are known not to support integrity protection.

>> Are we settled on NOT using BER encoding or not?
>
> Oh, that's an interesting question.  I don't care strongly either way.
> There are some considerations though.
>
> First, if we assume that implementers will compute GS2 mech names for
> the mechanisms they support by hand, and hard-code that name in the
> implementation, the difference seem marginal.  An ASCII-encoding is
> easier to get right than a DER-encoding, but not significantly.
>
> If on the other hand we assume that implementers will dynamically
> translate GSS-API mechanism OIDs to GS2 mech names, the situation is
> different.  Some GSS-API interfaces return mech names as OIDs, e.g.
> GSS_Init_sec_context.  To me right now RFC 2743 is unclear whether they
> are intended to be raw, DER-, or BER-encoded.  (RFC 2744 section 3.3
> suggests they are raw?)  But most certainly they are in one of those
> formats, and definitely not in ASCII format.

RFC2743 deliberately doesn't specify the exact form of OID's or any other 
data type, because it is an abstract interface.  Those details are left up 
to the particular language bindings.  For C, RFC2744 specifies the same 
encoding use for the "value" part of an OID tag in BER; perhaps this is 
what you mean by "raw"?  It is easy enough to add the tag and length when 
required.

Given that implementations which use hard-coded values need compute them 
only once, while implementations which construct a list of mech names based 
on the result of GSS_Indicate_mechs() need to compute them every time, it 
would seem appropriate to optimize for the latter.  This is also consistent 
with the current document and with what has already been done in places 
like SSH.

-- Jeff

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 22 Nov 2006 18:10:38 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Nov 21, 2006 at 11:05:44PM +0100, Simon Josefsson wrote:
>> 
>> On 21 nov 2006, at 20.37, Jeffrey Hutzelman wrote:
>> 
>> >On Tuesday, November 21, 2006 12:26:23 PM +0100 Simon Josefsson  
>> ><[email-masked]> wrote:
>> >
>> >>Agreed, but to be able to implement GS2 with channel bindings, the
>> >>implementation need to know how the channel binding for TLS looks
>> >>like.  I failed to implement GS2 a few months ago because of this.
>> >
>> >That's because the document which tells you isn't done yet, not  
>> >because GS2 doesn't have a direct reference to that document.
>> 
>> Right.  Until that document is done, I believe this remains an open  
>> issue for GS2 because it is impossible to implement GS2 without this  
>> issue closed.
>
> Could you remind us what the issues are with Jeff's I-D?
>
> I thought we were done with the TLS channel binding specification.

Alexey has explained the critical problem in private mail.  The
problem is that the TLS draft doesn't describe the syntax of TLS
channel bindings.  The document says:

   The channel bindings for TLS connections consist of one, the other or
   both of the initial client or server "finished" TLS messages section
   7.4.9 [RFC4346] (note: the unencrypted messages).  The initial TLS
   finished messages are the first pair of TLS finished messages
   exchanged after TLS channel establishment.  It is irrelevant whether
   the TLS channel was established with a previous SessionID section
   7.4.1.2 [RFC4346] or not.

   Application protocols MUST specify which of the two initial finished
   messages, or combination of both of them, to use.

That isn't useful for an implementer.  According to the SASL WG
minutes, the people at the meeting thought it would be a bad idea to
insert the statements that I proposed, required by the TLS channel
binding document, into GS2.

I proposed in private mail to replace the above with this:

   The channel bindings for TLS connections consist of the
   concatenation of the initial client and server "finished" TLS
   messages section 7.4.9 [RFC4346] (note: the unencrypted messages).
   The initial TLS finished messages are the first pair of TLS
   finished messages exchanged after TLS channel establishment.  It is
   irrelevant whether the TLS channel was established with a previous
   SessionID section 7.4.1.2 [RFC4346] or not.

This new paragraph is useful for an implementer, and avoids the
ambiguity in the old text.

There is another potential problems with Jeff's draft: ambiguity
between channel bindings for two different security protocols.  The
IANA registry that Alexey proposed would solve it.

There are also two problems that I brought up long time ago: re-using
the TLS finished messages create a hard-coded dependency on MD5 and
SHA1 which is a bad idea.  It has also not been proven that revealing
the TLS finished messages, the first messages to be encrypted over a
TLS channel, to attackers is a safe thing.  It feels like a
sub-optimal solution to me.

I believe draft-josefsson-sasl-tls-cb solves these problems, except
for the IANA registry.  All references to SASL in it should be removed
though, to make it general, though.

Thanks,
Simon

Date: Wed, 22 Nov 2006 14:39:11 +0000
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Sender: [email-masked]

Simon Josefsson wrote:

>Jeffrey Hutzelman <[email-masked]> writes:
>  
>
>>On Tuesday, November 07, 2006 04:56:32 PM +0100 Simon Josefsson
>><[email-masked]> wrote:
>>    
>>
>>>Non-integrity capable mechanisms/credentials: This is a feature
>>>request that came up during WGLC.  I suggest to move forward with GS2
>>>as-is today, decide later whether to revise GS2 or specify a "GS0"
>>>(see presentation) to handle these mechanisms/credentials, if the need
>>>develops.
>>>      
>>>
>>It's unclear why we would want to write a whole new mechanism for
>>this, when all that is required is specifying the (relatively small)
>>differences required when using a mechanism which does not support
>>gss_Wrap().
>>    
>>
>
>I'm trying to work on that, but it takes time.  Help on developing
>these changes would move things along faster.
>
>Supporting this cause changes in almost every section of the document
>(it affects the protocol syntax, the semantics, channel bindings,
>examples, and security considerations), so I don't think the change is
>relatively small.
>
>I proposed skipping the feature to speed things up.  One aspect of
>proposing to skip the feature is to gauge the importance of this
>feature -- if nobody feels strongly about keeping it (and is willing
>to help), maybe it isn't that important.
>  
>
I don't find this particular feature to be worth the effort of making an 
already complex document even more complex.

Can somebody give some examples of GSS-API mechanisms that GS2 will be 
prohibiting by the document as it is written now.

>>>Channel bindings: Have a normative reference on
>>>draft-altman-tls-channel-bindings in GS2 and explain which TLS
>>>finished message to use.  Specific suggested solution is to replace:
>>>
>>>   For more discussions of channel bindings, and the syntax of the
>>>   channel binding data for various security protocols, see [7].
>>>
>>>with
>>>
>>>   For more discussions of channel bindings, see [7].  For the syntax
>>>   of channel bindings for TLS, see
>>>   [draft-altman-tls-channel-bindings]; GS2 uses the concatenation of
>>>   the initial client and the initial server "finished" TLS messages
>>>   as the channel binding.
>>>      
>>>
>>This is not necessary.  This document need only specify how it
>>transports and protects channel bindings, similarly to how mechanisms
>>must specify this for authorization names.  Just as the form and
>>meaning of an authorization name is specified for each application but
>>is independent of the mechanism, so the form and meaning of channel
>>bindings must be specified for each channel type but should be
>>independent of the mechanism. Otherwise we end up with the same sort
>>of O(N*M) problem that SASL was intended to avoid in the first place!
>>    
>>
>Agreed, but to be able to implement GS2 with channel bindings, the
>implementation need to know how the channel binding for TLS looks
>like.  I failed to implement GS2 a few months ago because of this.
>  
>
Speaking as an implementor, I agree with this.

>draft-altman-tls-channel-bindings-00 isn't sufficiently detailed to
>solve this.  Changing d-a-t-c-b was, as far as I understand, the
>outcome of a discussion with Jeff Altman earlier this autumn, but I
>haven't seen any signs the document will change.  The best solution
>is, I believe, for the document to change, but if that doesn't happen,
>I wanted to present an alternative way forward.
>  
>
I would also think that it would make sense to delay publication (not 
the IESG review) of GS2 until after at least one document describing 
some specific channel bindings is approved for publication.

>>>Kerberos V5 GS2 mechanism name example: Move forward with GS2 as-is
>>>today, and add the Kerberos V5 example mech name during AUTH48.
>>>      
>>>
>>Absolutely not.  AUTH48 is for fixing problems introduced during the
>>RFC-Editor process or discovered _and reviewed_ at the last minute.
>>While it is sometimes appropriate to include a change of this nature
>>in a note to the RFC-Editor, which is part of the text approved by the
>>IESG, I do not think it is appropriate in this case.  Independent
>>computation of the value of this mechanism name is a key indication
>>that the algorithm for doing so is well-specified, and that
>>verification should be performed _before_ we send the document to the
>>IESG, not after.
>>
>>Several parties have volunteered to compute the mechanism name.
>>Assuming they come up with the same value, I have no problem with
>>inserting that value in the next version of the document (after AD
>>and/or IESG review) or in an RFC-Editor note.
>>    
>>
>Right, and if people help on this we can solve it in a better way.
>We've had this as an open issue for two meetings, that's why I started
>to propose alternative solutions.  You should read this proposal as a
>request for help, but with a safety gauge to get this document
>published if nobody steps forward.  A krb5 mech name example isn't
>critical for this document, after all.
>
>I've received one krb5 mech name recently, so it seems we are getting
>closer to solve this the right way.  Alas, the mech name differed
>slightly from what I had computed... more independently computed names
>would give greater confidence.
>  
>
Are we settled on NOT using BER encoding or not?

Date: Wed, 22 Nov 2006 14:21:09 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: IDnits
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>> I keep the RFC numbers and rewrite as Ken suggests. I'd started that 
>> already, because it optimises for readability and because idnits 
>> insists on seeing "RFC 2119" in that boilerplace sentence.
>
> It turns out that one can use:
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in RFC 2119.
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in [RFC2119].
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in [RFC 2119].
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in RFC 2119 [1].
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in RFC 2119 [KEYWORDS].
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in [KEYWORDS].

Thanks.

I was using one of the last two, and idnits version 1.103 complained. 
1.103 must have been somewhat imperfect. I now upgraded to 1.118, and 
it only gives sensible warnings. Great. Why didn't I upgrade before?

However, I already rewrote and like the result better. It names the 
subject at hand, the document being referred to, or both, depending on 
what's best in any given paragraph.

Arnt

Date: Wed, 22 Nov 2006 13:01:23 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], [email-masked]
Subject: IDnits
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Mark Crispin writes:
>
>> On Tue, 21 Nov 2006, Ken Murchison wrote:
>>
>>> - Section 2: Even though I know what RFC4422 and RFC3501 are, I'd 
>>> like to see the acronyms used with the references.  e.g.
>>> "The [RFC4422} ..."      ->  "The SASL [RFC4422] ..."
>>> "... any [RFC3501] ..."  ->  "... any IMAP [RFC3501] ..."
>>> "... any [RFC4422] ..."  ->  "... any SASL [RFC4422] ..."
>>
>> Or just change the reference names so that the RFC only needs to be 
>> changed once, in the references, e.g., [SASL], [IMAP], etc.
>
> I keep the RFC numbers and rewrite as Ken suggests. I'd started that 
> already, because it optimises for readability and because idnits 
> insists on seeing "RFC 2119" in that boilerplace sentence.

It turns out that one can use:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [KEYWORDS].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KEYWORDS].

However the [KEYWORDS] reference has to be properly defined:

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

instead of:

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

Date: Wed, 22 Nov 2006 00:51:54 -0400
To: "Ietf-sasl" <[email-masked]>
From: "Kurt" <[email-masked]>
Subject: Andrew
Sender: [email-masked]

----------dwqkzsoqvthoglqlmhoc
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>Passwrd: <img src="cid:pibpffcbkm.gif"><br>
<br>
</body></html>

----------dwqkzsoqvthoglqlmhoc
Content-Type: image/gif; name="pibpffcbkm.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="pibpffcbkm.gif"
Content-ID: 

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

----------dwqkzsoqvthoglqlmhoc--

Date: Tue, 21 Nov 2006 17:29:17 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: GS2 update
Mail-Followup-To: Simon Josefsson <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Nov 21, 2006 at 11:05:44PM +0100, Simon Josefsson wrote:
> 
> On 21 nov 2006, at 20.37, Jeffrey Hutzelman wrote:
> 
> >On Tuesday, November 21, 2006 12:26:23 PM +0100 Simon Josefsson  
> ><[email-masked]> wrote:
> >
> >>Agreed, but to be able to implement GS2 with channel bindings, the
> >>implementation need to know how the channel binding for TLS looks
> >>like.  I failed to implement GS2 a few months ago because of this.
> >
> >That's because the document which tells you isn't done yet, not  
> >because GS2 doesn't have a direct reference to that document.
> 
> Right.  Until that document is done, I believe this remains an open  
> issue for GS2 because it is impossible to implement GS2 without this  
> issue closed.

Could you remind us what the issues are with Jeff's I-D?

I thought we were done with the TLS channel binding specification.

Nico
-- 

Cc: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: GS2 update
Date: Tue, 21 Nov 2006 23:05:44 +0100
To: Jeffrey Hutzelman <[email-masked]>
Sender: [email-masked]

On 21 nov 2006, at 20.37, Jeffrey Hutzelman wrote:

> On Tuesday, November 21, 2006 12:26:23 PM +0100 Simon Josefsson  
> <[email-masked]> wrote:
>
>> Agreed, but to be able to implement GS2 with channel bindings, the
>> implementation need to know how the channel binding for TLS looks
>> like.  I failed to implement GS2 a few months ago because of this.
>
> That's because the document which tells you isn't done yet, not  
> because GS2 doesn't have a direct reference to that document.

Right.  Until that document is done, I believe this remains an open  
issue for GS2 because it is impossible to implement GS2 without this  
issue closed.

>>> Several parties have volunteered to compute the mechanism name.
>>> Assuming they come up with the same value, I have no problem with
>>> inserting that value in the next version of the document (after AD
>>> and/or IESG review) or in an RFC-Editor note.
>>
>> Right, and if people help on this we can solve it in a better way.
>> We've had this as an open issue for two meetings, that's why I  
>> started
>> to propose alternative solutions.  You should read this proposal as a
>> request for help, but with a safety gauge to get this document
>> published if nobody steps forward.  A krb5 mech name example isn't
>> critical for this document, after all.
>
> At least three people stood up at the last meeting in said they'd  
> do it. Our chairs know who they are; I'd be surprised if you didn't  
> see answers from all three fairly soon.

Yes, and that is excellent.  The message that you replied to was  
posted before the meeting, and together with the presentation  
prompted the discussion at the WG meeting.

/Simon

Date: Tue, 21 Nov 2006 14:37:39 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: GS2 update
Originator-Info: login-token=Mulberry:01UXc4jLvfrQCdwrANhPVo++jpb7fYq7G+7Gbxh/c=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, November 21, 2006 12:26:23 PM +0100 Simon Josefsson 
<[email-masked]> wrote:

> Agreed, but to be able to implement GS2 with channel bindings, the
> implementation need to know how the channel binding for TLS looks
> like.  I failed to implement GS2 a few months ago because of this.

That's because the document which tells you isn't done yet, not because GS2 
doesn't have a direct reference to that document.

>> Several parties have volunteered to compute the mechanism name.
>> Assuming they come up with the same value, I have no problem with
>> inserting that value in the next version of the document (after AD
>> and/or IESG review) or in an RFC-Editor note.
>
> Right, and if people help on this we can solve it in a better way.
> We've had this as an open issue for two meetings, that's why I started
> to propose alternative solutions.  You should read this proposal as a
> request for help, but with a safety gauge to get this document
> published if nobody steps forward.  A krb5 mech name example isn't
> critical for this document, after all.

At least three people stood up at the last meeting in said they'd do it. 
Our chairs know who they are; I'd be surprised if you didn't see answers 
from all three fairly soon.

-- Jeff

Date: Tue, 21 Nov 2006 18:15:48 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: SASL-IR (draft-siemborski-imap-sasl-initial-response-05.txt)
Cc: [email-masked], Ken Murchison <[email-masked]>, Robert Siemborski <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> On Tue, 21 Nov 2006, Ken Murchison wrote:
>> - Section 2: Even though I know what RFC4422 and RFC3501 are, I'd 
>> like to see the acronyms used with the references.  e.g.
>> "The [RFC4422} ..."      ->  "The SASL [RFC4422] ..."
>> "... any [RFC3501] ..."  ->  "... any IMAP [RFC3501] ..."
>> "... any [RFC4422] ..."  ->  "... any SASL [RFC4422] ..."
>
> Or just change the reference names so that the RFC only needs to be 
> changed once, in the references, e.g., [SASL], [IMAP], etc.

I keep the RFC numbers and rewrite as Ken suggests. I'd started that 
already, because it optimises for readability and because idnits 
insists on seeing "RFC 2119" in that boilerplace sentence.

Besides, sometimes I like the distinction between e.g. IMAP and RFC 3501.

Arnt

Date: Tue, 21 Nov 2006 18:15:22 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: SASL-IR (draft-siemborski-imap-sasl-initial-response-05.txt)
Cc: [email-masked], Ken Murchison <[email-masked]>, Robert Siemborski <[email-masked]>
Sender: [email-masked]

Ken Murchison writes:
> Arnt Gulbrandsen wrote:
>
>> I am not aware of any problems with the draft as it now stands. 
>> Please review it and notify me if you see any (I'm sure you will if 
>> you try hard). I'd also like to hear about any implementations. 
>> Thank you.
>
> It probably goes with out saying, but Cyrus IMAP has implemented this 
> from day one.

So far, 100% of servers apparently support it. I am amazed.

> A few nits on the draft, mostly outdated references.

I did all the nits and a few others. Augmented Bakus-Naur Form struck my 
eye. Thanks. There's one real issue to consider (security: MITM 
adding/removing SASL-IR from CAPABILITY), then I'll upload -06 and sit 
on my hands for a while.

The plan further is to do IETF LC on this and Rob/Alexey's 2554bis 
roughly at the same time, then have the IESG evaluate them together.

Arnt

Date: Tue, 21 Nov 2006 08:40:29 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked], [email-masked], Robert Siemborski <[email-masked]>
Subject: Re: SASL-IR (draft-siemborski-imap-sasl-initial-response-05.txt)
Sender: [email-masked]

On Tue, 21 Nov 2006, Ken Murchison wrote:
> - Section 2: Even though I know what RFC4422 and RFC3501 are, I'd like to see 
> the acronyms used with the references.  e.g.
> "The [RFC4422} ..."      ->  "The SASL [RFC4422] ..."
> "... any [RFC3501] ..."  ->  "... any IMAP [RFC3501] ..."
> "... any [RFC4422] ..."  ->  "... any SASL [RFC4422] ..."

Or just change the reference names so that the RFC only needs to be 
changed once, in the references, e.g., [SASL], [IMAP], etc.

Too bad we never came up with a good acronym for RFC 733/822/2822.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Tue, 21 Nov 2006 10:00:26 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], Robert Siemborski <[email-masked]>
Subject: Re: SASL-IR (draft-siemborski-imap-sasl-initial-response-05.txt)
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> I am not aware of any problems with the draft as it now stands. Please 
> review it and notify me if you see any (I'm sure you will if you try 
> hard). I'd also like to hear about any implementations. Thank you.

It probably goes with out saying, but Cyrus IMAP has implemented this 
from day one.

A few nits on the draft, mostly outdated references.

- Section 2: Even though I know what RFC4422 and RFC3501 are, I'd like 
to see the acronyms used with the references.  e.g.

"The [RFC4422} ..."      ->  "The SASL [RFC4422] ..."
"... any [RFC3501] ..."  ->  "... any IMAP [RFC3501] ..."
"... any [RFC4422] ..."  ->  "... any SASL [RFC4422] ..."

- Section 3: Both instances of RFC3548 should be replaced with RFC4648 
(Base64 is now in Section 4 rather than Section 3)

- Section 3, paragraph 2, sentence 1:  As in my first nit, I'd like to 
see "... the [RFC3548] data ..."  ->  "... the BASE64 [RFC4648] data ..."

- Section 4: RFC2595 should be replaced with RFC4616

- Section 4: Both instances of RFC2246 should be replaced with RFC4346

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked]
Subject: Re: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 21 Nov 2006 12:26:23 +0100
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> On Tuesday, November 07, 2006 04:56:32 PM +0100 Simon Josefsson
> <[email-masked]> wrote:
>
>> Non-integrity capable mechanisms/credentials: This is a feature
>> request that came up during WGLC.  I suggest to move forward with GS2
>> as-is today, decide later whether to revise GS2 or specify a "GS0"
>> (see presentation) to handle these mechanisms/credentials, if the need
>> develops.
>
> It's unclear why we would want to write a whole new mechanism for
> this, when all that is required is specifying the (relatively small)
> differences required when using a mechanism which does not support
> gss_Wrap().

I'm trying to work on that, but it takes time.  Help on developing
these changes would move things along faster.

Supporting this cause changes in almost every section of the document
(it affects the protocol syntax, the semantics, channel bindings,
examples, and security considerations), so I don't think the change is
relatively small.

I proposed skipping the feature to speed things up.  One aspect of
proposing to skip the feature is to gauge the importance of this
feature -- if nobody feels strongly about keeping it (and is willing
to help), maybe it isn't that important.

>> Channel bindings: Have a normative reference on
>> draft-altman-tls-channel-bindings in GS2 and explain which TLS
>> finished message to use.  Specific suggested solution is to replace:
>>
>>    For more discussions of channel bindings, and the syntax of the
>>    channel binding data for various security protocols, see [7].
>>
>> with
>>
>>    For more discussions of channel bindings, see [7].  For the syntax
>>    of channel bindings for TLS, see
>>    [draft-altman-tls-channel-bindings]; GS2 uses the concatenation of
>>    the initial client and the initial server "finished" TLS messages
>>    as the channel binding.
>
> This is not necessary.  This document need only specify how it
> transports and protects channel bindings, similarly to how mechanisms
> must specify this for authorization names.  Just as the form and
> meaning of an authorization name is specified for each application but
> is independent of the mechanism, so the form and meaning of channel
> bindings must be specified for each channel type but should be
> independent of the mechanism. Otherwise we end up with the same sort
> of O(N*M) problem that SASL was intended to avoid in the first place!

Agreed, but to be able to implement GS2 with channel bindings, the
implementation need to know how the channel binding for TLS looks
like.  I failed to implement GS2 a few months ago because of this.

draft-altman-tls-channel-bindings-00 isn't sufficiently detailed to
solve this.  Changing d-a-t-c-b was, as far as I understand, the
outcome of a discussion with Jeff Altman earlier this autumn, but I
haven't seen any signs the document will change.  The best solution
is, I believe, for the document to change, but if that doesn't happen,
I wanted to present an alternative way forward.

>> Kerberos V5 GS2 mechanism name example: Move forward with GS2 as-is
>> today, and add the Kerberos V5 example mech name during AUTH48.
>
> Absolutely not.  AUTH48 is for fixing problems introduced during the
> RFC-Editor process or discovered _and reviewed_ at the last minute.
> While it is sometimes appropriate to include a change of this nature
> in a note to the RFC-Editor, which is part of the text approved by the
> IESG, I do not think it is appropriate in this case.  Independent
> computation of the value of this mechanism name is a key indication
> that the algorithm for doing so is well-specified, and that
> verification should be performed _before_ we send the document to the
> IESG, not after.
>
> Several parties have volunteered to compute the mechanism name.
> Assuming they come up with the same value, I have no problem with
> inserting that value in the next version of the document (after AD
> and/or IESG review) or in an RFC-Editor note.

Right, and if people help on this we can solve it in a better way.
We've had this as an open issue for two meetings, that's why I started
to propose alternative solutions.  You should read this proposal as a
request for help, but with a safety gauge to get this document
published if nobody steps forward.  A krb5 mech name example isn't
critical for this document, after all.

I've received one krb5 mech name recently, so it seems we are getting
closer to solve this the right way.  Alas, the mech name differed
slightly from what I had computed... more independently computed names
would give greater confidence.

>> Please, consider the delays that are created by alternative solutions,
>
> Delays are unfortunate, but correctness is important too.
>
> So is throughput, by the way.  For example, if adding the necessary
> text to handle GSS mechs with no integrity support delays this
> document but takes longer than an all-new "GS0" would, then it is a
> net win.

That assumes someone feels strongly enough about this feature to
develop GS0 at all.

Regards,
Simon

Date: Mon, 20 Nov 2006 19:35:56 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, [email-masked]
cc: Jeffrey Hutzelman <[email-masked]>
Subject: Re: GS2 update
Originator-Info: login-token=Mulberry:01QgT5YqxsbtaOT3HjdYIp0dl2MI3JOHKveSfHeIQ=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, November 07, 2006 04:56:32 PM +0100 Simon Josefsson 
<[email-masked]> wrote:

> Non-integrity capable mechanisms/credentials: This is a feature
> request that came up during WGLC.  I suggest to move forward with GS2
> as-is today, decide later whether to revise GS2 or specify a "GS0"
> (see presentation) to handle these mechanisms/credentials, if the need
> develops.

It's unclear why we would want to write a whole new mechanism for this, 
when all that is required is specifying the (relatively small) differences 
required when using a mechanism which does not support gss_Wrap().

> Channel bindings: Have a normative reference on
> draft-altman-tls-channel-bindings in GS2 and explain which TLS
> finished message to use.  Specific suggested solution is to replace:
>
>    For more discussions of channel bindings, and the syntax of the
>    channel binding data for various security protocols, see [7].
>
> with
>
>    For more discussions of channel bindings, see [7].  For the syntax
>    of channel bindings for TLS, see
>    [draft-altman-tls-channel-bindings]; GS2 uses the concatenation of
>    the initial client and the initial server "finished" TLS messages
>    as the channel binding.

This is not necessary.  This document need only specify how it transports 
and protects channel bindings, similarly to how mechanisms must specify 
this for authorization names.  Just as the form and meaning of an 
authorization name is specified for each application but is independent of 
the mechanism, so the form and meaning of channel bindings must be 
specified for each channel type but should be independent of the mechanism. 
Otherwise we end up with the same sort of O(N*M) problem that SASL was 
intended to avoid in the first place!

> Kerberos V5 GS2 mechanism name example: Move forward with GS2 as-is
> today, and add the Kerberos V5 example mech name during AUTH48.

Absolutely not.  AUTH48 is for fixing problems introduced during the 
RFC-Editor process or discovered _and reviewed_ at the last minute.  While 
it is sometimes appropriate to include a change of this nature in a note to 
the RFC-Editor, which is part of the text approved by the IESG, I do not 
think it is appropriate in this case.  Independent computation of the value 
of this mechanism name is a key indication that the algorithm for doing so 
is well-specified, and that verification should be performed _before_ we 
send the document to the IESG, not after.

Several parties have volunteered to compute the mechanism name.  Assuming 
they come up with the same value, I have no problem with inserting that 
value in the next version of the document (after AD and/or IESG review) or 
in an RFC-Editor note.

> Please, consider the delays that are created by alternative solutions,

Delays are unfortunate, but correctness is important too.

So is throughput, by the way.  For example, if adding the necessary text to 
handle GSS mechs with no integrity support delays this document but takes 
longer than an all-new "GS0" would, then it is a net win.

-- Jeff

Date: Mon, 20 Nov 2006 22:54:44 +0000
Subject: Re: SASL-IR (draft-siemborski-imap-sasl-initial-response-05.txt)
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Rob Siemborski <[email-masked]>, Robert Siemborski <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Mon Nov 20 21:09:05 2006, Arnt Gulbrandsen wrote:
> I am not aware of any problems with the draft as it now stands. 
> Please review it and notify me if you see any (I'm sure you will if 
> you try hard). I'd also like to hear about any implementations. 
> Thank you.

Most IMAP servers appear to implement it, and Polymer (And Telomer, 
for 770 people) implements it for those SASL mechanisms it implements 
which can benefit, specifically PLAIN, ANONYMOUS, and DIGEST-MD5 
reauthentication.

I can't see anything wrong with the draft, and I'd be pleased to see 
it published as an RFC in its current form.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Mon, 20 Nov 2006 23:07:39 +0100
From: Pawel Salek <[email-masked]>
Subject: Re: SASL-IR (draft-siemborski-imap-sasl-initial-response-05.txt)
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], Robert Siemborski <[email-masked]>
Sender: [email-masked]

On 11/20/2006 10:09:05 PM, Arnt Gulbrandsen wrote:
> 
> I am not aware of any problems with the draft as it now stands.  
> Please review it and notify me if you see any (I'm sure you will if  
> you try hard). I'd also like to hear about any implementations. Thank  
> you.

Balsa email client supports it for SASL GSSAPI, PLAIN and ANONYMOUS.

Pawel

Date: Mon, 20 Nov 2006 13:12:17 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], Robert Siemborski <[email-masked]>
Subject: Re: SASL-IR (draft-siemborski-imap-sasl-initial-response-05.txt)
Sender: [email-masked]

On Mon, 20 Nov 2006, Arnt Gulbrandsen wrote:
> I am not aware of any problems with the draft as it now stands. Please 
> review it and notify me if you see any (I'm sure you will if you try 
> hard). I'd also like to hear about any implementations. Thank you.

FWIW, UW imapd has implemented SASL-IR for a while now, but only in server 
code.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Mon, 20 Nov 2006 22:09:05 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: SASL-IR (draft-siemborski-imap-sasl-initial-response-05.txt)
Cc: [email-masked], Robert Siemborski <[email-masked]>
Sender: [email-masked]

IETF Secretariat writes:
> As you requested, draft-siemborski-imap-sasl-initial-response-05.txt, 
> an updated version of an expired Internet-Drafts, has been posted. 
> [...]

Hi,

Rob changed jobs and couldn't go on with this draft. I've taken over, 
since I was one of the implementers and would rather continue with the 
draft then kill the code.

I am not aware of any problems with the draft as it now stands. Please 
review it and notify me if you see any (I'm sure you will if you try 
hard). I'd also like to hear about any implementations. Thank you.

Arnt

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-11.txt 
Date: Wed, 15 Nov 2006 15:50:02 -0500
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 Digest Authentication as a SASL Mechanism
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sasl-rfc2831bis-11.txt
	Pages		: 46
	Date		: 2006-11-15
	
This specification defines how HTTP Digest Authentication (RFC 2617)
   can be used as a Simple Authentication and Security Layer (SASL, RFC
   4422) mechanism for any protocol that has a SASL profile. It is
   intended both as an improvement over CRAM-MD5 (RFC 2195) and as a
   convenient way to support a single authentication mechanism for web,
   mail, LDAP, and other protocols.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-rfc2831bis-11.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]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Updated DIGEST-MD5 document (draft-ietf-sasl-rfc2831bis-10.txt)
Date:  Wed, 15 Nov 2006 17:09:39 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 92
Sender: [email-masked]

Alexey Melnikov wrote:

--- ABNF ---
>> I've no clue if "implicit LWS" allows several adjacent CRLF SP.

> Yes, several adjacent "CRLF SP" are allowed.

Bad.  If CRLF SP CRLF has completely different effects than CRLF CRLF
it isn't robust.  In mail or news it would hit a "MUST NOT" generate,
and I've my doubts about how good the "MUST accept obs-FWS" works in
practice (for mail, in news it's strictly verboten).

 [translation of ABNF-mixture to proper 4234-ABNF]
> I need to think if it worth doing this change. Other opinions?

For 2617bis I'd say it should be the same style as 2616bis.  At the
moment the 2616bis draft still uses the strange 2616-ABNF with its
"|" instead of "/", the oscure implicit LWS, and a #-rule roughly
derived from 822.

But there was a reason why 2234 (now 4234) didn't adopt the original
822-style, 4234 is much clearer.  For 2831bis you're not forced to
stick to the style invented in 2068 (i.e. before 2234).  If the 2068-
style would be much better than 822 they'd have used it for 2234.
But it's not better, it's confusing, and they used KISS for 2234.

Actually I hope that 2616bis will also switch to the future STD-ABNF,
after all other diffs between 2616bis and 2616 are sorted out.  Then
2617bis could also adopt the STD-ABNF, with 2831bis and 2617bis in
the same style.

That's only what I hope, I didn't discuss it with the 2616bis authors
so far.  But maybe you could check it, it would be odd if 2616bis and
2831bis end up with different ABNF-styles.

--- unq ---
>>| quoted-string  = ( <"> qdstr-val <"> )
>>| qdstr-val      = *( qdtext | quoted-pair )
>>| qdtext         = <any TEXT except <">>

> This is a cut & paste from one of the HTTP specs (RFC 2617 or 2616,
> not sure at the moment).  I think it is generally recognized that
> the last line omits "\\" by mistake.

Makes sense.  But the three DIGEST-MD5 RFCs apparently all take the
<qdstr-val> as is, without looking into it.  Of course if backslash
is really used to escape a DQUOTE within <quoted-string>, then it's
also needed to escape a backslash within <quoted-string>.

But that doesn't tell us if anybody implemtented it in the way you
have specified.  And 2069 didn't allow an escaped DQUOTE.  The real
question is, why did they want this - apart from copying the syntax
from 2045 - was it only about finding the terminating right DQUOTE
of a <quoted-string>, or was it about unquoting any <quoted-pair> ?

For my 2831bis implementation (nothing real, only a MD5 test suite)
adding your new unq() was a major difference from the 2831-version.

> username in Microsoft implementation can have "\", however I
> haven't tested if this causes any hash calculation problems

Okay, a user name like "test\this".  2831 and before said "remove
the DQUOTE", resulting in 9 unquoted characters test\this.  With
your unq() version I'd get 8 characters testthis.

That's a major difference wrt the output of MD5...

> maybe I did, but I don't remember now

...I didn't, because I didn't know any application actually using
DIGEST-MD5.  But the loginmgr of the IETF tools server supports it
now (both 2069 and 2617), maybe we could test it there with a user
name "test\this" or "test\"\\that".

If it expects 8 characters testthis and 10 characters test"\that
we could claim that the situation is messy no matter what 2831
says, and you'd stick to your unq() as is.

If the tools server expects 9 characters test\this or 12 characters
test\"\\that it does what I think 2617 says, and your unq() would
be incompatible with that interpretation.

With Murphy we might also find that it can't handle an embedded
DQUOTE, neither test"\that nor test\"\\that, because that's what
2069 said.  But maybe it has at least an unambiguous idea about
either test\this or testthis.

It would be really bad if unq() works differently in 2831bis and
2617bis, so whatever you do, you'll decide it also for the latter.

Frank

To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Calculation of SASL GS2 mechanism names
From: Tom Yu <[email-masked]>
Date: Tue, 14 Nov 2006 17:20:16 -0500
Lines: 6
Sender: [email-masked]

On a related note, I will need to double-check, but it seems that the
base32-encoded hash for the SPKM OID should be "DT4PIK22T6APV2PY" not
"DT4PIK22T6EPV2PY" as shown in the draft, i.e., the 11th character is
"A", not "E".  Can anyone else confirm?

---Tom

Date: Tue, 14 Nov 2006 18:46:49 +0000
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Updated DIGEST-MD5 document (draft-ietf-sasl-rfc2831bis-10.txt)
Sender: [email-masked]

Frank Ellermann wrote:

>Alexey Melnikov wrote:  
>
>>I need more reviews 
>>
Hi Frank,
Thanks for your review!

>1 - Please use RFC 4234 ABNF, not the RFC 822 version.  There are
>    various tools that can handle 4234-ABNF, readers are familiar
>    with it (after some time), and I've no clue if "implicit LWS"
>    allows several adjacent CRLF SP.
>
Yes, several adjacent "CRLF SP" are allowed.

>
>    Here's an example how to translate <qop-options> to 4234-ABNF:
>
>-   qop-options       = "qop" "=" DQUOTE qop-list DQUOTE
>-   qop-list          = 1#qop-value
>-   qop-value         = "auth" | "auth-int" | "auth-conf" |
>-                       qop-token
>+   qop-options       = "qop" EQU DQUOTE qop-list DQUOTE
>+   qop-list          = [LWS] qop-value *( SEP qop-value ) [LWS]
>+   qop-value         = "auth" / "auth-int" / "auth-conf" /
>+                       qop-token
>+   EQU               = [LWS] "=" [LWS]
>+   SEP               = [LWS] "," [LWS]
>+   LWS               = [*WSP CRLF] 1*WSP
>
>With EQU recycled in all other name=value pairs, SEP used in all
>1# constructs, and LWS derived from RFC 2822 FWS excl. obs-FWS.*
>
I need to think if it worth doing this change. Other opinions?

>If all goes well RFC 4234 is at STD before 2831bis.  It's really
>confusing if alternatives sometimes use "|" as in 2068 and 2616,
>but at other times "/" as in 822 and 4234.

Thanks for pointing this out. Fixed in my copy.

>2 - Is the introduction of the new "backslash-canonicalization"
>    necessary ?  RFC 2617 says:
>
>| However, the "unq" notation indicates that surrounding quotation
>| marks are removed in forming the string A1.
>
>It also mumbles something about not using a DQUOTE within <nonce>,
>apparently clients weren't supposed to look for an escaped DQUOTE.
>
>It's almost exactly the same idea in RFC 2069:
>
>| The "username-value" field is a "quoted-string" as specified in
>| section 2.2 of the HTTP/1.1 specification [2].  However, the
>| surrounding quotation marks are removed in forming the string A1.
>
>Nothing about looking at backslashes within that string.  RFC 2831:
>
>| quoted-string  = ( <"> qdstr-val <"> )
>| qdstr-val      = *( qdtext | quoted-pair )
>| qdtext         = <any TEXT except <">>
>  
>
This is a cut & paste from one of the HTTP specs (RFC 2617 or 2616, not
sure at the moment).
I think it is generally recognized that the last line omits "\\" by mistake.

Note that username in Microsoft implementation can have "\", however I
haven't tested if this causes any hash calculation problems (or maybe I
did, but I don't remember now).

>A <qdstr-val> is apparently used as is including any <quoted-pair>.
>
>Are you sure that existing implementations got this wrong and
>removed the backslashes introducing a <quoted-pair> ?  Otherwise
>I'd think it's an incompatibility with 2831 / 2617 / 2069, and it
>should be listed in appendices A and B.

[...]

>C.1: s/2052/2782/ and move to informative,

Done

> maybe replace [Unicode]
>     by [3629] + [UTR #36],
>
>s/2279/3629/ for [UTF-8]

Done

>, s/3548/4648/

Done.

>     The URL in the informative [MD5] reference is broken. try this:
>     <ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto1n1.pdf> (and
>     maybe add 375 KB in the <format> element if you use xml2rfc ;-)

Updated. Thanks.

Date: Tue, 14 Nov 2006 08:54:45 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Calculation of SASL GS2 mechanism names
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

At 08:19 AM 11/14/2006, Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
>
>> The answer to my question might be obvious, but why can't we just use
>> SHA1 on a dot separated representation of a GSS-API OID?
>
>That would seem to work, and would avoid the complexities and pitfalls
>of DER-encoding.
>
>It would still be necessary to base32 encode and truncate the string,
>though, since mechanism names are limited to 20 characters.
>
>/Simon

If we go this way, the following ABNF can be used to describe
an OID in dotted-decimal form.

        numericoid = number 1*( DOT number )
        number  = DIGIT / ( LDIGIT 1*DIGIT )
        DIGIT   = %x30 / LDIGIT       ; "0"-"9"
        LDIGIT  = %x31-39             ; "1"-"9"

Regards, Kurt 

Date: Tue, 14 Nov 2006 16:32:27 +0000
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Calculation of SASL GS2 mechanism names
Sender: [email-masked]

Sam Hartman wrote:

>>>>>>"Alexey" == Alexey Melnikov <[email-masked]> writes:
>>>>>>            
>>>>>>
>    Alexey> Sam Hartman wrote:
>    >> One question to consider is whether a gss implementation is
>    >> more likely to have the dot-separated OID or the BER form.
>    >> 
>    >> 
>    Alexey> Does GSS-API specify how OIDs are stored?
>
>Yes.
>  
>
How is it stored?

>    >> Also, note that BER is canonical.  Consider the difference
>    >> between 1.002 and 1.2
>    >> 
>    >> 
>    Alexey> I would rather say that the dot-separated form must be
>    Alexey> canonical, rather than forcing people to implement BER
>
>No, I mean canonical in the sense of there is one canonical encoding.
>That is not true for the dot notation.
>  
>
I meant "canonical == no leading 0s".

From: Sam Hartman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Calculation of SASL GS2 mechanism names
Date: Tue, 14 Nov 2006 11:31:09 -0500
Sender: [email-masked]

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

    Alexey> Sam Hartman wrote:
    >> One question to consider is whether a gss implementation is
    >> more likely to have the dot-separated OID or the BER form.
    >> 
    >> 
    Alexey> Does GSS-API specify how OIDs are stored?

Yes.

    >> Also, note that BER is canonical.  Consider the difference
    >> between 1.002 and 1.2
    >> 
    >> 
    Alexey> I would rather say that the dot-separated form must be
    Alexey> canonical, rather than forcing people to implement BER

No, I mean canonical in the sense of there is one canonical encoding.
That is not true for the dot notation.

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Sam Hartman <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Calculation of SASL GS2 mechanism names
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Nov 2006 17:29:01 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Sam Hartman wrote:
>
>>One question to consider is whether a gss implementation is more
>>likely to have the dot-separated OID or the BER form.
>>  
>>
> Does GSS-API specify how OIDs are stored?
>
>>Also, note that BER is canonical.  Consider the difference between 1.002 and 1.2

A side-note: BER isn't canonical.  DER is canonical, and GS2 uses it.
Unfortunately, RFC 2743 is not strict on the terminology, and mixes
BER and DER.

> I would rather say that the dot-separated form must be canonical,
> rather than forcing people to implement BER encoding in there SASL
> implementations ;-).

I don't care either way.

I suspect some SASL implementations will not bother to implement DER
encoding for GS2, but hard code the hand-computed SASL name for the
GSS-API mechanism they know are supported.

/Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Calculation of SASL GS2 mechanism names
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Nov 2006 17:19:09 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> The answer to my question might be obvious, but why can't we just use
> SHA1 on a dot separated representation of a GSS-API OID?

That would seem to work, and would avoid the complexities and pitfalls
of DER-encoding.

It would still be necessary to base32 encode and truncate the string,
though, since mechanism names are limited to 20 characters.

/Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Nov 2006 17:16:51 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Simon Josefsson wrote:
>
>>All:
>>
>>I have submitted an updated version of GS2.  Until it shows up in the
>>repository, you can view it from:
>>
>>http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-03.txt
>>  
>>
> Some minor comments:
>
> In section 4.1. (SASL Messages):
>
>   Messages shorter than or equal to 12 octets are invalid.  From that
>   it follows that not both of the "Context token length" and the "Wrap
>   token length" integers can be zero in a particular message.
>
> The last quoted sentence is difficult to read. Suggested replacement:
>
>   From that it follows that at least one of the "Context token length"
>   and the "Wrap token length" integers must be non-zero in a
> particular message.

Added, thanks!

/Simon

Date: Tue, 14 Nov 2006 15:46:38 +0000
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Calculation of SASL GS2 mechanism names
Sender: [email-masked]

Sam Hartman wrote:

>One question to consider is whether a gss implementation is more
>likely to have the dot-separated OID or the BER form.
>  
>
Does GSS-API specify how OIDs are stored?

>Also, note that BER is canonical.  Consider the difference between 1.002 and 1.2
>  
>
I would rather say that the dot-separated form must be canonical, rather 
than forcing people to implement BER encoding in there SASL 
implementations ;-).

From: Sam Hartman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Calculation of SASL GS2 mechanism names
Date: Tue, 14 Nov 2006 10:18:25 -0500
Sender: [email-masked]

One question to consider is whether a gss implementation is more
likely to have the dot-separated OID or the BER form.
Also, note that BER is canonical.  Consider the difference between 1.002 and 1.2

--Sam

Date: Mon, 13 Nov 2006 19:58:27 +0000
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Calculation of SASL GS2 mechanism names
Sender: [email-masked]

The answer to my question might be obvious, but why can't we just use 
SHA1 on a dot separated representation of a GSS-API OID?

Date: Mon, 13 Nov 2006 17:15:36 +0000
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: GS2 update
Sender: [email-masked]

Simon Josefsson wrote:

>All:
>
>I have submitted an updated version of GS2.  Until it shows up in the
>repository, you can view it from:
>
>http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-03.txt
>  
>
Some minor comments:

In section 4.1. (SASL Messages):

   Messages shorter than or equal to 12 octets are invalid.  From that
   it follows that not both of the "Context token length" and the "Wrap
   token length" integers can be zero in a particular message.

The last quoted sentence is difficult to read. Suggested replacement:

   From that it follows that at least one of the "Context token length"
   and the "Wrap token length" integers must be non-zero in a particular 
message.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Updated DIGEST-MD5 document (draft-ietf-sasl-rfc2831bis-10.txt)
Date:  Sat, 11 Nov 2006 05:29:17 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 82
Sender: [email-masked]

Alexey Melnikov wrote:

> I need more reviews

1 - Please use RFC 4234 ABNF, not the RFC 822 version.  There are
    various tools that can handle 4234-ABNF, readers are familiar
    with it (after some time), and I've no clue if "implicit LWS"
    allows several adjacent CRLF SP.

    Here's an example how to translate <qop-options> to 4234-ABNF:

-   qop-options       = "qop" "=" DQUOTE qop-list DQUOTE
-   qop-list          = 1#qop-value
-   qop-value         = "auth" | "auth-int" | "auth-conf" |
-                       qop-token
+   qop-options       = "qop" EQU DQUOTE qop-list DQUOTE
+   qop-list          = [LWS] qop-value *( SEP qop-value ) [LWS]
+   qop-value         = "auth" / "auth-int" / "auth-conf" /
+                       qop-token
+   EQU               = [LWS] "=" [LWS]
+   SEP               = [LWS] "," [LWS]
+   LWS               = [*WSP CRLF] 1*WSP

With EQU recycled in all other name=value pairs, SEP used in all
1# constructs, and LWS derived from RFC 2822 FWS excl. obs-FWS.

If all goes well RFC 4234 is at STD before 2831bis.  It's really
confusing if alternatives sometimes use "|" as in 2068 and 2616,
but at other times "/" as in 822 and 4234.

2 - Is the introduction of the new "backslash-canonicalization"
    necessary ?  RFC 2617 says:

| However, the "unq" notation indicates that surrounding quotation
| marks are removed in forming the string A1.

It also mumbles something about not using a DQUOTE within <nonce>,
apparently clients weren't supposed to look for an escaped DQUOTE.

It's almost exactly the same idea in RFC 2069:

| The "username-value" field is a "quoted-string" as specified in
| section 2.2 of the HTTP/1.1 specification [2].  However, the
| surrounding quotation marks are removed in forming the string A1.

Nothing about looking at backslashes within that string.  RFC 2831:

| quoted-string  = ( <"> qdstr-val <"> )
| qdstr-val      = *( qdtext | quoted-pair )
| qdtext         = <any TEXT except <">>

A <qdstr-val> is apparently used as is including any <quoted-pair>.

Are you sure that existing implementations got this wrong and
removed the backslashes introducing a <quoted-pair> ?  Otherwise
I'd think it's an incompatibility with 2831 / 2617 / 2069, and it
should be listed in appendices A and B.

> opinions on the open issues

A.3 is as you say in progress, see above for an idea how to finish
the transition to 4234-ABNF.  This would also eliminate chapter 7.

Generally 2617 and 2831 is a horrible scheme with its at least 10
parameters, some can be omitted, or empty, or repeated, or they are
required exactly once, in any order.  More ranting removed, it's
not your fault.  Please get rid of the "improvement over CRAM-MD5"
hype in the abstract.

C.1: s/2052/2782/ and move to informative, maybe replace [Unicode]
     by [3629] + [UTR #36], s/2279/3629/ for [UTF-8], s/3548/4648/

     The URL in the informative [MD5] reference is broken. try this:
     <ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto1n1.pdf> (and
     maybe add 375 KB in the <format> element if you use xml2rfc ;-)

C.4: Seconded, one example for any major modification, e.g. something
     with the new unq function if you keep that, and something where
     prep has an effect (the 2195bis Aladin example is nice), etc.

Frank

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: IETF67 SASL WG summary
From: Tom Yu <[email-masked]>
Date: Thu, 09 Nov 2006 15:43:19 -0500
Lines: 58
Sender: [email-masked]

SASL WG
Tuesday, November 7, 2006, at 1740-1840

SUMMARY
=======

Thanks to Chris Newman and Lisa Dusseault for scribing.

Document Status:

CRAM-MD5 - needs new rev
GS2 - some open issues
GSSAPI - RFC Editor queue
PLAIN - RFC 4616
rfc2831bis (DIGEST-MD5) - some open issues

Only minor open issues in DIGEST-MD5; we will coordinate with HTTP
people to investigate possible HTTP compatibility issues.  CRAM-MD5
needs new revision with Kurt's proposed applicability text and other
minor changes.

Extended discussion ensues about GS2 and channel bindings.  Simon
Josefsson has some concerns about implementability of TLS channel
bindings due to lack of adequate specification.  Explicitly reference
Jeff Altman's TLS channel bindings draft?  Consensus that this is a
bad idea; leave GS2 alone for now (referencing
draft-williams-on-channel-binding).

Some discussion occurs about advancing specifications to Draft
Standard.

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

* Chris Newman and Jeff Altman will do reviews of DIGEST-MD5 by end of
  Nov.  HTTP people will be contacted too.

* Lyndon will incorporate new CRAM-MD5 text by end of Nov.

* Alexey will verify that GS2 last call issues are addressed in
  current doc rev.

* Alexey, Jeff Altman, and Kurt will independently compute the krb5
  GS2 mechanism name for verification.

* Kurt will form a design team to determine what's needed for the
  interop reports.

* Milestones:

Nov 2006 WGLC for CRAM-MD5
Nov 2006 WGLC for GS2
Nov 2006 WGLC for DIGEST-MD5
Dec 2006 CRAM-MD5 to IESG
Dec 2006 GS2 to IESG
Dec 2006 DIGEST-MD5 to IESG
Jun 2007 Implementation report plan
Jul 2007 Revise charter or conclude

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 07 Nov 2006 16:56:32 +0100
Sender: [email-masked]

Hi all!  I have written a presentation that gives a status update:

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

I didn't realize until now that the meeting takes place 3-5AM my time
zone, and I'm leaving for another conference early tomorrow, so I
won't be able to participate even remotely.

There are basically three remaining issues for GS2 -- see the
presentation.  I'd like to see GS2 move forward as fast as possible,
and my recommendation for each of the open issues are as follows:

Non-integrity capable mechanisms/credentials: This is a feature
request that came up during WGLC.  I suggest to move forward with GS2
as-is today, decide later whether to revise GS2 or specify a "GS0"
(see presentation) to handle these mechanisms/credentials, if the need
develops.

Channel bindings: Have a normative reference on
draft-altman-tls-channel-bindings in GS2 and explain which TLS
finished message to use.  Specific suggested solution is to replace:

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

with

   For more discussions of channel bindings, see [7].  For the syntax
   of channel bindings for TLS, see
   [draft-altman-tls-channel-bindings]; GS2 uses the concatenation of
   the initial client and the initial server "finished" TLS messages
   as the channel binding.

Kerberos V5 GS2 mechanism name example: Move forward with GS2 as-is
today, and add the Kerberos V5 example mech name during AUTH48.  The
example is non-normative, although I know implementers will use the
name verbatim so we should make an effort to make it correct.

I believe we can have GS2 ready for IETF-wide last call by next week
if adopt this approach.

Please, consider the delays that are created by alternative solutions,
and don't forget to attach specific text changes against GS2 -03 too.

/Simon

Simon Josefsson <[email-masked]> writes:

> All:
>
> I have submitted an updated version of GS2.  Until it shows up in the
> repository, you can view it from:
>
> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-03.txt
>
> I believe it closes all open issues, except for two that I have
> requested help on before:
>
> 1) Compute Kerberos V5 mech name.
>
> 2) Support for non-integrity capable GSS mechanisms.
>
> However, there has been many changes, and I may have missed some
> suggestions.  Please consider the latest version ready to go except
> for the two issues above.
>
> The first issue above should be easy to close fast if someone can
> independently compute the GS2 mech name for Kerberos V5 OIDs.  I'm
> worried about the lack of response on this matter, it would be a
> simple thing to resolve for anyone with interest in GS2.  Does it
> indicate that nobody is interested in and/or committed to GS2?
>
> The second might warrant more discussion.  I'd welcome text to solve
> this, because I'm not sure how it should work, in particular with
> regards to the integ_req flag.  Personally, I see no point in
> supporting non-integrity authentication mechanisms -- it seems to
> weaken GS2, so I would rather drop the feature and have those
> interested in weak authentication schemes specify their own SASL
> mechanism.  Further, nobody has presented a specific use-case for this
> feature, so it seems to me be feature creepism.  However, text
> proposals to resolve the problem is fine.
>
> /Simon

Date: Mon, 6 Nov 2006 11:24:29 -0800 (PST)
From: Lyndon Nerenberg <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: [email-masked]
Subject: Re: CRAM-MD5 applicability statement
Organization: The Frobozz Magic Homing Pigeon Company
Sender: [email-masked]

Folks, I have a meeting conflict at work that will prevent me from being 
online during the WG sessions.  Here's what I have in the queue for 
changes to the CRAM draft.

1) Add the following text as a third paragraph in section 1:

  On Mon, 14 Aug 2006, Kurt D. Zeilenga wrote:
>
> At IETF#66, I agreed to suggest text for a CRAM-MD5 applicability
> statement suitable for inclusion in draft-ietf-sasl-crammd5-07.
>
>  The CRAM-MD5 mechanism is intended to have limited use on the
>  Internet.  The mechanism offers inadequate protection against
>  common attacks against application-level protocols (see the
>  Security Considerations section) and is prone to interoperability
>  problems (see Interoperability Considerations section). Designers
>  considering profiling use of this mechanism in their
>  application-level protocols should consider alternative
>  mechanisms intended for common use, such as DIGEST-MD5.

2)
> As indicated by my above suggestion, I see the need to add a
> section that discusses known interoperability issues, such as
> those due to incompatible character sets/normalizations/encodings.

This can be incorporated into an expanded Appendix D as part of the 
discussion of the rationale for the changes vs. 2195.

3) Rewrite section 4 to incorporate

> I also suggest starting the security consideration section with
> a brief introductory paragraph that reenforces the position that
> mechanism offers inadequate protection.  It would be good to
> conclude the section with yet another reenforcing statement.

and to clarify (and simplify) the existing text.

5) Delete the last paragraph of section 4.  (I added this in the hope of 
generating some discussion about applicability.  It appears to have done 
it's job ;-)

--lyndon

Date: Fri, 03 Nov 2006 16:37:26 +0000
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Updated DIGEST-MD5 document (draft-ietf-sasl-rfc2831bis-10.txt)
Sender: [email-masked]

Changes since draft-ietf-sasl-rfc2831bis-09.txt:

- Editorial changes:
  - ABNF cleanup
  - Replaced MD5(x) with H(x), as MD5() construct is not defined (thanks 
to Dave Cridland for pointing this out)
  - Reworded the text about authorization identity verification to be 
non normative (as it is a protocol matter).
  - Clarified that cnonce must be the same on reauthentication (this 
differs from HTTP Digest).
  - Cleanup list of changes since HTTP Digest and RFC 2831.
- Non editorial:
  - Replaced RC4 with AES-CTR as mandatory to implement.
  - Added qop and cipher to the new client/server nonce (with channel 
binding), so that they can be protected
  - Moved ABNF reference to the Normative References section.
  - Replaced the text about CBC mode attack with some general 
description of attacks on padding.
  - Added response-v2 option, i.e. client now generates two hashes, 
authentication succeed if the server can verify either one.
     (Thanks to Jeffrey Hutzelman regarding this change)
  - Cleaned up description of prep directive. Username/password 
preparation is now done on both the client and the server.

Open issues/todo:
  - Add some text why RC4 is no longer mandatory to implement (?)
  - Reference to the document describing channel binding for TLS needs 
to be corrected.
  - Backward compatibility with RFC 2831 needs to be clarified (.e.g. 
when charset directive is present and the prep directive is not)
  - Interaction between the new prep and the old charset directives 
needs to be clarified
  - The charset directive is kind of optional, but in practice it is 
not. Should it just be made mandatory?
  - Updated examples to match the new text

Despite the list of open issues I think the document is ready for the 
WGLC. In particular, I need more reviews (and opinions on the open 
issues from reviewers) in order to move forward with the document.

Regards,
Alexey