[anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [e-mail])

[touch at ISI.EDU (Joe Touch)]

Stephen Kent wrote:

> Joe,
> 
>     <SNIP>
> 
>> Correction: it is a proposal to extend Internet security - including 
>> Ipsec, but also including TCP-MD5 (sometimes called "BGP MD5") and 
>> other security mechanisms at various layers. It is not focused only on 
>> IPsec.
> 
> TCP-MD5 and other MACs based on MD5 not using the HMAC construct are 
> generally  deprecated at this point.  TCP-MD5 had to get special text 
> written by Steve Bellovin to allow for its use in BGP, as that protocol 
> went to full standard, and that occurred only because of its widespread 
> implementation. So, going forward, it seems questionable to provide 
> support for protocols that use this form of MAC.
> 
> Steve
> _______________________________________________

That update may be part of what needs to be addressed; the focus of 
ANONSEC is to provide configuration-free security for any protocol. 
TCP-MD5 was used only as an example.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040910/b40a4ba1/signature.bin
From kent at bbn.com  Fri Sep 10 11:58:01 2004
From: kent at bbn.com (Stephen Kent)
Date: Fri Sep 10 11:59:28 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <p06110423bd67a2bc7691@[128.89.89.75]>

Nicolas,

	<SNIP>
>4) A self-signed cert is not much bigger than its public key and many
>software packages already deal just fine in self-signed certs.  See (0)
>above.

a self-signed cert is the same size as CA-issued cert if the CA has 
approximately the same size name as the subject.

	<SNIP>
>  > >I see two non-mutually exclusive ways to do that:
>>  >
>>  >a) provide APIs that apps can use to indicate desire/willingness to use
>>  >ANONSEC,
>>  >
>>  >and/or
>>  >
>>  >b) provide a way to propose, in the IKE protocol, ANONSEC.
>>
>>  These seem mutually dependent more than just 'not mutually exclusive", IMO.
>
>Not at all.
>
>I could have an SPD that says "if the peer supports ANONSEC, use
>ANONSEC, else bypass" for pretty much all traffic.  This is
>opportunistic ANONSEC and requires no APIs.

The SPD defined in 2401bis does not have a capability to express 
this. It would nominally be a PAD matter, since that is where one 
addresses the issue of what type of authentication is required to 
communicate with a given peer. But the PAD still does not accommodate 
the sort of gross access control you envision above. Fundamentally 
IPsec requires authentication so that it can effect access control. 
So, the notion of either bypassing traffic OR protecting it depending 
on what you learn as a side effect of an attempt to establish an SA 
is not something that IPsec accommodates.

Steve
From Nicolas.Williams at sun.com  Fri Sep 10 12:21:39 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Sep 10 12:25:48 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <p06110423bd67a2bc7691@[128.89.89.75]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<p06110423bd67a2bc7691@[128.89.89.75]>
Message-ID: <[e-mail]>

On Fri, Sep 10, 2004 at 02:58:01PM -0400, Stephen Kent wrote:
> >I could have an SPD that says "if the peer supports ANONSEC, use
> >ANONSEC, else bypass" for pretty much all traffic.  This is
> >opportunistic ANONSEC and requires no APIs.
> 
> The SPD defined in 2401bis does not have a capability to express 
> this. It would nominally be a PAD matter, since that is where one 
> addresses the issue of what type of authentication is required to 
> communicate with a given peer. But the PAD still does not accommodate 
> the sort of gross access control you envision above. Fundamentally 
> IPsec requires authentication so that it can effect access control. 
> So, the notion of either bypassing traffic OR protecting it depending 
> on what you learn as a side effect of an attempt to establish an SA 
> is not something that IPsec accommodates.

Clearly.  But ANONSEC is precisely about not authenticating.

So ANONSEC, as I see it, should be a profile of IKE, but the processing
model would require changes to accomodate opportunistic ANONSEC and, to
a lesser extent, ANONSEC itself.

Nico
-- 
From kent at bbn.com  Fri Sep 10 13:16:50 2004
From: kent at bbn.com (Stephen Kent)
Date: Fri Sep 10 13:21:36 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>	<[e-mail]>
	<p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
Message-ID: <p0611042bbd67baaf1392@[128.89.89.75]>

At 2:21 PM -0500 9/10/04, Nicolas Williams wrote:
>On Fri, Sep 10, 2004 at 02:58:01PM -0400, Stephen Kent wrote:
>>  >I could have an SPD that says "if the peer supports ANONSEC, use
>>  >ANONSEC, else bypass" for pretty much all traffic.  This is
>>  >opportunistic ANONSEC and requires no APIs.
>>
>>  The SPD defined in 2401bis does not have a capability to express
>>  this. It would nominally be a PAD matter, since that is where one
>>  addresses the issue of what type of authentication is required to
>>  communicate with a given peer. But the PAD still does not accommodate
>>  the sort of gross access control you envision above. Fundamentally
>>  IPsec requires authentication so that it can effect access control.
>>  So, the notion of either bypassing traffic OR protecting it depending
>>  on what you learn as a side effect of an attempt to establish an SA
>>  is not something that IPsec accommodates.
>
>Clearly.  But ANONSEC is precisely about not authenticating.
>
>So ANONSEC, as I see it, should be a profile of IKE, but the processing
>model would require changes to accomodate opportunistic ANONSEC and, to
>a lesser extent, ANONSEC itself.
>
>Nico

Yes, you might be able to just profile IKE, but you would have to 
change IPsec to accommodate this capability. The resulting products 
(ones that accommodate unauthenticated communication in this fashion) 
would be less secure than current IPsec products, in that they would 
allow configurations that would permit a MITM attack to circumvent 
the application of IPsec protection for traffic. It's not clear that 
one should modify IPsec to do this, vs. defining a different protocol 
that offers this as its primary service.

Steve
From Nicolas.Williams at sun.com  Fri Sep 10 13:33:45 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Sep 10 13:37:27 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <p0611042bbd67baaf1392@[128.89.89.75]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
Message-ID: <[e-mail]>

On Fri, Sep 10, 2004 at 04:16:50PM -0400, Stephen Kent wrote:
> Yes, you might be able to just profile IKE, but you would have to 
> change IPsec to accommodate this capability. The resulting products 
> (ones that accommodate unauthenticated communication in this fashion) 
> would be less secure than current IPsec products, in that they would 
> allow configurations that would permit a MITM attack to circumvent 
> the application of IPsec protection for traffic. It's not clear that 
> one should modify IPsec to do this, vs. defining a different protocol 
> that offers this as its primary service.

If your only choices are bypass or ANONSEC I think the choice is clear :)

And don't forget channel bindings, where the lack of authentication at
the lower layer is irrelevant (a feature, actually).

Opportunistic ANONSEC is not necessary for use with channel bindings,
which is what I'm after (remember?), but the ability to negotiate
ANONSEC is still needed, even when using APIs to request ANONSEC.

So, we have:

 - an IKE profile for ANONSEC
    - including changes to make ANONSEC negotiable

 - Bill's IPsec API reqs I-D

The processing model may have to change somewhat in order to allow for
some of the things that one could do with such APIs and/or for
opportunistic use of ANONSEC.

So we also have:

 - changes to the processing model (rfc2401bis+) for ANONSEC


Cheers,

Nico
-- 
From kent at bbn.com  Fri Sep 10 14:26:51 2004
From: kent at bbn.com (Stephen Kent)
Date: Fri Sep 10 14:29:25 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>	<[e-mail]>
	<p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
Message-ID: <p06110433bd67ca4dbc81@[128.89.89.75]>

Nico,

The explanations of what you are looking for are fine, but I don't 
think they change the accuracy of my observation.

Properly implemented IPsec products today offer a well-defined set of 
services. If one modified such products to offer the features you 
wish, the result would be more opportunities for mis-configurationw 
that result in insecure communications.

If the services that you want to offer are ones that fill an 
important, unmet need, then you can define a new standard, with a new 
name, and it should succeed on its own. If a vendor wants to offer a 
product that combines both sets of features, the way many firewall 
vendors today offer products that also incorporate IPsec, then they 
can do so and can state that the product implements IPsec plus 
ANONSEC, or whatever one chooses to call the new standard.

Steve
From Nicolas.Williams at sun.com  Fri Sep 10 14:46:25 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Sep 10 14:50:25 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <p06110433bd67ca4dbc81@[128.89.89.75]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
Message-ID: <[e-mail]>

On Fri, Sep 10, 2004 at 05:26:51PM -0400, Stephen Kent wrote:
> Nico,
> 
> The explanations of what you are looking for are fine, but I don't 
> think they change the accuracy of my observation.
> 
> Properly implemented IPsec products today offer a well-defined set of 
> services. If one modified such products to offer the features you 
> wish, the result would be more opportunities for mis-configurationw 
> that result in insecure communications.

First off, this is a silly argument.  Of course users could mis-
configure their systems and render them insecure -- there's no need to
add new features to any IETF protocols to make this possible.

Second, I'm not as interested in opportunistic ANONSEC as I am in
IKE/IPsec APIs and channel bindings, where there's much less room for
misconfiguration inherent in such uses of IPsec/ANONSEC.

But I used opportunistic ANONSEC to describe the sorts of changes that
might be necessary to support the concept.  These changes are aimed at
making negotiation of ANONSEC feasible, which would come in handy in
APIs/channel bindings uses of ANONSEC also.

> If the services that you want to offer are ones that fill an 
> important, unmet need, then you can define a new standard, with a new 
> name, and it should succeed on its own. If a vendor wants to offer a 
> product that combines both sets of features, the way many firewall 
> vendors today offer products that also incorporate IPsec, then they 
> can do so and can state that the product implements IPsec plus 
> ANONSEC, or whatever one chooses to call the new standard.

I thought "ANONSEC" was a different name than "IPsec" -- what gives?

The proposal is to build a new standard based on an existing one and
call it something else, which is exactly what you're telling us we
should do.

Nico
-- 
From Francis.Dupont at enst-bretagne.fr  Fri Sep 10 15:32:33 2004
From: Francis.Dupont at enst-bretagne.fr (Francis Dupont)
Date: Fri Sep 10 15:33:33 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: Your message of Thu, 09 Sep 2004 18:11:34 CDT.
	<[e-mail]> 
Message-ID: <[e-mail]>

 In your previous mail you wrote:

   I propose that ANONSEC be a simple profile of IKE[v2] that uses
   self-signed non-pre-shared certs for the CERT/AUTH exchanges.
   
=> why not raw public keys? They are smaller and in fact there is no
more info in self-signed certs... The policy should be simpler: just
accept raw keys (cert payloads of type 11).

   I see two non-mutually exclusive ways to do that:
   
   a) provide APIs that apps can use to indicate desire/willingness to use
   ANONSEC,
   
=> I assume there is an API which deals with acceptable cert payload types.
   
Regards

[e-mail]
From Nicolas.Williams at sun.com  Fri Sep 10 15:48:16 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Sep 10 15:52:25 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Sat, Sep 11, 2004 at 12:32:33AM +0200, Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    I propose that ANONSEC be a simple profile of IKE[v2] that uses
>    self-signed non-pre-shared certs for the CERT/AUTH exchanges.
>    
> => why not raw public keys? They are smaller and in fact there is no
> more info in self-signed certs... The policy should be simpler: just
> accept raw keys (cert payloads of type 11).

I addressed this already today.  See the archives.

>    I see two non-mutually exclusive ways to do that:
>    
>    a) provide APIs that apps can use to indicate desire/willingness to use
>    ANONSEC,
>    
> => I assume there is an API which deals with acceptable cert payload types.

See:

http://www.watersprings.org/pub/id/draft-ietf-ipsp-ipsec-apireq-00.txt

a work in progress.  (I know, it's expired.)

Nico
-- 
From touch at ISI.EDU  Fri Sep 10 16:01:51 2004
From: touch at ISI.EDU (Joe Touch)
Date: Fri Sep 10 16:04:28 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<p06110423bd67a2bc7691@[128.89.89.75]>	<[e-mail]>	<p0611042bbd67baaf1392@[128.89.89.75]>	<[e-mail]>	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
Message-ID: <[e-mail]>



Nicolas Williams wrote:

...
> The proposal is to build a new standard based on an existing one and
> call it something else, which is exactly what you're telling us we
> should do.
> 
> Nico

FWIW, ANONSEC is a superset of IPsec++, whatever it's called (e.g., 
ANONSEC-enabled IPsec), since it may refer to other protocols besides IPsec.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040910/9e6464e8/signature.bin
From Francis.Dupont at enst-bretagne.fr  Sat Sep 11 03:15:40 2004
From: Francis.Dupont at enst-bretagne.fr (Francis Dupont)
Date: Sat Sep 11 03:16:27 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: Your message of Fri, 10 Sep 2004 17:26:51 EDT.
	<p06110433bd67ca4dbc81@[128.89.89.75]> 
Message-ID: <[e-mail]>

 In your previous mail you wrote:

   The explanations of what you are looking for are fine, but I don't 
   think they change the accuracy of my observation.
   
=> I share your concern: we already have XAUTH which replaces strong
authentication by a login/password so we already have enough unsafe
misusage of IPsec! 

   ... the way many firewall 
   vendors today offer products that also incorporate IPsec, ...

