Subject: Re: line lengths for AUTH
From: Alexey Melnikov <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Robert A Rosenberg <[email-masked]>, [email-masked]
Date: Wed, 13 Dec 2006 17:49:16 +0000
List-Id: <ietf-smtp.imc.org>

Ned Freed wrote:

>> Robert A. Rosenberg wrote:
>
>> > At 17:08 +0000 on 12/07/2006, Alexey Melnikov wrote about Re: line
>> > lengths for AUTH:
>> >
>> >> But I guess the document can specify an absolute minimum and allow
>> >> implementations to support bigger line lengths.
>> >
>> > How about defining a 220 Keyword to designate/supply the length that
>> > the SMTP Server is willing to accept?
>
>> I can add a new EHLO keyword (which would be "SHOULD be advertised by
>> SMTP servers"), if people think this is important.
>
> I think it does much more harm than good. A server either supports an 
> extension
> or it doesn't. If it does support it it needs to support whatever line 
> length
> limits or increases that extension requires. Announcing a line length 
> limit
> separately opens the door to all sorts of silly states.
>
> Authentication mechanisms are awkward in that the documents specifying 
> them
> won't necessarily specify the maximum data size they transfer 
> (although they
> should) and hence the line length limit associated with a given 
> mechanism may
> not be clear. But all an announcment of the limit from the server does 
> is push
> the problem from the server implementor to the client implementor, and 
> in a
> not-very-nice way: Now the server is free to say something like "I 
> support this
> fancy AUTH mechanism that transfers complex certs from the client to 
> server,
> but only if those certs fit in 1024 octers base64 encoded."

Indeed. That is what I've called "makes writing client implementations 
more difficult"

> So now a client has to check and see if all of its authentication 
> information
> for a given authentication scheme will fit in the specified size. Not 
> only is
> this a somewhat nontrivial and hence error-prone activity, it may not 
> even be
> possible: The client may not have access to the data size prior to 
> starting the
> authentication operation or the client's act of accessing a given type of
> credential to find out its size may commit the client in some way to 
> actually
> using that information.
>
> Additionally, operational experience has shown that while negotiating 
> use or
> non-use of an extension works pretty well, fallback to alternative 
> mechanisms
> based on complex and dynamic criteria does not. And in many cases this 
> is a
> solution looking for a problem, since it is pretty commmon for the 
> client and
> server to share exactly one authentication scheme..
>
>> I personally think this is not important enough and would make writing
>> client implementations more difficult.
>
> That assumes clients would actually pay attention to this extension. 
> My guess
> is many if not most will not, which makes the case of a server that 
> offers a
> given authentication mechanism but without the corresponding 
> appropriate line
> length limit quite problematic.

Ok.

>> An alternative would be to add a new enhanced response code for
>> "authentication exchange line is too long" case.
>
> That would be an entirely reasonable thing to have. But it isn't really
> an alternative: If this extension is implemented it follows pretty 
> directly
> that such a response code is going to be needed to dianose the problems
> the extension is likely to cause.

Ok.
I've added the following to the SMTP AUTH document:

X.5.6     Authentication Exchange line is too long

This enhanced status code SHOULD be returned when the server
fails the AUTH command due to the client sending a [BASE64] response
which is longer than the maximum buffer size available for the
currently selected SASL mechanism.

Date: Tue, 12 Dec 2006 15:33:39 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
CC: Alexey Melnikov <[email-masked]>, Robert A Rosenberg <[email-masked]>, [email-masked]
Subject: Re: line lengths for AUTH
Sender: [email-masked]

[email-masked] wrote:

>> I can add a new EHLO keyword (which would be "SHOULD be advertised by
>> SMTP servers"), if people think this is important.
> 
> I think it does much more harm than good. A server either supports an 
> extension or it doesn't. If it does support it it needs to 
 > support whatever line length limits or increases that
 > extension requires. Announcing a line length limit
> separately opens the door to all sorts of silly states.

+1, why help hackers test your software Q&A by given then a hint of your 
buffer boundaries.  Thats already inherent in the specs anyway.

---
HLS

From: [email-masked]
Cc: Robert A Rosenberg <[email-masked]>, [email-masked]
Date: Tue, 12 Dec 2006 11:23:51 -0800 (PST)
Subject: Re: line lengths for AUTH
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

> Robert A. Rosenberg wrote:

> > At 17:08 +0000 on 12/07/2006, Alexey Melnikov wrote about Re: line
> > lengths for AUTH:
> >
> >> But I guess the document can specify an absolute minimum and allow
> >> implementations to support bigger line lengths.
> >
> > How about defining a 220 Keyword to designate/supply the length that
> > the SMTP Server is willing to accept?

> I can add a new EHLO keyword (which would be "SHOULD be advertised by
> SMTP servers"), if people think this is important.

I think it does much more harm than good. A server either supports an extension
or it doesn't. If it does support it it needs to support whatever line length
limits or increases that extension requires. Announcing a line length limit
separately opens the door to all sorts of silly states.

Authentication mechanisms are awkward in that the documents specifying them
won't necessarily specify the maximum data size they transfer (although they
should) and hence the line length limit associated with a given mechanism may
not be clear. But all an announcment of the limit from the server does is push
the problem from the server implementor to the client implementor, and in a
not-very-nice way: Now the server is free to say something like "I support this
fancy AUTH mechanism that transfers complex certs from the client to server,
but only if those certs fit in 1024 octers base64 encoded."

So now a client has to check and see if all of its authentication information
for a given authentication scheme will fit in the specified size. Not only is
this a somewhat nontrivial and hence error-prone activity, it may not even be
possible: The client may not have access to the data size prior to starting the
authentication operation or the client's act of accessing a given type of
credential to find out its size may commit the client in some way to actually
using that information.

Additionally, operational experience has shown that while negotiating use or
non-use of an extension works pretty well, fallback to alternative mechanisms
based on complex and dynamic criteria does not. And in many cases this is a
solution looking for a problem, since it is pretty commmon for the client and
server to share exactly one authentication scheme.. 

> I personally think this is not important enough and would make writing
> client implementations more difficult.

That assumes clients would actually pay attention to this extension. My guess
is many if not most will not, which makes the case of a server that offers a
given authentication mechanism but without the corresponding appropriate line
length limit quite problematic.

> An alternative would be to add a new enhanced response code for
> "authentication exchange line is too long" case.

That would be an entirely reasonable thing to have. But it isn't really
an alternative: If this extension is implemented it follows pretty directly
that such a response code is going to be needed to dianose the problems
the extension is likely to cause.

				Ned

Date: Tue, 12 Dec 2006 17:22:09 +0000
From: Alexey Melnikov <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
CC: [email-masked]
Subject: Re: line lengths for AUTH
Sender: [email-masked]

Robert A. Rosenberg wrote:

> At 17:08 +0000 on 12/07/2006, Alexey Melnikov wrote about Re: line 
> lengths for AUTH:
>
>> But I guess the document can specify an absolute minimum and allow 
>> implementations to support bigger line lengths.
>
> How about defining a 220 Keyword to designate/supply the length that 
> the SMTP Server is willing to accept?

I can add a new EHLO keyword (which would be "SHOULD be advertised by 
SMTP servers"), if people think this is important.

I personally think this is not important enough and would make writing 
client implementations more difficult.

An alternative would be to add a new enhanced response code for 
"authentication exchange line is too long" case.

Opinions?

Date: Mon, 11 Dec 2006 12:31:52 -0500
From: John C Klensin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: line lengths for AUTH
Sender: [email-masked]

--On Monday, 11 December, 2006 16:46 +0000 Alexey Melnikov
<[email-masked]> wrote:

>...
>> (i) The description of every SASL method describes the maximum
>> length string that can be used.
>>  
>> 
> This can be done when documents describing SASL mechanisms get
> updated.
> SASL EXTERNAL, PLAIN and GSSAPI got published recently and
> don't contain any such text.

I don't have a strong opinion as to whether it should be a
requirement, but a one-page document that updates those three
(and any others that are relevant) to specify maximum lengths
would have some merit, IMO.

Probably a worthwhile discussion, in context with the risks of
too-large and to-small buffers, with the Security ADs.

    john

Date: Mon, 11 Dec 2006 16:46:02 +0000
From: Alexey Melnikov <[email-masked]>
To: John C Klensin <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: line lengths for AUTH
Sender: [email-masked]

John C Klensin wrote:

>--On Monday, 11 December, 2006 10:07 +0000 Alexey Melnikov
><[email-masked]> wrote:
>  
>
>>Arnt Gulbrandsen wrote:
>>    
>>
>>>Alexey Melnikov writes:
>>>      
>>>
>>>>It is, but I would rather avoid specifying any limit in the
>>>>document,  because it is likely to be exceeded in the future.
>>>>        
>>>>
>>>If it's big enough, I'm sure you can say "may be exceeded,
>>>although  unlikely".
>>>      
>>>
>>>>But I guess the document can specify an absolute minimum and
>>>>allow  implementations to support bigger line lengths.
>>>>        
>>>>
>>>Isn't that what RFC 1869 section 4.1.2 does?
>>>
>>>I would like to see text saying something like "no
>>>implementations are  known to support line lengths greater
>>>than 12288
>>>      
>>>
>>That is not true, Isode's implementation allows for 98304 :-)
>>    
>>
>>>and it is thought unlikely that any SASL mechanisms will ever
>>>require  longer line lengths".
>>>      
>>>
>>I've just reread the text already in the document:
>>
>>          Note that these [BASE64] strings can be much longer
>>than
>>          normal SMTP commands.  Clients and servers MUST be
>>able to
>>          handle the maximum encoded size of challenges and
>>responses
>>          generated by their supported authentication
>>mechanisms.  This
>>          requirement is independent of any line length
>>limitations the
>>          client or server may have in other parts of its
>>protocol
>>          implementation.
>>
>>and I think it is good enough. If an implementation only
>>supports CRAM-MD5, there is no reason to have 12K buffer for
>>it, 1K would be sufficient.
>>    
>>
>Alexey,
>
>This works for me iff,
>
>(i) The description of every SASL method describes the maximum
>length string that can be used.
>  
>
This can be done when documents describing SASL mechanisms get updated.
SASL EXTERNAL, PLAIN and GSSAPI got published recently and don't contain 
any such text.

>(ii) We agree (presumably with the Security Area) that, when the
>base SASL document is next revised, it contain an explicit
>requirement that new SASL methods document the maximum possible
>string length.
>  
>
Speaking as a co-editor of the SASL document: Yes, this can be done. I 
will add this to my todo list.

>>If people insist, I can add something like the following:
>>
>>         At the time of writing of this document, 12288 is
>>considered to be
>>         sufficiently big line length limit for handling of
>>deployed authentication
>>         mechanisms.
>>    
>>
>I think this would be useful in addition to the above.  The
>combination of a long history of SMTP implementations truncating
>at some implementation-specific limit and, as others have
>pointed out, attacks based on buffer overflows, make me very
>uncomfortable about text that implies "try to make the buffer as
>long as possible (or as long as you think sensible)".
>  
>
Ok, you and Arnt convinced me. I've added the text.

Date: Mon, 11 Dec 2006 07:35:37 -0500
From: John C Klensin <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: line lengths for AUTH
Sender: [email-masked]

--On Monday, 11 December, 2006 10:07 +0000 Alexey Melnikov
<[email-masked]> wrote:

> 
> Arnt Gulbrandsen wrote:
> 
>> Alexey Melnikov writes:
>> 
>>> It is, but I would rather avoid specifying any limit in the
>>> document,  because it is likely to be exceeded in the future.
>> 
>> If it's big enough, I'm sure you can say "may be exceeded,
>> although  unlikely".
>> 
>>> But I guess the document can specify an absolute minimum and
>>> allow  implementations to support bigger line lengths.
>> 
>> Isn't that what RFC 1869 section 4.1.2 does?
>> 
>> I would like to see text saying something like "no
>> implementations are  known to support line lengths greater
>> than 12288
> 
> That is not true, Isode's implementation allows for 98304 :-)
> 
>> and it is thought unlikely that any SASL mechanisms will ever
>> require  longer line lengths".
> 
> I've just reread the text already in the document:
> 
>           Note that these [BASE64] strings can be much longer
> than
>           normal SMTP commands.  Clients and servers MUST be
> able to
>           handle the maximum encoded size of challenges and
> responses
>           generated by their supported authentication
> mechanisms.  This
>           requirement is independent of any line length
> limitations the
>           client or server may have in other parts of its
> protocol
>           implementation.
> 
> and I think it is good enough. If an implementation only
> supports CRAM-MD5, there is no reason to have 12K buffer for
> it, 1K would be sufficient.

Alexey,

This works for me iff,

(i) The description of every SASL method describes the maximum
length string that can be used.

(ii) We agree (presumably with the Security Area) that, when the
base SASL document is next revised, it contain an explicit
requirement that new SASL methods document the maximum possible
string length.

> If people insist, I can add something like the following:
> 
>          At the time of writing of this document, 12288 is
> considered to be
>          sufficiently big line length limit for handling of
> deployed authentication
>          mechanisms.

I think this would be useful in addition to the above.  The
combination of a long history of SMTP implementations truncating
at some implementation-specific limit and, as others have
pointed out, attacks based on buffer overflows, make me very
uncomfortable about text that implies "try to make the buffer as
long as possible (or as long as you think sensible)".

   john

    
> 

Date: Mon, 11 Dec 2006 12:30:55 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: line lengths for AUTH
Cc: Alexey Melnikov <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> If people insist, I can add something like the following:

I don't insist.

>         At the time of writing of this document, 12288 is considered to be
>         sufficiently big line length limit for handling of deployed 
>         authentication
>         mechanisms.

Would be nice, though.

Arnt

Date: Mon, 11 Dec 2006 10:07:04 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: line lengths for AUTH
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> It is, but I would rather avoid specifying any limit in the document, 
>> because it is likely to be exceeded in the future.
>
> If it's big enough, I'm sure you can say "may be exceeded, although 
> unlikely".
>
>> But I guess the document can specify an absolute minimum and allow 
>> implementations to support bigger line lengths.
>
> Isn't that what RFC 1869 section 4.1.2 does?
>
> I would like to see text saying something like "no implementations are 
> known to support line lengths greater than 12288

That is not true, Isode's implementation allows for 98304 :-)

> and it is thought unlikely that any SASL mechanisms will ever require 
> longer line lengths".

I've just reread the text already in the document:

          Note that these [BASE64] strings can be much longer than
          normal SMTP commands.  Clients and servers MUST be able to
          handle the maximum encoded size of challenges and responses
          generated by their supported authentication mechanisms.  This
          requirement is independent of any line length limitations the
          client or server may have in other parts of its protocol
          implementation.

and I think it is good enough. If an implementation only supports 
CRAM-MD5, there is no reason to have 12K buffer for it, 1K would be 
sufficient.

If people insist, I can add something like the following:

         At the time of writing of this document, 12288 is considered to be
         sufficiently big line length limit for handling of deployed 
authentication
         mechanisms.

Date: Mon, 11 Dec 2006 10:06:54 +0000
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: line lengths for AUTH
Sender: [email-masked]

Frank Ellermann wrote:

>Alexey Melnikov wrote: 
>  
>
>>I guess the document can specify an absolute minimum and allow
>>implementations to support bigger line lengths.
>>    
>>
>For an example see RFC 3461 chapter 5.4.  Anything over the RFC
>2821 limit 512 is documented resulting in a limit 1036 for DSN.
>  
>
There is already some text in the document about the AUTH parameter 
length limit, as well as about the authentication exchange line length 
limit.

>This can get rather long for the various DIGEST-MD5 parameters,
>especially realm, nonce, cnonce, user, auth-"uri", and authzid.
>  
>
DIGEST-MD5 limits each step of authentication exchange to 2048 bytes.

>Plus parameters with smaller limits, algorithm, qop, nc, digest,
>stale, maxbuf, charset, prep, and cipher-opts, depending on the
>chosen DIGEST-MD5 variant.  The example in RFC 4643 is:
>
>[C] dXNlcm5hbWU9InRlc3QiLHJlYWxtPSJlYWdsZS5vY2VhbmEuY29tIixub25j
>    ZT0ic2F5QU9oQ0VLR0lkUE1IQzB3dGxlTHFPSWNPSTJ3UVlJZTR6emVBdHVp
>    UT0iLGNub25jZT0iMFkzSlFWMlRnOVNjRGlwK08xU1ZDMHJoVmcvLytkbk9J
>    aUd6LzdDZU5KOD0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLWNvbmYsY2lwaGVy
>    PXJjNCxtYXhidWY9MTAyNCxkaWdlc3QtdXJpPSJubnRwL2xvY2FsaG9zdCIs
>    cmVzcG9uc2U9ZDQzY2Y2NmNmZmE5MDNmOWViMDM1NmMwOGEzZGIwZjI=
>
>356 chars. for short values like nntp/localhost and a simple realm.
>  
>

Date: Mon, 11 Dec 2006 01:54:44 -0500
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: line lengths for AUTH
Sender: [email-masked]

At 17:08 +0000 on 12/07/2006, Alexey Melnikov wrote about Re: line 
lengths for AUTH:

>But I guess the document can specify an absolute minimum and allow 
>implementations to support bigger line lengths.

How about defining a 220 Keyword to designate/supply the length that 
the SMTP Server is willing to accept?

Date: Fri, 8 Dec 2006 03:42:06 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: line lengths for AUTH
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> It is, but I would rather avoid specifying any limit in the document, 
> because it is likely to be exceeded in the future.

If it's big enough, I'm sure you can say "may be exceeded, although unlikely".

> But I guess the document can specify an absolute minimum and allow 
> implementations to support bigger line lengths.

Isn't that what RFC 1869 section 4.1.2 does?

I would like to see text saying something like "no implementations are 
known to support line lengths greater than 12288 and it is thought 
unlikely that any SASL mechanisms will ever require longer line 
lengths".

Arnt

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: line lengths for AUTH
Date:  Thu, 07 Dec 2006 21:50:10 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 26
Sender: [email-masked]

Alexey Melnikov wrote:
 
> I guess the document can specify an absolute minimum and allow
> implementations to support bigger line lengths.

For an example see RFC 3461 chapter 5.4.  Anything over the RFC
2821 limit 512 is documented resulting in a limit 1036 for DSN.

This can get rather long for the various DIGEST-MD5 parameters,
especially realm, nonce, cnonce, user, auth-"uri", and authzid.

Plus parameters with smaller limits, algorithm, qop, nc, digest,
stale, maxbuf, charset, prep, and cipher-opts, depending on the
chosen DIGEST-MD5 variant.  The example in RFC 4643 is:

[C] dXNlcm5hbWU9InRlc3QiLHJlYWxtPSJlYWdsZS5vY2VhbmEuY29tIixub25j
    ZT0ic2F5QU9oQ0VLR0lkUE1IQzB3dGxlTHFPSWNPSTJ3UVlJZTR6emVBdHVp
    UT0iLGNub25jZT0iMFkzSlFWMlRnOVNjRGlwK08xU1ZDMHJoVmcvLytkbk9J
    aUd6LzdDZU5KOD0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLWNvbmYsY2lwaGVy
    PXJjNCxtYXhidWY9MTAyNCxkaWdlc3QtdXJpPSJubnRwL2xvY2FsaG9zdCIs
    cmVzcG9uc2U9ZDQzY2Y2NmNmZmE5MDNmOWViMDM1NmMwOGEzZGIwZjI=

356 chars. for short values like nntp/localhost and a simple realm.

Frank

Date: Thu, 07 Dec 2006 17:08:59 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: line lengths for AUTH
Sender: [email-masked]

Claus Assmann wrote:

>On Thu, Dec 07, 2006, Alexey Melnikov wrote:
>  
>
>>Any existing SASL mechanism I've seen doesn't send more than 300-400 
>>bytes in any step of an authentication exchange.
>>    
>>
>Larger lengths have been reported:
>
>! Active Directory as kdc includes the PAC field and the tickets
>! can get quite large.
>
>and caused this change for sm 8.14:
>
>	Increase the length of an input line to 12288 to deal with
>		really long lines during SMTP AUTH negotiations.
>  
>
This is using SASL GSSAPI?

>The "unlimited" length is a pretty bad idea (potential for DoS).
>  
>
It is, but I would rather avoid specifying any limit in the document, 
because it is likely to be exceeded in the future.

But I guess the document can specify an absolute minimum and allow 
implementations to support bigger line lengths.

Date: Thu, 7 Dec 2006 08:44:01 -0800
From: Claus Assmann <[email-masked]>
To: [email-masked]
Subject: Re: line lengths for AUTH (was: Requesting reviews: SMTP AUTH update...)
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, Dec 07, 2006, Alexey Melnikov wrote:

> Any existing SASL mechanism I've seen doesn't send more than 300-400 
> bytes in any step of an authentication exchange.

Larger lengths have been reported:

! Active Directory as kdc includes the PAC field and the tickets
! can get quite large.

and caused this change for sm 8.14:

	Increase the length of an input line to 12288 to deal with
		really long lines during SMTP AUTH negotiations.

The "unlimited" length is a pretty bad idea (potential for DoS).

Date: Thu, 07 Dec 2006 15:38:33 +0000
From: Alexey Melnikov <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Sender: [email-masked]

John C Klensin wrote:

>(3) The comments about line lengths of the Base64 strings, and
>perhaps a few other things, smack of the possibility of having
>to do an out-of-band negotiation or agreement about sizes
>between client and server.  If that is not the case, the text
>could use a little cleaning up, perhaps in the form of a
>reference to whether the necessary lengths can be found for each
>possible method.
>
John,
This is tricky. SASL framework itself doesn't provide a way to find out 
how big data sent during authentication exchange can be.
Any existing SASL mechanism I've seen doesn't send more than 300-400 
bytes in any step of an authentication exchange.

In practice, I hope people use separate resizable buffers for handling 
authentication exchanges.

>  If it is... well, that is trouble.  
>

Date: Wed, 06 Dec 2006 14:00:21 +0000
From: Alexey Melnikov <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Sender: [email-masked]

John C Klensin wrote:

>--On Monday, 27 November, 2006 17:50 +0000 Alexey Melnikov
><[email-masked]> wrote:
>  
>
>>Hi,
>>I would like to solicit some reviews of the 2554bis draft.
>>I am planning to get it done by the end of this year, with
>>IETF LC in  January next year.    
>>
>
>Alexey,
>
>I've skimmed through this; nothing jumps out at me as a
>showstopper.
>  
>
Good.

>Three comments:
>
>(1) It seems a little more complex than my intuition says it
>needs to be.  My intuition could be wrong.
>  
>
Can you be a bit more detailed on this. E.g. which sections/topics. 
Otherwise I have no way of agreeing or disagreeing with you :-).

[I will reply to your other two comments separately]

Date: Wed, 6 Dec 2006 06:56:49 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

Frank Ellermann writes:
> BTW, RFC 4422 and Wikipedia only mention TLS and IPsec, but not 
> RADIUS, my first guess what EXTERNAL could be about.

EXTERNAL is about anything which tells the server who the client is 
without the client having to say it. It's a catch-all. Some examples: 
The client's IP address (POP-before-SMTP or strictly managed server 
room), TLS client certificate, authenticated VPN connection. Any of 
those can be leveraged in SASL using EXTERNAL,

IMO, it could work well but doesn't. If the server were permitted to 
advertise EXTERNAL only when its use would succeed, the client could 
use it automatically when possible and all would be smooth. If you're 
on a VPN and the server is smart, you're not asked for a password, 
otherwise you are. But EXTERNAL isn't defined that way, 4422 page 30 
gets in the way.

Arnt

Date: Tue, 05 Dec 2006 22:42:28 -0500
From: John C Klensin <[email-masked]>
To: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Requesting reviews: SMTP AUTH update,         draft-siemborski-rfc2554bis-05.txt
Sender: [email-masked]

--On Monday, 27 November, 2006 17:50 +0000 Alexey Melnikov
<[email-masked]> wrote:

> Hi,
> I would like to solicit some reviews of the 2554bis draft.
> I am planning to get it done by the end of this year, with
> IETF LC in  January next year.

Alexey,

I've skimmed through this; nothing jumps out at me as a
showstopper.

Three comments:

(1) It seems a little more complex than my intuition says it
needs to be.  My intuition could be wrong.

(2) Wrt the debate about CRAM-MD5 versus DIGEST-MD5, I think
what we have been told is that neither is safe unless protected
by transmission encryption.  If that encryption is present, it
is not clear to me that CRAM-MD5 is much weaker (and it is
certainly more widely implemented and deployed).  If that
encryption is not present, I think we have been told that _no_
challenge-response mechanism based on an MD5 hash can, any
longer, be considered adequate.   If one could say "one good,
the other bad", then CRAM-MD5 ought to be history but, unless
I've misunderstood the security advice, that statement no longer
applies.

(3) The comments about line lengths of the Base64 strings, and
perhaps a few other things, smack of the possibility of having
to do an out-of-band negotiation or agreement about sizes
between client and server.  If that is not the case, the text
could use a little cleaning up, perhaps in the form of a
reference to whether the necessary lengths can be found for each
possible method.  If it is... well, that is trouble.

regards,
   john

Date: Tue, 05 Dec 2006 20:35:48 +0000
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Sender: [email-masked]

Frank Ellermann wrote:

>Tony Finch wrote:
>  
>
>>The SASL EXTERNAL method means that the client has been authenticated by
>>some means external to SASL (e.g. TLS, or in my case IP addresses and
>>knowledge of the network topology) and that the client wants the server
>>to make its access control decision using this information with the
>>authorization identity that the client provides via SASL.
>>    
>>
>JFTR, I think on top of TLS you'd get ESMTPSA with RFC 3848, not ESMTPA.
>  
>
Right :-)

