Subject: Comments on draft-ietf-sasl-rfc2831

From: Sam Hartman <[email-masked]>
Date: Tue, 25 Mar 2003 09:40:45 -0500 (EST)

In section 2.1.1, the draft states:

       Note, that this directive doesn't affect authorization id
       ("authzid") which is always in UTF-8.

It is not the place of the mechanism spec to say anything about the
character set of the authorization ID; the mechanism should treat the
authorization ID as an opaque string and leave it up to the
application to specify the meaning of the authorization id.

In section 2.1.2.1, is exchange protected against a downgrade attack
from auth-conf, auth-int to auth?  I.E. Looking at the definition of
a2 and response, I see where the client value of qop is used, but not
the server supplied qop options.  The security discussion seems
inadequate.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 31 Mar 2003 22:28:59 -0700

> application to specify the meaning of the authorization id.

We have to be clear that for the protocols that use the same format for
authentication and authorization ids, "authzid" is in UTF-8 and MUST NOT
be converted to ISO-8859-1 as username/password are.

This doesn't belong to protocol profiles either, I don't think we should
special case DIGEST-MD5 in all protocol profiles.

> from auth-conf, auth-int to auth?

> I.E. Looking at the definition of a2 and response, I see where the
> client value of qop is used, but not
> the server supplied qop options.

You are right, server supplied list of supported qop options is not
protected. An attacker can remove all but the weakest (i.e. "auth").

>  The security discussion seems inadequate.

Suggestions?

Regards,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 31 Mar 2003 22:28:59 -0700

Suggestions?

Regards,
Alexey

Date: Mon, 31 Mar 2003 22:28:59 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-ietf-sasl-rfc2831
Sender: [email-masked]

Suggestions?

Regards,
Alexey

To: [email-masked]
Cc: [email-masked]
Subject:  security report for sasl digest-md5
From: Sam Hartman <[email-masked]>
Date: Mon, 31 Mar 2003 15:25:53 -0500
Sender: [email-masked]

During the SASL working group meeting at IETF 56,
Eric Rescorla and I agreed to review the security of cipher usage in
the digest-md5 SASL mechanism draft (draft-ietf-sasl-rfc2831bis).  We
have reached the following conclusions:

1) Instructions on how to use rc4 are unclear; an implementation might read
the draft and assume that  the PRNG should be initialized for every
message sent.  This would  allow an attacker to retrieve the xor of
multiple plaintext messages given the ciphertext and in most
situations would completely compromise confidentiality.

2)  The use of CBC is unclear.  The draft does not specify whether the
IV is reinitialized  from one message to the next or whether  the  the
last block of  ciphertext becomes the IV of the next message.  From a
security standpoint the IV should not be reinitialized and instead
should be chained between messages.

3) The handling of parity bits is significantly different from other
   protocols that specify how to set up keys and may lead to
   confusion.

4) Part of the key material is used as the IV for the 3DES cipher.

5) As previously discussed on the SASL list, the protocol is
vulnerable to CBC chaining issue (the Rogaway attack).

6) Implementation guidance on avoiding timing attacks related to
verifying padding before performing the MAC operations needs to be
given.  See http://lasecwww.epfl.ch/memo_ssl.shtml.

Since existing implementations of the RC4 cipher do preserve PRNG
state between messages, there is no technical objection to retaining
the existing RC4 cipher or even to making it mandatory to implement.
An appropriate document for a normative reference will need to be
found and the text will need to be clarified if the working group
wishes to proceed in this direction.

We recommend that the working group deprecate the existing DES and
3DES ciphers.  An AES cipher should be specified.  The AES cipher can
either use counter mode or avoid the CBC chaining attack in some other
way such as the addition of random text to each message.  The AES
cipher should not use key material as part of the IV.

To: [email-masked]
Subject: Draft minutes for IETF 56 SASL working group meeting
Date: Mon, 31 Mar 2003 12:35:28 -0500 (EST)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

Please send any corrections; the corrected minutes will be submitted
later this week for the proceedings.

Minutes based on notes from Chris Newman and Sam Hartman.

-----
SASL WG IETF 56 San Francisco

