Subject: Re: SASL WG session at IETF67
From: Tom Yu <[email-masked]>
To: [email-masked]
Date: Mon, 18 Sep 2006 09:20:18 -0400
List-Id: <ietf-sasl.imc.org>

I have also added IPR and BTNS as first-priority conflicts.  Please
respond if you think any other additional conflicts should be listed.
The deadline is 17:00 US/Eastern time.  The current list is:

Conflicts to Avoid:	

First Priority:	 krb-wg pkix saag tls apparea imapext eap sieve kitten lemonade calsify emu ipr btns
Second Priority:	 dkim

Other WGs that included sasl in their conflict lists:	sieve, msec, lemonade, capwap, isms, kitten, btns, dkim, emu

Date: Sat, 16 Sep 2006 00:47:03 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Sender: [email-masked]

My review comments are below. Some of them you probably already 
addressed and some of them are nitpicking.

 >4.1.  SASL Tokens
 >
 >   All top-level SASL packets for the GS2 mechanism family follow the
 >   following format:

I would suggest avoid using the term SASL packet, as it usually refers to
SASL security layer. Something like "SASL authentication exchange packets"
would be better here.

 >4.2.  Context Token

[...]

 >   The client calls GSS_Init_sec_context, passing in
 >   input_context_handle of 0 (initially), mech_type of the GSSAPI
 >   mechanism for which this SASL mechanism is registered, the
 >   chan_binding is set to NULL, and targ_name equal to output_name from
 >   GSS_Import_Name called with input_name_type of
 >   GSS_C_NT_HOSTBASED_SERVICE and input_name_string of

The GS1 has the note marker (*) after the "GSS_C_NT_HOSTBASED_SERVICE",
the note reads:

   (*) - Clients MAY use name types other than
   GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but
   only when they have a priori knowledge that the servers support
   alternate name types.  Otherwise clients MUST use
   GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names.

This is to address recent Nico's proposal to allow for domain based names.

[...]

 >   If the client will be requesting a security
 >   layer, it MUST also supply to the GSS_Init_sec_context a
 >   mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
 >   integ_req_flag of TRUE.  If the client will be requesting a security
 >   layer providing confidentiality protection, it MUST also supply to
 >   the GSS_Init_sec_context a conf_req_flag of TRUE.

This text got replaced with the following in GS1:

   When calling the GSS_Init_sec_context the client
   MUST pass the integ_req_flag of TRUE.  If the client will be
   requesting a security layer, it MUST also supply to the
   GSS_Init_sec_context a mutual_req_flag of TRUE, and a
   sequence_req_flag of TRUE.  If the client will be requesting a
   security layer providing confidentiality protection, it MUST also
   supply to the GSS_Init_sec_context a conf_req_flag of TRUE.

 >   If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
 >   expect the server to issue a token in a subsequent challenge or as
 >   additional information to the outcome of the authentication.

I suggest adding before this sentence (as in GS1):

   The client then responds with the resulting output_token.

otherwise it is not clear what happens to the generated token.

[...]

 >   The server passes the first client response to GSS_Accept_sec_context

I suggest s/first/initial, as "initial client response" is a SASL term.

 >   as input_token, setting input_context_handle to 0 (initially),
 >   mech_type of the GSSAPI mechanism for which this SASL mechanism is
 >   registered,

Delete description of the mech_type parameter, as it is an output parameter
of GSS_Accept_sec_context.

 > the chan_binding set to NULL, and acceptor_cred_handle
 >   equal to output_cred_handle from GSS_Acquire_cred called with
 >   desired_name equal to output_name from GSS_Import_name with
 >   input_name_type of GSS_C_NT_HOSTBASED_SERVICE and input_name_string
 >   of "service@hostname" where "service" is the service name specified
 >   in the protocol's profile, and "hostname" is the fully qualified host
 >   name of the server.

The text about acceptor_cred_handle got replaced with the following in GS1:

   and a suitable acceptor_cred_handle (see below).

and later:

   Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
   or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
   GSS-API mechanism for which this SASL mechanism is registered (*). 
Servers MAY use
   GSS_C_NO_CREDENTIAL as an acceptor credential handle.  Servers MAY
   use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred
   for the server's principal name(s) (**) and the
   GSS-API mechanism for which this SASL mechanism is registered.

   (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
   GSS-API mechanism as an input parameter.  The OID set can be created
   by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member.  It can
   be freed by calling the GSS_Release_oid_set.

   (**) - Use of server's principal names having
   GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
   where "service" is the service name specified in the protocol's
   profile, is RECOMMENDED.

   Upon successful establishment of the security context (i.e.
   GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
   verify that the negotiated GSS-API mechanism is indeed the registered
   one.  This is done by examining the value of the mech_type
   parameter returned from the GSS_Accept_sec_context call.  If the
   value differ SASL authentication MUST be aborted.

(I've edited the text not to reference Kerberos)

And the text quoted above is followed by additional text which is not 
currently in GS2:

   Upon successful establishment of the security context and if the
   server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
   credential handle, the server SHOULD also check using the
   GSS_Inquire_context that the target_name used by the client matches:

   -  the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
      where "service" is the service name specified in the application
      protocol's profile.

   When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
   examines the context to ensure that it provides a level of protection
   permitted by the server's security policy.  In particular, if the
   integ_avail flag is not set in the context, then no security layer
   can be offered or accepted.  If the conf_avail flag is not set in the
   context, then no security layer with confidentiality can be offered
   or accepted.

 >4.3.  Wrap Token

[...]
 >   The entity that sends its first Wrap token will have to specify a
 >   bitmap of supported and preferred quality of protection schemes.  The
 >   entity that reply to the Wrap tokens will pick a scheme, based on the

typo: replies

 >   bitmask and local policy.

 >   Four input formats to the GSS_Wrap function are defined.

This is confusing. Maybe "two pairs of input formats"?

 >  The first
 >   two input formats are used when the client sends the GSS_Wrap token
 >   first and the server reponds.  The other two input formats are used

typo: responds

 >   when the server sends the GSS_Wrap token first and the client
 >   responds.

 >4.3.1.  GSS_Wrap input for client requests

Here and in other 4.3.* sections: using SASL terms, the client sends 
"responses", while the server sends "challenges".

[...]

 >   The "client_maxbuf" field indicate the maximum protected buffer size

 ... in network byte order

 >   the client can receive.

 >4.3.2.  GSS_Wrap input for server responses

 [...]
 >   The "server_qop" field integer indicate the selected quality of
 >   protection.

I suggest to add:

  It must be one of the values specified by the client in 
"client_qops"/"client_cbqops"

And similar text for "client_qop" in 4.3.4.

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

typo: do not

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

missing word "and"?

 >   NULL.

 >6.  Protocol Overview

 [...]

 >   Because GSS-API authentication is initiated by the client, the length
 >   field will be 0 in the initial token from the server to the client
 >   when the protocol profile do not support additional information to be

typo: does not

 >   sent together with the authentication request.

You might want to add the following to section 9:

   When decoding any received data with GSS_Unwrap the major_status
   other than the GSS_S_COMPLETE MUST be treated as a fatal error.

 >9.1.  Examples

 [...]

 >   When integrity is negotiated the octet will encode an integer 4 as

I think you meant "confidentiality" here.

 >   follows.
 >
 >       0 1 2 3 4 5 6 7
 >      +-+-+-+-+-+-+-+-+
 >      |0|0|0|0|0|0|1|1|
 >      +-+-+-+-+-+-+-+-+

And the example doesn't match the description above, it shows the value 
3 (no layer + integrity)

 >12.  IANA Considerations
 >
 >   The IANA is advised that SASL mechanism names starting with "GS2-"
 >   are reserved for SASL mechanisms which conform to this document.  The
 >   IANA is directed to place a statement to that effect in the sasl-
 >   mechanisms registry.
 >
 >     Subject: Registration of SASL mechanism GS2-*
 >     Family of SASL mechanisms: YES

I think Kurt took out this line from the IANA registration template in 
RFC 4422.

 >     SASL mechanism prefix: GS2-

Date: Wed, 13 Sep 2006 16:44:00 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Mail-Followup-To: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Sep 13, 2006 at 05:08:38PM -0400, Sam Hartman wrote:
> Hmm.  Do you want to actually length count everything in both teh
> client and server messages so you can have extensibility in the
> future?

Good point.  I think all that would be required would be to add a length
of authzid field to the wrap token data, and standard MUST NOT send/MUST
ignore text.

Nico
-- 

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Date: Wed, 13 Sep 2006 17:08:38 -0400
Sender: [email-masked]

Hmm.  Do you want to actually length count everything in both teh
client and server messages so you can have extensibility in the
future?

From: Sam Hartman <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Tom Yu <[email-masked]>, [email-masked]
Subject: Re: SASL WG session at IETF67
Date: Wed, 13 Sep 2006 17:05:06 -0400
Sender: [email-masked]

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

    Jeffrey> On Wednesday, September 13, 2006 10:39:47 AM +0100 Alexey
    Jeffrey> Melnikov
    Jeffrey> <[email-masked]> wrote:

    >>  Tom Yu wrote:
    >>> I've added emu and calsify to the first-priority conflicts
    >>> list.  I've noticed that msec, capwap, and btns list us in
    >>> their conflict lists.  Do people think we should reciprocate
    >>> those conflicts?
    >>> 
    >>> 
    >> Maybe as second-priority conflicts?

    Jeffrey> I consider BTNS a pretty significant conflict.

At some level, you don't need to worry about BTNS and SASL happening
at the same time.
I will be at both of them:-)

--Sam

Date: Wed, 13 Sep 2006 13:07:23 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Tom Yu <[email-masked]>
cc: [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: SASL WG session at IETF67
Originator-Info: login-token=Mulberry:01MdSvoJs8JBR9HychZFLfD8hG5su4CCieSd0FZ1Q=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, September 13, 2006 10:39:47 AM +0100 Alexey Melnikov 
<[email-masked]> wrote:

>
> Tom Yu wrote:
>
>> I've added emu and calsify to the first-priority conflicts list.  I've
>> noticed that msec, capwap, and btns list us in their conflict lists.
>> Do people think we should reciprocate those conflicts?
>>
>>
> Maybe as second-priority conflicts?

I consider BTNS a pretty significant conflict.

Date: Wed, 13 Sep 2006 10:39:47 +0100
From: Alexey Melnikov <[email-masked]>
To: Tom Yu <[email-masked]>
CC: [email-masked]
Subject: Re: SASL WG session at IETF67
Sender: [email-masked]

Tom Yu wrote:

>I've added emu and calsify to the first-priority conflicts list.  I've
>noticed that msec, capwap, and btns list us in their conflict lists.
>Do people think we should reciprocate those conflicts?
>  
>
Maybe as second-priority conflicts?

To: [email-masked]
Subject: Re: SASL WG session at IETF67
From: Tom Yu <[email-masked]>
Date: Tue, 12 Sep 2006 19:59:50 -0400
Lines: 5
Sender: [email-masked]

I've added emu and calsify to the first-priority conflicts list.  I've
noticed that msec, capwap, and btns list us in their conflict lists.
Do people think we should reciprocate those conflicts?

---Tom

Date: Mon, 11 Sep 2006 14:15:14 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Nicolas Williams <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: gs2 and qop
Sender: [email-masked]

Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
>  
>
>>Nicolas Williams wrote:
>>    
>>
>>>If we allow use of GSS-API mechanisms that don't offer integrity
>>>protection then:
>>>
>>>a) GS2 has to be modified so the client sends the authzid without
>>>  wrapping;
>>>      
>>>
>>Why does this matter?
>>    
>>
>
>Mechanisms that doesn't provide integrity likely won't support the
>GSS_Wrap function.
>
>If integ_avail isn't set, GS2 would have to use another token to
>transfer the authorization identity, it can't use GSS_Wrap.  The
>maxbuf, channel binding and SASL qop fields are not relevant in this
>case, leaving only the authorization identity.
>  
>
Thanks for the clarification. This make sense.

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: gs2 and qop
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 11 Sep 2006 13:44:42 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Nicolas Williams wrote:
>
>>If we allow use of GSS-API mechanisms that don't offer integrity
>>protection then:
>>
>>a) GS2 has to be modified so the client sends the authzid without
>>   wrapping;
>>  
>>
> Why does this matter?

Mechanisms that doesn't provide integrity likely won't support the
GSS_Wrap function.

If integ_avail isn't set, GS2 would have to use another token to
transfer the authorization identity, it can't use GSS_Wrap.  The
maxbuf, channel binding and SASL qop fields are not relevant in this
case, leaving only the authorization identity.

/Simon

Date: Fri, 08 Sep 2006 13:45:53 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: gs2 and qop
Sender: [email-masked]

Nicolas Williams wrote:

>If we allow use of GSS-API mechanisms that don't offer integrity
>protection then:
>
>a) GS2 has to be modified so the client sends the authzid without
>   wrapping;
>  
>
Why does this matter?