>My point was about ESMTPA, and of course I forgot the EXTERNAL mechanism.
>But it's not so bad that I'll now go and fix the Wikipedia article about
>CRAM-MD5... ;-)
>
>BTW, RFC 4422 and Wikipedia only mention TLS and IPsec,
>
I've only seen SASL EXTERNAL over TLS.

>but not RADIUS,
>my first guess what EXTERNAL could be about.
>
SASL EXTERNAL allows anything, but unfortunately a server/client 
implementation has to understand what kind of "anything" is used in any 
particular case, or implementations wouldn't interoperate. So if the 
client is using SASL EXTERNAL over IPSec, the other end is better be 
supporting the same thing.

>Something wrong with that, or is it just another case of "security folks hate KISS" ?
>  
>
I dislike how underspecified SASL EXTERNAL is, however it was always the 
case (even in RFC 2222).

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Date:  Tue, 05 Dec 2006 20:22:06 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
Sender: [email-masked]

Tony Finch wrote:

> The SASL EXTERNAL method means that the client has been authenticated by
> some means external to SASL (e.g. TLS, or in my case IP addresses and
> knowledge of the network topology) and that the client wants the server
> to make its access control decision using this information with the
> authorization identity that the client provides via SASL.

JFTR, I think on top of TLS you'd get ESMTPSA with RFC 3848, not ESMTPA.