1. Base spec -- document editor is non-responsive, will assign new editor.

   Issue: Is security considerations sufficient to meet IESG review?

2. Anonymous
  went through WG last call, will fix issues raised during last call,
  will submit with base spec. Sam  Hartman will send a summary of the
  last call to the working group after reviewing with the editor. 

3.  Plain/saslprep

  The main issue is the stringprep profile. More review is required,
  especially of the profile.

  Issue: SASLprep profile should deal with user@domain-name syntax
  issues.  IN particular many authentication identifiers and
  authorization  identifiers include domain components. We need to be
  aware of any differences between nameprep and saslprep and  avoid
  introducing these differences without good reason.  Nameprep works on
  domain labels, while saslprep works on the string as a whole.
  Applications may mistakenly perform nameprep on input before giving
  it to SASL.

  Issue: Want SASLprep and Kerberos prep to use the same namespace.

  Discussion of authorization  names vs authentication names.  Larry
  Greenfield believes that applications will use the same profile for
  both.  Kurt pointed out that  LDAP is an example of an application
  with significantly different requirements for authorization
  identifiers than authentication identifiers.

3. DIGEST-MD5 issues  Alexey is editor
  draft-ietf-sasl-rfc2831bis
  three open issues:
  1. Whether we want to merge AES cipher?
     Postpone selection of mandatory-to-implement and adding AES
     until we have done a security analysis.  Security analysis will
  be posted to the working group list.
  2. Add SASLprep.
  3. then ready for last call.

4. CRAM-MD5 draft   Lyndon is editor
  1. add SASLprep, then done.

5. GSSAPI issues    
  1. Last call the base32 draft, then last call.
  2. An editor needs to be selected.

6. Individual submissions
  Authors of SRP document want to last call it.
    Issue: Sam Hartman believes it should have structure which
  included an OID in front so it could be used as a GSSAPI mechanism. 

To: [email-masked]
Subject: Draft minutes for IETF 56 SASL working group meeting
Date: Mon, 31 Mar 2003 12:28:23 -0500 (EST)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

Please send any corrections; the corrected minutes will be submitted
later this week for the proceedings.

-----
SASL WG IETF 56 San Francisco

1. Base spec -- document editor is non-responsive, will assign new editor.

   Issue: Is security considerations sufficient to meet IESG review?

2. Anonymous
  went through WG last call, will fix issues raised during last call,
  will submit with base spec. Sam  Hartman will send a summary of the
  last call to the working group after reviewing with the editor. 

3.  Plain/saslprep

  The main issue is the stringprep profile. More review is required,
  especially of the profile.

  Issue: SASLprep profile should deal with user@domain-name syntax
  issues.  IN particular many authentication identifiers and
  authorization  identifiers include domain components. We need to be
  aware of any differences between nameprep and saslprep and  avoid
  introducing these differences without good reason.  Nameprep works on
  domain labels, while saslprep works on the string as a whole.
  Applications may mistakenly perform nameprep on input before giving
  it to SASL.

  Issue: Want SASLprep and Kerberos prep to use the same namespace.

  Discussion of authorization  names vs authentication names.  Larry
  Greenfield believes that applications will use the same profile for
  both.  Kurt pointed out that  LDAP is an example of an application
  with significantly different requirements for authorization
  identifiers than authentication identifiers.

3. DIGEST-MD5 issues  Alexey is editor
  draft-ietf-sasl-rfc2831bis
  three open issues:
  1. Whether we want to merge AES cipher?
     Postpone selection of mandatory-to-implement and adding AES
     until we have done a security analysis.  Security analysis will
  be posted to the working group list.
  2. Add SASLprep.
  3. then ready for last call.

4. CRAM-MD5 draft   Lyndon is editor
  1. add SASLprep, then done.

5. GSSAPI issues    
  1. Last call the base32 draft, then last call.
  2. An editor needs to be selected.

6. Individual submissions
  Authors of SRP document want to last call it.
    Issue: Sam Hartman believes it should have structure which
  included an OID in front so it could be used as a GSSAPI mechanism. 

Date: Tue, 25 Mar 2003 09:40:45 -0500 (EST)
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Comments on draft-ietf-sasl-rfc2831
Sender: [email-masked]

