Re: SACRED Protocol (long!)

Hi Dave,

A couple of comments inline.

Best Regards,

Dale Gustafson

Dave Crocker wrote:

> At 11:50 AM 12/7/2001 -0500, Magnus Nystrom wrote:
> >SACRED in the form proposed this week by me is quite self-sufficient
> >and puts very few requirements on the protocol it runs on top of.
>
> Magnus,
>
> This is the core of your error.  You want Sacred to do too much work.

As it's currently defined, the base SACRED protocol is fairly straightforward:

 - Mutually authenticate client and server,
 - dynamically negotiate a strong encryption key (session key) known only to
client and server,
 - client sends in a single request message (encrypted with session key),
 - server returns a single response message (encrypted with session key).

Note that all of this is accomplished by exchange of approx. 6 messages between
client and server when the SRP3 strong password protocol provides the necessary
mutual authentication and key negotiation.  SACRED performs two functions; a)
establish a security context and b) perform a secured request-response sequence.

It appears that BEEP is aimed primarily at simplifying and accelerating the
design and implementation of sophisticated application protocols.  The SACRED
request-response protocol seems to be a relatively poor fit for BEEP's
capabilities (as Marshall has pointed out several times) and, hence, relatively
little advantage is gained by it's use here (e.g. as compared to when
multiplexed data channels, server initiated sessions, etc. are important).

Including multiple session layer protocols (which I think is what Magnus has
recently suggested) seems somewhat suspect if that would create unnecessary
complexity.  However, such extra complexity is still much preferred over any
approach that would "materially" affect our ability to also define and field an
HTTP-based version of the protocol.  Doing that would be off the mark since that
appears to be the majority of the existing market.

A dominant techical factor affecting the SACRED protocol is that it will often
be used with highly constrained client devices.  It may not yet be clear to many
how much that technical factor tends to overwhelm others.  However, looking at
things from that point of view, I think it's easier to see that Magnus'
conclusion that it's preferable to include all functions described above within
the SACRED protocol (e.g., sooner rather than later) is probably unavoidable
and, most importantly, it would be significantly less painful to establish such
a stucture now.

The discussion over the last few days has convinced me that BEEP is likely not a
good fit here and that we should take a closer look at other alternatives such
as SOAP, etc.

> An essential part of making a successful protocol standard is to have it do
> no more than is essential.  That is the entire reason for layering.
>
> Hence, define a protocol that does only the new part that you need
> done.  Then define a functional interface below that protocol, thereby
> specifying all the "infrastructure" services you need from the layer(s)
> below.  The new protocol is the client of that interface.
>
> Then map one or more lower layers -- as providers -- to supply the required
> services.
>
> As a matter of well-engineered convenience, BEEP supplies a very useful
> functional interface to client applications.
>
> So the way to do what YOU want is not to have Sacred do all sorts of
> required, supporting tasks.  It is to create a protocol that uses the beep
> interface.
>
> That, of course, means it will run over beep.
>
> If you wish to make your new application run over OTHER infrastructure
> services, you merely need to assemble those services into a package that
> satisfies the beep services.
>
> d/
>
> ps.  If you can specify Sacred requirements for an infrastructure package
> of services that is different from beep, please do so and then get support
> for it.
>
> ----------
> Dave Crocker  <mailto:[email protected]>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.273.6464