Subject: Re: Update of GS2
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Date: Fri, 30 Jun 2006 16:51:04 -0500
List-Id: <ietf-sasl.imc.org>

On Fri, Jun 30, 2006 at 12:43:04PM +0200, Simon Josefsson wrote:
> Is this approach regarding channel binding OK with everyone?

Yes.  We can probably last call this soon, though we'll want to resolve
the matter of who specifies the TLS channel bindings.  That'll have to
wait until we firm up our sense of the state of the other channel
bindings I-Ds.  We can always keep your text and not reference any
channel bindings documents.

> There is one more issue, maybe we can resolve it on-list:
> 
> * Should the document say that integrity/privacy layers
>   MAY/SHOULD/MUST be negotiated?  If channel binding negotiation
>   succeeds, it currently says:
> 
>    Implementations MAY set the "client_cbqops" and "server_cbqops" to no
>    security layer to improve performance by using only one security
>    layer.

MAY is fine, but I'd prefer SHOULD.

And I'd re-write that sentence like so:

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

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

   [Here a reference to the NFSv4 WG channel bindings I-D would be
   useful, both for formal definitions and for discussion of the
   security benefits of channel binding hinter at above.]

>   This seems acceptable to me, but we may also require that a security
>   layer must always be negotiated if there is no channel binding.

RFC4422 doesn't require the use of security layers, therefore neither
should GS2.

>   There is a complication when the GSS-API mechanism doesn't provide
>   security layers.  Should we say anything about this?

That point is moot.  Note that if the client wants to negotiate
confidentiality protection then it MUST set the conf_req_flag for
GSS_Init_sec_context() (GSS_C_CONF_FLAG).

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

Example connections?

Nico
-- 

Date: Fri, 30 Jun 2006 06:39:46 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Open issues in DIGEST-MD5 (draft-ietf-sasl-rfc2831bis-09.txt)
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Sender: [email-masked]

At 04:04 AM 6/30/2006, Simon Josefsson wrote:
>I'm not sure if we can mark
>parts of a protocol as HISTORIC, anyone? 

The term Historic (RFC 2026) applies at a Technical Specification
level, document(s) in practice.

If a document revising an existing specification wants not
to bring forward a particular feature, it should not include
that feature in the revised specification.  In doing so,
it should note that the feature was not brought forward
and why.

An alternative would for the document to include a specification
of the feature but indicate that it's "not recommended" (and
why).

I recommend the former.

-- Kurt

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: Open issues in DIGEST-MD5 (draft-ietf-sasl-rfc2831bis-09.txt)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 30 Jun 2006 13:04:17 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Simon Josefsson wrote:
>
>>Alexey Melnikov <[email-masked]> writes:
>>  
>>
>>>Main issues:
>>>    
>>>
>>I'd like to add:
>>
>>5) Use of RC4 as the mandatory to implement cipher?
>>
>>RFC 4345 suggests that discarding the initial 1536 bytes from the RC4
>>key-stream protect against published attacks on RC4.  DIGEST-MD5 does
>>not discard any bytes as far as I can see, but I haven't seen -09 yet.
>>
>>If DIGEST-MD5 must go forward, I think we should move the RC4 cipher
>>from optional (as in RFC 2831) to historic, and explain the security
>>problems (i.e., a reference to MANTIN01/MANTIN05).
>>  
>>
> Right. I actually think this is more or less decided after your
> message and Sam's reply, but I haven't done the change yet.

Oh, that's good news!

> Suggested text with explanation of security problems with RC4 is welcome.

How about this, based mostly on RFC 4345.  I'm not sure if we can mark
parts of a protocol as HISTORIC, anyone?

   An overview of published results on the security of RC4 is
   available in [MANTIN01], which also contains in section 6.3.4 the
   recommendation to discard the initial 1536 bytes of the key-stream
   to avoid a statistical bias that would defend against strong
   distinguishers.  The use of RC4 in DIGEST-MD5 does not discard any
   initial bytes, and if the cipher as used in DIGEST-MD5 were to be
   modified to defend against strong distinguishers, it would no
   longer be backwards compatible.  There are further results in
   [FMcG] and [MANTIN05] regarding weak distinguishers that are not
   defended by discarding the initial output.  Therefor the cipher is
   labeled as HISTORIC.

   [MANTIN01] Mantin, I., "Analysis of the Stream Cipher RC4", M.Sc.
              Thesis, Weizmann Institute of Science, 2001, <http://
              www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Mantin1.zip>.

   [FMcG]     Fluhrer, S. and D. McGrew, "Statistical Analysis of the
              Alleged RC4 Keystream Generator", Fast Software
              Encryption:  7th International Workshop, FSE 2000, April
              2000, <http://www.mindspring.com/~dmcgrew/rc4-03.pdf>.

   [MANTIN05] Mantin, I., "Predicting and Distinguishing Attacks on RC4
              Keystream Generator", Advances in Cryptology -- EUROCRYPT
              2005: 24th Annual International Conference on the Theory
              and Applications of Cryptographic Techniques, May 2005.

/Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: Update of GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 30 Jun 2006 12:43:04 +0200
Sender: [email-masked]

Here is the new version and rfcdiff compared to -01:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--01.diff.html

I'm including the new channel binding section below.  It doesn't
reference draft-ietf-nfsv4-channel-bindings-04.txt because that
document doesn't contain the necessary details yet.

Is this approach regarding channel binding OK with everyone?

There is one more issue, maybe we can resolve it on-list:

* Should the document say that integrity/privacy layers
  MAY/SHOULD/MUST be negotiated?  If channel binding negotiation
  succeeds, it currently says:

   Implementations MAY set the "client_cbqops" and "server_cbqops" to no
   security layer to improve performance by using only one security
   layer.

  This seems acceptable to me, but we may also require that a security
  layer must always be negotiated if there is no channel binding.

  There is a complication when the GSS-API mechanism doesn't provide
  security layers.  Should we say anything about this?

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

Thanks,
Simon

5.  Channel Bindings

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

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

   Implementations MAY set the "client_cbqops" and "server_cbqops" to no
   security layer to improve performance by using only one security
   layer.

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

5.1.  Name Of TLS Channel For Use As Channel Binding

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

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

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

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

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: Update of GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 30 Jun 2006 12:29:54 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Thu, Jun 29, 2006 at 10:45:34PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[email-masked]> writes:
>> > Strike the last sentence.  It's not useful -- we only need integrity
>> > protection for channel binding data, and GSS-API mechanisms that support
>> > channel binding do provide that.
>> 
>> Do the GSS-API framework require that "chan_binding"s are negotiated
>> in an integrity protected way?
>
> Yes, but we don't want to use this facility because we want different
> semantics, so this isn't relevant.
>
>> What I'm getting at is this: is a GSS-API mechanism allowed (by the
>> framework) to send chan_binding in the clear, and use memcmp() with
>> the received data and the local channel binding data to test whether
>> the correct channel binding is used?
>
> Yes, it is.  But again, we don't care.

These two statements seem to conflict -- either the chan_bindings are
integrity protected or not -- but I agree that it is irrelevant.

>> If the framework doesn't mandate integrity protection, it seems that
>> we have to re-implement this in GS2, which is done by sending the
>> channel binding data in a GSS_Wrap-protected token.
>
> No, we have to implement a channel binding facility in GS2 because we
> want semantics that are different from the GSS-API's.

Right.

>> >>    The client can select, using the "Native Channel Bindings" bit,
>> >>    whether it wishes to use the "chan_bindings" parameter in the GSS-API
>> >>    layer or not.  If it wishes to use this, it is not possible to
>> >>    continue after a failed channel binding negotiation.
>> >
>> > I don't understand why we should use the GSS-API channel binding
>> > facility at all given that we need to build a SASL-specific channel
>> > binding facility to support the semantics we want.
>> >
>> > I think this text would be simplified if it required that
>> > GSS_C_NO_CHANNEL_BINDINGS be used for channel bindings in the GSS_Init/
>> > Accept_sec_context() calls.
>> 
>> I agree that it would be simpler.
>> 
>> The reason I added it was that some future GSS-API mechanism may, in
>> some configurations, require or need the channel binding to be present
>> in order for authentication to succeed.
>
> I don't think we'll ever see a concrete GSS-API mechanisms that requires
> the use of channel bindings.
>
> I have proposed a stackable pseudo-mechanism which composes mechanisms
> that are intended to make channel bindings negotiable, but use of such
> mechanisms in GS2 would not be appropriate .
>
>> However, if nobody else finds this property favorable, I'll drop it.
>
> Please do.

I'm making this change now.

>> It would simplify the protocol, since the "Native Channel Binding"
>> flag can be dropped, including the complexity related to it.  This is
>> probably a good thing.
>
> Exactly.

Yup.

I'll post a status update in the next e-mail.

/Simon

Date: Thu, 29 Jun 2006 16:34:04 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Update of GS2
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Jun 29, 2006 at 10:45:34PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[email-masked]> writes:
> > Strike the last sentence.  It's not useful -- we only need integrity
> > protection for channel binding data, and GSS-API mechanisms that support
> > channel binding do provide that.
> 
> Do the GSS-API framework require that "chan_binding"s are negotiated
> in an integrity protected way?

Yes, but we don't want to use this facility because we want different
semantics, so this isn't relevant.

> What I'm getting at is this: is a GSS-API mechanism allowed (by the
> framework) to send chan_binding in the clear, and use memcmp() with
> the received data and the local channel binding data to test whether
> the correct channel binding is used?

Yes, it is.  But again, we don't care.

> If the framework doesn't mandate integrity protection, it seems that
> we have to re-implement this in GS2, which is done by sending the
> channel binding data in a GSS_Wrap-protected token.

