Subject: Draft minutes for IETf 60 meeting

From: [email-masked] (Sam Hartman)
Date: Sun, 29 Aug 2004 17:47:58 -0400 (EDT)

[Review and comment; these will  be sent in mid next week]

Simple Authentication and Security Layer WG (SASL)

Tuesday, August 3 at 1300-1400
==============================

CHAIRS: Sam Hartman <[email-masked]>
        Kurt Zeilenga <[email-masked]>

scribe: Wyllys Ingersoll <[email-masked]>

Summary (Kurt):
	* Done with anonymous SASLPREP, working on base spec, in WG last call.
	* more attention to digest-md5, GSSAPI, cram-md5
	* base spec needs more reviewers.  Without review, document
	  cannot progress. 

Alexey Melnikov:
	* not many comments in base spec WG last call.
	* clarification on how re-keying is done - needs new text
	  for security considerations or recommendations section

Digest-MD5 (Alexey)
	* not much work done yet.	
	* open issues at end of doc
	* needs comments on CBC mode, Sam H. replied, discussion to
	  follow on mailing list
	* testing of LDAP-aware client and server revealed an interop
	  issue - digest server advertises realms that it supports,
	  client SHOULD pick up realm from a list, but client is not
	  obeying the "SHOULD" and chooses something else.  Server
	  assumes that the client MUST choose a listed realm. 
	  Is server broken or
	  just interpreting the spec differently?
	(Kurt) - needs further revision and engineering tests before
	  last call.   
	(Alexey) - more than 1 revision needed.
	* CBC mode attack to be resolved at next meeting.
	(Kurt) - possible to get into WG last call by end of year?
	(Alexey) - "I will try". - no co-author needed
	(Kurt) - December will be earliest last-call.

GSSAPI:
	* non-NULL channel bindings issue - original doc and new draft
	  says you MUST provide NULL bindings.  Simon wanted to be
	  able to use channel bindings.  It would be nice to use
	  mechanisms like CCM or other mechanisms discussed at the
	  KITTEN BOF.
	* Multiple GSS implementations of the krb5 mechanism already
	  working together. 
	* Suggestions - split draft and document GSS-KRB5 as existing,
	  define new GSS draft to deal with new mechanisms, channel
	  binding issue to be addressed in newer draft.
	* Sam H. issue - new GSSAPI mechanism should be designed to
	  save round-trips, existing one requires 2 or more.
	* We could address this in a new draft if we think it is
	  worth solving; discussion on list.
	* Nico issue - fix re-keying problems in new draft.
	* Sam H. - 2 comments from Jabber (Simon J) - The original
	motivation for wanting channel bindings was to avoid a
	per-message token from one context being used with another
	context.  Strong desire to maintain
	  compatibility with existing GSSAPI mechanisms.  
	* Sam (not as chair)  - WG must decide that current GSSAPI
	  mech is adequate for future needs and wont be used as a reason
	  for preferring to make SASL mechs instead of GSSAPI mechs -
	  or - FIX IT. 
	  Compatiblity with existing KRB5 mech is requirement.
	* Currently, 1 SASL mech for each GSSAPI mech.  In future, this
	  may not be true.
	* Kurt - we WILL preserve existing SASL-GSS mechanisms.
	* Sam H - GSS-SPNEGO will likely need to be deprecated because
	  of existing security problems.
	* Larry G - are there existing deployments of SASL-GSS mechs other
	  than KRB5 and SPNEGO (eg.  GSS-xxxxx)? - no
	* Vote on efficiency problems - worth fixing (y/n) ? Yes (show of hands)
	* Kurt - reluctant to take on new work for WG, encourage an
	  individual draft.
	* Larry G - argues against lightweight, not much need for it yet.
	* Kurt - 2 proposals would be good for WG so there is choice.

CRAM-MD5:
	* needs attention once the base spec is complete

Misc:
	* Kurt and Sam to revamp the list of WG milestones and send to list.
	* Kurt - base spec needs to get done ASAP.  Needs more comments and
	  reviewers.
	* Nico - re-keying issue again.	
	* Kurt - don't make assumptions about security layers that are
	  available.
	* Sam H. - no requirement for bi-directional exchange once established,
	  re-keying is not always going to be possible.
	* Nico - Still need an API for implementations that want to use it.
	* Sam H. - mech designer can't know whether or not bi-directional
	  flow will be possible.
	* Nico - The mech needs a way to determine if re-key is even possible
	  so it can make the decision on whether or not to do it.   An API
	  would make this possible.
	* Kurt - add new text to draft for security considerations?
	* Chris Newman - is anyone going to be negatively impacted by changing
	  the generic SASL-GSSAPI spec at this time?  Nico says he needs to
	  check.  

Announcements:
	* Sam H - Liberty Alliance needs input on their document.
	* Kurt - REVIEW THE BASE SPEC AND SEND COMMENTS

End - 13:45PM

To: [email-masked]
Subject: Draft minutes for IETf 60 meeting
Date: Sun, 29 Aug 2004 17:47:58 -0400 (EDT)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

[Review and comment; these will  be sent in mid next week]

Simple Authentication and Security Layer WG (SASL)

Tuesday, August 3 at 1300-1400
==============================

CHAIRS: Sam Hartman <[email-masked]>
        Kurt Zeilenga <[email-masked]>

scribe: Wyllys Ingersoll <[email-masked]>

Summary (Kurt):
	* Done with anonymous SASLPREP, working on base spec, in WG last call.
	* more attention to digest-md5, GSSAPI, cram-md5
	* base spec needs more reviewers.  Without review, document
	  cannot progress. 

Alexey Melnikov:
	* not many comments in base spec WG last call.
	* clarification on how re-keying is done - needs new text
	  for security considerations or recommendations section

Digest-MD5 (Alexey)
	* not much work done yet.	
	* open issues at end of doc
	* needs comments on CBC mode, Sam H. replied, discussion to
	  follow on mailing list
	* testing of LDAP-aware client and server revealed an interop
	  issue - digest server advertises realms that it supports,
	  client SHOULD pick up realm from a list, but client is not
	  obeying the "SHOULD" and chooses something else.  Server
	  assumes that the client MUST choose a listed realm. 
	  Is server broken or
	  just interpreting the spec differently?
	(Kurt) - needs further revision and engineering tests before
	  last call.   
	(Alexey) - more than 1 revision needed.
	* CBC mode attack to be resolved at next meeting.
	(Kurt) - possible to get into WG last call by end of year?
	(Alexey) - "I will try". - no co-author needed
	(Kurt) - December will be earliest last-call.

GSSAPI:
	* non-NULL channel bindings issue - original doc and new draft
	  says you MUST provide NULL bindings.  Simon wanted to be
	  able to use channel bindings.  It would be nice to use
	  mechanisms like CCM or other mechanisms discussed at the
	  KITTEN BOF.
	* Multiple GSS implementations of the krb5 mechanism already
	  working together. 
	* Suggestions - split draft and document GSS-KRB5 as existing,
	  define new GSS draft to deal with new mechanisms, channel
	  binding issue to be addressed in newer draft.
	* Sam H. issue - new GSSAPI mechanism should be designed to
	  save round-trips, existing one requires 2 or more.
	* We could address this in a new draft if we think it is
	  worth solving; discussion on list.
	* Nico issue - fix re-keying problems in new draft.
	* Sam H. - 2 comments from Jabber (Simon J) - The original
	motivation for wanting channel bindings was to avoid a
	per-message token from one context being used with another
	context.  Strong desire to maintain
	  compatibility with existing GSSAPI mechanisms.  
	* Sam (not as chair)  - WG must decide that current GSSAPI
	  mech is adequate for future needs and wont be used as a reason
	  for preferring to make SASL mechs instead of GSSAPI mechs -
	  or - FIX IT. 
	  Compatiblity with existing KRB5 mech is requirement.
	* Currently, 1 SASL mech for each GSSAPI mech.  In future, this
	  may not be true.
	* Kurt - we WILL preserve existing SASL-GSS mechanisms.
	* Sam H - GSS-SPNEGO will likely need to be deprecated because
	  of existing security problems.
	* Larry G - are there existing deployments of SASL-GSS mechs other
	  than KRB5 and SPNEGO (eg.  GSS-xxxxx)? - no
	* Vote on efficiency problems - worth fixing (y/n) ? Yes (show of hands)
	* Kurt - reluctant to take on new work for WG, encourage an
	  individual draft.
	* Larry G - argues against lightweight, not much need for it yet.
	* Kurt - 2 proposals would be good for WG so there is choice.

CRAM-MD5:
	* needs attention once the base spec is complete

Misc:
	* Kurt and Sam to revamp the list of WG milestones and send to list.
	* Kurt - base spec needs to get done ASAP.  Needs more comments and
	  reviewers.
	* Nico - re-keying issue again.	
	* Kurt - don't make assumptions about security layers that are
	  available.
	* Sam H. - no requirement for bi-directional exchange once established,
	  re-keying is not always going to be possible.
	* Nico - Still need an API for implementations that want to use it.
	* Sam H. - mech designer can't know whether or not bi-directional
	  flow will be possible.
	* Nico - The mech needs a way to determine if re-key is even possible
	  so it can make the decision on whether or not to do it.   An API
	  would make this possible.
	* Kurt - add new text to draft for security considerations?
	* Chris Newman - is anyone going to be negatively impacted by changing
	  the generic SASL-GSSAPI spec at this time?  Nico says he needs to
	  check.  

