Discussion of anonymous security on the Internet

headers Sam Hartman | 4 Dec 2007 18:58

I'd like to request five minutes on the agenda to discuss interactions between our work and nfs.
_______________________________________________

What is the purpose of the connection states?  I see them enumerated but never used.

Why must implementations make available nat state?  I'm unconvinced
that is well enough defined to actually be useful.

   o  Any IPsec channel created with a given peer while another
      distinct, established IPsec channel exists with the same source
      and destination addresses SHOULD be bound to the same peer.

How does this interact with nats?
 Is it really desirable?
It seems like the BITS model plus proprietary extensions might work for channel binding.

Section 2.1: What does it mean for connection latches to be broken?

Section 2.1: define what a conflicting latch is; you use the term
several times but don't  define it.  There is what I think is a definition but it is not associated with the term.

_______________________________________________

On Thu, Dec 06, 2007 at 06:38:36PM -0500, Sam Hartman wrote:
> What is the purpose of the connection states?  I see them enumerated but never used.

To help describe the process by which latches are created and torn down.

> Why must implementations make available nat state?  I'm unconvinced
> that is well enough defined to actually be useful.

I think this is Michael's requirement.

>    o  Any IPsec channel created with a given peer while another
>       distinct, established IPsec channel exists with the same source
>       and destination addresses SHOULD be bound to the same peer.
> 
> 
> How does this interact with nats?

Hmmm, badly :)

>  Is it really desirable?

It's a mitigation for BTNS clients using non-channel binding
applications with multiple TCP connections.  It's not important to me,
and I'll be glad to remove it.

> It seems like the BITS model plus proprietary extensions might work for channel binding.

That's native IPsec built with BITS components.

> Section 2.1: What does it mean for connection latches to be broken?

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams <at> sun.com> writes:

    Nicolas> On Thu, Dec 06, 2007 at 06:38:36PM -0500, Sam Hartman
    Nicolas> wrote:
    >> What is the purpose of the connection states?  I see them
    >> enumerated but never used.

    Nicolas> To help describe the process by which latches are created
    Nicolas> and torn down.

Then actually use the states in section 2 etc.

    >> Why must implementations make available nat state?  I'm
    >> unconvinced that is well enough defined to actually be useful.

    Nicolas> I think this is Michael's requirement.

    >> o Any IPsec channel created with a given peer while another
    >> distinct, established IPsec channel exists with the same source
    >> and destination addresses SHOULD be bound to the same peer.
    >> 
    >> 
    >> How does this interact with nats?

    Nicolas> Hmmm, badly :)

    >> Is it really desirable?

    Nicolas> It's a mitigation for BTNS clients using non-channel
    Nicolas> binding applications with multiple TCP connections.  It's

On Thu, 6 Dec 2007, Nicolas Williams wrote:

> To help describe the process by which latches are created and torn down.
>
> > Why must implementations make available nat state?  I'm unconvinced
> > that is well enough defined to actually be useful.
>
> I think this is Michael's requirement.

I think this might have to do with detecting multiple clients behind
the same NAT router.

> >    o  Any IPsec channel created with a given peer while another
> >       distinct, established IPsec channel exists with the same source
> >       and destination addresses SHOULD be bound to the same peer.
> >
> >
> > How does this interact with nats?
>
> Hmmm, badly :)

Why not make it souce and destination address plus port?

>     o  Create a connection latch object for a ULP 5-tuple (local and
>        remote address, protocol and local and remote port numbers).

Like here.

Paul
_______________________________________________

On Thu, Dec 06, 2007 at 11:50:06PM -0500, Paul Wouters wrote:
> On Thu, 6 Dec 2007, Nicolas Williams wrote:
> > > Why must implementations make available nat state?  I'm unconvinced
> > > that is well enough defined to actually be useful.
> >
> > I think this is Michael's requirement.
> 
> I think this might have to do with detecting multiple clients behind
> the same NAT router.

The information is available, therefore requiring that it be made
available seems reasonable.  Making this a recommendation is also
reasonable.

> > >    o  Any IPsec channel created with a given peer while another
> > >       distinct, established IPsec channel exists with the same source
> > >       and destination addresses SHOULD be bound to the same peer.
> > >
> > >
> > > How does this interact with nats?
> >
> > Hmmm, badly :)
> 
> Why not make it souce and destination address plus port?

