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
Attachment:
pgp00000.pgp
Description: PGP signature