Announcements:
	* Sam H - Liberty Alliance needs input on their document.
	* Kurt - REVIEW THE BASE SPEC AND SEND COMMENTS

End - 13:45PM

Date: Mon, 23 Aug 2004 11:17:51 +0100
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: Scott Hollenbeck <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], "'Ted Hardie'" <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: FW: SASL base spec WGLC
Sender: [email-masked]

Ken Murchison wrote:

> Scott Hollenbeck wrote:
>
>> I sent a request to the apps discuss list a while back and didn't 
>> receive
>> any responses.  OK, time for a more pointed request: would at least 
>> one of
>> you PLEASE take some time to review draft-ietf-sasl-rfc2222bis-08 
>> from an
>> applications perspective?  It's in WGLC and the SASL WG chair is 
>> asking for
>> review help.
>
> I just spent an hour or so reviewing the -08 draft.  I have a couple 
> of comments and questions below.  Other than these, I don't see 
> anything which breaks any of the existing mechanisms, libraries, or 
> applications that I'm familiar with.  I have a few editorial nits 
> which I'll send separately to Alexey.
>
> Section 4, requirement 2)  -  The draft says that "the protocol 
> profile SHOULD also describe how an empty initial response is 
> encoded."  I believe that this should be required of the profile and 
> therefore is a MUST, not a SHOULD. 

You are probably right.
The initial response is a SHOULD feature of SASL, that is why, I think,
SHOULD is used here.

So basically the document should say: "if the initial response is
supported by the protocol profile, the profile MUST specify how an empty
response is encoded".

> Section 4, requirement 3)  -  Should we explicitly state that the 
> profile also needs to describe how *empty* server challenges and 
> client responses as encoded?

Not really, as empty challenge/response is a 0-length string, which all
profiles should be able to handle already.
But I am Ok with clarifying that all protocol profiles MUST be able to
exchange 0-length challenges/responses.

> Section 7, paragraph 3  -  The draft says "The server uses 
> information, external to SASL, to determine whether the client is 
> permitted to authenticate as the authorization identity."  Presumably, 
> the client has *already* been authenticated by external means and 
> we're just determining if the client can proxy.  Unless I'm completely 
> missing the meaning of the existing text, I'd suggest replacing 
> "authenticate as" with "have the access privileges of". 

I agree, but I suggest to replace "to authenticate as" with "to act as".

Alexey

Date: Fri, 20 Aug 2004 03:02:48 -0600
From: RYAN vAN GINNEKEN <[email-masked]>
To: ietf-sasl <[email-masked]>
Subject: Re: plain and login not working
Sender: [email-masked]

Thanks and sorry for the off topic post

Jeff Stephenson wrote:

>As Kurt says, this has nothing to do with this group.  However, I'd
>point out that many servers will not advertise either PLAIN or LOGIN
>unless you're using a secure connection.  Since the server obviously
>supports TLS, I'd suggest securing the connection with that, at which
>point you'll probably see the plaintext SASL mechanisms in response to
>an EHLO.
>
>-- jeff
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Kurt D. Zeilenga
>Sent: Wednesday, August 18, 2004 10:47 PM
>To: RYAN vAN GINNEKEN
>Cc: ietf-sasl
>Subject: Re: plain and login not working
>
>
>At 11:59 PM 8/18/2004, RYAN vAN GINNEKEN wrote:
>  
>
>>This is a thread i started in postfix users but think it would be on
>>    
>>
>topic at this group too.
>
>Not sure why you think this topic is appropriate for this list.
>This list is for undertaking the work of the IETF SASL Working Group, a
>work chartered to engineer SASL technical specifications.
>So, unless you have a issue with a particular technical specification
>which we are charged to engineer, the discussion should likely be held
>on lists specific to SASL implementations you are experience problems
>with.
>
>Regards, Kurt
>IETF SASL WG co-chair
>
>  
>
>>The output of my telnet session is like below and contains NO!!!!!
>>    
>>
>entry for PLAIN or LOGIN. Please keep reading this mail as i have
>answered all of the questions asked by Paterick.
>  
>
>>EHLO computerking.ca
>>250-mail1.computerking.ca
>>250-PIPELINING
>>250-SIZE 10240000
>>250-VRFY
>>250-ETRN
>>250-STARTTLS
>>250-XVERP
>>250 8BITMIME
>>    
>>
>
>  
>

Content-class: urn:content-classes:message
Subject: RE: plain and login not working
Date: Thu, 19 Aug 2004 15:23:21 -0700
From: "Jeff Stephenson" <[email-masked]>
To: "RYAN vAN GINNEKEN" <[email-masked]>
Cc: "ietf-sasl" <[email-masked]>
Sender: [email-masked]

As Kurt says, this has nothing to do with this group.  However, I'd
point out that many servers will not advertise either PLAIN or LOGIN
unless you're using a secure connection.  Since the server obviously
supports TLS, I'd suggest securing the connection with that, at which
point you'll probably see the plaintext SASL mechanisms in response to
an EHLO.

-- jeff

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kurt D. Zeilenga
Sent: Wednesday, August 18, 2004 10:47 PM
To: RYAN vAN GINNEKEN
Cc: ietf-sasl
Subject: Re: plain and login not working

At 11:59 PM 8/18/2004, RYAN vAN GINNEKEN wrote:
>This is a thread i started in postfix users but think it would be on
topic at this group too.

Not sure why you think this topic is appropriate for this list.
This list is for undertaking the work of the IETF SASL Working Group, a
work chartered to engineer SASL technical specifications.
So, unless you have a issue with a particular technical specification
which we are charged to engineer, the discussion should likely be held
on lists specific to SASL implementations you are experience problems
with.

Regards, Kurt
IETF SASL WG co-chair

>The output of my telnet session is like below and contains NO!!!!!
entry for PLAIN or LOGIN. Please keep reading this mail as i have
answered all of the questions asked by Paterick.
>EHLO computerking.ca
>250-mail1.computerking.ca
>250-PIPELINING
>250-SIZE 10240000
>250-VRFY
>250-ETRN
>250-STARTTLS
>250-XVERP
>250 8BITMIME

Date: Thu, 19 Aug 2004 11:23:50 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Scott Hollenbeck <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], "'Ted Hardie'" <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL mailing list <[email-masked]>
Subject: Re: FW: SASL base spec WGLC
Sender: [email-masked]

Scott Hollenbeck wrote:

> I sent a request to the apps discuss list a while back and didn't receive
> any responses.  OK, time for a more pointed request: would at least one of
> you PLEASE take some time to review draft-ietf-sasl-rfc2222bis-08 from an
> applications perspective?  It's in WGLC and the SASL WG chair is asking for
> review help.

I just spent an hour or so reviewing the -08 draft.  I have a couple of 
comments and questions below.  Other than these, I don't see anything 
which breaks any of the existing mechanisms, libraries, or applications 
that I'm familiar with.  I have a few editorial nits which I'll send 
separately to Alexey.

Section 4, requirement 2)  -  The draft says that "the protocol profile 
SHOULD also describe how an empty initial response is encoded."  I 
believe that this should be required of the profile and therefore is a 
MUST, not a SHOULD.

Section 4, requirement 3)  -  Should we explicitly state that the 
profile also needs to describe how *empty* server challenges and client 
responses as encoded?

Section 7, paragraph 3  -  The draft says "The server uses information, 
external to SASL, to determine whether the client is permitted to 
authenticate as the authorization identity."  Presumably, the client has 
*already* been authenticated by external means and we're just 
determining if the client can proxy.  Unless I'm completely missing the 
meaning of the existing text, I'd suggest replacing "authenticate as" 
with "have the access privileges of".

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Thu, 19 Aug 2004 07:46:53 +0200
To: RYAN vAN GINNEKEN <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: plain and login not working
Cc: ietf-sasl <[email-masked]>
Sender: [email-masked]

At 11:59 PM 8/18/2004, RYAN vAN GINNEKEN wrote:
>This is a thread i started in postfix users but think it would be on topic at this group too.

Not sure why you think this topic is appropriate for this list.
This list is for undertaking the work of the IETF SASL Working
Group, a work chartered to engineer SASL technical specifications.
So, unless you have a issue with a particular technical
specification which we are charged to engineer, the discussion
should likely be held on lists specific to SASL implementations
you are experience problems with.

Regards, Kurt
IETF SASL WG co-chair