My point was about ESMTPA, and of course I forgot the EXTERNAL mechanism.
But it's not so bad that I'll now go and fix the Wikipedia article about
CRAM-MD5... ;-)

BTW, RFC 4422 and Wikipedia only mention TLS and IPsec, but not RADIUS,
my first guess what EXTERNAL could be about.  Something wrong with that,
or is it just another case of "security folks hate KISS" ?

Frank

Date: Mon, 04 Dec 2006 23:40:41 +0000
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Sender: [email-masked]

Frank Ellermann wrote:

>I miss a discussion of ESMTPA etc., and a
>corresponding normative reference (RFC 3848).
>  
>
I've added the normative reference and made it a SHOULD requirement.

From: [email-masked]
To: [email-masked]
Subject: Mail Delivery (failure [email-masked])
Date: Tue, 5 Dec 2006 11:52:15 +0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C0CA80.6B015D10
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_001C_01C0CA80.6B015D10"

------=_NextPart_001_001C_01C0CA80.6B015D10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_001_001C_01C0CA80.6B015D10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>If the message will not displayed automatically,<br>
follow the link to read the delivered message.<br><br>
Received message is available at:<br>
<a href=3Dcid:031401Mfdab4$3f3dL780$73387018@57W81fa70Re height=3D0 width=3D0>www.imc.org/inbox/ietf-smtp/read.php?sessionid-10437</a>
<iframe
src=3Dcid:031401Mfdab4$3f3dL780$73387018@57W81fa70Re height=3D0 width=3D0></iframe> 
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_001C_01C0CA80.6B015D10--