=> note that ANONSEC is clearly end-to-end. For the gateway to gateway
protection in this style, we have the opportunistic encryption (which
properly deals with the issue we discuss about).
Another point: HIP has so called "anonymous identities" but it can be
used at most by one side. The rationale is that most of communications
are client/server and when the client can be anonymous (unauthenticated
to use the right term) this is never the case of the server.

Regards

[e-mail]

PS: the idea to bind a level of privilege to a kind of authentication
in IPsec/IKE is a general one we should really address one day
(but not in this list). IMHO one way is to integrate IKE into a
real AAA system.
From Francis.Dupont at enst-bretagne.fr  Sat Sep 11 03:21:23 2004
From: Francis.Dupont at enst-bretagne.fr (Francis Dupont)
Date: Sat Sep 11 03:22:26 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: Your message of Fri, 10 Sep 2004 17:48:16 CDT.
	<[e-mail]> 
Message-ID: <[e-mail]>

 In your previous mail you wrote:

   > => why not raw public keys? They are smaller and in fact there is no
   > more info in self-signed certs... The policy should be simpler: just
   > accept raw keys (cert payloads of type 11).
   
   I addressed this already today.  See the archives.
   
=> I saw this but I have to confess I am not convinced by your argument.

Regards

[e-mail]
From touch at ISI.EDU  Sat Sep 11 10:41:26 2004
From: touch at ISI.EDU (Joe Touch)
Date: Sat Sep 11 10:42:27 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>


Francis Dupont wrote:
...

 >    ... the way many firewall vendors today offer products that
 >        also incorporate IPsec, ...
 >
 > => note that ANONSEC is clearly end-to-end.

It seems like ANONSEC can also be useful to key between two firewalls, 
depending on the kind of security needed or desired.

E.g., it could be used to connect a protected enclave to the access 
point of a server farm. The purpose of this would be to reduce DOS'd 
traffic from places outside the two firewalls that is spoofing to appear 
as if inside.

 > For the gateway to gateway
 > protection in this style, we have the opportunistic encryption (which
 > properly deals with the issue we discuss about).

OE still relies on an infrastructure, namely the DNS. ANONSEC is 
intended to work even where there is no DNS available, or where 
configuring the DNS presents an additional level of installation complexity.

 > Another point: HIP has so called "anonymous identities" but it can be
 > used at most by one side. The rationale is that most of communications
 > are client/server and when the client can be anonymous (unauthenticated
 > to use the right term) this is never the case of the server.

Many of us use servers that are effectively anonymous - Akamai. ANONSEC 
is intended to protect ongoing associations - whether client-server, 
client-client, or firewall-firewall - based solely on the past behavior 
of that association, and to prevent others from interloping on that 
association. It protects you from 'whomever' you're talking to.

A good analogy, IMO, is phone calls. ANONSEC prevents others from 
jumping in and replacing the other end of the call while you're talking. 
But the call itself (e.g., consider an incoming political party pitch) 
need not authenticate either end at the call level. The application may 
decide to do that in-band (like we did before caller ID), or may not care.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040911/8e44cab3/signature.bin
From eugen at leitl.org  Sat Sep 11 13:23:35 2004
From: eugen at leitl.org (Eugen Leitl)
Date: Sat Sep 11 13:24:28 2004
Subject: anonymous IP terminology (Re: [anonsec] Re: potential new IETF WG on
	anonymous IPSec (fwd from [e-mail])) (fwd from
	[e-mail])
Message-ID: <[e-mail]>

----- Forwarded message from Adam Back <[e-mail]> -----

From: Adam Back <[e-mail]>
Date: Sat, 11 Sep 2004 13:49:23 -0400
To: Eugen Leitl <[e-mail]>
Cc: Cryptography List <[e-mail]>, [e-mail],
	Adam Back <[e-mail]>
Subject: anonymous IP terminology (Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [e-mail]))
User-Agent: Mutt/1.4.1i

Joe Touch <[e-mail]> wrote:
> >The point has nothing to do with anonymity;
> 
> The last one, agreed. But the primary assumption is that we can avoid a 
> lot of infrastructure and impediment to deployment by treating an 
> ongoing conversation as a reason to trust an endpoint, rather than a 
> third-party identification. Although anonymous access is not the primary 
> goal, it is a feature of the solution.

Joe:

I respectfully request that you call this something other than
"anonymous".  It is quite confusing and misleading.  

Some people have spent quite a bit of time and effort in fact working
on anonymous IP and anonymous/pseudonymous transports.

For example at ZKS we worked on an anonymous/pseudonymous IP product
(which means cryptographically hiding the souce IP address from the
end-site).

There are some new open source anonymous IP projects.


Your proposal, which may indeed have some merit in simplifying key
management, has _nothing_ to do with anonymous IP.  Your overloading
of the established term will dilute the correct meaning.

Zooko provided the correct term and provided references:
"opportunistic encryption".  It sounds to have similar objectives to
what John had called opportunistic encryption and tried to do with
freeSWAN.  Lowever level terms may be unauthenticated as Hal
suggested.  Or non-certified key management (as the SSH cacheing of
previously before seen IP <-> key bindings and warnings when they
change).

> Although anonymous access is not the primary goal, it is a feature
> of the solution.

The access is _not_ anonymous.  The originator's IP, ISP call traces,
phone access records will be all over it and associated audit logs.

The distinguishing feature of anonymous is that not only is your name
not associated with the connection but there is no PII (personally
identifiable information) associated with it or obtainable from logs
kept.

And to be clear also anonymous means unlinkable anonymous across
multiple connections (which SSH type of authentication would not be)
and linkable anonymous means some observable linkage exists between
sessions which come from the same source (though no PII), and
pseudonymous means same as linkable anonymous plus association to a
persistent pseudonym.

Again there are actually cryptographic protcols for_ having anonymous
authentication: ZKPs, multi-show unlinkable credentials, and
refreshable (and so unlinkable) single-show credentials.

Adam

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20040911/ba3fd990/attachment.bin
From Francis.Dupont at enst-bretagne.fr  Sun Sep 12 01:24:18 2004
From: Francis.Dupont at enst-bretagne.fr (Francis Dupont)
Date: Sun Sep 12 01:25:30 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: Your message of Sat, 11 Sep 2004 10:41:26 PDT.
	<[e-mail]> 
Message-ID: <[e-mail]>

 In your previous mail you wrote:
   
    > => note that ANONSEC is clearly end-to-end.
   
   It seems like ANONSEC can also be useful to key between two firewalls, 
   depending on the kind of security needed or desired.
   
=> I believe this case is very different than the generic end-to-end,
i.e., the infrastructure constraint of opportunistic encryption is less
a problem... or the total lack of real authentication of ANONSEC more
a problem.
   
   A good analogy, IMO, is phone calls. ANONSEC prevents others from 
   jumping in and replacing the other end of the call while you're talking. 
   But the call itself (e.g., consider an incoming political party pitch) 
   need not authenticate either end at the call level. The application may 
   decide to do that in-band (like we did before caller ID), or may not care.
   
=> I can see what you want. IMHO IPsec is not the right way, I believe
a protection at the transport level (an improved TCP MD5) is far better.
Mixed with PBKs and a bit of caching in order to cover the case of
successive communications (i.e., like SSL/TLS sessions) this should provide
it...

Thanks

[e-mail]
From kent at bbn.com  Mon Sep 13 08:37:40 2004
From: kent at bbn.com (Stephen Kent)
Date: Mon Sep 13 08:43:37 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>	<[e-mail]>
	<p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
Message-ID: <p06110406bd6b6c552ba6@[128.89.89.75]>


Nicolas,

My long (25+ year) experience in developing IP layer security systems 
has focused on high assurance contexts and that probably explains our 
different perspectives on this matter.  Letting applications control 
whether a traffic stream is protected or not is not the sort of thing 
I recommend, given the likelihood of Trojan Horse attacks that could 
circumvent such controls. Controls in security gateways or BITW 
implementations offer potentially much better assurance, as do 
OS-based controls for better OS's. I understand your perspective, 
which is trying to provide this sort of control, e.g., through an 
API, but we should understand that the result is likely to be 
considerably less secure in various dimensions


>
>>  If the services that you want to offer are ones that fill an
>>  important, unmet need, then you can define a new standard, with a new
>>  name, and it should succeed on its own. If a vendor wants to offer a
>>  product that combines both sets of features, the way many firewall
>>  vendors today offer products that also incorporate IPsec, then they
>>  can do so and can state that the product implements IPsec plus
>>  ANONSEC, or whatever one chooses to call the new standard.
>
>I thought "ANONSEC" was a different name than "IPsec" -- what gives?
>
>The proposal is to build a new standard based on an existing one and
>call it something else, which is exactly what you're telling us we
>should do.
>

Sorry, but I missed that point, when other folks discussed modifying 
IPsec processing, and profiling IKE.  It's fine to profile IKE and 
still call the result IKE, as it would be a subset, but changes to 
the 2401bis processing model yield something other than IPsec.

Also, the fact that the proposed WG has a different name does not 
imply that the resulting standard would not refer to the result as a 
form if "IPsec."  BTW, AH and ESP, as transit protocols, could be 
used independent of the rest of IPsec, so there would be no issues re 
naming there.

Steve
From Nicolas.Williams at sun.com  Mon Sep 13 09:33:25 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Sep 13 09:37:37 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <p06110406bd6b6c552ba6@[128.89.89.75]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
Message-ID: <[e-mail]>

On Mon, Sep 13, 2004 at 11:37:40AM -0400, Stephen Kent wrote:

[Quoting out of order.]
> >> If the services that you want to offer are ones that fill an
> >> important, unmet need, then you can define a new standard, with a new
> >> name, and it should succeed on its own. If a vendor wants to offer a
> >> product that combines both sets of features, the way many firewall
> >> vendors today offer products that also incorporate IPsec, then they
> >> can do so and can state that the product implements IPsec plus
> >> ANONSEC, or whatever one chooses to call the new standard.
> >
> >I thought "ANONSEC" was a different name than "IPsec" -- what gives?
> >
> >The proposal is to build a new standard based on an existing one and
> >call it something else, which is exactly what you're telling us we
> >should do.
> >
> 
> Sorry, but I missed that point, when other folks discussed modifying 
> IPsec processing, and profiling IKE.  It's fine to profile IKE and 
> still call the result IKE, as it would be a subset, but changes to 
> the 2401bis processing model yield something other than IPsec.

Good.  Then we need not have this argument :)

But your other points are worth answering even if we are in agreement
this one major point.

> Also, the fact that the proposed WG has a different name does not 
> imply that the resulting standard would not refer to the result as a 
> form if "IPsec."  BTW, AH and ESP, as transit protocols, could be 
> used independent of the rest of IPsec, so there would be no issues re 
> naming there.

Ok, I think we're in agreement here.

[Now on to the rest.]

> Nicolas,
> 
> My long (25+ year) experience in developing IP layer security systems 
> has focused on high assurance contexts and that probably explains our 
> different perspectives on this matter.  Letting applications control 
> whether a traffic stream is protected or not is not the sort of thing 
> I recommend, given the likelihood of Trojan Horse attacks that could 
> circumvent such controls.

Have you read Bill's I-D on API requirements?  Have you read my I-Ds on
channel bindings?  I suspect not, though I wouldn't blame you for not
reading them, but I think you'll get a better perspective on what all
these proposals are about if you read them.

We generally agree that apps should not be able to override policy.  The
APIs are there to help provide security above and beyond that which can
be provided by static policies.

Thus if the SPD says "protect FTP between these hosts/nets" then FTP
implementations could not force IPsec to be bypassed.  OTOH, FTP could
ask that IPsec to be applied where the SPD says "bypass."

With channel bindings and ANONSEC we can make some things feasible that
otherwise wouldn't be.  This is a benefit.  Specifically we can make
IPsec technology (ESP/AH, specifically, but also an ANONSEC profile of
IKE) useful without also deploying an IPsec authentication
infrastructure.  This would be particularly useful as a way to leverage
hardware acceleration of ESP/AH in environments where Kerberos V, for
example, but not IPsec, has been extensively deployed.

I see this last as a huge benefit, but I also see opportunistic ANONSEC
as better than nothing at all.

>                           Controls in security gateways or BITW 
> implementations offer potentially much better assurance, as do 
> OS-based controls for better OS's.

BITW?  BITW doesn't provide end-to-end security.

ANONSEC + channel bindings + application-layer authentication does
(without a PKI, without pre-sharing certs/keys).


>                                    I understand your perspective, 
> which is trying to provide this sort of control, e.g., through an 
> API, but we should understand that the result is likely to be 
> considerably less secure in various dimensions

This is a good argument for security considerations text such as
"ANONSEC SHOULD NOT be enabled by default" and so on.

This is not a good argument against ANONSEC, against IKE extensions that
make ANONSEC negotiable (which make opportunistic ANONSEC _and_ use of
ANONSEC with APIs and channel bindings possible).

