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

From: Internet-Drafts at ietf.org ([email-masked])
Date: Mon, 18 Jun 2007 15:50:02 -0400

ENCODING mime
FILE /internet-drafts/draft-ietf-btns-c-api-00.txt
-------------- next part --------------

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Mon, 18 Jun 2007 13:47:03 -0700

This draft makes many assumptions about the execution environment.
Far too many, in my opinion, for anything beyond an informational RFC.

In particular the requirements that the objects be "opaque" and
non-copyable are problematic in embedded and/or virtualized
environments.
Not allowing the client to copy the object to another location in the
same process, or to an entirely different process is quite reasonable.
But can the process itself be migrated? Are these objects expected
to work after a Unix style fork? What if the entire IP host is
migrated to another physical machine?

These types of issues are exactly the sort of implementation details
that are best not dealt with by the IETF, but the plain reading of
the draft could seem to apply to all of them.

I see no problem with requiring that the API MUST NOT require
the application to directly manipulate the object. You could
mention that applications SHOULD NOT manipulate the object
by other means, but that belongs in to "application SHOULD
NOT zero-out random portions of physical memory" category.

What needs to be stated is what expectations there are about
this memory. Are normal operations on the entire memory space,
such as swap-out/swap-in and virtualization migration, compatible
with these objects or not?

My hunch is that from a security perspective, the host is the host
and it really does not matter to the remote peer how opaque and/or
protected any specific data object is. These concepts merely promote
robust and readable code. Writing robust wonderful code is of course
to be encouraged, but I don't think we can make it a MUST.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 18 Jun 2007 16:03:13 -0500

> Far too many, in my opinion, for anything beyond an informational RFC.

Such as?

> non-copyable are problematic in embedded and/or virtualized

As long as interfaces are provided for copying opaque objects that may
need to be copied that should suffice to address the concern.

> migrated to another physical machine?

Some RFCs that define APIs never described fork- or thread-safety.  For
any interface like this one, however, I think that fork- and thread-
safety must be addressed, even if to say that it is undefined.

> the draft could seem to apply to all of them.

I think discussions about the propriety of the IETF doing API work are
outside the scope of this WG.

> NOT zero-out random portions of physical memory" category.

Opaqueness, IMO, can (and in this case should) cover the "size" of the
object in memory -- the application need not know; as fas as it's
concerned the object has a pointer- or integer-sized handle and that's
that.

> with these objects or not?

I think swapping and paging are out of scope here.  How many APIs do you
know of that are not swap-safe?!

Migration should be like suspend/resume: a socket may become
disconnected, a connection latch may be broken, etc...

> to be encouraged, but I don't think we can make it a MUST.

I agree with the first sentence; most API details are local details, not
protocol details.  I disagree with the rest.

Nico
--

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Mon, 18 Jun 2007 14:36:53 -0700

Nicolas Williams wrote:
> 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.

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

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?

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.

I assume there is no intent to actually mandate how Hypervisors and/or
embedded deployments will operate. But writing things as though the
entire world were Unix and making it a standard has the effect of
imposing arbitrary requirements in other environments.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 18 Jun 2007 16:57:51 -0500

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

> SHOULD NOT/MUST NOT be copied to an unsecure location (such as

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.

> by encryption hardware and/or supporting daemons?

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

> be migration friendly or the library has to flag the memory as not

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.

> embedded deployments will operate. But writing things as though the

Correct.

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