Subject: SRP CP/IP/RD options

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 15 Jan 2002 13:51:50 -0500

I'm confused why there are options to negotiate encryption but not
integrity, etc.  Is there some feature that's served by allowing
people to negotiate somewhat nonsensical options?  Shouldn't we
require replay detection if you're going through the trouble of
integrity?  Shouldn't we require integrity protection if you're going
through the trouble of encryption?

I think there should be a substantial benefit to these options if
they're going to be left in.  In my view, they'll just cause
interoperability and testing headaches without serving any useful
purpose.

I therefore propose that the chart in 5.4:

      CP   IP   RD   Peer sends/receives

      I    I    I    { eos(p) }
      I    A    I    { eos(p) | os( IALG(K)( bytes(p) ) ) }
      I    A    A    { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) }
      A    I    I    { eos(c) }
      A    A    I    { eos(c) | os( IALG(K)( bytes(c) ) ) }
      A    A    A    { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) }

should be just:

      CP   IP   RD   Peer sends/receives

      I    I    I    { eos(p) }
      I    A    A    { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) }
      A    A    A    { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) }

Larry

---

From: "Raif S. Naffah" <[email-masked]>
Date: Wed, 30 Jan 2002 21:00:36 +1100

At 02:44 PM 1/22/02 -0800, Kurt D. Zeilenga wrote:
>At 10:08 AM 2002-01-22, Lawrence Greenfield wrote:
> >I'd at least like to see a strong recommendation in the document that
> >security be accompanied by integrity, but I guess I'd like to see an
> >example of a real world SASL using application that _needs_
> >confidentiality without integrity.
>
>Personally, it seems quite pointless to go through the expense
>of SRP and then to through away its value by not using
>providing replay/integrity protection for the stream.  For
>non-Internet applications, I can see where no-replay/no-integrity
>might be appropriate. But, for the Internet, both SHOULD be
>used (regardless of confidentiality protection).

as per the latest discussion, the SRP mechanism now offers a security layer 
with IP (Integrity) and CP (Confidentiality), independantly settable; i.e.

       CP   IP   Peer sends/receives

       I    I    { eos(p) }
       I    A    { eos(p) | os( IALG(K)( bytes(p) | bytes(q)) ) }
       A    I    { eos(c) }
       A    A    { eos(c) | os( IALG(K)((bytes(c) | bytes(q)) ) }

as we understand it, the discussion is now whether to allow the first 
option or not as a valid combination.

what feature to activate and when to do so is the responsibility of the 
user.  there's nothing inherently insecure about each individual 
combination.  in all of them, the mechanism has achieved its first 
objective which is authentication of the client, and depending on the 
selected feature, authentication of the server as well.

if the user is willing to assume that, among other factors, the risk of 
session hijacking is minimal and high speed is important, then the first 
combination is a solution.

we agree that a security layer with integrity protection should be the 
default configuration.  we therefore will state, in the next draft, that at 
least one integrity algorithm MUST be offered by the server and that 
integrity protection SHOULD be chosen by the client.

thank you for your comments + cheers;
Keith + Raif