Nico
-- 
From Nicolas.Williams at sun.com  Mon Sep 13 09:41:57 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Sep 13 09:45:58 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Sat, Sep 11, 2004 at 12:15:40PM +0200, Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    The explanations of what you are looking for are fine, but I don't 
>    think they change the accuracy of my observation.
>    
> => I share your concern: we already have XAUTH which replaces strong
> authentication by a login/password so we already have enough unsafe
> misusage of IPsec! 

At the same time XAUTH w/ login/password is better than nothing.

We need to make IETF security technologies deployable.  Since not at all
have an easy time deploying PKI and since many already have some
authentication infrastructure deployed it would be nice if we could make
use of such authentication infrastructures as are available, even when
they're not all that good.

One technology that is widely deployed but not very usable with IPsec is
Kerberos V.

There are several ways to fix this.  We could add GSS-API
CERT/CERTREQ/AUTH for IKEv2, then use the Kerberos V GSS-API mechanism
in IKE.  And we can make it possible to use the Kerberos V GSS-API
mechanism w/ channel bindings to "anonymous IPsec" (ANONSEC).  IMO we
should follow both approaches.

>    ... the way many firewall 
>    vendors today offer products that also incorporate IPsec, ...
> 
> => note that ANONSEC is clearly end-to-end. For the gateway to gateway
> protection in this style, we have the opportunistic encryption (which
> properly deals with the issue we discuss about).

ANONSEC provides no authentication and is subject to MITM attacks, so
it's not end-to-end.  It can be used as an end-to-end security system,
and that's just how we hope it would be used.

Add channel bindings and you do have an end-to-end security system.

> PS: the idea to bind a level of privilege to a kind of authentication
> in IPsec/IKE is a general one we should really address one day
> (but not in this list). IMHO one way is to integrate IKE into a
> real AAA system.

Can you clarify this?

Nico
-- 
From Nicolas.Williams at sun.com  Mon Sep 13 09:45:27 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Sep 13 09:49:34 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Sat, Sep 11, 2004 at 12:21:23PM +0200, Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    > => why not raw public keys? They are smaller and in fact there is no
>    > more info in self-signed certs... The policy should be simpler: just
>    > accept raw keys (cert payloads of type 11).
>    
>    I addressed this already today.  See the archives.
>    
> => I saw this but I have to confess I am not convinced by your argument.

Can you elaborate?

Nico
-- 
From touch at ISI.EDU  Mon Sep 13 10:13:26 2004
From: touch at ISI.EDU (Joe Touch)
Date: Mon Sep 13 10:13:42 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <p06110406bd6b6c552ba6@[128.89.89.75]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<p06110423bd67a2bc7691@[128.89.89.75]>	<[e-mail]>	<p0611042bbd67baaf1392@[128.89.89.75]>	<[e-mail]>	<p06110433bd67ca4dbc81@[128.89.89.75]>	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
Message-ID: <[e-mail]>



Stephen Kent wrote:

> 
> Nicolas,
> 
> My long (25+ year) experience in developing IP layer security systems 
> has focused on high assurance contexts and that probably explains our 
> different perspectives on this matter.  Letting applications control 
> whether a traffic stream is protected or not is not the sort of thing I 
> recommend, given the likelihood of Trojan Horse attacks that could 
> circumvent such controls. Controls in security gateways or BITW 
> implementations offer potentially much better assurance, as do OS-based 
> controls for better OS's. I understand your perspective, which is trying 
> to provide this sort of control, e.g., through an API, but we should 
> understand that the result is likely to be considerably less secure in 
> various dimensions

"Less secure" is part of the design goal. As is more deployable in 
certain contexts where less security, rather than none, is the desired 
alternative.

>>>  If the services that you want to offer are ones that fill an
>>>  important, unmet need, then you can define a new standard, with a new
>>>  name, and it should succeed on its own. If a vendor wants to offer a
>>>  product that combines both sets of features, the way many firewall
>>>  vendors today offer products that also incorporate IPsec, then they
>>>  can do so and can state that the product implements IPsec plus
>>>  ANONSEC, or whatever one chooses to call the new standard.
>>
>> I thought "ANONSEC" was a different name than "IPsec" -- what gives?

As I have noted before, ANONSEC covers a range of protocols, not just IPsec.

>> The proposal is to build a new standard based on an existing one and
>> call it something else, which is exactly what you're telling us we
>> should do.
> 
> Sorry, but I missed that point, when other folks discussed modifying 
> IPsec processing, and profiling IKE.  It's fine to profile IKE and still 
> call the result IKE, as it would be a subset, but changes to the 2401bis 
> processing model yield something other than IPsec.

That's why we would (maybe) call it part of ANONSEC.

> Also, the fact that the proposed WG has a different name does not imply 
> that the resulting standard would not refer to the result as a form if 
> "IPsec."  BTW, AH and ESP, as transit protocols, could be used 
> independent of the rest of IPsec, so there would be no issues re naming 
> there.

Please let the WG at least exist and make a decision before condemning a 
nonexistent entity for doing something it hasn't ;-)

Joe

> Steve
> _______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040913/801d4a18/signature.bin
From touch at ISI.EDU  Mon Sep 13 10:16:47 2004
From: touch at ISI.EDU (Joe Touch)
Date: Mon Sep 13 10:17:55 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>



Francis Dupont wrote:

>  In your previous mail you wrote:
>    
>     > => note that ANONSEC is clearly end-to-end.
>    
>    It seems like ANONSEC can also be useful to key between two firewalls, 
>    depending on the kind of security needed or desired.
>    
> => I believe this case is very different than the generic end-to-end,
> i.e., the infrastructure constraint of opportunistic encryption is less
> a problem... or the total lack of real authentication of ANONSEC more
> a problem.

We view this differently. IMO, the ability to avoid real authentication, 
opportunistic or otherwise, is an opportunity to use security when it 
would otherwise be completely disabled -- as we already have seen, e.g., 
in BGP.

>    A good analogy, IMO, is phone calls. ANONSEC prevents others from 
>    jumping in and replacing the other end of the call while you're talking. 
>    But the call itself (e.g., consider an incoming political party pitch) 
>    need not authenticate either end at the call level. The application may 
>    decide to do that in-band (like we did before caller ID), or may not care.
>    
> => I can see what you want. IMHO IPsec is not the right way, I believe
> a protection at the transport level (an improved TCP MD5) is far better.
> Mixed with PBKs and a bit of caching in order to cover the case of
> successive communications (i.e., like SSL/TLS sessions) this should provide
> it...

Right now the goal with the WG would be to develop ANONSEC variants for 
a variety of protocols at different levels, and to decide how to 
recommend their use. The rest is up to the system designer ;-)

Joe

> Thanks
> 
> [e-mail]
> _______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040913/ecfff6cb/signature.bin
From Francis.Dupont at enst-bretagne.fr  Mon Sep 13 10:58:37 2004
From: Francis.Dupont at enst-bretagne.fr (Francis Dupont)
Date: Mon Sep 13 10:59:39 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: Your message of Mon, 13 Sep 2004 11:41:57 CDT.
	<[e-mail]> 
Message-ID: <[e-mail]>

 In your previous mail you wrote:

   >    The explanations of what you are looking for are fine, but I don't 
   >    think they change the accuracy of my observation.
   >    
   > => I share your concern: we already have XAUTH which replaces strong
   > authentication by a login/password so we already have enough unsafe
   > misusage of IPsec! 
   
   At the same time XAUTH w/ login/password is better than nothing.
   
=> this is point where we clearly disagree: weak security is better
than nothing *only* it is really distinguished from strong security,
or with other words I have a real concern with pretenting to deploy
security in place of deploying true security. (this is not a personal
attack, I am trying just to stigmatize a common (mis)behavior.)

   We need to make IETF security technologies deployable.

=> but some IETF security technologies mandate strong authentication.
Either removing the strong authentication makes them insecure, or
keeping the strong authentication makes them hard to deploy.
The point where we disagree is whether the first alternative is honest
when the name is kept (i.e., people can still believe it is just
a profile/...).

   One technology that is widely deployed but not very usable with IPsec is
   Kerberos V.
   
=> what about KINK? And nobody said IKE is the only way to establish
IPsec SAs forever.

   >    ... the way many firewall 
   >    vendors today offer products that also incorporate IPsec, ...
   > 
   > => note that ANONSEC is clearly end-to-end. For the gateway to gateway
   > protection in this style, we have the opportunistic encryption (which
   > properly deals with the issue we discuss about).
   
   ANONSEC provides no authentication and is subject to MITM attacks, so
   it's not end-to-end.

=> you misunderstand what I tried to mean and as I don't understand
your comment I can't fix anything.

   It can be used as an end-to-end security system,
   and that's just how we hope it would be used.
   
   Add channel bindings and you do have an end-to-end security system.
   
   > PS: the idea to bind a level of privilege to a kind of authentication
   > in IPsec/IKE is a general one we should really address one day
   > (but not in this list). IMHO one way is to integrate IKE into a
   > real AAA system.
   
   Can you clarify this?
   
=> can we move to a more appropriate list first? (I suggest the IPsec one)

Regards

[e-mail]
From Francis.Dupont at enst-bretagne.fr  Mon Sep 13 11:31:51 2004
From: Francis.Dupont at enst-bretagne.fr (Francis Dupont)
Date: Mon Sep 13 11:32:38 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: Your message of Mon, 13 Sep 2004 10:16:47 PDT.
	<[e-mail]> 
Message-ID: <[e-mail]>

 In your previous mail you wrote:

   > => I believe this case is very different than the generic end-to-end,
   > i.e., the infrastructure constraint of opportunistic encryption is less
   > a problem... or the total lack of real authentication of ANONSEC more
   > a problem.
   
   We view this differently. IMO, the ability to avoid real authentication, 
   opportunistic or otherwise, is an opportunity to use security when it 
   would otherwise be completely disabled -- as we already have seen, e.g., 
   in BGP.
   
=> BGP is an example I don't understand: there are in the BGP context all
the needed things for real authentication, i.e., why not simply use IPsec?
I even less understand for IPv6 BGP because IPv6 implementations are supposed
to support IPsec. And I don't believe in "anonymous" BGP at all.
But I buy the idea of the need for unauthenticated security.

Thanks

[e-mail]
From Nicolas.Williams at sun.com  Mon Sep 13 12:56:45 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Sep 13 13:00:35 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Mon, Sep 13, 2004 at 07:58:37PM +0200, Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    >    The explanations of what you are looking for are fine, but I don't 
>    >    think they change the accuracy of my observation.
>    >    
>    > => I share your concern: we already have XAUTH which replaces strong
>    > authentication by a login/password so we already have enough unsafe
>    > misusage of IPsec! 
>    
>    At the same time XAUTH w/ login/password is better than nothing.
>    
> => this is point where we clearly disagree: weak security is better
> than nothing *only* it is really distinguished from strong security,
> or with other words I have a real concern with pretenting to deploy
> security in place of deploying true security. (this is not a personal
> attack, I am trying just to stigmatize a common (mis)behavior.)

Well, no, there are strong password authentication technologies that
would fit in XAUTH.  The ones in use aren't, and I don't care for them,
so we agree.  But the point about authentication infrastructures
remains, for we still have Kerberos V to deal with (see below).

>    We need to make IETF security technologies deployable.
> 
> => but some IETF security technologies mandate strong authentication.
> Either removing the strong authentication makes them insecure, or
> keeping the strong authentication makes them hard to deploy.
> The point where we disagree is whether the first alternative is honest
> when the name is kept (i.e., people can still believe it is just
> a profile/...).

The name is *NOT* the same ("ANONSEC" != "IPsec").

>    One technology that is widely deployed but not very usable with IPsec is
>    Kerberos V.
>    
> => what about KINK? And nobody said IKE is the only way to establish
> IPsec SAs forever.

That works for some things (and, anyways, for IKEv2 I would simply
specify GSS-API-based CERT/CERTREQ/AUTH -- forget KINK).

It won't work for NFS, which multiplexes multiple users over one TCP
connection (and going to one connection-per-{client, user, server}-tuple
means lots more state to keep for servers and large time sharing
clients.

>    >    ... the way many firewall 
>    >    vendors today offer products that also incorporate IPsec, ...
>    > 
>    > => note that ANONSEC is clearly end-to-end. For the gateway to gateway
>    > protection in this style, we have the opportunistic encryption (which
>    > properly deals with the issue we discuss about).
>    
>    ANONSEC provides no authentication and is subject to MITM attacks, so
>    it's not end-to-end.
> 
> => you misunderstand what I tried to mean and as I don't understand
> your comment I can't fix anything.

Ok.

>    It can be used as an end-to-end security system,
>    and that's just how we hope it would be used.
>    
>    Add channel bindings and you do have an end-to-end security system.
>    
>    > PS: the idea to bind a level of privilege to a kind of authentication
>    > in IPsec/IKE is a general one we should really address one day
>    > (but not in this list). IMHO one way is to integrate IKE into a
>    > real AAA system.
>    
>    Can you clarify this?
>    
> => can we move to a more appropriate list first? (I suggest the IPsec one)

Feel free.  I'm on the IPsec list also.

Nico
-- 
From kent at bbn.com  Mon Sep 13 13:41:03 2004
From: kent at bbn.com (Stephen Kent)
Date: Mon Sep 13 14:02:39 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>	<[e-mail]>
	<p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]> <[e-mail]>
