[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