Date: Fri, 8 Sep 2006 10:44:12 -0400 (EDT)
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: Simon Josefsson <[email-masked]>, Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, <[email-masked]>
Subject: Re: gs2 and qop
Sender: [email-masked]

On Fri, 8 Sep 2006, Sam Hartman wrote:

> I don't expect there to be any authentication only gss mechanisms on
> the standards track either.
>
> But there are mechanisms not on the standards track.  And my point is
> that as an individual I want a standards track solution for using any
> gss mechanisms as sasl mechanisms--even if those mechanisms are not on
> the standards track themselves.

Right.  We know from people like Martin Rex that there are a wide variety
of GSS mechanisms out there that most of us have never seen.  We also know
that some of the vendors of these mechansims go to some effort to make
sure they are usable with SAP, which suggests there are people out there
who have them deployed.

It would be rather ironic if some sites could use their chosen
authentication infrastructure with SAP but not IMAP, SMTP, or LDAP.

-- Jeff

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: gs2 and qop
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 08 Sep 2006 15:57:22 +0200
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

> But there are mechanisms not on the standards track.  And my point is
> that as an individual I want a standards track solution for using any
> gss mechanisms as sasl mechanisms--even if those mechanisms are not on
> the standards track themselves.

Sounds reasonable.  Since this opinion appears to be the consensus
among those who have spoken so far, I'll try to incorporate this.

/Simon

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: gs2 and qop
Date: Fri, 08 Sep 2006 09:10:54 -0400
Sender: [email-masked]

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

    Simon> I don't understand why an authentication-only GS2 mechanism
    Simon> is any better than a "pure" SASL authentication-only
    Simon> mechanism.

It isn't but we want people to write gss mechanisms not sasl
mechanisms.  So, we'd like gss to be a superset of the functionality.
And we'd like all gss mechanisms to be sasl mechanisms.

    Simon> A simple question that may illustrate the situation: Will
    Simon> there ever by any more authentication-only SASL mechanisms
    Simon> on the standards track?

I hope not.

    Simon> If the answer is no, I'd argue that they shouldn't be
    Simon> permitted to be specified through GS2 either.

I don't expect there to be any authentication only gss mechanisms on
the standards track either.

But there are mechanisms not on the standards track.  And my point is
that as an individual I want a standards track solution for using any
gss mechanisms as sasl mechanisms--even if those mechanisms are not on
the standards track themselves.

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Sam Hartman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: gs2 and qop
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 08 Sep 2006 11:27:06 +0200
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

>>> My opinion is yes, but that's an individual, not as an AD.
>
>> I take no position on whether GS2 should support GSS-API mechanisms that
>> cannot provide integrity protection.  Though I can probably be convinced
>> that it should.
>
> I believe that it should.  We have a tradition in SASL of supporting
> "authentication-only" mechanisms, some of which are widely deployed in
> configurations where integrity protection and confidentiality are
> provided at another layer.

Remember that this tradition have stopped, and appear to be actively
discouraged.

CRAM-MD5 is an example of such a mechanism.  CRAM-MD5 is not permitted
to enter the standards track, because (according to Sam) it doesn't
support integrity layers or channel bindings.  Any authentication-only
GS2 mechanisms will have the same problem.

I don't understand why an authentication-only GS2 mechanism is any
better than a "pure" SASL authentication-only mechanism.

A simple question that may illustrate the situation: Will there ever
by any more authentication-only SASL mechanisms on the standards
track?

If the answer is no, I'd argue that they shouldn't be permitted to be
specified through GS2 either.

Sam said yes to authentication-only GS2 mechanisms as individual,
perhaps we should solicit his opinion as AD.  I wouldn't want an IESG
member to say no to GS2 because it enables authentication-only
mechanisms on the Internet.

One consequence of support for authentication-only GS2 mechanisms: by
defining a CRAM-MD5 GSS-API mechanism, that would allow CRAM-MD5 to
continue to be used as a Standards Track protocol.  That seems counter
to the goal of refusing CRAM-MD5 to enter the standards track.

/Simon

Date: Thu, 07 Sep 2006 14:37:57 -0400
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Jeffrey Hutzelman <[email-masked]>
CC: Nicolas Williams <[email-masked]>, Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: gs2 and qop
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Jeffrey Hutzelman wrote:
> 
> 
> 
> On Thursday, September 07, 2006 12:12:55 PM -0500 Nicolas Williams
> <[email-masked]> wrote:
> 
>>
>> On Thu, Sep 07, 2006 at 12:07:01PM -0400, Sam Hartman wrote:
>>>
>>> >>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>>>
>>>     Simon> Is the consensus that GS2 should support GSS-API mechanisms
>>>     Simon> that doesn't offer integrity protection?
>>>
>>> My opinion is yes, but that's an individual, not as an AD.
> 
>> I take no position on whether GS2 should support GSS-API mechanisms that
>> cannot provide integrity protection.  Though I can probably be convinced
>> that it should.
> 
> I believe that it should.  We have a tradition in SASL of supporting
> "authentication-only" mechanisms, some of which are widely deployed in
> configurations where integrity protection and confidentiality are
> provided at another layer.  To the extent that GSS mechanisms with those
> properties exist, IMHO it would be a mistake not to allow their use in
> SASL.
> 
> -- Jeff

I concur.

Jeffrey Altman

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

--------------ms050706000309060307090108--

Date: Thu, 07 Sep 2006 13:23:22 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Sam Hartman <[email-masked]>
cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: gs2 and qop
Originator-Info: login-token=Mulberry:01jez9BPdUcnjZN3WFwGotcyReNC8UIHb6YStpw2w=; token_authority=[email-masked]
Sender: [email-masked]

On Thursday, September 07, 2006 12:12:55 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>
> On Thu, Sep 07, 2006 at 12:07:01PM -0400, Sam Hartman wrote:
>>
>> >>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>>
>>     Simon> Is the consensus that GS2 should support GSS-API mechanisms
>>     Simon> that doesn't offer integrity protection?
>>
>> My opinion is yes, but that's an individual, not as an AD.

> I take no position on whether GS2 should support GSS-API mechanisms that
> cannot provide integrity protection.  Though I can probably be convinced
> that it should.

I believe that it should.  We have a tradition in SASL of supporting 
"authentication-only" mechanisms, some of which are widely deployed in 
configurations where integrity protection and confidentiality are provided 
at another layer.  To the extent that GSS mechanisms with those properties 
exist, IMHO it would be a mistake not to allow their use in SASL.

-- Jeff

Date: Thu, 7 Sep 2006 12:12:55 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: gs2 and qop
Mail-Followup-To: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Sep 07, 2006 at 12:07:01PM -0400, Sam Hartman wrote:
> 
> >>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
> 
>     Simon> Is the consensus that GS2 should support GSS-API mechanisms
>     Simon> that doesn't offer integrity protection?
> 
> My opinion is yes, but that's an individual, not as an AD.

Jeff Hutzelman and I worked out the implications of this off-line just
now.

If we allow use of GSS-API mechanisms that don't offer integrity
protection then:

a) GS2 has to be modified so the client sends the authzid without
   wrapping;

b) SASL applications must be able to inquire which GS2 mechanisms offer
   integrity protection so they can avoid negotiating a mechanism that
   cannot provide what they want;