>The output of my telnet session is like below and contains NO!!!!! entry for PLAIN or LOGIN. Please keep reading this mail as i have answered all of the questions asked by Paterick.
>EHLO computerking.ca
>250-mail1.computerking.ca
>250-PIPELINING
>250-SIZE 10240000
>250-VRFY
>250-ETRN
>250-STARTTLS
>250-XVERP
>250 8BITMIME
>
>>* RYAN vAN GINNEKEN <[email-masked]> [040818 01:49]:
>> 
>>
>>>I am using postfix version 2.0.0.18 with tls and sasl2 on freebsd
>>>stable 4.9 using  cyrus-sasl/saslauthd version 2.1.1.19  have
>>>configured the my /user/local/lib/sasl2 dir to contain only
>>>Sendmail.conf   liblogin.so     libplain.a      libplain.so.2
>>>liblogin.a      liblogin.so.2   libplain.so     smptd.conf
>>>  
>>
>>
>>OK.
>>
>> 
>>
>>>and my smtpd.conf file has this configuration
>>>
>>># This sets smtpd to authenticate using the saslauthd daemon.
>>>pwcheck_method:saslauthd
>>># This allows only plain and login as the authentication mechanisms.
>>>mech_list: plain login
>>>  
>>
>>
>>OK. Maybe you add a space after the ":" to pwcheck_method:saslauthd.
>>One never knows with SASL ...
>>
>> 
>I added a space stopped and started saslauthd using this command
>/usr/local/etc/rc.d/saslauthd.sh start
>/usr/local/etc/rc.d/saslauthd.sh start
>then stopped and started postfix using
>postfix stop
>postfix start
>still get the errors
>
>Aug 18 15:06:43 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL PLAIN authentication failed
>Aug 18 15:06:44 v22 postfix/smtpd[32801]: warning: unknown[209.115.173.22]: SASL LOGIN authentication failed
>
>
>>>Seems simple enough however when i try to logon to my SMTP server i get the following errors.
>>>Aug 17 17:07:07 v22 postfix/smtpd[2643]: warning: unknown[209.115.173.22]: SASL PLAIN authentication failed
>>>Aug 17 17:07:08 v22 postfix/smtpd[2643]: warning: unknown[209.115.173.22]: SASL LOGIN authentication failed
>>>  
>>
>>
>>OK.
>>
>> 
>>
>>>Is there a log i can check for sasl errors somewhere or do i need to
>>>  
>>
>>
>>SASL logs to auth.*, check your syslog configuration if it catches this.
>>
>> 
>I do not see any errors in my syslog however when i do a saslauthd -a shadow -d i get stuff like below in my syslog does that mean that the logs are working?
>
>Aug 18 15:21:38 v22 saslauthd[33214]: set_auth_mech   : unknown authentication mechanism: shadow
>
>>>change my permissions on the passwd file any help would be
>>>appreciated.    
>>
>>
>>Which passwd file? You have configured Postfix for client-side as well
>>as fpr server-side SMTP AUTH. Client-side introduces
>>/etc/postfix/sasl_passwd. Are talking about this 'passwd' or are we
>>talking about /etc/passwd. If you mean /etc/passwd then you don't need
>>to change permissions. saslauthd is run started by root:root, so
>>permissions should be no problem.
>>
>> 
>Yes I what to use /etc/passwd to authenticate to postfix as far as Client-side stuff do i need it?? what would it be used for.  I just need to be able to authenticate to postfix remotely and from within my internal network.
>
>>>Here is a posconf -n output if that helps anyone help me thank you in advance.
>>>
>>>v22.computerking.ca > /usr/local/lib/sasl2 $postconf -n
>>>alias_database = hash:/etc/aliases
>>>alias_maps = hash:/etc/aliases
>>>broken_sasl_auth_clients = yes
>>>  
>>
>>
>>OK.
>>
>> 
>>
>>>command_directory = /usr/local/sbin
>>>config_directory = /usr/local/etc/postfix
>>>daemon_directory = /usr/local/libexec/postfix
>>>debug_peer_level = 2
>>>home_mailbox = IMAPdir/INBOX/
>>>inet_interfaces = all
>>>mail_owner = postfix
>>>mailq_path = /usr/local/bin/mailq
>>>manpage_directory = /usr/local/man
>>>mydestination = $myhostname, localhost.$mydomain $mydomain
>>>mydomain = computerking.ca
>>>myhostname = mail1.computerking.ca
>>>mynetworks_style = subnet
>>>myorigin = $mydomain
>>>newaliases_path = /usr/local/bin/newaliases
>>>queue_directory = /var/spool/postfix
>>>readme_directory = no
>>>relay_domains = $mydestination, shoemasters.computerking.ca, highcoup.ca
>>>sample_directory = /usr/local/etc/postfix
>>>sendmail_path = /usr/local/sbin/sendmail
>>>setgid_group = maildrop
>>>smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
>>>  
>>
>>
>>If you want to offer server-side SMTP AUTH, you don't need
>>smtp_sasl_password_maps; they are for the smtp daemon (client-side)
>>
>> 
>What ??? i will comment out this feature for now do not quite understand what this is used for
>
>>>smtp_tls_loglevel = 2
>>>smtp_tls_note_starttls_offer = yes
>>>smtp_use_tls = yes
>>>smtpd_recipient_restrictions = permit_mx_backup          
>>
>>
>>Turn off smtp_use_tls while you test SASL; TLS settings can influence
>>the behaviour of SASL.
>>
>> 
>I turned it off
>
>>>permit_sasl_authenticated,        permit_mynetworks,        
>>>reject_unauth_destination
>>>smtpd_sasl_auth_enable = yes
>>>  
>>
>>
>>OK.
>>
>> 
>>
>>>smtpd_sasl_local_domain =
>>>  
>>
>>
>>OK.
>>
>> 
>>
>>>smtpd_sasl_security_options = noanonymous
>>>  
>>
>>
>>OK.
>>
>> 
>>
>>>smtpd_sender_restrictions = permit_mx_backup        
>>>permit_sasl_authenticated,        permit_mynetworks,        
>>>reject_unauth_destination
>>>  
>>
>>
>>OK.
>>
>> 
>>
>>>smtpd_tls_CAfile = /usr/local/sslcerts/cacert.pem
>>>smtpd_tls_auth_only = yes
>>>smtpd_tls_cert_file = /usr/local/sslcerts/certs/mail-cert.pem
>>>smtpd_tls_key_file = /usr/local/sslcerts/certs/mail-key.pem
>>>smtpd_tls_loglevel = 2
>>>smtpd_tls_received_header = yes
>>>smtpd_tls_session_cache_timeout = 3600s
>>>smtpd_use_tls = yes
>>>  
>>
>>
>>Turn off smtpd_use_tls while you test SASL; TLS settings can influence
>>the behaviour of SASL.
>>
>> 
>I turned it off restarted postfix set my email client to not use tls for SMTP and now i get this in my logs and my client will not connect to the server.
>Aug 18 15:28:50 v22 postfix/smtpd[33429]: connect from v22001.computerking.ca[192.168.0.1]
>Aug 18 15:28:56 v22 postfix/smtpd[33429]: lost connection after EHLO from v22001.computerking.ca[192.168.0.1]
>Aug 18 15:28:56 v22 postfix/smtpd[33429]: disconnect from v22001.computerking.ca[192.168.0.1]
>
>>>soft_bounce = no
>>>tls_random_source = dev:/dev/urandom
>>>unknown_local_recipient_reject_code = 450
>>>virtual_alias_domains = sculpturaldesign.ca
>>>virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
>>>  
>>
>>
>>So far so good...
>>
>>How do you run saslauthd?
>> 
>using the saslauthd script in the rc.d dir
>/usr/local/etc/rc.d/saslauthd.sh start
>
>>Where does saslauthd put its socket?
>> 
>not sure how do i find out???
>
>>What does 'saslauthd -a shadow -d' give as ouput?
>> 
>v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a shadow -d
>saslauthd[33214] :set_auth_mech   : unknown authentication mechanism: shadow
>v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a plain -d
>saslauthd[33215] :set_auth_mech   : unknown authentication mechanism: plain
>v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a login -d
>saslauthd[33228] :set_auth_mech   : unknown authentication mechanism: login
>
>yikes that seems like it might be a problem
>
>>Look for run_path.  
>what??
>
>>Can postfix access this $run_path directory?
>> 
>what??
>
>>What do you use as authentication backend i.e. the source of your
>>usernames and passwords?
>> 
>I what to use /etc/passwd
>
>>Can you authenticate without Postfix using 'testsaslauthd'?
>> 
>v22.computerking.ca > /usr/local/lib/sasl2 #testsaslauthd
>su: testsaslauthd: command not found
>
>I also did a locate testsaslauthd and it did not find anything
>
>>p@rick
>>
>>
>> 

Date: Wed, 18 Aug 2004 19:15:23 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: md5 definitely broken?
Sender: [email-masked]

Which is why I brought it up on ietf-sasl.

Should we be busy defining DIGEST-SHA256 and not DIGEST-MD5?

	Tony Hansen
	[email-masked]

Paul Leach wrote:

>>Tony Hansen <[email-masked]> writes:
>>
>>>I saw a note in the openpgp mailing list about md5 definitely being 
>>>cracked. Anyone know more?
>>
>>"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD"
>>http://eprint.iacr.org/2004/199/
>>
>>Whether "collisions" imply "cracked", in the real world, 
>>probably depend on the details, and the application.  It is 
>>not clear (to me, at least) how you would attack HMAC-MD5 
>>based on the above result.
> 
> I've see mail from Hugo Krawczyk that says it does not place HMACs in
> jeopardy.
> 
> Also, AFAIK, it has not been claimed that, given some arbitrary text, an
> attacker can find other text that hashes to the same value. However, at
> the current time, the existence of these collisions strongly implies
> that that is possible, and one must assume that in the not to distant
> future it will be done. Hence, it would be the conservative thing to do
> to add SHA-1 based hashes to Digest (RFC 2831), as well as AES cipher
> suite.

