Subject: Re: WG Review: draft-ietf-sasl-gssapi-03.txt
From: Nicolas Williams <[email-masked]>
To: Paul Leach <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>, Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Date: Wed, 30 Nov 2005 21:12:11 -0600
List-Id: <ietf-sasl.imc.org>

On Wed, Nov 30, 2005 at 07:24:48PM -0600, Nicolas Williams wrote:
> These are our choices:
> 
> [...]
> 
> Pick one.

I didn't mean to sound harsh, BTW.

Date: Wed, 30 Nov 2005 19:24:48 -0600
From: Nicolas Williams <[email-masked]>
To: Paul Leach <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: WG Review: draft-ietf-sasl-gssapi-03.txt
Mail-Followup-To: Paul Leach <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>, Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 30, 2005 at 04:56:12PM -0800, Paul Leach wrote:
> As a person who has to implement both straight GSS and SASL, I would
> much prefer that I only have to implement one negotiation mechanism, or,
> barring that, that my customers usually only have to deploy one
> negotiation mechanism.
> 
> Furthermore, SPNEGO protects its negotiations, and as I understand it
> the SASL negotiation is not protected.

Not quite right.  RFC222bis says that apps SHOULD get the mech list from
the server again after establishing security layers and compare it to
the unprotected list.

> Hence, I would prefer to use GSS-SPNEGO as the only negotiation
> mechanism where possible.

This is very difficult to do without either:

 - making sure that we have GSS mechanisms for every existing SASL
   mechanism

   or

 - without having something in the SASL/GSS bridge like I proposed
   earlier for the new bridge for protecting the integrity of the server
   SASL mech list in the GSS bridge

An earlier draft used relative mechanism strength factors -- that turned
out to be dangerous and difficult to implement to boot.

> Finally, our implementation of GSS-SPNEGO does some extra local
> processing, such as determining which mechanisms to use based on whether
> usable credentials for the mechanism are available for the two
> communicating systems (in addition to just whether an implementation of
> the mechanism is available).

SPNEGO implementations should do this to begin with -- what's the point
of offering a mechanism that one lacks credentials to use?

> For the above reasons, I'd prefer that GSS-SPNEGO not be deprecated. (Or
> perhaps I really should say that I prefer that GS2-SPEGO should not be
> deprecated).

Does knowledge that SASL does provide a way for SASL apps to protect
their negotiation affect your view?

> While I expect that we will implement whatever is needed for
> interoperability, in many situations we would recommend that the only
> SASL mechanism advertised would be the SPNEGO based one, and let SPNEGO
> do the rest of the negotiation.

Oh, I too would rather just have GSS-API mechanisms and treat SASL as a
legacy framework that can use GSS mechanisms to get by.  This would
require that we design GSS mechanisms at least for the SASL DIGEST-MD5
mechanism.

These are our choices:

a) SASL/GS2 explicitly prohibits SPNEGO
b) SASL/GS2 provides protection for SASL mech lists
c) specify a DIGEST-MD5 GSS-API mechanism, deprecate all non-GSS SASL
   mechanisms, and close the SASL mechanism namespace.

Pick one.

(a) is the simplest, easiest to specify and implement
(b) is the next simplest
(c) will take a lot of time and effort to get out the door

I proposed (b) originally, but now pick "not (c), preferably (a)."

Nico
-- 

Content-class: urn:content-classes:message
Subject: RE: WG Review: draft-ietf-sasl-gssapi-03.txt
Date: Wed, 30 Nov 2005 16:56:12 -0800
From: "Paul Leach" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, "Alexey Melnikov" <[email-masked]>
Cc: "Nicolas Williams" <[email-masked]>, "Simon Josefsson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

As a person who has to implement both straight GSS and SASL, I would
much prefer that I only have to implement one negotiation mechanism, or,
barring that, that my customers usually only have to deploy one
negotiation mechanism.

Furthermore, SPNEGO protects its negotiations, and as I understand it
the SASL negotiation is not protected.

Hence, I would prefer to use GSS-SPNEGO as the only negotiation
mechanism where possible.

Finally, our implementation of GSS-SPNEGO does some extra local
processing, such as determining which mechanisms to use based on whether
usable credentials for the mechanism are available for the two
communicating systems (in addition to just whether an implementation of
the mechanism is available).

For the above reasons, I'd prefer that GSS-SPNEGO not be deprecated. (Or
perhaps I really should say that I prefer that GS2-SPEGO should not be
deprecated).

While I expect that we will implement whatever is needed for
interoperability, in many situations we would recommend that the only
SASL mechanism advertised would be the SPNEGO based one, and let SPNEGO
do the rest of the negotiation.

Date: Wed, 30 Nov 2005 20:41:42 +0000
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: [email-masked]
Subject: Re: WG Review: draft-ietf-sasl-gssapi-03.txt
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>>>So I'm willing to accept SASL/GSS as is only to obsolete it.  I'd also
>>>be happy with SASL/GSS being pared down to just those parts that have
>>>actually been implemented -- publish as Historic and replace it with
>>>SASL/GS2.
>>>      
>>>
>>I am uncomfortable publishing SASL/GSS as Historic, because it is relatively widely deployed and there are no implementations of GS2.
>>But once the situation changes it should be moved to Historic.
>>    
>>
>
>I think we should handle the SASL/GSSAPI (KerberosV) mechanism
>much like we are handling the SASL/CRAM-MD5 mechanism.  Document
>what folks are doing in an Informational RFC, provide better
>mechanisms (e.g., GS2) in Standard Track RFCs.
>  
>
Well, I disagree.
GSSAPI is not nearly as broken as CRAM-MD5. It supports authorization 
identities and has a security layer.
It doesn't provide channel bindings, but is it such a big deal, 
considering that it has own security layer?

If ability to have channel bindings is a requirement for all SASL 
mechanisms, then at the moment we have no single mechanism in this WG 
that would qualify for anything other then Historic. (DIGEST-MD5 can be 
disqualified for other reasons)

I don't see this WG to be very energetic, so lets publish GSSAPI as 
Standard Track (to document existing practices) and move it to Historic 
once GS2 is done.

Date: Wed, 30 Nov 2005 14:24:40 -0600
From: Nicolas Williams <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: WG Review: draft-ietf-sasl-gssapi-03.txt
Mail-Followup-To: "Kurt D. Zeilenga" <[email-masked]>, Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 30, 2005 at 08:37:57AM -0800, Kurt D. Zeilenga wrote:
> At 04:40 AM 11/30/2005, Alexey Melnikov wrote:
> >Is it worth documenting the problem with GSS-SPNEGO in the document?
> 
> I note that the GSS-SPNEGO's mechanism registration and
> specification are not under the IETF change control.  I
> think we don't have a sufficient good reason to take
> over change control over the registration nor the
> specification. 

Ah yes, the IANA registration entry for SASL GSS-SPNEGO is:

MECHANISMS           USAGE    REFERENCE   OWNER
----------           -----    ---------   -----
GSS-SPNEGO           LIMITED  [Leach]     Paul Leach <[email-masked]>

> If there are problems to be documented, I suggest someone
> (or the WG) request IANA add a comment to the existing
> registration detailing the problems.

It might be possible to change the entry ownership from Paul to the IETF
if Paul consents to it.

> I recommend we remove any specification of GSS-SPNEGO from
> our draft and, as Simon suggests, word any multi-level
> security consideration (or the like) in general terms.

Or call out the GSS-SPNEGO spec in the SASL/GSS draft as Infromative,
not normative.

> I think we should handle the SASL/GSSAPI (KerberosV) mechanism
> much like we are handling the SASL/CRAM-MD5 mechanism.  Document
> what folks are doing in an Informational RFC, provide better
> mechanisms (e.g., GS2) in Standard Track RFCs.

Yes.

> I see no reason to do any further work on the SASL/GS1 family of
> mechanisms.

Do we need a new document for SASL/GS1 at all then?

Nico
-- 

Date: Wed, 30 Nov 2005 08:37:57 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: WG Review: draft-ietf-sasl-gssapi-03.txt
Cc: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

At 04:40 AM 11/30/2005, Alexey Melnikov wrote:

>Nicolas Williams wrote:
>
>>On Tue, Nov 29, 2005 at 11:37:35PM +0100, Simon Josefsson wrote:
>> 
>>
>>>I reviewed the document.  Two high-level comments:
>>>
>>>1. Does anyone care about GSS-SPNEGO?  It is not in RFC 2222.  Has it
>>>  been implemented?  My preference is to only forward SASL mechanisms
>>>  on the standards track that we know are good and that we want to
>>>  promote.  I'm not sure this holds for GSS-SPNEGO; I don't see any
>>>  value in implementing it and haven't done so.  I don't see it in
>>>  Cyrus SASL either, but I may be missing something.
>>>   
>Cyrus SASL doesn't implement GSS-SPNEGO.
>
>I only know about Microsoft implementation.
>
>>
>>I think it's fair to say that the GSS-SPNEGO mechanism is difficult to
>>implement because of the two-layer negotiation problem.  I'd rather see
>>GSS-SPNEGO go away, but I'd much rather still see SASL/GS2 replace
>>SASL/GSS.
>Is it worth documenting the problem with GSS-SPNEGO in the document?

I note that the GSS-SPNEGO's mechanism registration and
specification are not under the IETF change control.  I
think we don't have a sufficient good reason to take
over change control over the registration nor the
specification. 

If there are problems to be documented, I suggest someone
(or the WG) request IANA add a comment to the existing
registration detailing the problems.

I recommend we remove any specification of GSS-SPNEGO from
our draft and, as Simon suggests, word any multi-level
security consideration (or the like) in general terms.

>>So I'm willing to accept SASL/GSS as is only to obsolete it.  I'd also
>>be happy with SASL/GSS being pared down to just those parts that have
>>actually been implemented -- publish as Historic and replace it with
>>SASL/GS2.
>I am uncomfortable publishing SASL/GSS as Historic, because it is relatively widely deployed and there are no implementations of GS2.
>But once the situation changes it should be moved to Historic.

I think we should handle the SASL/GSSAPI (KerberosV) mechanism
much like we are handling the SASL/CRAM-MD5 mechanism.  Document
what folks are doing in an Informational RFC, provide better
mechanisms (e.g., GS2) in Standard Track RFCs.

>>>2. Channel bindings are not supported.  If we are updating DIGEST-MD5
>>>  to add that feature, shouldn't we hold this document to the same
>>>  standard?  That essentially amount to GS2 though.
>>>   
>>
>>Precisely: let SASL/GS2 replace SASL/GSS and be done.
>>
>>I think it's worth documenting at least those parts of SASL/GSS that
>>have been implemented.

I think the SASL/GSSAPI (KerberosV) mechanism specification should
simply note its failings as security considerations and refer
implementors to the SASL/GS2 specification.

I see no reason to do any further work on the SASL/GS1 family of
mechanisms.

kurt

From: Simon Josefsson <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: [email-masked]
Subject: Re: GS2 & two-level negotiation: a possible solution
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 30 Nov 2005 18:02:35 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Nov 30, 2005 at 12:45:01AM +0100, Simon Josefsson wrote:
>> 
>> Nicolas Williams <[email-masked]> writes:
>> 
>> > On Tue, Nov 29, 2005 at 11:44:48PM +0100, Simon Josefsson wrote:
>> >> I think we could simply say that you "MUST NOT use SPNEGO under GS2".
>> >> 
>> >> Does anyone object to making that change?
>> >
>> > I support that change.
>> 
>> On second thought, should we make it "MUST NOT use any GSS-API
>> mechanism, such as SPNEGO, that negotiate between mechanisms that
>> could be negotiated directly through SASL"?
>> 
>> That would also include SPNEGO-like mechanisms.
>
> Yes.
>
> See draft-ietf-kitten-extended-mech-inquiry-01.txt, specifically
> GSS_Inquire_attrs_for_mech() and GSS_C_MA_MECH_NEGO.

Thank you for the pointer.

I have updated the draft, available from

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

with several fixes.

I replaced the section on SPNEGO with the following.  Is this ok?

I have more things to fix before re-submitting it.

Thanks,
Simon

5.  Mechanisms that negotiate other mechanisms

   A GSS-API mechanism that negotiate other mechanisms interact badly
   with the SASL mechanism negotiation.  There are two problems.  The
   first is an interoperability problem and the second is a security
   concern.

   For the reasons explained in the following two sections, a GSS-API
   mechanism used under GS2 MUST NOT negotiate other mechanisms.  This
   specifically covers SPNEGO [10].  The GSS_C_MA_MECH_NEGO attribute of
   GSS_Inquire_attrs_for_mech() [15] can be used to identify these
   mechanisms.

5.1.  Interoperability problem

   A SASL client or server that implement the Kerberos V5 GSSAPI
   mechanism under GS2 will not interoperate with a client/server that
   only implement the "GSSAPI" SASL mechanism, nor will it interoperate
   with a client/server that only implement the Kerberos V5 GSSAPI
   mechanism under the "GSS-SPNEGO" SASL mechanism.

   The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which
   could enable certain tunnel attacks [16].  If Kerberos V5 is
   supported, it is RECOMMENDED to support Kerberos V5 under GS2.  If
   the lack of channel bindings is acceptable, for backwards
   compatibility reasons, it is RECOMMENDED to, in addition, also
   support Kerberos V5 under the "GSSAPI" mechanism.

   The SPNEGO mechanism is not supported under GS2, so if the SPNEGO
   mechanism is supported under SASL, the "GSS-SPNEGO" mechanism will be
   used.

5.2.  Security problem

   If a client's policy is to first prefer GSSAPI mechanism X, then non-
   GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports
   mechanisms Y and Z but not X, then if the client attempts to
   negotiate mechanism X by using a GSS-API mechanism that negotiate
   other mechanisms (such as SPNEGO), it may end up using mechanism Z
   when it should have used mechanism Y. For this reason, the use of
   GSS-API mechanisms that negotiate other mechanisms are disallowed
   under GS2.

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked], Nicolas Williams <[email-masked]>
Subject: Re: WG Review: draft-ietf-sasl-gssapi-03.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 30 Nov 2005 17:57:14 +0100
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Nicolas Williams wrote:
>
>>On Tue, Nov 29, 2005 at 11:37:35PM +0100, Simon Josefsson wrote:
>>  
>>
>>>I reviewed the document.  Two high-level comments:
>>>
>>>1. Does anyone care about GSS-SPNEGO?  It is not in RFC 2222.  Has it
>>>   been implemented?  My preference is to only forward SASL mechanisms
>>>   on the standards track that we know are good and that we want to
>>>   promote.  I'm not sure this holds for GSS-SPNEGO; I don't see any
>>>   value in implementing it and haven't done so.  I don't see it in
>>>   Cyrus SASL either, but I may be missing something.
>>>    
>>>
> Cyrus SASL doesn't implement GSS-SPNEGO.
>
> I only know about Microsoft implementation.

Ok, that makes one.  Then I think it is good to document it.

>>I think it's fair to say that the GSS-SPNEGO mechanism is difficult to
>>implement because of the two-layer negotiation problem.  I'd rather see
>>GSS-SPNEGO go away, but I'd much rather still see SASL/GS2 replace
>>SASL/GSS.
>>
> Is it worth documenting the problem with GSS-SPNEGO in the document?

This is documented now, right?  There is a section on SPNEGO.

>>So I'm willing to accept SASL/GSS as is only to obsolete it.  I'd also
>>be happy with SASL/GSS being pared down to just those parts that have
>>actually been implemented -- publish as Historic and replace it with
>>SASL/GS2.
>>
> I am uncomfortable publishing SASL/GSS as Historic, because it is
> relatively widely deployed and there are no implementations of GS2.
> But once the situation changes it should be moved to Historic.

I don't care.  I note that CRAM-MD5 is widely deployed too.

>>>2. Channel bindings are not supported.  If we are updating DIGEST-MD5
>>>   to add that feature, shouldn't we hold this document to the same
>>>   standard?  That essentially amount to GS2 though.
>>>    
>>>
>>
>>Precisely: let SASL/GS2 replace SASL/GSS and be done.
>>
>>I think it's worth documenting at least those parts of SASL/GSS that
>>have been implemented.

I agree.

Thanks,
Simon

Date: Wed, 30 Nov 2005 10:33:05 -0600
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: WG Review: draft-ietf-sasl-gssapi-03.txt
Mail-Followup-To: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 30, 2005 at 12:40:39PM +0000, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >On Tue, Nov 29, 2005 at 11:37:35PM +0100, Simon Josefsson wrote:
> >>I reviewed the document.  Two high-level comments:
> >>
> >>1. Does anyone care about GSS-SPNEGO?  It is not in RFC 2222.  Has it
> >>  been implemented?  My preference is to only forward SASL mechanisms
> >>  on the standards track that we know are good and that we want to
> >>  promote.  I'm not sure this holds for GSS-SPNEGO; I don't see any
> >>  value in implementing it and haven't done so.  I don't see it in
> >>  Cyrus SASL either, but I may be missing something.
> >>   
> >>
> Cyrus SASL doesn't implement GSS-SPNEGO.
> 
> I only know about Microsoft implementation.

We (Sun) have an implementation that we didn't ship because at the time
the text on multi-layer negotiation was not implementable.

> >
> >I think it's fair to say that the GSS-SPNEGO mechanism is difficult to
> >implement because of the two-layer negotiation problem.  I'd rather see
> >GSS-SPNEGO go away, but I'd much rather still see SASL/GS2 replace
> >SASL/GSS.
> >
> Is it worth documenting the problem with GSS-SPNEGO in the document?

If there's at least one implementor (there is), yes.

> >
> >So I'm willing to accept SASL/GSS as is only to obsolete it.  I'd also
> >be happy with SASL/GSS being pared down to just those parts that have
> >actually been implemented -- publish as Historic and replace it with
> >SASL/GS2.
> >
> I am uncomfortable publishing SASL/GSS as Historic, because it is 
> relatively widely deployed and there are no implementations of GS2.
> But once the situation changes it should be moved to Historic.

Ok.

Date: Wed, 30 Nov 2005 12:40:39 +0000
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: WG Review: draft-ietf-sasl-gssapi-03.txt
Sender: [email-masked]

Nicolas Williams wrote:

>On Tue, Nov 29, 2005 at 11:37:35PM +0100, Simon Josefsson wrote:
>  
>
>>I reviewed the document.  Two high-level comments:
>>
>>1. Does anyone care about GSS-SPNEGO?  It is not in RFC 2222.  Has it
>>   been implemented?  My preference is to only forward SASL mechanisms
>>   on the standards track that we know are good and that we want to
>>   promote.  I'm not sure this holds for GSS-SPNEGO; I don't see any
>>   value in implementing it and haven't done so.  I don't see it in
>>   Cyrus SASL either, but I may be missing something.
>>    
>>
Cyrus SASL doesn't implement GSS-SPNEGO.