No, we have to implement a channel binding facility in GS2 because we
want semantics that are different from the GSS-API's.

> >>    The client can select, using the "Native Channel Bindings" bit,
> >>    whether it wishes to use the "chan_bindings" parameter in the GSS-API
> >>    layer or not.  If it wishes to use this, it is not possible to
> >>    continue after a failed channel binding negotiation.
> >
> > I don't understand why we should use the GSS-API channel binding
> > facility at all given that we need to build a SASL-specific channel
> > binding facility to support the semantics we want.
> >
> > I think this text would be simplified if it required that
> > GSS_C_NO_CHANNEL_BINDINGS be used for channel bindings in the GSS_Init/
> > Accept_sec_context() calls.
> 
> I agree that it would be simpler.
> 
> The reason I added it was that some future GSS-API mechanism may, in
> some configurations, require or need the channel binding to be present
> in order for authentication to succeed.

I don't think we'll ever see a concrete GSS-API mechanisms that requires
the use of channel bindings.

I have proposed a stackable pseudo-mechanism which composes mechanisms
that are intended to make channel bindings negotiable, but use of such
mechanisms in GS2 would not be appropriate .

> However, if nobody else finds this property favorable, I'll drop it.

Please do.

> It would simplify the protocol, since the "Native Channel Binding"
> flag can be dropped, including the complexity related to it.  This is
> probably a good thing.

Exactly.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: Update of GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 29 Jun 2006 22:45:34 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Thu, Jun 29, 2006 at 12:32:35PM +0200, Simon Josefsson wrote:
>> 5.  Channel Bindings
>> 
>>    [[This section is tentative further discussion on the topic.  This
>>    was written to provide an example of how the details of how one
>>    approach to this concept could look like.  There are other approaches
>>    that may be preferable.]]
>> 
>>    The GS2 mechanism provide its own token field for channel bindings,
>>    in addition to the "chan_binding" parameter in the GSS-API context
>>    functions.  The reason for this is that the GS2 mechanism wish to
>>    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.  The GSS-API framework
>>    also does not specify the kind of privacy layer the channel binding
>>    should be transferred under, thus making it possible for attackers to
>>    modify it to always make channel binding negotiation succeed.
>
> Strike the last sentence.  It's not useful -- we only need integrity
> protection for channel binding data, and GSS-API mechanisms that support
> channel binding do provide that.

Do the GSS-API framework require that "chan_binding"s are negotiated
in an integrity protected way?

What I'm getting at is this: is a GSS-API mechanism allowed (by the
framework) to send chan_binding in the clear, and use memcmp() with
the received data and the local channel binding data to test whether
the correct channel binding is used?

If the framework doesn't mandate integrity protection, it seems that
we have to re-implement this in GS2, which is done by sending the
channel binding data in a GSS_Wrap-protected token.

>>    The client can select, using the "Native Channel Bindings" bit,
>>    whether it wishes to use the "chan_bindings" parameter in the GSS-API
>>    layer or not.  If it wishes to use this, it is not possible to
>>    continue after a failed channel binding negotiation.
>
> I don't understand why we should use the GSS-API channel binding
> facility at all given that we need to build a SASL-specific channel
> binding facility to support the semantics we want.
>
> I think this text would be simplified if it required that
> GSS_C_NO_CHANNEL_BINDINGS be used for channel bindings in the GSS_Init/
> Accept_sec_context() calls.

I agree that it would be simpler.

The reason I added it was that some future GSS-API mechanism may, in
some configurations, require or need the channel binding to be present
in order for authentication to succeed.

However, if nobody else finds this property favorable, I'll drop it.
It would simplify the protocol, since the "Native Channel Binding"
flag can be dropped, including the complexity related to it.  This is
probably a good thing.

>>    For TLS, the channel binding data is specified in the next section.
>>    For other security layers, channel binding data will have to
>>    specified elsewhere, and this specification will have to be updated
>>    with explicit considerations.
>> 
>>    [[All channel bindings should go into a separate document.]]
>
> I've resubmitted draft-ietf-nfsv4-channel-bindings-04.txt, it doesn't
> have quite the txt below, but we can modify it.
>
>> 5.1.  Name Of Tls Channel For Use As Channel Binding

Ok, excellent!  I'll review it, and the next GS2 version should
reference it instead.

Thanks,
Simon

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-09.txt 
Date: Thu, 29 Jun 2006 15:50:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Using Digest Authentication as a SASL Mechanism
	Author(s)	: P. Leach, et al.
	Filename	: draft-ietf-sasl-rfc2831bis-09.txt
	Pages		: 42
	Date		: 2006-6-29
	