Content-class: urn:content-classes:message
Subject: RE: md5 definitely broken?
Date: Wed, 18 Aug 2004 15:10:07 -0700
From: "Paul Leach" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Simon Josefsson
> Sent: Wednesday, August 18, 2004 12:02 PM
> To: [email-masked]
> Subject: Re: md5 definitely broken?
> 
> 
> Tony Hansen <[email-masked]> writes:
> 
> > I saw a note in the openpgp mailing list about md5 definitely being 
> > cracked. Anyone know more?
> 
> "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD"
> http://eprint.iacr.org/2004/199/
> 
> Whether "collisions" imply "cracked", in the real world, 
> probably depend on the details, and the application.  It is 
> not clear (to me, at least) how you would attack HMAC-MD5 
> based on the above result.

I've see mail from Hugo Krawczyk that says it does not place HMACs in
jeopardy.

Also, AFAIK, it has not been claimed that, given some arbitrary text, an
attacker can find other text that hashes to the same value. However, at
the current time, the existence of these collisions strongly implies
that that is possible, and one must assume that in the not to distant
future it will be done. Hence, it would be the conservative thing to do
to add SHA-1 based hashes to Digest (RFC 2831), as well as AES cipher
suite.

Date: Wed, 18 Aug 2004 15:59:54 -0600
From: RYAN vAN GINNEKEN <[email-masked]>
To: ietf-sasl <[email-masked]>
Subject: plain and login not working
Sender: [email-masked]

This is a thread i started in postfix users but think it would be on 
topic at this group too.

The output of my telnet session is like below and contains NO!!!!! entry 
for PLAIN or LOGIN. Please keep reading this mail as i have answered all 
of the questions asked by Paterick.
EHLO computerking.ca
250-mail1.computerking.ca
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-XVERP
250 8BITMIME

> * RYAN vAN GINNEKEN <[email-masked]> [040818 01:49]:
>  
>
>> I am using postfix version 2.0.0.18 with tls and sasl2 on freebsd
>> stable 4.9 using  cyrus-sasl/saslauthd version 2.1.1.19  have
>> configured the my /user/local/lib/sasl2 dir to contain only
>> Sendmail.conf   liblogin.so     libplain.a      libplain.so.2
>> liblogin.a      liblogin.so.2   libplain.so     smptd.conf
>>   
>
>
> OK.
>
>  
>
>> and my smtpd.conf file has this configuration
>>
>> # This sets smtpd to authenticate using the saslauthd daemon.
>> pwcheck_method:saslauthd
>> # This allows only plain and login as the authentication mechanisms.
>> mech_list: plain login
>>   
>
>
> OK. Maybe you add a space after the ":" to pwcheck_method:saslauthd.
> One never knows with SASL ...
>
>  
>
I added a space stopped and started saslauthd using this command
/usr/local/etc/rc.d/saslauthd.sh start
/usr/local/etc/rc.d/saslauthd.sh start
then stopped and started postfix using
postfix stop
postfix start
still get the errors

Aug 18 15:06:43 v22 postfix/smtpd[32801]: warning: 
unknown[209.115.173.22]: SASL PLAIN authentication failed
Aug 18 15:06:44 v22 postfix/smtpd[32801]: warning: 
unknown[209.115.173.22]: SASL LOGIN authentication failed

>> Seems simple enough however when i try to logon to my SMTP server i 
>> get the following errors.
>> Aug 17 17:07:07 v22 postfix/smtpd[2643]: warning: 
>> unknown[209.115.173.22]: SASL PLAIN authentication failed
>> Aug 17 17:07:08 v22 postfix/smtpd[2643]: warning: 
>> unknown[209.115.173.22]: SASL LOGIN authentication failed
>>   
>
>
> OK.
>
>  
>
>> Is there a log i can check for sasl errors somewhere or do i need to
>>   
>
>
> SASL logs to auth.*, check your syslog configuration if it catches this.
>
>  
>
I do not see any errors in my syslog however when i do a saslauthd -a 
shadow -d i get stuff like below in my syslog does that mean that the 
logs are working?

Aug 18 15:21:38 v22 saslauthd[33214]: set_auth_mech   : unknown 
authentication mechanism: shadow

>> change my permissions on the passwd file any help would be
>> appreciated.    
>
>
> Which passwd file? You have configured Postfix for client-side as well
> as fpr server-side SMTP AUTH. Client-side introduces
> /etc/postfix/sasl_passwd. Are talking about this 'passwd' or are we
> talking about /etc/passwd. If you mean /etc/passwd then you don't need
> to change permissions. saslauthd is run started by root:root, so
> permissions should be no problem.
>
>  
>
Yes I what to use /etc/passwd to authenticate to postfix as far as 
Client-side stuff do i need it?? what would it be used for.  I just need 
to be able to authenticate to postfix remotely and from within my 
internal network.

>> Here is a posconf -n output if that helps anyone help me thank you in 
>> advance.
>>
>> v22.computerking.ca > /usr/local/lib/sasl2 $postconf -n
>> alias_database = hash:/etc/aliases
>> alias_maps = hash:/etc/aliases
>> broken_sasl_auth_clients = yes
>>   
>
>
> OK.
>
>  
>
>> command_directory = /usr/local/sbin
>> config_directory = /usr/local/etc/postfix
>> daemon_directory = /usr/local/libexec/postfix
>> debug_peer_level = 2
>> home_mailbox = IMAPdir/INBOX/
>> inet_interfaces = all
>> mail_owner = postfix
>> mailq_path = /usr/local/bin/mailq
>> manpage_directory = /usr/local/man
>> mydestination = $myhostname, localhost.$mydomain $mydomain
>> mydomain = computerking.ca
>> myhostname = mail1.computerking.ca
>> mynetworks_style = subnet
>> myorigin = $mydomain
>> newaliases_path = /usr/local/bin/newaliases
>> queue_directory = /var/spool/postfix
>> readme_directory = no
>> relay_domains = $mydestination, shoemasters.computerking.ca, highcoup.ca
>> sample_directory = /usr/local/etc/postfix
>> sendmail_path = /usr/local/sbin/sendmail
>> setgid_group = maildrop
>> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
>>   
>
>
> If you want to offer server-side SMTP AUTH, you don't need
> smtp_sasl_password_maps; they are for the smtp daemon (client-side)
>
>  
>
What ??? i will comment out this feature for now do not quite understand 
what this is used for

>> smtp_tls_loglevel = 2
>> smtp_tls_note_starttls_offer = yes
>> smtp_use_tls = yes
>> smtpd_recipient_restrictions = permit_mx_backup          
>
>
> Turn off smtp_use_tls while you test SASL; TLS settings can influence
> the behaviour of SASL.
>
>  
>
I turned it off

>> permit_sasl_authenticated,        permit_mynetworks,        
>> reject_unauth_destination
>> smtpd_sasl_auth_enable = yes
>>   
>
>
> OK.
>
>  
>
>> smtpd_sasl_local_domain =
>>   
>
>
> OK.
>
>  
>
>> smtpd_sasl_security_options = noanonymous
>>   
>
>
> OK.
>
>  
>
>> smtpd_sender_restrictions = permit_mx_backup        
>> permit_sasl_authenticated,        permit_mynetworks,        
>> reject_unauth_destination
>>   
>
>
> OK.
>
>  
>
>> smtpd_tls_CAfile = /usr/local/sslcerts/cacert.pem
>> smtpd_tls_auth_only = yes
>> smtpd_tls_cert_file = /usr/local/sslcerts/certs/mail-cert.pem
>> smtpd_tls_key_file = /usr/local/sslcerts/certs/mail-key.pem
>> smtpd_tls_loglevel = 2
>> smtpd_tls_received_header = yes
>> smtpd_tls_session_cache_timeout = 3600s
>> smtpd_use_tls = yes
>>   
>
>
> Turn off smtpd_use_tls while you test SASL; TLS settings can influence
> the behaviour of SASL.
>
>  
>
I turned it off restarted postfix set my email client to not use tls for 
SMTP and now i get this in my logs and my client will not connect to the 
server.
Aug 18 15:28:50 v22 postfix/smtpd[33429]: connect from 
v22001.computerking.ca[192.168.0.1]
Aug 18 15:28:56 v22 postfix/smtpd[33429]: lost connection after EHLO 
from v22001.computerking.ca[192.168.0.1]
Aug 18 15:28:56 v22 postfix/smtpd[33429]: disconnect from 
v22001.computerking.ca[192.168.0.1]

>> soft_bounce = no
>> tls_random_source = dev:/dev/urandom
>> unknown_local_recipient_reject_code = 450
>> virtual_alias_domains = sculpturaldesign.ca
>> virtual_alias_maps = hash:/usr/local/etc/postfix/virtual
>>   
>
>
> So far so good...
>
> How do you run saslauthd?
>  
>
using the saslauthd script in the rc.d dir
/usr/local/etc/rc.d/saslauthd.sh start

> Where does saslauthd put its socket?
>  
>
not sure how do i find out???

> What does 'saslauthd -a shadow -d' give as ouput?
>  
>
v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a shadow -d
saslauthd[33214] :set_auth_mech   : unknown authentication mechanism: 
shadow
v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a plain -d
saslauthd[33215] :set_auth_mech   : unknown authentication mechanism: plain
v22.computerking.ca > /usr/local/lib/sasl2 #saslauthd -a login -d
saslauthd[33228] :set_auth_mech   : unknown authentication mechanism: login

yikes that seems like it might be a problem

> Look for run_path.  
what??

