Subject: SRP security layer output

From: Ken Murchison <[email-masked]>
Date: Wed, 23 Jul 2003 16:01:37 -0400

After working through the draft again in detail and attempting to bring 
the CMU implementation up to date, I found that the documented security 
layer output is suboptimal.

The main problem that I found is that when no layer is active, the raw 
data still needs to be put into an EOS and then wrapped in a buffer. 
This means that the raw data would be prepended with three 4-byte 
lengths (counting the one already required by RFC 2222[bis]).  I'm 
pretty sure that the other mechs that support security layers don't 
require the raw data to be encoded/decoded when no layer is active.

I also don't see the point in wrapping the data segments into EOS and OS 
even when layers *are* active.  Given the fact that SASL already 
requires the 4-byte length prepended to the output, and we know that the 
size of the HMAC is fixed, why not just append the HMAC to the 
raw/encrypted data and send them as plain bytes?  The HMAC will always 
be the last 'hashlen' bytes and the data will always be the first 
'inputlen-hashlen' bytes.

So, I'm proposing this change to section 5.5 (Note that this eliminates 
the EOS data element from the spec):

       CP   IP   RD   Peer sends/receives

       I    I    I    bytes(p)
       I    A    I    bytes(p) | IALG(Ki)( bytes(p) )
       I    A    A    bytes(p) | IALG(Ki)( bytes(p) | bytes(q) )
       A    I    I    bytes(c)
       A    A    I    bytes(c) | IALG(Ki)( bytes(c) )
       A    A    A    bytes(c) | IALG(Ki)( bytes(c) | bytes(q) )

This allows applications and/or SASL implementations to short-circuit 
the no layer case (output = input) and potentially eliminates buffer 
copies resulting from the data wrapping.

Also, with regards to the table, I think it makes it easier to read if 
the inactive layers are shown without any symbol (eg, remove the 'I's).

Regards,
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: Sam Hartman <[email-masked]>
Date: Thu, 24 Jul 2003 17:37:30 -0400

The SASL mech should never use section 5 with all layers disabled.  If
the SASL mech is used without security layers, the application will
never even pass the data to the SASL implementation.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 24 Jul 2003 20:35:07 -0400

> never even pass the data to the SASL implementation.

I agree, but that's not what is stated in Section 5 paragraph 3:

   "The data always passes through this three-stage filter, though any of
    the stages may be inactive.  Only when a stage is active would the
    output be different from the input.  In other words, if a stage is
    inactive, the octet sequence at the output side is an exact duplicate
    of the same sequence at the input side."

This statement and the summary in Section 5.5 leads me to believe that 
the intention is to encode the data whether a security layer exists or 
not.  I disagree with this (and the needless wrapping of the data 
elements), which is why I proposed my change.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 25 Jul 2003 13:05:52 -0400

>>>>> "Ken" == Ken Murchison <[email-masked]> writes:

    Ken> I agree, but that's not what is stated in Section 5 paragraph
    Ken> 3:

    Ken>    "The data always passes through this three-stage filter,
    Ken> though any of the stages may be inactive.  Only when a stage
    Ken> is active would the output be different from the input.  In

That's true only so long as section 5 is being referenced.  Any other
reading implies that this mechanism spec updates the base SASL spec.

But I agree that the section on SASL should be clarified.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 24 Jul 2003 17:37:30 -0400

---

From: Ken Murchison <[email-masked]>
Date: Thu, 24 Jul 2003 20:35:07 -0400

---

From: Sam Hartman <[email-masked]>
Date: Fri, 25 Jul 2003 13:05:52 -0400