I only know about Microsoft implementation.

>
>I think it's fair to say that the GSS-SPNEGO mechanism is difficult to
>implement because of the two-layer negotiation problem.  I'd rather see
>GSS-SPNEGO go away, but I'd much rather still see SASL/GS2 replace
>SASL/GSS.
>
Is it worth documenting the problem with GSS-SPNEGO in the document?

>
>So I'm willing to accept SASL/GSS as is only to obsolete it.  I'd also
>be happy with SASL/GSS being pared down to just those parts that have
>actually been implemented -- publish as Historic and replace it with
>SASL/GS2.
>
I am uncomfortable publishing SASL/GSS as Historic, because it is 
relatively widely deployed and there are no implementations of GS2.
But once the situation changes it should be moved to Historic.

>>2. Channel bindings are not supported.  If we are updating DIGEST-MD5
>>   to add that feature, shouldn't we hold this document to the same
>>   standard?  That essentially amount to GS2 though.
>>    
>>
>
>Precisely: let SASL/GS2 replace SASL/GSS and be done.
>
>I think it's worth documenting at least those parts of SASL/GSS that
>have been implemented.
>
>  
>

Date: Tue, 29 Nov 2005 18:18:16 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: GS2 & two-level negotiation: a possible solution
Mail-Followup-To: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 30, 2005 at 12:45:01AM +0100, Simon Josefsson wrote:
> 
> Nicolas Williams <[email-masked]> writes:
> 
> > On Tue, Nov 29, 2005 at 11:44:48PM +0100, Simon Josefsson wrote:
> >> I think we could simply say that you "MUST NOT use SPNEGO under GS2".
> >> 
> >> Does anyone object to making that change?
> >
> > I support that change.
> 
> On second thought, should we make it "MUST NOT use any GSS-API
> mechanism, such as SPNEGO, that negotiate between mechanisms that
> could be negotiated directly through SASL"?
> 
> That would also include SPNEGO-like mechanisms.

Yes.

See draft-ietf-kitten-extended-mech-inquiry-01.txt, specifically
GSS_Inquire_attrs_for_mech() and GSS_C_MA_MECH_NEGO.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: [email-masked]
Subject: Re: GS2 & two-level negotiation: a possible solution
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 30 Nov 2005 00:45:01 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Nov 29, 2005 at 11:44:48PM +0100, Simon Josefsson wrote:
>> I think we could simply say that you "MUST NOT use SPNEGO under GS2".
>> 
>> Does anyone object to making that change?
>
> I support that change.

On second thought, should we make it "MUST NOT use any GSS-API
mechanism, such as SPNEGO, that negotiate between mechanisms that
could be negotiated directly through SASL"?

That would also include SPNEGO-like mechanisms.

There is a complication if the mechanism can negotiate between some
mechanisms that are supported by SASL (e.g., username/password) and
other more advanced methods not supported by SASL.  I think we could
ignore this until anyone has a real-world example.

Thanks,
Simon

Date: Tue, 29 Nov 2005 17:33:59 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: GS2 & two-level negotiation: a possible solution
Mail-Followup-To: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Nov 29, 2005 at 11:44:48PM +0100, Simon Josefsson wrote:
> I think we could simply say that you "MUST NOT use SPNEGO under GS2".
> 
> Does anyone object to making that change?

I support that change.

Date: Tue, 29 Nov 2005 17:07:22 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: WG Review: draft-ietf-sasl-gssapi-03.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Nov 29, 2005 at 11:37:35PM +0100, Simon Josefsson wrote:
> 
> I reviewed the document.  Two high-level comments:
> 
> 1. Does anyone care about GSS-SPNEGO?  It is not in RFC 2222.  Has it
>    been implemented?  My preference is to only forward SASL mechanisms
>    on the standards track that we know are good and that we want to
>    promote.  I'm not sure this holds for GSS-SPNEGO; I don't see any
>    value in implementing it and haven't done so.  I don't see it in
>    Cyrus SASL either, but I may be missing something.

I think it's fair to say that the GSS-SPNEGO mechanism is difficult to
implement because of the two-layer negotiation problem.  I'd rather see
GSS-SPNEGO go away, but I'd much rather still see SASL/GS2 replace
SASL/GSS.

So I'm willing to accept SASL/GSS as is only to obsolete it.  I'd also
be happy with SASL/GSS being pared down to just those parts that have
actually been implemented -- publish as Historic and replace it with
SASL/GS2.

> 2. Channel bindings are not supported.  If we are updating DIGEST-MD5
>    to add that feature, shouldn't we hold this document to the same
>    standard?  That essentially amount to GS2 though.

Precisely: let SASL/GS2 replace SASL/GSS and be done.

I think it's worth documenting at least those parts of SASL/GSS that
have been implemented.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: [email-masked]
Subject: Re: GS2 & two-level negotiation: a possible solution
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 29 Nov 2005 23:44:48 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Nov 23, 2005 at 01:19:17PM -0600, Nicolas Williams wrote:
>> On Wed, Nov 23, 2005 at 11:11:32AM -0800, Chris Newman wrote:
>> > Perhaps we should not worry about protecting the SASL mechanism list.
>> 
>> Perhaps!  I don't have a position on this yet, other than not wanting
>> GS2 to support SPNEGO, and that position is motivated by a desire to
>> avoid the complication of the GS1 multi-layer negotiation issues.
>
> Hmmm, rfc2222bis already has text about what apps that care about
> protected negotiations should do: confirm the SASL mech lists after
> establishing security layers.
>
> That should be enough, so I withdraw my proposal for protecting the
> negotiation in the GS2 bridge, but I reiterate my proposal that the GS2
> bridge prohibit use of mechanism-negotiation mechanisms (i.e., SPNEGO).
>
> I want the two-layer mechanism negotiation issue to go away.

I liked your proposal to protect the SASL capabilities, but after
reading the discussion, I find myself agreeing with this as well.  The
2222bis recommendation to confirm the SASL mech list under a security
layer is sufficient.

I agree with Chris that complexity has a high cost, and any additional
feature has to be motivated.

I mostly dodged the SPNEGO issue in GS2.  I really want it to go away
too.

I think we could simply say that you "MUST NOT use SPNEGO under GS2".

Does anyone object to making that change?

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Review: draft-ietf-sasl-gssapi-03.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 29 Nov 2005 23:37:35 +0100
Sender: [email-masked]

I reviewed the document.  Two high-level comments:

1. Does anyone care about GSS-SPNEGO?  It is not in RFC 2222.  Has it
   been implemented?  My preference is to only forward SASL mechanisms
   on the standards track that we know are good and that we want to
   promote.  I'm not sure this holds for GSS-SPNEGO; I don't see any
   value in implementing it and haven't done so.  I don't see it in
   Cyrus SASL either, but I may be missing something.

2. Channel bindings are not supported.  If we are updating DIGEST-MD5
   to add that feature, shouldn't we hold this document to the same
   standard?  That essentially amount to GS2 though.

Thanks,
Simon

"Kurt D. Zeilenga" <[email-masked]> writes:

> Please review this I-D in the next 2-weeks and raise any issues
> you have with it to the WG.  If after your review, you find it
> suitable for progression without any changes, please inform
> Tom and I have this.  The review period will expire on 7
> December 2005.
>
> It is hoped that after this 2-week review period expires
> that there will not only be a list of specific issues for
> the WG to work on, but that the WG will actively undertake
> the work.
>
> You may consider this a WG Last Call in the sense that if
> the adequate review is not provided, the likely action will
> be to cease this further work on this I-D (within the WG)
> due to lack of interest and to update the charter appropriately.
> So, if you care about this work, you should review the I-D
> now.
>
> It is noted that likely outcome of this review will likely
> lead to significant and substantial changes in the I-D,
> and hence a subsequent WG Last Call.
>
> Kurt Zeilenga, SASL co-chair
>
>   
> At 02:50 PM 9/6/2005, [email-masked] wrote:
>>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           : SASL GSSAPI mechanisms
>>        Author(s)       : A. Melnikov
>>        Filename        : draft-ietf-sasl-gssapi-03.txt
>>        Pages           : 13
>>        Date            : 2005-9-6
>>        
>>The Simple Authentication and Security Layer [SASL] is a method for
>>   adding authentication support to connection-based protocols.  This
>>   document describes the method for using the Generic Security Service
>>   Application Program Interface [GSSAPI] KERBEROS V5 and SPNEGO in the
>>   Simple Authentication and Security Layer [SASL].
>>
>>   This document replaces section 7.2 of RFC 2222 [SASL], the definition
>>   of the "GSSAPI" SASL mechanism.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-03.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-gssapi-03.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-gssapi-03.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.
>>
>>Content-Type: text/plain
>>Content-ID:     <[email-masked]>
>>
>>ENCODING mime
>>FILE /internet-drafts/draft-ietf-sasl-gssapi-03.txt
>>
>>
>><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-03.txt>

To: [email-masked]
Subject: WG Last Call: Simple Authentication and Security Layer (SASL)
From: Tom Yu <[email-masked]>
Date: Mon, 28 Nov 2005 15:18:37 -0500
Lines: 17
Sender: [email-masked]

This message begins a Working Group Last Call on submitting the
following document to the IESG for publication as a Proposed Standard.

	Title		: Simple Authentication and Security Layer (SASL)
	Author(s)	: A. Melnikov, K. Zeilenga
	Filename	: draft-ietf-sasl-rfc2222bis-14.txt
	Pages		: 32
	Date		: 2005-11-21

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

Please review this document, and address feedback to the WG mailing
list.  This Last Call will expire at 17:00 EST on December 12, 2005.

Tom Yu, SASL co-chair

Date: Wed, 23 Nov 2005 14:03:27 -0600
From: Nicolas Williams <[email-masked]>
To: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: GS2 & two-level negotiation: a possible solution
Mail-Followup-To: Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 23, 2005 at 01:19:17PM -0600, Nicolas Williams wrote:
> On Wed, Nov 23, 2005 at 11:11:32AM -0800, Chris Newman wrote:
> > Perhaps we should not worry about protecting the SASL mechanism list.
> 
> Perhaps!  I don't have a position on this yet, other than not wanting
> GS2 to support SPNEGO, and that position is motivated by a desire to
> avoid the complication of the GS1 multi-layer negotiation issues.

Hmmm, rfc2222bis already has text about what apps that care about
protected negotiations should do: confirm the SASL mech lists after
establishing security layers.

That should be enough, so I withdraw my proposal for protecting the
negotiation in the GS2 bridge, but I reiterate my proposal that the GS2
bridge prohibit use of mechanism-negotiation mechanisms (i.e., SPNEGO).

I want the two-layer mechanism negotiation issue to go away.

Nico
-- 

Date: Wed, 23 Nov 2005 11:19:19 -0800
From: Rob Siemborski <[email-masked]>
To: Chris Newman <[email-masked]>
Subject: Re: GS2 & two-level negotiation: a possible solution
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Sender: [email-masked]

On 11/23/05, Chris Newman <[email-masked]> wrote:

> Perhaps we should not worry about protecting the SASL mechanism list.

I strongly agree.

-Rob

--
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

Date: Wed, 23 Nov 2005 13:19:17 -0600
From: Nicolas Williams <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: [email-masked]
Subject: Re: GS2 & two-level negotiation: a possible solution
Mail-Followup-To: Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Nov 23, 2005 at 11:11:32AM -0800, Chris Newman wrote:
> This sounds like a better plan than using SPNEGO.

Glad you concur.

> However, I am dubious of the value of protecting the mechanism list at all. 
> A truly secure deployment requires configured policy on both the client and 
> the server, and at least one of the useful policies simply won't use weaker 
> mechanisms.  So the downgrade detection feature is not necessary to achieve 
> a secure deployment.

So perhaps we need to decide whether we ever want protected mechanism
negotiations.  If the answer is "never" then drop this proposal.  If the
answer is "sometimes" then keep this proposal but allow the mech lists
in the wrap tokens to be empty as a way to skip negotiation protection.
If the answer is "always" then...

> Given that, is the cost in terms of code complexity for the downgrade 
> detection really worth the benefit?  As we've all seen from the real-world 
> security vulnerabilities with SSL, SSH, IKE, Kerberos, etc., code 
> complexity has a very big impact on security.  While I haven't done an 
> in-depth analysis, my instinct is that the security cost of the 
> code/protocol complexity necessary to protect the mechanism list exceeds 
> the security benefit of the downgrade attack detection.

The code complexity embodied here is mostly about getting the app to
provide the SASL mech lists to the mechanism -- a smallish, IMO, layer
violation.

Actual verification that no downgrade attack has taken place is trivial:
octet string equality comparison.

> Perhaps we should not worry about protecting the SASL mechanism list.

Perhaps!  I don't have a position on this yet, other than not wanting
GS2 to support SPNEGO, and that position is motivated by a desire to
avoid the complication of the GS1 multi-layer negotiation issues.

Nico
-- 

Date: Wed, 23 Nov 2005 11:11:32 -0800
From: Chris Newman <[email-masked]>
Subject: Re: GS2 & two-level negotiation: a possible solution
To: Nicolas Williams <[email-masked]>, [email-masked]
Sender: [email-masked]

This sounds like a better plan than using SPNEGO.

However, I am dubious of the value of protecting the mechanism list at all.  A 
truly secure deployment requires configured policy on both the client and the 
server, and at least one of the useful policies simply won't use weaker 
mechanisms.  So the downgrade detection feature is not necessary to achieve a 
secure deployment.

Given that, is the cost in terms of code complexity for the downgrade detection 
really worth the benefit?  As we've all seen from the real-world security 
vulnerabilities with SSL, SSH, IKE, Kerberos, etc., code complexity has a very 
big impact on security.  While I haven't done an in-depth analysis, my instinct 
is that the security cost of the code/protocol complexity necessary to protect 
the mechanism list exceeds the security benefit of the downgrade attack 
detection.

Perhaps we should not worry about protecting the SASL mechanism list.

                - Chris

Nicolas Williams wrote on 11/23/05 10:44 -0600:

>
> Simon, you may remember that the original GSS bridge has a pretty
> significant flaw with respect to mechanism negotiation, namely that
> applications that results from having two negotiations: one for SASL
> mechanisms, and then SPNEGO (when the "GSS-SPNEGO" mech is used).
>
> I think we have a chance to fix this with the GS2 bridge by adding
> protection for the SASL mech list exchanges and prohibiting the use of
> GSS-API mechanisms that negotiate mechanisms (i.e., SPNEGO).
>
> To do this we need to add fields to the negotiation wrap token values:
>
>  - add to the client's wrap token two fields:
>
>     - optional client's SASL mech list (for app protocols where the
>       server gets to pick a mechanism?)
>
>     - server's SASL mech list, as received by the client
>
>
>  - add to the server's wrap token two fields:
>
>     - server's SASL mech list
>
>     - optional client's SASL mech list as received by the server (for
>       app protocols where the server gets to pick a mechanism?)
>
>
> With this we can then simply kill the original bridge and move on.
>
> Nico
> --
>
>

Date: Wed, 23 Nov 2005 10:44:37 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: GS2 & two-level negotiation: a possible solution
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Simon, you may remember that the original GSS bridge has a pretty
significant flaw with respect to mechanism negotiation, namely that
applications that results from having two negotiations: one for SASL
mechanisms, and then SPNEGO (when the "GSS-SPNEGO" mech is used).

I think we have a chance to fix this with the GS2 bridge by adding
protection for the SASL mech list exchanges and prohibiting the use of
GSS-API mechanisms that negotiate mechanisms (i.e., SPNEGO).

To do this we need to add fields to the negotiation wrap token values:

 - add to the client's wrap token two fields:

    - optional client's SASL mech list (for app protocols where the
      server gets to pick a mechanism?)

    - server's SASL mech list, as received by the client

 - add to the server's wrap token two fields:

    - server's SASL mech list

    - optional client's SASL mech list as received by the server (for
      app protocols where the server gets to pick a mechanism?)

With this we can then simply kill the original bridge and move on.

Nico
-- 

Date: Tue, 22 Nov 2005 11:47:48 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: WG Review: draft-ietf-sasl-gssapi-03.txt 
Sender: [email-masked]

Please review this I-D in the next 2-weeks and raise any issues
you have with it to the WG.  If after your review, you find it
suitable for progression without any changes, please inform
Tom and I have this.  The review period will expire on 7
December 2005.

It is hoped that after this 2-week review period expires
that there will not only be a list of specific issues for
the WG to work on, but that the WG will actively undertake
the work.

You may consider this a WG Last Call in the sense that if
the adequate review is not provided, the likely action will
be to cease this further work on this I-D (within the WG)
due to lack of interest and to update the charter appropriately.
So, if you care about this work, you should review the I-D
now.

It is noted that likely outcome of this review will likely
lead to significant and substantial changes in the I-D,
and hence a subsequent WG Last Call.

Kurt Zeilenga, SASL co-chair

At 02:50 PM 9/6/2005, [email-masked] wrote:
>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           : SASL GSSAPI mechanisms
>        Author(s)       : A. Melnikov
>        Filename        : draft-ietf-sasl-gssapi-03.txt
>        Pages           : 13
>        Date            : 2005-9-6
>        
>The Simple Authentication and Security Layer [SASL] is a method for
>   adding authentication support to connection-based protocols.  This
>   document describes the method for using the Generic Security Service
>   Application Program Interface [GSSAPI] KERBEROS V5 and SPNEGO in the
>   Simple Authentication and Security Layer [SASL].
>
>   This document replaces section 7.2 of RFC 2222 [SASL], the definition
>   of the "GSSAPI" SASL mechanism.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-03.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-gssapi-03.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-gssapi-03.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.
>
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-sasl-gssapi-03.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-03.txt>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-14.txt 
Date: Mon, 21 Nov 2005 18: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		: Simple Authentication and Security Layer (SASL)
	Author(s)	: A. Melnikov, K. Zeilenga
	Filename	: draft-ietf-sasl-rfc2222bis-14.txt
	Pages		: 32
	Date		: 2005-11-21
	
The Simple Authentication and Security Layer (SASL) is a framework for
  providing authentication and data security services in
  connection-oriented protocols via replaceable mechanisms.  It provides
  a structured interface between protocols and mechanisms.  The
  resulting framework allows new protocols to reuse existing mechanisms
  and allows old protocols to make use of new mechanisms.  The framework
  also provides a protocol for securing subsequent protocol exchanges
  within a data security layer.

  This document describes how a SASL mechanism is structured, describes
  how protocols include support for SASL, and defines the protocol for
  carrying a data security layer over a connection.  Additionally, this
  document defines one SASL mechanism, the EXTERNAL mechanism.

  This document obsoletes RFC 2222.

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

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

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

--OtherAccess--

--NextPart--

