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: Ken Murchison <[email-masked]>
Date: Thu, 17 Jan 2002 14:03:15 -0500

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

Since I'm updating the CMU SASL implementation to draft -06, and would
like to make any other proposed changes at the same time, I thought I'd
try to spark this thread to see if we can get a resolution.

I tend to agree with Larry.

This scheme will greatly simplify implementations and reduce the amount
of option "chatter" in the exchanges.  The "reply detection" option can
go away, since it would always be done as part of integrity protection. 
Also, the server would only have to use either "mandatory=integrity" or
"mandatory=confidentiality" since "confidentiality" implies "integrity"
and "integrity" implies "replay detection".

FWIW, this same scheme is also used in DIGEST-MD5.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sun, 20 Jan 2002 10:24:56 +1100

At 01:51 PM 1/15/02 -0500, Lawrence Greenfield wrote:

>through the trouble of encryption?...

Later, at 02:03 PM 1/17/02 -0500, Ken Murchison wrote:

 > ...I tend to agree with Larry...

We agree that integrity protection without replay detection is not that 
useful. It also results in messages of the same size and adds little 
processing overhead, so we will remove the "replay detection" option and 
combine it with integrity protection, as suggested.

However, we believe that there are some situations that justify 
confidentiality protection without integrity protection --e.g. short-lived 
confidential exchanges or applications concerned with the number of bits on 
the wire. If the recepient does not hold a valid session key, he/she will 
not be able to
access the plaintext, so integrity protection is not strictly necessary.

Keith + Raif

---

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 22 Jan 2002 13:08:10 -0500

Date: Sun, 20 Jan 2002 10:24:56 +1100
   From: "Raif S. Naffah" <[email-masked]>
[...]
   We agree that integrity protection without replay detection is not that 
   useful. It also results in messages of the same size and adds little 
   processing overhead, so we will remove the "replay detection" option and 
   combine it with integrity protection, as suggested.

Good.

   However, we believe that there are some situations that justify
   confidentiality protection without integrity protection
   --e.g. short-lived confidential exchanges or applications concerned
   with the number of bits on the wire. If the recepient does not hold
   a valid session key, he/she will not be able to access the
   plaintext, so integrity protection is not strictly necessary.

It's not clear to me that application programmers will frequently make
the right choice on this.  We'll probably force the Cyrus SASL library
to always negotiate integrity if confidentiality is desired simply
because this is a genuine pain.

Remember, the first in SASL standards for "Simple"; let's try to keep
the mechanisms as simple as possible to use correctly.

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.

Larry

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 22 Jan 2002 14:44:20 -0800

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

Kurt

---

From: Ken Murchison <[email-masked]>
Date: Thu, 17 Jan 2002 14:03:15 -0500

Ken

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sun, 20 Jan 2002 10:24:56 +1100

Keith + Raif

---

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 22 Jan 2002 13:08:10 -0500

Good.

Larry

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 22 Jan 2002 14:44:20 -0800

Kurt