[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Security



On 12 Aug 2008, at 12:54 PM, Frank Ellermann wrote:



Kurt Zeilenga wrote:

 [TLS]

That places restrictions on specifications, not implementations,
which is somewhat weird, but CRAM-MD5 could do the same.  That
is what I propose to do.



I personally think such a change would be good.   I feel that TLS
recommendations to protect CRAM-MD5 ought to be the same as those
we made for the TLS protection of PLAIN.


Could work.  What about existing protocols, has this to be limited
to future specifications ?
The RFC 4616 requirement upon technical specifications applies regardless of whether that technical specification details a new or existing protocol. The requirements simply means that when one revises a technical specification then need to address an additional concern. 


Normally we say "SHOULD" when we mean
"old stuff has a good excuse, its old".


There are many reasons to use SHOULD.


IIRC there are a two old
protocols with a mandatory CRAM-MD5, one of them (on demand relay)
won't be updated anytime soon, if ever.
One might view newer requirements upon technical specification as a reason to update older specifications... 


 [i18n]

SHOULD has worked fine for PLAIN, so I disagree.


It works fine because of PLAIN's design.  The party, the server, is
preparing both the presented and stored strings.   In CRAM-MD5, two
parties need to agree on the preparation on what preparation to use
for things to work properly.


I don't get this point.  A new user creating an account picks a
free userid, and a password.  The details can vary, one way is
online in a Web form.  If the server can note these credentials
for PLAIN, it can also note it for CRAM-MD5 or other mechanisms,
in any required format(s), even the somewhat odd "APR1" format.
The point is that server is viewed has having more knowledge about the properties of values stored in its password store than the client. The client has no clue as to what encoding / preparation was used within the password store.
With PLAIN, the client lack of knowledge doesn't matter. It simply provides the UTF-8 encoded Unicode password. The server can sort it out.
But with CRAM-MD5, for independently implemented interoperability, the client must prepare the password for input into the cryptographic functions the same way the server does. The client and server need to agree as to how to prepare the input to the cryptographic functions.
Note that RFC 4616 actually does detail why it used a SHOULD instead of a MUST. I would argue that CRAM-MD5, for consideration on the Standard Track, do likewise. 

One could argue that one could get away with something like:
Except where the client and server have an a priori agreement to utilize a different character set, encoding, and/or preparation, the password MUST be represented using Unicode, prepared using SASLprep, and encoded as UTF-8 prior to input to the cryptographic functions. 

Or alternatively as:
The password SHOULD be represented using Unicode, prepared using SASLprep, and encoded as UTF-8 prior to input to the cryptographic functions. Use of Unicode, SASLprep, and UTF-8 are not mandatory to allow clients and servers which have a priori agreements to use other character sets, character set encoding, and/or preparation to use whatever character sets, character set encoding, preparation they might agree to. How a client and server might reach such an agreement is outside the scope of this specification. It is also noted that such agreements will hinder interoperability with clients and servers strictly implement this specification (e.g., adhere to the above SHOULD).
As I noted when I recently brought up intended publication track of this I-D, one option is Standard Track with waiver. The above text is basically asking for a waiver from the RFC 4422 requirement. 


In what way is the design of PLAIN different ?  Like CRAM-MD5 it
sends the userid as plain text.


Unlike CRAM-MD5, PLAIN sends the password as plain text.




Frank