From: Marco Colombo (no email)
Date: Mon Mar 14 2005 - 06:01:22 EST
Rob Siemborski wrote:
> On Fri, 11 Mar 2005, Marco Colombo wrote:
>
>> Ok technically speaking SSL/TLS is not part of SASL. But the two are
>> related. Maybe I'm biased by the fact that most of the connections I see
>> are SSL+plaintext. So I was referring to SSL keys actually.
>
>
> Sure, or, say, kerberos keys.
>
> For what SASL is using it for, its a far lesser sin.
>
>> I have to say I'm not familiar with CRAM-MD5/DIGEST-MD5. But in the
>> latter
>> the channel can be encrypted, so I guess at some point a shared session
>> key is generated.
>
>
> Yes, there is a session key here, but the information it is based off of
> is the nonces (as I said, they need to be sent in the clear anyway, so
> coming from urandom doesn't matter that much), the shared secret, and
> some static text.
>
> See RFC 2831.
Well, now I _am_ confused. The nonce is sent in plain, but the RFC says:
The contents of the nonce are implementation dependent. The
security of the implementation depends on a good choice. It is
RECOMMENDED that it contain at least 64 bits of entropy.
So, the RFC is saying you'd better get the nonce value (and cnonce too)
from /dev/random, at least 8 bytes. Then you can encode them in hex or
base64 (which will result in longer string of course, but still with 64
bits of entropy in it).
As I read it, it is _not_ recommended to use /dev/urandom, which may let
you generate a nonce value with 0 bits of entropy. That's true also for
the client and cnonce value.
Now the problem is different. I agree someone attacking the kernel PRNG
is not pratical a threat. But if you want to confrom to RFC 2831, you need
to "understand the full implications":
[RFC 2119]
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
Now, can you claim conformance to RFC 2831 if you're using /dev/urandom?
Does the fact that your cyrus server is heavily used fall under those
"particular circumstances"? Or is it normal operations, instead?
What are the "valid reasons" you found not to use /dev/random, in your
_particular_ case?
In general: we've got here a security mechanism that apparently is, by
design, based on a combination of entropy and crypto techniques. If we
substitute the entropy with something that is protected by another
crypto technique, what claims can we make on the final result? Do the
two different techniques mix together in a cryptographicly secure way?
Or have we introduced some subtle weakness in the system? The brief
history of computer cryptography is full of examples of combinations of
different algorithms with no added strengh or, even worse, less strengh
than the components alone.
Now, I'm not being theoretical. I'm being bureaucratic. :-)
As far as I'm concerned, the whole purpose of this thread was to make
steps towards "fully understanding the implications".
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
|
|
|