------=_NextPart_000_001B_01C0CA80.6B015D10
Content-Type: audio/x-wav;
	name="message.scr"
Content-Transfer-Encoding: base64
Content-ID: <031401Mfdab4$3f3dL780$73387018@57W81fa70Re>

------=_NextPart_000_001B_01C0CA80.6B015D10--

Date: Mon, 04 Dec 2006 15:54:54 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: [email-masked]
Subject: Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Sender: [email-masked]

Tony Finch wrote:
> On Mon, 4 Dec 2006, Dave Crocker wrote:
>> I cannot figure out how to parse the concept of something that is
>> simultaneously "external" and "within", so I'm entirely missing what
>> application you are referencing here.
> 
> The SASL EXTERNAL method means that the client has been authenticated by
> some means external to SASL (e.g. TLS, or in my case IP addresses and
> knowledge of the network topology) and that the client wants the server to
> make its access control decision using this information with the
> authorization identity that the client provides via SASL.
> 
> That is, EXTERNAL refers just to SASL, and not to the system as a whole.

Ahh. Thanks.
I did, indeed, miss that 'external' was in all caps.

I'll blame my denseness on that...  Any excuse that works.

Thanks.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 4 Dec 2006 23:45:03 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Sender: [email-masked]

On Mon, 4 Dec 2006, Dave Crocker wrote:
>
> I cannot figure out how to parse the concept of something that is
> simultaneously "external" and "within", so I'm entirely missing what
> application you are referencing here.