c) GSS mechs that can provide integ prot but fail to provide it for a
   given security context are a problem -- GS2 should fail
   authentication for such mechanisms when the security context fails to
   provide integrity protection and either the application wanted a
   security layer or wanted channel binding.

I take no position on whether GS2 should support GSS-API mechanisms that
cannot provide integrity protection.  Though I can probably be convinced
that it should.

Nico
-- 

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: gs2 and qop
Date: Thu, 07 Sep 2006 12:07:01 -0400
Sender: [email-masked]

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

    Simon> Is the consensus that GS2 should support GSS-API mechanisms
    Simon> that doesn't offer integrity protection?

My opinion is yes, but that's an individual, not as an AD.

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: gs2 and qop
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 07 Sep 2006 17:41:05 +0200
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>     >> Are you talking about gss-api level qop or sasl security
>     >> layers?
>
>     Simon> SASL security layers.
>
> I skip your answers to the rest of my questions because they assumed
> you meant GSS QOP.
>
> I'm failing to see the downgrade attack here though: if integ_avail is
> false, you don't negotiate security layers.
> Provided you enforce that what is the downgrade issue.

GS2 doesn't enforce that right now.  Instead, GS2 would fail the
authentication, because the integ_avail flag was not set.  I suppose
that GS2 could accept this situation and continue.  This would be
insecure: the authorization identity is not integrity protected.  I
wouldn't want to see wide use of a mechanism that has such an obvious
security problem.  However, the SASL framework permits this.

Is the consensus that GS2 should support GSS-API mechanisms that
doesn't offer integrity protection?

If so, the document should also say that channel bindings MUST NOT be
negotiated when integ_avail is false, because the channel bindings in
that situation would also not integrity protected.

> Some editorial comments on the draft:
>
> In your examples you do separate parts of packets input to gss_wrap
> with ,.  I'd suggest |.
>
> You never clearly define that the qop values you talk about correspond
> to the security layer stuff in section 9.

Thanks, the updated document should address this.

/Simon

Date: Thu, 7 Sep 2006 10:31:35 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Sam Hartman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: gs2 and qop
Mail-Followup-To: Simon Josefsson <[email-masked]>, Sam Hartman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Sep 07, 2006 at 04:33:21PM +0200, Simon Josefsson wrote:
> Sam Hartman <[email-masked]> writes:
> > Why do you negotiate qop?
> 
> All SASL mechanisms that support security layers negotiate qop,
> including GSSAPI and DIGEST-MD5.  Further, GS2 can use channel
> bindings to avoid another security layer, so it actually negotiates
> two qop's; one qop if the channel binding succeeds and another qop if
> the channel binding does not succeed.

"QoP" may mean different things here in the contexts of SASL and the
GSS-API.  In the SASL context it seems to be synonymous with "security
layer."  Whereas in the GSS-API context it means something much more
akin to SASL's "SSF" (but not quite).

GS2 does NOT negotiate GSS-API QoPs -- it should always use the default
GSS-API QoP (0).

Nico
-- 

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: gs2 and qop
Date: Thu, 07 Sep 2006 10:53:23 -0400
Sender: [email-masked]

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

    >> Are you talking about gss-api level qop or sasl security
    >> layers?

    Simon> SASL security layers.

I skip your answers to the rest of my questions because they assumed
you meant GSS QOP.

I'm failing to see the downgrade attack here though: if integ_avail is
false, you don't negotiate security layers.
Provided you enforce that what is the downgrade issue.

Some editorial comments on the draft:

In your examples you do separate parts of packets input to gss_wrap
with ,.  I'd suggest |.

You never clearly define that the qop values you talk about correspond
to the security layer stuff in section 9.

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: gs2 and qop
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 07 Sep 2006 16:33:21 +0200
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>     Simon> Sam Hartman <[email-masked]> writes:
>     >> So, this is a bit complicated and perhaps the best thing is to
>     >> decide that we just don't care about mechansims without
>     >> integ_avail.
>
>     Simon> For GS2, there is a downgrade attack of the quality of
>     Simon> protection (at the SASL level) if the GSS-API mechanism
>     Simon> doesn't provide integrity of GSS_Wrap tokens.  In general,
>     Simon> that's probably not acceptable.
>
>
> I clearly have not been paying enough attention to gs2.

In WGLC now:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-02.txt

The next version, and some other stuff is available from:

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

> Are you talking about gss-api level qop or sasl security layers?

SASL security layers.

> Why do you negotiate qop?

All SASL mechanisms that support security layers negotiate qop,
including GSSAPI and DIGEST-MD5.  Further, GS2 can use channel
bindings to avoid another security layer, so it actually negotiates
two qop's; one qop if the channel binding succeeds and another qop if
the channel binding does not succeed.

> Is that safe to do?

If GSS_Wrap provides integrity, yes.

> I thought qop values were implementation local.

I don't follow.

Btw, this isn't GS2 specific, it affects GSSAPI too, since GSSAPI also
uses GSS_Wrap to protect the qop negotiation.

/Simon

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: gs2 and qop
Date: Thu, 07 Sep 2006 10:21:33 -0400
Sender: [email-masked]

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

    Simon> Sam Hartman <[email-masked]> writes:
    >> So, this is a bit complicated and perhaps the best thing is to
    >> decide that we just don't care about mechansims without
    >> integ_avail.

    Simon> For GS2, there is a downgrade attack of the quality of
    Simon> protection (at the SASL level) if the GSS-API mechanism
    Simon> doesn't provide integrity of GSS_Wrap tokens.  In general,
    Simon> that's probably not acceptable.

I clearly have not been paying enough attention to gs2.

Are you talking about gss-api level qop or sasl security layers?

Why do you negotiate qop?
Is that safe to do?
I thought qop values were implementation local.

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 07 Sep 2006 16:00:08 +0200
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

> So, this is a bit complicated and perhaps the best thing is to decide
> that we just don't care about mechansims without integ_avail.

For GS2, there is a downgrade attack of the quality of protection (at
the SASL level) if the GSS-API mechanism doesn't provide integrity of
GSS_Wrap tokens.  In general, that's probably not acceptable.

However, if a particular GSS-API mechanism doesn't provide integrity,
perhaps the security problems in having GS2 support it anyway, with
the obvious weakness of an downgrade attack, is acceptable?  Thoughts
on this?

> RFC 4422 only requires us to integrity protect the security layer
> exchange if the underlying mechanism has integrity protection.  It is
> quite clear that we cannot do channel binding exchange without
> integrity protection.

Right.

> I'm assuming that gssapi mechanisms protect their negotiation enough
> that if integrity is requested that the mechanism prevents downgrade
> attacks and either gives you integrity or only fails to give you
> integrity if one end doesn't support it or required credentials are
> missing.  If you are concerned that is not actually required by 2743
> I'd be happy to see if we can get kitten to specify that.

It may be a good thing to do, but it doesn't seem directly relevant to
this.  The downgrade attack I talk about above is at the SASL level,
not at the GSS-API level.

> I don't think it makes any sense at all to return prot_ready without
> integrity being available so aborting if somehow you get prot_ready
> but later not integ_avail seems fine.

Right.

> (Alternatively we could require that integ_avail is set at the same
> time as prot_ready)

That would be up to Kitten, I suppose.

> The only important thing seems to be not to negotiate a security layer
> or pass channel bindings if integ_avail is not set.

For GS2, it may be as important to not succeed the authentication if
integ_avail is not set.

/Simon

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Date: Thu, 07 Sep 2006 09:30:40 -0400
Sender: [email-masked]

So, this is a bit complicated and perhaps the best thing is to decide
that we just don't care about mechansims without integ_avail.

RFC 4422 only requires us to integrity protect the security layer
exchange if the underlying mechanism has integrity protection.  It is
quite clear that we cannot do channel binding exchange without
integrity protection.

I'm assuming that gssapi mechanisms protect their negotiation enough
that if integrity is requested that the mechanism prevents downgrade
attacks and either gives you integrity or only fails to give you
integrity if one end doesn't support it or required credentials are
missing.  If you are concerned that is not actually required by 2743
I'd be happy to see if we can get kitten to specify that.

I don't think it makes any sense at all to return prot_ready without
integrity being available so aborting if somehow you get prot_ready
but later not integ_avail seems fine.  (Alternatively we could require
that integ_avail is set at the same time as prot_ready)

The only important thing seems to be not to negotiate a security layer
or pass channel bindings if integ_avail is not set.

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 07 Sep 2006 14:20:05 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Sep 06, 2006 at 02:41:45PM +0100, Alexey Melnikov wrote:
>> Nicolas Williams wrote:
>> >I see no value in the server verifying that client_maxbuf == 0 when the
>> >client doesn't ask for any security layers.
>> >
>> >Also, even with no security layers the application may benefit from the
>> >SASL mechanism maxbuf negotiation (again, think of small devices).
>> > 
>> >
>> No, when there is no SASL security layer there is no SASL framing. And 
>> SASL maxbuf has no effect on TCP.
>
> I was hoping that the maxbuf value would be of use to applications that
> want no security layers.  That if an application does the equivalent of,
> in Cyrus SASL terms,
>
> 	unsigned int len = 4096;
> 	...
> 	/*
> 	 * Note: Cyrus SASL doesn't allow setting this property, only
> 	 * getting it
> 	 */
> 	sasl_setprop(..., SASL_MAXOUTBUF, &len);
>
> then its peers might want to know, even when using no security layers.
>
> But I see now that this is really not quite a good thing, that the
> application ought to negotiate this on its own.

Right.

> So I withdraw that comment, but I still see no value to the client or
> server verifying that server_maxbuff == 0 or client_maxbuf == 0 when no
> security layers are offered/requested.

If the value isn't forced to be 0 when the value isn't used by the
protocol, there is a side channel that can be used to transfer data
in.  That's a minor issue, though..

/Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 07 Sep 2006 14:01:37 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Simon Josefsson wrote:
>
>>Alexey Melnikov <[email-masked]> writes:
>>  
>>
>>>After the followup conversation with Sam he convinced me that this is
>>>the right thing.
>>>
>>>OLD text:
>>>  If the client will be requesting a security
>>>  layer, it MUST also supply to the GSS_Init_sec_context a
>>>  mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
>>>  integ_req_flag of TRUE.  If the client will be requesting a security
>>>  layer providing confidentiality protection, it MUST also supply to
>>>  the GSS_Init_sec_context a conf_req_flag of TRUE.
>>>
>>>NEW text:
>>>
>>> When calling the GSS_Init_sec_context the client MUST
>>> pass the integ_req_flag of TRUE. If the client will be requesting a
>>>security
>>> layer, it MUST also supply to the GSS_Init_sec_context a
>>> mutual_req_flag of TRUE, and a sequence_req_flag of TRUE.
>>> If the client will be requesting a security
>>> layer providing confidentiality protection, it MUST also supply to the
>>> GSS_Init_sec_context a conf_req_flag of TRUE.
>>>    
>>>
>>
>>The same text is found in the GS2 document as well.  I have made the
>>same change in it, but I also added:
>>
>>   The client MUST verify that the requested flags become enabled in
>>   the context.
>>  
>>
> As per discussion between Jeff and Sam I've already added the
> following text to -08.
>
> When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
> examines the context to ensure that it provides a level of protection
> permitted by the server's security policy.
> In particular, if the integ_avail flag is not set in the context,
> then no security layer can be offered or accepted. If the conf_avail
> flag is not set in the context, then no security layer with
> confidentiality can be offered or accepted.
>
> (the first sentence was already in the document).
>
> And similar text in the client side section.

That work slightly different in GS2 because the GSS_Wrap token, with
the qop information, is sent before GSS_Accept_sec_context returns
GSS_S_COMPLETE.

On the other hand, the client/server can verify the returned flags
after the context has been set up, and if it turns out it cannot offer
security layers, it abort the authentication.  This is still possible.

> Jeff/Sam came to conclusion that checking for integ_avail is not
> needed, unless a SASL security layer is negotiated.
> They didn't request any text regarding other flags.
>
> Sam, can you post a digest of why this is the case?

This seems wrong to me -- the "GSSAPI" authentication requires that
the QOP is integrity protected by GSS_Wrap.  If the GSS context can't
provide integrity for GSS_Wrap, there is a downgrade attack on the
QOPs.

For GS2, the situation is worse, since GSS_Wrap protects the channel
binding, and you really want integrity protection of the channel
binding data.

/Simon

>>I suggest that the same, or similar, text is added to GS1.
>>
>>Without that text, it seems as if the mechanism could simply ignore
>>them, and (for the C bindings) that the RET_FLAGS variable indicate
>>that they were never negotiated.  That seems to be a fatal problem to
>>me.  Or am I missing something?
>>  
>>

Date: Wed, 6 Sep 2006 16:14:04 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Mail-Followup-To: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Sep 06, 2006 at 02:41:45PM +0100, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >I see no value in the server verifying that client_maxbuf == 0 when the
> >client doesn't ask for any security layers.
> >
> >Also, even with no security layers the application may benefit from the
> >SASL mechanism maxbuf negotiation (again, think of small devices).
> > 
> >
> No, when there is no SASL security layer there is no SASL framing. And 
> SASL maxbuf has no effect on TCP.

I was hoping that the maxbuf value would be of use to applications that
want no security layers.  That if an application does the equivalent of,
in Cyrus SASL terms,

	unsigned int len = 4096;
	...
	/*
	 * Note: Cyrus SASL doesn't allow setting this property, only
	 * getting it
	 */
	sasl_setprop(..., SASL_MAXOUTBUF, &len);

then its peers might want to know, even when using no security layers.

But I see now that this is really not quite a good thing, that the
application ought to negotiate this on its own.

So I withdraw that comment, but I still see no value to the client or
server verifying that server_maxbuff == 0 or client_maxbuf == 0 when no
security layers are offered/requested.

Nico
-- 

Date: Wed, 06 Sep 2006 19:37:57 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>, Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Sender: [email-masked]

Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
>  
>
>>After the followup conversation with Sam he convinced me that this is
>>the right thing.
>>
>>OLD text:
>>  If the client will be requesting a security
>>  layer, it MUST also supply to the GSS_Init_sec_context a
>>  mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
>>  integ_req_flag of TRUE.  If the client will be requesting a security
>>  layer providing confidentiality protection, it MUST also supply to
>>  the GSS_Init_sec_context a conf_req_flag of TRUE.
>>
>>NEW text:
>>
>> When calling the GSS_Init_sec_context the client MUST
>> pass the integ_req_flag of TRUE. If the client will be requesting a
>>security
>> layer, it MUST also supply to the GSS_Init_sec_context a
>> mutual_req_flag of TRUE, and a sequence_req_flag of TRUE.
>> If the client will be requesting a security
>> layer providing confidentiality protection, it MUST also supply to the
>> GSS_Init_sec_context a conf_req_flag of TRUE.
>>    
>>
>
>The same text is found in the GS2 document as well.  I have made the
>same change in it, but I also added:
>
>   The client MUST verify that the requested flags become enabled in
>   the context.
>  
>
As per discussion between Jeff and Sam I've already added the following 
text to -08.

When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
examines the context to ensure that it provides a level of protection
permitted by the server's security policy.
In particular, if the integ_avail flag is not set in the context,
then no security layer can be offered or accepted. If the conf_avail
flag is not set in the context, then no security layer with
confidentiality can be offered or accepted.

(the first sentence was already in the document).

And similar text in the client side section.

Jeff/Sam came to conclusion that checking for integ_avail is not needed, 
unless a SASL security layer is negotiated.
They didn't request any text regarding other flags.

Sam, can you post a digest of why this is the case?

>I suggest that the same, or similar, text is added to GS1.
>
>Without that text, it seems as if the mechanism could simply ignore
>them, and (for the C bindings) that the RET_FLAGS variable indicate
>that they were never negotiated.  That seems to be a fatal problem to
>me.  Or am I missing something?
>  
>

Date: Wed, 06 Sep 2006 14:41:45 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Sender: [email-masked]

Nicolas Williams wrote:

>On Wed, Sep 06, 2006 at 10:55:35AM +0200, Simon Josefsson wrote:
>  
>
>>For interoperability, I believe this problem should be noted, because
>>it may make it impossible to use a negotiated security layer.
>>
>>Can we use the following and move on?
>>
>>      <t>The "client_maxbuf" field indicate the maximum protected
>>	buffer size the client can receive.  It MUST be 0 if the
>>	client doesn't advertise support for any security layer, the
>>	server MUST verify this.  Small values can make it impossible
>>	for the server to send any protected message to the client,
>>	due to the overhead added by GSS_Wrap, and the server MAY
>>	reject the authentication if it detects this situation.</t>
>>    
>>
>s/, the server MUST verify this//
>
>I see no value in the server verifying that client_maxbuf == 0 when the
>client doesn't ask for any security layers.
>
>Also, even with no security layers the application may benefit from the
>SASL mechanism maxbuf negotiation (again, think of small devices).
>  
>
No, when there is no SASL security layer there is no SASL framing. And 
SASL maxbuf has no effect on TCP.

>So I think the entire second sentence should be removed.
>  
>

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 06 Sep 2006 15:39:39 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Simon Josefsson wrote:
>
>>Looking at specifications, RFC 2831 does not impose any limits on
>>maxbuf at all.  GSSAPI restricts maxbuf to be 0..0xFFFFFF because the
>>integer field is 3 bytes.  RFC 2831bis changes RFC 2831 and enforces
>>16 <= maxbuf <= 16777215.  I don't know where this minimum comes from?
>>  
>>
> Each SASL packet will have the 16byte long MAC.

>>      <t>The "client_maxbuf" field indicate the maximum protected
>>	buffer size the client can receive.  It MUST be 0 if the
>>	client doesn't advertise support for any security layer, the
>>	server MUST verify this.  Small values can make it impossible
>>	for the server to send any protected message to the client,
>>	due to the overhead added by GSS_Wrap, and the server MAY
>>	reject the authentication if it detects this situation.</t>
>>
>>      <t>The "server_maxbuf" field indicate the maximum protected data
>>	buffer size the server can receive.  It MUST be 0 if the
>>	server doesn't advertise support for any security layer, the
>>	client MUST verify this.  Small values can make it impossible
>>	for the client to send any protected message to the server,
>>	due to the overhead added by GSS_Wrap, and the client MAY
>>	reject the authentication if it detects this situation.</t>
>>  
>>
> That is fine by me. I would even change the last MAY to SHOULD.

Seems reasonable.  What do others think?

/Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 06 Sep 2006 15:32:47 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Sep 06, 2006 at 10:55:35AM +0200, Simon Josefsson wrote:
>> For interoperability, I believe this problem should be noted, because
>> it may make it impossible to use a negotiated security layer.
>> 
>> Can we use the following and move on?
>> 
>>       <t>The "client_maxbuf" field indicate the maximum protected
>> 	buffer size the client can receive.  It MUST be 0 if the
>> 	client doesn't advertise support for any security layer, the
>> 	server MUST verify this.  Small values can make it impossible
>> 	for the server to send any protected message to the client,
>> 	due to the overhead added by GSS_Wrap, and the server MAY
>> 	reject the authentication if it detects this situation.</t>
>
> s/, the server MUST verify this//
>
> I see no value in the server verifying that client_maxbuf == 0 when the
> client doesn't ask for any security layers.
>
> Also, even with no security layers the application may benefit from the
> SASL mechanism maxbuf negotiation (again, think of small devices).
>
> So I think the entire second sentence should be removed.

How is this the buffer size value relevant when there is no security
layer?  The value is not used in any way in that case, as far as I can
tell.

Note that GSSAPI -09 contains:

   client fails the negotiation.  The client verifies that the server
   maximum buffer is 0 if the server doesn't advertise support for any
   security layer.  The client then constructs data, with the first
...
   The server verifies that the client has selected a security layer
   that was offered, and that the client maximum buffer is 0 if no
   security layer was chosen.  The server must verify that the src_name

/Simon