Date: Sun, 23 Mar 2003 17:57:00 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Kurt D. Zeilenga" <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: [SASL] Comments about draft-ietf-sasl-plain-00.txt
Sender: [email-masked]

More comments below.

Alexey Melnikov wrote:

> 2. PLAIN SASL mechanism
>
>   The mechanism consists of a single message from the client to the
>   server.  The client sends the authorization identity (identity to
>   login as), followed by a NUL character, followed by the authentication
>   identity (identity whose password will be used), followed by a NUL
>   character, followed by the clear-text password.   The client leaves
>   the authorization identity empty if wishes the server to derive the
>   authorization identity from the provided the authentication identity.

Last line: drop "the" before "authentication identity".

> Appendix A.  Changes since RFC 2595
>
>   The specification details how the server is to compare client-provided
>   character strings with stored character strings.

I suggest that the example code be moved to SASLPrep document or the base
SASL spec.
Or maybe not, as it has some PLAIN specific checks, but some pieces of it
are generic and I would hate to cut & paste them into every SASL mechanism
that requires SASLPrep.

>   The ABNF grammar was updated.  In particular, the grammar now allows
>   LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the
>   authzid, authcid, passwd productions.   However, whether these control
>   characters may be used depends on the string preparation rules
>   applicable to the production.   For authcid, control characters are
>   prohibited.  For passwd, control characters are allowed.

IMHO, CRs and LFs must not be allowed in passwords. They are almost
impossible to enter in UI and this change might break existing protocols,
like ACAP.

>  For authzid,
>   one must consult the application-level SASL profile.

...if the one exists.

Regards,
Alexey

To: Lawrence Greenfield <[email-masked]>
Cc: [email-masked]
Subject: Re: SASL applicability statement
From: Sam Hartman <[email-masked]>
Date: Wed, 19 Mar 2003 23:16:36 -0500
Sender: [email-masked]

I think the document should discuss both TLS and SASL, but should
refer to a TLS applicability statement being written elsewhere for
specific TLS issues.  I suspect politically completely combining the
documents will be challenging.

Date: Wed, 19 Mar 2003 19:55:50 -0800
From: Lawrence Greenfield <[email-masked]>
To: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: SASL applicability statement
Sender: [email-masked]

--On Wednesday, March 19, 2003 5:52 PM -0500 Sam Hartman <[email-masked]> 
wrote:

> Do people believe such an applicability statement is useful?  Would
> someone volunteer to be an editor?

It would be useful to have such a statement at times, especially since SASL 
tends to be underutilized in protocols that could easily make use of it 
without making any or little over-the-wire changes to them. There are still 
generic authentication frameworks being developed in protocol specific 
contexts (iSCSI, some proposals for IPsec). It would be nice if these 
attempts could instead be guided to strongly considering SASL.

But it's not clear to me that (for instance) TLS and SASL should be 
discussed in separate documents.

I think the document would be more useful for non-application area 
protocols, since the application area has (generally) become much more 
standardized on TLS and SASL usage.

Larry

To: [email-masked]
Subject:  SASL applicability statement
From: Sam Hartman <[email-masked]>
Date: Wed, 19 Mar 2003 17:52:47 -0500
Sender: [email-masked]

At this week's security directorate meeting, we discussed the need for
applicability statements for security protocols that both describe how
they should be used in another protocol and when they are appropriate.
Such a statement is being developed for TLS.

Some people felt that SASL didn't need such a statement because it was
sufficiently well understood by the applications area that nothing
needed to be said.  I and some others at the lunch disagreed and
believe that SASL tends to be misused in new protocols that try and
adopt it just like other security technologies.  The reason this tends
not to be a problem is that several people do a good job of looking at
SASL usage and fixing problems that we discover.

Do people believe such an applicability statement is useful?  Would
someone volunteer to be an editor?

Steve indicated that asking for this work to be added to our charter
would be a reasonable thing to do.

--Sam

Date: Tue, 18 Mar 2003 19:34:20 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Morteza Ansari <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: SASL C API meeting?
Sender: [email-masked]

