Subject: Re: SACRED Protocol (long!)

From: Magnus Nystrom <[email-masked]>
Date: Thu, 6 Dec 2001 19:33:55 -0500 (Eastern Standard Time)

Marshall,

Thanks for your comments.

On Thu, 6 Dec 2001, Marshall T. Rose wrote:

> > -allow SACRED protocol exchanges to run on top of any reliable
> >  transport, including SOAP, http, BEEP, and other protocols,
> > -allow easy integration of other SASL mechanisms than SRP into the
> >  protocol, and
> > -allow the use of other security context establishment techniques
> >  than those provided by SASL.
>
> err, the dependence on beep is a good thing simply because it allows you to
> avoid having to deal with the 101 administrative issues that arise
> otherwise.

Actually Marshall, I think it is a good thing to run SACRED on top of
BEEP. However, I also do believe that it should be possible to run
SACRED on top of other protocols as well, including protocols that
does not have BEEP's support for SASL. By integrating SACRED's
security mechanism into SACRED itself we claim to achieve this.

> if you want to have something that runs on lots of different things, then
> can i suggest that you remove the beep support simply because you have very
> effectively negated 90% of the advantages of using beep...

BR,
-- Magnus

---

From: "Marshall T. Rose" <[email-masked]>
Date: Thu, 6 Dec 2001 16:59:41 -0800

> security mechanism into SACRED itself we claim to achieve this.

everything has a cost. by mandating

> > >  transport, including SOAP, http, BEEP, and other protocols,

you have increased the cost of entry for developers (which mappings do i do
first) along with the switching cost for consumers (can't switch to vendor
Y's product, because it doesn't support the mapping used by vendor X's
product).

very often having too many choices is far worse than having once choice.

/mtr

ps: of course, this all assumes that the wg can agree on N mappings in
finite time, that the iesg goes along with it, etc., etc. in other words,
the scope of effort just got a whole lot bigger...

---

From: Magnus Nystrom <[email-masked]>
Date: Fri, 7 Dec 2001 10:05:48 -0500 (Eastern Standard Time)

Marshall,

I agree with you that there certainly is a need to do mappings to
underlying transports. But we claim that with our proposal, this won't
be any more difficult than, e.g., the mapping of OCSP messages to http
(which is described in an Appendix to RFC 2560, less than one page
long) or XKMS messages to OCSP (which also is described in a simple
Appendix).

With the current draft, it was not clear how to do this, and hence if
someone would have liked to implement SACRED on top of http, they
would more or less had been forced to start all over again (since the
current proposal relied on BEEP's support of SASL, and http does not
have this support (yet)).

My suggestion is to define a mapping to SOAP. Since SOAP already maps
to BEEP (as I understand it) and also has a http binding this would
seem to take care of our immediate requirements.

BR,
-- Magnus

> the scope of effort just got a whole lot bigger...

-- Magnus
Magnus Nystrom
RSA Security

---

From: "Marshall T. Rose" <[email-masked]>
Date: Fri, 7 Dec 2001 08:33:45 -0800

> have this support (yet)).

i think the problem is the "if someone wanted to implement sacred on http"
part...

the reason that people use beep is because it allows them to focus on the
90% of the problem that's "interesting" rather than the 10% of the problem
that's administrative. otherwise, 90% of the effort gets spent dealing with
the administrative part.

if you can get a tight match between http's service and your application's
requirements, then you should use http. the problem comes up when the match
isn't tight enough.

in this particular case, the ietf/iesg is pretty clear that application
protocols be thoughtful with respect to security issues, and that the use of
sasl is a good first step.

> seem to take care of our immediate requirements.

the problem, of course, is what happens if you don't run soap over beep. in
that case, you're back to square one, because the iesg will require that you
flesh out all the security stuff you'll need to implement sacred in that
environment.

if it positively, absolutely is a requirement that sacred run directly over
http, then time would be far better spent dealing with the security issues
of that mapping. you won't need beep, because it's not saving you any time.
instead, you get to spend 90% of your time working on the administrative
overhead instead of focusing on the problem domain. enjoy!

/mtr

---

From: Magnus Nystrom <[email-masked]>
Date: Fri, 7 Dec 2001 11:50:19 -0500 (Eastern Standard Time)

Marshall,

I certainly agree with you that we need to be thoughtful on security
issues - and that's why we are specifying the use of a security
framework (SASL, so far) and strong mechanisms within that framework
(SRP, so far). There are no differencies between us there, AFAICT.

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.
Compare once again with OCSP. The authors of OCSP wanted it to be
possible to run OCSP over a variety of protocols, including http,
smtp, and ldap. By making sure that OCSP could protect its own
exchanges and minimizing the requirements on underlying protocols they
achieved this. There are other examples of this, as I mentioned in my
previous posting.

