Subject: draft-burdis-cat-srp-sasl-06.txt

From: John Viega <[email-masked]>
Date: Sat, 6 Apr 2002 03:35:57 -0500

I've just reviewed the SRP/SASL draft, and I have some comments that I
hope will be somewhat useful.  Some of these might be dead wrong... my
apologies in advance.
 
1) I don't really like the method for protecting against key reuse
problems.  First, SRP doesn't really have a key reuse problem, even
when used with a stream cipher (or block cipher in a stream mode)
assuming the PRNG used on each side is securely seeded, and assuming
there's no resumption mechanism (which there isn't as far as I could
see).  

Second, if there is a key reuse problem, from my first reading, at
least, the search space is only 2^16, which is too low.  I think this
is probably just underspecified, although I don't see why one wouldn't
just use a completely random IV, instead of using a null IV.  Probably
the additional k-4 octets in the block are meant to be random?

Third, even with the above construction assumed, the way I read it, it
does not do what it is intended to do.  In OFB, given a particular key
and IV, they keystream is constant.  Neither the plaintext nor the
ciphertext impacts the keystream.  The description indicates that the
first block should be the special value that "makes up for the IV"
(let's call it N).  Since the IV in OFB is the first block of
plaintext to the ECB encryption when generating the keystream, that
can't be what N is.  

Encryption with OFB doesn't really work on blocks, so any other
description doesn't make so much sense.  Assuming the spec means the
first k octets of the keystream, then I have to assume that the first
N bits of plaintext are set to N.  The plaintext doesn't affect the
keystream, though, which is the intent of N.

2) Why OFB?  OFB has really been losing in popularity recently to
counter mode, because they largely have the same properties, except
that counter mode allows for random access and parallel computation of
the keystream.  CTR mode is now a NIST-recommended mode of operation,
and has provable security properties, assuming the security of the
underlying block cipher.  There's no compelling reason to use OFB over
CTR mode.  

3) I don't understand why one would ever want to make encryption,
integrity and replay resistance optional.  I'd prefer to see a
specification that's easy to implement and apply securely.  If
everything other than authentication is optional, then security
against common network attacks is the responsibility of the people
applying the protocol, which is, IMHO very bad.  I suppose that
allowing for insecure usage caters to those who want to use SRP in
some environments where SASL is already being used insecurely.  In
that case, why not allow, but perhaps recommend against?

4) There are lots of ambiguities in the spec, from what I can tell.
For example, the shared secret one derives from SRP is twice the
digest length of the hash function.  It isn't well-specified how to
convert the shared secret into the keys used for the encryption and
message authentication.  I assume simple truncation, but why not use
seprate halves of the output to key the MAC and the cipher separately?

5) I wonder if people would consider the CCM-AES encryption mode as
the only mode, or the only required mode.  CCM-AES is proposed for the
new 802.11 security standard, and, from what I've heard, it is
expected to be fast-tracked through NIST to become an approved mode
for AES.  It essentially combines CTR mode with CBC-MAC using a single
key.  It is patent unencumbered.  It is provably secure, and simple to
implement.  Additionally, to streamline things, I think the server
proof should be mandatory.

Even if people don't agree with a "simpler is better" philosophy, how
would CCM-AES (or OCB mode for that matter) be specified?  It's an
encryption algorithm, but it does integrity, and it isn't clear at all
how such a thing would be specified.

6) For parameter generation, I'd like to see a requirement for secure
seeding of the PRNG, and use of a cryptographically secure PRNG.  

7) What happens when tampering is detected?  How is an exception
signaled?  Is *abortion* actually required, or can one side request a
retransmission?  I'd like more specification here, and it'd be great
if connections could survive a non-sustained integrity attack.

8) The specication does say that the two OFB states (on the client and
server ends) need to be in lockstep.  This implies that there can be
no asynchronous sending of messages, lest there be a race condition on
the state.  I consider that quite a drawback for some protocols.  I'd
love to see an option for supporting asynchronous connections by using
two encryption contexts.  

9) How do the sides know how long the plaintexts for individual
messages are??  That's not specified, as far as I could find.  I see a
specification for the maximum ciphertext buffer size, though.

10) The section on padding is totally baffling to me.  OFB has no need
for padding.  The unused bytes of the key stream can be saved for the
next message.  This seems totally superfluous, or am I missing
something?

John

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 28 Apr 2002 21:24:28 +0100

Hi John,

I am not the author of SASL SRP, but I will comment on some of your points.
Also, you should probably send comments about SASL SRP to SASL mailing list
<[email-masked]> and/or draft authors.

> hope will be somewhat useful.  Some of these might be dead wrong... my

...skipped...

> some environments where SASL is already being used insecurely.

The main point of SASL in authentication. Integrity and privacy protection are
optional for a SASL mechanisms.

> In that case, why not allow, but perhaps recommend against?

Sure.

> seprate halves of the output to key the MAC and the cipher separately?

You are correct, this has to be clarified in the document.

...skipped...

> if connections could survive a non-sustained integrity attack.

SASL work only with reliable data streams, so the only way you can signal an
exception is to abort the connection. Also, there is no way of knowing whether
somebody is tampering or whether there is a bug in the other peer's
implementation of SASL SRP.

> server ends) need to be in lockstep.

I don't believe that the document actually says that. But you are right,
encryption states for sending and receiving must be separate and this is how
it is in other SASL mechanisms.

> This implies that there can be

Well, you can estimate maximum plaintext buffer size from the maximum
ciphertext buffer size. Although I haven't seen a SASL mechanisms that defined
"maximal ciphertext buffer size", it always was "maximal plaintext buffer
size".

Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

I speak for myself only, not for my employer.
__________________________________________