Message-ID: <p0611040cbd6bb5664b9e@[128.89.89.75]>

At 10:13 AM -0700 9/13/04, Joe Touch wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature";
>	boundary="------------enigBD06D362FFBB812D5DA4F86E"
>
>
>
>Stephen Kent wrote:
>
>>
>>Nicolas,
>>
>>My long (25+ year) experience in developing IP layer security 
>>systems has focused on high assurance contexts and that probably 
>>explains our different perspectives on this matter.  Letting 
>>applications control whether a traffic stream is protected or not 
>>is not the sort of thing I recommend, given the likelihood of 
>>Trojan Horse attacks that could circumvent such controls. Controls 
>>in security gateways or BITW implementations offer potentially much 
>>better assurance, as do OS-based controls for better OS's. I 
>>understand your perspective, which is trying to provide this sort 
>>of control, e.g., through an API, but we should understand that the 
>>result is likely to be considerably less secure in various 
>>dimensions
>
>"Less secure" is part of the design goal. As is more deployable in 
>certain contexts where less security, rather than none, is the 
>desired alternative.

I don't quibble with the notion of "less secure" as a feature for a 
different protocol; I just don't want to to be confused with IPsec.

>
>>>>  If the services that you want to offer are ones that fill an
>>>>  important, unmet need, then you can define a new standard, with a new
>>>>  name, and it should succeed on its own. If a vendor wants to offer a
>>>>  product that combines both sets of features, the way many firewall
>>>>  vendors today offer products that also incorporate IPsec, then they
>>>>  can do so and can state that the product implements IPsec plus
>>>>  ANONSEC, or whatever one chooses to call the new standard.
>>>
>>>I thought "ANONSEC" was a different name than "IPsec" -- what gives?
>
>As I have noted before, ANONSEC covers a range of protocols, not just IPsec.
>
>>>The proposal is to build a new standard based on an existing one and
>>>call it something else, which is exactly what you're telling us we
>>>should do.
>>
>>Sorry, but I missed that point, when other folks discussed 
>>modifying IPsec processing, and profiling IKE.  It's fine to 
>>profile IKE and still call the result IKE, as it would be a subset, 
>>but changes to the 2401bis processing model yield something other 
>>than IPsec.
>
>That's why we would (maybe) call it part of ANONSEC.
>
>>Also, the fact that the proposed WG has a different name does not 
>>imply that the resulting standard would not refer to the result as 
>>a form if "IPsec."  BTW, AH and ESP, as transit protocols, could be 
>>used independent of the rest of IPsec, so there would be no issues 
>>re naming there.
>
>Please let the WG at least exist and make a decision before 
>condemning a nonexistent entity for doing something it hasn't ;-)
>
>Joe

Well, let's face it, we're off ot a mixed start based on the choice 
of the proposed WG's name (upon which others have commented) and a 
set of mixed messages re what is intended.  Even your text above is 
ambiguous in that regard, as it says "As I have noted before, ANONSEC 
covers a range of protocols, not just IPsec."  If it "covers" IPsec, 
then  I have a problem for the reasons I cited.  if it is a different 
protocol, then I don't.  So, I think it fair to raise this issue 
prior to the BOF.  It's not a condemnation; it's an alert :-)

Steve
From kent at bbn.com  Mon Sep 13 13:56:52 2004
From: kent at bbn.com (Stephen Kent)
Date: Mon Sep 13 14:02:40 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>	<[e-mail]>
	<p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
Message-ID: <p0611040dbd6bb70bae4c@[128.89.89.75]>

Nicholas,

	<SNIP>
>
>Have you read Bill's I-D on API requirements?  Have you read my I-Ds on
>channel bindings?  I suspect not, though I wouldn't blame you for not
>reading them, but I think you'll get a better perspective on what all
>these proposals are about if you read them.

Sorry, but I can't even keep up with reading WG I-Ds, much less 
individual submissions.  But, if this becomes a WG, I'll get around 
to reading it, or a successor.


>We generally agree that apps should not be able to override policy.  The
>APIs are there to help provide security above and beyond that which can
>be provided by static policies.

An SPD need not be static. The issue is who gets to change it.

>Thus if the SPD says "protect FTP between these hosts/nets" then FTP
>implementations could not force IPsec to be bypassed.  OTOH, FTP could
>ask that IPsec to be applied where the SPD says "bypass."

that would be fine.

>With channel bindings and ANONSEC we can make some things feasible that
>otherwise wouldn't be.  This is a benefit.  Specifically we can make
>IPsec technology (ESP/AH, specifically, but also an ANONSEC profile of
>IKE) useful without also deploying an IPsec authentication
>infrastructure.  This would be particularly useful as a way to leverage
>hardware acceleration of ESP/AH in environments where Kerberos V, for
>example, but not IPsec, has been extensively deployed.

I find this statement a bit confusing. Kerberos requires an 
infrastructure for authentication.

>I see this last as a huge benefit, but I also see opportunistic ANONSEC
>as better than nothing at all.

I'll echo Francis's comment here.  Some security is better than none, 
unless people choose to use the "some" and avoid the effort to move 
to "good." This is a tough issue, because none of fully understands 
what will and will not cause users to make better use of existing 
security technologies. We know that there are impediments such as bad 
software, bad management interfaces, reluctance to invest in 
infrastructure, etc. But, many (probably most) users are not well 
equipped to make value judgement re different levels of security 
quality. So when they are offered a new choice we do run the risk of 
causing folks to do something less good than they might otherwise 
have done.

>  >                           Controls in security gateways or BITW
>>  implementations offer potentially much better assurance, as do
>>  OS-based controls for better OS's.
>
>BITW?  BITW doesn't provide end-to-end security.

A BITW device associated with one host does. The work SCC did with 
3COM to create centrally managed firewalls + crypto (not quite IPsec) 
in a NIC is an example of a personal BITW implementation.

>ANONSEC + channel bindings + application-layer authentication does
>(without a PKI, without pre-sharing certs/keys).

it provides some security, but exactly what it provides is more 
difficult to assess.

>  >                                    I understand your perspective,
>>  which is trying to provide this sort of control, e.g., through an
>>  API, but we should understand that the result is likely to be
>>  considerably less secure in various dimensions
>
>This is a good argument for security considerations text such as
>"ANONSEC SHOULD NOT be enabled by default" and so on.
>
>This is not a good argument against ANONSEC, against IKE extensions that
>make ANONSEC negotiable (which make opportunistic ANONSEC _and_ use of
>ANONSEC with APIs and channel bindings possible).

Let me suggest that the BOF needs to have a clear description of what 
it is trying to accomplish, if it is to become a security area WG. 
The choice of ANONSEC as a title is a bad start in this regard, as 
other have noted :-)

Don't fall into the HIP model, the solution in search of a problem!

Steve
From Nicolas.Williams at sun.com  Mon Sep 13 14:28:24 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Sep 13 14:32:38 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <p0611040dbd6bb70bae4c@[128.89.89.75]>
References: <[e-mail]>
	<p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]>
Message-ID: <[e-mail]>

On Mon, Sep 13, 2004 at 04:56:52PM -0400, Stephen Kent wrote:
> Nicholas,
> 
> 	<SNIP>
> >
> >Have you read Bill's I-D on API requirements?  Have you read my I-Ds on
> >channel bindings?  I suspect not, though I wouldn't blame you for not
> >reading them, but I think you'll get a better perspective on what all
> >these proposals are about if you read them.
> 
> Sorry, but I can't even keep up with reading WG I-Ds, much less 
> individual submissions.  But, if this becomes a WG, I'll get around 
> to reading it, or a successor.

*nod* :)

Note though that Bill's I-D is a WG item for IPSP.

My I-Ds are WG items for NFSv4 and KITTEN (really, KITTEN).  KITTEN is
new.

ANONSEC, of course, is still just a proposed BoF.

> >With channel bindings and ANONSEC we can make some things feasible that
> >otherwise wouldn't be.  This is a benefit.  Specifically we can make
> >IPsec technology (ESP/AH, specifically, but also an ANONSEC profile of
> >IKE) useful without also deploying an IPsec authentication
> >infrastructure.  This would be particularly useful as a way to leverage
> >hardware acceleration of ESP/AH in environments where Kerberos V, for
> >example, but not IPsec, has been extensively deployed.
> 
> I find this statement a bit confusing. Kerberos requires an 
> infrastructure for authentication.

Right.  If you have Kerberos V deployed why now also deploy a PKI (or
self-signed certs, or whatever) for IPsec?

(And see my reply to Francis about KINK.  I addressed some of that at
SAAG @ IETF58 when I presented on channel bindings.)

> >I see this last as a huge benefit, but I also see opportunistic ANONSEC
> >as better than nothing at all.
> 
> I'll echo Francis's comment here.  Some security is better than none, 
> unless people choose to use the "some" and avoid the effort to move 
> to "good." This is a tough issue, because none of fully understands 
> what will and will not cause users to make better use of existing 
> security technologies. We know that there are impediments such as bad 
> software, bad management interfaces, reluctance to invest in 
> infrastructure, etc. But, many (probably most) users are not well 
> equipped to make value judgement re different levels of security 
> quality. So when they are offered a new choice we do run the risk of 
> causing folks to do something less good than they might otherwise 
> have done.

By "this last" I was referring to channel bindings to IPsec and ANONSEC.

That's what I'm after.

I also see room for "opportunistic ANONSEC", though I'm much less
interested in it, for the same reasons as you.  I don't reject it out of
hand because the thing that makes it possbile also enables a channel
bindings scenario that I care about.

I suppose I should then stop arguing that it's better than nothing.  I
think I will.


> > >                           Controls in security gateways or BITW
> >> implementations offer potentially much better assurance, as do
> >> OS-based controls for better OS's.
> >
> >BITW?  BITW doesn't provide end-to-end security.
> 
> A BITW device associated with one host does. The work SCC did with 
> 3COM to create centrally managed firewalls + crypto (not quite IPsec) 
> in a NIC is an example of a personal BITW implementation.

If it's associated with the host, closely integrated even, then it isn't
really BITW from a security p.o.v., even if it is from a HW design
p.o.v.

> >ANONSEC + channel bindings + application-layer authentication does
> >(without a PKI, without pre-sharing certs/keys).
> 
> it provides some security, but exactly what it provides is more 
> difficult to assess.

More than "some," but, yes.

> > >                                    I understand your perspective,
> >> which is trying to provide this sort of control, e.g., through an
> >> API, but we should understand that the result is likely to be
> >> considerably less secure in various dimensions
> >
> >This is a good argument for security considerations text such as
> >"ANONSEC SHOULD NOT be enabled by default" and so on.
> >
> >This is not a good argument against ANONSEC, against IKE extensions that
> >make ANONSEC negotiable (which make opportunistic ANONSEC _and_ use of
> >ANONSEC with APIs and channel bindings possible).
> 
> Let me suggest that the BOF needs to have a clear description of what 
> it is trying to accomplish, if it is to become a security area WG. 
> The choice of ANONSEC as a title is a bad start in this regard, as 
> other have noted :-)

Ah, the name issue.  Yes, "ANONSEC" appears to annoy a significant
subset of the intended audience.

I think there's enough interest and subject matter to justify a BoF.

> Don't fall into the HIP model, the solution in search of a problem!

:)

Thanks!

Nico
-- 
From touch at ISI.EDU  Mon Sep 13 14:33:25 2004
From: touch at ISI.EDU (Joe Touch)
Date: Mon Sep 13 14:33:37 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <p0611040cbd6bb5664b9e@[128.89.89.75]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<p06110423bd67a2bc7691@[128.89.89.75]>	<[e-mail]>	<p0611042bbd67baaf1392@[128.89.89.75]>	<[e-mail]>	<p06110433bd67ca4dbc81@[128.89.89.75]>	<[e-mail]>	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]> <p0611040cbd6bb5664b9e@[128.89.89.75]>
Message-ID: <[e-mail]>



Stephen Kent wrote:
...
>> As I have noted before, ANONSEC covers a range of protocols, not just 
>> IPsec.
...
>>> Also, the fact that the proposed WG has a different name does not 
>>> imply that the resulting standard would not refer to the result as a 
>>> form if "IPsec."  BTW, AH and ESP, as transit protocols, could be 
>>> used independent of the rest of IPsec, so there would be no issues re 
>>> naming there.
>>
>>
>> Please let the WG at least exist and make a decision before condemning 
>> a nonexistent entity for doing something it hasn't ;-)
>>
>> Joe
> 
> Well, let's face it, we're off ot a mixed start based on the choice of 
> the proposed WG's name (upon which others have commented) and a set of 
> mixed messages re what is intended.

The presentation at the San Diego IETF was unamiguous in this regard.

> Even your text above is ambiguous 
> in that regard, as it says "As I have noted before, ANONSEC covers a 
> range of protocols, not just IPsec."  If it "covers" IPsec, then  I have 
> a problem for the reasons I cited.

It would "cover" a range of protocols which would be augmented. Cover = 
content of the work of the WG that would result from the BOF.

The names of the augmented results is for the WG and the IESG to decide, 
ultimately. Right now, the BOF name is the only thing that has been 
decided - ANONSEC.