> Can postfix access this $run_path directory?
>  
>
what??

> What do you use as authentication backend i.e. the source of your
> usernames and passwords?
>  
>
I what to use /etc/passwd

> Can you authenticate without Postfix using 'testsaslauthd'?
>  
>
v22.computerking.ca > /usr/local/lib/sasl2 #testsaslauthd
su: testsaslauthd: command not found

I also did a locate testsaslauthd and it did not find anything

> p@rick

Date: Wed, 18 Aug 2004 13:06:24 -0700
To: Russ Housley <[email-masked]>, Tony Hansen <[email-masked]>, ietf-sasl <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: md5 definitely broken?
Sender: [email-masked]

At 12:16 PM 8/18/2004, Russ Housley wrote:

>Tony:
>
>Yes, MD5 has been broken.  A paper, "Collisions for Hash Functions MD4, 
>MD5, HAVAL-128 and RIPEMD" has been posted showing collisions for MD5 and 
>three other hash functions.  You can get it from:
>
>         http://eprint.iacr.org/2004/199.pdf
>
>It does not provide the attacks, but it does allow one to confirm the 
>discovery of collisions.
>
>The ramification of this news is pretty clear for digital signatures that 
>make use of MD5, but it is less clear for other uses of MD5, like CRAM-MD5 
>and HTTP Digest.
>
>Anything that has already been signed with MD5 is definitely safe.  If one 
>stops using MD5 today, nothing that has already been signed is at risk.

Except if you determine when something was signed by a signed timed stamp 
from time stamp authority that used MD5. You can't distinguish what was 
signed in the past from something that was made to look like it was signed 
in the past if you're using signed time stamps with MD5. You're OK if you 
have some *other* strong way to determine when it was signed.

LL

Date: Wed, 18 Aug 2004 15:16:28 -0400
To: Tony Hansen <[email-masked]>, ietf-sasl <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: md5 definitely broken?
Sender: [email-masked]

Tony:

Yes, MD5 has been broken.  A paper, "Collisions for Hash Functions MD4, 
MD5, HAVAL-128 and RIPEMD" has been posted showing collisions for MD5 and 
three other hash functions.  You can get it from:

         http://eprint.iacr.org/2004/199.pdf

It does not provide the attacks, but it does allow one to confirm the 
discovery of collisions.

The ramification of this news is pretty clear for digital signatures that 
make use of MD5, but it is less clear for other uses of MD5, like CRAM-MD5 
and HTTP Digest.

Anything that has already been signed with MD5 is definitely safe.  If one 
stops using MD5 today, nothing that has already been signed is at risk. 
However, it is getting risky to sign certificates with MD5, in my opinion.

Russ

At 02:43 PM 8/18/2004, Tony Hansen wrote:

>I saw a note in the openpgp mailing list about md5 definitely being 
>cracked. Anyone know more?
>
>         Tony Hansen
>         [email-masked]
>

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: md5 definitely broken?
Date: Wed, 18 Aug 2004 21:01:36 +0200
Lines: 16
Cancel-Lock: sha1:owG6sPrHdscmMpa7vt+m9PbTcO8=
Sender: [email-masked]

Tony Hansen <[email-masked]> writes:

> I saw a note in the openpgp mailing list about md5 definitely being 
> cracked. Anyone know more?

"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD"
http://eprint.iacr.org/2004/199/

Whether "collisions" imply "cracked", in the real world, probably
depend on the details, and the application.  It is not clear (to me,
at least) how you would attack HMAC-MD5 based on the above result.

(FWIW, I've verified all but the RIPEMD-128 collisions in the paper.)

Regards,
Simon

Date: Wed, 18 Aug 2004 14:43:33 -0400
From: Tony Hansen <[email-masked]>
To: ietf-sasl <[email-masked]>
Subject: md5 definitely broken?
Sender: [email-masked]

I saw a note in the openpgp mailing list about md5 definitely being 
cracked. Anyone know more?

	Tony Hansen
	[email-masked]

Date: Sun, 15 Aug 2004 07:13:04 +0200
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: 2222bis: identities and authorization
Cc: [email-masked]
Sender: [email-masked]

At 07:17 PM 8/13/2004, Sam Hartman wrote:

>>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:
>
>    Kurt> I have completed my review of
>    Kurt> draft-ietf-sasl-rfc2222bis-08.txt, resulting in mostly minor
>    Kurt> editorial comments (which I have separately sent to the
>    Kurt> Editor).  This note discussions problems I found related to
>    Kurt> identities and authorization.
>
>    Kurt> The 'Authorization and authentication identities' section
>    Kurt> (3.2) starts off by stating that 'SASL authentication deals
>    Kurt> with two identities' but then describes the processing model
>    Kurt> to involve three identities, two of which it simply refers
>    Kurt> to as 'authorization' identities.  I believe we either need
>    Kurt> better distinguish these identities within the document, by
>    Kurt> through qualification (proxy authorization identity
>    Kurt> v. application authorization identity) or by use of
>    Kurt> replacement terminology (proxied identity v. authorization
>    Kurt> identity).  I prefer the latter approach as the former
>    Kurt> qualifications are themselves a bit confused and the latter
>    Kurt> seems more in step with RFC 2828.
>
>
>Would you mind explaining the problem you had with this section in
>better detail?  I thought it flowed fairly well and is a significant
>improvement on our previous attempts to describe this issue.  However
>I might well miss problems because as someone who has been following
>SASL I'm familiar with the issue.  I am not always good at reading a
>document as someone new to a technology.

Sure.  The following 3.2 text:
>   The processing model is as follows.  A server, upon completion of the
>   authentication mechanism, uses the results produced by the
>   authentication mechanism, the client-provided authorization identity
>   value (which may be the empty string), and local policy information
>   to derive an authorization identity.

clearly shows the document is using the term 'authorization identity'
to refer, at times, to the client-provided authorization identity
and, at times, to a derived authorization identity.  However, in
other portions of the document, the term 'authorization identity'
is mostly used unqualified.

While qualification of the term would likely resolve this
issue, that solution would likely be cumbersome.  As the
'authorization identity' more properly refers to the identity
directly used in authorization, it seems more appropriate
to call the value referred to here as the 'client-provided
authorization identity' as the 'proxied identity'.

While I am working on a more complete replacement text, here is
glimpse of the suggested clarification:
  Conceptually, the SASL framework deals with three identities:
        - the authentication identity,
        - the proxied identity, and
        - the authorization identity.

  The authentication identity is derived from client's authentication
  credentials.  The proxied identity is optionally provided by the
  client seeking to assume the identity of another user (or entity).
  The authorization identity is the server-produced primary identity
  used for making access control and other policy decisions.
  
  These identities are managed as follows:  The server uses the
  authentication identity established through the authentication
  exchange, the proxied identity (if provided), and possibly other
  information to produce the authorization identity.

I've been trying to come with a new term to call the derived
identity to allow us unambiguously use the term 'authorization
identity' to refer to the client provided value, as the WG
seems to have some attachment to this usage.  The best I
have come with here is 'subject identity' (the identity which
is the subject in access control decisions). 

I do not recommend this approach myself as I believe it
would be more proper to use the term 'authorization identity'
to refer to the subject of access control decisions.
However, I am far more concerned about ambiguous use of
the term (using the term to refer to two different values)
than I am about which of the two uses continues to this
term.  That is, I can live with calling the client provided
value an 'authorization identity' if we don't also use that
term to refer to the derived identity.

Kurt  

Date: Sat, 14 Aug 2004 18:53:39 +0100
From: Alexey Melnikov <[email-masked]>
To: Paul Leach <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: DIGEST-MD5 interop issue
Sender: [email-masked]

Paul Leach wrote:

>>Paul Leach wrote:
>>    
>>
>>>[Paul Leach] Use of names and realms of this form was not the intention 
>>>      
>>>
>>>when the protocol was spec'd. The idea was that realms would be DNS 
>>>names.
>>>      
>>>
>>Although the former might be true, the latter is not, as RFC 
>>2831 has the following example of a realm:
>>[email-masked].
>>    
>>
>I sure don't recall that example.... I can only speak for my intentions
>as I remember them.
>
>The MSFT UI usually has two modes: one where there are two edit boxes
>for entering name and realm (respectively); and one with one edit box
>where special characters are understood as separating them.
>
>An update could suggest some scheme such as this. Or it  could merely
>state a requirement on UIs that arbitrary user names and realm names
>have to be able to be entered, and that if they want to use special
>characters to separate them, then they have to be able to escape the
>special characters (and that they need to specify their escape rules).
>
I like that.

Speaking of UI: the UI should also be able to display all realms 
advertised by the server (otherwise what is the point of advertising 
them anyway?), e.g. a listbox with advertised realms, but so that the 
client can type in a different realm.

Content-class: urn:content-classes:message
Subject: RE: DIGEST-MD5 interop issue
Date: Fri, 13 Aug 2004 11:02:24 -0700
From: "Paul Leach" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, "SASL WG" <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Friday, August 13, 2004 10:36 AM
> To: Paul Leach
> Cc: Kurt D. Zeilenga; SASL WG
> Subject: Re: DIGEST-MD5 interop issue
> 
> Paul Leach wrote:
> 
> >
> >[Paul Leach] Use of names and realms of this form was not 
> the intention 
> >when the protocol was spec'd. The idea was that realms would be DNS 
> >names.
> >
> Although the former might be true, the latter is not, as RFC 
> 2831 has the following example of a realm:
> [email-masked].
> 
I sure don't recall that example.... I can only speak for my intentions
as I remember them.

The MSFT UI usually has two modes: one where there are two edit boxes
for entering name and realm (respectively); and one with one edit box
where special characters are understood as separating them.

An update could suggest some scheme such as this. Or it  could merely
state a requirement on UIs that arbitrary user names and realm names
have to be able to be entered, and that if they want to use special
characters to separate them, then they have to be able to escape the
special characters (and that they need to specify their escape rules).

Date: Fri, 13 Aug 2004 18:44:03 +0100
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Re: DIGEST-MD5 interop issue
Sender: [email-masked]

Alexey Melnikov wrote:

> There is another issue here: the client has split 
> "[email-masked]" into username and realm parts, instead of 
> sending the value as is in the username option. The same client was 
> also treating a username "BAR\foo" as username=foo and realm=BAR.

To complete my description: the client is transforming entered username 
"foo" into
username="foo", realm=""

> Arguably this is UI issue, but the client is still broken, because the 
> client makes assumptions about how username should look like and there 
> is no easy way to enter username as expected by the server.

Date: Fri, 13 Aug 2004 18:36:10 +0100
From: Alexey Melnikov <[email-masked]>
To: Paul Leach <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: DIGEST-MD5 interop issue
Sender: [email-masked]

Paul Leach wrote:

>>-----Original Message-----
>>From: [email-masked]
>>    
>>
>>On Behalf Of Kurt D. Zeilenga
>>Sent: Friday, August 13, 2004 12:32 AM
>>To: Alexey Melnikov
>>Cc: SASL WG
>>Subject: Re: DIGEST-MD5 interop issue
>>
>>Exactly, the client is making assumptions which prevent users from being
>>    
>>
>>able to use it with independently developed servers.  A client which
>>cannot
>>handle the full range of identity and realm values is simply broken. For
>>    
>>
>>instance, my DIGEST-MD5 authentication identity is [email-masked] in
>>    
>>
>>the realm [email-masked].  I would not be able to use this or like
>>    
>>
>>clients.
>>    
>>
>
>[Paul Leach] Use of names and realms of this form was not the intention
>when the protocol was spec'd. The idea was that realms would be DNS
>names.
>
Although the former might be true, the latter is not, as RFC 2831 has 
the following example of a realm:
[email-masked].

>You can legitimately gripe that the spec does not make this intention
>clear.
>
Indeed. Text about realms has caused problems before, because it is so 
vague.

> Or that the client in question doesn't make clear its rules for
>transforming what the user types into what gets sent on the wire. Or
>both.
>  
>
Yes (both).

Alexey

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: 2222bis: identities and authorization
From: Sam Hartman <[email-masked]>
Date: Fri, 13 Aug 2004 13:17:09 -0400
Sender: [email-masked]

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

    Kurt> I have completed my review of
    Kurt> draft-ietf-sasl-rfc2222bis-08.txt, resulting in mostly minor
    Kurt> editorial comments (which I have separately sent to the
    Kurt> Editor).  This note discussions problems I found related to
    Kurt> identities and authorization.

    Kurt> The 'Authorization and authentication identities' section
    Kurt> (3.2) starts off by stating that 'SASL authentication deals
    Kurt> with two identities' but then describes the processing model
    Kurt> to involve three identities, two of which it simply refers
    Kurt> to as 'authorization' identities.  I believe we either need
    Kurt> better distinguish these identities within the document, by
    Kurt> through qualification (proxy authorization identity
    Kurt> v. application authorization identity) or by use of
    Kurt> replacement terminology (proxied identity v. authorization
    Kurt> identity).  I prefer the latter approach as the former
    Kurt> qualifications are themselves a bit confused and the latter
    Kurt> seems more in step with RFC 2828.

Would you mind explaining the problem you had with this section in
better detail?  I thought it flowed fairly well and is a significant
improvement on our previous attempts to describe this issue.  However
I might well miss problems because as someone who has been following
SASL I'm familiar with the issue.  I am not always good at reading a
document as someone new to a technology.

--Sam

To: [email-masked]
Subject: Re: Does rfc2222bis need text on channel bindings?
From: Sam Hartman <[email-masked]>
Date: Fri, 13 Aug 2004 13:14:25 -0400
Sender: [email-masked]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> I figure the new SASL GSS mech document will say
    Nicolas> something about channel bindings, but perhaps rfc2222bis
    Nicolas> should also.

I do hope the new GSSAPI draft discusses this issue.

    Nicolas> Specifically I think that rfc2222bis could use:

    Nicolas> a) Security Considerations text about use of mechanisms
    Nicolas> that don't support channel bindings in conjunction with
    Nicolas> TLS.