Did you mean only one port, and if so, the destination port, or both
ports?  (Connection latching already does this for all five elements of
the 5-tuple, so if your answer is "both" then note that that's the whole
point of connection latching :)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Better-Than-Nothing Security Working Group of the IETF.

	Title           : IPsec Channels: Connection Latching
	Author(s)       : N. Williams
	Filename        : draft-ietf-btns-connection-latching-04.txt
	Pages           : 20
	Date            : 2007-12-09

This document specifies, abstractly, how to interface applications
and transport protocols with IPsec so as to create "channels" by
"latching" "connections" (packet flows) to certain IPsec Security
Association (SA) parameters for the lifetime of the connections.
This can be used to protect applications against accidentally
exposing live packet flows to unintended peers, whether as the result
of a reconfiguration of IPsec or as the result of using weak peer
identity to peer address associations.

Weak association of peer ID and peer addresses is at the core of
Better Than Nothing Security (BTNS), thus connection latching can add
a significant measure of protection to BTNS IPsec nodes.  A model of
of connection latching is given.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-04.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce

Folks,

Minutes of the meeting are available there:

<http://www3.ietf.org/proceedings/07dec/minutes/btns.txt>

Please send to chairs corrections and/or add-ons, if any.

Thanks.

--julien
_______________________________________________

Nicolas Williams wrote:
> On Thu, Dec 06, 2007 at 06:38:36PM -0500, Sam Hartman wrote:
>> What is the purpose of the connection states?  I see them enumerated but never used.
> 
> To help describe the process by which latches are created and torn down.
> 
>> Why must implementations make available nat state?  I'm unconvinced
>> that is well enough defined to actually be useful.

> I think this is Michael's requirement.
> 
>>    o  Any IPsec channel created with a given peer while another
>>       distinct, established IPsec channel exists with the same source
>>       and destination addresses SHOULD be bound to the same peer.
>>
>>
>> How does this interact with nats?
> 
> Hmmm, badly :)

If as you say, it's my requirement, let me remember why.
I thought that we had ruled NAT interaction as out-of-scope.

BTW: real world case where channel binding is necessary:

http://www.schneier.com/blog/archives/2007/12/defeating_the_s.html
...
   This works because the two security systems are decoupled. And the shoe
   screening machine is so crowded and chaotic, and so poorly manned, that no
   one notices the switch.

Hi.  I've sent the core document to last call.  It was not as readable
as I would like.  If you get a bunch of comments back from people who
do not understand you probably should take a style and readability
pass.

I have two changes I'd like te request as last call comments myself.

First, when you require bare RSA cert payloads, please reference a
specific section of the IKE V2 spec for a definition of this.  Also,
how can BTNS work with DSA if nodes are required to include RSA
payloads?

Please replace the statement in section 4.2 that leap of faith is
being handled by BTNS with a statement that it is an item for future
work.

_______________________________________________

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

1	August 2008
3	July 2008
3	June 2008
4	May 2008
21	April 2008
1	March 2008
6	February 2008
34	January 2008
12	December 2007
3	November 2007
1	October 2007
11	September 2007
1	August 2007
42	July 2007
18	June 2007
21	May 2007
64	April 2007
42	March 2007
9	February 2007
1	January 2007
8	December 2006
4	November 2006
2	October 2006
5	September 2006
5	July 2006
10	June 2006
14	May 2006
60	April 2006
68	March 2006
48	February 2006
90	December 2005
37	November 2005
27	October 2005
18	September 2005
27	August 2005
3	July 2005
55	June 2005
17	May 2005
29	April 2005
103	March 2005
7	February 2005
7	January 2005
7	December 2004
203	November 2004
1	October 2004
64	September 2004

Five minutes to discuss nfs interactions

Comments on connection latching draft

Re: Comments on connection latching draft

Re: Comments on connection latching draft

Re: Comments on connection latching draft

Re: Comments on connection latching draft

I-D Action:draft-ietf-btns-connection-latching-04.txt

Minutes of BTNS session at IETF-70

Re: Comments on connection latching draft

AD review comments on draft-ietf-btns-core