Subject: [anonsec] Opportunistic ANONSEC

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu Sep 9 16:15:22 2004

I propose that ANONSEC be a simple profile of IKE[v2] that uses
self-signed non-pre-shared certs for the CERT/AUTH exchanges.

This clearly is workable where two peers' SPDs are statically configured
to allow ANONSEC.

To be workable for opportunistic ANONSEC (meaning: "use ANONSEC if where
peers support it") this approach would require that there be a way for
peers to request/agree to use ANONSEC.

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.

For (a) see Bill Sommerfeld's draft-ietf-ipsp-ipsec-apireq-00.

For (b) I'd propose a new CERT type whose payload is a self-signed cert
and whose use indicates a proposal to do ANONSEC, as well as a new
CERTREQ type whose payload is empty or, optionally, a self-signed cert,
and whose use indicates a proposal to do ANONSEC.

Comments?

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Sep 10 09:14:33 2004

> self-signed non-pre-shared certs for the CERT/AUTH exchanges.

FWIW, ANONSEC (the BOF that we hope to have, and the topic of this 
mailing list) is intended to include IKE mods, as well as mods to other 
Internet security protocols, e.g., TCP-MD5.

Can you explain why certs of any type are needed in this case? It would 
be easier to deploy to avoid the cert issue altogether.

> peers to request/agree to use ANONSEC.

Agreed. That's already been discussed.

> b) provide a way to propose, in the IKE protocol, ANONSEC.

These seem mutually dependent more than just 'not mutually exclusive", IMO.

-------------- 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/0fbc2c3d/signature.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Sep 10 10:18:31 2004

> be easier to deploy to avoid the cert issue altogether.

0) Simplicity.  This approach is very, very simple.

1) We need something that can be reused later for re-keying (including
re-establishing SAs after SA expiration).  Not covering this is really
not acceptable, and making changes to IKE to allow for renewal of
expired SAs goes against (0).

A public key would do, but this leads me to:

2) No need to talk about AUTH with bare keys vs. certs.  We need only
talk about CERT/CERTREQ (see my previous post).

3) Leap-of-faith.  Once you've shared a self-signed cert through ANONSEC
(and better: authenticated it using channel bindings and whatever
authentication you had available) the cert becomes available for
non-ANONSEC purposes.

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.

KISS :)

An alternative to having new CERT/CERTREQ types would be to have a new
ID type to assert the public key of the given cert as the ANONSEC ID.

We need to have the public key as ID for channel bindings to ANONSEC
channels anyways.

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

I could also have apps that set a socket option on their sockets saying
"protect this socket's traffic with ANONSEC if possible, else bypass."

The two are neither mutually exclusive nor mutually dependent.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Fri Sep 10 11:59:28 2004

Nicolas,

	<SNIP>
>software packages already deal just fine in self-signed certs.  See (0)

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>
>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 (Nicolas Williams)
Date: Fri Sep 10 12:25:48 2004

> 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 (Stephen Kent)
Date: Fri Sep 10 13:21:36 2004

>a lesser extent, ANONSEC itself.

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 (Nicolas Williams)
Date: Fri Sep 10 13:37:27 2004

> 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 (Stephen Kent)
Date: Fri Sep 10 14:29:25 2004

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 (Nicolas Williams)
Date: Fri Sep 10 14:50:25 2004

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

> 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 (Francis Dupont)
Date: Fri Sep 10 15:33:33 2004

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 assume there is an API which deals with acceptable cert payload types.
   
Regards

[email-masked]

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Sep 10 15:52:25 2004

> accept raw keys (cert payloads of type 11).

I addressed this already today.  See the archives.

> => 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 (Joe Touch)
Date: Fri Sep 10 16:04:28 2004

Nicolas Williams wrote:

...
> call it something else, which is exactly what you're telling us we

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 (Francis Dupont)
Date: Sat Sep 11 03:16:27 2004

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

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 (Francis Dupont)
Date: Sat Sep 11 03:22:26 2004

=> I saw this but I have to confess I am not convinced by your argument.

Regards

---

From: touch at ISI.EDU (Joe Touch)
Date: Sat Sep 11 10:42:27 2004

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

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.

 > 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: Francis.Dupont at enst-bretagne.fr (Francis Dupont)
Date: Sun Sep 12 01:25:30 2004

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

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

---

From: kent at bbn.com (Stephen Kent)
Date: Mon Sep 13 08:43:37 2004

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

>call it something else, which is exactly what you're telling us we

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 (Nicolas Williams)
Date: Mon Sep 13 09:37:37 2004

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

[Quoting out of order.]
> 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.

> used independent of the rest of IPsec, so there would be no issues re 

Ok, I think we're in agreement here.

[Now on to the rest.]

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

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 (Nicolas Williams)
Date: Mon Sep 13 09:45:58 2004

> authentication by a login/password so we already have enough unsafe

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.

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

> (but not in this list). IMHO one way is to integrate IKE into a

Can you clarify this?

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Sep 13 09:49:34 2004

> => I saw this but I have to confess I am not convinced by your argument.

Can you elaborate?

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon Sep 13 10:13:42 2004

Stephen Kent wrote:

> 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 
> 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 thought "ANONSEC" was a different name than "IPsec" -- what gives?

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