This seems problematic given that all current mechanisms don't support
channel bindings.

I think the best we could do is security considerations text
describing the multiple layers problem.

    Nicolas>    Clients should be admonished to validate TLS server
    Nicolas> IDs to prevent MITM attacks when using SASL-over-TLS.
    Nicolas> Similarly with other variants of SASL-over-TLS.

Agreed.

    Nicolas> b) Text recommending support for channel bindings in
    Nicolas> future mechanisms, where possible.  Digest-MD5, for
    Nicolas> example, could easily support channel bindings.

This sounds out of scope for the SASL working group.  I believe our
charter prohibits us from adding new features to SASL.  I don't think
it has similar prohibitions for the GSSAPI mechanism.

I agree channel bindings are a good thing for SASL.  I disagree that
they are well specified enough for us to be adding text about them to
the base sasl document for this revision.

Content-class: urn:content-classes:message
Subject: RE: DIGEST-MD5 interop issue
Date: Fri, 13 Aug 2004 10:05:21 -0700
From: "Paul Leach" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>, "Alexey Melnikov" <[email-masked]>
Cc: "SASL WG" <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Jeffrey Hutzelman
> Sent: Friday, August 13, 2004 7:52 AM
> To: Kurt D. Zeilenga; Alexey Melnikov
> Cc: SASL WG
> Subject: Re: DIGEST-MD5 interop issue
> 
> The reason for the SHOULD is that the server has indicated which
realms it
> is willing/able to accept, and it's expected that the server will
usually
> reject any other realms.
[Paul Leach] The server may also accept names in the realm "fbi.gov",
but may not want to advertise that fact. Clients that have out of band
knowledge about the realms supported may attempt to authenticate using
one of those realms.

Hence it is not "expected" that another realm will fail. The inverse: it
can not be expected that it will succeed without OOB info.

Content-class: urn:content-classes:message
Subject: RE: DIGEST-MD5 interop issue
Date: Fri, 13 Aug 2004 09:57:32 -0700
From: "Paul Leach" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, "Alexey Melnikov" <[email-masked]>
Cc: "SASL WG" <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Kurt D. Zeilenga
> Sent: Friday, August 13, 2004 12:32 AM
> To: Alexey Melnikov
> Cc: SASL WG
> Subject: Re: DIGEST-MD5 interop issue
> 
> Exactly, the client is making assumptions which prevent users from
being
> able to use it with independently developed servers.  A client which
> cannot
> handle the full range of identity and realm values is simply broken.
For
> instance, my DIGEST-MD5 authentication identity is [email-masked]
in
> the realm [email-masked].  I would not be able to use this or
like
> clients.

[Paul Leach] Use of names and realms of this form was not the intention
when the protocol was spec'd. The idea was that realms would be DNS
names.

You can legitimately gripe that the spec does not make this intention
clear. Or that the client in question doesn't make clear its rules for
transforming what the user types into what gets sent on the wire. Or
both.

Date: Fri, 13 Aug 2004 16:52:46 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: [email-masked]
Subject: Re: Does rfc2222bis need text on channel bindings?
Sender: [email-masked]

Nicolas Williams wrote:

>I figure the new SASL GSS mech document will say something about channel
>bindings, but perhaps rfc2222bis should also.
>
>Specifically I think that rfc2222bis could use:
>
>a) Security Considerations text about use of mechanisms that don't
>   support channel bindings in conjunction with TLS.
>
>   Clients should be admonished to validate TLS server IDs to prevent
>   MITM attacks when using SASL-over-TLS.  Similarly with other variants
>   of SASL-over-TLS.
>
I suspect you mean "SASL-over-<foo>".

>   SACRED is an example of an application where such text could be
>   useful.
>
>b) Text recommending support for channel bindings in future mechanisms,
>   where possible.  Digest-MD5, for example, could easily support
>   channel bindings.
>
If you mean that it can be easily extended, then I agree.

>Comments?  Shall I just send proposed text to the list?
>
Please do.

Alexey

Date: Fri, 13 Aug 2004 16:14:58 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: DIGEST-MD5 interop issue
Sender: [email-masked]

Jeffrey Hutzelman wrote:

> On Friday, August 13, 2004 09:32:05 +0200 "Kurt D. Zeilenga" 
> <[email-masked]> wrote:
>
>>> So, the client has violated SHOULD and the server is treating SHOULD as
>>> MUST.
>>
>> No, the server is treating the client provided realm as invalid and 
>> hence
>> the exchange fails.  The server behavior is proper.
>
> Put another way...
>
> The server is not rejecting the exchange because it thinks the client 
> has violated the protocol.  It's doing so based on policy -- the 
> client provided a name in bar.example.com, and the server is only 
> willing to deal with clients in test.example.com.

