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

Re: Random data





On Aug 12, 2008, at 2:34 AM, Simon Josefsson wrote:


Lyndon Nerenberg <lyndon@xxxxxxxxxx> writes:

Depends on which traits one thinks are desirable.   In general, I
would say that CRAM-MD5 offers slightly better security than PLAIN,
while PLAIN offers better ability to support external/legacy
password stores, proxy-authz, etc.

Where is the peer reviewed analysis of CRAM-MD5 vs. PLAIN that
everyone alludes to? A simple reference to it in son-of-2195 would
solve this argument.

I'm not aware of any existing good analysis of C vs P, but a comparison
can be made in a table.  Here is a starting point.  Questions of the
applicability of PLAIN vs CRAM-MD5 often comes up in deployment
discussions, so I agree that adding it to 2195bis would be a good thing.

This straw-man needs to be expanded and reviewed carefully though.


                       PLAIN               CRAM-MD5

Support for
Authorization             Yes                  No
Identity

Supports Mutual Authentication	No No

Transfers identities in clear text	Yes (*)	Yes (*)


Transfers
Passwords
in Clear Text             Yes (*)              No

Compatible with
hashed password           Yes                  No
databases, such
as Unix
/etc/shadow (**)

Requires a
mechanism-                Yes                  No
specific
password database (**)

Your answers to this seem reversed.

PLAIN doesn't require a mechanism specific password store. Given the server has the presented password, the server can verify it against any password store, regardless of the algorithms used in that storage. Unlike CRAM-MD5.



Supports a
Channel Binding            No                  No

Cryptographic security
status                     None                Medium (***)

Though I am certainly not an crypto expert, I would not give CRAM-MD5 a medium here. I'd probably give it a Minimal, to imply that the security benefit the mechanism gains by its use of crypto is minimal.



Support for non-ASCII
identities (SASLPrep       Yes                 No (?)
or UTF-8)

...

(*) PLAIN solves the security problem by being used under TLS.


(**) This is a consequence of the previous item, but explained from a
different point of view which often comes up in deployment.

(***) There are no published attack against HMAC-MD5 even though the
underlying MD5 function has been attacked.  There are analysis that
suggests HMAC can be used securely even with moderately broken hash
functions. [Reference to Krawczyk's paper]

There is still concerns about dictionary attacks. Of course, this isn't much of an issue when TLS is used.



/Simon