From touch at ISI.EDU Fri Jun 1 06:16:07 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 01 Jun 2007 06:16:07 -0700 Subject: [anonsec] mailing list problems In-Reply-To: <20070531174153.GT27420@Sun.COM> References: <20070531174153.GT27420@Sun.COM> Message-ID: <46601C17.1020903@isi.edu> Hi, all, Nicolas Williams wrote: > Joe, > > Please make your filters smart enough to allow postings by subscribers > or by senders who've posted before or remove the filters altogether. While the idea that "if you posted before, all future posts are OK" seems useful on the surface, there are two problems: 1) that's not a setting in Mailman (of which I am aware; if anyone knows otherwise, please let me know off-list) 2) that won't stop the spam (we already get) spoofed with source addresses of regular posters, as well as other subscribed addresses > If you don't then I will ask the chair to create a btns at ietf.org list > and move the WG discussion to it. (The chair may refuse to do that, of > course.) That's your perogative (and the chair's). I provide the service I can, with the resources available. I don't have the resources to rewrite Mailman every time a transient like this comes up, nor would I expect the IETF system to either. In general, we receive very little spam, and trip up the system on cases like this rarely. If you believe that there is a potential problem, it might be useful to start by changing the subject line, since most of our filters weigh the subject line heavily. Joe (as list admin) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/anonsec/attachments/20070601/7a8b5fb0/signature.bin From julien.IETF at laposte.net Fri Jun 1 07:35:38 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Fri, 1 Jun 2007 16:35:38 +0200 Subject: [anonsec] WG adoption of draft-komu-btns-api-01 In-Reply-To: <18558.1178935860@marajade.sandelman.ca> References: <18558.1178935860@marajade.sandelman.ca> Message-ID: <200706011635.38550.julien.IETF@laposte.net> [re-issuing question w/ different subject line since it seems the previous one got us caught in a spam filter rule] Folks, Miika has worked on C-bindings for the abstract API (draft-komu-btns-api-01). Hereby I'd like to call for WG adoption of this document. If you agree, or disagree with adoption, please send an email saying so to the mailing list without changing the subject line before 2007-06-15. (OTOH please do change the subject line if you want to discuss contents of the documents themselves.) (If you have no time to read the documents, you might take a look at their respective presentations given during last meeting.) -- julien / BTNS co-chair From julien.IETF at laposte.net Fri Jun 1 07:35:40 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Fri, 1 Jun 2007 16:35:40 +0200 Subject: [anonsec] WG adoption draft-richardson-btns-abstract-api-00 In-Reply-To: <18558.1178935860@marajade.sandelman.ca> References: <18558.1178935860@marajade.sandelman.ca> Message-ID: <200706011635.41281.julien.IETF@laposte.net> [re-issuing question w/ different subject line since it seems the previous one got us caught in a spam filter rule] Folks, Michael has worked on a revised abstract API, available at: Hereby I'd like to call for WG adoption of this document. If you agree, or disagree with adoption, please send an email saying so to the mailing list without changing the subject line before 2007-06-15. (OTOH please do change the subject line if you want to discuss contents of the documents themselves.) (If you have no time to read the documents, you might take a look at their respective presentations given during last meeting.) -- julien / BTNS co-chair From julien.IETF at laposte.net Fri Jun 1 08:12:34 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Fri, 1 Jun 2007 17:12:34 +0200 Subject: [anonsec] Note on draft adoption questions In-Reply-To: <18558.1178935860@marajade.sandelman.ca> References: <18558.1178935860@marajade.sandelman.ca> Message-ID: <200706011712.35031.julien.IETF@laposte.net> Folks, since we had issues with the first question issued that were caught into a spam filter, as well as answer to them, I'd like to ask those of you who replied to the question already to double check if their answer made it to the list. In case it didn't, please reply again, but to the second questions (with no "call" in subject line) Sorry for the annoyance. -- julien / BTNS co-chair From Nicolas.Williams at sun.com Fri Jun 1 08:42:32 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 1 Jun 2007 10:42:32 -0500 Subject: [anonsec] mailing list problems In-Reply-To: <46601C17.1020903@isi.edu> References: <20070531174153.GT27420@Sun.COM> <46601C17.1020903@isi.edu> Message-ID: <20070601154232.GB1551@Sun.COM> On Fri, Jun 01, 2007 at 06:16:07AM -0700, Joe Touch wrote: > > Please make your filters smart enough to allow postings by subscribers > > or by senders who've posted before or remove the filters altogether. > > While the idea that "if you posted before, all future posts are OK" > seems useful on the surface, there are two problems: > > 1) that's not a setting in Mailman (of which I am aware; > if anyone knows otherwise, please let me know off-list) > > 2) that won't stop the spam (we already get) spoofed with > source addresses of regular posters, as well as other > subscribed addresses So let's make it the IETF's problem. They have a tools team. > > If you don't then I will ask the chair to create a btns at ietf.org list > > and move the WG discussion to it. (The chair may refuse to do that, of > > course.) > > That's your perogative (and the chair's). I provide the service I can, > with the resources available. I don't have the resources to rewrite > Mailman every time a transient like this comes up, nor would I expect > the IETF system to either. > > In general, we receive very little spam, and trip up the system on cases > like this rarely. I've been annoyed more than once by these filters. From what you say any subject line with "call for" causes this. Well. In a consensus driven organization calls for consensus are common, so your filter is broken. Please fix it, or just turn it off. > If you believe that there is a potential problem, it might be useful to > start by changing the subject line, since most of our filters weigh the > subject line heavily. Absolutely not. I will not try to guess what possible filters you have, nor try to remember which ones I've tripped over in the past, when answering someone else's e-mail. In this case I was answering an e-mail from the WG chair -- I won't look askance at the chairs' e-mails' subject lines! Nico -- From touch at ISI.EDU Fri Jun 1 10:48:49 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 01 Jun 2007 10:48:49 -0700 Subject: [anonsec] mailing list problems In-Reply-To: <20070601154232.GB1551@Sun.COM> References: <20070531174153.GT27420@Sun.COM> <46601C17.1020903@isi.edu> <20070601154232.GB1551@Sun.COM> Message-ID: <46605C01.3040806@isi.edu> Nicolas Williams wrote: ... >> In general, we receive very little spam, and trip up the system on cases >> like this rarely. > > I've been annoyed more than once by these filters. From what you say > any subject line with "call for" causes this. Well. In a consensus > driven organization calls for consensus are common, so your filter is > broken. Please fix it, or just turn it off. I will proceed with fixing the filter, which has been delayed replying to your repeated complaints. :-( Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/anonsec/attachments/20070601/80573c94/signature.bin From Nicolas.Williams at sun.com Fri Jun 1 11:27:12 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 1 Jun 2007 13:27:12 -0500 Subject: [anonsec] mailing list problems In-Reply-To: <46605C01.3040806@isi.edu> References: <20070531174153.GT27420@Sun.COM> <46601C17.1020903@isi.edu> <20070601154232.GB1551@Sun.COM> <46605C01.3040806@isi.edu> Message-ID: <20070601182712.GN1551@Sun.COM> On Fri, Jun 01, 2007 at 10:48:49AM -0700, Joe Touch wrote: > I will proceed with fixing the filter, which has been delayed replying > to your repeated complaints. Excuse me? The first complaint you rejected. The second caused you to finally fix it, and it's my fault that it's taking you some time to fix it?! For the record, I don't care if it takes you a day or three to fix it, as long as you do. Nico -- From miika at iki.fi Fri Jun 1 12:33:35 2007 From: miika at iki.fi (Miika Komu) Date: Fri, 1 Jun 2007 22:33:35 +0300 (EEST) Subject: [anonsec] Consensus call on WG adoption of draft-komu-btns-api-01 In-Reply-To: <87bqg1yorc.fsf@mocca.josefsson.org> References: <18558.1178935860@marajade.sandelman.ca> <200705311041.49271.julien.IETF@laposte.net> <87bqg1yorc.fsf@mocca.josefsson.org> Message-ID: On Thu, 31 May 2007, Simon Josefsson wrote: Hi, no worries, I got already feedback that the OpenSSL part should be removed or abstracted. It was there mostly to clarify things to myself. Thanks for the notice on the copyright. > I object to standardize any API that uses data types from a particular > external implementation (in this case OpenSSL). > > The approach used in this document appear to require that every > implementation of the document needs to #include OpenSSL headers, and > possibly call OpenSSL functions (the implementation of the > ipsec_openssl_to_channel_info is unclear to me). I believe that is > clearly unacceptable for any Standards Track document. > > If this problem can be solved, by having a generic interface to input > the necessary information needed from the TLS library, the document > seems like a useful contribution to me. > > A suggestion for an improvement to the document would be to add a > copyright license to the example code to make it possible to use the > example in implementations. This often helps spread usage and leads to > faster adoption of the API. See section 3 of > draft-josefsson-free-standards-howto-00.txt. > > /Simon > > Julien Laganier writes: > >> Folks, >> >> Miika has worked on C-bindings for the abstract API >> (draft-komu-btns-api-01). Hereby I'd like to call for >> WG adoption of this document. If you agree, or >> disagree with adoption, please send an email saying so >> to the mailing list without changing the subject line >> before 2007-06-14. (OTOH please do change the subject >> line if you want to discuss contents of the documents >> themselves.) >> >> (If you have no time to read the documents, you might >> take a look at their respective presentations given >> during last meeting.) >> >> -- julien / BTNS co-chair >> _______________________________________________ > _______________________________________________ > -- Miika Komu http://www.iki.fi/miika/ From Nicolas.Williams at sun.com Fri Jun 1 09:14:19 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 1 Jun 2007 11:14:19 -0500 Subject: [anonsec] Consensus call on WG adoption of draft-komu-btns-api-01 In-Reply-To: <87bqg1yorc.fsf@mocca.josefsson.org> References: <18558.1178935860@marajade.sandelman.ca> <200705311041.49271.julien.IETF@laposte.net> <87bqg1yorc.fsf@mocca.josefsson.org> Message-ID: <20070601161418.GH1551@Sun.COM> On Thu, May 31, 2007 at 05:52:07PM +0200, Simon Josefsson wrote: > I object to standardize any API that uses data types from a particular > external implementation (in this case OpenSSL). I agree that we must not have APIs that rely on non-standard APIs. I.e., a C bindings of Michael's API that relies on BSDish sockets (or Unix-like integer file descriptors for "sockets") is OK, but a C bindings of Michael's API that relies on OpenSSL is not. > The approach used in this document appear to require that every > implementation of the document needs to #include OpenSSL headers, and > possibly call OpenSSL functions (the implementation of the > ipsec_openssl_to_channel_info is unclear to me). I believe that is > clearly unacceptable for any Standards Track document. > > If this problem can be solved, by having a generic interface to input > the necessary information needed from the TLS library, the document > seems like a useful contribution to me. I'm sure that this problem can be solved. In fact, I can't understand why any dependence on any SSL/TLS library would be needed here. Miika's API should use octet strings to deal with certificates (DER or PEM) and raw public keys. > A suggestion for an improvement to the document would be to add a > copyright license to the example code to make it possible to use the > example in implementations. This often helps spread usage and leads to > faster adoption of the API. See section 3 of > draft-josefsson-free-standards-howto-00.txt. I should read that I-D. Yes, it's important in an API document to make sure that implementors have the right to: a) derive work from the API in the document and distribute the result freely, b) derive documentation from the RFC and distribute that freely. From julien.IETF at laposte.net Wed Jun 13 03:24:15 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Wed, 13 Jun 2007 12:24:15 +0200 Subject: [anonsec] WG adoption of draft-komu-btns-api-01 In-Reply-To: <200706011635.38550.julien.IETF@laposte.net> References: <18558.1178935860@marajade.sandelman.ca> <200706011635.38550.julien.IETF@laposte.net> Message-ID: <200706131224.16226.julien.IETF@laposte.net> Folks, We have a consensus to adopt draft-komu-btns-api-00 as WG item. Miika, could you please submit it as a WG draft: draft-ietf-btns-c-api-00. Best, -- julien, BTNS co-chair On Friday 01 June 2007 16:35, Julien Laganier wrote: > [re-issuing question w/ different subject line since > it seems the previous one got us caught in a spam > filter rule] > > Folks, > > Miika has worked on C-bindings for the abstract API > (draft-komu-btns-api-01). Hereby I'd like to call > for WG adoption of this document. If you agree, or > disagree with adoption, please send an email saying > so to the mailing list without changing the subject > line before 2007-06-15. (OTOH please do change the > subject line if you want to discuss contents of the > documents themselves.) > > (If you have no time to read the documents, you > might take a look at their respective presentations > given during last meeting.) > > -- julien / BTNS co-chair > _______________________________________________ From julien.IETF at laposte.net Wed Jun 13 03:24:11 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Wed, 13 Jun 2007 12:24:11 +0200 Subject: [anonsec] WG adoption draft-richardson-btns-abstract-api-00 In-Reply-To: <200706011635.41281.julien.IETF@laposte.net> References: <18558.1178935860@marajade.sandelman.ca> <200706011635.41281.julien.IETF@laposte.net> Message-ID: <200706131224.11844.julien.IETF@laposte.net> Folks, We have a consensus to adopt draft-richardson-btns-abstract-api-00 as WG item. Michael, could you please submit it as a WG draft: draft-ietf-btns-abstract-api-00. Best, -- julien, BTNS co-chair On Friday 01 June 2007 16:35, Julien Laganier wrote: > [re-issuing question w/ different subject line since > it seems the previous one got us caught in a spam > filter rule] > > Folks, > > Michael has worked on a revised abstract API, > available at: > > son-btns-abstract-api-00.txt> > > Hereby I'd like to call for WG adoption of this > document. If you agree, or disagree with adoption, > please send an email saying so to the mailing list > without changing the subject line before 2007-06-15. > (OTOH please do change the subject line if you want > to discuss contents of the documents themselves.) > > (If you have no time to read the documents, you > might take a look at their respective presentations > given during last meeting.) > > -- julien / BTNS co-chair > _______________________________________________ From julien.IETF at laposte.net Mon Jun 18 02:32:58 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Mon, 18 Jun 2007 11:32:58 +0200 Subject: [anonsec] Fwd: Nomcom 2007-8 Message-ID: <200706181132.59062.julien.IETF@laposte.net> FYI: the Nomcom chair, Lakshminath Dondeti, is asking for more volunteers to serve on the Nomcom (so far there's only about 50 people). Please see below for the details. --julien / btns co-chair -------------- next part -------------- An embedded message was scrubbed... From: Lakshminath Dondeti Subject: Nomcom 2007-8: First Call for Volunteers Date: Mon, 04 Jun 2007 17:32:15 -0700 Size: 6043 Url: http://mailman.postel.org/pipermail/anonsec/attachments/20070618/cee6d90a/attachment.mht From Internet-Drafts at ietf.org Mon Jun 18 12:50:02 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 18 Jun 2007 15:50:02 -0400 Subject: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-c-api-00.txt -------------- next part -------------- From caitlinb at broadcom.com Mon Jun 18 13:47:03 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Mon, 18 Jun 2007 13:47:03 -0700 Subject: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt In-Reply-To: Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D0439AF95@NT-IRVA-0750.brcm.ad.broadcom.com> 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 Mon Jun 18 14:03:13 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 18 Jun 2007 16:03:13 -0500 Subject: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D0439AF95@NT-IRVA-0750.brcm.ad.broadcom.com> References: <1EF1E44200D82B47BD5BA61171E8CE9D0439AF95@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <20070618210313.GL24098@Sun.COM> 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. > 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? 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. > 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 think discussions about the propriety of the IETF doing API work are outside the scope of this WG. > 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. 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. > 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? 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... > 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. 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 Mon Jun 18 14:36:53 2007 From: caitlinb at broadcom.com (Caitlin Bestler) Date: Mon, 18 Jun 2007 14:36:53 -0700 Subject: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt In-Reply-To: <20070618210313.GL24098@Sun.COM> Message-ID: <1EF1E44200D82B47BD5BA61171E8CE9D0439AFDC@NT-IRVA-0750.brcm.ad.broadcom.com> 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. 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 Mon Jun 18 14:57:51 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 18 Jun 2007 16:57:51 -0500 Subject: [anonsec] I-D ACTION:draft-ietf-btns-c-api-00.txt In-Reply-To: <1EF1E44200D82B47BD5BA61171E8CE9D0439AFDC@NT-IRVA-0750.brcm.ad.broadcom.com> References: <20070618210313.GL24098@Sun.COM> <1EF1E44200D82B47BD5BA61171E8CE9D0439AFDC@NT-IRVA-0750.brcm.ad.broadcom.com> Message-ID: <20070618215750.GP24098@Sun.COM> 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 -- From Internet-Drafts at ietf.org Fri Jun 29 14:08:01 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri, 29 Jun 2007 17:08:01 -0400 Subject: [anonsec] I-D ACTION:draft-ietf-btns-abstract-api-00.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-abstract-api-00.txt -------------- next part --------------