This make sense.

But in case of CMU SASL the realm value doesn't matter, it is only used 
for constructing the authentication verifier.

Alexey

Date: Fri, 13 Aug 2004 16:12:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: DIGEST-MD5 interop issue
Sender: [email-masked]

Jeffrey Hutzelman wrote:

> The reason for the SHOULD is that the server has indicated which 
> realms it is willing/able to accept, and it's expected that the server 
> will usually reject any other realms. 

One problem with the DIGEST-MD5 spec I can see is that there is no way 
for the server to tell whether it only accepts certain realms or whether 
it will accept any realms. There are servers that implement either 
policy. Servers that implement the latter policy can accept 
authentication for any realm and will try to proxy authenticate if possible.

Alexey

Date: Fri, 13 Aug 2004 10:51:31 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: SASL WG <[email-masked]>
Subject: Re: DIGEST-MD5 interop issue
Sender: [email-masked]

On Friday, August 13, 2004 09:32:05 +0200 "Kurt D. Zeilenga" 
<[email-masked]> wrote:

>> So, the client has violated SHOULD and the server is treating SHOULD as
>> MUST.
>
> No, the server is treating the client provided realm as invalid and hence
> the exchange fails.  The server behavior is proper.

Put another way...

The server is not rejecting the exchange because it thinks the client has 
violated the protocol.  It's doing so based on policy -- the client 
provided a name in bar.example.com, and the server is only willing to deal 
with clients in test.example.com.

The reason for the SHOULD is that the server has indicated which realms it 
is willing/able to accept, and it's expected that the server will usually 
reject any other realms.

Date: Fri, 13 Aug 2004 12:28:27 +0200
To: [email-masked] (Sam Hartman)
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: rfc2222bis:  confidentiality and integrity
Cc: [email-masked]
Sender: [email-masked]

I support this suggestion.  The subsequent sentence is sufficent
to suggest other kinds (including poorly designed :-) layers
may be supported.

At 09:15 PM 8/12/2004, Sam Hartman wrote:

>Hi.  There's another change I thought would be editorial but
>apparently is not.  The document currently says in section 1 that
>confidentiality protection usually implies integrity protection.
>
>This seems less than ideal from a security standpoint.  I believe that
>applications need to be able to depend on the fact that
>confidentiality protection comes along with integrity protection.
>
>I propose to drop the word usually.

Date: Fri, 13 Aug 2004 09:34:04 +0200
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: 2222bis: identities and authorization
Sender: [email-masked]

I have completed my review of draft-ietf-sasl-rfc2222bis-08.txt,
resulting in mostly minor editorial comments (which I have
separately sent to the Editor).  This note discussions problems
I found related to identities and authorization.

The 'Authorization and authentication identities' section (3.2)
starts off by stating that 'SASL authentication deals with
two identities' but then describes the processing model to
involve three identities, two of which it simply refers to
as 'authorization' identities.  I believe we either need
better distinguish these identities within the document,
by through qualification (proxy authorization identity
v. application authorization identity) or by use of
replacement terminology (proxied identity v. authorization
identity).  I prefer the latter approach as the former
qualifications are themselves a bit confused and the
latter seems more in step with RFC 2828.

I am willing to prepare replacement text for consideration.

Kurt

Date: Fri, 13 Aug 2004 09:32:05 +0200
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: DIGEST-MD5 interop issue
Cc: SASL WG <[email-masked]>
Sender: [email-masked]

At 07:42 PM 8/12/2004, Alexey Melnikov wrote:
>Posting this to the mailing list, as my mumbling was not recorded in the Jabber logs:
>
>While testing an LDAP client that has DIGEST-MD5 support against Isode LDAP server (which uses CMU SASL DIGEST-MD5 plugin) I've discovered the following issue: the server end was advertising a single DIGEST-MD5 "realm" test.example.com.
>I've entered a username "[email-masked]" in the client and the client has sent this to the server as
>"username=foo, realm=bar.example.com, ...". The server end has checked that the realm it sent to the client ("test.example.com") doesn't match the one received from the client ("bar.example.com").
>
>At first I thought that the client is completely broken. But I've decided to check the DIGEST-MD5 spec and found the following (here the "realm" option is the one sent from the client to the server):
>
>>realm 
>>The realm containing the user's account, encoded according to the value of the "charset" directive. This directive is required if the server provided any realms in the "digest-challenge", in which case it may appear exactly once and its value SHOULD be one of those realms. If the directive is missing, "realm-value" will set to the empty string when computing A1 (see below for details).
>
>
>So, the client has violated SHOULD and the server is treating SHOULD as MUST.

No, the server is treating the client provided realm as invalid and hence
the exchange fails.  The server behavior is proper.

>So arguably this is a server problem, although  the client shouldn't assume that it knows better about which realms are supported by the server.
>
>There is another issue here: the client has split "[email-masked]" into username and realm parts,

This is real issue.

>instead of sending the value as is in the username option. The same client was also treating a username "BAR\foo" as username=foo and realm=BAR. Arguably this is UI issue, but the client is still broken, because the client makes assumptions about how username should look like and there is no easy way to enter username as expected by the server.

Exactly, the client is making assumptions which prevent users from being
able to use it with independently developed servers.  A client which cannot
handle the full range of identity and realm values is simply broken.  For
instance, my DIGEST-MD5 authentication identity is [email-masked] in
the realm [email-masked].  I would not be able to use this or like
clients.

Kurt  

To: [email-masked]
Subject: Re: rfc2222bis:  confidentiality and integrity
From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2004 22:14:51 -0400
Sender: [email-masked]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> If there are any mechanisms that provide confidentiality
    Nicolas> protection without providing integrity protection then I
    Nicolas> propose: a) that rfc2222bis identify such mechanisms, b)
    Nicolas> say new mechs MUST NOT do such Bad Things.

I know of no such mechanisms.

Date: Thu, 12 Aug 2004 19:47:13 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Does rfc2222bis need text on channel bindings?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I figure the new SASL GSS mech document will say something about channel
bindings, but perhaps rfc2222bis should also.

Specifically I think that rfc2222bis could use:

a) Security Considerations text about use of mechanisms that don't
   support channel bindings in conjunction with TLS.

   Clients should be admonished to validate TLS server IDs to prevent
   MITM attacks when using SASL-over-TLS.  Similarly with other variants
   of SASL-over-TLS.

   SACRED is an example of an application where such text could be
   useful.

b) Text recommending support for channel bindings in future mechanisms,
   where possible.  Digest-MD5, for example, could easily support
   channel bindings.

Comments?  Shall I just send proposed text to the list?

Nico
-- 

Date: Thu, 12 Aug 2004 19:42:09 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: rfc2222bis:  confidentiality and integrity
Mail-Followup-To: Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Aug 12, 2004 at 03:15:37PM -0400, Sam Hartman wrote:
> 
> 
> Hi.  There's another change I thought would be editorial but
> apparently is not.  The document currently says in section 1 that
> confidentiality protection usually implies integrity protection.
> 
> This seems less than ideal from a security standpoint.  I believe that
> applications need to be able to depend on the fact that
> confidentiality protection comes along with integrity protection.

If there are any mechanisms that provide confidentiality protection
without providing integrity protection then I propose: a) that
rfc2222bis identify such mechanisms, b) say new mechs MUST NOT do such
Bad Things.

> I propose to drop the word usually.

Yes.

Nico
-- 

To: [email-masked]
Subject: rfc2222bis:  confidentiality and integrity
Date: Thu, 12 Aug 2004 15:15:37 -0400 (EDT)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

Hi.  There's another change I thought would be editorial but
apparently is not.  The document currently says in section 1 that
confidentiality protection usually implies integrity protection.

This seems less than ideal from a security standpoint.  I believe that
applications need to be able to depend on the fact that
confidentiality protection comes along with integrity protection.

I propose to drop the word usually.

Date: Thu, 12 Aug 2004 18:42:25 +0100
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: DIGEST-MD5 interop issue
Sender: [email-masked]

Posting this to the mailing list, as my mumbling was not recorded in the Jabber logs:

While testing an LDAP client that has DIGEST-MD5 support against Isode LDAP server (which uses CMU SASL DIGEST-MD5 plugin) I've discovered the following issue: the server end was advertising a single DIGEST-MD5 "realm" test.example.com.
I've entered a username "[email-masked]" in the client and the client has sent this to the server as
"username=foo, realm=bar.example.com, ...". The server end has checked that the realm it sent to the client ("test.example.com") doesn't match the one received from the client ("bar.example.com").

At first I thought that the client is completely broken. But I've decided to check the DIGEST-MD5 spec and found the following (here the "realm" option is the one sent from the client to the server):

>realm 
>
>The realm containing the user's account, encoded according to the 
>value of the "charset" directive. This directive is required 
>if the server provided any realms in the "digest-challenge", in which case it 
>may appear exactly once and its value SHOULD be one of those realms. If the 
>directive is missing, "realm-value" will set to the empty string when 
>computing A1 (see below for details).

So, the client has violated SHOULD and the server is treating SHOULD as MUST. So arguably this is a server problem, although  the client shouldn't assume that it knows better about which realms are supported by the server.