Date: Mon, 21 Nov 2005 18:05:24 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>
cc: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: IANA Considerations
Originator-Info: login-token=Mulberry:01FWXbEH/NUIRhsFORSOMLf6zXEjucmVSC2gl1S+U=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, November 16, 2005 03:42:02 PM -0500 Sam Hartman 
<[email-masked]> wrote:

>
>
>>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:
>
>     Kurt> How about something like?  The review should focus on
>     Kurt> whether or not the requested family name is appropriate for
>     Kurt> the proposed use and the proposed naming and registration
>     Kurt> plan for existing and future mechanisms in the family, etc..
>
>
> This is not a complete sentence and I think it is missing its core.

It's a complete sentence, if you put the parens in the right place:

"The review should focus on whether or not the requested family name is
appropriate for the proposed used, on the proposed naming and
registration plan for existing and future mechanisms in the family, and
on similar factors".

So, an expert can reject a request because it inappropriately uses a
prefix like "STRONG-", or because it attempts to delegate too large a
portion of the namespace "A".  He could also reject it because the
naming plan for the family is a fixed prefix followed by the hexadecimal
encoding of the first four octets of some OID, on the grounds that such
a technique doesn't have strong enough collision-resistance to justify
replacing explicit registration.

In general, I think that Expert Review is an appropriate policy for SASL
mechanism family names, and that Kurt's language both provides sufficient
guidance to the expert and is sufficiently clear about the scope of the
expert's authority.  The goal here is to protect the namespace without
requiring IANA to make determinations requiring technical expertise.  The 
goal is _not_ to require that a particular working group, or mailing list, 
or the IETF as a whole achieve consensus on every family registration (BTW, 
note that there is precedent for designating a mailing list as the expert, 
if an AD chooses to do so).

-- Jeff

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 21 Nov 2005 12:21:09 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Mon, Nov 21, 2005 at 01:06:15AM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[email-masked]> writes:
>> > Why would the client not trust the server to honor the client's
>> > preferences?  Why trust it for anything?
>> 
>> It is not only about trusting it to honor the client's preferences.
>> The server might optimize for other things, such as performance.
>> 
>> So in the original proposal, if both integrity and privacy layer bits
>> were set in the bitmask, and thus acceptable to the client, the server
>> might pick integrity because it cost less CPU.
>
> Yes, I suppose a server might be willing to short-change a client if it
> could avoid committing its preferences before the client.
>
> I'm not sure that servers will, in reality, have an incentive to do this
> to their clients.
>
> But more importantly, I'm not sure that clients should offer QoPs that
> they really don't want -- they should risk failure to authenticate and
> set up security layers over risking the security of the application
> session, if the user really wanted to secure it.

I realize that.  I'm thinking of the case where the client's
preference is "Integrity is acceptable only when I can't get privacy".

That preference cannot be expressed without permitting both the 1) and
2) exchange finishes.

My preference for reading and sending my personal e-mail (which is
unauthenticated and unencrypted in general anyway) against my IMAP and
SMTP server would probably be "I want privacy but can settle with
integrity if the server doesn't support privacy".

I don't know how widely adopted that policy is.

>> Some clients may not care about this, but some might.  With my
>> flexibility, then client can then force the server to send its
>> "server_qops" bitmask, and then the client can select the qop it needs.
>
> Why wouldn't clients that care just offer only confidentiality
> protection?

See above.  This is not a critical security feature.  It is about
being able to express all possible security policies in the protocol.

If nobody else speak up on this, I'll drop the flexibility.

If this is not supported, there should be a security consideration, so
it is clear that not all security preferences can be expressed in the
protocol.

> Or why couldn't they use GS1?  (Let's call the original SASL/GSS
> bridge GS1 for now).

They would have to implement SPNEGO to be able to use it.  The old
GSSAPI/GSS-SPNEGO mechanisms only support Kerberos V5 and mechanisms
under SPNEGO.  That will likely make the protocol even more expensive,
round-trip wise...

Thanks,
Simon

Date: Mon, 21 Nov 2005 00:18:25 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Nov 21, 2005 at 01:06:15AM +0100, Simon Josefsson wrote:
> Nicolas Williams <[email-masked]> writes:
> > Why would the client not trust the server to honor the client's
> > preferences?  Why trust it for anything?
> 
> It is not only about trusting it to honor the client's preferences.
> The server might optimize for other things, such as performance.
> 
> So in the original proposal, if both integrity and privacy layer bits
> were set in the bitmask, and thus acceptable to the client, the server
> might pick integrity because it cost less CPU.

Yes, I suppose a server might be willing to short-change a client if it
could avoid committing its preferences before the client.

I'm not sure that servers will, in reality, have an incentive to do this
to their clients.

But more importantly, I'm not sure that clients should offer QoPs that
they really don't want -- they should risk failure to authenticate and
set up security layers over risking the security of the application
session, if the user really wanted to secure it.

> The holds even if the "client_qops" is a list, as per your proposal.

Of course.

[...]
> Some clients may not care about this, but some might.  With my
> flexibility, then client can then force the server to send its
> "server_qops" bitmask, and then the client can select the qop it needs.

Why wouldn't clients that care just offer only confidentiality
protection?  Or why couldn't they use GS1?  (Let's call the original
SASL/GSS bridge GS1 for now).

> I just think I found the argument for permitting both 1) and 2) in my
> earlier mail.  I don't think 3 should be permitted, though.

I'm not convinced.  I'm not sure what it means to want confidentiality
protection but be willing to do less -- if confidentiality matters to
me, why would I settle for less?

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 21 Nov 2005 01:09:53 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> I'm pretty sure that for SASL "confidentiality" means "confidentiality
> and integrity" -- if not then we should fix that.

I'm not sure that is accurate, but it is not important.  It is true
for GSS-API, that is what matters here.

> As for actual cipher modes, this GS2 bridge, being layered above the
> GSS-API, can't specify such things.  If we ever improve the GSS-API's
> notion of QoP we might do so through named cryptographic profiles, and
> similarly, I'd hope, for SASL -- named profiles are much simpler for
> users to deal with than actual lists of cipher modes and what not, IMO.
>
> Using that approach we'd not have to modify the GS2 client_qops,
> client_qop, server_qops or server_qop types.

Right.  I think we have now concluded that plain/integrity/privacy are
the only three QOPs we ever have to care about in GS2.

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 21 Nov 2005 01:06:15 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Sat, Nov 19, 2005 at 03:35:13PM +0100, Simon Josefsson wrote:
>> With my flexibility, the client can force itself to be in that
>> position (if we permit 1 and 2 but not 3 in my other e-mail).  Then we
>> wouldn't have to think about this problem.  But it would cost one half
>> round-trip...  Hm.
>
> Why would the client not trust the server to honor the client's
> preferences?  Why trust it for anything?

It is not only about trusting it to honor the client's preferences.
The server might optimize for other things, such as performance.

So in the original proposal, if both integrity and privacy layer bits
were set in the bitmask, and thus acceptable to the client, the server
might pick integrity because it cost less CPU.

The holds even if the "client_qops" is a list, as per your proposal.
For example, the list could be to prefer privacy and then integrity.
The server then realize the client would accept integrity, and choose
it to reduce CPU costs.

In both cases, the client never knew the server actually supported
privacy.  If the client knew that, it may not have agreed on integrity
only.

Some clients may not care about this, but some might.  With my
flexibility, then client can then force the server to send its
"server_qops" bitmask, and then the client can select the qop it needs.

I just think I found the argument for permitting both 1) and 2) in my
earlier mail.  I don't think 3 should be permitted, though.

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 21 Nov 2005 00:59:37 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> The alternative, which I would prefer is: the wrap tokens MAY be sent as
> soon as the context is PROT_READY (and no earlier), and MUST be sent no
> later than when the context becomes fully established.
>
> I think this is easier to implement.
>
> Oh, and s/MAY/SHOULD/ :)  -- we want to encourage round-trip
> optimization.

I'm starting to prefer this to.

The only reason for not adopting your approach would be if we could
find an argument to why it would be useful for the client to force
itself (rather than the server) to decide the qop.  I cannot
currently, but I haven't ruled out the existence of that argument.

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 21 Nov 2005 00:56:04 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Sat, Nov 19, 2005 at 03:28:16PM +0100, Simon Josefsson wrote:
>> Thanks for the explanation.  I agree that some of the flexibility was
>> pointless.  Permitting the flexibility to allow these two cases still
>> seem useful:
>> 
>> 1)
>> 
>> ...
>> I: GSS_S_COMPLETE, send context_token and GSS_Wrap token
>> A: GSS_S_COMPLETE, send context_token and GSS_Wrap token
>
> Can't happen.  In this case GSS_Accept_sec_context() can either output
> an error and possibly a context token, or else it can output
> GSS_S_COMPLETE and no context token -- it cannot output GSS_S_COMPLETE
> and a context token because the initiator already is complete.
>
> But that's not your point, I think.

Right.  I meant:

1)

I: GSS_S_COMPLETE, send context_token and GSS_Wrap token
A: GSS_S_COMPLETE, send GSS_Wrap token

2)

I: GSS_S_COMPLETE, send context_token
A: GSS_S_COMPLETE, send GSS_Wrap token
I: Send GSS_Wrap token

3)

I: GSS_S_COMPLETE, send context_token
A: GSS_S_COMPLETE, send 0
I: Send GSS_Wrap token
A: Send GSS_Wrap token

I now believe 3 is pointless.  The property that who gets to decide
the qop can be switched, can be achieved using only 1 and 2.

I don't know if there is any good reason to permit 2.  It seems
useful, but I can't come up with an argument.

> What you want, I think, is to say that the round-trip optimization is
> optional, yes?  I think that's fine, but I have to go think about
> implementation complexity.

Part of this is that I believe the implementation would be simpler if
we permit this.

Non-flexible:

In 1) above, the implementation has to check that one entity didn't
leave out an GSS_Wrap token.  This can only be done after processing
the context token.  If your local implementation returned
GSS_S_COMPLETE, you must expect a GSS_Wrap token.

Flexible:

Simply pass any context tokens to the GSS layer.  If there is a
GSS_Wrap token, parse it as well.  You need to make sure you don't
parse a GSS_Wrap token more than once, and the you only parse it when
the context has been established (or if PROT_READY is set).  But you
don't have to verify that the other entity implemented the protocol
correctly.

> You can state this by saying that the wrap tokens MAY be sent as soon as
> the context is PROT_READY (and no earlier), and MUST be sent no later
> than: a) the context is established, server-side, or b) the client's
> context is established and the client has received the server's wrap
> token.

Exactly.  If we only want to permit 1 and 2 but not 3, it would be
"MUST NOT be sent later than a) or b)".

> I think we can simplify this as I proposed earlier:
>
> 1) When the client sends its proposal first it sends a *list* of
> acceptable QoPs and the server picks one.  
>
> 2) When the server sends its proposal first it sends a *set* of
> acceptable QoPs and the client picks one.

> This gives use semantics similar to the original bridge's: the selected
> QoP will be the client's preference from amongst those the server is
> willing to negotiate.

You have convinced me, I will make the "client_qops" field a list
instead.

> Of course, I think it's fine to have the round-trip optimization be
> optional (as described above).

Ok.  I'm not sure about 3.  It make the complete optimization
optional, but I don't see why the protocol has to permit that.  The
flexibility to allow 2 can be used to switch who get to decide, which
may be useful (although I'm not sure what a good argument for that
would be), but further flexibility seem like permitting to much.

Thanks,
Simon

To: Simon Josefsson <[email-masked]>
Cc: [email-masked], Pekka Savola <[email-masked]>
Subject: Re: sasl-2222bis-13 and lower layer assumptions
From: Sam Hartman <[email-masked]>
Date: Sun, 20 Nov 2005 18:49:47 -0500
Sender: [email-masked]

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

    Simon> Sam Hartman <[email-masked]> writes:
    >>>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:
    >>
    Pekka> None of the SASL security mechanisms protect against such
    Pekka> attackers AFAICS, so to get that security, one must depend
    Pekka> on the existance of sufficient security layers underneath.
    >>  Any mechanism that provides mutual authentication and for
    >> which you actually use at least an integrity security layer
    >> will protect against this.

    Simon> I'm not sure "at least" is correct.  A mechanism can offer
    Simon> privacy without explicit integrity checking.

Not really; see below.

    Simon> This reminds me, wouldn't it be useful to say that "privacy
    Simon> layers SHOULD provide explicit integrity protection"?
    Simon> History suggest that if you don't integrity protect
    Simon> encrypted data, you may be vulnerable to some attacks, at
    Simon> least in some protocols.

More like majorly broken in all protocols.  Steve Bellovin and Matt
Blaze have papers on this for IPsec as I recall.  Tom, Ken and I wrote
a paper on the implications for krb4.

Basically I'd say that confidentiality implies integrity needs to be a
must.

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], Pekka Savola <[email-masked]>
Subject: Re: sasl-2222bis-13 and lower layer assumptions
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 21 Nov 2005 00:41:40 +0100
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:
>
>     Pekka> None of the SASL security mechanisms protect against such
>     Pekka> attackers AFAICS, so to get that security, one must depend
>     Pekka> on the existance of sufficient security layers underneath.
>
> Any mechanism that provides mutual authentication and for which you
> actually use at least an integrity security layer will protect against
> this.

I'm not sure "at least" is correct.  A mechanism can offer privacy
without explicit integrity checking.

This reminds me, wouldn't it be useful to say that "privacy layers
SHOULD provide explicit integrity protection"?  History suggest that
if you don't integrity protect encrypted data, you may be vulnerable
to some attacks, at least in some protocols.

It may be reasonable to consider that the "privacy layer" was intended
to provide integrity as well, only that some mechanisms assume that
encryption is sufficient integrity protection.  That isn't true in the
general case.

Thanks,
Simon

To: Pekka Savola <[email-masked]>
Cc: [email-masked]
Subject: Re: sasl-2222bis-13 and lower layer assumptions
From: Sam Hartman <[email-masked]>
Date: Sun, 20 Nov 2005 14:42:19 -0500
Sender: [email-masked]

>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:

    Pekka> None of the SASL security mechanisms protect against such
    Pekka> attackers AFAICS, so to get that security, one must depend
    Pekka> on the existance of sufficient security layers underneath.

Any mechanism that provides mutual authentication and for which you
actually use at least an integrity security layer will protect against
this.

So, digest, gssapi protect against this if you use an integrity layer.
Cram and plain do not.

--Sam

Date: Sun, 20 Nov 2005 11:38:26 -0800
To: Nicolas Williams <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

At 01:18 AM 11/20/2005, Nicolas Williams wrote:
>On Sat, Nov 19, 2005 at 03:35:46PM -0800, Kurt D. Zeilenga wrote:
>> At 12:45 PM 11/19/2005, Nicolas Williams wrote:
>> >I'm pretty sure that for SASL "confidentiality" means "confidentiality
>> >and integrity" -- if not then we should fix that. 
>> 
>> In SASL, what security services are offered in the mechanism's
>> security layer is quite mechanism specific.  The mechanism
>> could offer a security layer with data confidentiality but
>> without data integrity.
>
>Not so for the GSS-API.  This being the SASL GSS bridge version 2,
>"confidentiality" means "and integrity."

My point is simply that whether data integrity is provided in any
layer that provides data confidentiality is mechanism dependent.
That is, the base specification does not restrict the range of
security services offered by a mechanism.

>Therefore, and for the reasons I gave before, I see no reason to
>negotiate from more than three options: no protection, integrity
>protection, and confidentiality-and-integrity protection.

I concur.

Kurt 

Date: Sun, 20 Nov 2005 03:18:08 -0600
From: Nicolas Williams <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
Mail-Followup-To: "Kurt D. Zeilenga" <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sat, Nov 19, 2005 at 03:35:46PM -0800, Kurt D. Zeilenga wrote:
> At 12:45 PM 11/19/2005, Nicolas Williams wrote:
> >I'm pretty sure that for SASL "confidentiality" means "confidentiality
> >and integrity" -- if not then we should fix that. 
> 
> In SASL, what security services are offered in the mechanism's
> security layer is quite mechanism specific.  The mechanism
> could offer a security layer with data confidentiality but
> without data integrity.

Not so for the GSS-API.  This being the SASL GSS bridge version 2,
"confidentiality" means "and integrity."

Therefore, and for the reasons I gave before, I see no reason to
negotiate from more than three options: no protection, integrity
protection, and confidentiality-and-integrity protection.

Nico
-- 

Date: Sat, 19 Nov 2005 15:35:46 -0800
To: Nicolas Williams <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:45 PM 11/19/2005, Nicolas Williams wrote:
>I'm pretty sure that for SASL "confidentiality" means "confidentiality
>and integrity" -- if not then we should fix that. 

In SASL, what security services are offered in the mechanism's
security layer is quite mechanism specific.  The mechanism
could offer a security layer with data confidentiality but
without data integrity.

Kurt 

Date: Sat, 19 Nov 2005 14:45:13 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sat, Nov 19, 2005 at 03:35:13PM +0100, Simon Josefsson wrote:
> > Assuming we'll never have more than three choices makes designing
> > client_qops easy: three client_qop bytes.  Is this good enough?
> 
> I think so.  Permitting further choices will require a revised
> document anyway, and if that occur it can be solved then.
> 
> One potential future qop could be "privacy combined with
> authentication mode", but this is just speculation.  (It would mean
> AES-CCM or similar.  I know privacy imply integrity, but it doesn't
> imply that the modes has to be combined.  Some people are skeptical
> about the security of non-combined modes.)

I'm pretty sure that for SASL "confidentiality" means "confidentiality
and integrity" -- if not then we should fix that.

As for actual cipher modes, this GS2 bridge, being layered above the
GSS-API, can't specify such things.  If we ever improve the GSS-API's
notion of QoP we might do so through named cryptographic profiles, and
similarly, I'd hope, for SASL -- named profiles are much simpler for
users to deal with than actual lists of cipher modes and what not, IMO.

Using that approach we'd not have to modify the GS2 client_qops,
client_qop, server_qops or server_qop types.

Nico
-- 

Date: Sat, 19 Nov 2005 14:40:50 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sat, Nov 19, 2005 at 01:00:16PM -0600, Nicolas Williams wrote:
> What you want, I think, is to say that the round-trip optimization is
> optional, yes?  I think that's fine, but I have to go think about
> implementation complexity.
> 
> You can state this by saying that the wrap tokens MAY be sent as soon as
> the context is PROT_READY (and no earlier), and MUST be sent no later
> than: a) the context is established, server-side, or b) the client's
> context is established and the client has received the server's wrap
> token.

The alternative, which I would prefer is: the wrap tokens MAY be sent as
soon as the context is PROT_READY (and no earlier), and MUST be sent no
later than when the context becomes fully established.

I think this is easier to implement.

Oh, and s/MAY/SHOULD/ :)  -- we want to encourage round-trip
optimization.

Nico
-- 