The fact is, BEEP is not universally implemented. We should allow for
other bindings too, and make the work to do those mappings as simple
as possible.

-- Magnus

-- Magnus
Magnus Nystrom
RSA Security

---

From: "Marshall T. Rose" <[email-masked]>
Date: Fri, 7 Dec 2001 13:13:56 -0800

> achieved this. There are other examples of this, as I mentioned in my

we just aren't communicating here...

the basic problem is this: if you write a protocol that both:

- maps onto multiple underlying protocols, and
- protects its own exchanges

then you are reinventing the wheel, spending more
design/implementation/review time on administrative overhead and less on the
application domain that you're trying to deal with.

in other words, you've managed to maximize the pain and focus all the
engineering energy on the non-essential parts of the system. probably not a
good trade-off.

> other bindings too, and make the work to do those mappings as simple

it's true that beep isn't universally implemented.

it's also true that do the other bindings, you'll have to complicate sacred
in order to make up for the fact that all these other mappings are on top of
transports that don't adequately deal with security, asynchrony, etc., etc.

and all for the benefit of fragmenting the marketplace, reducing the amount
of interoperability between implementations, promoting vendor lock-in, etc,
etc.

just because you can do it this way, doesn't mean you should.

/mtr

---

From: Magnus Nystrom <[email-masked]>
Date: Fri, 7 Dec 2001 18:08:16 -0500 (Eastern Standard Time)

Hi again Marshall,

What I am trying to say is that our proposal already re-uses the
SASL framework and integrates SASL into SACRED for a very small cost,
namely two extra messages. Not too complicated.

Sure, a mapping is needed. But the way the mapping is done in the
current draft is making it really hard to define SACRED for other
protocols that do not support SASL. One would even have to define
new SACRED PDUs for some mappings, thereby changing the protocol
itself. And, since there are other constituencies that are aiming to
make use of SACRED, e.g. the W3C XKMS WG, whose charter explicitly
states that one of the objectives is harmonization with SACRED, and
who are using other transports (in the case of XKMS SOAP), a tight
binding to BEEP could be counterproductive. My suggestion is therefore
to map to SOAP (and SOAP in turn has mappings to BEEP (soon, at least)
and http).

Speaking of charters, SACRED's own charter states: "Credentials must
be available to many different types of clients with different
characteristics in terms of processing power, storage and network
connectivity." Binding SACRED tightly to BEEP, and therfore requiring
constrained devices to implement BEEP when they already have to
implement SOAP and/or HTTP, does not, IMHO, really match well with
this statement.

Finally, my understanding of BEEP is that it is a protocol framework,
and as such suitable as a basis for a wide range of application
protocols having certain characteristics. As far as I understood from
your "On the design of application protocols" RFC, one of those
characteristics was asynchronous messaging, and BEEP therefore handles
asynchronous message exchanges. Since SACRED, has a clean
request-response, synchronous situation that does not appear to need
BEEP's support of these exchanges, and we, as our current proposal
aims to demonstrate, also are able to handle the security context
establishment ourselves in a simple manner, I feel that this tight
binding to BEEP is not optimal.

-- Magnus

---

From: "Marshall T. Rose" <[email-masked]>
Date: Sat, 8 Dec 2001 15:05:55 -0800

hi. i'm just getting more and more confused. perhaps a diagram or two would
help.

are you suggesting that sacred be a:

    - application protocol
    - a sasl mechanism
    - an exchange over soap
    - or ...

if the argument is that sacred has to integrate with multiple application
protocols, then it should be defined as a sasl mechanism.

if the argument is that sacred should be a seperate application protocol,
then we're back to the issue of pain amplification or minimization, and
everyone already knows which of those i favor.

if the argument is that sacred should be defined as a soap exchange, then
the question is what context does the exchange occur in, and who's going to
write down the one-hundred-and-one security issues that the iesg will want
answered with respect to things that layer over soap and http and ...

regardless, i don't understand about the requirement to accomodate protocols
that don't do sasl, since, afaik, any "modern" application protocol
developed in the ietf does sasl...

if it looks like i'm being difficult here, i guess i'm more confused than
anything else...

/mtr

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2001 09:23:39 -0800

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

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-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Dale Gustafson <[email-masked]>
Date: Mon, 10 Dec 2001 09:01:23 -0600

Hi Dave,

A couple of comments inline.

Best Regards,

Dale Gustafson

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Dec 2001 13:46:19 -0700

Dale,

>  - Mutually authenticate client and server,

A function that SASL already performs

>  - dynamically negotiate a strong encryption key (session key) known only to

A function that SASL already performs

>  - server returns a single response message (encrypted with session key).

Functions that require some infrastructure, above TCP and below the SACRED 
semantics.

No matter how few or simple the interactions.

>design and implementation of sophisticated application protocols.