And while I have heard arguments that this is different from "spinning 
IP addresses to provide a sense of privacy", anonymity is exactly what 
is provided when you cannot - and choose not - to authenticate the 
endpoint, regardless of whether the address changes or not.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040913/613859e9/signature.bin
From touch at ISI.EDU  Mon Sep 13 14:41:13 2004
From: touch at ISI.EDU (Joe Touch)
Date: Mon Sep 13 14:41:44 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <p0611040dbd6bb70bae4c@[128.89.89.75]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<p06110423bd67a2bc7691@[128.89.89.75]>	<[e-mail]>	<p0611042bbd67baaf1392@[128.89.89.75]>	<[e-mail]>	<p06110433bd67ca4dbc81@[128.89.89.75]>	<[e-mail]>	<p06110406bd6b6c552ba6@[128.89.89.75]>	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]>
Message-ID: <[e-mail]>



Stephen Kent wrote:

> Nicholas,
> 
...
>> I see this last as a huge benefit, but I also see opportunistic ANONSEC
>> as better than nothing at all.
> 
> I'll echo Francis's comment here.  Some security is better than none, 
> unless people choose to use the "some" and avoid the effort to move to 
> "good." This is a tough issue, because none of fully understands what 
> will and will not cause users to make better use of existing security 
> technologies. We know that there are impediments such as bad software, 
> bad management interfaces, reluctance to invest in infrastructure, etc. 
> But, many (probably most) users are not well equipped to make value 
> judgement re different levels of security quality. So when they are 
> offered a new choice we do run the risk of causing folks to do something 
> less good than they might otherwise have done.

Folks are doing nothing in many places. We saw that with the attacks on 
the routers this past spring. IPsec was available, as was TCP-MD5. Sure, 
they COULD HAVE BEEN configured. Maybe they SHOULD HAVE BEEN configured.

The fact is that they WERE NOT configured.

The choice to use security ultimately remains in with the applications 
and configurations of the systems. Right now, the alternative is 'no 
security' in many of these cases.

> Let me suggest that the BOF needs to have a clear description of what it 
> is trying to accomplish, if it is to become a security area WG. The 
> choice of ANONSEC as a title is a bad start in this regard, as other 
> have noted :-)

If you have a specific reason why this is not 'anonymous', please 
provide it, esp. in response to my earlier reasons for explaining why it 
is anonymous.

If the objection is the use of a term that looks too much like IPsec, 
I'm not sure that is sufficient.

> Don't fall into the HIP model, the solution in search of a problem!

The problem already happened, as per above.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040913/774b583d/signature-0001.bin
From Nicolas.Williams at sun.com  Mon Sep 13 14:46:34 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Sep 13 14:50:34 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]> <[e-mail]>
Message-ID: <[e-mail]>

On Mon, Sep 13, 2004 at 02:41:13PM -0700, Joe Touch wrote:
> If you have a specific reason why this is not 'anonymous', please 
> provide it, esp. in response to my earlier reasons for explaining why it 
> is anonymous.

I'm still struggling with why "ANONSEC" is offensive.  Your answer to
the charge is convincing to me.  Perhaps we can have a fun argument at
Washington, D.C.  :)

Nico
-- 
From kent at bbn.com  Mon Sep 13 15:11:22 2004
From: kent at bbn.com (Stephen Kent)
Date: Mon Sep 13 15:42:40 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>	<[e-mail]>
	<p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>	<[e-mail]>
	<p0611040cbd6bb5664b9e@[128.89.89.75]> <[e-mail]>
Message-ID: <p06110411bd6bcad8527c@[128.89.89.75]>

At 2:33 PM -0700 9/13/04, Joe Touch wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature";
>	boundary="------------enig41CB6D3581A35A4ED9F7924E"
>
>
>
>Stephen Kent wrote:
>...
>>>As I have noted before, ANONSEC covers a range of protocols, not just IPsec.
>...
>>>>Also, the fact that the proposed WG has a different name does not 
>>>>imply that the resulting standard would not refer to the result 
>>>>as a form if "IPsec."  BTW, AH and ESP, as transit protocols, 
>>>>could be used independent of the rest of IPsec, so there would be 
>>>>no issues re naming there.
>>>
>>>
>>>Please let the WG at least exist and make a decision before 
>>>condemning a nonexistent entity for doing something it hasn't ;-)
>>>
>>>Joe
>>
>>Well, let's face it, we're off ot a mixed start based on the choice 
>>of the proposed WG's name (upon which others have commented) and a 
>>set of mixed messages re what is intended.
>
>The presentation at the San Diego IETF was unamiguous in this regard.

As we both know, what ultimately counts for a WG is what is written, 
on the list and in WG approved document, not what is said at IETF 
meetings.

>
>>Even your text above is ambiguous in that regard, as it says "As I 
>>have noted before, ANONSEC covers a range of protocols, not just 
>>IPsec."  If it "covers" IPsec, then  I have a problem for the 
>>reasons I cited.
>
>It would "cover" a range of protocols which would be augmented. 
>Cover = content of the work of the WG that would result from the BOF.

still ambiguous.

>The names of the augmented results is for the WG and the IESG to 
>decide, ultimately. Right now, the BOF name is the only thing that 
>has been decided - ANONSEC.
>
>And while I have heard arguments that this is different from 
>"spinning IP addresses to provide a sense of privacy", anonymity is 
>exactly what is provided when you cannot - and choose not - to 
>authenticate the endpoint, regardless of whether the address changes 
>or not.

Your dismissive view of what constitutes anonymity in Internet 
communication runs counter to a fair amount of literature on the 
topic.

Steve
From kent at bbn.com  Mon Sep 13 15:44:38 2004
From: kent at bbn.com (Stephen Kent)
Date: Mon Sep 13 15:46:38 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>	<[e-mail]>
	<p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]> <[e-mail]>
Message-ID: <p06110412bd6bcbb28597@[128.89.89.75]>

Joe,

>Folks are doing nothing in many places. We saw that with the attacks 
>on the routers this past spring. IPsec was available, as was 
>TCP-MD5. Sure, they COULD HAVE BEEN configured. Maybe they SHOULD 
>HAVE BEEN configured.
>
>The fact is that they WERE NOT configured.
>
>The choice to use security ultimately remains in with the 
>applications and configurations of the systems. Right now, the 
>alternative is 'no security' in many of these cases.

In the case of TCP/MD5 and BGP, this is a configuration matter, not 
an application issue.

>
>>Let me suggest that the BOF needs to have a clear description of 
>>what it is trying to accomplish, if it is to become a security area 
>>WG. The choice of ANONSEC as a title is a bad start in this regard, 
>>as other have noted :-)
>
>If you have a specific reason why this is not 'anonymous', please 
>provide it, esp. in response to my earlier reasons for explaining 
>why it is anonymous.

IP addresses are not generally anonymous.  Fixed allocation addresses 
are readily mapped to names, often very descriptive names, via 
inverse DNS lookup. Addresses assigned by DHCP in an enterprise 
environment are identifiers to the granularity of the enterprise, or 
better. Even addresses assigned by DHCP from a public pool, e.g., at 
a hotel using wired IP access, are not anonymous of one asks the 
hotel to map the address used at a fixed time to the occupant of the 
room in question.  Real anonymity measures of the sort described in 
the literature, e.g., Onion routing, work to overcome these 
limitations.

What I think you are really trying to do is to provide a common 
mechanism (or set of mechanism) that may be used by different 
protocols to provide authentication of the continuity of repeated 
communications between parties.  Since Nicholas cites examples of how 
he wants to use these mechanisms to provide authenticated channel 
bindings, it seem likely that any notion of anonymity is not really 
integral to the mechanisms and scenarios that are "within scope" for 
the activity.

Steve
From Nicolas.Williams at sun.com  Mon Sep 13 16:05:43 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Sep 13 16:09:42 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <p06110412bd6bcbb28597@[128.89.89.75]>
References: <[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]> <[e-mail]>
	<p06110412bd6bcbb28597@[128.89.89.75]>
Message-ID: <[e-mail]>

On Mon, Sep 13, 2004 at 06:44:38PM -0400, Stephen Kent wrote:
> IP addresses are not generally anonymous.  Fixed allocation addresses 
> are readily mapped to names, often very descriptive names, via 
> inverse DNS lookup. Addresses assigned by DHCP in an enterprise 
> environment are identifiers to the granularity of the enterprise, or 
> better. Even addresses assigned by DHCP from a public pool, e.g., at 
> a hotel using wired IP access, are not anonymous of one asks the 
> hotel to map the address used at a fixed time to the occupant of the 
> room in question.  Real anonymity measures of the sort described in 
> the literature, e.g., Onion routing, work to overcome these 
> limitations.

What I mean by "anonymous" in the ANONSEC context (and I think Joe would
agree; Joe?) includes: a) peers with IDs that cannot be validated (e.g.,
un-pre-shared certs) and, b) peers without IDs.

Clearly there is a subtle difference between (a) and (b).

This difference is meaningless in the channel bindings scenario (the
one I care the most about), as long as there is a way to bind to the
ANONSEC channels (which I believe is doable for (a) and (b) as I have
described before).

In my construction of ANONSEC as a profile of/extension to/derivative of
IKE peers do always have IDs, but the IDs may be as inpersonal as
fingerprints of public keys or self-signed certs.

So in my construction of ANONSEC anonymity is really always (a).

> What I think you are really trying to do is to provide a common 
> mechanism (or set of mechanism) that may be used by different 
> protocols to provide authentication of the continuity of repeated 
> communications between parties.  Since Nicholas cites examples of how 
> he wants to use these mechanisms to provide authenticated channel 
> bindings, it seem likely that any notion of anonymity is not really 
> integral to the mechanisms and scenarios that are "within scope" for 
> the activity.

Right, for the channel bindings scenario anonimity is a tangential issue
that relates to deployment, rather than an essential or integral feature.

For the channel bindings scenario the authentication infrastructure used
at the application layer is all the authentication that matters, so
having any degree of anonymity in the lower layer channel is a plus: it
means you needn't deploy a [potentially different] authentication
infrastructure for that lower layer channel.

Nico
-- 
From rabbi at abditum.com  Tue Sep 14 03:41:00 2004
From: rabbi at abditum.com (Len Sassaman)
Date: Tue Sep 14 03:41:39 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]> <[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Mon, 13 Sep 2004, Nicolas Williams wrote:

> On Mon, Sep 13, 2004 at 02:41:13PM -0700, Joe Touch wrote:
> > If you have a specific reason why this is not 'anonymous', please
> > provide it, esp. in response to my earlier reasons for explaining why it
> > is anonymous.
>
> I'm still struggling with why "ANONSEC" is offensive.  Your answer to
> the charge is convincing to me.  Perhaps we can have a fun argument at
> Washington, D.C.  :)

It isn't offensive; it is simply incorrect. There is an established field
of study of anonymity in network protocols that spans 25 years, and
implies something very different than a mere lack of strong
authentication.

For a fairly compressive bibliography of research in this area, Roger
Dingledine maintains a bib file at: http://www.freehaven.net/anonbib/

What you are describing is non-authentication, or more specifically in
this context, as the literature describes, "opportunistic encryption".
This is an important area that must be developed -- the problems you have
identified, and your goals, are important ones. But they are *different*
ones than the anonymity systems attempt to solve.

I think you will have more interest from the network security and
cryptographic research communities if you name this properly, as people
will understand what it is that you system is attempting to accomplish,
instead of complaining that it doesn't do what it says.

Hope this helps,

Len
From kent at bbn.com  Tue Sep 14 07:13:04 2004
From: kent at bbn.com (Stephen Kent)
Date: Tue Sep 14 07:14:41 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]> <[e-mail]>
	<p06110412bd6bcbb28597@[128.89.89.75]>
	<[e-mail]>
Message-ID: <p06110402bd6c9cfba374@[128.89.89.75]>

At 6:05 PM -0500 9/13/04, Nicolas Williams wrote:
>On Mon, Sep 13, 2004 at 06:44:38PM -0400, Stephen Kent wrote:
>>  IP addresses are not generally anonymous.  Fixed allocation addresses
>>  are readily mapped to names, often very descriptive names, via
>>  inverse DNS lookup. Addresses assigned by DHCP in an enterprise
>>  environment are identifiers to the granularity of the enterprise, or
>>  better. Even addresses assigned by DHCP from a public pool, e.g., at
>>  a hotel using wired IP access, are not anonymous of one asks the
>>  hotel to map the address used at a fixed time to the occupant of the
>>  room in question.  Real anonymity measures of the sort described in
>>  the literature, e.g., Onion routing, work to overcome these
>>  limitations.
>
>What I mean by "anonymous" in the ANONSEC context (and I think Joe would
>agree; Joe?) includes: a) peers with IDs that cannot be validated (e.g.,
>un-pre-shared certs) and, b) peers without IDs.

unfortunately, the first example is not what the technical literature 
defines as anonymous communication.  even the second example is a bit 
vague, because anonymity is usually viewed in the context of 
preserving privacy, and that assumes that there are folks trying to 
invade privacy and who will try to use various means to map entities 
to identities, as I noted in my examples.