Date: Sat, 19 Nov 2005 13:03:48 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sat, Nov 19, 2005 at 03:35:13PM +0100, Simon Josefsson wrote:
> With my flexibility, the client can force itself to be in that
> position (if we permit 1 and 2 but not 3 in my other e-mail).  Then we
> wouldn't have to think about this problem.  But it would cost one half
> round-trip...  Hm.

Why would the client not trust the server to honor the client's
preferences?  Why trust it for anything?

Nico
-- 

Date: Sat, 19 Nov 2005 13:00:16 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sat, Nov 19, 2005 at 03:28:16PM +0100, Simon Josefsson wrote:
> Thanks for the explanation.  I agree that some of the flexibility was
> pointless.  Permitting the flexibility to allow these two cases still
> seem useful:
> 
> 1)
> 
> ...
> I: GSS_S_COMPLETE, send context_token and GSS_Wrap token
> A: GSS_S_COMPLETE, send context_token and GSS_Wrap token

Can't happen.  In this case GSS_Accept_sec_context() can either output
an error and possibly a context token, or else it can output
GSS_S_COMPLETE and no context token -- it cannot output GSS_S_COMPLETE
and a context token because the initiator already is complete.

But that's not your point, I think.

> and
> 
> 2)
> ...
> I: GSS_S_COMPLETE, send context_token
> A: GSS_S_COMPLETE, send context_token and GSS_Wrap token
> I: Send length=0, no context token, and GSS_Wrap token

Same thing.

What you want, I think, is to say that the round-trip optimization is
optional, yes?  I think that's fine, but I have to go think about
implementation complexity.

You can state this by saying that the wrap tokens MAY be sent as soon as
the context is PROT_READY (and no earlier), and MUST be sent no later
than: a) the context is established, server-side, or b) the client's
context is established and the client has received the server's wrap
token.

> The semantic is as follows:
> 
> 1) Both parties want to have the round-trip optimized protocol and
>    doesn't care which end select the qop.
> 
> 2) The client (Initiator) did not want the server to select qop, so it
>    did not include the GSS_Wrap token at the final context exchange.
> 
> 3) The server denied the clients' request to have the client select
>    the qop, so the client is then forced to sends its qop bitmask
>    first, and then the server pick.

I think we can simplify this as I proposed earlier:

1) When the client sends its proposal first it sends a *list* of
acceptable QoPs and the server picks one.  

2) When the server sends its proposal first it sends a *set* of
acceptable QoPs and the client picks one.

This gives use semantics similar to the original bridge's: the selected
QoP will be the client's preference from amongst those the server is
willing to negotiate.

Of course, I think it's fine to have the round-trip optimization be
optional (as described above).

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 19 Nov 2005 15:35:13 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Fri, Nov 18, 2005 at 11:28:41PM +0100, Simon Josefsson wrote:
>> >    If PROT_READY is not output prior to full security context
>> >    establishment then the wrap token MUST be sent when the context is
>> >    fully established.  As a result the length field will be set to zero
>> >    whenever GSS_Init_sec_context() or GSS_Accept_sec_context() return
>> >    GSS_S_COMPLETE, does not output a context token and has not
>> >    previously output the PROT_READY flag..
>> 
>> This would force the wrap token to be sent immediately when
>> init-sec-context or accept-sec-context returned gss-s-complete.
>
> This is OK.  The whole point of GS2 is to have this wrap token sent as
> soon as possible, even if it flips the order of wrap token exchange as
> in the original SASL GSS bridge.

I'm still not convinced the flexibility that permit the example in my
other e-mail should be disallowed.  Let's see if continued discussion
result in any more insights...

>> The concern I have with that is that then the GSS-API mechanism design
>> influence which end will send the qop bitmask and which will pick the
>> resulting qop.  My goal was that this should be flexible.
>
> No, this is what we want, to have the initiator send its wrap token
> first if that will save a round-trip.
>
> The first peer to send the wrap token should send a set of security
> layers it is willing to use, and the other should pick a qop.
>
> The only wrinkle in this is that the client should send a list of
> security layers it is willing to use in order of preference, since in
> the original SASL GSS bridge the client gets to choose the best of the
> server's offerings.

With my flexibility, the client can force itself to be in that
position (if we permit 1 and 2 but not 3 in my other e-mail).  Then we
wouldn't have to think about this problem.  But it would cost one half
round-trip...  Hm.

> So, client_qops should probably be not a one- byte bitmask but something
> else.  What should it be?
>
> Assuming we'll never have more than three choices makes designing
> client_qops easy: three client_qop bytes.  Is this good enough?

I think so.  Permitting further choices will require a revised
document anyway, and if that occur it can be solved then.

One potential future qop could be "privacy combined with
authentication mode", but this is just speculation.  (It would mean
AES-CCM or similar.  I know privacy imply integrity, but it doesn't
imply that the modes has to be combined.  Some people are skeptical
about the security of non-combined modes.)

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 19 Nov 2005 15:28:16 +0100
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Fri, Nov 18, 2005 at 11:28:41PM +0100, Simon Josefsson wrote:
>> For example, the server doesn't know whether init-sec-context returned
>> GSS_S_COMPLETE in the client, so it can't require that the gss_wrap token
>> is present.  ...
>
> No, GSS security context token exchanges are largely synchronized, so
> that you just can't have one peer return GSS_S_CONTINUE_NEEDED when the
> other has already returned GSS_S_COMPLETE.  Once one peer has gotten
> GSS_S_COMPLETE then the other cannot get GSS_S_CONTINUE_NEEDED, it can
> only complete or fail.
>
> The only departure from complete synchronization is the possible
> production of context tokens on error by a peer that had been awaiting
> the last context token from the other, like so:
>
> ...
> I: GSS_S_COMPLETE, token, send token
> A: GSS_S_<error>, token, send token, fail
> I: consume token with gss_process_context_token(), fail
>
> In that case a peer receives a context token it wasn't expecting, but
> the other peer cannot be complete or await another token, no, it must
> have failed.
>
>
> This cannot happen:
>
> ...
> I: GSS_S_COMPLETE, token, send token
> A: GSS_S_CONTINUE_NEEDED, token, send token
>
> Nor this:
>
> ...
> A: GSS_S_COMPLETE, token, send token
> I: GSS_S_CONTINUE_NEEDED, token, send token
>
>
> So, I don't think you need all the flexibility you were making room for.

Thanks for the explanation.  I agree that some of the flexibility was
pointless.  Permitting the flexibility to allow these two cases still
seem useful:

1)

...
I: GSS_S_COMPLETE, send context_token and GSS_Wrap token
A: GSS_S_COMPLETE, send context_token and GSS_Wrap token

and

2)
...
I: GSS_S_COMPLETE, send context_token
A: GSS_S_COMPLETE, send context_token and GSS_Wrap token
I: Send length=0, no context token, and GSS_Wrap token

Also permitting:

3)
...
I: GSS_S_COMPLETE, send context_token
A: GSS_S_COMPLETE, send context_token
I: Send length=0, no context token, and GSS_Wrap token
A: Send length=0, no context token, and GSS_Wrap token

may be useful.

The semantic is as follows:

1) Both parties want to have the round-trip optimized protocol and
   doesn't care which end select the qop.

2) The client (Initiator) did not want the server to select qop, so it
   did not include the GSS_Wrap token at the final context exchange.

3) The server denied the clients' request to have the client select
   the qop, so the client is then forced to sends its qop bitmask
   first, and then the server pick.

Of course, in all cases, the qop bitmask is integrity protected so
there is no downgrade attack.

Further, the qop bitmask reflect PREFERRED qops that would be
acceptable.  The other end CAN pick another qop, if it require that
specific qop, but it should be aware that the authentication may be
rejected.

I see no problem letting the other end select qop.  Each side announce
which qops it support.  The entity that decide know which qops it
can use.

I am worried that this causes interoperability problems.  This
flexibility complicate the description of the protocol.  However, I
believe the implementation is simpler than if we allow this
flexibility.  If we disallow the flexibility, each entity have to keep
track of when the other side should have sent a GSS_Wrap token.  This
complicate the implementation.  With the flexibility, it doesn't have
to care.

Thanks,
Simon

Date: Fri, 18 Nov 2005 17:05:01 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, Nov 18, 2005 at 11:28:41PM +0100, Simon Josefsson wrote:
> >    If PROT_READY is not output prior to full security context
> >    establishment then the wrap token MUST be sent when the context is
> >    fully established.  As a result the length field will be set to zero
> >    whenever GSS_Init_sec_context() or GSS_Accept_sec_context() return
> >    GSS_S_COMPLETE, does not output a context token and has not
> >    previously output the PROT_READY flag..
> 
> This would force the wrap token to be sent immediately when
> init-sec-context or accept-sec-context returned gss-s-complete.

This is OK.  The whole point of GS2 is to have this wrap token sent as
soon as possible, even if it flips the order of wrap token exchange as
in the original SASL GSS bridge.

> The concern I have with that is that then the GSS-API mechanism design
> influence which end will send the qop bitmask and which will pick the
> resulting qop.  My goal was that this should be flexible.

No, this is what we want, to have the initiator send its wrap token
first if that will save a round-trip.

The first peer to send the wrap token should send a set of security
layers it is willing to use, and the other should pick a qop.

The only wrinkle in this is that the client should send a list of
security layers it is willing to use in order of preference, since in
the original SASL GSS bridge the client gets to choose the best of the
server's offerings.

So, client_qops should probably be not a one- byte bitmask but something
else.  What should it be?

Assuming we'll never have more than three choices makes designing
client_qops easy: three client_qop bytes.  Is this good enough?

Nico
-- 

Date: Fri, 18 Nov 2005 16:53:13 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, Nov 18, 2005 at 11:28:41PM +0100, Simon Josefsson wrote:
> For example, the server doesn't know whether init-sec-context returned
> GSS_S_COMPLETE in the client, so it can't require that the gss_wrap token
> is present.  ...

No, GSS security context token exchanges are largely synchronized, so
that you just can't have one peer return GSS_S_CONTINUE_NEEDED when the
other has already returned GSS_S_COMPLETE.  Once one peer has gotten
GSS_S_COMPLETE then the other cannot get GSS_S_CONTINUE_NEEDED, it can
only complete or fail.

The only departure from complete synchronization is the possible
production of context tokens on error by a peer that had been awaiting
the last context token from the other, like so:

...
I: GSS_S_COMPLETE, token, send token
A: GSS_S_<error>, token, send token, fail
I: consume token with gss_process_context_token(), fail

In that case a peer receives a context token it wasn't expecting, but
the other peer cannot be complete or await another token, no, it must
have failed.

This cannot happen:

...
I: GSS_S_COMPLETE, token, send token
A: GSS_S_CONTINUE_NEEDED, token, send token

Nor this:

...
A: GSS_S_COMPLETE, token, send token
I: GSS_S_CONTINUE_NEEDED, token, send token

So, I don't think you need all the flexibility you were making room for.

Nico
-- 

Date: Fri, 18 Nov 2005 23:28:41 +0100 (CET)
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
From: "Simon Josefsson" <[email-masked]>
To: "Nicolas Williams" <[email-masked]>
Cc: [email-masked]
Importance: Normal
Sender: [email-masked]

>    "
>                                   In this case, the length field will
>    encode the integer 0, indicating that the context token is absent.
>    If the context has not been established at that point, the
>    authentication MUST fail.
>    "
>
>    This is not right though -- one or the other of
>    GSS_Init/Accept_sec_context() will output a security context token
>    and GSS_S_COMPLETE.

Actually, I intended to leave some flexibility in the protocol.  Wheter
the GSS_Wrap token is sent together with the last context tokens was
something I intended could be flexible.  That text was probably
underspecified though, since that message apparently didn't made it
through.

What I was after was to permit all these SASL negotiation finishes, for
the same GSS-API mechanism:  (in all cases, the init-sec-context and
accept-sec-context functions return gss-s-complete)

...
C: init-sec-context-token, gss_wrap
S: accept-sec-context-token, gss_wrap

or

...
C: init-sec-context-token
S: accept-sec-context-token, gss_wrap
C: gss_wrap

or

...
C: init-sec-context-token
S: accept-sec-context-token
C: gss_wrap
S: gss_wrap

or

...
C: init-sec-context-token
S: accept-sec-context-token
C: 0
S: gss_wrap
C: gss_wrap

Again, I'm not sure we should permit this.  Perhaps only the first two
should be permitted.  Perhaps only the first.

The problem in forbidding this flexibility is that the other end cannot
tell that the invalid situation has occured until later.  And then it
might as well accept the situation, because there is no ambuiguity.

For example, the server doesn't know whether init-sec-context returned
GSS_S_COMPLETE in the client, so it can't require that the gss_wrap token
is present.  Or?  It will now that the client has finished, when the next
packet is receive.  If the packet contain another context token, the
client didn't finish, but if the context token is zero length, the client
should presumably have sent the gss_wrap token in the last message, but
didn't.  I don't see any harm in accepting that case, and simply parse the
gss_wrap token if accept-sec-context has finished locally.  It will be
less efficient, but it will also permit the client of asking the server to
send its qops first, if it wants.  The optimized protocol is permitted
too.

>    If PROT_READY is not output prior to full security context
>    establishment then the wrap token MUST be sent when the context is
>    fully established.  As a result the length field will be set to zero
>    whenever GSS_Init_sec_context() or GSS_Accept_sec_context() return
>    GSS_S_COMPLETE, does not output a context token and has not
>    previously output the PROT_READY flag..

This would force the wrap token to be sent immediately when
init-sec-context or accept-sec-context returned gss-s-complete.

The concern I have with that is that then the GSS-API mechanism design
influence which end will send the qop bitmask and which will pick the
resulting qop.  My goal was that this should be flexible.

Given my explanation, do you have any additional thoughts?

>    "
>    The client MUST verify that GSS_Init_context return GSS_S_COMPLETE
>    rather than trust the server's signaling of whether the
>    authentication was successful or not.  If the server report
>    successful authentication and GSS_Init_sec_context did not return
>    GSS_S_COMPLETE on the last token, the authentication MUST be aborted
>    by the client.
>    "
>
>    It might be easier to list the conditions under which authentication
>    fails:
>
>     - GSS_Init/Accept_sec_context() return anything other than
>       GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE
>
>     or
>
>     - GSS_Wrap() returns anything other than GSS_S_COMPLETE
>
>     or
>
>     - GSS_Unwrap() returns anything other than GSS_S_COMPLETE (there
>       can't be supplementary status codes in GS2 at this point, so any
>       indications of out of order processing or replays should be fatal)
>
>     or
>
>     - policy (e.g., client and server can't agree on qop proposal)
>
>     or
>
>     - (server-side) authorization of client principal to requested
>       authz-id failed

I like this.  I'll incorporate it.

Thanks,
Simon

Date: Fri, 18 Nov 2005 14:53:57 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Nov 17, 2005 at 05:36:21PM -0600, Nicolas Williams wrote:
> On Fri, Nov 18, 2005 at 12:12:25AM +0100, Simon Josefsson wrote:
> > Is this document in line with what the discussion about that
> > mechanism?
> 
> I think so.  I'll post some minor editorial comments separately.

Comments:

 - Comments on text about PROT_READY

   "
   If PROT_READY is never set by GSS_Init_sec_context or
   GSS_Accept_sec_context, the GSS_Wrap messages can be sent after the
   context has been established.
   "

   This text is good -- PROT_READY is implied when GSS_S_COMPLETE;
   GSS-API v2u1 implementations must output it, but GSS-API v1
   implementations don't know what PROT_READY is.  But see below.

   "
                                  In this case, the length field will
   encode the integer 0, indicating that the context token is absent.
   If the context has not been established at that point, the
   authentication MUST fail.
   "

   This is not right though -- one or the other of
   GSS_Init/Accept_sec_context() will output a security context token
   and GSS_S_COMPLETE.

   How about:

   If PROT_READY is not output prior to full security context
   establishment then the wrap token MUST be sent when the context is
   fully established.  As a result the length field will be set to zero
   whenever GSS_Init_sec_context() or GSS_Accept_sec_context() return
   GSS_S_COMPLETE, does not output a context token and has not
   previously output the PROT_READY flag..

   The protocol examples will have to be updated.  E.g., change this:

         C: Request authentication exchange
         ...
         S: GSS_Accept_sec_context return GSS_S_COMPLETE,
            send [length, GSS_Accept_sec_context] token
         C: GSS_Init_sec_context return GSS_S_COMPLETE,
            send [length, GSS_Init_sec_context] token
         S: Send [length=0, GSS_Wrap(server_qops, server_maxbuf)] token
         C: Send [length=0,
                  GSS_Wrap(client_qop, client_maxbuf, authzid)] token
         S: Outcome of authentication exchange

   to this:

         C: Request authentication exchange
         ...
	 S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and outputs
	    a token, send [length, context token,
	                   GSS_Wrap(server_qops, server_maxbuf)]
         C: GSS_Init_sec_context() returns GSS_S_COMPLETE and does not
	    output a token, send [length=0, context token,
				  GSS_Wrap(client_qop, client_maxbuf,
				  authzid)]
         S: Outcome of authentication exchange

   And similarly for when GSS_Init_sec_context() returns GSS_S_COMPLETE
   first:

         C: Request authentication exchange
         ...
	 C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a
	    token, send [length, context token,
	                 GSS_Wrap(client_qops, client_maxbuf, authzid)]
	 S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not
	    output a token, send [length, context token,
	                          GSS_Wrap(server_qop, server_maxbuf)]
         S: Outcome of authentication exchange

 - Other comments:

   "
   The client MUST verify that GSS_Init_context return GSS_S_COMPLETE
   rather than trust the server's signaling of whether the
   authentication was successful or not.  If the server report
   successful authentication and GSS_Init_sec_context did not return
   GSS_S_COMPLETE on the last token, the authentication MUST be aborted
   by the client.
   "

   It might be easier to list the conditions under which authentication
   fails:
   
    - GSS_Init/Accept_sec_context() return anything other than
      GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE

    or

    - GSS_Wrap() returns anything other than GSS_S_COMPLETE

    or

    - GSS_Unwrap() returns anything other than GSS_S_COMPLETE (there
      can't be supplementary status codes in GS2 at this point, so any
      indications of out of order processing or replays should be fatal)

    or

    - policy (e.g., client and server can't agree on qop proposal)

    or

    - (server-side) authorization of client principal to requested
      authz-id failed

Date: Fri, 18 Nov 2005 09:54:02 -0800
To: Pekka Savola <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: sasl-2222bis-13 and lower layer assumptions
Cc: [email-masked]
Sender: [email-masked]

At 09:16 AM 11/18/2005, Pekka Savola wrote:
>On Fri, 18 Nov 2005, Kurt D. Zeilenga wrote:
>>> Obviously, running SASL on top of plaintext is very different from
>>> running SASL on top of TLS, for example.
>>Depends on how one uses TLS.  Note the text avoids simply saying
>>"use TLS" by referring to particular useful security service
>>that TLS might provide.
>
>Certainly, I was making a simplification.
>
>>> This is relevant due to man-in-the-middle attackers who were on the path
>>> before the SASL-protected session was established.
>>Section 6.1.2 discuss how one can protect against such attacks.
>
>It describes how you can use these attacks to downgrade the level of SASL protection.  It does not describe the case where by the virtue of a MITM attack you are establishing a SASL session (with integrity protection and all the frills) to *the wrong endpoint*, i.e., someone who isn't quite the one you think it is, and who may also be masquarading as you towards the server with high integrity and all the nice SASL security layers you can think of.

When the document uses the term 'data integrity', it uses
under the assumption that there is bound to appropriate
authentication of the data origins, an assumption which is
common place in IETF documents.  This is especially
true when referring to services provided by the SASL mechanism.
And even when we say to use of external data integrity protective
services, there is the assumption that those services
include adequate data origin authentication.  It is also
assumed that those using external security services are
familiar with the security considerations of the particular
service they are using.  For instance, aware that common
use of TLS does not involve mutual authentication and the
implications of this its data integrity protections.

I could see adding some text regarding the relationship
between data origin authentication and integrity protection
(possibly in a "Masquerade Attacks" subsection of 6.1).
This section could also note that reliance on external
data security services may not adequately protection
against such attacks.  For instance, external data
security service may not provide mutual endpoint
authentication (e.g., TLS as commonly used with SASL
mechanisms other than EXTERNAL)... and even where
the external data service does provide mutual data
origin authentication, there may be channel binding issues.

That said, I having trouble coming up with appropriate
words for the document and hence renew my request for
specific suggestions (e.g., text).  In absence of a
specific suggestion (or WG support for any offered
specific suggestion), I believe the document should be
progressed "as is".

Kurt 

Date: Fri, 18 Nov 2005 19:16:17 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: [email-masked]
Subject: Re: sasl-2222bis-13 and lower layer assumptions
Sender: [email-masked]

On Fri, 18 Nov 2005, Kurt D. Zeilenga wrote:
> > Obviously, running SASL on top of plaintext is very different from
> > running SASL on top of TLS, for example.
> 
> Depends on how one uses TLS.  Note the text avoids simply saying
> "use TLS" by referring to particular useful security service
> that TLS might provide.

Certainly, I was making a simplification.

> > This is relevant due to man-in-the-middle attackers who were on the path
> > before the SASL-protected session was established.
> 
> Section 6.1.2 discuss how one can protect against such attacks.

It describes how you can use these attacks to downgrade the level of 
SASL protection.  It does not describe the case where by the virtue of 
a MITM attack you are establishing a SASL session (with integrity 
protection and all the frills) to *the wrong endpoint*, i.e., someone 
who isn't quite the one you think it is, and who may also be 
masquarading as you towards the server with high integrity and all the 
nice SASL security layers you can think of.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Date: Fri, 18 Nov 2005 09:14:14 -0800
From: Chris Newman <[email-masked]>
Subject: Re: sasl-2222bis-13 and lower layer assumptions
To: Pekka Savola <[email-masked]>, [email-masked]
Sender: [email-masked]

Given how late we are in the standards cycle on this document, I would prefer 
to minimize changes and get the RFC out sooner.  The security consideration you 
raise can be deferred to the mechanism specifications (and I believe it's 
discussed at length in the PLAIN mechanism spec).

If you want the WG to do otherwise, you need to suggest specific text.

                - Chris

Pekka Savola wrote on 11/18/05 15:17 +0200:

>
> Hi,
>
> I took a quick look at the security considerations of 2222bis-13.
>
> Unfortunately, it still does not contain what I have been looking for.
> Specifically, IMHO the document should describe the difference in security
> from user's (or app writer's) point-of-view depending on which security
> mechanisms you use below SASL.
>
> Obviously, running SASL on top of plaintext is very different from running
> SASL on top of TLS, for example.
>
> This is relevant due to man-in-the-middle attackers who were on the path
> before the SASL-protected session was established.
>
> None of the SASL security mechanisms protect against such attackers AFAICS,
> so to get that security, one must depend on the existance of sufficient
> security layers underneath.
>
> So, at the minimum I'd suggest adding a short paragraph or subsection at the
> start of section 6.1 on lower-layer security implications.
>
> HTH
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>

Date: Fri, 18 Nov 2005 09:13:14 -0800
To: Pekka Savola <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: sasl-2222bis-13 and lower layer assumptions
Cc: [email-masked]
Sender: [email-masked]

At 05:17 AM 11/18/2005, you wrote:
>I took a quick look at the security considerations of 2222bis-13.
>
>Unfortunately, it still does not contain what I have been looking for. Specifically, IMHO the document should describe the difference in security from user's (or app writer's) point-of-view depending on which security mechanisms you use below SASL.
>
>Obviously, running SASL on top of plaintext is very different from running SASL on top of TLS, for example.