Date: Wed, 6 Sep 2006 07:58:54 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Sep 06, 2006 at 10:55:35AM +0200, Simon Josefsson wrote:
> For interoperability, I believe this problem should be noted, because
> it may make it impossible to use a negotiated security layer.
> 
> Can we use the following and move on?
> 
>       <t>The "client_maxbuf" field indicate the maximum protected
> 	buffer size the client can receive.  It MUST be 0 if the
> 	client doesn't advertise support for any security layer, the
> 	server MUST verify this.  Small values can make it impossible
> 	for the server to send any protected message to the client,
> 	due to the overhead added by GSS_Wrap, and the server MAY
> 	reject the authentication if it detects this situation.</t>

s/, the server MUST verify this//

I see no value in the server verifying that client_maxbuf == 0 when the
client doesn't ask for any security layers.

Also, even with no security layers the application may benefit from the
SASL mechanism maxbuf negotiation (again, think of small devices).

So I think the entire second sentence should be removed.

>       <t>The "server_maxbuf" field indicate the maximum protected data
> 	buffer size the server can receive.  It MUST be 0 if the
> 	server doesn't advertise support for any security layer, the
> 	client MUST verify this.  Small values can make it impossible
> 	for the client to send any protected message to the server,
> 	due to the overhead added by GSS_Wrap, and the client MAY
> 	reject the authentication if it detects this situation.</t>

Same here.

Otherwise I'm happy.

Nico
-- 

Date: Wed, 06 Sep 2006 13:15:18 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Sender: [email-masked]

Simon Josefsson wrote:

>Looking at specifications, RFC 2831 does not impose any limits on
>maxbuf at all.  GSSAPI restricts maxbuf to be 0..0xFFFFFF because the
>integer field is 3 bytes.  RFC 2831bis changes RFC 2831 and enforces
>16 <= maxbuf <= 16777215.  I don't know where this minimum comes from?
>  
>
Each SASL packet will have the 16byte long MAC.

>There doesn't seem to be much consistency here.  The only consistent
>value is in GSSAPI and RFC 2831bis, where the upper limit is 2^24.
>That limit is not imposed by the core SASL specification, though,
>which has 2^32.
>
>For interoperability, I believe this problem should be noted, because
>it may make it impossible to use a negotiated security layer.
>  
>
Sure. Cyrus SASL had the check for minimum maxbuf for some time.

>Can we use the following and move on?
>
>      <t>The "client_maxbuf" field indicate the maximum protected
>	buffer size the client can receive.  It MUST be 0 if the
>	client doesn't advertise support for any security layer, the
>	server MUST verify this.  Small values can make it impossible
>	for the server to send any protected message to the client,
>	due to the overhead added by GSS_Wrap, and the server MAY
>	reject the authentication if it detects this situation.</t>
>
>      <t>The "server_maxbuf" field indicate the maximum protected data
>	buffer size the server can receive.  It MUST be 0 if the
>	server doesn't advertise support for any security layer, the
>	client MUST verify this.  Small values can make it impossible
>	for the client to send any protected message to the server,
>	due to the overhead added by GSS_Wrap, and the client MAY
>	reject the authentication if it detects this situation.</t>
>  
>
That is fine by me. I would even change the last MAY to SHOULD.

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 06 Sep 2006 10:55:35 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Sep 05, 2006 at 11:53:25AM +0200, Simon Josefsson wrote:
>> Right.  How about enforcing a minimum buffer size?  Is 256 bytes a
>> reasonable minimum value?
>
> Why start that with GS2?  I'd rather see the doc finished.
>
> I think, anyways, that this is a problem for SASL, not the mechanisms,
> and if the mechanisms all handle this in much the same way then that
> will make it easier for SASL to handle the problem.
>
> Please, let's not diverge from the other mechs w.r.t. maxbuf.
>
> Figuring out a good minimum has the look of a good rat hole.

RFC 4422 says this about security layers:

   Each buffer of protected data is transferred over the underlying
   transport connection as a sequence of octets prepended with a four-
   octet field in network byte order that represents the length of the
   buffer.  The length of the protected data buffer MUST be no larger
   than the maximum size that the other side expects.  Upon the receipt
   of a length field whose value is greater than the maximum size, the
   receiver SHOULD close the connection, as this might be a sign of an
   attack.

SASL is thus restricted to packets of size 2^32, so I withdraw my
request to be able to express "no limit".

Looking at specifications, RFC 2831 does not impose any limits on
maxbuf at all.  GSSAPI restricts maxbuf to be 0..0xFFFFFF because the
integer field is 3 bytes.  RFC 2831bis changes RFC 2831 and enforces
16 <= maxbuf <= 16777215.  I don't know where this minimum comes from?

There doesn't seem to be much consistency here.  The only consistent
value is in GSSAPI and RFC 2831bis, where the upper limit is 2^24.
That limit is not imposed by the core SASL specification, though,
which has 2^32.

For interoperability, I believe this problem should be noted, because
it may make it impossible to use a negotiated security layer.

Can we use the following and move on?

      <t>The "client_maxbuf" field indicate the maximum protected
	buffer size the client can receive.  It MUST be 0 if the
	client doesn't advertise support for any security layer, the
	server MUST verify this.  Small values can make it impossible
	for the server to send any protected message to the client,
	due to the overhead added by GSS_Wrap, and the server MAY
	reject the authentication if it detects this situation.</t>

      <t>The "server_maxbuf" field indicate the maximum protected data
	buffer size the server can receive.  It MUST be 0 if the
	server doesn't advertise support for any security layer, the
	client MUST verify this.  Small values can make it impossible
	for the client to send any protected message to the server,
	due to the overhead added by GSS_Wrap, and the client MAY
	reject the authentication if it detects this situation.</t>

/Simon

Date: Tue, 5 Sep 2006 15:02:49 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Text (Re: Proposed updates for domain-based drafts)
Mail-Followup-To: Alexey Melnikov <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Tue, Sep 05, 2006 at 08:24:43AM -0500, Nicolas Williams wrote:
> On Tue, Sep 05, 2006 at 12:39:10PM +0100, Alexey Melnikov wrote:
> > Nicolas Williams wrote:
> > I like the suggested changes, except for the last sentence quoted above. 
> > Here you are trying to put requirements on application protocols, which 
> > is probably Ok. But you are effectively declaring all existing 
> > application layer protocols non compliant with this MUST. Was this the 
> > intent?
> 
> Not at all -- existing apps don't know how to use domain-based names, so
> they will require updating anyways.  This is a requirement only for
> applications that wish to support the use of domain-based names.

Also, if your concern is about DIGEST-MD5 applications that use
serv-name then worry not: these drafts are specifically for GSS-API
applications, and clearly no SASL/GS1 applications have used
domain-based names in the past.

OT:  Now, about DIGEST-MD5's support for domain-based naming...  Are
there SASL applications that use this?  Does Cyrus SASL implement this?
Any other implementations?  Please answer off-list, or at least off the
KITTEN list, as this would be off-topic there.

To: [email-masked]
Subject: SASL WG session at IETF67
From: Tom Yu <[email-masked]>
Date: Tue, 05 Sep 2006 15:56:10 -0400
Lines: 60
Sender: [email-masked]

--=-=-=

Please respond if you think the session request below, particularly
the conflict list, needs adjustment.  The initial deadline for session
requests is Sep. 18th.

---Tom

--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
        [email-masked]
From: IETF Meeting Session Request Tool <[email-masked]>
Subject: sasl - New Meeting Session Request for IETF 67 
Date: Tue, 05 Sep 2006 15:28:19 -0400
Lines: 22

A new meeting session request has just been submitted
by Tom Yu, a working group chair of sasl.

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

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

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

Special Requests:
  
---------------------------------------------------------

--=-=-=--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-gssapi-08.txt 
Date: Tue, 05 Sep 2006 15:50:02 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: The Kerberos V5 ("GSSAPI") SASL mechanism
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sasl-gssapi-08.txt
	Pages		: 11
	Date		: 2006-9-5
	
The Simple Authentication and Security Layer (SASL, RFC 4422) is a
framework for adding authentication support to connection-based
protocols.  This document describes the method for using the Generic
Security Service Application Program Interface (GSS-API) Kerberos V5
in the SASL.

This document replaces section 7.2 of RFC 2222, the definition of the
"GSSAPI" SASL mechanism.

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 05 Sep 2006 15:00:23 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Text (Re: Proposed updates for domain-based drafts)
Originator-Info: login-token=Mulberry:01dJ2io94FFxfA6BokpxvSEgsP2c770RvhEtAIqh0=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, September 05, 2006 08:24:43 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

> On Tue, Sep 05, 2006 at 12:39:10PM +0100, Alexey Melnikov wrote:
>> Nicolas Williams wrote:
>> > +   For the purposes of domain-based names a "domain" is defined by the
>> > +   applications that use domain-based names.  An application protocol
>> > +   might use a simple DNS domainname, such as "example.com" for
>> > naming, +   while another it might use the DNS domainname of the SRV
>> > RRs it +   queries (e.g., "_tcp._foo.example.com"), and yet another
>> > may use +   something that does not resemble a DNS domainname.
>> > Application +   protocol specifications that provide for use of
>> > domain-based service +   names MUST define the domain-portion of their
>> > domain-based names.
>> >
>> >
>> I like the suggested changes, except for the last sentence quoted above.
>> Here you are trying to put requirements on application protocols, which
>> is probably Ok. But you are effectively declaring all existing
>> application layer protocols non compliant with this MUST. Was this the
>> intent?
>
> Not at all -- existing apps don't know how to use domain-based names, so
> they will require updating anyways.  This is a requirement only for
> applications that wish to support the use of domain-based names.

Right.  Just as an application which uses host-based service names needs to 
specify a service name, and application which uses domain-based names needs 
to specify both a service name and how to derive the "domain" component.

-- Jeff