This specification defines how HTTP Digest Authentication (RFC 2617)
   can be used as a Simple Authentication and Security Layer (SASL, RFC
   4422) mechanism for any protocol that has a SASL profile. It is
   intended both as an improvement over CRAM-MD5 (RFC 2195) and as a
   convenient way to support a single authentication mechanism for web,
   mail, LDAP, and other protocols

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sasl-rfc2831bis-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-09.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 29 Jun 2006 14:36:21 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>
cc: [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Update of GS2
Originator-Info: login-token=Mulberry:01rwrnMBlyXKT7VV+x4ogXn0Z8Hls2PmAcfxWV5Yo=; token_authority=[email-masked]
Sender: [email-masked]

On Thursday, June 29, 2006 11:59:41 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

>
> On Thu, Jun 29, 2006 at 12:32:35PM +0200, Simon Josefsson wrote:
>> 5.  Channel Bindings
>>
>>    [[This section is tentative further discussion on the topic.  This
>>    was written to provide an example of how the details of how one
>>    approach to this concept could look like.  There are other approaches
>>    that may be preferable.]]
>>
>>    The GS2 mechanism provide its own token field for channel bindings,
>>    in addition to the "chan_binding" parameter in the GSS-API context
>>    functions.  The reason for this is that the GS2 mechanism wish to
>>    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.  The GSS-API framework
>>    also does not specify the kind of privacy layer the channel binding
>>    should be transferred under, thus making it possible for attackers to
>>    modify it to always make channel binding negotiation succeed.
>
> Strike the last sentence.  It's not useful -- we only need integrity
> protection for channel binding data, and GSS-API mechanisms that support
> channel binding do provide that.

Agree.

>>    The client can select, using the "Native Channel Bindings" bit,
>>    whether it wishes to use the "chan_bindings" parameter in the GSS-API
>>    layer or not.  If it wishes to use this, it is not possible to
>>    continue after a failed channel binding negotiation.
>
> I don't understand why we should use the GSS-API channel binding
> facility at all given that we need to build a SASL-specific channel
> binding facility to support the semantics we want.
>
> I think this text would be simplified if it required that
> GSS_C_NO_CHANNEL_BINDINGS be used for channel bindings in the GSS_Init/
> Accept_sec_context() calls.

Agree.

-- Jeff

Date: Thu, 29 Jun 2006 11:59:41 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Update of GS2
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Jun 29, 2006 at 12:32:35PM +0200, Simon Josefsson wrote:
> 5.  Channel Bindings
> 
>    [[This section is tentative further discussion on the topic.  This
>    was written to provide an example of how the details of how one
>    approach to this concept could look like.  There are other approaches
>    that may be preferable.]]
> 
>    The GS2 mechanism provide its own token field for channel bindings,
>    in addition to the "chan_binding" parameter in the GSS-API context
>    functions.  The reason for this is that the GS2 mechanism wish to
>    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.  The GSS-API framework
>    also does not specify the kind of privacy layer the channel binding
>    should be transferred under, thus making it possible for attackers to
>    modify it to always make channel binding negotiation succeed.

Strike the last sentence.  It's not useful -- we only need integrity
protection for channel binding data, and GSS-API mechanisms that support
channel binding do provide that.

>    The client can select, using the "Native Channel Bindings" bit,
>    whether it wishes to use the "chan_bindings" parameter in the GSS-API
>    layer or not.  If it wishes to use this, it is not possible to
>    continue after a failed channel binding negotiation.

I don't understand why we should use the GSS-API channel binding
facility at all given that we need to build a SASL-specific channel
binding facility to support the semantics we want.

I think this text would be simplified if it required that
GSS_C_NO_CHANNEL_BINDINGS be used for channel bindings in the GSS_Init/
Accept_sec_context() calls.

>    For TLS, the channel binding data is specified in the next section.
>    For other security layers, channel binding data will have to
>    specified elsewhere, and this specification will have to be updated
>    with explicit considerations.
> 
>    [[All channel bindings should go into a separate document.]]

I've resubmitted draft-ietf-nfsv4-channel-bindings-04.txt, it doesn't
have quite the txt below, but we can modify it.

> 5.1.  Name Of Tls Channel For Use As Channel Binding

...

Nico
-- 

Date: Thu, 29 Jun 2006 17:58:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: Open issues in DIGEST-MD5 (draft-ietf-sasl-rfc2831bis-09.txt)
Sender: [email-masked]

Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
>  
>
>>Main issues:
>>    
>>
>I'd like to add:
>
>5) Use of RC4 as the mandatory to implement cipher?
>
>RFC 4345 suggests that discarding the initial 1536 bytes from the RC4
>key-stream protect against published attacks on RC4.  DIGEST-MD5 does
>not discard any bytes as far as I can see, but I haven't seen -09 yet.
>
>If DIGEST-MD5 must go forward, I think we should move the RC4 cipher
>from optional (as in RFC 2831) to historic, and explain the security
>problems (i.e., a reference to MANTIN01/MANTIN05).
>  
>
Right. I actually think this is more or less decided after your message 
and Sam's reply, but I haven't done the change yet.

Suggested text with explanation of security problems with RC4 is welcome.

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: Open issues in DIGEST-MD5 (draft-ietf-sasl-rfc2831bis-09.txt)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 29 Jun 2006 18:37:48 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Main issues:

I'd like to add:

5) Use of RC4 as the mandatory to implement cipher?

RFC 4345 suggests that discarding the initial 1536 bytes from the RC4
key-stream protect against published attacks on RC4.  DIGEST-MD5 does
not discard any bytes as far as I can see, but I haven't seen -09 yet.

If DIGEST-MD5 must go forward, I think we should move the RC4 cipher
from optional (as in RFC 2831) to historic, and explain the security
problems (i.e., a reference to MANTIN01/MANTIN05).

/Simon

Date: Thu, 29 Jun 2006 07:41:06 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Update of GS2
Sender: [email-masked]

Does anyone have any concerns regarding the channel binding
approach taken here?

At 03:32 AM 6/29/2006, Simon Josefsson wrote:

>I've updated the GS2 spec:
>
>http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-01.txt
>
>The changes since last version:
>
>http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--00.diff.html
>
>The only change is to address the only open issue I am aware of:
>channel bindings.  I've picked one approach, see the new section 5.
>I'm including the text for easy review and quoting below.
>
>I won't be present in Montreal, but can provide a slide to help
>discussion of channel bindings and my solution.  I'll hopefully be
>able to participate remotely via jabber.
>
>/Simon
>
>5.  Channel Bindings
>
>   [[This section is tentative further discussion on the topic.  This
>   was written to provide an example of how the details of how one
>   approach to this concept could look like.  There are other approaches
>   that may be preferable.]]
>
>   The GS2 mechanism provide its own token field for channel bindings,
>   in addition to the "chan_binding" parameter in the GSS-API context
>   functions.  The reason for this is that the GS2 mechanism wish to
>   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.  The GSS-API framework
>   also does not specify the kind of privacy layer the channel binding
>   should be transferred under, thus making it possible for attackers to
>   modify it to always make channel binding negotiation succeed.
>
>   The client can select, using the "Native Channel Bindings" bit,
>   whether it wishes to use the "chan_bindings" parameter in the GSS-API
>   layer or not.  If it wishes to use this, it is not possible to
>   continue after a failed channel binding negotiation.
>
>   A client that wish to continue with the authentication even if the
>   channel bindings does not match, set the "Native Channel Binding" bit
>   to 0.  It MUST use the channel binding field in the GS2 token.  It
>   MUST set the "chan_binding" parameter in the calls to
>   GSS_Init_sec_context to GSS_Accept_sec_context to NULL.  The
>   application MUST set the "client_qops" field to include privacy
>   protection (to protect the SASL application data), and MAY set the
>   "client_cbqops" to no security layer (to avoid performance
>   degradation due to two security layers).
>
>   If a client do not wish to continue the authentication if channel
>   binding negotiation fails, or wishes to use the channel binding in
>   the GSS-API layer, it will set the "Native Channel Binding" bit to 1
>   in its first token.  It MUST use both the channel binding field in
>   the GS2 token and the "chan_binding" parameter in the calls to
>   GSS_Init_sec_context and GSS_Accept_sec_context.  The authentication
>   will fail in the GSS-API layer if the channel bindings does not
>   match, and thus the "client_qops" and "client_cbqops" MUST be set to
>   the same value.  It MAY be set to no security layer (to avoid
>   performance degradation due to two security layers).
>
>   For TLS, the channel binding data is specified in the next section.
>   For other security layers, channel binding data will have to
>   specified elsewhere, and this specification will have to be updated
>   with explicit considerations.
>
>   [[All channel bindings should go into a separate document.]]
>
>5.1.  Name Of Tls Channel For Use As Channel Binding
>
>   The TLS Pseudo-Random Function (PRF) generate, using the constant
>   string "TLS channel binding", and based on the master secret and the
>   random values established during a TLS handshake, a 64 octet string
>   that make up the SASL channel binding data.
>
>   Using the terminology of TLS [13], the channel binding data is
>   computed as follows:
>
>          SASL_channel_binding =
>             PRF(SecurityParameters.master_secret,
>                "TLS channel binding",
>                SecurityParameters.server_random +
>                SecurityParameters.client_random) [0..64];
>
>   The derived data is intended to be used as a name of the TLS channel
>   that is cryptographically bound to the channel, for use in
>   authentication mechanisms tunneled over TLS.

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Update of GS2
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 29 Jun 2006 12:32:35 +0200
Sender: [email-masked]

I've updated the GS2 spec:

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

The changes since last version:

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

The only change is to address the only open issue I am aware of:
channel bindings.  I've picked one approach, see the new section 5.
I'm including the text for easy review and quoting below.

I won't be present in Montreal, but can provide a slide to help
discussion of channel bindings and my solution.  I'll hopefully be
able to participate remotely via jabber.

/Simon

