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

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 protected]> and/or draft authors.

John Viega wrote:

> 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.

...skipped...

> 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.

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.

> 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?

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

...skipped...

> 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.

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.

> 8) The specication does say that the two OFB states (on the client and
> 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
> 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.

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.
__________________________________________