Depends on how one uses TLS.  Note the text avoids simply saying
"use TLS" by referring to particular useful security service
that TLS might provide.

>This is relevant due to man-in-the-middle attackers who were on the path before the SASL-protected session was established.

Section 6.1.2 discuss how one can protect against such attacks.

>None of the SASL security mechanisms protect against such attackers AFAICS,
> so to get that security, one must depend on the existance of sufficient security layers underneath.

No, the considerations in 6.1.2 are sufficient.

>So, at the minimum I'd suggest adding a short paragraph or subsection at the start of section 6.1 on lower-layer security implications.

I suggest you (or someone) offer specific text for the WG to
consider.

Kurt

Date: Fri, 18 Nov 2005 15:17:40 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: sasl-2222bis-13 and lower layer assumptions
Sender: [email-masked]

Hi,

I took a quick look at the security considerations of 2222bis-13.

Unfortunately, it still does not contain what I have been looking for. 
Specifically, IMHO the document should describe the difference in 
security from user's (or app writer's) point-of-view depending on 
which security mechanisms you use below SASL.

Obviously, running SASL on top of plaintext is very different from 
running SASL on top of TLS, for example.

This is relevant due to man-in-the-middle attackers who were on the 
path before the SASL-protected session was established.

None of the SASL security mechanisms protect against such attackers 
AFAICS, so to get that security, one must depend on the existance of 
sufficient security layers underneath.

So, at the minimum I'd suggest adding a short paragraph or subsection 
at the start of section 6.1 on lower-layer security implications.

HTH

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Date: Thu, 17 Nov 2005 17:36:21 -0600
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, Nov 18, 2005 at 12:12:25AM +0100, Simon Josefsson wrote:
> Hi all.  This is an initial version of the GS2 work that I was
> supposed to help with, if I understood the Vancouver meeting
> correctly.
> 
> Is this document in line with what the discussion about that
> mechanism?

I think so.  I'll post some minor editorial comments separately.

> Note that I picked the PROT_READY approach rather than the channel
> binding approach.  The channel binding approach require additional
> descriptions on how to combine any application channel bindings and
> the GS2 mechanism's channel bindings.  Describing both seem complex,
> but may be required.

I'm fine with this choice.

> Is the WG interested in adopting this work?

I support making this a WG item.

Thank you,

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-josefsson-sasl-gs2-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 18 Nov 2005 00:12:25 +0100
Sender: [email-masked]

Hi all.  This is an initial version of the GS2 work that I was
supposed to help with, if I understood the Vancouver meeting
correctly.

Is this document in line with what the discussion about that
mechanism?

Note that I picked the PROT_READY approach rather than the channel
binding approach.  The channel binding approach require additional
descriptions on how to combine any application channel bindings and
the GS2 mechanism's channel bindings.  Describing both seem complex,
but may be required.

Is the WG interested in adopting this work?

Naturally, I'd appreciate all comments and suggestions.

Thanks,
Simon

[email-masked] writes:

> 	Title		: Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
> 	Author(s)	: S. Josefsson
> 	Filename	: draft-josefsson-sasl-gs2-00.txt
> 	Pages		: 19
> 	Date		: 2005-11-17
> 	
>    This document describes how to use a Generic Security Service
>    Application Program Interface mechanism in the the Simple
>    Authentication and Security Layer framework.
>
>    See <http://josefsson.org/sasl-gs2-*/> for more information.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-sasl-gs2-00.txt

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: rfc2222bis-13: challenges, responses and other messages
Date: Wed, 16 Nov 2005 23:50:55 +0100
Sender: [email-masked]

I'm having a look at rfc2222bis again:

The definitions and uses of challenges, responses, etc seem unclear or
inconsistent.

I always thought "Initial response" referred to the optional response
sent with the authentication command, and the wordings in sections 3 and
4 seem to me to say that.  rfc2222bis-10 explicitly uses the term that
way.

However, the example in section 3 uses it to mean just the first message
with client data.  I guess the text can be read to allow that meaning
too, but at least to me it's not the most natural way to read it.  Most
other text now seems to use that meaning.  I don't quite see the point
of giving that response any particular name though.

(One other meaning which it could make sense to give a name is the first
client data when the client sends data first - either with the auth
command or when prompted by an empty challenge.  That doesn't seem to be
the meaning used in this draft though.)

Since several mechanisms in RFC 2222 define the initial response, does
that mean text now says these support protocols whose authentication
commands do not include an initial response?

E.g. RFC 2222 required EXTERNAL to have an initial response, while
rfc2222bis until recently explicitly added support for no initial
response, and now that support is gone again.

"Initial challenge" just seems to be a descriptive phrase now, not a
defined term.  I think it meant the challenge when the server sends data
first, but if it means that or not doesn't seem to matter in rfc2222bis.

> 3.3 Request Authentication Exchange

>  Where the mechanism is defined to allow the client to send data first,
>  and the protocol's request message includes an optional initial
>  response field, the client may include the response to the initial
>  challenge in the authentication request message.

The last two lines have gotten scrambled.  That initial response is not
a response to any challenge.

BTW, I wonder if s/includes/supports/ here and elsewhere would be
clearer, to better distinguish from when the server/client includes the
optional field in some message it sends.

> 3.4. Challenges and Responses
>
>  The authentication exchange involves one or more pairs of
>  server-challenges and client-responses, the particulars of which are
>  mechanism specific.

I don't remember if this has been discussed before, but:

This seems to say one or more pairs of (challenge, the response to that
challenge) are exchanged.

But if the client sends data first and the server responds with the
final outcome, there are two messages but no such "pair".

I suppose this could be stated as "conceptual" pairs in that this should
be considered equivalent to the exchange where both auth command and
outcome had no data.  (However I'm not sure if a mechanism may be
specified so that the the client may send data with the auth command,
but if it does not the server may send a non-empty challenge.  If so
that "conceptual" exchange would have another semantics to the one using
the initial response in the auth command.)

Anyway if that's OK that might fix another problem too: I understand
correctly an the auth command with no initial response is not a
"response", and an outcome with no data is not a "challenge".  So there
is no challenge involved if the client sends an auth command and the
server responds with the outcome message and no data - e.g. EXTERNAL
when the auth command included the initial response.

OTOH, if the client sends no data, there is no response involved either.
(E.g. an ANONYMOUS-like mechanism with no trace info field.)  So that
will still not be supported.

-- 
Hallvard

Date: Wed, 16 Nov 2005 12:35:03 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: IANA Considerations
Cc: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

How about something like?

  The review should focus on whether or not the requested family
  name is appropriate for the proposed use and the proposed
  naming and registration plan for existing and future mechanisms
  in the family, etc..  The scope of this request review may
  entail consideration of relevant aspects of any provided
  technical specification, such as their IANA Considerations
  section.  However this review is narrowly focused on
  the appropriateness of the requested registration and not on
  the overall soundness of any provided technical
  specification.  Authors are encouraged to community review
  by posting the technical specification as an Internet-Draft
  and soliciting comment by posting to appropriate IETF
  mailing lists.

Kurt

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: IANA Considerations
From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2005 15:42:02 -0500
Sender: [email-masked]

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    Kurt> How about something like?  The review should focus on
    Kurt> whether or not the requested family name is appropriate for
    Kurt> the proposed use and the proposed naming and registration
    Kurt> plan for existing and future mechanisms in the family, etc..

This is not a complete sentence and I think it is missing its core.

However if you did complete the sentence I think I'd agree that your
guidelines were sufficient.

As an individual I still prefer IETf consensus for family
registrations.

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: rfc2222bis-13: challenges, responses and other messages
Date: Wed, 16 Nov 2005 23:50:55 +0100
Sender: [email-masked]

I'm having a look at rfc2222bis again:

The definitions and uses of challenges, responses, etc seem unclear or
inconsistent.

I always thought "Initial response" referred to the optional response
sent with the authentication command, and the wordings in sections 3 and
4 seem to me to say that.  rfc2222bis-10 explicitly uses the term that
way.

However, the example in section 3 uses it to mean just the first message
with client data.  I guess the text can be read to allow that meaning
too, but at least to me it's not the most natural way to read it.  Most
other text now seems to use that meaning.  I don't quite see the point
of giving that response any particular name though.

(One other meaning which it could make sense to give a name is the first
client data when the client sends data first - either with the auth
command or when prompted by an empty challenge.  That doesn't seem to be
the meaning used in this draft though.)

Since several mechanisms in RFC 2222 define the initial response, does
that mean text now says these support protocols whose authentication
commands do not include an initial response?

E.g. RFC 2222 required EXTERNAL to have an initial response, while
rfc2222bis until recently explicitly added support for no initial
response, and now that support is gone again.

"Initial challenge" just seems to be a descriptive phrase now, not a
defined term.  I think it meant the challenge when the server sends data
first, but if it means that or not doesn't seem to matter in rfc2222bis.

> 3.3 Request Authentication Exchange

>  Where the mechanism is defined to allow the client to send data first,
>  and the protocol's request message includes an optional initial
>  response field, the client may include the response to the initial
>  challenge in the authentication request message.

The last two lines have gotten scrambled.  That initial response is not
a response to any challenge.

BTW, I wonder if s/includes/supports/ here and elsewhere would be
clearer, to better distinguish from when the server/client includes the
optional field in some message it sends.

> 3.4. Challenges and Responses
>
>  The authentication exchange involves one or more pairs of
>  server-challenges and client-responses, the particulars of which are
>  mechanism specific.

I don't remember if this has been discussed before, but:

This seems to say one or more pairs of (challenge, the response to that
challenge) are exchanged.

But if the client sends data first and the server responds with the
final outcome, there are two messages but no such "pair".

I suppose this could be stated as "conceptual" pairs in that this should
be considered equivalent to the exchange where both auth command and
outcome had no data.  (However I'm not sure if a mechanism may be
specified so that the the client may send data with the auth command,
but if it does not the server may send a non-empty challenge.  If so
that "conceptual" exchange would have another semantics to the one using
the initial response in the auth command.)

Anyway if that's OK that might fix another problem too: I understand
correctly an the auth command with no initial response is not a
"response", and an outcome with no data is not a "challenge".  So there
is no challenge involved if the client sends an auth command and the
server responds with the outcome message and no data - e.g. EXTERNAL
when the auth command included the initial response.

OTOH, if the client sends no data, there is no response involved either.
(E.g. an ANONYMOUS-like mechanism with no trace info field.)  So that
will still not be supported.

-- 
Hallvard

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: IANA Considerations
From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2005 15:42:02 -0500
Sender: [email-masked]

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    Kurt> How about something like?  The review should focus on
    Kurt> whether or not the requested family name is appropriate for
    Kurt> the proposed use and the proposed naming and registration
    Kurt> plan for existing and future mechanisms in the family, etc..

This is not a complete sentence and I think it is missing its core.

However if you did complete the sentence I think I'd agree that your
guidelines were sufficient.

As an individual I still prefer IETf consensus for family
registrations.

Date: Wed, 16 Nov 2005 12:35:03 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: IANA Considerations
Cc: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

How about something like?

  The review should focus on whether or not the requested family
  name is appropriate for the proposed use and the proposed
  naming and registration plan for existing and future mechanisms
  in the family, etc..  The scope of this request review may
  entail consideration of relevant aspects of any provided
  technical specification, such as their IANA Considerations
  section.  However this review is narrowly focused on
  the appropriateness of the requested registration and not on
  the overall soundness of any provided technical
  specification.  Authors are encouraged to community review
  by posting the technical specification as an Internet-Draft
  and soliciting comment by posting to appropriate IETF
  mailing lists.

Kurt

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: IANA Considerations
From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2005 14:22:02 -0500
Sender: [email-masked]

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    Kurt> I really don't see any particular needs for more guidance.

The IESG recently had to review a complex case based on the IESG
review guideline with no additional criteria given.

It was very unclear what to do.

I see no reason why expert review would be easier.

If you want the expert to use their best technical judgment about the
proposal--considering factors such as technical quality of the
proposal, quality of the specification, impact of the proposal, etc,
then that's OK but please state explicitly that you want broad
technical judgment of the expert.  Even then I'd recommend grabbing one of the IESg review criteria paragraphs and adapting it.  Something like:

     Reviews should focus on these questions: "Is this assignment and
          itssupporting material a reasonable basis on which to build
          the salient part of the Internet infrastructure? If not,
          what changes would make it so?"

If you don't want criteria that broad then you really need to have
clear guidelines.

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: IANA Considerations
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 16 Nov 2005 14:20:38 +0100
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>     Simon> Thanks for using the first-come-first-serve approach also
>     Simon> for SASL families.
>
>     Simon> While looking into "GSS-*", I noticed a potential namespace
>     Simon> problem.  We already have "GSS-SPNEGO".  So the "GSS-*"
>     Simon> family will use "GS2-*".
>
>     Simon> However, that illustrate a situation that the IANA should
>     Simon> not be permitted to create.  If IANA receive a request to
>     Simon> register "FOO-*", it must reject it if there is an earlier
>     Simon> registration that begin with "FOO-".  Right?
>
> It's reasons like this why I would rather family registrations require
> ietf consensus.  We can decide how to handle existing registrations,
> decide whether IANA will keep a list of common members of the family,
> give guidelines for the family, give change control guidance for the
> family itself.  All these things are easier to do with ietf consensus.
>
> For experimental registrations you could register members of the
> family and then if the experiment is successful register the family as
> a whole.

That sounds like a good solution.  Forcing people who describe EAP-*
to register EAP-MSCHAP and EAP-TLS-EAP etc is not much of a burden, it
is still first-come-first-serve.  I never cared much for the mechanism
family concept.

If we do things this way, it is important that family mechanism names
are permitted to cover already registered names.  If any problems are
caused by that (e.g., if someone registered EAP-GAZONK which does not
work the same way as other EAP-* mechanism, but only happen to use the
same prefix), those problems should be discussed in the specification
registering the family.  The EAP-* spec could then simply say that
EAP-GAZONK is a different mechanism not covered by that spec.

Thanks,
Simon

Date: Tue, 15 Nov 2005 23:30:58 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: IANA Considerations
Cc: Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