5.  Channel Bindings

   [[This section is tentative further discussion on the topic.  This
   was written to provide an example of how the details of how one
   approach to this concept could look like.  There are other approaches
   that may be preferable.]]

   The GS2 mechanism provide its own token field for channel bindings,
   in addition to the "chan_binding" parameter in the GSS-API context
   functions.  The reason for this is that the GS2 mechanism wish to
   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.  The GSS-API framework
   also does not specify the kind of privacy layer the channel binding
   should be transferred under, thus making it possible for attackers to
   modify it to always make channel binding negotiation succeed.

   The client can select, using the "Native Channel Bindings" bit,
   whether it wishes to use the "chan_bindings" parameter in the GSS-API
   layer or not.  If it wishes to use this, it is not possible to
   continue after a failed channel binding negotiation.

   A client that wish to continue with the authentication even if the
   channel bindings does not match, set the "Native Channel Binding" bit
   to 0.  It MUST use the channel binding field in the GS2 token.  It
   MUST set the "chan_binding" parameter in the calls to
   GSS_Init_sec_context to GSS_Accept_sec_context to NULL.  The
   application MUST set the "client_qops" field to include privacy
   protection (to protect the SASL application data), and MAY set the
   "client_cbqops" to no security layer (to avoid performance
   degradation due to two security layers).

   If a client do not wish to continue the authentication if channel
   binding negotiation fails, or wishes to use the channel binding in
   the GSS-API layer, it will set the "Native Channel Binding" bit to 1
   in its first token.  It MUST use both the channel binding field in
   the GS2 token and the "chan_binding" parameter in the calls to
   GSS_Init_sec_context and GSS_Accept_sec_context.  The authentication
   will fail in the GSS-API layer if the channel bindings does not
   match, and thus the "client_qops" and "client_cbqops" MUST be set to
   the same value.  It MAY be set to no security layer (to avoid
   performance degradation due to two security layers).

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

   [[All channel bindings should go into a separate document.]]

5.1.  Name Of Tls Channel For Use As Channel Binding

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

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

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

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-gs2-01.txt 
Date: Wed, 28 Jun 2006 18:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	Author(s)	: S. Josefsson
	Filename	: draft-ietf-sasl-gs2-01.txt
	Pages		: 21
	Date		: 2006-6-28
	
This document describes how to use a Generic Security Service
   Application Program Interface (GSS-API) mechanism in the the Simple
   Authentication and Security Layer (SASL) framework.

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

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sasl-gs2-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-gs2-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-gs2-01.txt

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

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

--OtherAccess--

--NextPart--

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, sasl mailing list <[email-masked]>, sasl chair <[email-masked]>, sasl chair <[email-masked]>
Subject: Protocol Action: 'The PLAIN SASL Mechanism' to Proposed  Standard 
Date: Wed, 28 Jun 2006 17:18:24 -0400
Sender: [email-masked]

The IESG has approved the following document:

- 'The PLAIN SASL Mechanism '
   <draft-ietf-sasl-plain-09.txt> as a Proposed Standard

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

The IESG contact persons are Sam Hartman and Russ Housley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-09.txt

Technical Summary

 This document defines a simple clear-text user/password Simple
 Authentication and Security Layer (SASL) mechanism called the PLAIN
 mechanism.  The PLAIN mechanism is intended to be used, in combination
 with data confidentiality services provided by a lower layer, in
 protocols which lack a simple password authentication command. This document
updates RFC 2595.
 
Working Group Summary
 
 The working group came to rough consensus on this document.  There
 was some debate about how stringprep's desire to avoid comparison of
 two strings both involving unassigned codepoints interacts with
 situations where one string is transported by an IETF-controlled
 protocol like this mechanism and the other string is the providence of
 an implementation-specific protocol with broader applicability than
 this specification.

Protocol Quality
 
 This specification has been reviewed by Sam Hartman for the IESG.

RFC Editor Note
 
  In section 1

old:
  Clear-text, multiple-use passwords are simple, interoperate with
  almost all existing operating system authentication databases, and are
  useful for a smooth transition to a more secure password-based
  authentication mechanism. The drawback is that they are unacceptable
  for use over network connection where data confidentiality is not
  assured (by encryption or other means).

  new (removing parenthetical):

  Clear-text, multiple-use passwords are simple, interoperate with
  almost all existing operating system authentication databases, and are
  useful for a smooth transition to a more secure password-based
  authentication mechanism. The drawback is that they are unacceptable
  for use over network connection where data confidentiality is not
  assured.

Date: Wed, 28 Jun 2006 18:31:08 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Open issues in DIGEST-MD5 (draft-ietf-sasl-rfc2831bis-09.txt)
Sender: [email-masked]

I've submitted -09 on Monday, so it should be announced soon.

Main changes:
1). Removed any mentioning of downconversion from UTF-8 to ISO-8859-1.
This resulted in removal of 2 open issues.
2). Added "prep" directive which specifies which preparation
algorithm(s) are used/supported by client/server.
3). Cleanup in section describing HTTP variant of ABNF.

Main issues:
1). Initial value for AES cipher can be defined to depend on the list of
qop values specified by the server. I think this can eliminate one of 
the MITM attacks. Should I do the change?