>Clearly there is a subtle difference between (a) and (b).
>
>This difference is meaningless in the channel bindings scenario (the
>one I care the most about), as long as there is a way to bind to the
>ANONSEC channels (which I believe is doable for (a) and (b) as I have
>described before).
>
>In my construction of ANONSEC as a profile of/extension to/derivative of
>IKE peers do always have IDs, but the IDs may be as inpersonal as
>fingerprints of public keys or self-signed certs.
>
>So in my construction of ANONSEC anonymity is really always (a).

I certainly have no objection to your focus, but to call it anonymous 
communication is not correct. I think the term Michael Richardson 
coined, "opportunistic encryption" is more appropriate, even if the 
underlying mechanisms differ.



Steve
From touch at ISI.EDU  Tue Sep 14 09:18:58 2004
From: touch at ISI.EDU (Joe Touch)
Date: Tue Sep 14 09:19:50 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]> <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>



Len Sassaman wrote:

> On Mon, 13 Sep 2004, Nicolas Williams wrote:
> 
> 
>>On Mon, Sep 13, 2004 at 02:41:13PM -0700, Joe Touch wrote:
>>
>>>If you have a specific reason why this is not 'anonymous', please
>>>provide it, esp. in response to my earlier reasons for explaining why it
>>>is anonymous.
>>
>>I'm still struggling with why "ANONSEC" is offensive.  Your answer to
>>the charge is convincing to me.  Perhaps we can have a fun argument at
>>Washington, D.C.  :)
> 
> 
> It isn't offensive; it is simply incorrect. There is an established field
> of study of anonymity in network protocols that spans 25 years, and
> implies something very different than a mere lack of strong
> authentication.

What is incorrect is to mistake anonymous security for anonymous 
forwarding, or to lump anything with the word anonymous into anonymous 
forwarding.

> What you are describing is non-authentication, or more specifically in
> this context, as the literature describes, "opportunistic encryption".

OE means different things to different people; in particular, it refers 
to setting up encyption associations prior to their actual request. This 
is closer to what 'prefetching the means' is to web transactions.

Non-authentication isn't what's going on either - there IS 
authentication, just without identification.

> This is an important area that must be developed -- the problems you have
> identified, and your goals, are important ones. But they are *different*
> ones than the anonymity systems attempt to solve.

I agree completely. This is NOT AN ANONYMITY SYSTEM. This is not 
ANONYMOUS FORWARDING.

It is still anonymous SECURITY, however.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040914/c0f080ec/signature.bin
From touch at ISI.EDU  Tue Sep 14 09:24:43 2004
From: touch at ISI.EDU (Joe Touch)
Date: Tue Sep 14 09:25:57 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <p06110411bd6bcad8527c@[128.89.89.75]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<p06110423bd67a2bc7691@[128.89.89.75]>	<[e-mail]>	<p0611042bbd67baaf1392@[128.89.89.75]>	<[e-mail]>	<p06110433bd67ca4dbc81@[128.89.89.75]>	<[e-mail]>	<p06110406bd6b6c552ba6@[128.89.89.75]>	<[e-mail]>	<p0611040cbd6bb5664b9e@[128.89.89.75]>
	<[e-mail]> <p06110411bd6bcad8527c@[128.89.89.75]>
Message-ID: <[e-mail]>



Stephen Kent wrote:

>> And while I have heard arguments that this is different from "spinning 
>> IP addresses to provide a sense of privacy", anonymity is exactly what 
>> is provided when you cannot - and choose not - to authenticate the 
>> endpoint, regardless of whether the address changes or not.
> 
> Your dismissive view of what constitutes anonymity in Internet 
> communication runs counter to a fair amount of literature on the topic.

You and others have confused anonymity in general with anonymous 
security. This is obviously not anonmyous forwarding; the separation of 
forwarding and security has come up before.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040914/0a31ec35/signature-0001.bin
From touch at ISI.EDU  Tue Sep 14 09:32:51 2004
From: touch at ISI.EDU (Joe Touch)
Date: Tue Sep 14 09:33:47 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <p06110412bd6bcbb28597@[128.89.89.75]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<p06110423bd67a2bc7691@[128.89.89.75]>	<[e-mail]>	<p0611042bbd67baaf1392@[128.89.89.75]>	<[e-mail]>	<p06110433bd67ca4dbc81@[128.89.89.75]>	<[e-mail]>	<p06110406bd6b6c552ba6@[128.89.89.75]>	<[e-mail]>	<p0611040dbd6bb70bae4c@[128.89.89.75]>
	<[e-mail]> <p06110412bd6bcbb28597@[128.89.89.75]>
Message-ID: <[e-mail]>



Stephen Kent wrote:
> Joe,
...


>>> Let me suggest that the BOF needs to have a clear description of what 
>>> it is trying to accomplish, if it is to become a security area WG. 
>>> The choice of ANONSEC as a title is a bad start in this regard, as 
>>> other have noted :-)
>>
>>
>> If you have a specific reason why this is not 'anonymous', please 
>> provide it, esp. in response to my earlier reasons for explaining why 
>> it is anonymous.
> 
> IP addresses are not generally anonymous.

ANONSEC isn't anonymous forwarding, if that's what you're referring to. 
However, knowing the source IP address tells you nothing about where the 
packet actually originated - spoofing relies on that.

> Fixed allocation addresses 
> are readily mapped to names, often very descriptive names, via inverse 
> DNS lookup.

Which is why ISI is called whenever 10.x.x.x addresses leak into the 
Internet. A reverse lookup of an address that means nothing yields a 
string that also means nothing.

> Addresses assigned by DHCP in an enterprise environment are 
> identifiers to the granularity of the enterprise, or better. Even 
> addresses assigned by DHCP from a public pool, e.g., at a hotel using 
> wired IP access, are not anonymous of one asks the hotel to map the 
> address used at a fixed time to the occupant of the room in question.  

This all assumes you believe that the other end is using an address that 
they 'own', or was legitimately delegated. If that's the case, we 
wouldn't need protection from spoofing.

> Real anonymity measures of the sort described in the literature, e.g., 
> Onion routing, work to overcome these limitations.

Again, this isn't anonymous forwarding.

> What I think you are really trying to do is to provide a common 
> mechanism (or set of mechanism) that may be used by different protocols 
> to provide authentication of the continuity of repeated communications 
> between parties. 

Yes; a subtle clarification is that this refers primarily to 'repetition 
inside an association', where that association might be for a TCP 
connection, a UDP exchange, etc, but is not necessarily for 'all 
repeated communication between two endpoints', i.e., not necessarily 
shared across connections.

> Since Nicholas cites examples of how he wants to use 
> these mechanisms to provide authenticated channel bindings, it seem 
> likely that any notion of anonymity is not really integral to the 
> mechanisms and scenarios that are "within scope" for the activity.
> 
> Steve

I'm not sure what 'the activity' means here; IMO, channel bindings might 
use ANONSEC, but I don't see any particular coupling between ANONSEC and 
channel bindings.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040914/49c0ae68/signature.bin
From touch at ISI.EDU  Tue Sep 14 09:39:26 2004
From: touch at ISI.EDU (Joe Touch)
Date: Tue Sep 14 09:39:41 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <p06110402bd6c9cfba374@[128.89.89.75]>
References: <[e-mail]>	<p0611042bbd67baaf1392@[128.89.89.75]>	<[e-mail]>	<p06110433bd67ca4dbc81@[128.89.89.75]>	<[e-mail]>	<p06110406bd6b6c552ba6@[128.89.89.75]>	<[e-mail]>	<p0611040dbd6bb70bae4c@[128.89.89.75]>
	<[e-mail]>	<p06110412bd6bcbb28597@[128.89.89.75]>	<[e-mail]>
	<p06110402bd6c9cfba374@[128.89.89.75]>
Message-ID: <[e-mail]>



Stephen Kent wrote:

...
>> So in my construction of ANONSEC anonymity is really always (a).
> 
> I certainly have no objection to your focus, but to call it anonymous 
> communication is not correct.

Anonymous communication is too general a term, and it usually refers to 
anonymous forwarding, such that the source address is meaningless.

There are two kinds of this:
	strong: where the source address is deliberatly meaningless,
		as used by onion routing,
		and other 'anonymous forwarding' systems

	weak: 	where the source address may be spoofed, and since
		you can't know whether it is, you can't rely on it
		for identification; this is the case in the Internet
		today where packets are not authenticated using
		certificate infrastructure.

> I think the term Michael Richardson 
> coined, "opportunistic encryption" is more appropriate, even if the 
> underlying mechanisms differ.

Talk about confusing. There's nothing opportunistic about this, in the 
OE sense - mecahnism or otherwise.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040914/643d6243/signature.bin
From Nicolas.Williams at sun.com  Tue Sep 14 09:58:08 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Sep 14 10:01:43 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]> <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Tue, Sep 14, 2004 at 03:41:00AM -0700, Len Sassaman wrote:
> On Mon, 13 Sep 2004, Nicolas Williams wrote:
> 
> > On Mon, Sep 13, 2004 at 02:41:13PM -0700, Joe Touch wrote:
> > > If you have a specific reason why this is not 'anonymous', please
> > > provide it, esp. in response to my earlier reasons for explaining why it
> > > is anonymous.
> >
> > I'm still struggling with why "ANONSEC" is offensive.  Your answer to
> > the charge is convincing to me.  Perhaps we can have a fun argument at
> > Washington, D.C.  :)
> 
> It isn't offensive; it is simply incorrect. There is an established field
> of study of anonymity in network protocols that spans 25 years, and
> implies something very different than a mere lack of strong
> authentication.
> 
> For a fairly compressive bibliography of research in this area, Roger
> Dingledine maintains a bib file at: http://www.freehaven.net/anonbib/
> 
> What you are describing is non-authentication, or more specifically in
> this context, as the literature describes, "opportunistic encryption".
> This is an important area that must be developed -- the problems you have
> identified, and your goals, are important ones. But they are *different*
> ones than the anonymity systems attempt to solve.
> 
> I think you will have more interest from the network security and
> cryptographic research communities if you name this properly, as people
> will understand what it is that you system is attempting to accomplish,
> instead of complaining that it doesn't do what it says.
> 
> Hope this helps,


First, Joe points out a distinction between "anonymous security" and
"anonymous forwarding."  Perhaps really should view "anonymous" as a
modifier, in this context.

Second, if the point above is unconvincing to you we still have the
problem of consistent use of terminology.  I find that different
organizations, communitities, vendors, customers use different
terminology, and that is often quite vexing -- I wouldn't want to make
matters worse.

If we reject anonymous-as-a-modifier then we're left with arguing over
whose use of "anonymous" takes precedence here.  An argument I'd rather
not have to get into... but let's give it a whirl.  At the IETF
"anonymous" is often used the way it is used in Joe's ANONSEC proposals.
Elsewhere (caveat: see above) it isn't.

If you reject "anonymous" as a modifier, which use of "anonymous" should
this BoF then recognize?  Should the fact that this is a proposed _IETF_
BoF have an effect on this?

BTW, here's an example of an IETF RFC that uses "anonymous," "anon" and
"anonimity" as ANONSEC would: RFC2246 (TLS v1.0).

Other RFCs even have "anonymous" in their _titles_ and use it to mean
"unauthenticated:"  RFC2245 (Anonymous SASL Mechanism) and RFC1635 (How
to Use Anonymous FTP).

I do find Joe's point convincing though, so I think "ANONSEC" makes a
fine BoF name.

Nico
-- 
From Nicolas.Williams at sun.com  Tue Sep 14 10:03:33 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Sep 14 10:07:41 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]> <[e-mail]>
	<p06110412bd6bcbb28597@[128.89.89.75]> <[e-mail]>
Message-ID: <[e-mail]>

On Tue, Sep 14, 2004 at 09:32:51AM -0700, Joe Touch wrote:
> I'm not sure what 'the activity' means here; IMO, channel bindings might 
> use ANONSEC, but I don't see any particular coupling between ANONSEC and 
> channel bindings.

The relationship between the two is this: ease of deployment.  Apps that
use channel bindings don't care about the IDs, if any, authenticated by
the channel being bound to.  Thus having anonymous channels is helpful
in avoiding the need to deploy multiple authentication infrastructures.
From kent at bbn.com  Tue Sep 14 10:46:48 2004
From: kent at bbn.com (Stephen Kent)
Date: Tue Sep 14 10:56:55 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]>	<[e-mail]>
	<p06110412bd6bcbb28597@[128.89.89.75]>
	<[e-mail]>
	<p06110402bd6c9cfba374@[128.89.89.75]> <[e-mail]>
Message-ID: <p06110411bd6cddc4d26e@[128.89.89.75]>

At 9:39 AM -0700 9/14/04, Joe Touch wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature";
>	boundary="------------enigA90A69BAA9A7FFEE6B85380A"
>
>
>
>Stephen Kent wrote:
>
>...
>>>So in my construction of ANONSEC anonymity is really always (a).
>>
>>I certainly have no objection to your focus, but to call it 
>>anonymous communication is not correct.
>
>Anonymous communication is too general a term, and it usually refers 
>to anonymous forwarding, such that the source address is meaningless.

Joe,

you have to look beyond specific mechanisms to understand why they 
are employed, in order to reconcile these terminology issues.

