Subject: RE: Planning for DC IETF CAT session

From: "Linn, John" <[email-masked]>
Date: Fri, 31 Oct 1997 14:55:00 -0500

Dennis writes, excerpting: 

> Better
> yet, we could standardize an API for each IETF secure protocol
> thus eliminating most of the current abstraction goo. We could
> also develop boiler plate API specifications, such as a
> standard manner and form for setting and testing parameters,
> buffer management, managing multi-level error information,
> and multi-thread considerations. Work groups could elect to
> develop an API themselves from the API boiler plate
> specifications or, preferably, pass that task to another
> group whose speciality is security APIs--the CAT group, for
> example.
> 
Would this really be a better result?  While per-protocol API
definitions would facilitate per-protocol tailoring, their use would
also make it unlikely for a single API provider to serve multiple
protocol consumers within a system.  Multiple per-protocol API providers
in a system, independently developed, would likely not coexist
gracefully (e.g., to share common credentials).  Also, if providers and
consumers were normally co-developed in closely coordinated pairs, the
motivation to employ independently-specified interface elements to
delimit boundaries between the paired modules might be limited.

--jl

John Linn ([email-masked]), writing as an individual from
RSA Laboratories East, Bedford, MA, USA

---

From: Dennis Glatting <[email-masked]>
Date: Sat, 1 Nov 97 15:58:31 -0800

From: "Linn, John" <[email-masked]>
Date: Fri, 31 Oct 1997 14:55:00 -0500

> definitions would facilitate per-protocol tailoring, their
> use would also make it unlikely for a single API provider to
> serve multiple protocol consumers within a system.  Multiple
> per-protocol API providers in a system, independently
> developed, would likely not coexist gracefully (e.g., to
> share common credentials).  Also, if providers and consumers
> were normally co-developed in closely coordinated pairs, the
> motivation to employ independently-specified interface
> elements to delimit boundaries between the paired modules
> might be limited.
>

I agree multiple protocols would probably not coexist
gracefully but I do not believe shoe-horning all security
protocols into a single abstracted API is the only answer.

An API, if reasonably done, helps to facilitate the acceptance
of a protocol because that's the API's focus and it provides
access to all of the protocol's functions, for better or worse.
The GSS-API, on the other hand, isn't focused on one particular
protocol, rather it abstracts their interface thereby
increasing the learning burden while not providing the
richness of the protocol's functions.

Most users of the GSS-API are not security astute. Thus, after
muddling through a protocol's particulars, they have to
muddle through an abstraction, often having questions not
answered in the document sets, such as "how do I get the GSS-API
to do a krb5_mk_priv()? Of course, that's not the end of it. The
marriage of Kerberos and the GSS-API involves RFC-1510,
RFC-1964, RFC-2078, draft-ietf-cat-gssv2-cbind-04.txt,
and possibly draft-ietf-cat-snego-06.txt. By sheer
combined document thickness the effort of understanding is
daunting (wait... I feel a book coming on :)).

The GSS-API also hurts protocols because it cannot provide the
richness of the protocol itself. For example, what if I wanted
to use the GSS-API for authentication but for some reason had
need to do a krb5_mk_priv()? Or, I wanted to access the context
key material to perform custom transactions? The GSS-API just
gets in the way and to perform those functions I have to break the
abstraction.

Another area where the GSS-API hurts protocols is
implementation dependent, non-protocol functions. For
example, what if I want to instruct the underlying
implementation to use memory based replay caches for a group of
transactions, shared memory for another group, and disk based
for another? It can't be done at the GSS-API layer (well, it
*could* be). To accomplish those functions I must again break
the GSS-API abstraction.

This is not to say I believe the GSS-API does not have a place. It
does. I believe protocols can be better services if protocol
specific APIs were developed and standardized too.

I believe the GSS-API does not accomplish peaceful
coexistence unless all of the pieces are provided by the same
vendor or the user has (and understands) source. If a user
changes vendors or must mix implementations then it is highly
unlikely the user has peaceful coexistence. I offer the
outputs of gss_display_name() and
gss_export_sec_context() as examples.

-dpg

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 6 Nov 1997 15:18:12 -0500

From: Dennis Glatting <[email-masked]>
   Date: Sat,  1 Nov 97 15:58:31 -0800

   The GSS-API also hurts protocols because it cannot provide the
   richness of the protocol itself. For example, what if I wanted
   to use the GSS-API for authentication but for some reason had
   need to do a krb5_mk_priv()? 

Why would application programmers want to do a "krb5_mk_priv"?  That's a
protocol unit; usually application programmers want to do some explicit
function, such as "send this data with integrity protection and
confidentiality services"?

   Or, I wanted to access the context key material to perform custom
   transactions? The GSS-API just gets in the way and to perform those
   functions I have to break the abstraction.

The question I have is why do you need these custom transformations?
Both this and the mk_priv question above suggest to me that you're
thinking about the case where you need to use GSSAPI to implement some
protocol which was not originally specified to use the GSSAPI.  (Hence,
the need for an explicit krb_mk_priv, and use of the explicit DES key).

In such cases, you're absolutely right that GSSAPI is probably not the
right tool.  I don't think that says that then entire concept of the
GSSAPI is bad, though.

						- Ted

---

From: Dennis Glatting <[email-masked]>
Date: Sat, 8 Nov 97 16:53:06 -0800

Date: Thu, 6 Nov 1997 15:18:12 -0500
From: "Theodore Y. Ts'o" <[email-masked]>

> Why would application programmers want to do a
> "krb5_mk_priv"?  That's a protocol unit; usually application
> programmers want to do some explicit function, such as "send
> this data with integrity protection and confidentiality
> services"?
>

There are times when a system needs more than simple functions.
Krb5_mk_priv() is just an example I pulled from the top of my
head. Other examples might be: legacy applications where you
want to use the GSS-API to authenticate (rather than exchange a
plaintext password) then extract the key material from the
context for use in a lower level legacy protocol (protocols
like OSPF, for example); you might want to use the GSS-API as
your base protocol but have need to package KRB_CRED messages
or authenticators (MS-to-local/global authenticator
construction and interrogation may be useful some day :)); or
perhaps the application wants to know the realm. It doesn't
really matter why someone would want to do these kinds of things
what matters is there can be valid technical and business
reasons for doing so and we should support them.

> The question I have is why do you need these custom
> transformations? Both this and the mk_priv question above
> suggest to me that you're thinking about the case where you need
> to use GSSAPI to implement some protocol which was not
> originally specified to use the GSSAPI.  (Hence, the need for an
> explicit krb_mk_priv, and use of the explicit DES key).
>
> In such cases, you're absolutely right that GSSAPI is probably
> not the right tool.  I don't think that says that then entire
> concept of the GSSAPI is bad, though.
>

The GSS-API is a good thing. All I'm saying is by abstracting
away the details of the underlying protocol it's richness is
removed too; and, there is room (plenty of room, IMO) for the
GSS-API and protocol-specific APIs. By offering both we
increase the value and acceptance of protocols.

-dpg