2). The only allowed preparation algorithm is SASLPrep. Should the
document describe "prep=none"? Previous version of the document used
"SHOULD use SASLPrep", similar to the text from SASL PLAIN.

3). The draft currently says:
  The server SHOULD verify the correctness of an authzid as specified
  by the corresponding SASL protocol profile.
Should this be a MUST?

4). I think I've briefly discussed this one in Dallas: DIGEST-MD5
requires cnonce to be the same on reauthentication. HTTP Digest doesn't
seem to require this (server nonce *is* required to be the same in
both). Which is more secure?

Date: Mon, 26 Jun 2006 08:41:04 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: agenda input
Sender: [email-masked]

Our past sessions have been short on technical discussion
and long on I-D status/changes reporting.  To encourage
more face-to-face technical discussions and reduce
status/changes reporting, it would be good to an
issue-driven agenda.

To this end, requests for time should include a list of
the technical issues to be discussed.  Once time has been
allocated, the requester should provide a summary of each
issue to be discussed to the list.

While it is expected that each WG editor requests time
for outstanding issues needing face-to-face time to resolve,
anyone with request time to discuss a technical issue in a
SASL or SASL-related I-D.  Requesters unable to attend
should note so in their request.

Please submit your requests for session time in the
next couple of days.  Tom and I will provide a draft agenda
by Friday, and final agenda before the 3 July cut-off.
Summaries of issues to be discussed should be submitted
shortly there after, certainly by 7 July.

Also, those who would like to use slides to aide in the
technical discussions should submit them (most any common
source format acceptable) to the chairs by 9 July so that
they may be made available (in a variety of presentation
formats) to remote attendees prior to the session <at
http://www.openldap.org/ietf/sasl/66/>.

Thanks, Kurt

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-plain-09.txt 
Date: Tue, 20 Jun 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 PLAIN SASL Mechanism
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-plain-09.txt
	Pages		: 10
	Date		: 2006-6-19
	
This document defines a simple clear-text user/password Simple
Authentication and Security Layer (SASL) mechanism called the PLAIN
mechanism.  The PLAIN mechanism is intended to be used, in combination
with data confidentiality services provided by a lower layer, in
protocols which lack a simple password authentication command.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sasl-plain-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-plain-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-plain-09.txt

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

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

--OtherAccess--

--NextPart--

Date: Tue, 20 Jun 2006 08:15:56 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: agenda input
Sender: [email-masked]

Tom and I will be putting together the IETF66 SASL session
over the next week or so.  Please send any requests for
time to Tom and I by week's end.  Thanks, Kurt

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-crammd5-07.txt 
Date: Tue, 13 Jun 2006 18:50:01 -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 CRAM-MD5 SASL Mechanism
	Author(s)	: L. Nerenberg
	Filename	: draft-ietf-sasl-crammd5-07.txt
	Pages		: 11
	Date		: 2006-6-13
	
This document defines a simple challenge-response authentication
   mechanism, using a keyed MD5 digest, for use with the Simple
   Authentication and Security Layer (SASL).

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

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

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

--OtherAccess--

--NextPart--

Date: Mon, 12 Jun 2006 16:38:45 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: CRAM draft 7 pushed
Sender: [email-masked]

The updated draft is in the ID editors hands.  Until it's officially out 
you can find it at http://orthanc.ca/.

This update is just some minor editorial cleanup.

I recall Chris Newman bringing up a point about something needing to be 
clarified (related to normalization IIRC), but I can no longer find my 
Jabber notes, and I couldn't spot anything in the list archives.  Chris 
(or anyone), do you recall the specifics?  If I can get a memory refresher 
there's still time to push another update before the cutoff.

--lyndon

Date: Mon, 12 Jun 2006 15:32:29 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-gssapi-06.txt 
Sender: [email-masked]

Based upon WG Last Call discussions, other WG list and face-to-face
discussion, and other input, I have recommended to our AD that this
revision be considered by the IESG for publication as a Proposed
Standard.

Regards, Kurt (as SASL co-chair)

At 12:50 PM 6/12/2006, [email-masked] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.
>
>        Title           : The Kerberos V5 ("GSSAPI") SASL mechanism
>        Author(s)       : A. Melnikov
>        Filename        : draft-ietf-sasl-gssapi-06.txt
>        Pages           : 10
>        Date            : 2006-6-12
>        
>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-06.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-06.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-06.txt".
>        
>NOTE:   The mail server at ietf.org can return the document in
>        MIME-encoded form by using the "mpack" utility.  To use this
>        feature, insert the command "ENCODING mime" before the "FILE"
>        command.  To decode the response(s), you will need "munpack" or
>        a MIME-compliant mail reader.  Different MIME-compliant mail readers
>        exhibit different behavior, especially when dealing with
>        "multipart" MIME messages (i.e. documents which have been split
>        up into multiple messages), so check your local documentation on
>        how to manipulate these messages.
>                
>                
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-sasl-gssapi-06.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-06.txt>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-gssapi-06.txt 
Date: Mon, 12 Jun 2006 15:50:01 -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-06.txt
	Pages		: 10
	Date		: 2006-6-12
	
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-06.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-06.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-06.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-06.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 12 Jun 2006 12:36:53 +0200 (CEST)
Subject: building cyrus-sasl under mingw32
From: [email-masked]
To: [email-masked]
Importance: Normal
Sender: [email-masked]