Primarily?  Sophisticated?  No and No.

All applications need framing and error codes and basic mechanisms for 
exchanging things.  BEEP standardizes these.  If you do not use BEEP, you 
must (re-)invent some other method of performing them.

Negotiating options, such as SASL, is typically required.  Again if you do 
not use BEEP, you must re-invent them.  However if an application does not 
need negotiation, the cost of it is not incurred.  For SACRED, it appears 
that SASL can solve some standard requirements in a standardized way.  Why 
anyone would want to re-invent mechanisms that are a) already working well, 
and b) difficult to design and deploy successfully, is a matter of some 
curiosity and should be a matter of very great concern.

The multiplexing mechanism of BEEP is a different matter from the 
others.  It is somewhat innovative (or at least unusual), not simple enough 
to call trivial, and does not yet have large amounts of operational 
experience.  So it is nicely convenient that if you do not need its 
benefits, you do not incur its costs.  On the other hand, if you DO need 
those facilities, you should be eager to avoid re-inventing them, since 
they are known to carry significant risk.

The bottom line, therefore, is that the BEEP method of performing 
particular functions adds essentially no overhead to a protocol that needs 
those functions.  And for protocols that do not need particular BEEP 
sub-functions, BEEP adds no overhead at all.

The only question, therefore, is where the pieces come from.  They can come 
from a standardized place, like BEEP, or they can be 
re-invented.  (Re-)inventing mechanisms -- even very small bits of 
mechanism -- carries far more cost and risk than is generally 
appreciated.  What is small and simple and easy for an individual developer 
is different for an Internet-scale effort.  Internet efforts are always 
large, expensive and risky.  (For those so inclined, think of it as the 
difference in cost between engineering a product vs. total life-cycle cost 
for the product, and in risk between building something simple vs. ensuring 
that the business selling it is successful.)

The premise behind BEEP is that using BEEP saves the community considerable 
effort/cost and reduces risk.  Again, let me caution that we distinguish 
between an individual's perspective on effort and risk, versus the 
community view.  Most people do an analysis in personal terms, rather than 
knowing or thinking about community-level issues.

>   The SACRED request-response protocol seems to be a relatively poor fit 
> for BEEP's
>capabilities

On the contrary, it seems like an excellent fit, as noted above.

>how much that technical factor tends to overwhelm others.

Perspective on "highly constrained" changes over the years.  From an 
historical perspective, the idea that anything that is considered highly 
constrained would use HTTP is, in fact, downright amusing.

Less frivolously, I challenge the claim that BEEP somehow introduces 
significant overhead, beyond that inherent in the functions it 
performs.  That is, for the substructure functions that SACRED needs to 
perform, I challenge that they can be performed with massively less 
overhead than BEEP incurs.

The one point of debate might be default data encoding, since MIME and XML 
are not maximally efficient.  This issue is a matter of long-standing 
debate in the applications protocol community, and has generally 
demonstrated preference and success for text encoding.

>  I think it's easier to see that Magnus'

It always seems better to create a fully self-contained facility.  For 
Internet design, the history is that it is not only NOT better, but in fact 
it is just plain wrong.

At 11:37 AM 12/10/2001 -0500, Linn, John wrote:
>  Relative to most applications, SACRED is quite
>a special case.

Every application is special.

What are the specific technical or operational aspects of SACRED that make 
it unique?  I am hoping that there is more than you cited in your note.

>As far as transport integration is concerned, is there any existing practice
>in evaluating how effectively and comprehensively non-BEEP transports can be
>applied to implement the BEEP interface?  As applications go, I think
>SACRED's transport requirements will be fairly simple (e.g., purely
>synchronous exchanges)

OK.  That means you do not need BEEP's asynchrony.  So, don't use it.

>, but other applications where SACRED might be
>incorporated as an element will probably establish their transport choices
>against their own priorities and constraints.

There is a fascinating effect caused by creating a separate 
"layer":  People often tend to think that because it is separate it is 
extra or different, whereas tight integration automatically makes things 
cleaner, simpler, and/or more efficient.

That thinking is quite simply wrong.

Somethat that I create is more familiar to me than something I get from 
elsewhere.  However the fact of familiarity does not have any relationship 
to quality, ease or cost, no matter how wonderful I might think my own 
creation.

d/

----------

d/

----------

---

From: Magnus Nystrom <[email-masked]>
Date: Mon, 10 Dec 2001 17:34:03 -0700 (Mountain Standard Time)

Hi again Marshall.

You are not being difficult at all (perhaps I am the one being
difficult...;). On the contrary, thanks for continuing the discussion.
Please find my responses below.

> protocols, then it should be defined as a sasl mechanism.

SACRED is not a sasl mechanism. It currently makes use of SASL to
establish a security context, but could also make use of other
security context establishing frameworks.