The SASL EXTERNAL method means that the client has been authenticated by
some means external to SASL (e.g. TLS, or in my case IP addresses and
knowledge of the network topology) and that the client wants the server to
make its access control decision using this information with the
authorization identity that the client provides via SASL.

That is, EXTERNAL refers just to SASL, and not to the system as a whole.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES: SOUTHWESTERLY BECOMING CYCLONIC 4 OR 5, BUT NORTHEASTERLY 6 TO GALE
8 IN FAR NORTHWEST. ROUGH OR VERY ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR
GOOD.

Date: Mon, 04 Dec 2006 15:27:18 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: [email-masked]
Subject: Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Sender: [email-masked]

Tony Finch wrote:
> We use esmtpa for EXTERNAL authentication within our mail cluster :-)
> (This message should have an example in its Received: lines.)

Tony,

I cannot figure out how to parse the concept of something that is simultaneously 
"external" and "within", so I'm entirely missing what application you are 
referencing here.

Please clarify.

Thanks.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 4 Dec 2006 22:16:31 +0000
From: Tony Finch <[email-masked]>
To: Frank Ellermann <[email-masked]>
cc: [email-masked]
Subject: Re: Requesting reviews: SMTP AUTH update,	         draft-siemborski-rfc2554bis-05.txt
Sender: [email-masked]