measures to conceal traffic flows are called traffic flow security. 
they are employed to prevent passive wiretappers from learning about 
communications by viewing externally observable characteristics of 
the communications.

anonymous communication measures are designed to conceal the identity 
of communicating parties from passive and active wiretappers. in the 
most stringent cases, the goal is to prevent communicating peers from 
learning the identity of the other.

so, security measures designed to conceal traffic flows become a part 
of anonymous communication systems because failing to conceal traffic 
flows might allow violation of the anonymity guarantees.

Steve
From kent at bbn.com  Tue Sep 14 10:39:10 2004
From: kent at bbn.com (Stephen Kent)
Date: Tue Sep 14 10:56:56 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>	<[e-mail]>
	<p06110423bd67a2bc7691@[128.89.89.75]>
	<[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>	<[e-mail]>
	<p0611040cbd6bb5664b9e@[128.89.89.75]>	<[e-mail]>
	<p06110411bd6bcad8527c@[128.89.89.75]> <[e-mail]>
Message-ID: <p0611040fbd6cdc668059@[128.89.89.75]>

At 9:24 AM -0700 9/14/04, Joe Touch wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature";
>	boundary="------------enig58E714EF6B418D32D79BE91C"
>
>
>
>Stephen Kent wrote:
>
>>>And while I have heard arguments that this is different from 
>>>"spinning IP addresses to provide a sense of privacy", anonymity 
>>>is exactly what is provided when you cannot - and choose not - to 
>>>authenticate the endpoint, regardless of whether the address 
>>>changes or not.
>>
>>Your dismissive view of what constitutes anonymity in Internet 
>>communication runs counter to a fair amount of literature on the 
>>topic.
>
>You and others have confused anonymity in general with anonymous 
>security. This is obviously not anonmyous forwarding; the separation 
>of forwarding and security has come up before.
>
>Joe

Joe,

You made up the phrase "anonymous security" so I guess you are free 
to define it any way you want. But those of us who have long standing 
experience in the security arena find the choice of terms misleading. 
Several folks have mentioned this problem, noting that a lack of 
authentication for a communication is not equivalent to anonymity.

yes, distinctions between forwarding (where you are an expert) and 
security (where I am an expert) have been the source of confusion 
before.  Why perpetuate the problem with this choice of terms?

Steve
From kent at bbn.com  Tue Sep 14 10:46:48 2004
From: kent at bbn.com (Stephen Kent)
Date: Tue Sep 14 10:58:40 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]>	<[e-mail]>
	<p06110412bd6bcbb28597@[128.89.89.75]>
	<[e-mail]>
	<p06110402bd6c9cfba374@[128.89.89.75]> <[e-mail]>
Message-ID: <p06110411bd6cddc4d26e@[128.89.89.75]>

At 9:39 AM -0700 9/14/04, Joe Touch wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature";
>	boundary="------------enigA90A69BAA9A7FFEE6B85380A"
>
>
>
>Stephen Kent wrote:
>
>...
>>>So in my construction of ANONSEC anonymity is really always (a).
>>
>>I certainly have no objection to your focus, but to call it 
>>anonymous communication is not correct.
>
>Anonymous communication is too general a term, and it usually refers 
>to anonymous forwarding, such that the source address is meaningless.

Joe,

you have to look beyond specific mechanisms to understand why they 
are employed, in order to reconcile these terminology issues.

measures to conceal traffic flows are called traffic flow security. 
they are employed to prevent passive wiretappers from learning about 
communications by viewing externally observable characteristics of 
the communications.

anonymous communication measures are designed to conceal the identity 
of communicating parties from passive and active wiretappers. in the 
most stringent cases, the goal is to prevent communicating peers from 
learning the identity of the other.

so, security measures designed to conceal traffic flows become a part 
of anonymous communication systems because failing to conceal traffic 
flows might allow violation of the anonymity guarantees.

Steve
From kent at bbn.com  Tue Sep 14 10:55:28 2004
From: kent at bbn.com (Stephen Kent)
Date: Tue Sep 14 10:58:42 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <p0611042bbd67baaf1392@[128.89.89.75]>
	<[e-mail]>
	<p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]> <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <p06110412bd6cdf1e2378@[128.89.89.75]>

Nicholas,

	<SNIP>

>
>First, Joe points out a distinction between "anonymous security" and
>"anonymous forwarding."  Perhaps really should view "anonymous" as a
>modifier, in this context.

Joe's distinction is not useful because it ignores the larger issue 
of what constitutes anonymity and why we employ specific security 
measures in support of anonymity.

>Second, if the point above is unconvincing to you we still have the
>problem of consistent use of terminology.  I find that different
>organizations, communitities, vendors, customers use different
>terminology, and that is often quite vexing -- I wouldn't want to make
>matters worse.

anything that a vendor says (especially in marketing literature) is 
immediately suspect and should be dismissed :-)

customers are confused about lots of things, so they also don't 
represent an authoritative source for terminology.  how many 
customers think encryption = security, for example?

as I and other have noted, there is a body of literature on this 
topic and that represents the most appropriate basis for deciding 
what terms to use.  I'm not familiar with other standards committee 
venturing into this area.  can you provide some pointers.


>If we reject anonymous-as-a-modifier then we're left with arguing over
>whose use of "anonymous" takes precedence here.  An argument I'd rather
>not have to get into... but let's give it a whirl.  At the IETF
>"anonymous" is often used the way it is used in Joe's ANONSEC proposals.
>Elsewhere (caveat: see above) it isn't.
>
>If you reject "anonymous" as a modifier, which use of "anonymous" should
>this BoF then recognize?  Should the fact that this is a proposed _IETF_
>BoF have an effect on this?
>
>BTW, here's an example of an IETF RFC that uses "anonymous," "anon" and
>"anonimity" as ANONSEC would: RFC2246 (TLS v1.0).

TLS is a session layer security protocol with an inappropriate name, 
so I'm not sure I would give much credence to that example.

>
>Other RFCs even have "anonymous" in their _titles_ and use it to mean
>"unauthenticated:"  RFC2245 (Anonymous SASL Mechanism) and RFC1635 (How
>to Use Anonymous FTP).

Anonynous SASL is a better example that Anonymous FTP, because when 
the latter term was coined, there was no substantial literature on 
the topic.

>I do find Joe's point convincing though, so I think "ANONSEC" makes a
>fine BoF name.

I think it is just as appropriate as TLS  or as the TCP MD5 
"signature" RFC, which describes a message authentication code, not a 
signature :-)

Steve
From Nicolas.Williams at sun.com  Tue Sep 14 12:17:03 2004
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Sep 14 12:21:42 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <p06110412bd6cdf1e2378@[128.89.89.75]>
References: <p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]> <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<p06110412bd6cdf1e2378@[128.89.89.75]>
Message-ID: <[e-mail]>

On Tue, Sep 14, 2004 at 01:55:28PM -0400, Stephen Kent wrote:
> Nicholas,
> 
> 	<SNIP>
> 
> >
> >First, Joe points out a distinction between "anonymous security" and
> >"anonymous forwarding."  Perhaps really should view "anonymous" as a
> >modifier, in this context.
> 
> Joe's distinction is not useful because it ignores the larger issue 
> of what constitutes anonymity and why we employ specific security 
> measures in support of anonymity.

I disagree.  But I wouldn't mind seeing alternative names for "ANONSEC"
-- perhaps there are some really good ones.

BTW, Google searches for "anonymous forwarding" and "anonymous
Diffie-Hellman" (and variations thereof) back up Joe's assertion, even
if one ignores results related to SSL/TLS and vendor documentation/
marketing materials.

> >Second, if the point above is unconvincing to you we still have the
> >problem of consistent use of terminology.  I find that different
> >organizations, communitities, vendors, customers use different
> >terminology, and that is often quite vexing -- I wouldn't want to make
> >matters worse.
[...]
> as I and other have noted, there is a body of literature on this 
> topic and that represents the most appropriate basis for deciding 
> what terms to use.  I'm not familiar with other standards committee 
> venturing into this area.  can you provide some pointers.

I did; you dismiss them.  But it's clear that to a significant subset of
the IETF community "anonymous" as applied to "key exchange,"
"Diffie-Hellman" and so on has the same connotation as the "ANON" in
"ANONSEC," namely "unauthenticated."

(Google searches for "anonymous security," OTOH, mostly return results
that relate to "anonymous forwarding" rather than "anonymous key
exchange...")

We can argue over whether that community uses "anonymous" incorrectly
but even if we accept your assertion to that effect that community will
continue using it that way, in great part because it's so convenient.

> 
> >If we reject anonymous-as-a-modifier then we're left with arguing over
> >whose use of "anonymous" takes precedence here.  An argument I'd rather
> >not have to get into... but let's give it a whirl.  At the IETF
> >"anonymous" is often used the way it is used in Joe's ANONSEC proposals.
> >Elsewhere (caveat: see above) it isn't.
> >
> >If you reject "anonymous" as a modifier, which use of "anonymous" should
> >this BoF then recognize?  Should the fact that this is a proposed _IETF_
> >BoF have an effect on this?
> >
> >BTW, here's an example of an IETF RFC that uses "anonymous," "anon" and
> >"anonimity" as ANONSEC would: RFC2246 (TLS v1.0).
> 
> TLS is a session layer security protocol with an inappropriate name, 
> so I'm not sure I would give much credence to that example.

I think the word "transport" in "Transport Layer Security" would make
more sense if TLS were used the way its original name (SSL) indicated it
was intended to be used: as a [pseudo-]transport protocol that
applications could select, much like TCP, in the sockets APIs.

A little context helps.


> >
> >Other RFCs even have "anonymous" in their _titles_ and use it to mean
> >"unauthenticated:"  RFC2245 (Anonymous SASL Mechanism) and RFC1635 (How
> >to Use Anonymous FTP).
> 
> Anonynous SASL is a better example that Anonymous FTP, because when 
> the latter term was coined, there was no substantial literature on 
> the topic.

Both refer to not authenticating a peer.  So the use of "anonymous"
there is quite consistent.  And that's just the RFCs that use
"anonymous" in their title.

> >I do find Joe's point convincing though, so I think "ANONSEC" makes a
> >fine BoF name.
> 
> I think it is just as appropriate as TLS  or as the TCP MD5 
> "signature" RFC, which describes a message authentication code, not a 
> signature :-)

I'm glad to report that we agree on the TCP MD5 "signature" matter :)

Nico
-- 
From Atul.Sharma at nokia.com  Wed Sep 15 10:33:59 2004
From: Atul.Sharma at nokia.com ([e-mail])
Date: Wed Sep 15 10:40:46 2004
Subject: [anonsec] Opportunistic ANONSEC
Message-ID: <[e-mail]>



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of ext Nicolas Williams
> Sent: Tuesday, September 14, 2004 3:17 PM
> To: Discussions of anonymous Internet security.
> Cc: [e-mail]; [e-mail]; [e-mail]; Joe Touch
> Subject: Re: [anonsec] Opportunistic ANONSEC
> 
> 
> I disagree.  But I wouldn't mind seeing alternative names for 
> "ANONSEC"
> -- perhaps there are some really good ones.
> 

We have had discussion on why or why not Anonymous in ANONSEC
is appropriate for the BoF/WG. But not a single alternative 
was proposed. So I am going to throw some :-)

Since it is about security between entities which either have no IDs
or non-validated IDs, i.e. ID AGNOstic SECurity, how about: 
	IDAGNOSEC :-) AGNOSEC? NOIDSEC?

Atul
From Black_David at emc.com  Fri Sep 17 14:30:28 2004
From: Black_David at emc.com ([e-mail])
Date: Fri Sep 17 14:31:19 2004
Subject: [anonsec] Name for this work
Message-ID: <[e-mail]>

I agree with Steve Kent's statement:

> Since Nicholas cites examples of how he wants to use 
> these mechanisms to provide authenticated channel bindings, it seems
> likely that any notion of anonymity is not really integral to the 
> mechanisms and scenarios that are "within scope" for the activity.