There is another issue here: the client has split "[email-masked]" into username and realm parts, instead of sending the value as is in the username option. The same client was also treating a username "BAR\foo" as username=foo and realm=BAR. Arguably this is UI issue, but the client is still broken, because the client makes assumptions about how username should look like and there is no easy way to enter username as expected by the server.

I have a reason to believe that the client is using a library implementing DIGEST-MD5, which is widely deployed.

Alexey

Date: Thu, 12 Aug 2004 03:27:17 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: Text on re-keying for rfc2222bis
Mail-Followup-To: Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Aug 11, 2004 at 05:27:32PM -0400, Sam Hartman wrote:
> 
> I'm a bit uncomfortable saying that SASL mechanisms should support
> rekeying.  I'm not sure that the community understands what this would
> mean well enough that mechanisms would converge on solutions with
> similar properties.

Ok, how about this:

   SASL mechanisms that support re-keying SHOULD:
   
    - indicate that re-keying is or will be needed immediately;

    - provide re-keying messages or transparently include re-keying
      messages in the security layers; the latter can happen without
      application involvement, but only as long as the application is
      engaged in timely bidirectional exchanges with its peer.

> 
> Also, do we want to point out that for interop reasons SASL mechanisms
> may want to provide advisory notice that rekeying is necessary rather
> than invalidating security contexts.  I'm particularly concerned about
> the transferring large file case.

I sympathize.  I don't mind seeing text in rfc2222bis about advisory vs.
mandatory security layer expiration.  But I think that text about this
that is specific to the GSS mechanisms seems well beyond the scope of
rfc2222bis.  Suggestions?

Nico
-- 

To: [email-masked]
Subject: Re: Text on re-keying for rfc2222bis
From: Sam Hartman <[email-masked]>
Date: Wed, 11 Aug 2004 17:27:32 -0400
Sender: [email-masked]

I'm a bit uncomfortable saying that SASL mechanisms should support
rekeying.  I'm not sure that the community understands what this would
mean well enough that mechanisms would converge on solutions with
similar properties.

Also, do we want to point out that for interop reasons SASL mechanisms
may want to provide advisory notice that rekeying is necessary rather
than invalidating security contexts.  I'm particularly concerned about
the transferring large file case.

To: [email-masked]
Subject: Comments on draft-ietf-sasl-rfc2222bis.txt
Date: Wed, 11 Aug 2004 15:17:07 -0400 (EDT)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

In section 2, the draft claims that the layer does not generally hide
the details of mechanisms from protocols.  I actually believe the
statement we want to be making is that while the layer hides the
details of protocols from mechanisms and the details of mechanisms
from protocols, it does not hide the details of mechanisms from
protocol implementations.  In particular, I consider it a requirement
to be able to specify a SASL binding to a protocol without thinking
about mechanism details.  I believe this requirement is met by the
base spec.  However actually implementing this protocol spec for a
particular mechanism requires the server and client to be aware of the
mechanism details.

I would not in general consider it acceptable for mechanism
specifications to place requirements on protocol specifications.

Besides this concern and some editorial issues I've sent to the
editor, I have read this document and believe it is of high quality.
As a chair however, I believe we still have not received sufficient
review to publish the document.

--Sam

Date: Wed, 11 Aug 2004 15:07:09 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: SASL working group summary for IETF 60
Sender: [email-masked]

Simon Josefsson wrote:

>Sam Hartman <[email-masked]> writes:
>  
>
>>There was discussion of the GSSAPI mechanism.  everyone agrees we need
>>to maintain compatibility with the widely deployed Kerberos 5
>>mechanism.  Sam Hartman proposed significant changes to other GSSAPI
>>SASL mechanisms for improved efficiency.  One reason we may want this
>>change is HTTP SASL.  Discussion will continue on the list.
>>    
>>
>
>How about forking the GSSAPI document into one Kerberos 5 "GSSAPI"
>document, and one document for the generic "GSS-*" mechanism set?  If
>the protocol for "GSS-*" will be different from the "GSSAPI" protocol,
>perhaps it doesn't make sense to describe both in the same document.
>It might also help focus on making the "GSS-*" protocol better,
>without having to pay attention to Kerberos 5 specific issues.
>
This is pretty much what I've suggested.

Date: Fri, 6 Aug 2004 19:09:13 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Text on re-keying for rfc2222bis
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Diffs for section 6.3:

--- /tmp/sasl-6.3-orig	Fri Aug  6 19:08:10 2004
+++ /tmp/sasl-6.3	Fri Aug  6 19:08:00 2004
@@ -1,5 +1,6 @@
+
 6.3.  Multiple authentications
 
    Unless otherwise stated by the protocol's profile, only one
    successful SASL negotiation may occur in a protocol session.  In this
    case, once an authentication protocol exchange has successfully
@@ -8,18 +9,22 @@
 
    If a profile explicitly permits multiple successful SASL negotiations
    to occur, then in no case may multiple security layers be
    simultaneously in effect.  If a security layer is in effect and a
    subsequent SASL negotiation selects a second security layer, then the
-   second security layer replaces the first. If a security layer is in
-   effect and a subsequent SASL negotiation selects no security layer,
-   the original security layer remains in effect.
+   second security layer replaces the first; this can be used as a form
+   of re-keying, where SASL mechanisms that provide security layers fail
+   to provide for re-keying, provided that the authenticated identities
+   remain the same.  If a security layer is in effect and a subsequent
+   SASL negotiation selects no security layer, the original security
+   layer remains in effect.
 
    Where a protocol profile permits multiple successful SASL
    negotiations, the profile MUST detail the effect of a failed SASL
    negotiation upon the previously established authentication state.
    In particular, it MUST state whether the previously established
    authenticated state remain in force or whether the connection is to
    revert to an non-authenticated state. Regardless of the specified
    effect upon authentication state, the previously negotiated security
    layer remains in effect.
+

New text for the security considerations section:

   The secure or administratively permitted lifetimes of SASL
   mechanisms' security layers are finite.  The use of cryptographic
   keys and the passage of time after the initial use of a cryptographic
   key weakens said keys by increasing the amount of ciphertext, other
   cryptographic material, and/or time that is available to
   cryptanalysts in any effort to attack the security layers.

   Administrative limits on security layers lifetime may take the form
   of time limits expressed in x.509 certificates, Kerberos V tickets,
   or in directories, and are often desired.

   In practice one likely effect of administrative security layers
   lifetime limits is that applications may find that security layers
   stop working in the middle of application protocol operation, such
   as, perhaps, during large data transfers.

   SASL does not provide for re-keying.  SASL mechanisms may; all future
   SASL mechanisms that provide security layers SHOULD provide for
   re-keying.

   Applications that wish to re-key SASL security layers where the
   mechanism does not provide for re-keying should re-authenticate the
   same IDs and replace the expired or soon-to-expire security layers.
   This approach requires support for re-keying in the application
   protocols.  See section 6.3.

Sorry for the delay.

Nico
-- 

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: SASL working group summary for IETF 60
Date: Thu, 05 Aug 2004 00:07:38 +0200
Lines: 17
Cancel-Lock: sha1:1UGFIBfleUZDGUKIZYN4HerfHRM=
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

> There was discussion of the GSSAPI mechanism.  everyone agrees we need
> to maintain compatibility with the widely deployed Kerberos 5
> mechanism.  Sam Hartman proposed significant changes to other GSSAPI
> SASL mechanisms for improved efficiency.  One reason we may want this
> change is HTTP SASL.  Discussion will continue on the list.

How about forking the GSSAPI document into one Kerberos 5 "GSSAPI"
document, and one document for the generic "GSS-*" mechanism set?  If
the protocol for "GSS-*" will be different from the "GSSAPI" protocol,
perhaps it doesn't make sense to describe both in the same document.
It might also help focus on making the "GSS-*" protocol better,
without having to pay attention to Kerberos 5 specific issues.

Regards,
Simon

To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: SASL working group summary for IETF 60
From: Sam Hartman <[email-masked]>
Date: Wed, 04 Aug 2004 17:35:06 -0400
Sender: [email-masked]

The SASL working group met for one hour.  The SASL base spec
(draft-ietf-sasl-rfc2222bis) is in last call.  We need more review of
this document; without this review the chairs will be unable to
recommend the document for publication.  Nicolas Williams will provide
security considerations text for rekeying to be considered by the group.

Not much progress has been made on digest-md5 since the last IETF.
The explicit IV issues for CBC have been discussed but are still open.
The character set conversion issues are still open although there is
still a possibility we will be able to move exclusively to UTF8.  At
least two more revisions of the draft are expected.

There was discussion of the GSSAPI mechanism.  everyone agrees we need
to maintain compatibility with the widely deployed Kerberos 5
mechanism.  Sam Hartman proposed significant changes to other GSSAPI
SASL mechanisms for improved efficiency.  One reason we may want this
change is HTTP SASL.  Discussion will continue on the list.

To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: GSSAPI direction
From: Sam Hartman <[email-masked]>
Date: Tue, 03 Aug 2004 12:56:34 -0400
Sender: [email-masked]

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

    Alexey> I don't mind the changes you are proposing (at least I
    Alexey> agree with their motivation), however this suggestion is a
    Alexey> bit late and I would like to point out that there several
    Alexey> independent implementations of GSSAPI (Kerberos) mechanism
    Alexey> that interoperate well (at least better than DIGEST-MD5).

We cannot make these changes for the SASL mechanism called GSSAPI;
that seems clear.