[anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt

[Nicolas.Williams at sun.com (Nicolas Williams)]

On Mon, Jun 18, 2007 at 02:36:53PM -0700, Caitlin Bestler wrote:
> Nicolas Williams wrote:
> > On Mon, Jun 18, 2007 at 01:47:03PM -0700, Caitlin Bestler wrote:
> >> This draft makes many assumptions about the execution environment.
> >> Far too many, in my opinion, for anything beyond an informational
> >> RFC. 
> > 
> > Such as?
> > 
> >> In particular the requirements that the objects be "opaque" and
> >> non-copyable are problematic in embedded and/or virtualized
> >> environments.
> > 
> > As long as interfaces are provided for copying opaque objects
> > that may need to be copied that should suffice to address the concern.
> 
> A virtual machine or an application is opaque to the entity that
> migrates it. There is no way to know that certain bytes require
> special copying procedures.

So?  The special copying instructions are not relevant to the VM.

The VM *bulk copies everything* and that OK for all "user-land" state.

Kernel-land state is another story, and here I think the API MUST
provide for signalling of lost resources (lost because of migration,
suspend/resume, whatever).  Kernels, of course, need to know how to
support running in specific VM environments, how to suspend/resume.

[Yes, I'm ignoring things like TLI/XTI that had quite a lot of state in
user-land that BSD sockets semantics required be kept in kernel-land.
But that's OK: define the semantics, make sure that there's a way to
signal lost resources, and that there's nothing impossible to implement
and by and large that should be OK.  Also, TLI/XTI is a thing of the
past, and at least one implementor has coped well, in the end, with this
impedance mismatch between TLI/XTI and BSD sockets.]

> It is also common for security libraries to have content that
> SHOULD NOT/MUST NOT be copied to an unsecure location (such as
> the swap disk).

Implementation detail.

Look at the GSS-API for an example of API design that by and large gets
all of this right.  It has the following opaque objects:

 - SECURITY CONTEXT
 - CREDENTIAL HANDLE
 - NAME

For SECURITY CONTEXT it provides functions to export/import contexts
such that exported SECURITY CONTEXT tokens are valid only on the same
host and not across reboots.  The GSS-API pre-dated VM migration, and
some implementations may have to invalidate exported SECURITY CONTEXT
tokens across VM migration, but that is an implementation detail.

There are no functions for serializing CREDENTIAL HANDLE objects --
that's because the underlying credentials and details about how to copy
them are outside the scope of the GSS-API (besides, how does one "copy"
or smartcards in software on the host without cooperation of the user?).

NAME objects, like SECURITY CONTEXT, can be exported.  Exported NAME
tokens can be imported, both on the same host, on other hosts, and
across reboots.

GSS-API implementations might have hypervisor issues to take into
account.  For example, _session_ keys associated with a SECURITY CONTEXT
might be stored in a cryptographic hardware co-processor or token
accessed through a hypervisor, in which case the implementation will
have to find a way to migrate such state during VM migrations (but in
general session keys are never stored in tokens such that their values
cannot be extracted nor that they have not existed outside the token, so
this is a rather contrived example).

Sure, the GSS-API did not specify fork- nor thread-safety details, but
we can and will add those in a future version of the GSS-API.

BTNS' APIs should follow the GSS-API model in this regard, with the
addition of specifying fork- and thread-safety now, rather than later,
plus a facility for signalling (not necessarily in the sense of Unix
signals, mind you) resource loss.

> Basically the rationale for opaqueness and special migration routines
> needs to be clear in order to provide guidance for a wider set of
> execution environments. Are the objects opague because that's good
> programming practice, or because they might need to be accessible 
> by encryption hardware and/or supporting daemons?

No, the rationale for opaqueness and export/import functions is to hide
detail from the application.

> As an informational RFC it would be sufficient to state the assumptions,
> if you want to be a standard then the specification of the API needs
> to avoid making such assumptions unless it can justify them. I am
> quite confident that Hypervisors will NOT add special migration hooks
> for BTNS objects, so either the definition of these objects has to
> be migration friendly or the library has to flag the memory as not
> being migratable.

There is no expectation that hypervisors would have to deal with
anything in BTNS.  I'm not sure why you'd think that anything in this
API could possibly depend on hypervisor knowledge of it.

> I assume there is no intent to actually mandate how Hypervisors and/or
> embedded deployments will operate. But writing things as though the

Correct.

> entire world were Unix and making it a standard has the effect of
> imposing arbitrary requirements in other environments.

I think it's appropriate to design APIs at the IETF that are based on,
say, "BSD sockets," even if "BSD sockets" are traditionally associated
with Unix and Unix-like operating systems.

That said, I believe it to be very important that an abstract API be
provided without any programming language or operating system/platform
bindings in the same specification (except as examples of how one might
design such bindings).  I think that's even more important than
providing any such bindings.

Nico
--