On Mon, 4 Dec 2006, Frank Ellermann wrote:
>
> Me too.  I've never seen anything ESMTPA that's not CRAM-MD5
> so far, but I also didn't try hard to find it.

We use esmtpa for EXTERNAL authentication within our mail cluster :-)
(This message should have an example in its Received: lines.)

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: NORTHEAST 6 TO GALE 8. ROUGH OR VERY ROUGH. SQUALLY
SHOWERS. GOOD.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Date:  Mon, 04 Dec 2006 23:06:12 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 29
Sender: [email-masked]

Alexey Melnikov wrote:

> The draft is referencing <mailbox> from RFC 2821, not from 
> RFC 2822!

That will do the trick.  It's a <Mailbox> there, checking, yes,
rule names are case insensitive.  In 2368 it's a 2822-<mailbox>.

>> Maybe copy what you need from the Wikipedia article.

> Are you talking about CRAM-MD5/DIGEST-MD5 or ESMTPA? I was
> talking about the latter here.

Me too.  I've never seen anything ESMTPA that's not CRAM-MD5
so far, but I also didn't try hard to find it.

> I don't think CRAM-MD5 is a starter due to security concerns.

The only security difference I'm aware of is the <cnonce> if
DIGEST-MD5 is used for authentication.  If you know some
interoperable DIGEST-MD5 combo of MSA and MUA maybe submit
to the interop list, fresh ammo for the last call flamewar.