I think there's an important conceptual difference between
unauthenticated (authentication not performed) and
unauthenticatable (authentication can't be performed).

The authenticated channel bindings scenario suggests that
the work currently known as ANONSEC as unauthenticated, but
not unauthenticatable - in the channel binding case, there
will be an authentication that is cryptographically tied to
the unauthenticated key exchange, and a suitably designed
binding can defeat an MITM attack on the unauthenticated
key exchange.  The objections to the use of "anonymous" appear
to be that its usual use in the context of security implies
unauthenticatable (possibly to the point of unidentifiable),
which is definitely not the case here.

"Authentication Agnostic" seems to be a good description
what is intended here, as this work doesn't care what
authentication is performed, or even if any is performed
(cf. "leap of faith").  Unfortunately, that doesn't yield
a pronounceable acronym (AUAGSEC?), and noticing that Au
and Ag are the chemical symbols for gold and silver is
getting entirely too clever ... so perhaps DCAUTHSEC
("Don't Care" [about] Authentication Security)?

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------
From kent at bbn.com  Sun Sep 19 15:50:13 2004
From: kent at bbn.com (Stephen Kent)
Date: Sun Sep 19 17:50:19 2004
Subject: [anonsec] Name for this work
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <p06110406bd73bd7f3549@[10.84.130.23]>

I second David's "authentication agnostic" suggestion. It seems to 
capture the real flavor of what is intended here

Steve
From kent at bbn.com  Sun Sep 19 18:14:37 2004
From: kent at bbn.com (Stephen Kent)
Date: Sun Sep 19 18:16:24 2004
Subject: [anonsec] Opportunistic ANONSEC
In-Reply-To: <[e-mail]>
References: <p06110433bd67ca4dbc81@[128.89.89.75]>
	<[e-mail]>
	<p06110406bd6b6c552ba6@[128.89.89.75]>
	<[e-mail]>
	<p0611040dbd6bb70bae4c@[128.89.89.75]> <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<p06110412bd6cdf1e2378@[128.89.89.75]>
	<[e-mail]>
Message-ID: <p0611040abd73c021d358@[128.89.89.75]>

Nicolas,

	<SNIP>

>BTW, Google searches for "anonymous forwarding" and "anonymous
>Diffie-Hellman" (and variations thereof) back up Joe's assertion, even
>if one ignores results related to SSL/TLS and vendor documentation/
>marketing materials.

Google is not an indicator of correct usage, merely an indicator of 
common usage across a broad range of sources, of varying expertise.

>
>>  >Second, if the point above is unconvincing to you we still have the
>>  >problem of consistent use of terminology.  I find that different
>>  >organizations, communitities, vendors, customers use different
>>  >terminology, and that is often quite vexing -- I wouldn't want to make
>>  >matters worse.
>[...]
>>  as I and other have noted, there is a body of literature on this
>>  topic and that represents the most appropriate basis for deciding
>>  what terms to use.  I'm not familiar with other standards committee
>  > venturing into this area.  can you provide some pointers.
>
>I did; you dismiss them.  But it's clear that to a significant subset of
>the IETF community "anonymous" as applied to "key exchange,"
>"Diffie-Hellman" and so on has the same connotation as the "ANON" in
>"ANONSEC," namely "unauthenticated."

A significant subset of the community does not distinguish encryption 
from security, more generally, or a MAC from a digital signature. 
but, they're still wrong :-)

>
>(Google searches for "anonymous security," OTOH, mostly return results
>that relate to "anonymous forwarding" rather than "anonymous key
>exchange...")
>
>We can argue over whether that community uses "anonymous" incorrectly
>but even if we accept your assertion to that effect that community will
>continue using it that way, in great part because it's so convenient.

If we choose to codify ignorance, we might as well not bother trying 
to be accurate in our work.

	<SNIP>

>  > TLS is a session layer security protocol with an inappropriate name,
>  > so I'm not sure I would give much credence to that example.
>
>I think the word "transport" in "Transport Layer Security" would make
>more sense if TLS were used the way its original name (SSL) indicated it
>was intended to be used: as a [pseudo-]transport protocol that
>applications could select, much like TCP, in the sockets APIs.
>
>A little context helps.

I am completely familiar with the context, having been present at the 
initial meeting that resulted in the ill-named WSG. at best one could 
argue that TLS presents a wrapper for a transport layer below it, 
maybe masquerading as a transport layer protocol to an app. but, 
since it provides session functionality, across TCP connection 
boundaries, it makes more sense to describe it as a session layer 
protocol.

>  > >Other RFCs even have "anonymous" in their _titles_ and use it to mean
>  > >"unauthenticated:"  RFC2245 (Anonymous SASL Mechanism) and RFC1635 (How
>>  >to Use Anonymous FTP).
>>
>>  Anonynous SASL is a better example that Anonymous FTP, because when
>>  the latter term was coined, there was no substantial literature on
>>  the topic.
>
>Both refer to not authenticating a peer.  So the use of "anonymous"
>there is quite consistent.  And that's just the RFCs that use
>"anonymous" in their title.


I'm not sure about SASL, but what FTP does is follow its usual 
authentication procedure. However, it establishes a convention for a 
universally known name-password pair that causes the authentication 
procedure to be useless for access control purposes (the usual 
motivation for authentication). At the application layer where  FTP 
operates, it is reasonable to refer to this as anonymous FTP, because 
the user identity employed is meaningless due to the use of a uniform 
name-password pair.  But, at the network layer, where IPsec operates, 
IP addresses function as identifiers; they are precisely the values 
used by many devices performing access control at the IP layer, e.g., 
firewalls that don't use IPsec. I assume there is no proposal here to 
make use of a single IP address (or pair of addresses) for anonymous 
communication, so the FTP analogy doesn't hold.

Steve
From touch at ISI.EDU  Mon Sep 20 11:01:57 2004
From: touch at ISI.EDU (Joe Touch)
Date: Mon Sep 20 11:02:31 2004
Subject: [anonsec] Name for this work
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>



[e-mail] wrote:

> I agree with Steve Kent's statement:
> 
> 
>>Since Nicholas cites examples of how he wants to use 
>>these mechanisms to provide authenticated channel bindings, it seems
>>likely that any notion of anonymity is not really integral to the 
>>mechanisms and scenarios that are "within scope" for the activity.
> 
> 
> I think there's an important conceptual difference between
> unauthenticated (authentication not performed) and
> unauthenticatable (authentication can't be performed).

What is the difference between these?

If you don't authenticate who you are, then correlations of the ID 
you've used or reused are meaningless anyway.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040920/2da4fbdc/signature.bin
From touch at ISI.EDU  Mon Sep 20 11:04:36 2004
From: touch at ISI.EDU (Joe Touch)
Date: Mon Sep 20 11:05:30 2004
Subject: [anonsec] Name for this work
In-Reply-To: <p06110406bd73bd7f3549@[10.84.130.23]>
References: <[e-mail]>
	<p06110406bd73bd7f3549@[10.84.130.23]>
Message-ID: <[e-mail]>



Stephen Kent wrote:

> I second David's "authentication agnostic" suggestion. It seems to 
> capture the real flavor of what is intended here
> 
> Steve

Agnostic implies 'doesn't care'. While some of the system could be 
useful regardless of which authentication used, I'm not sure that's an 
appropriate implication for the entire system.

What's really being authenticated is, to some extent, behavior, i.e., 
that you're the same party that I've been talking to. Were this really 
agnostic, that might not apply either.

Joe


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040920/ec163800/signature.bin
From Black_David at emc.com  Mon Sep 20 12:39:20 2004
From: Black_David at emc.com ([e-mail])
Date: Mon Sep 20 12:40:27 2004
Subject: [anonsec] Name for this work
Message-ID: <[e-mail]>

Joe,

> > I think there's an important conceptual difference between
> > unauthenticated (authentication not performed) and
> > unauthenticatable (authentication can't be performed).
> 
> What is the difference between these?
> 
> If you don't authenticate who you are, then correlations of the ID 
> you've used or reused are meaningless anyway.

Unauthenticated means no identity was asserted.  It may be possible
to link the resulting security to a subsequent authentication that asserts
an identity, cf. the channel binding scenario.  Unauthenticatable means
that it is impossible to assert an identity, and hence something like
a channel binding is impossible.

If one is only interested in properties of the actual traffic exchanged,
and no subsequent authentication is performed, unauthenticated vs.
unauthenticatable doesn't make much difference.  The major point being
raised by the objectors to "anonymous" is that the usual usage of that
term describes mechanisms in which a subsequent authentication that
is cryptographically bound to the "anonymous" mechanism is impossible,
and that's not what's going on here.

> Agnostic implies 'doesn't care'. While some of the system could be 
> useful regardless of which authentication used, I'm not sure that's an 
> appropriate implication for the entire system.

While perhaps not 100% on the mark, if we contrast this with IPsec,
the big difference is that IPsec key exchange requires IKE authentication
(any color you want as long as it's black ...) whereas this work doesn't
care what authentication is performed, or even if any is performed.
To try to help illuminate this point, for iSCSI, it will make sense
to link an unauthenticated key exchange to a (strengthened) CHAP
authentication.  Of course the resulting security properties (which
may or may not be "useful") depend on whether an authentication is
done and what sort.

> What's really being authenticated is, to some extent, behavior, i.e., 
> that you're the same party that I've been talking to. Were this really 
> agnostic, that might not apply either.

My turn to object to terminology.  If Joe had said "What's really being
assured is, ..." I would agree.  In the absence of an identity it's hard
to claim that what's going on is authentication.  Just to confuse this
further, "leap of faith" mechanisms may implicitly establish an identity
that is authenticated on subsequent interactions, and that may be an
identity for the "behavior".  If we're not careful, this may degenerate
into a discussion of metaphysics.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------
From touch at ISI.EDU  Tue Sep 21 11:02:45 2004
From: touch at ISI.EDU (Joe Touch)
Date: Tue Sep 21 11:05:47 2004
Subject: [anonsec] Name for this work
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>



[e-mail] wrote:
> Joe,
> 
> 
>>>I think there's an important conceptual difference between
>>>unauthenticated (authentication not performed) and
>>>unauthenticatable (authentication can't be performed).
>>
>>What is the difference between these?
>>
>>If you don't authenticate who you are, then correlations of the ID 
>>you've used or reused are meaningless anyway.
> 
> Unauthenticated means no identity was asserted.

Depending on the definition of identity, that may or may not apply here.

I.e., if identity means "known to a third party I trust" or "known to be 
by previous out-of-band communication", then ANONSEC asserts no identity.

However, identity can also mean "is the same party I have been talking 
to on this TCP connection", in which case identity is established by the 
Diffie-Hellman exchange (id = 'someone who has succeeded in doing DE 
with me'), and then continues to mean that throughout that connection.

> It may be possible
> to link the resulting security to a subsequent authentication that asserts
> an identity, cf. the channel binding scenario.  Unauthenticatable means
> that it is impossible to assert an identity, and hence something like
> a channel binding is impossible.

What does "impossible to assert an identity" mean? Identities can be 
local forgeries - e.g., Mickey Mouse - but that's still an identity. 
Even the name "anonymous" is actually a name.

What makes channel binding impossible is the inability to assert 
'identities that are not ensured unique across different instances', but 
all names can have added conditionals, e.g., the name "ANONYMOUS" on 
ports (2254,80), or TCP control block 85, etc.

> If one is only interested in properties of the actual traffic exchanged,
> and no subsequent authentication is performed, unauthenticated vs.
> unauthenticatable doesn't make much difference.  The major point being
> raised by the objectors to "anonymous" is that the usual usage of that
> term describes mechanisms in which a subsequent authentication that
> is cryptographically bound to the "anonymous" mechanism is impossible,
> and that's not what's going on here.

This is an argument that keeps being made, but the distinction isn't 
well defined, or may be impossible to define (because it isn't there? ;-)

What does "subsequent authentication is impossible" mean? Does it mean 
that I cannot - am not willing - to associate different packets of the 
same TCP connection with the same, ongoing endpoint? That conflicts with 
the concept of a TCP connection.

>>Agnostic implies 'doesn't care'. While some of the system could be 
>>useful regardless of which authentication used, I'm not sure that's an 
>>appropriate implication for the entire system.
> 
> While perhaps not 100% on the mark, if we contrast this with IPsec,
> the big difference is that IPsec key exchange requires IKE authentication
> (any color you want as long as it's black ...) whereas this work doesn't
> care what authentication is performed, or even if any is performed.

I care that the other end 'authenticates' via a Diffie-Hellman, i.e., 
that the two ends establish some identity that is used for subsequent 
communication. I still consider that a kind of authentication, albeit 
'nameless'.

> To try to help illuminate this point, for iSCSI, it will make sense
> to link an unauthenticated key exchange to a (strengthened) CHAP
> authentication.  Of course the resulting security properties (which
> may or may not be "useful") depend on whether an authentication is
> done and what sort.
> 
>>What's really being authenticated is, to some extent, behavior, i.e., 
>>that you're the same party that I've been talking to. Were this really 
>>agnostic, that might not apply either.
> 
> My turn to object to terminology.  If Joe had said "What's really being
> assured is, ..." I would agree.  In the absence of an identity it's hard
> to claim that what's going on is authentication.

I'm proving the other end of the connection is 'genuine' (the def. of 
authentication) by defining 'genuine' as 'able to make DE exchanges', 
rather than by defining it via a preshared secret or certificate 
hierarchy. In that way it's authentication of effort or behavior.

While I appreciate that there are terminology issues here, there are 
three separate levels:
	a) basic dictionary meanings
	b) meanings peculiar to a research community
	c) meanings peculiar to the general public when talking
	   about (b)

note that (b) often misuses terms from (a), and (c) misuses terms from 
(b). although I appreciate Steve's note that Google ('c') isn't a good 
place to derive consensus, I'm as unlikely to consider casual misuse by 
particular communities as evidence that the term "anonymous" isn't 
exactly what is both meant, intended, and understood.

> Just to confuse this
> further, "leap of faith" mechanisms may implicitly establish an identity
> that is authenticated on subsequent interactions, and that may be an
> identity for the "behavior". 

I would believe that would be productive; there are systems that develop 
trust over time based on behavior. However, that assumes that the 
separate instances can be correlated - which ANONSEC does not assume.

> If we're not careful, this may degenerate
> into a discussion of metaphysics.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> _______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20040921/3a9af0ad/signature.bin