On Tue, 18 Mar 2003, Morteza Ansari wrote:

> > And this is not going to be long.
> >
> > Anyway, all results will be discussed at SASL WG meeting on Thursday.
>
> Is this Wed. 18:15?

Sorry, Tonight, (Tuesday) 1815.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 18 Mar 2003 17:02:04 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Rob Siemborski <[email-masked]>
CC: Morteza Ansari <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: SASL C API meeting?
Sender: [email-masked]

Rob Siemborski wrote:

> On Tue, 18 Mar 2003, Alexey Melnikov wrote:
>
> > Any preferences?
> > Thursday would be too busy for me, so I would rather do this today or
> > Wednesday.
> > Wednesday morning at 9:00 (or today) works for me.
>
> We'll be meeting at 1815 near the message board, and probably getting some
> sort of food this evening.

And this is not going to be long.

Anyway, all results will be discussed at SASL WG meeting on Thursday.

Cheers,
Alexey Melnikov

Date: Tue, 18 Mar 2003 18:45:17 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Morteza Ansari <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: SASL C API meeting?
Sender: [email-masked]

On Tue, 18 Mar 2003, Alexey Melnikov wrote:

> Any preferences?
> Thursday would be too busy for me, so I would rather do this today or
> Wednesday.
> Wednesday morning at 9:00 (or today) works for me.

We'll be meeting at 1815 near the message board, and probably getting some
sort of food this evening.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Tue, 18 Mar 2003 14:43:17 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Morteza Ansari <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: SASL C API meeting?
Sender: [email-masked]

Morteza ANSI wrote:

> I think that would be a good idea.

Any preferences?
Thursday would be too busy for me, so I would rather do this today or
Wednesday.
Wednesday morning at 9:00 (or today) works for me.

Cheers,
Alexey Melnikov

Date: Tue, 18 Mar 2003 13:18:54 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: SASL C API meeting?
Sender: [email-masked]

Is there enough interest to have an informal meeting to discuss changes
to SASL C API draft (currently draft-newman-sasl-c-api-01.txt)?

Alexey

Date: Sun, 09 Mar 2003 18:19:51 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Agenda items for IETF#56
Sender: [email-masked]

Sam and I are now putting together the agenda for IETF#56.
Editors (and others), please send us a quick note with
I-D name(s), list of outstanding issues you would like
to discuss, and a estimate of the time needed.

Thanks, Kurt & Sam

To: [email-masked]
Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt
From: Sam Hartman <[email-masked]>
Date: Sat, 08 Mar 2003 15:49:03 -0500
Sender: [email-masked]

It seems that we really already have enough mechanisms for doing
PKI-like things with SASL:

* SPKM 
* LIPKI
* TLS + plain

What's wrong with using something like LIPKI and negotiating no
integrity protection?

If your complaint is simply the lack of implementations of LIPKI, then
I think that the advantages of having fewer standards outweigh the
implementation complexity of LIPKI.

If your complaint is that you don't want the complexity of a GSS
library, then you should realize that you can implement the LIPKI
protocol without actually using a GSSAPI library.

To: [email-masked]
Cc: IETF-Announce: ;, [email-masked]
Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt
From: Sam Hartman <[email-masked]>
Date: Sat, 08 Mar 2003 15:16:51 -0500
Sender: [email-masked]

It seems that we really already have enough mechanisms for doing
PKI-like things with SASL:

* SPKM 
* LIPKI
* TLS + plain

What's wrong with using something like LIPKI and negotiating no
integrity protection?

If your complaint is simply the lack of implementations of LIPKI, then
I think that the advantages of having fewer standards outweigh the
implementation complexity of LIPKI.

If your complaint is that you don't want the complexity of a GSS
library, then you should realize that you can implement the LIPKI
protocol without actually using a GSSAPI library.

To: [email-masked]
Cc: 
Subject: Re: draft-nystrom-http-sasl-06.txt
Organization: Seeking Work...
From: Scott Lawrence <[email-masked]>
Date: 07 Mar 2003 12:59:55 -0500
Lines: 109
Sender: [email-masked]

Thanks for posting this notice to ietf-http-wg; I hadn't heard of it
before then.