> everyone already knows which of those i favor.

This is the core of the discussion yes, and I will try to summarize
in a subsequent posting.

> answered with respect to things that layer over soap and http and ...

Honestly, I don't think that work will be too onerous. C.f. with other
security-related protocols that runs over http.

> developed in the ietf does sasl...

As I mentioned in an earlier posting, the concern we had about the
current draft stemmed from two facts:

-it binds SACRED tightly to BEEP; and
-there are widely implemented protocols that do not support SASL (or
 other security frameworks), and platforms that SACRED is expected to
 serve support these protocols and not BEEP.

We therefore felt that making SACRED payloads security-aware would
alleviate these concerns. And yes, at least one mapping to some
existing transport is needed, and given the latter factor above I
suggest that the initial mapping shall be to SOAP.

BR,
-- Magnus

-- Magnus
Magnus Nystrom
RSA Security

---

From: Dale Gustafson <[email-masked]>
Date: Tue, 11 Dec 2001 10:44:34 -0600

Hi Dave,

To summarize -- you've clarified that BEEP gives us a standard way to define:

 - message types (upload, download, change password, ... message responses)
 - message framing
 - common error codes
 - etc.

BEEP also has many additional features that we don't need.  As you say, if we don't
need them, that's not problem -- just don't use them.

We're convinced there will be many constrained devices (many different suppliers,
high volume products) that will not have storage space available to add support for
much of anything.  I believe we're not as concerned about bits on the wire and cpu
overhead as long as usage is in line with what any similar protocol would use.  The
rub occurs whenever {SACRED + BEEP + SASL +...} won't fit.

Until now, BEEP is the only option that's had much list discussion.  I agree with
Magnus and others that http/SOAP should also be considered assuming it's sure to be
present in many client devices.  In fact, "ryo" should be possible if/when we
encounter a situation where a bare-bones approach is truly required.

Additional comments inline.

Best Regards,

--dg

> must (re-)invent some other method of performing them.

Yes, every application that doesn't use BEEP must do something like that.

> curiosity and should be a matter of very great concern.

Agree, althought it's not as clear that SASL needs to be tightly coupled with BEEP.

Also, many SASL mechanisms won't work for SACRED.  Ideally, we need a proper subset
of SASL.

> > The SACRED request-response protocol seems to be a relatively poor fit for
> BEEP's

> >be used with highly constrained client devices.  It may not yet be clear
> >to many how much that technical factor tends to overwhelm others.
>

Highly constrained means a ROM or EE-PROM based appliance such as a cell phone or
similar device.  Typically, room for new functionality must be found by replacing
and/or compressing existing functions (which can often be very hard work).  Pent up
demand for additional application functionality complicates things ...

The reason that http may well emerge as the top candidate is solely by virtue of
the fact it's already a "must support" capability in most applicable client devices
since they depend on http to provide much of their internet functionality.  We
will, no doubt, need the flexibility that allows us to take a free ride on well
known capabilities whenever necessary.

> overhead than BEEP incurs.

Don't think that BEEP introduces any unusual processing or protocol overhead.  In
any event, reasonable additional overhead is probably not a big issue.

However, using an extra 2 or 4 K of a client device's storage space might be a
non-trivial problem (seems strange, I know).

> >a structure now.

> Internet design, the history is that it is not only NOT better, but in fact

We're after the most flexible standardization structure that fits a very wide range
of needs.

< snip  >

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Dec 2001 10:18:32 -0700

>Agree, althought it's not as clear that SASL needs to be tightly coupled 

Indeed.  SASL was developed independently.  The point was (and is) that 
choosing BEEP solves a set of issues.  So you do ONE adoption/integration, 
rather than a series.  SASL comes WITH beep.  Skip beep and you need to 
integrate SASL separately, along with doing your own framing, error codes, 
etc., etc.

>Also, many SASL mechanisms won't work for SACRED.  Ideally, we need a 

SASL is a negotiation mechanism.  I would venture to say that no protocol 
that uses it requires (or even expects) participants to support ALL of the 
mechanisms it defines.  In other words, all you have done is to highlight 
the benefit of SASL, rather than a problem (or extra work).

>Highly constrained means

yes, of course.  I understand.  my point was missed, so I'll just say it 
directly:  From a practical standpoing, BEEP does not introduce overhead 
that you won't incur without beep.

>... We

Like BEEP.  Yes.  Excellent perspective.

>non-trivial problem (seems strange, I know).

For functionality in the modern Internet, that level of optimization will 
typically require using totally non-standard mechanisms.

>We're after the most flexible standardization structure that fits a very 

Hmmm.  That suggests two very different responses:

1.  Excellent.  That's another good reason for using BEEP, or

2.  You probably want to do your work outside the IETF, such as perhaps ISO...

d/

----------