I really don't see any particular needs for more guidance.

At 09:43 PM 11/15/2005, Sam Hartman wrote:
>Is the expert allowed to consider the technical merits of a proposal?

Given that specification is not required, if one is provided,
the expert should likely not have to give the technical
specification much consideration.  However, he may.  Certainly
there are cases where the appropriateness of the request
may depend on aspects of the specification.

Note that BCP 26 says:
   The designated expert can initiate and coordinate as
   wide a review of an assignment request as may be
   necessary to evaluate it properly.

>Is the expert allowed to consider whether a prefix is too short?

If the shortness of the name is not appropriate for the request
(in the determination of the expert after obtaining community
input), the expert can certainly disapprove it.

>Is the expert allowed to simply judge consensus? 

As RFC 2434 describes Expert Review, there is no consensus
requirement under this registration policy.

> It's reasons like this why I would rather family registrations require
ietf consensus

Note that "IETF Consensus", as defined by BCP 26, requires
publication of an RFC approved by the IESG.  I find that
a little too heavy.

IESG Approval would be a bit lighter as it wouldn't
require an RFC approval.

I rather not define a SASL specific registration policy.

Kurt 

To: Simon Josefsson <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: IANA Considerations
From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2005 00:43:03 -0500
Sender: [email-masked]

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

    Simon> "Kurt D. Zeilenga" <[email-masked]> writes:

    >> I do not see any need to specify any more guidelines to the
    >> Expert than "Requests for family name will be forwarded to the
    >> <[email-masked]> mailing list.  After a 2-week comment
    >> period, the Expert will make a determination of the
    >> appropriateness of the request and either approve or disapprove
    >> the request with notification to the requestor, IANA, and this
    >> list.  The approval/disapproval action may be appealed."

    Simon> That is a good expert reviewer guideline, so I think we
    Simon> could live with a expert review situation for mechanism
    Simon> families.  Could we make the decision process a little more
    Simon> accountable?  For example:

I consider that guideline unacceptable.  For example it does not
indicate whether the expert is judging consensus or what factors
should be considered.

Is the expert allowed to consider the technical merits of a proposal?
Is the expert allowed to consider whether a prefix is too short?  Is
the expert allowed to simply judge consensus?

To: Simon Josefsson <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked], "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: IANA Considerations
From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2005 00:39:43 -0500
Sender: [email-masked]

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

    Simon> If we go with a expert reviewer, I believe there should be
    Simon> guidelines for that expert reviewer in the document.  

The document will be returned to the WG after AD review if it contains
a requirement for expert review without guidelines.

so, yes, with my AD hat on I agree with Simon.

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: IANA Considerations
From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2005 00:38:09 -0500
Sender: [email-masked]

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

    Simon> Thanks for using the first-come-first-serve approach also
    Simon> for SASL families.

    Simon> While looking into "GSS-*", I noticed a potential namespace
    Simon> problem.  We already have "GSS-SPNEGO".  So the "GSS-*"
    Simon> family will use "GS2-*".

    Simon> However, that illustrate a situation that the IANA should
    Simon> not be permitted to create.  If IANA receive a request to
    Simon> register "FOO-*", it must reject it if there is an earlier
    Simon> registration that begin with "FOO-".  Right?

It's reasons like this why I would rather family registrations require
ietf consensus.  We can decide how to handle existing registrations,
decide whether IANA will keep a list of common members of the family,
give guidelines for the family, give change control guidance for the
family itself.  All these things are easier to do with ietf consensus.

For experimental registrations you could register members of the
family and then if the experiment is successful register the family as
a whole.

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: IANA Considerations
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 15 Nov 2005 18:40:24 +0100
Sender: [email-masked]

We are taking up too much time on this issue.  I believe an expert
reviewer who isn't obligated to base his decision on community
consensus is sub-optimal.  However, I don't care strongly enough about
this, so consider my suggested rewording withdrawn.

Regards,
Simon

Date: Tue, 15 Nov 2005 12:36:53 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: IANA Considerations
Cc: Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

At 09:40 AM 11/15/2005, Simon Josefsson wrote:
>We are taking up too much time on this issue.  I believe an expert
>reviewer who isn't obligated to base his decision on community
>consensus is sub-optimal.  However, I don't care strongly enough about
>this, so consider my suggested rewording withdrawn.

Okay.  To move things forward (and into WGLC), I am going
to submit a revised I-D with expert review for family requests
and then recommend Tom issue a WGLC.

Kurt 

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: IANA Considerations
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 15 Nov 2005 18:40:24 +0100
Sender: [email-masked]

We are taking up too much time on this issue.  I believe an expert
reviewer who isn't obligated to base his decision on community
consensus is sub-optimal.  However, I don't care strongly enough about
this, so consider my suggested rewording withdrawn.

Regards,
Simon

Date: Tue, 15 Nov 2005 09:20:54 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: IANA Considerations
Cc: Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

At 08:40 AM 11/15/2005, Simon Josefsson wrote:
>"Kurt D. Zeilenga" <[email-masked]> writes:
>
>> I do not see any need to specify any more guidelines to
>> the Expert than "Requests for family name will be forwarded
>> to the <[email-masked]> mailing list.  After a 2-week
>> comment period, the Expert will make a determination of
>> the appropriateness of the request and either approve or
>> disapprove the request with notification to the requestor,
>> IANA, and this list.  The approval/disapproval action may
>> be appealed."
>
>That is a good expert reviewer guideline, so I think we could live
>with a expert review situation for mechanism families.  Could we make
>the decision process a little more accountable?  For example:

Accountable to whom?

The expert reviewer is accountable to the IESG and hence
the community as a whole.

> Requests for a family name will be forwarded to the
> <[email-masked]> mailing list asking for support or objections.
> It is assumed that the mailing list will continue to be open to
> anyone.  After a 2-week comment period, the Expert will make a
> determination of the appropriateness of the request, and either
> approve or disapprove the request with notification to the requestor,
> IANA, and the list.  The expert's decision should be based on the
> list discussion,

I rather not say "based on list discussion".  The expert
should consider community input in making his decision.

>but the expert may suggest a default action in order
> to avoid needless discussion.

I doubt that suggesting a default action will avoid
needless discussion.   Personally, I think having the
Expert state his views up front would likely stifle
comment. 

>If no consensus can be established,

Consensus of the list should not be required.  Community
input should be allowed and encouraged, but the Expert
decision should be his/her own as a subject matter expert.

Note here the subject matter here is not "SASL" but
"SASL family mechanism registrations" or even more
generally "IANA-managed IETF protocol value registries".
That is, the determination is less about whether the
specification of the family (and the mechanisms in that
family) are technically sound (which should be obvious
given the specification is not required), but whether the
registration of the family would cause some harm.

For instance, one could well design a mechanism
family but choose a really bad name, like "STRONG" or
"MUST".  Or one could poorly design a mechanism
family but choose a good name, "XYZ-FOO-BAR-".
The former should be disapproved, the latter should
be approved.

Unforunately, most of the list will focus on issues
of the family and its specification, and not on issues
of the name and its delegation.

> the registration should be delayed until consensus can be
> established.  The approval/disapproval action may be appealed.

I see no reason why any request could not be approved or
disapproved within 2 weeks.

Kurt 

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: IANA Considerations
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 15 Nov 2005 17:40:34 +0100
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:

> I do not see any need to specify any more guidelines to
> the Expert than "Requests for family name will be forwarded
> to the <[email-masked]> mailing list.  After a 2-week
> comment period, the Expert will make a determination of
> the appropriateness of the request and either approve or
> disapprove the request with notification to the requestor,
> IANA, and this list.  The approval/disapproval action may
> be appealed."

That is a good expert reviewer guideline, so I think we could live
with a expert review situation for mechanism families.  Could we make
the decision process a little more accountable?  For example:

 Requests for a family name will be forwarded to the
 <[email-masked]> mailing list asking for support or objections.
 It is assumed that the mailing list will continue to be open to
 anyone.  After a 2-week comment period, the Expert will make a
 determination of the appropriateness of the request, and either
 approve or disapprove the request with notification to the requestor,
 IANA, and the list.  The expert's decision should be based on the
 list discussion, but the expert may suggest a default action in order
 to avoid needless discussion.  If no consensus can be established,
 the registration should be delayed until consensus can be
 established.  The approval/disapproval action may be appealed.

Thanks,
Simon

Date: Tue, 15 Nov 2005 07:53:40 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: IANA Considerations
Cc: Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

At 01:36 AM 11/15/2005, Simon Josefsson wrote:
>However, I don't see how any IANA registration could be harmful.

I think this is the real difference in opinion.

What if I registered the families:
        "A", "B", "C", ... "Z" as well as "0" ... "9".

just to me make me the registration czar.  This registration is
with is not bogus as it with purpose, hence IANA should be expected
to accept my registration. 

>The IANA registry isn't normative, it is merely there for informational
>purposes.

The IANA registry is intended to be definitive.  If there
specifications for two different mechanisms both called "FOO",
the IANA registry is definitive as which specification is
the real "FOO".

>Restricting people to give information about SASL
>mechanisms they use or specify appear counter-productive to me.

Note that we're talking about mechanism families, not individual
mechanisms.

>We do want people to make us aware of their SASL mechanisms names, to
>avoid name collisions, and the SASL WG is not likely to be around
>forever, making the IANA SASL registry the only point of official
>information about SASL mechanisms.

We don't want folks grabbing the name space and delegating it
inappropriately to non-IANA registries, which is what families
allow to happen.  Given the IETF previous determination that
an IANA registry for SASL mechanism is appropriate, establishing
new registration procedures which allow persons without any
IETF action to delegate registration to non-IANA registries
is, I think, counter to the previously established consensus.

Lastly, the reason why I favor Expert Review is that little
to no guidelines are actually necessary as its assumed the
Expert understands the issues (both specific to SASL, but
general IETF/IANA considerations) and will make appropriate
decisions AFTER obtaining community input.  The decisions
are appealable. 

I do not see any need to specify any more guidelines to
the Expert than "Requests for family name will be forwarded
to the <[email-masked]> mailing list.  After a 2-week
comment period, the Expert will make a determination of
the appropriateness of the request and either approve or
disapprove the request with notification to the requestor,
IANA, and this list.  The approval/disapproval action may
be appealed."

Kurt

>Thanks,
>Simon
>
>Chris Newman <[email-masked]> writes:
>
>> Try to make the process as lightweight as possible.
>>
>> Require expert review if:
>> 1. The family prefix is shorter than 3 characters (namespace issues), or doesn't
>>   end in a "-".
>> 2. The family name would include an already registered mechanism name.
>>
>> Otherwise I think first-come, first-serve is fine for name families.
>>
>>                - Chris
>>
>> Kurt D. Zeilenga wrote on 11/14/05 11:42 -0800:
>>
>>>
>>> One minimal change that might help here (but obviously will not
>>> cure all the woes) here is to:
>>>
>>> -Each family of SASL mechanisms MUST be identified by a prefix.
>>> +Each family of SASL mechanisms MUST be identified by a unique prefix.
>>>
>>> Of course, as Alexey hints at, registering a family which
>>> encompasses an existing mechanism may be appropriate,
>>> such as a CRAM-* or DIGEST-* family.   Deciding whether or not
>>> such is appropriate, I think, requires some expert review.
>>> That is, I don't think its something IANA can determine out
>>> on their own.
>>>
>>> So, I'm thinking that we might want to require Expert Review,
>>> possibly with Specification Required, for registration of
>>> families.
>>>
>>> Kurt
>>>
>>> At 03:56 AM 11/12/2005, Simon Josefsson wrote:
>>>
>>>> Thanks for using the first-come-first-serve approach also for SASL
>>>> families.
>>>>
>>>> While looking into "GSS-*", I noticed a potential namespace problem.
>>>> We already have "GSS-SPNEGO".  So the "GSS-*" family will use "GS2-*".
>>>>
>>>> However, that illustrate a situation that the IANA should not be
>>>> permitted to create.  If IANA receive a request to register "FOO-*",
>>>> it must reject it if there is an earlier registration that begin with
>>>> "FOO-".  Right?
>>>>
>>>> Thanks,
>>>> Simon
>>>
>>>

From: Simon Josefsson <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: [email-masked], "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: IANA Considerations
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 15 Nov 2005 10:36:58 +0100
Sender: [email-masked]

If we go with a expert reviewer, I believe there should be guidelines
for that expert reviewer in the document.  That is why I'm opposed to
that solution.  It is complicated to write up good guidelines for
expert reviewers.  If someone volunteer to come up with expert review
guidelines, and assuming the guidelines look good, I'll yield.

Perhaps, as a compromise, the IANA considerations could include the
possibility of removing registered mechanism names through IETF
Conensus, to make it possible to remove non-obviously bogus but
harmful registration.

However, I don't see how any IANA registration could be harmful.  The
IANA registry isn't normative, it is merely there for informational
purposes.  Restricting people to give information about SASL
mechanisms they use or specify appear counter-productive to me.

We do want people to make us aware of their SASL mechanisms names, to
avoid name collisions, and the SASL WG is not likely to be around
forever, making the IANA SASL registry the only point of official
information about SASL mechanisms.

Thanks,
Simon

Chris Newman <[email-masked]> writes:

> Try to make the process as lightweight as possible.
>
> Require expert review if:
> 1. The family prefix is shorter than 3 characters (namespace issues), or doesn't
>   end in a "-".
> 2. The family name would include an already registered mechanism name.
>
> Otherwise I think first-come, first-serve is fine for name families.
>
>                - Chris
>
> Kurt D. Zeilenga wrote on 11/14/05 11:42 -0800:
>
>>
>> One minimal change that might help here (but obviously will not
>> cure all the woes) here is to:
>>
>> -Each family of SASL mechanisms MUST be identified by a prefix.
>> +Each family of SASL mechanisms MUST be identified by a unique prefix.
>>
>> Of course, as Alexey hints at, registering a family which
>> encompasses an existing mechanism may be appropriate,
>> such as a CRAM-* or DIGEST-* family.   Deciding whether or not
>> such is appropriate, I think, requires some expert review.
>> That is, I don't think its something IANA can determine out
>> on their own.
>>
>> So, I'm thinking that we might want to require Expert Review,
>> possibly with Specification Required, for registration of
>> families.
>>
>> Kurt
>>
>> At 03:56 AM 11/12/2005, Simon Josefsson wrote:
>>
>>> Thanks for using the first-come-first-serve approach also for SASL
>>> families.
>>>
>>> While looking into "GSS-*", I noticed a potential namespace problem.
>>> We already have "GSS-SPNEGO".  So the "GSS-*" family will use "GS2-*".
>>>
>>> However, that illustrate a situation that the IANA should not be
>>> permitted to create.  If IANA receive a request to register "FOO-*",
>>> it must reject it if there is an earlier registration that begin with
>>> "FOO-".  Right?
>>>
>>> Thanks,
>>> Simon
>>
>>

Date: Mon, 14 Nov 2005 17:10:32 -0800
From: Chris Newman <[email-masked]>
Subject: Re: IANA Considerations
To: "Kurt D. Zeilenga" <[email-masked]>, Simon Josefsson <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Try to make the process as lightweight as possible.

Require expert review if:
1. The family prefix is shorter than 3 characters (namespace issues), or doesn't
   end in a "-".
2. The family name would include an already registered mechanism name.

Otherwise I think first-come, first-serve is fine for name families.

                - Chris

Kurt D. Zeilenga wrote on 11/14/05 11:42 -0800:

>
> One minimal change that might help here (but obviously will not
> cure all the woes) here is to:
>
> -Each family of SASL mechanisms MUST be identified by a prefix.
> +Each family of SASL mechanisms MUST be identified by a unique prefix.
>
> Of course, as Alexey hints at, registering a family which
> encompasses an existing mechanism may be appropriate,
> such as a CRAM-* or DIGEST-* family.   Deciding whether or not
> such is appropriate, I think, requires some expert review.
> That is, I don't think its something IANA can determine out
> on their own.
>
> So, I'm thinking that we might want to require Expert Review,
> possibly with Specification Required, for registration of
> families.
>
> Kurt
>
> At 03:56 AM 11/12/2005, Simon Josefsson wrote:
>
>> Thanks for using the first-come-first-serve approach also for SASL
>> families.
>>
>> While looking into "GSS-*", I noticed a potential namespace problem.
>> We already have "GSS-SPNEGO".  So the "GSS-*" family will use "GS2-*".
>>
>> However, that illustrate a situation that the IANA should not be
>> permitted to create.  If IANA receive a request to register "FOO-*",
>> it must reject it if there is an earlier registration that begin with
>> "FOO-".  Right?
>>
>> Thanks,
>> Simon
>
>

Date: Mon, 14 Nov 2005 11:42:01 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: IANA Considerations
Cc: [email-masked]
Sender: [email-masked]

One minimal change that might help here (but obviously will not
cure all the woes) here is to:

-Each family of SASL mechanisms MUST be identified by a prefix.
+Each family of SASL mechanisms MUST be identified by a unique prefix.

Of course, as Alexey hints at, registering a family which
encompasses an existing mechanism may be appropriate,
such as a CRAM-* or DIGEST-* family.   Deciding whether or not
such is appropriate, I think, requires some expert review.
That is, I don't think its something IANA can determine out
on their own.

So, I'm thinking that we might want to require Expert Review,
possibly with Specification Required, for registration of
families.

Kurt

At 03:56 AM 11/12/2005, Simon Josefsson wrote:

>Thanks for using the first-come-first-serve approach also for SASL
>families.
>
>While looking into "GSS-*", I noticed a potential namespace problem.
>We already have "GSS-SPNEGO".  So the "GSS-*" family will use "GS2-*".
>
>However, that illustrate a situation that the IANA should not be
>permitted to create.  If IANA receive a request to register "FOO-*",
>it must reject it if there is an earlier registration that begin with
>"FOO-".  Right?
>
>Thanks,
>Simon

Date: Sat, 12 Nov 2005 16:24:34 +0000
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: IANA Considerations
Sender: [email-masked]

Simon Josefsson wrote:

>Thanks for using the first-come-first-serve approach also for SASL
>families.
>
>While looking into "GSS-*", I noticed a potential namespace problem.
>We already have "GSS-SPNEGO".  So the "GSS-*" family will use "GS2-*".
>
>However, that illustrate a situation that the IANA should not be
>permitted to create.  If IANA receive a request to register "FOO-*",
>it must reject it if there is an earlier registration that begin with
>"FOO-".  Right?
>  
>
Right, unless FOO-XXX is a member of FOO-* family.

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: IANA Considerations
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 12 Nov 2005 12:56:09 +0100
Sender: [email-masked]

Thanks for using the first-come-first-serve approach also for SASL
families.

While looking into "GSS-*", I noticed a potential namespace problem.
We already have "GSS-SPNEGO".  So the "GSS-*" family will use "GS2-*".