Date: Tue, 5 Sep 2006 08:24:43 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Text (Re: Proposed updates for domain-based drafts)
Mail-Followup-To: Alexey Melnikov <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Tue, Sep 05, 2006 at 12:39:10PM +0100, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >+   For the purposes of domain-based names a "domain" is defined by the
> >+   applications that use domain-based names.  An application protocol
> >+   might use a simple DNS domainname, such as "example.com" for naming,
> >+   while another it might use the DNS domainname of the SRV RRs it
> >+   queries (e.g., "_tcp._foo.example.com"), and yet another may use
> >+   something that does not resemble a DNS domainname.  Application
> >+   protocol specifications that provide for use of domain-based service
> >+   names MUST define the domain-portion of their domain-based names.
> > 
> >
> I like the suggested changes, except for the last sentence quoted above. 
> Here you are trying to put requirements on application protocols, which 
> is probably Ok. But you are effectively declaring all existing 
> application layer protocols non compliant with this MUST. Was this the 
> intent?

Not at all -- existing apps don't know how to use domain-based names, so
they will require updating anyways.  This is a requirement only for
applications that wish to support the use of domain-based names.

Nico
-- 

Date: Tue, 5 Sep 2006 08:21:15 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Sep 05, 2006 at 11:53:25AM +0200, Simon Josefsson wrote:
> Right.  How about enforcing a minimum buffer size?  Is 256 bytes a
> reasonable minimum value?

Why start that with GS2?  I'd rather see the doc finished.

I think, anyways, that this is a problem for SASL, not the mechanisms,
and if the mechanisms all handle this in much the same way then that
will make it easier for SASL to handle the problem.

Please, let's not diverge from the other mechs w.r.t. maxbuf.

Figuring out a good minimum has the look of a good rat hole.

Nico
-- 

Date: Tue, 05 Sep 2006 09:10:59 -0400
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Alexey Melnikov <[email-masked]>
CC: Nicolas Williams <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Text (Re: Proposed updates for domain-based drafts)
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Alexey Melnikov wrote:
> Nicolas Williams wrote:
> 
>>    A domain-based name consists of three required elements:
>>
>>    o  a service name
>>
>>    o  a domain name
>>
>>    o  a hostname
>>
>> +   For the purposes of domain-based names a "domain" is defined by the
>> +   applications that use domain-based names.  An application protocol
>> +   might use a simple DNS domainname, such as "example.com" for naming,
>> +   while another it might use the DNS domainname of the SRV RRs it
>> +   queries (e.g., "_tcp._foo.example.com"), and yet another may use
>> +   something that does not resemble a DNS domainname.  Application
>> +   protocol specifications that provide for use of domain-based service
>> +   names MUST define the domain-portion of their domain-based names.
>>  
>>
> I like the suggested changes, except for the last sentence quoted above.
> Here you are trying to put requirements on application protocols, which
> is probably Ok. But you are effectively declaring all existing
> application layer protocols non compliant with this MUST. Was this the
> intent?

The way I read this is that the MUST does not apply to existing
application protocols because they do not "provide for the use of
domain-based service names".  Only new application protocols that
specify the use of domain-based service names will need to define what a
"domain" is for that application.

Jeffrey Altman

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

--------------ms050509090406060804050909--

Date: Tue, 05 Sep 2006 12:39:10 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Text (Re: Proposed updates for domain-based drafts)
Sender: [email-masked]

Nicolas Williams wrote:

>    A domain-based name consists of three required elements:
> 
>    o  a service name
> 
>    o  a domain name
> 
>    o  a hostname
> 
>+   For the purposes of domain-based names a "domain" is defined by the
>+   applications that use domain-based names.  An application protocol
>+   might use a simple DNS domainname, such as "example.com" for naming,
>+   while another it might use the DNS domainname of the SRV RRs it
>+   queries (e.g., "_tcp._foo.example.com"), and yet another may use
>+   something that does not resemble a DNS domainname.  Application
>+   protocol specifications that provide for use of domain-based service
>+   names MUST define the domain-portion of their domain-based names.
>  
>
I like the suggested changes, except for the last sentence quoted above. 
Here you are trying to put requirements on application protocols, which 
is probably Ok. But you are effectively declaring all existing 
application layer protocols non compliant with this MUST. Was this the 
intent?

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked], Sam Hartman <[email-masked]>
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 05 Sep 2006 13:13:39 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> After the followup conversation with Sam he convinced me that this is
> the right thing.
>
> OLD text:
>   If the client will be requesting a security
>   layer, it MUST also supply to the GSS_Init_sec_context a
>   mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
>   integ_req_flag of TRUE.  If the client will be requesting a security
>   layer providing confidentiality protection, it MUST also supply to
>   the GSS_Init_sec_context a conf_req_flag of TRUE.
>
> NEW text:
>
>  When calling the GSS_Init_sec_context the client MUST
>  pass the integ_req_flag of TRUE. If the client will be requesting a
> security
>  layer, it MUST also supply to the GSS_Init_sec_context a
>  mutual_req_flag of TRUE, and a sequence_req_flag of TRUE.
>  If the client will be requesting a security
>  layer providing confidentiality protection, it MUST also supply to the
>  GSS_Init_sec_context a conf_req_flag of TRUE.

The same text is found in the GS2 document as well.  I have made the
same change in it, but I also added:

   The client MUST verify that the requested flags become enabled in
   the context.

I suggest that the same, or similar, text is added to GS1.

Without that text, it seems as if the mechanism could simply ignore
them, and (for the C bindings) that the RET_FLAGS variable indicate
that they were never negotiated.  That seems to be a fatal problem to
me.  Or am I missing something?

/Simon

Date: Tue, 05 Sep 2006 11:44:09 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Sender: [email-masked]

Simon Josefsson wrote:

>>So the the third sentence above needs to be re-written.  I propose:
>>
>>   This mechanism family offers a number of improvements over the
>>   previous SASL/GSS-API mechanism family: it is more general, uses
>>   fewer messages for the authentication phase in some cases, and
>>   supports a SASL-specific notion of channel binding.
>>    
>>
>There is no previous SASL/GSS-API mechanism family (the "GSSAPI" mech
>isn't a mechanism family, in the RFC 4422 terminology), so I changed
>the abstract into:
>
>  <t>This document describes how to use a Generic Security Service
>    Application Program Interface (GSS-API) mechanism in the the
>    Simple Authentication and Security Layer (SASL) framework.  This
>    is done by defining a new SASL mechanism family, called GS2.  This
>    mechanism family offers a number of improvements over the previous
>    SASL/GSS-API mechanism: it is more general, uses fewer messages
>    for the authentication phase in some cases, and supports a
>    SASL-specific notion of channel binding.</t>
>  
>
This looks fine to me.

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 05 Sep 2006 12:16:40 +0200
Sender: [email-masked]

Simon Josefsson <[email-masked]> writes:

>>  - Section 4.2, the second paragraph is way too long and should be
>>    broken up (see my comments on SASL/GS1).
>
> I'll look into it.

I've tried to address this now, see:

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

Let me know if you can think of a way to improve it further.

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 05 Sep 2006 12:02:21 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Mon, Sep 04, 2006 at 06:35:47PM +0100, Alexey Melnikov wrote:
>> Simon Josefsson wrote:
>> >Nicolas Williams <[email-masked]> writes:
>> > <t>This document describes how to use a Generic Security Service
>> >   Application Program Interface (GSS-API) mechanism in the the
>> >   Simple Authentication and Security Layer (SASL) framework.  This
>> >   is done by defining a new SASL mechanism family, called GS2.  The
>> >   mechanism family uses the SASL mechanism negotiation to select the
>> >   GSS-API mechanism, offers reduced number of round-trips over the
>> >   earlier Kerberos V5-specific "GSS-API"
>> >
>> If you are referencing the GS1, why do you have "-"? If not, why is it 
>> quoted?
>
> Yeah, be very carefule with "GSSAPI" vs. "GSS-API" -- in the context of
> SASL the first means "the mistake that was made years ago when the name
> given the SASL mechanism corresponding to the GSS-API Kerberos V
> mechanism was "GSSAPI" and the latter means _the_ GSS-API (as in
> RFC2743).

The intention was to avoid confusion by spelling out "Kerberos
V5-specific" explicitly, but it seems that it didn't succeed.

> Also, there is no SASL mechanism negotiation as such -- SASL
> applications negotiate mechanisms on an ad-hoc basis (each app protocol
> specifies its own negotiations, usually based on the server listing its
> available mechanisms to the client prior to starting SASL).

Right.

> So the the third sentence above needs to be re-written.  I propose:
>
>    This mechanism family offers a number of improvements over the
>    previous SASL/GSS-API mechanism family: it is more general, uses
>    fewer messages for the authentication phase in some cases, and
>    supports a SASL-specific notion of channel binding.

There is no previous SASL/GSS-API mechanism family (the "GSSAPI" mech
isn't a mechanism family, in the RFC 4422 terminology), so I changed
the abstract into:

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

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 05 Sep 2006 11:53:25 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Nicolas Williams wrote:
>
>>On Mon, Sep 04, 2006 at 04:37:26PM +0100, Alexey Melnikov wrote:
>>  
>>
>>>Simon Josefsson wrote:
>>>    
>>>
>>>>A maxbuf value of 0 has weird semantics -- it is a error-state, and
>>>>authentication using a maxbuf=0 value with security layers should not
>>>>succeed.
>>>>      
>>>>
>>>Yes. (So is maxbuf=1)
>>>    
>>>
>>
>>Good point!  So is maxbuf == 2, or any impractically small value.
>>  
>>
> Exactly.
>
>>Is this an error state for the framework or for the application?  I say
>>the latter.
>>  
>>
> It is an error case for a specific SASL mechanism.

Right.  How about enforcing a minimum buffer size?  Is 256 bytes a
reasonable minimum value?

If I understand correctly, the maxbuf value refer to the packet sent
on the wire, which could include integrity checksums (typically 16-64
bytes) and various headers (typically in the same ball park as
checksums, but for ASN.1 protocols could be larger).

If we can agree on a specific number X, to avoid introducing error
states, the encoding of the maxbuf value on the wire would thus be
'buffer size - X'.

It seems Alexey didn't like using 0 as meaning "no limit".  How about
using 0xFFFFFF as meaning "no limit"?  DIGEST-MD5 and GS1 doesn't do
that, but if Cyrus SASL is already doing this (which seems wrong to
me, but that's another story), there is some history supporting that
choice.

/Simon

Date: Tue, 05 Sep 2006 10:30:27 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Sender: [email-masked]

Nicolas Williams wrote:

>On Mon, Sep 04, 2006 at 04:37:26PM +0100, Alexey Melnikov wrote:
>  
>
>>Simon Josefsson wrote:
>>    
>>
>>>A maxbuf value of 0 has weird semantics -- it is a error-state, and
>>>authentication using a maxbuf=0 value with security layers should not
>>>succeed.
>>>      
>>>
>>Yes. (So is maxbuf=1)
>>    
>>
>
>Good point!  So is maxbuf == 2, or any impractically small value.
>  
>
Exactly.

>Is this an error state for the framework or for the application?  I say
>the latter.
>  
>
It is an error case for a specific SASL mechanism.

Date: Tue, 5 Sep 2006 00:23:38 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Mail-Followup-To: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Sep 04, 2006 at 06:35:47PM +0100, Alexey Melnikov wrote:
> Simon Josefsson wrote:
> >Nicolas Williams <[email-masked]> writes:
> > <t>This document describes how to use a Generic Security Service
> >   Application Program Interface (GSS-API) mechanism in the the
> >   Simple Authentication and Security Layer (SASL) framework.  This
> >   is done by defining a new SASL mechanism family, called GS2.  The
> >   mechanism family uses the SASL mechanism negotiation to select the
> >   GSS-API mechanism, offers reduced number of round-trips over the
> >   earlier Kerberos V5-specific "GSS-API"
> >
> If you are referencing the GS1, why do you have "-"? If not, why is it 
> quoted?

Yeah, be very carefule with "GSSAPI" vs. "GSS-API" -- in the context of
SASL the first means "the mistake that was made years ago when the name
given the SASL mechanism corresponding to the GSS-API Kerberos V
mechanism was "GSSAPI" and the latter means _the_ GSS-API (as in
RFC2743).

Also, there is no SASL mechanism negotiation as such -- SASL
applications negotiate mechanisms on an ad-hoc basis (each app protocol
specifies its own negotiations, usually based on the server listing its
available mechanisms to the client prior to starting SASL).

So the the third sentence above needs to be re-written.  I propose:

   This mechanism family offers a number of improvements over the
   previous SASL/GSS-API mechanism family: it is more general, uses
   fewer messages for the authentication phase in some cases, and
   supports a SASL-specific notion of channel binding.

> >>- Section 4.2, second paragraph.  As with SASL/GS1 we need to decide
> >>  whether SASL/GS2 is limited to host-based names, or whether that's
> >>  just what is required for interop.  We need to decide what we want to
> >>  do w.r.t. SASL and GSS-API name types other than
> >>  GSS_C_NT_HOSTBASED_SERVICE.
> >>
> >>  I propose moving the instructions on how the targ_name is obtained
> >>  into a separate paragraph and saying that host-based naming is a
> >>  REQUIRED to implement feature, but not actually requiring use of
> >>  host-based naming in all circumstances (which the current
> >>  prescriptive text can be read to imply).
> >>   
> >>
> I like the suggestion, but I can't propose any text at the moment.

Tomorrow.

Date: Tue, 5 Sep 2006 00:15:53 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Mail-Followup-To: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Sep 04, 2006 at 04:37:26PM +0100, Alexey Melnikov wrote:
> Simon Josefsson wrote:
> 
> >A maxbuf value of 0 has weird semantics -- it is a error-state, and
> >authentication using a maxbuf=0 value with security layers should not
> >succeed.
> > 
> >
> Yes. (So is maxbuf=1)

Good point!  So is maxbuf == 2, or any impractically small value.

Is this an error state for the framework or for the application?  I say
the latter.

> >It seems simpler to use it to signal something else (i.e., no buffer
> >size limit) than to use 0xFFFFFF for the same thing on the wire AND
> >ALSO describe the behaviour for the error state.
> > 
> >
> I would like to have consistency accross multiple SASL mechanisms. GS1 
> or DIGEST-MD5 don't treat 0 specially.

Me too.

> If you insist on using 0 in way different from GS1 and DIGEST-MD5, 
> please stick a big note saying that GS2 is different from GS1 in 
> handling of maxbuf==0.

I don't think GS2 should treat maxbuf==0 differently than other SASL
mechanisms unless those other mechanisms' treatment of it is itself
broken.

Nico
-- 

Date: Mon, 04 Sep 2006 18:35:47 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Sender: [email-masked]

Simon Josefsson wrote:

>Nicolas Williams <[email-masked]> writes:
>  
>
>> - The abstract needs to say a little more...
>>    
>>
>
>I've changed it to:
>
>  <t>This document describes how to use a Generic Security Service
>    Application Program Interface (GSS-API) mechanism in the the
>    Simple Authentication and Security Layer (SASL) framework.  This
>    is done by defining a new SASL mechanism family, called GS2.  The
>    mechanism family uses the SASL mechanism negotiation to select the
>    GSS-API mechanism, offers reduced number of round-trips over the
>    earlier Kerberos V5-specific "GSS-API"
>
If you are referencing the GS1, why do you have "-"? If not, why is it 
quoted?

> mechanism, and supports
>    channel bindings that improve efficiency when the mechanism is
>    used in a secure channel.</t>
>
>Comments?
>  
>
Looks good otherwise.
 [...]

>> - Section 4.2, second paragraph.  As with SASL/GS1 we need to decide
>>   whether SASL/GS2 is limited to host-based names, or whether that's
>>   just what is required for interop.  We need to decide what we want to
>>   do w.r.t. SASL and GSS-API name types other than
>>   GSS_C_NT_HOSTBASED_SERVICE.
>>
>>   I propose moving the instructions on how the targ_name is obtained
>>   into a separate paragraph and saying that host-based naming is a
>>   REQUIRED to implement feature, but not actually requiring use of
>>   host-based naming in all circumstances (which the current
>>   prescriptive text can be read to imply).
>>    
>>
I like the suggestion, but I can't propose any text at the moment.

>Suggestions?  I'm not really sure about these details.
>

Date: Mon, 04 Sep 2006 16:37:26 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Sender: [email-masked]

Simon Josefsson wrote:

>>>>If someone find them useful, I suggest adding that the value '0', when
>>>>integrity/privacy layers are installed, means that the peer that sends
>>>>that value does not have any limit on the maximum packet size.
>>>>        
>>>>
>>This would be inconsistent with several other SASL mechanisms (GS1 and
>>DIGEST-MD5).
>>Cyrus implementation is using 0xFFFFFF in this case.
>>    
>>
>
>A maxbuf value of 0 has weird semantics -- it is a error-state, and
>authentication using a maxbuf=0 value with security layers should not
>succeed.
>  
>
Yes. (So is maxbuf=1)

>It seems simpler to use it to signal something else (i.e., no buffer
>size limit) than to use 0xFFFFFF for the same thing on the wire AND
>ALSO describe the behaviour for the error state.
>  
>
I would like to have consistency accross multiple SASL mechanisms. GS1 
or DIGEST-MD5 don't treat 0 specially.

>Effectively, my approach removes an error-state.
>  
>
If you insist on using 0 in way different from GS1 and DIGEST-MD5, 
please stick a big note saying that GS2 is different from GS1 in 
handling of maxbuf==0.

>Also, Cyrus should have no problem in mapping a 0-value on the wire to
>a maxbuf value of 0xFFFFFF internally, right?  My implementation uses
>SIZE_MAX to signal the same in the APIs.
>  
>

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 04 Sep 2006 12:44:51 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

>  - The abstract needs to say a little more...

I've changed it to:

  <t>This document describes how to use a Generic Security Service
    Application Program Interface (GSS-API) mechanism in the the
    Simple Authentication and Security Layer (SASL) framework.  This
    is done by defining a new SASL mechanism family, called GS2.  The
    mechanism family uses the SASL mechanism negotiation to select the
    GSS-API mechanism, offers reduced number of round-trips over the
    earlier Kerberos V5-specific "GSS-API" mechanism, and supports
    channel bindings that improve efficiency when the mechanism is
    used in a secure channel.</t>

Comments?

>  - Section 3.3, please add the Kerberos V mechanism OID
>    (1.2.840.113554.1.2.2) as an example also...

See: http://article.gmane.org/gmane.ietf.sasl/2405

If someone else computes the same name that I got, I suppose it is
good enough to be added.  It would be bad if there were interop
mistakes here.

>  - Section 4.2, the second paragraph is way too long and should be
>    broken up (see my comments on SASL/GS1).

I'll look into it.

>  - Section 4.2, second paragraph.  As with SASL/GS1 we need to decide
>    whether SASL/GS2 is limited to host-based names, or whether that's
>    just what is required for interop.  We need to decide what we want to
>    do w.r.t. SASL and GSS-API name types other than
>    GSS_C_NT_HOSTBASED_SERVICE.
>
>    I propose moving the instructions on how the targ_name is obtained
>    into a separate paragraph and saying that host-based naming is a
>    REQUIRED to implement feature, but not actually requiring use of
>    host-based naming in all circumstances (which the current
>    prescriptive text can be read to imply).

Suggestions?  I'm not really sure about these details.

>    We should separately update RFC4422 to better describe the world of
>    SASL server naming.  But I don't think either SASL/GS1 or GS2 should
>    have to block on that, as long as we agree on something like the
>    above.

I agree.

>  - Section 4.2, s/setting input_context_handle to 0/setting
>    input_context_handle to GSS_C_NO_CONTEXT/

Fixed.

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 04 Sep 2006 12:26:30 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Please keep them, for the reasons that Nico and I stated.

Yup.

>>>If someone find them useful, I suggest adding that the value '0', when
>>>integrity/privacy layers are installed, means that the peer that sends
>>>that value does not have any limit on the maximum packet size.
>>>
> This would be inconsistent with several other SASL mechanisms (GS1 and
> DIGEST-MD5).
> Cyrus implementation is using 0xFFFFFF in this case.

A maxbuf value of 0 has weird semantics -- it is a error-state, and
authentication using a maxbuf=0 value with security layers should not
succeed.

It seems simpler to use it to signal something else (i.e., no buffer
size limit) than to use 0xFFFFFF for the same thing on the wire AND
ALSO describe the behaviour for the error state.

Effectively, my approach removes an error-state.

Also, Cyrus should have no problem in mapping a 0-value on the wire to
a maxbuf value of 0xFFFFFF internally, right?  My implementation uses
SIZE_MAX to signal the same in the APIs.

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 04 Sep 2006 12:19:27 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Fri, Sep 01, 2006 at 11:46:46AM +0200, Simon Josefsson wrote:
>> First, is anyone using the maximum client/server buffer size field for
>> anything useful?  They were carried over from the GSS-API spec, but I
>> never thought about whether they are useful in GS2.
>
> Cyrus SASL and our derivative of it both enforce the max buffer size
> sender-side.
>
> And at least one application (sendmail) that I know of checks [but can't
> and doesn't set] the max buffer size.
>
> Knowing a priori what the maximum buffer size is important.  Negotiating
> a maximum message size also seems important where there might be
> implementations that set small wrap size limits.
>
>> If nobody cares about them, I suggest to drop them.
>
> I don't agree.

Agreed; let's keep them.

> I don't see any text anywhere in RFC2743 limiting GSS_Wrap_size_limit()
> to fully established security contexts, so I don't think that calling it
> on PROT_READY-but-not-fully-established contexts should be a problem.
>
> PROT_READY implies having a session key of some sort, which should allow
> a mechanism implementation to make some wrap size limit determination,
> though this may not be accurate until full security context
> establishment (because cipher algorithms might change, say).

True.

>> If someone find them useful, I suggest adding that the value '0', when
>> integrity/privacy layers are installed, means that the peer that sends
>> that value does not have any limit on the maximum packet size.  I
>> dislike having arbitrary limitations (which is implied by having a
>> 32-bit size), and don't want my implementation to have them.
>
> Er, I think the current draft limits the max message size to 2^24 bytes
> -- the client/server_maxbuf fields are three octets, yes?

Oops, you are right.

> 32-bits should suffice, but you can always make it 64.

My point is that I don't want a limitation in my implementation here,
regardless of how large.  Do you see any problem or object to using a
0-value to indicate that a peer does not enforce any limit?
Tentatively, I've changed the descriptions to:

      <t>The "client_maxbuf" field indicate the maximum protected
	buffer size the client can receive.  It MUST be 0 if the
	client doesn't advertise support for any security layer, the
	server MUST verify this.  If the client advertise support for
	security layers, a value of 0 means that the client does not
	place any limit on the size of data.</t>

      <t>The "server_maxbuf" field indicate the maximum data buffer
	size the server can receive.  It MUST be 0 if the server
	doesn't advertise support for any security layer, the client
	MUST verify this.  If the server advertise support for
	security layers, a value of 0 means that the server does not
	place any limit on the size of data.</t>

Thanks,
Simon

Date: Fri, 01 Sep 2006 17:57:11 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Sender: [email-masked]

Nicolas Williams wrote:

>On Fri, Sep 01, 2006 at 11:46:46AM +0200, Simon Josefsson wrote:
>  
>
>>First, is anyone using the maximum client/server buffer size field for
>>anything useful?  They were carried over from the GSS-API spec, but I
>>never thought about whether they are useful in GS2.
>>    
>>
>
>Cyrus SASL and our derivative of it both enforce the max buffer size
>sender-side.
>
>And at least one application (sendmail) that I know of checks [but can't
>and doesn't set] the max buffer size.
>
>Knowing a priori what the maximum buffer size is important.  Negotiating
>a maximum message size also seems important where there might be
>implementations that set small wrap size limits.
>  
>
Exactly. This can be used by an application that uses fixed or 
preallocated buffer, e.g. a client running on a cell phone.

>>If nobody cares about them, I suggest to drop them.
>>    
>>
>
>I don't agree.
>  
>
Please keep them, for the reasons that Nico and I stated.

>>If someone find them useful, I suggest adding that the value '0', when
>>integrity/privacy layers are installed, means that the peer that sends
>>that value does not have any limit on the maximum packet size.
>>
This would be inconsistent with several other SASL mechanisms (GS1 and 
DIGEST-MD5).
Cyrus implementation is using 0xFFFFFF in this case.

>>I dislike having arbitrary limitations (which is implied by having a
>>32-bit size), and don't want my implementation to have them.
>>    
>>
>
>Er, I think the current draft limits the max message size to 2^24 bytes
>-- the client/server_maxbuf fields are three octets, yes?
>  
>
Nico is correct.

>32-bits should suffice, but you can always make it 64.
>  
>
>>A second point: The client_maxbuf description is underspecified,
>>compare the server_maxbuf description.  I suggest duplicating some of
>>the normative text for client_maxbuf as well.
>>    
>>
>Sure.
>  
>
+1.

Date: Fri, 1 Sep 2006 11:21:04 -0500
From: Nicolas Williams <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Mail-Followup-To: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Sender: [email-masked]

 - The abstract needs to say a little more...

 - Section 3.3, please add the Kerberos V mechanism OID
   (1.2.840.113554.1.2.2) as an example also...

 - Section 4.2, the second paragraph is way too long and should be
   broken up (see my comments on SASL/GS1).

 - Section 4.2, second paragraph.  As with SASL/GS1 we need to decide
   whether SASL/GS2 is limited to host-based names, or whether that's
   just what is required for interop.  We need to decide what we want to
   do w.r.t. SASL and GSS-API name types other than
   GSS_C_NT_HOSTBASED_SERVICE.

   I propose moving the instructions on how the targ_name is obtained
   into a separate paragraph and saying that host-based naming is a
   REQUIRED to implement feature, but not actually requiring use of
   host-based naming in all circumstances (which the current
   prescriptive text can be read to imply).

   We should separately update RFC4422 to better describe the world of
   SASL server naming.  But I don't think either SASL/GS1 or GS2 should
   have to block on that, as long as we agree on something like the
   above.

 - Section 4.2, s/setting input_context_handle to 0/setting
   input_context_handle to GSS_C_NO_CONTEXT/

Nico
-- 

Date: Fri, 1 Sep 2006 11:05:04 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, Sep 01, 2006 at 11:46:46AM +0200, Simon Josefsson wrote:
> First, is anyone using the maximum client/server buffer size field for
> anything useful?  They were carried over from the GSS-API spec, but I
> never thought about whether they are useful in GS2.

Cyrus SASL and our derivative of it both enforce the max buffer size
sender-side.

And at least one application (sendmail) that I know of checks [but can't
and doesn't set] the max buffer size.

Knowing a priori what the maximum buffer size is important.  Negotiating
a maximum message size also seems important where there might be
implementations that set small wrap size limits.

> If nobody cares about them, I suggest to drop them.

I don't agree.

I don't see any text anywhere in RFC2743 limiting GSS_Wrap_size_limit()
to fully established security contexts, so I don't think that calling it
on PROT_READY-but-not-fully-established contexts should be a problem.

PROT_READY implies having a session key of some sort, which should allow
a mechanism implementation to make some wrap size limit determination,
though this may not be accurate until full security context
establishment (because cipher algorithms might change, say).

> If someone find them useful, I suggest adding that the value '0', when
> integrity/privacy layers are installed, means that the peer that sends
> that value does not have any limit on the maximum packet size.  I
> dislike having arbitrary limitations (which is implied by having a
> 32-bit size), and don't want my implementation to have them.

Er, I think the current draft limits the max message size to 2^24 bytes
-- the client/server_maxbuf fields are three octets, yes?

32-bits should suffice, but you can always make it 64.

> A second point: The client_maxbuf description is underspecified,
> compare the server_maxbuf description.  I suggest duplicating some of
> the normative text for client_maxbuf as well.

Sure.

> A third point: The channel_binding_length field in the server request
> is redundant, since the length can be inferred from the packet size.

Yes.

> The reason it looks that way is because the field is needed in client
> requests -- that simplifies a encoder/decoder.  I believe the problem
> of handling an incorrect value in that field for server requests is
> more difficult than what can be motivated by reduced implementation
> costs.  I suggest that the field is removed, and text is added that
> implementation should deduce the channel_binding length from the
> message size.

I don't mind.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-02.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 01 Sep 2006 11:46:46 +0200
Sender: [email-masked]

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

> This message initiates a SASL Working Group Last Call on the
> document:

Thanks for starting the last call!

I'm implementing GS2 now, and will probably provide more feedback
later on.  However, three things that I've discovered so far:

First, is anyone using the maximum client/server buffer size field for
anything useful?  They were carried over from the GSS-API spec, but I
never thought about whether they are useful in GS2.

If nobody cares about them, I suggest to drop them.

If someone find them useful, I suggest adding that the value '0', when
integrity/privacy layers are installed, means that the peer that sends
that value does not have any limit on the maximum packet size.  I
dislike having arbitrary limitations (which is implied by having a
32-bit size), and don't want my implementation to have them.

I also question whether the discussion about GSS_Wrap_size_limit is
relevant.  It seems as if that function takes a context parameter, but
in GS2, that function would have to be called after PROT_READY is
signalled, which may be before the context has been established.  I
don't know whether that function works in that case?  So it may not be
possible to find out what the maximum buffer size is at all.  I
suggest that if someone cares about the fields, they should provide
more text about how to deduce useful values for the fields.

A second point: The client_maxbuf description is underspecified,
compare the server_maxbuf description.  I suggest duplicating some of
the normative text for client_maxbuf as well.

A third point: The channel_binding_length field in the server request
is redundant, since the length can be inferred from the packet size.
The reason it looks that way is because the field is needed in client
requests -- that simplifies a encoder/decoder.  I believe the problem
of handling an incorrect value in that field for server requests is
more difficult than what can be motivated by reduced implementation
costs.  I suggest that the field is removed, and text is added that
implementation should deduce the channel_binding length from the
message size.

If there are no feedback on my comments, as editor, I'll incorporate
the suggested solutions above.

/Simon