Subject: [anonsec] Proposed BTNS charter

From: Black_David at emc.com ([email-masked])
Date: Tue, 15 Feb 2005 19:07:37 -0500

Sam and Nico,

>     Nicolas> Presumably we may conclude that there must also be a
>     Nicolas> mechanism for deliver such information to the
>     Nicolas> applications, and associated requirements, which I think
>     Nicolas> would fall under goal (e) below:
> 
> My intent was to make any API requirements work or actual API work
> require a recharter operation.  So, if we find that the best advice we
> can give is "we need this new mechanism," we should ask to revise the
> charter.

Can I agree with both of you?  I agree that API work, and requirements
work sufficient to drive API work do not belong here.  OTOH, for channel
bindings to be usable, a statement of the form "this is the material that
a higher level protocol needs from an IPsec SA in order to bind to it"
is needed (and possibly in a standard-track document) to avoid having the
discussion of how to channel binding (in document E) become irrelevant
because implementers didn't know *what* to expose.  I agree that *how*
to expose it (e.g., an API) and what to do after the info is exposed
(e.g., how the binding interacts with application authentication
protocols) should be out of scope, with the possible exception of
examples in document E.  FWIW, 2401 and 2401bis make a similar
distinction in that their databases (e.g., SAD, SPD) are specified
from a functional standpoint (*what* to do) without specifying APIs
or implementation algorithms (*how* to do it).

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: anonsec-bounces at postel.org 
> [mailto:anonsec-bounces at postel.org] On Behalf Of Sam Hartman
> Sent: Tuesday, February 15, 2005 6:19 PM
> To: Discussions of anonymous Internet security.
> Subject: Re: [anonsec] Proposed BTNS charter
> 
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> 
>     Nicolas> Sam, I like this charter very much.  Question:
>     >> Secondly, BTNS and the channel bindings work both encourage
>     >> IPsec to be used to secure higher layer protocols.  AS such we
>     >> need to consider what information these higher layer protocols
>     >> need from IPsec.
> 
>     Nicolas> Presumably we may conclude that there must also be a
>     Nicolas> mechanism for deliver such information to the
>     Nicolas> applications, and associated requirements, which I think
>     Nicolas> would fall under goal (e) below:
> 
> My intent was to make any API requirements work or actual API work
> require a recharter operation.  So, if we find that the best advice we
> can give is "we need this new mechanism," we should ask to revise the
> charter.  I'd object to including such work in the charter now because
> I don't believe we understand it well enough to agree to it, to
> convince the IESG we know what we are doing and have things running
> well enough to be sure we could do that work without derailing other
> efforts.
> 
> However if you take a look at the RFC 2401bis comment log in the id
> tracker you will see that I'm significantly concerned about these
> issues.
> 
> Note however that Steve Kent and probably other participants in the
> IPsec working group disagree with me.  Depending on how those
> discussions go, we may be looking at use of IPsec to secure higher
> level protocols very differently.  That's another reason I feel
> uncomfortable with anything more than implementation advice in a
> charter at this time.
> 
> --Sam
> 
> _______________________________________________
>

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Tue, 15 Feb 2005 20:24:19 -0500

On Tue, 2005-02-15 at 19:07, Black_David at emc.com wrote:

> is needed (and possibly in a standard-track document) 

moreover, any such efforts will be necessarily incomplete unless
someone actually builds an API and reports on how well it matched with the abstract architecture before we finalize the document.