However, that illustrate a situation that the IANA should not be
permitted to create.  If IANA receive a request to register "FOO-*",
it must reject it if there is an earlier registration that begin with
"FOO-".  Right?

Thanks,
Simon

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-13.txt 
Date: Fri, 11 Nov 2005 15:50:01 -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		: Simple Authentication and Security Layer (SASL)
	Author(s)	: A. Melnikov, K. Zeilenga
	Filename	: draft-ietf-sasl-rfc2222bis-13.txt
	Pages		: 30
	Date		: 2005-11-11
	
The Simple Authentication and Security Layer (SASL) is a framework for
  providing authentication and data security services in
  connection-oriented protocols via replaceable mechanisms.  It provides
  a structured interface between protocols and mechanisms.  The
  resulting framework allows new protocols to reuse existing mechanisms
  and allows old protocols to make use of new mechanisms.  The framework
  also provides a protocol for securing subsequent protocol exchanges
  within a data security layer.

  This document describes how a SASL mechanism is structured, describes
  how protocols include support for SASL, and defines the protocol for
  carrying a data security layer over a connection.  Additionally, this
  document defines one SASL mechanism, the EXTERNAL mechanism.

  This document obsoletes RFC 2222.

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

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

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

--OtherAccess--

--NextPart--

Date: Thu, 10 Nov 2005 22:23:05 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-12.txt
Sender: [email-masked]

Kurt D. Zeilenga wrote:
> At 04:10 PM 11/10/2005, Chris Newman wrote:
>> This text is acceptable.  If we wanted to be more verbose:
>>
>> A SASL mechanism can be defined as client-first, variable, or server-first.
>> If a SASL mechanism is defined as client-first and the client does not send
>> an initial response, then the first server challenge MUST be empty (the
>> PLAIN mechanism is an example of this case).  If a SASL mechanism is
>> defined as variable, then the specification needs to state how the server
>> behaves when the initial client response is omitted (the DIGEST-MD5 mechanism
>> is an example of this case).  If a SASL mechanism is defined as server-first
>> then the client MUST NOT send an initial client response (the CRAM-MD5
>> mechanism is an example of this case). 
> 
> I prefer this text.

Me too.  Nice job Chris.

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University

Date: Thu, 10 Nov 2005 16:49:29 -0800
To: Chris Newman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-12.txt
Cc: Ken Murchison <[email-masked]>, [email-masked]
Sender: [email-masked]

At 04:10 PM 11/10/2005, Chris Newman wrote:
>This text is acceptable.  If we wanted to be more verbose:
>
> A SASL mechanism can be defined as client-first, variable, or server-first.
> If a SASL mechanism is defined as client-first and the client does not send
> an initial response, then the first server challenge MUST be empty (the
> PLAIN mechanism is an example of this case).  If a SASL mechanism is
> defined as variable, then the specification needs to state how the server
> behaves when the initial client response is omitted (the DIGEST-MD5 mechanism
> is an example of this case).  If a SASL mechanism is defined as server-first
> then the client MUST NOT send an initial client response (the CRAM-MD5
> mechanism is an example of this case). 

I prefer this text.

Kurt 

Date: Thu, 10 Nov 2005 16:10:43 -0800
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-12.txt
To: Ken Murchison <[email-masked]>, [email-masked]
Sender: [email-masked]

Ken Murchison wrote on 11/8/05 9:41 -0500:
> Suggested text:
>
>       a) An indication whether the client is required to send data first.
>          If so, when the client does not send data first, the initial
>          challenge MUST be specified as being an empty challenge.

This text is acceptable.  If we wanted to be more verbose:

  A SASL mechanism can be defined as client-first, variable, or server-first.
  If a SASL mechanism is defined as client-first and the client does not send
  an initial response, then the first server challenge MUST be empty (the
  PLAIN mechanism is an example of this case).  If a SASL mechanism is
  defined as variable, then the specification needs to state how the server
  behaves when the initial client response is omitted (the DIGEST-MD5 mechanism
  is an example of this case).  If a SASL mechanism is defined as server-first
  then the client MUST NOT send an initial client response (the CRAM-MD5
  mechanism is an example of this case).

        - Chris

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: IETF64 SASL WG summary
From: Tom Yu <[email-masked]>
Date: Thu, 10 Nov 2005 14:42:46 -0500
Lines: 49
Sender: [email-masked]

SASL WG
Tuesday, November 8, 2005
09:00-11:30

SUMMARY
=======

Thanks to Bob Morgan for scribing.

SASL base spec is late; Kurt to revise and post new version this week.
No objections to WGLC for the GSSAPI mech, but require positive
support to progress.  Plain mech will hold for base.  Previous
consensus during IETF63 for taking CRAM-MD5 off standards track, but
objections in mailing list.  Some people prefer standards track for
CRAM-MD5, but do not object to making it Informational.

DIGEST-MD5: Added channel bindings text.  Dropped AES CBC mode with
separate IV.  Update ABNF to reference RFC.  Some discussion about how
to get AES counter mode text written.  Some remaining issues about ISO
8859-1 compat with HTTP DIGEST.  Check with apps area.

SASL base: Minor changes re error handling, empty initial server
challenge, etc.  Some proposed cleanup of security considerations
section.  Discussion re IANA considerations re family of mechs.
Consensus for delegation to registrant upon assignment.

GSSAPI family of mechs: Simon will write some text; note base-32
encoding needs checking vs DNSEXT.

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

Kurt will talk with apps area people about HTTP DIGEST 8859-1 issue

GSS (krb5 & SPNEGO) WGLC nowish

SASL base to IESG Dec 2005

DIGEST-MD5 next rev before Dec 2006

GSS mech family initial draft Feb 2006

CRAM-MD5 WGLC around Mar 2006

DIGEST-MD5 WGLC around Mar 2006

implementation plan Summer 2006

GSS mech family to IESG Sep 2006

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Base32 alphabet
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 08 Nov 2005 19:55:25 +0100
Sender: [email-masked]

All,

The base32 alphabet (A-Z2-7) used for the GSS-* family doesn't
preserve sort order of the binary input when sorted as encoded data.
There has been a long discussion on this in the DNSEXT WG:

http://thread.gmane.org/gmane.ietf.dnsext/7829

As a result of that discussion, I added the 2938 base32 alphabet to
the base encoding draft, see:

http://josefsson.org/base-encoding/

The question I'd like to ask the SASL WG is:

Is there a reason to keep using the A-Z2-7 alphabet?  I know of no
existing use of that base32 alphabet.  It reduces implementation costs
if we can re-use the same base32 implementation and use the same
base32 alphabet in different places.  I believe the GSS-* family
should use the 0-9A-V alphabet.  Further, I believe the A-Z2-7
alphabet should be dropped in the revised base-encoding RFC.  If
anyone here knows of any reason we shouldn't do this, please let me
know.

Cheers,
Simon

Date: Tue, 08 Nov 2005 09:41:59 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-12.txt
Sender: [email-masked]

Chris Newman wrote:
> Section 5 (substantive):
> 
>>       If so, when the client does not send data first, the initial
>>       challenge MUST be specified as being an empty challenge.
> 
> 
> I would prefer this be deleted for the following reasons:
> 1. If the non-standard LOGIN mechanism is implemented in such a way as to
>   follow this rule, it will not interoperate with the installed base of
>   SMTP client software.  Thus it is bad advice in at least one case.
> 2. A SASL mechanism which provides a "fast reconnect" facility but would be
>   server-first when that facility is not used can save a round trip by
>   ignoring this rule.  The workaround for that situation would be to define
>   two SASL mechanisms, one for the fast reconnect and one for the regular
>   variant.  I find that less palatable than one mechanism with an optional
>   initial client response and non-empty initial server response.
> I will not block rough consensus over this issue and do not wish to 
> introduce delay, but if this suggestion is non-controversial I would 
> like the change made.

I agree with Chris that either this text should be removed or rewritten 
to give the mechanism some flexibility, since DIGEST-MD5 can be either 
server-first (initial auth) or client-first (fast reauth), at the 
client's discretion.

Suggested text:

      a) An indication whether the client is required to send data first.
         If so, when the client does not send data first, the initial
         challenge MUST be specified as being an empty challenge.

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked], Sam Hartman <[email-masked]>
Subject: Re: rfc2222bis -12 comments
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 08 Nov 2005 13:37:28 +0100
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:

> At 05:05 PM 11/7/2005, Sam Hartman wrote:
>>I'd support reserving x-* for experimentals.
>
> I see no point in reserving x-* for experiments when
> all names are registered on a "first come, first serve"
> basis.

I agree.  I think X-* would be a poor solution, it causes problems
when an experimental mechanism is brought to standardization.

> I note that one of the reasons why families are restricted
> to IETF Standard Track documents is that, aside from
> requesting the family be registered, these documents
> can provide IANA with amended registration procedures
> for that portion of the name space it consumes.  I could
> see the document providing these procedures to be
> non-standard track, but I do think they need IESG
> approval (coupled with the usual IANA review during
> IESG consideration).  So, possibly we could say
> registration of a name space requires both specification
> and IESG action.

I agree that a specification and IESG action are preferably, but I
disagree when it comes to requiring this.

I think you are requiring too much effort to experiment with SASL
mechanisms.

There are no signs that the liberal registration mechanism for SASL
mechanisms has been abused.  If it is simple to register a SASL
mechanism used in experiments, people will do it, and this will avoid
confusion for us in the future when those experiments are brought for
IETF standardization.

If it is difficult to reserve a SASL mechanism family, people won't
bother going through the effort of doing so, and you will have a
deployment problem when standardizing this.  Look at TLS to see how
this is causing real problems.

Thanks,
Simon

Date: Mon, 07 Nov 2005 19:22:36 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: rfc2222bis -12 comments
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

At 05:05 PM 11/7/2005, Sam Hartman wrote:
>I'd support reserving x-* for experimentals.

I see no point in reserving x-* for experiments when
all names are registered on a "first come, first serve"
basis.  On the other hand, I wouldn't mind reserving
x-* for "private use".

I note that one of the reasons why families are restricted
to IETF Standard Track documents is that, aside from
requesting the family be registered, these documents
can provide IANA with amended registration procedures
for that portion of the name space it consumes.  I could
see the document providing these procedures to be
non-standard track, but I do think they need IESG
approval (coupled with the usual IANA review during
IESG consideration).  So, possibly we could say
registration of a name space requires both specification
and IESG action.

Kurt 

Date: Mon, 07 Nov 2005 18:22:37 -0800
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>
cc: [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: rfc2222bis -12 comments
Originator-Info: login-token=Mulberry:016vakT1ReGcM2QRzQHXTUvoFo23pxKh1Xa9K0IHY=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, November 07, 2005 08:05:25 PM -0500 Sam Hartman 
<[email-masked]> wrote:

>
> I'd support reserving x-* for experimentals.

As would I

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis -12 comments
From: Sam Hartman <[email-masked]>
Date: Mon, 07 Nov 2005 20:05:25 -0500
Sender: [email-masked]

I'd support reserving x-* for experimentals.

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis -12 comments
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 08 Nov 2005 01:23:26 +0100
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>     Simon> This suggest only IETF Standards Track documents can
>     Simon> reserve a SASL family.  Why is that?  I see no reason for
>     Simon> it.
>
> I think the issue is namespace management.  Taking up a large prefix
> of the namespace is something we want to carefully consider before
> approving.

I don't see any signs that the current SASL namespace registry has
been abused to warrant this.  It is useful to permit early
registration of experimental mechanism names, since this avoid
eventual conflicts when two organizations experiment with, say, EAP-*.

Thanks,
Simon

Date: Mon, 07 Nov 2005 01:14:44 -0800
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-12.txt
To: [email-masked]
Sender: [email-masked]

I have reviewed this draft carefully and consider it acceptable for publication 
in its present form.  However, I believe another round of fixes would improve 
the draft usefully if the editor has time.  I found two substantial issues and 
many editorial issues.  Detailed comments follow:

Section 3.2 (editorial):

>  To detect downgrade attacks, a protocol may allow the client to
>  discover available mechanism subsequent to the authentication exchange
                      ^^^^^^^^^
                      mechanisms

Section 3.6 (substantive):

I suggest adding this paragraph, which I believe to be non-controversial:

----
The outcome message provided by the server MAY provide a way for the client to 
distinguish between errors which are best dealt with by re-prompting the user 
for her credentials, errors which are best dealt with by telling the user to 
try again later, and errors where the user must contact a system administrator 
for resolution (see RFC 3206 for an example).  This distinction is particularly 
useful during scheduled server maintenance periods as it reduces support costs. 
It is also important that the server can be configured such that the outcome 
message will not distinguish between a valid user with invalid credentials and 
an invalid user.
----

Section 3.7 (editorial):

>  The maximum size for each side expects is fixed by the mechanism,
                    XXX
remove unnecessary word

Section 4 (editorial):

>  6) Identify precisely where newly negotiated security layers starts to
                                                                     ^
remove unnecessary plural.

Section 5 (substantive):

>       If so, when the client does not send data first, the initial
>       challenge MUST be specified as being an empty challenge.

I would prefer this be deleted for the following reasons:
1. If the non-standard LOGIN mechanism is implemented in such a way as to
   follow this rule, it will not interoperate with the installed base of
   SMTP client software.  Thus it is bad advice in at least one case.
2. A SASL mechanism which provides a "fast reconnect" facility but would be
   server-first when that facility is not used can save a round trip by
   ignoring this rule.  The workaround for that situation would be to define
   two SASL mechanisms, one for the fast reconnect and one for the regular
   variant.  I find that less palatable than one mechanism with an optional
   initial client response and non-empty initial server response.
I will not block rough consensus over this issue and do not wish to introduce 
delay, but if this suggestion is non-controversial I would like the change made.

Section 6 (editorial):

>  services.  It is also hoped that future mechanisms will provide more
>  advance data security services like re-keying (see Section 6.1).
   ^^^^^^^
   advanced

Section 6.1.1 (editorial):

>  mechanism is a security-sensitive negotiations.

   "negotiations" -> "negotiation"
or "is a security-sensitive negotiations." -> "is security-sensitive."

>  The client's initiation of the SASL exchange, including the the

remove redundant "the"

Section 6.2 (editorial):

>  Many mechanisms are subject to various passive attacks, including
>  simple eavesdropping of unprotected credential information in
>  mechanisms, such as PLAIN, to online and offline dictionary attacks.

I don't believe this is correct grammar.  I suggest changing:
       "in mechanisms, such as PLAIN, to"
to be: "(e.g., PLAIN), as well as"

Section 6.3 (editorial):

>  Administrative limits on security layers lifetime may take the form of

remove unnecessary plural: "layers lifetime" -> "layer lifetime"  (occurs twice 
in paragraph).

Section 7.1.2 (editorial):

>  registration itself by sending mail to <[email-masked]>.  At IANA sole
>  discretion, IANA may attach the comment to the registration SASL
>  mechanism.

"At IANA sole discretion" -> "At IANA's sole discretion"
"registration SASL mechanism" -> "SASL mechanism registration" or "registered 
SASL mechanism"

Section 7.2 (editorial):

>  It is requested that IANA updates the SASL mechanisms registry as

remove unnecessary plural "updates" -> "update"

Section A.1 (editorial):

>  response is non-empty when the client is requesting to act as identity

"act as identity" -> "act as the identity"

>    server unwilling or unable to associate an authorization identity

"server unwilling" -> "server is unwilling"

>    with the clients credentials,

"clients credentials" -> "client's credentials"

>  with the clients request to initiate the authentication exchange.

"clients request" -> "client's request"

Appendix B (editorial):

>     Unicode characters.  The NUL (U+0000) is prohibited.  While protocol

"The NUL (U+0000) is prohibited" -> "The NUL (U+0000) character is prohibited"

>  have been significant tightened.  Existing protocol and mechanism

"significant" -> "significantly"

                - Chris

Date: Mon, 07 Nov 2005 01:14:44 -0800
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-12.txt
To: [email-masked]
Sender: [email-masked]

I have reviewed this draft carefully and consider it acceptable for publication 
in its present form.  However, I believe another round of fixes would improve 
the draft usefully if the editor has time.  I found two substantial issues and 
many editorial issues.  Detailed comments follow:

Section 3.2 (editorial):

>  To detect downgrade attacks, a protocol may allow the client to
>  discover available mechanism subsequent to the authentication exchange
                      ^^^^^^^^^
                      mechanisms

Section 3.6 (substantive):

I suggest adding this paragraph, which I believe to be non-controversial:

----
The outcome message provided by the server MAY provide a way for the client to 
distinguish between errors which are best dealt with by re-prompting the user 
for her credentials, errors which are best dealt with by telling the user to 
try again later, and errors where the user must contact a system administrator 
for resolution (see RFC 3206 for an example).  This distinction is particularly 
useful during scheduled server maintenance periods as it reduces support costs. 
It is also important that the server can be configured such that the outcome 
message will not distinguish between a valid user with invalid credentials and 
an invalid user.
----

Section 3.7 (editorial):

>  The maximum size for each side expects is fixed by the mechanism,
                    XXX
remove unnecessary word

Section 4 (editorial):

>  6) Identify precisely where newly negotiated security layers starts to
                                                                     ^
remove unnecessary plural.

Section 5 (substantive):

>       If so, when the client does not send data first, the initial
>       challenge MUST be specified as being an empty challenge.

I would prefer this be deleted for the following reasons:
1. If the non-standard LOGIN mechanism is implemented in such a way as to
   follow this rule, it will not interoperate with the installed base of
   SMTP client software.  Thus it is bad advice in at least one case.
2. A SASL mechanism which provides a "fast reconnect" facility but would be
   server-first when that facility is not used can save a round trip by
   ignoring this rule.  The workaround for that situation would be to define
   two SASL mechanisms, one for the fast reconnect and one for the regular
   variant.  I find that less palatable than one mechanism with an optional
   initial client response and non-empty initial server response.
I will not block rough consensus over this issue and do not wish to introduce 
delay, but if this suggestion is non-controversial I would like the change made.

Section 6 (editorial):

>  services.  It is also hoped that future mechanisms will provide more
>  advance data security services like re-keying (see Section 6.1).
   ^^^^^^^
   advanced

Section 6.1.1 (editorial):

>  mechanism is a security-sensitive negotiations.

   "negotiations" -> "negotiation"
or "is a security-sensitive negotiations." -> "is security-sensitive."

>  The client's initiation of the SASL exchange, including the the

remove redundant "the"

Section 6.2 (editorial):

>  Many mechanisms are subject to various passive attacks, including
>  simple eavesdropping of unprotected credential information in
>  mechanisms, such as PLAIN, to online and offline dictionary attacks.

I don't believe this is correct grammar.  I suggest changing:
       "in mechanisms, such as PLAIN, to"
to be: "(e.g., PLAIN), as well as"

Section 6.3 (editorial):