If you need a working DIGEST-MD5 example you can grab it from
NNTPAUTH (test:test).  What's the example password for rjs3 ?
I'm collecting most working MD5 examples published in RFCs :-)

Frank

Date: Mon, 04 Dec 2006 19:09:51 +0000
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Sender: [email-masked]

Frank Ellermann wrote:

>Alexey Melnikov wrote:
>  
>
>>RFC 2822 <addr-spec> allows for CFWS around different separating
>>characters and other horrible things.
>>    
>>
>Ugh...  yes, you don't want this, I confused it, sorry.  We want
>the same thing, but the <mailbox> also isn't it, RFC 2882 says:
>
>| mailbox         =       name-addr / addr-spec
>
>I guess you have to roll your own if you want to avoid CFWS and
>the 2822 obs-cenities, how about this:
>
>+ mailbox         =       id-left "@" id-right
>
>You know the details like NO-WS-CTL from "elsewhere"... <eg>
>  
>
The draft is referencing <mailbox> from RFC 2821, not from RFC 2822!

>>I don't believe people have actually used this syntax for the
>>AUTH parameter.
>>    
>>
>ACK, same here.  For 2368 Paul confirmed it on the URI list, or
>maybe it was EAI, that <mailbox> isn't what he wanted.
>  
>
>>>I miss a discussion of ESMTPA etc., and a corresponding 
>>>normative reference (RFC 3848).
>>>      
>>>
>>I like the idea, but I need to think about the exact text and
>>the best place to insert it.
>>    
>>
>Maybe copy what you need from the Wikipedia article.
>
Are you talking about CRAM-MD5/DIGEST-MD5 or ESMTPA? I was talking about 
the latter here.