> 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 (Joe Touch)
Date: Mon Sep 13 10:17:55 2004

> a problem... or the total lack of real authentication of ANONSEC more

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.

> successive communications (i.e., like SSL/TLS sessions) this should provide

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

-------------- 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 (Francis Dupont)
Date: Mon Sep 13 10:59:39 2004

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

=> what about KINK? And nobody said IKE is the only way to establish
IPsec SAs forever.

   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.

   
   Can you clarify this?
   
=> can we move to a more appropriate list first? (I suggest the IPsec one)

Regards

---

From: Francis.Dupont at enst-bretagne.fr (Francis Dupont)
Date: Mon Sep 13 11:32:38 2004

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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Sep 13 13:00:35 2004

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

> when the name is kept (i.e., people can still believe it is just

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

> => what about KINK? And nobody said IKE is the only way to establish

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.

> your comment I can't fix anything.

Ok.

> => 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 (Stephen Kent)
Date: Mon Sep 13 14:02:39 2004

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

>>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.
>
>>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 (Stephen Kent)
Date: Mon Sep 13 14:02:40 2004

Nicholas,

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

>be provided by static policies.

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

>ask that IPsec to be applied where the SPD says "bypass."

that would be fine.

>example, but not IPsec, has been extensively deployed.

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

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

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

>(without a PKI, without pre-sharing certs/keys).

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

>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 (Nicolas Williams)
Date: Mon Sep 13 14:32:38 2004

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

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

> causing folks to do something less good than they might otherwise 

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.

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

> it provides some security, but exactly what it provides is more 

More than "some," but, yes.

> The choice of ANONSEC as a title is a bad start in this regard, as 

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 (Joe Touch)
Date: Mon Sep 13 14:33:37 2004

Stephen Kent wrote:
...
...
>> 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 (Joe Touch)
Date: Mon Sep 13 14:41:44 2004

...
> 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 (Nicolas Williams)
Date: Mon Sep 13 14:50:34 2004

> provide it, esp. in response to my earlier reasons for explaining why it 

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 (Stephen Kent)
Date: Mon Sep 13 15:42:40 2004

At 2:33 PM -0700 9/13/04, Joe Touch wrote:
>	boundary="------------enig41CB6D3581A35A4ED9F7924E"
>
>
>
>Stephen Kent wrote:
>...
>>>>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.
>>>
>>>
>>set of mixed messages re what is intended.
>

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 (Stephen Kent)
Date: Mon Sep 13 15:46:38 2004

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 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 :-)
>
>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 (Nicolas Williams)
Date: Mon Sep 13 16:09:42 2004

> the literature, e.g., Onion routing, work to overcome these 

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

> integral to the mechanisms and scenarios that are "within scope" for 

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 (Len Sassaman)
Date: Tue Sep 14 03:41:39 2004

> the charge is convincing to me.  Perhaps we can have a fun argument at

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 (Stephen Kent)
Date: Tue Sep 14 07:14:41 2004

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

>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 (Joe Touch)
Date: Tue Sep 14 09:19:50 2004

> implies something very different than a mere lack of strong

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

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

> 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 (Joe Touch)
Date: Tue Sep 14 09:25:57 2004

Stephen Kent wrote:

> 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 (Joe Touch)
Date: Tue Sep 14 09:33:47 2004

...

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

> 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 (Joe Touch)
Date: Tue Sep 14 09:39:41 2004

Stephen Kent wrote:

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

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 (Nicolas Williams)
Date: Tue Sep 14 10:01:43 2004

> instead of complaining that it doesn't do what it says.

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 (Nicolas Williams)
Date: Tue Sep 14 10:07:41 2004

> use ANONSEC, but I don't see any particular coupling between ANONSEC and 

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 (Stephen Kent)
Date: Tue Sep 14 10:56:55 2004

At 9:39 AM -0700 9/14/04, Joe Touch wrote:
>	boundary="------------enigA90A69BAA9A7FFEE6B85380A"
>
>
>
>Stephen Kent wrote:
>
>...
>>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 (Stephen Kent)
Date: Tue Sep 14 10:56:56 2004

At 9:24 AM -0700 9/14/04, Joe Touch wrote:
>	boundary="------------enig58E714EF6B418D32D79BE91C"
>
>
>
>Stephen Kent wrote:
>
>>>"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.
>>
>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 (Stephen Kent)
Date: Tue Sep 14 10:58:40 2004

Joe,

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Tue Sep 14 10:58:42 2004

Nicholas,

	<SNIP>

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

>terminology, and that is often quite vexing -- I wouldn't want to make

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.

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

>"unauthenticated:"  RFC2245 (Anonymous SASL Mechanism) and RFC1635 (How

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

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 (Nicolas Williams)
Date: Tue Sep 14 12:21:42 2004

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

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

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

> the latter term was coined, there was no substantial literature on 

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.

> "signature" RFC, which describes a message authentication code, not a 

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

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Sun Sep 19 18:16:24 2004

Nicolas,

	<SNIP>

>if one ignores results related to SSL/TLS and vendor documentation/

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

>"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 :-)

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

>applications could select, much like TCP, in the sockets APIs.

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.

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