>  Administrative limits on security layers lifetime may take the form of

remove unnecessary plural: "layers lifetime" -> "layer lifetime"  (occurs twice 
in paragraph).

Section 7.1.2 (editorial):

>  registration itself by sending mail to <[email-masked]>.  At IANA sole
>  discretion, IANA may attach the comment to the registration SASL
>  mechanism.

"At IANA sole discretion" -> "At IANA's sole discretion"
"registration SASL mechanism" -> "SASL mechanism registration" or "registered 
SASL mechanism"

Section 7.2 (editorial):

>  It is requested that IANA updates the SASL mechanisms registry as

remove unnecessary plural "updates" -> "update"

Section A.1 (editorial):

>  response is non-empty when the client is requesting to act as identity

"act as identity" -> "act as the identity"

>    server unwilling or unable to associate an authorization identity

"server unwilling" -> "server is unwilling"

>    with the clients credentials,

"clients credentials" -> "client's credentials"

>  with the clients request to initiate the authentication exchange.

"clients request" -> "client's request"

Appendix B (editorial):

>     Unicode characters.  The NUL (U+0000) is prohibited.  While protocol

"The NUL (U+0000) is prohibited" -> "The NUL (U+0000) character is prohibited"

>  have been significant tightened.  Existing protocol and mechanism

"significant" -> "significantly"

                - Chris

Date: Mon, 07 Nov 2005 08:47:32 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: rfc2222bis -12 comments
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

At 07:15 AM 11/7/2005, Sam Hartman wrote:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>    Simon> This suggest only IETF Standards Track documents can
>    Simon> reserve a SASL family.  Why is that?  I see no reason for
>    Simon> it.
>
>I think the issue is namespace management.  Taking up a large prefix
>of the namespace is something we want to carefully consider before
>approving.

Exactly.

- Kurt 

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis -12 comments
From: Sam Hartman <[email-masked]>
Date: Mon, 07 Nov 2005 10:15:13 -0500
Sender: [email-masked]

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

    Simon> This suggest only IETF Standards Track documents can
    Simon> reserve a SASL family.  Why is that?  I see no reason for
    Simon> it.

I think the issue is namespace management.  Taking up a large prefix
of the namespace is something we want to carefully consider before
approving.

Date: Mon, 7 Nov 2005 06:28:50 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: draft-ietf-sasl-rfc2222bis-12.txt
Sender: [email-masked]

Hi,

(please keep in Cc:)

I reviewed -11 in July, and was asked to check whether the issues had 
been addressed in -12.

I went through the discussions where I was Cc:.  Most substantial 
issues seemed to be adequately addressed or discussed.  I was sad to 
note the majority of editorial issues fell through the cracks; I've 
removed the previous coomments from below which I believe no longer 
apply.

substantial
-----------

     In order to avoid interoperability problems due to differing
      normalizations, the protocol specification MUST detail precisely
      the how and where (client or server) non-\mpty authorization
      identity strings are prepared, including all normalizations, for
      comparison and other applicable functions to ensure proper
      function.

==> s/\/e/

substantial
-----------

7) Whether or not you are vulnerable to MITM attacks seems to depend
on the challenge/response methods used, so the below text may need
tuning.  An attack example is challenge/response where the server doesn't
authenticate the client, so an attacker which is doing MITM when SASL
is exchanged can continue to perform MITM after the SASL exchange.
I guess it's important to distinguish the cases "MITM attacker after SASL
auth" and "MITM attacker modifying the SASL negotiation", as well as look
at the security services provided.

8) shouldn't there be some recommendations how to avoid the most important
passive attacks?

6.2.  Passive Attacks

   Many mechanisms are subject to various passive attacks, including
   simple eavesdropping of unprotected credential information in
   mechanisms, such as PLAIN, to online and offline dictionary attacks.

[[200511: These two issues have one thing in common: while the doc states
that integrity protection provides a number of things (like prevent MITM
hijacking), this still seems assumptive.  It may be perfectly legitimate to
run e.g., SASL-over-PLAIN (or anything else where the endpoints haven't been
strongly identified and authenticated), where this may not hold.  Security
considerations should have more truth in advertising.

   To detect downgrade attacks, a protocol may allow the client to
   discover available mechanism subsequent to the authentication exchange
   and installation of data security layers with at least integrity
   protection.  This allows the client to detect changes to the list of
   mechanisms supported by the server.
]]

editorial
---------

   If the outcome is successful and a data layer was negotiated, this
   layer is then installed.  Protocols may allow this data to be carried
   in the request message.  This applies as well to the following
   illustrations.

   Some mechanisms specify that the first data sent in the authentication
   exchange is from the client to the server.  Protocols may provide an
   optional initial response field in the request message to carry this
   data.  Where the mechanism specifies the first data data sent in the
   exchange is from the client to the server, the protocol provides an
   optional initial response field, and the client uses this field, the
   exchange is shortened by one round-trip:

       C: Request authentication exchange + Initial response
       <additional challenge/response messages>
       S: Outcome of authentication exchange

==> quite a bit of text duplication in the 2nd paragraph?  Basically you say
the same thing twice. Is this necessary/useful?

This appears to be a stylistic issue, as the following
paragraphs have the same as well.

[[200511: Jeffrey mentioned in a follow-up that the above was poorly 
worded]]

   SASL mechanisms names are registered as discussed in Section 7.1.

==> s/mechanisms/mechanism/

     - the identity associated with the client's credentials are not
       authorized to act as the requested authorization identity,

==> s/are/is/

   7) If the protocol supports other layered security services, such as
      Transport Layer Security (TLS) [RFC2246], the specification MUST
      prescribe the order in which security layers are applied to
      protocol data.

==> the revision of TLS spec appears to be almost complete
(draft-ietf-tls-rfc2246-bis), so maybe it could be referred, though
for the intents and purposes of this reference this should not matter.

[[ 200511: that draft is now in RFC-ed queue ]]

   1) The name of the mechanism (see Section 3.1).  This name MUST be
      registered as discussed in Section 8.1.

==> you mean sect 7.1..

   In order to avoid interoperability problems due to differing
   normalizations, when a mechanism calls for character data is to be
   used as input to a cryptographic and/or comparison function, the

==> I cannot parse "calls for character data ..."

   services.  It is also hoped that future mechanisms will provide more
   advance data security services like re-keying (see Section 6.1).

==> s/advance/advanced/

   Administrative limits on security layers lifetime may take the form of

==> s/layers/layers'/ (similar later in the paragraph)

       Security considerations: See RFC XXXX, section 9.
       Published specification (optional, recommended): RFC XXXX

==> it may be blindingly obviously, but should you say that XXXX
refers to the number given to this draft? :)

     Security considerations: See RFC XXXX, section 9.

==> did you mean section 7 or appendix A?
Using xml2rfc would help you with these ;-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: rfc2222bis -12 comments
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 07 Nov 2005 04:01:21 +0100
Sender: [email-masked]

I reviewed -12, and it looks fine.  Please find some minor
comments/questions and typo fixes below.

Regards,
Simon

3.2. Mechanism Negotiation
...
  To detect downgrade attacks, a protocol may allow the client to
  discover available mechanism subsequent to the authentication exchange
  and installation of data security layers with at least integrity
  protection.  This allows the client to detect changes to the list of
  mechanisms supported by the server.

This is actually recommended through SHOULD below.  How about
replacing "may" with "should" here?

6.1.1. Man-in-the-middle Attacks

  In order to detect downgrade attacks to the least (or less) secure
  mechanism supported, the client may discover the SASL mechanisms the
  server makes available both before the SASL authentication exchange
  and after the negotiated SASL security layer (with at least integrity
  protection) has been installed through the protocol's mechanism
  discovery facility.  If the client finds that the integrity protected
  list (the list obtained after the security layer was installed)
  contains a stronger mechanism than those in the previously obtained
  list, the client should assume the previously obtained list was
  modified by an attacker.

Shouldn't there be a recommended action here?  I.e., abort the
connection?

7.1.1.  Registration Procedure
...
  There is no naming convention for SASL mechanisms; any name that
  conforms to the syntax of a SASL mechanism name can be registered.
  However an IETF Standards Track document may reserve a portion of the
  SASL mechanism namespace ("family of SASL mechanisms") for its own
  use, amending the registration rules for that portion of the
  namespace.  Each family of SASL mechanisms MUST be identified by a
  prefix.

This suggest only IETF Standards Track documents can reserve a SASL
family.  Why is that?  I see no reason for it.

Typo:
     the how and where (client or server) non-\mpty authorization
                                              -- huh?
  The maximum size for each side expects is fixed by the mechanism,
                   --- remove
  The client's initiation of the SASL exchange, including the the
                                                          ---
  Most existing SASL security layers to not, themselves, offer
                                     --
  provide for re-keying.  SASL mechanisms may.  Designers of future SASL
                                             -- huh?

To: Chris Newman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: cram-md5 and standards track
From: Sam Hartman <[email-masked]>
Date: Sat, 05 Nov 2005 08:41:27 -0500
Sender: [email-masked]

>>>>> "Chris" == Chris Newman <[email-masked]> writes:

    Chris> Informational is a good compromise.  Historic doesn't fit
    Chris> for a mechanism which is deployed in a significant market
    Chris> niche and which most vendors will continue to ship
    Chris> regardless of the document status.

I don't see why historic is a problem: as I read 2026 a TS with
limited applicability can be part of an AS with not recommended status
and that's a candidate for historic.  However that TS still has
applicability in that limited domain.  However most people I talk to
don't seem to read 2026 that way and read it that specifications that
are in use should not be marked historic.

I certainly do not want to imply that cram-md5 is not in use nor imply
that you should not implement it if you want a generally useful email
client.

It does seem that informational may actually convey that to people
much better than historic.

Date: Sat, 05 Nov 2005 00:42:39 -0800
From: Chris Newman <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-rfc2222-bis
To: Alexey Melnikov <[email-masked]>, Sam Hartman <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Alexey Melnikov wrote on 11/4/05 21:53 +0000:
> Sam Hartman wrote:
>
>> 3) The framework does not allow mechanisms to have additional data on
>>    failure.  I know this was discussed.  Did we determine that doing
>>    so would break things?
>>
> I think it might break existing implementations, because they might not
> expect a failure response to have extra data.

This could be added as an optional feature of new SASL application profiles 
without permitting its use in any existing SASL application profiles (unless a 
profile revision added negotiation for the feature).  That wouldn't break 
anything.  But...

>>  If not, I'd rather remove this prohibition
>>    because it would be useful for GSSAPI.
>>
> The server can return the additional data on failure as a regular SASL
> challenge. The client will figure out that the authentication attempt has
> failed and can abort the exchange. This adds one round trip, but I don't
> think that failures are that frequent, so we don't need to optimize for them.

This is a strong argument to not add the feature.  No need to optimize the 
failure case, so let's keep it simpler.

                - Chris

Date: Sat, 05 Nov 2005 00:33:54 -0800
From: Chris Newman <[email-masked]>
Subject: Re: cram-md5 and standards track
To: Sam Hartman <[email-masked]>, [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Sam Hartman wrote on 11/4/05 10:18 -0500:
> Hi folks.  I've been thinking about the issue of cram-md5 on the
> standards track.
>
> Tom has not stated the results of his consensus call, but it is clear
> that things are not as clear-cut as they were in the room at Paris.
> I'm afraid I have to say something unpopular though.  The IESG process
> requires that at least one AD vote yes on a document meaning that they
> have read the document, believe it as good stuff and are willing to
> advocate it within the IESG.  In addition, the shepherd for a document
> is expected to vote yes on that document.
>
> I cannot vote yes on cram-md5 as a standard-track specification.  It
> provides no channel bindings to TLS and provides no integrity
> mechanism of its own.  It is weaker at dealing with MITM attacks than
> digest-md5.
> ...
> I could sponsor a version of cram-md5 at informational or historic.

Informational is a good compromise.  Historic doesn't fit for a mechanism which 
is deployed in a significant market niche and which most vendors will continue 
to ship regardless of the document status.

I would suggest that we have rough consensus on informational now that the 
standards track option has been removed from the list of possible choices. 
Anyone disagree?

                - Chris

Date: Fri, 04 Nov 2005 21:53:11 +0000
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-ietf-sasl-rfc2222-bis
Sender: [email-masked]

Sam Hartman wrote:

>3) The framework does not allow mechanisms to have additional data on
>    failure.  I know this was discussed.  Did we determine that doing
>    so would break things?
>
I think it might break existing implementations, because they might not 
expect a failure response to have extra data.

>  If not, I'd rather remove this prohibition
>    because it would be useful for GSSAPI.
>  
>
The server can return the additional data on failure as a regular SASL 
challenge. The client will figure out that the authentication attempt 
has failed and can abort the exchange. This adds one round trip, but I 
don't think that failures are that frequent, so we don't need to 
optimize for them.

Date: Fri, 04 Nov 2005 11:38:09 -0800
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-rfc2222-bis
Cc: [email-masked]
Sender: [email-masked]

At 10:00 AM 11/4/2005, Sam Hartman wrote:
>I think the document is a significant improvement over rfc2222 and is
>clear to me as someone who has worked with SASL for a while.
>
>I do have a few comments.
>
>1) Please indicate in the title of appendix A on external that it is
>   normative.

It seems odd to me to have something like:
        Appendix A.  SASL EXTERNAL Mechanism - a normative appendix
I don't recall this being done in any IETF document (but then
I haven't read them all :-).  Is this a generally accepted
practice?  Regardless, I have no objection to the change.

>You may receive a request from some IESG members to
>   make that a section not an appendix; I don't care myself.

The reason why I made it an appendix is that it is a separate
technical specification from the base technical specification,
with separate security considerations.  Combining the
specifications into the body would likely lead to some
confusion as to which considerations applied to which
specification.

As the specification of SASL EXTENRAL is not essential to the
specification of the SASL base, I think it is quite appropriate to 
keep it separate.  I would recommend moving the material
to a separate document if there were significant objections
to having that material attached to the base specification
document as an appendix.  But I think we should wait for these
objection to materialize and subsequent discussion before
undertaking any edit here.

>2) The document requires that server implementations of protocols
>   supporting client initial response actually take advantage of an
>   initial response if it is given.  I.E. the client MAY use the
>   feature, but a server is broken if it ignores the response.
>   Similarly servers MAY use the additional data with success, but
>   clients are broken if they don't interpret the data.  Of course if
>   the protocol doesn't have the option then it cannot be used.  Is
>   this consistent with implementation reality and wg consensus?

I believe Yes and Yes.

>   I hope so; it is a useful semantic.

I concur.  If the first answer wasn't Yes, the client would have to
somehow negotiate use of optional initial data prior to its use and
the server would have to somehow negotiate use of optional final data
prior to its use, or have some other goofy logic.  The key is that
the fields, when offered in the protocol, are optional to the
sender and hence the receiver must deal with both possibilities.

>3) The framework does not allow mechanisms to have additional data on
>    failure.  I know this was discussed.  Did we determine that doing
>    so would break things?

I believe so. I certainly believe it likely would introduce
backwards compatibility issues in existing protocols and
their implementations.

>4) The document requires that mechanisms be able to distinguish
>    between empty initial responses and absent initial responses.  I
>    know this issue was discussed.  Did we conclude we needed both?

I believe so.  The alternative would require restricting all
(or some) mechanism data challenges and responses to non-empty
octet strings.  This likely would be problematic.

Kurt

To: [email-masked]
Subject: Comments on draft-ietf-sasl-rfc2222-bis
From: Sam Hartman <[email-masked]>
Date: Fri, 04 Nov 2005 13:00:01 -0500
Sender: [email-masked]

Hi.

I think Kurt has done a lot of great work for the base spec.  I just
finished a review as an individual; this should not be taken as an AD
review which will be required as part of forwarding the document to
the IESG.

I think the document is a significant improvement over rfc2222 and is
clear to me as someone who has worked with SASL for a while.

I do have a few comments.

1) Please indicate in the title of appendix A on external that it is
   normative.  You may receive a request from some IESG members to
   make that a section not an appendix; I don't care myself.

2) The document requires that server implementations of protocols
   supporting client initial response actually take advantage of an
   initial response if it is given.  I.E. the client MAY use the
   feature, but a server is broken if it ignores the response.
   Similarly servers MAY use the additional data with success, but
   clients are broken if they don't interpret the data.  Of course if
   the protocol doesn't have the option then it cannot be used.  Is
   this consistent with implementation reality and wg consensus?  I
   hope so; it is a useful semantic.

3) The framework does not allow mechanisms to have additional data on
    failure.  I know this was discussed.  Did we determine that doing
    so would break things?  If not, I'd rather remove this prohibition
    because it would be useful for GSSAPI.

4) The document requires that mechanisms be able to distinguish
    between empty initial responses and absent initial responses.  I
    know this issue was discussed.  Did we conclude we needed both?

--Sam

To: [email-masked]
Subject: Progress on base specification
From: Sam Hartman <[email-masked]>
Date: Fri, 04 Nov 2005 10:28:47 -0500
Sender: [email-masked]

Folks, there has been no visible progress on the base spec since the
Paris meeting.  That's kind of a problem since the primary goal of
this WG is to produce that document.

I'd like to ask for some rearrangement of the agenda in Vancouver.
I'd like to start with a presentation from either Tom or Kurt
explaining where we are with base and what needs to happen.  I'm
perfectly happy to use our time inefficiently--up to and including
working on text in the session--if it gets us to a point where we have
a plan for getting base out that both the WG and I can agree to.  If
we can get that same plan and use the time more efficiently that's
wonderful as well.

This working group will be shut down if you cannot come up with such a
plan by end of November.

--Sam

To: [email-masked]
Cc: [email-masked]
Subject: cram-md5 and standards track
From: Sam Hartman <[email-masked]>
Date: Fri, 04 Nov 2005 10:18:39 -0500
Sender: [email-masked]

Hi folks.  I've been thinking about the issue of cram-md5 on the
standards track.

Tom has not stated the results of his consensus call, but it is clear
that things are not as clear-cut as they were in the room at Paris.
I'm afraid I have to say something unpopular though.  The IESG process
requires that at least one AD vote yes on a document meaning that they
have read the document, believe it as good stuff and are willing to
advocate it within the IESG.  In addition, the shepherd for a document
is expected to vote yes on that document.

I cannot vote yes on cram-md5 as a standard-track specification.  It
provides no channel bindings to TLS and provides no integrity
mechanism of its own.  It is weaker at dealing with MITM attacks than
digest-md5.

People will ask why I'm supporting plain given these concerns with
cram-md5.  Plain is absolutely necessary because of environments like
deployed AAA infrastructures, PAM, etc where only plaintext passwords
can be verified.  Also, I think people understand the risks of
plaintext passwords better than the cram-md5 style of mechanism.

I could sponsor a version of cram-md5 at informational or historic.

--Sam