I'd like to support most of the comments made by Joe Orton, and
amplify on couple.

Joe Orton <[email-masked]> writes:

> The 1xx status-codes are reserved for "interim" HTTP responses, but the
> draft is now using 102 for a final response here, which won't work (or
> at least, isn't compatible with HTTP/1.1).

In particular, current clients (including proxies) will just treat a
102 as 100 and probably ignore it.

> Draft is confused about whether HTTP auth is per-request or
> per-connection.  Restrictions on not mixing auth sessions on a single
> connection etc should be dropped.

This gets to the heart of the issue, really.  HTTP is stateless by
definition, and the connection has no semantic importance; as such, it
can't (in HTTP alone) have any security significance.  Earlier efforts
to apply SASL to HTTP (drafts long expired) failed on just this point;
they tried to wedge SASL mechanisms into the stateless HTTP framework
(without success).  You've mostly recognized this and gotten a better
model, but I think you've not quite taken it far enough, and I think
that fixing it actually makes the suggested changes simpler.

As you point out in your Introduction, SASL is connection-oriented,
so in order to exploit it, the HTTP server must recognize that it is
using different rules - that the connection provides the security.
This is essentially the same as what we described (and you cited) in
RFC 2817.  I think therefor that rather than defining new
authentication responses you should just use the existing Upgrade
framework. 

I'll try to illustrate how this goes - fleshing it out will require a
bit more study (with which I'm happy to help).  This example assumes
no intermediaries (which would just add the required CONNECT
handshaking to make a tunnel over which to do this sequence)

    Client:                               Server:
1)    (original request)  --------------> [determines that SASL
                                           service is required]

2)     <-------------------------------- 426 Upgrade Required
                                         Upgrade: SASL/1.0, HTTP/1.1
                                         Connection: Upgrade
                                         WWW-Authenticate: sasl (mechanisms)

3)    (request) -----------------------> [changes semantics of 
      Upgrade: SASL/1.0                   connection to be SASL
                                          but not yet unauthenticated]
   
4a)    <-------------------------------- 101 Switching Protocols
                                         Upgrade: SASL/1.0, HTTP/1.1
                                         
4b)    <-------------------------------- 401 Unauthorized
                                         WWW-Authenticate: sasl (sasl challenge)
                 
5)     (original request) ------------->
       Authorization: sasl (sasl-response)                        

Step 1 is the client naively attempting the unauthenticated request.

Step 2 is the server insisting on SASL security for it, and including
the available mechanisms (if it is willing, it could also include
other WWW-Authenticate options such as digest, with the attendant
problems in downgrade attacks). 

The request in step 3 above (which is indicating that the client is
SASL-capable, and a desire to activate it) could be either the
original request, or a dummy request (OPTIONS would do) that exists
just to trigger the protocol upgrade.

4a is the server signalling that the new connection-oriented security
rules apply.  It's an intermediate response - the client can't send
anything in response to it.

4b is the server actually beginning the (mechanism-dependant) SASL
handshake by sending the challenge. 

I suspect that may be possible to fold some of these steps together, by
including the SASL challenge with the 426, enabling the client to
include Authorization in step 3.  

> The draft doesn't actually make any requirements on how the server
> responds to an OPTIONS request, so it's pointless as as well as
> misguided :)

Alas, we tried to make a formal definition of the response to OPTIONS
that would be programatically useful, but never got there.

> The CONNECT-to-port-80/SASL-security-layer-negotiation bits aren't
> compatible with HTTP, and Just Won't Work with deployed HTTP proxies,
> most of which don't even grok HTTP/1.1 properly.

This can be made to work - if SASL is genuinely better and offers
value, then perhaps vendors at all levels would find reasons to
support them.  I have some skepticism about this, but one can hope.
In any event, we have what we need in tbe protocol now to determine
_why_ (and where) things fail, which is the first step.

-- 
Scott Lawrence        
  Actively seeking work 
  http://skrb.org/scott/
  [ <[email-masked]> is deprecated ]