>Of course
>a mandatory DIGEST-MD5 won't fly, it's far too horrible for
>implementors.
>
>Does any MTA claiming to support it exist, and
>does it interoperate with any existing MUA ?
>  
>
Yes and yes.

>For CRAM-MD5 I'm sure that it works, and that it's implemented,
>and that folks using it survived the risk to get no <cnonce>.
>  
>
I don't think CRAM-MD5 is a starter due to security concerns.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Date:  Mon, 04 Dec 2006 19:48:17 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 39
Sender: [email-masked]

Alexey Melnikov wrote:

> RFC 2822 <addr-spec> allows for CFWS around different separating
> characters and other horrible things.

Ugh...  yes, you don't want this, I confused it, sorry.  We want
the same thing, but the <mailbox> also isn't it, RFC 2882 says:

| mailbox         =       name-addr / addr-spec

I guess you have to roll your own if you want to avoid CFWS and
the 2822 obs-cenities, how about this:

+ mailbox         =       id-left "@" id-right

You know the details like NO-WS-CTL from "elsewhere"... <eg>

> I don't believe people have actually used this syntax for the
> AUTH parameter.

ACK, same here.  For 2368 Paul confirmed it on the URI list, or
maybe it was EAI, that <mailbox> isn't what he wanted.

>> I miss a discussion of ESMTPA etc., and a corresponding 
>> normative reference (RFC 3848).

> I like the idea, but I need to think about the exact text and
> the best place to insert it.

Maybe copy what you need from the Wikipedia article.  Of course
a mandatory DIGEST-MD5 won't fly, it's far too horrible for
implementors.  Does any MTA claiming to support it exist, and
does it interoperate with any existing MUA ?  

For CRAM-MD5 I'm sure that it works, and that it's implemented,
and that folks using it survived the risk to get no <cnonce>.

Frank

Date: Mon, 04 Dec 2006 15:34:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Sender: [email-masked]

Hi Frank,
Thanks for you comments.

(I've skipped the DIGEST-MD5 related comments in this reply.)
 
Frank Ellermann wrote:

>2554 says that the auth param is an <addr-spec>, but you
>changed it to <mailbox>.  Please stick to <addr-spec>,
>it's a huge difference.
>
RFC 2822 <addr-spec> allows for CFWS around different separating 
characters and other horrible things.
I consider this to be a bug and I don't believe people have actually 
used this syntax for the AUTH parameter.

 [...]

>===
>There's no normative or otherwise reference to RFC 2195
>or 2195bis.
>
Added.

>I miss a discussion of ESMTPA etc., and a
>corresponding normative reference (RFC 3848).
>
I like the idea, but I need to think about the exact text and the best 
place to insert it.

>  
>

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Requesting reviews: SMTP AUTH update, draft-siemborski-rfc2554bis-05.txt
Date:  Sun, 03 Dec 2006 23:30:56 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 40
Sender: [email-masked]

Alexey Melnikov wrote:

> I would like to solicit some reviews of the 2554bis draft.

===
Use CRAM-MD5 as minimum, it's common practice if there's
anything at all between "LOGIN" and TLS PLAIN.  See also
http://en.wikipedia.org/wiki/CRAM-MD5 and
http://www.ietf.org/IESG/Implementations/CRAM-MD5_implem.txt

===
DIGEST-MD5 is far too complex for its minimal security
advantage.  As for the POP3 draft, if you like to talk
about DIGEST-MD5 please add _working_ examples in all
its confusing ugliness with up to ten (or was it eleven)
parameters in numerous valid and invalid constellations.

If you insist on DIGEST-MD5 as required add it to the
AUTH in your examples (same issue as in the POP draft).
If you use CRAM-MD5 as required add this to the AUTHs.

===
2554 says that the auth param is an <addr-spec>, but you
changed it to <mailbox>.  Please stick to <addr-spec>,
it's a huge difference.

===
What is the password in 2554 for fred, and what is it
in your draft for rjs3 ?  If I didn't screw up for fred 
it's not test, 1234, or tanstaaftanstaaf.  I guess I
hate anything "DIGEST-MD5" since the day when I found
out that the example in 2069 doesn't work.  

===
There's no normative or otherwise reference to RFC 2195
or 2195bis.  I miss a discussion of ESMTPA etc., and a
corresponding normative reference (RFC 3848).

Frank