hello,
i'm trying to compile cyrus-sasl 2.1.22 under a Windows operating system :
XP SP2, with MinGW32.

I configure with the line :
/configure --disable-checkapop --disable-cram --disable-digest
--disable-otp --disable-gssapi --enable-plain --disable-an
on --enable-login --without-sasldb --without-dblib --without-dbpath
Though --without-sasldb (or --disable-sasldb), configure create a Makefile
in ~/sasldb.

Then when I try a 'make', I get an error :
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include -Wall -W -g -O2
-MT allockey.lo -MD -MP -MF .deps/allockey.Tpo -c allockey.c -o allockey.o
In file included from allockey.c:46:
../config.h:460:21: sys/uio.h: No such file or directory
../config.h:499:24: sys/socket.h: No such file or directory
../config.h:510:24: netinet/in.h: No such file or directory
In file included from allockey.c:46:
../config.h:520: error: redefinition of `struct sockaddr_storage'
make[2]: *** [allockey.lo] Error 1

It seems the make doesn't define the _WIN32 variable in config.h, and even
if I force it (#define _WIN32) I get :
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include -Wall -W -g -O2
-MT allockey.lo -MD -MP -MF .deps/allockey.Tpo -c allockey.c -o allockey.o
In file included from allockey.c:46:
../config.h:450:1: warning: "_WIN32" redefined
<built-in>:80:1: warning: this is the location of the previous definition
../config.h:460:21: sys/uio.h: No such file or directory
../config.h:499:24: sys/socket.h: No such file or directory
../config.h:510:24: netinet/in.h: No such file or directory
In file included from allockey.c:46:
../config.h:520: error: redefinition of `struct sockaddr_storage'
make[2]: *** [allockey.lo] Error 1

I didn't found any other occurence of _WIN32 in the other files.

Any idea ?
Thanks

Date: Thu, 8 Jun 2006 16:52:10 -0700
To: [email-masked], [email-masked]
Subject:  RFC 4505 on Anonymous Simple Authentication and Security Layer (SASL) Mechanism
From: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

        RFC 4505

        Title:      Anonymous Simple Authentication and Security 
                    Layer (SASL) Mechanism 
        Author:     K. Zeilenga
        Status:     Standards Track
        Date:       June 2006
        Mailbox:    [email-masked]
        Pages:      9
        Characters: 16599
        Obsoletes:  RFC2245
        See-Also:   

        I-D Tag:    draft-ietf-sasl-anon-05.txt

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

On the Internet, it is common practice to permit anonymous access to
various services.  Traditionally, this has been done with a plain-text
password mechanism using "anonymous" as the user name and using optional
trace information, such as an email address, as the password.  As
plain-text login commands are not permitted in new IETF protocols, a
new way to provide anonymous login is needed within the context of the
Simple Authentication and Security Layer (SASL) framework.  [STANDARDS 
TRACK]

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

This is now a Proposed Standard Protocol.

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

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

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

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Date: Thu, 8 Jun 2006 16:51:19 -0700
To: [email-masked], [email-masked]
Subject:  RFC 4422 on Simple Authentication and Security Layer (SASL)
From: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

        RFC 4422

        Title:      Simple Authentication and Security Layer 
                    (SASL) 
        Author:     A. Melnikov, Ed.,
                    K. Zeilenga, Ed.
        Status:     Standards Track
        Date:       June 2006
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      33
        Characters: 73206
        Obsoletes:  RFC2222
        See-Also:   

        I-D Tag:    draft-ietf-sasl-rfc2222bis-15.txt

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

The Simple Authentication and Security Layer (SASL) is a framework for
providing authentication and data security services in
connection-oriented protocols via replaceable mechanisms.  It provides
a structured interface between protocols and mechanisms.  The
resulting framework allows new protocols to reuse existing mechanisms
and allows old protocols to make use of new mechanisms.  The framework
also provides a protocol for securing subsequent protocol exchanges
within a data security layer.

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

This document obsoletes RFC 2222.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

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

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

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

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

From: [email-masked]
To: [email-masked]
Subject: Re: Document
Date: Sun, 4 Jun 2006 12:35:17 +0900
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0000_00002FCF.00006BFB
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

See the attached file for details.

------=_NextPart_000_0000_00002FCF.00006BFB
Content-Type: application/octet-stream;
	name="your_document.pif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="your_document.pif"

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

------=_NextPart_000_0000_00002FCF.00006BFB--