To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nystrom-http-sasl-06.txt
Date: Wed, 05 Mar 2003 06:30:19 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SASL in HTTP/1.1
	Author(s)	: M. Nystrom, R. Zuccherato, A. Melnikov
	Filename	: draft-nystrom-http-sasl-06.txt
	Pages		: 32
	Date		: 2003-3-4
	
This memo suggest the use of SASL [RFC2222] as a framework to enable
the use of strong authentication mechanisms in http/1.1 [RFC2616],
and defines one approach to accomplish this.
Please send comments on this document to the relevant mailing lists,
e.g. [email-masked].

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-nystrom-http-sasl-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-nystrom-http-sasl-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-nystrom-http-sasl-06.txt

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

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

--OtherAccess--

--NextPart--

Date: Sun, 02 Mar 2003 18:09:10 -0800
To: "Ramsay, Ron" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt
Cc: "Lawrence Greenfield" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 05:32 PM 3/2/2003, Ramsay, Ron wrote:
>Well, Kurt, you're the only one who has tried to make the TLS session transient.

As I noted in my last response, it is now clear to me is that
TLS+SASL/PLAIN+closure is not a viable approach.

However, I content that it is not obviously so.  TLS is transient
by design.  And application protocol profiles of TLS could be
defined which support this approach.  And existing TLS and SASL
libraries would allow implementation of the approach.  And there
existing implementations of application protocols which do use
this approach today.

So, I think, my original question was quite reasonable to ask.
Personally, I think the answer deserves brief mention in the I-D.

Kurt 

content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt
Date: Mon, 3 Mar 2003 12:32:49 +1100
From: "Ramsay, Ron" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: "Lawrence Greenfield" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Well, Kurt, you're the only one who has tried to make the TLS session transient. I go with the author who said it should last for the whole session. You don't put up an Aunt Sally just to knock it down again!

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Monday, 3 March 2003 12:17
To: Ramsay, Ron
Cc: Lawrence Greenfield; [email-masked]; [email-masked]
Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt

At 05:03 PM 3/2/2003, Ramsay, Ron wrote:
>I don't see how this can work. You are proposing to use TLS while authentication is in progress and then drop back to cleartext. However, for LDAPv3, RFC 2830 Section 5.2 states that, after TLS closure, the authentication state should return to anonymous.

Good catch.  I then say that the I-D should note that one
of the reasons why TLS+SASL/PLAIN+closure is that application
profiles of TLS define inconsistent TLS closure semantics.

Kurt 

Date: Sun, 02 Mar 2003 17:17:23 -0800
To: "Ramsay, Ron" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt
Cc: "Lawrence Greenfield" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 05:03 PM 3/2/2003, Ramsay, Ron wrote:
>I don't see how this can work. You are proposing to use TLS while authentication is in progress and then drop back to cleartext. However, for LDAPv3, RFC 2830 Section 5.2 states that, after TLS closure, the authentication state should return to anonymous.

Good catch.  I then say that the I-D should note that one
of the reasons why TLS+SASL/PLAIN+closure is that application
profiles of TLS define inconsistent TLS closure semantics.

Kurt 

content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-hansen-sasl-pki-00.txt
Date: Mon, 3 Mar 2003 12:03:53 +1100
From: "Ramsay, Ron" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Kurt,

I don't see how this can work. You are proposing to use TLS while authentication is in progress and then drop back to cleartext. However, for LDAPv3, RFC 2830 Section 5.2 states that, after TLS closure, the authentication state should return to anonymous.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Saturday, 1 March 2003 06:22
To: Lawrence Greenfield
Cc: [email-masked]; [email-masked]
Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt

At 11:02 AM 2/28/2003, Lawrence Greenfield wrote:
>   Date: Fri, 28 Feb 2003 10:06:54 -0800
>   From: "Kurt D. Zeilenga" <[email-masked]>
>
>   What's the advantage of this approach over using TLS+SASL/PLAIN
>   and then just closing TLS gracefully so that remainder of the
>   session is in the clear?
>
>You don't close TLS; you can renegotiate to the NULL cipher.

Application-level protocols may permit use the stream after TLS
closure.  See RFC 2246, Section 7.2.1.  LDAPv3 is an example,
RFC 2830, of an application-level protocol which explicitly
permits such use.

Kurt