Subject: Revisiting the SAP (with security) format

From: Ross Finlayson <[email-masked]>
Date: Thu, 21 May 1998 00:26:13

I've recently been reviewing the SAP Security..." draft, motivated by
thinking about how it might be used in the future as the basis of a more
general multicast data architecture.  (For instance, it'd be nice to
eventually be able to support more general multicast data caches/proxies,
rather than ones that understand only SAP.)

In summary, the proposed SAP security mechanisms seem pretty good, but I
have some comments about parts of the spec that remain unclear.  I also
think that the most recently proposed packet format for SAP+security is
rather ugly, largely due to an (unnecessary) goal of retaining
compatibility with the existing SAP format.  In this light, I believe we
should reexamine this packet format, to see if we can clean it up somewhat,
and make it a bit more general.

1/ Unclear parts of the specification
=====================================

- What does the AH cover?
The SAP Security spec doesn't make clear exactly which parts of the packet
are covered by the digital signature in the Authentication Header (AH).  It
should, I presume, cover the entire packet (except for the digital
signature itself, of course).  But this needs to be clearly stated.  Note,
BTW, that the original "sap-01" draft implies that the data that precedes
the AH is *not* covered by the signature.  If true, then this seems totally
wrong, because (for example) it would allow someone to turn a 'create'
message into a 'delete'.

- The "Signature Length" field in the AH
The spec doesn't say what the units of this length are.  I presume it's
"bytes", because no padding bit defined for just the signature part of the
AH.  (If so, then is 2048 bits (==(2^8)*8) enough for the signature?)

I'm also not thrilled by the fact that this field is defined to be present
for all authentication schemes, yet is useful with only one authentication
scheme (PGP+certificate).  It would be better to define this field as being
part of the "Format Specific Authentication Subheader" for the
"PGP+certificate" scheme only.  (That way, these 8 bits would not be wasted
with other authentication schemes.)

- How to distinguish between symmetric and assymmetric privacy headers?
The explanation, in section 3.3.1, of how a receiver is supposed to figure
out which kind of privacy header is being used, is very unclear, IMHO.
[BTW, I'm pretty much agnostic as to whether part of the privacy header
should be standardized to make this easier (as Bill Lewis & Peter Kirstein
suggested last month.)  I'd be happy just to see a clearer explanation in
the spec.]

2/ Cleaning up the "SAP+security" packet format
====================================================

I have no complaint with the proposed security mechanisms (& their
associated packet formats).  However, the overall layout of the
"SAP+security" packet seems rather inelegant, apparently due to a desire to
reuse the previous SAP (v1) packet format.  This, however, seems
unnecessary, because the "SAP+security" spec already assumes that a new
protocol version (2) will be used.

So, as long as we retain the "SAP version number" field (in the same
position), we should feel free to consider improvements to the packet
format.  Any minor implementation inconvenience for receivers that wish to
understand both SAPv1 and SAPv2 is outweighed, IMHO, by the benefits of
having a cleaner, more general SAPv2 format for the future.  (Also, to my
knowledge, few, if any, people outside University College London have yet
implemented the recently proposed format.)

There are two main things that I dislike about the current SAP+security
proposal:

- Too many optional fields/subheaders.
In protocol design, optional fields should be avoided as much as possible.
The Authentication Header should instead be made a *manditory* part of the
packet.  (In the future, the use of digital signatures is likely to be
commonplace, if not ubiquitous.)  To support unauthenticated data (as in
the current SAP), we could define a special Authentication Type code to
mean "unauthenticated".  (This could be Authentication Code zero - which is
currently unused.)

The "Timeout" field should also be manditory.  This not only makes it
possible to use the same packet format for other kinds of data than SDP,
but also simplifies the implementation of SDP-only caches: They will be
able look in only one place for 'timeout' information, rather than having
to look in one place (the binary "Timeout" field) for encrypted
announcements, and in another place (an ASCII field inside the SDP data,
possibly after gzip decompression) for unencrypted announcements.

The cost of making the "Timeout" field manditory - an extra 4 bytes in the
case where the payload is unencrypted SDP data - is worth paying for this
simplicity, I believe.

On the other hand, I'd be willing to keep the privacy header optional.
However, if we end up deciding to adopt a standardized privacy header, then
even this could be made manditory.  (We might, for example, rename this as
something like the "Data Transformation Specifier", in which case it could
include the gzip compression ("C) bit, as well as indicating when data is
unencrypted - i.e., the null transformation.)

- The "message id hash" and "originating source" fields are an
implementation-specific hack.
These two fields are intended to be combined and used by receivers
(caches/proxies or endpoints) - after verifying the Authentication Header -
as a 'key' for quickly detecting whether the announcement is identical to
one that has already been received.  That is, these fields are intended to
provide support for a particular performance optimization by receivers.

In many case, however, receivers might wish to perform the identity test in
a completely different way.  In particular, for authenticated
announcements, they may instead wish to use the message digest (which has
already been computed as part of the authentication check) for the identity
check.

For this reason, I propose removing these two fields from the fixed header.
 Instead, they could be defined as part of the "Format Specific
Authentication Subheader" for the "unauthenticated" Authentication Type
only.  (So, receivers could continue to use this information for the
identity check of unauthenticated announcements, where there's no message
digest for receivers to use.)

Note, BTW, that the "originating source" also has the problem of being
IPv4-specific.  It's also the only IP protocol-related data in the header.
By removing it - at least in the case of authenticated announcements - we
can make SAP packets independent of IP.

Finally, here is a possible outline of a redesigned "SAP+security" packet
format:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=2 |P|AuthTyp| Auth Hdr Lngth|    Authentication Header      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Authentication Header (continued)                |
|                       ..............                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Timeout                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MT (6 bits)|E|C|         Privacy Header (optional)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Privacy Header (continued)                    |
|                       ..............                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Payload                              |
|                       ..............                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that allocating more bits (than the current 3) to the "Message Type"
(MT) field gives us more flexibility if we wish to use this packet format
for data other than SAP in the future.

	Ross.