Subject: [anonsec] integration of Sam's version with the pre-BOF charter

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 23 Mar 2005 23:04:00 -0800

Hi, all,

The following attempts to incorporate some of the revisions Sam 
suggested, excepting in particular the use of the term "unauthenticated" 
to replace the original "anonymous" (which is the term used more 
commonly to refer to Diffie-Hellman in the absence of signatures), as 
well as retaining the context and motivation of the previous versions of 
the charter.

Joe

----

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: btns-charter-03-23-05.txt
Url: http://www.postel.org/pipermail/anonsec/attachments/20050323/c99fe15b/btns-charter-03-23-05.txt
-------------- 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/20050323/c99fe15b/signature.bin

---

From: Julien.Laganier at Sun.COM (Julien Laganier)
Date: Thu, 24 Mar 2005 11:25:14 +0100

On Thursday 24 March 2005 08:04, Joe Touch wrote:
> suggested, excepting in particular the use of the term
> "unauthenticated" to replace the original "anonymous" (which is the
> term used more commonly to refer to Diffie-Hellman in the absence
> of signatures), as well as retaining the context and motivation of
> the previous versions of the charter.

The proposed charter is fine with me.

--julien

PS: There's a typo in item d) at the end of the text: 
s/anonymou/anonymous

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Thu, 24 Mar 2005 10:18:15 -0500

> well as retaining the context and motivation of the previous versions of 

I support the removal of "anonymous".  it has implications which either
blow up the scope of our work or provide grounds for others not familiar
with how we're using the term to claim we didn't deliver what we
promised.

The primary implication I'm referring to, of course, is the notion that
"anonymous" services provide a way for a peer's identity to remain
unknown to its peers.

This is a very hard problem and is not at all related to the problems
you seem to be interested in securing.

Joe: Can you clarify your objection to "unauthenticated"?   I get the
impression that you're actually looking for integrity-protected but not
authenticated communication..

						- Bill

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 24 Mar 2005 08:07:07 -0800

Bill Sommerfeld wrote:
| On Thu, 2005-03-24 at 02:04, Joe Touch wrote:
|
|
|>The following attempts to incorporate some of the revisions Sam
|>suggested, excepting in particular the use of the term "unauthenticated"
|>to replace the original "anonymous" (which is the term used more
|>commonly to refer to Diffie-Hellman in the absence of signatures), as
|>well as retaining the context and motivation of the previous versions of
|>the charter.
|
|
| I support the removal of "anonymous".  it has implications which either
| blow up the scope of our work or provide grounds for others not familiar
| with how we're using the term to claim we didn't deliver what we
| promised.
|
| The primary implication I'm referring to, of course, is the notion that
| "anonymous" services provide a way for a peer's identity to remain
| unknown to its peers.
|
| This is a very hard problem and is not at all related to the problems
| you seem to be interested in securing.
|
| Joe: Can you clarify your objection to "unauthenticated"?   I get the
| impression that you're actually looking for integrity-protected but not
| authenticated communication..
|
| 						- Bill

The term "anonymous" when applied to Diffie-Hellman is precisely what I
mean, and is the more conventional term in the security literature.

That term is also applied to things beyond keying, such as anonymous web
surfing, email, etc. - which is certainly a different thing.

Unauthenticated isn't appropriate - we may authenticate traffic between
two parties whose identity is not validated by a third party or
preshared secret.

Unauthenticated thus implies that authentication (vs. encryption) is
avoided. That's not the case; it is only the identity that is not
authenticated.

I.e., in both cases there is opportunity for overloaded interpretation,
but anonymous - for this purpose - is more appropriate.

Joe

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Thu, 24 Mar 2005 11:28:00 -0500

>>>>> "Bill" == Bill Sommerfeld <sommerfeld at sun.com> writes:

    Bill> On Thu, 2005-03-24 at 02:04, Joe Touch wrote:
    >> "unauthenticated" to replace the original "anonymous" (which is
    >> the term used more commonly to refer to Diffie-Hellman in the
    >> absence of signatures), as well as retaining the context and
    >> motivation of the previous versions of the charter.

    Bill> I support the removal of "anonymous".  it has implications
    Bill> which either blow up the scope of our work or provide
    Bill> grounds for others not familiar with how we're using the
    Bill> term to claim we didn't deliver what we promised.

I understand Bill's concern.  However I'm actually OK with a charter
either with or without anonymous.

The charter Joe sent to the list is fine with me provided that typos
are fixed.  The charter I sent last night is also fine with me.

I've sent Joe's charter to the IESG and Russ noting that we're likely
to choose something that very much looks like either Joe's charter or
Steve's charter and that anyone with strong opinions should express
them now.

But mainly, I support efficient closure on this issue. :-)

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 24 Mar 2005 09:11:44 -0800

Joe Touch wrote:
| Hi, all,
|
| The following attempts to incorporate some of the revisions Sam
| suggested, excepting in particular the use of the term "unauthenticated"
| to replace the original "anonymous" (which is the term used more
| commonly to refer to Diffie-Hellman in the absence of signatures), as
| well as retaining the context and motivation of the previous versions of
| the charter.

Specific changes:

a) changed unauthenticated back to anonymous
	reasons as noted in my reply to Bill

b) changed the first paragraph mostly back to the pre-BOF version
	Sam's version weakens the motivation that I thought
	was fine - and useful - in the pre-BOF version.
	FYI, most of the differences are in the first half;
	the two versions are more similar after,
	"There is significant interest...".

c) added motivation back to the end of the second paragraph
	"...to enable and encourage", again restoring the context
	beyond basicailly 'where deemed appropriate'

The remainder is as Sam posted, including the milestones.

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 24 Mar 2005 13:46:38 -0500

Joe,

In IPsec, there are two forms of identity that we make use of as an 
input to access control: the IP address of a peer or a symbolic 
identity for the peer. This is reflected in the forms of peer ID that 
are supported in the SPD and in the PAD. We authenticate peers, based 
on one of these two forms of identity, as a precursor to the access 
control decisions that determine what traffic is allowed to flow 
across the IPsec barrier.

Authentication is generically defined as verification of an 
attribute, and more commonly verification of a claimed identity. 
Thus, in the IPsec context, we authenticate a peer's identity either 
as an IP address or as a symbolic name. Thus unauthenticated IPsec 
communication is communication in which IPsec does not verify a 
claimed either of the two forms of identity attributes which we 
otherwise would verify.

This is precisely what we are proposing to explore when we say that 
we will consider accepting self-signed certs or raw keys. The 
identity in a self signed cert might be accurate, and thus provide no 
anonymity ion terms of a symbolic name, but it would be 
unauthenticated in the IPsec context.  The IP address of a peer may 
be accurate, and thus provide no anonymity in terms of that identity 
form, yet if we fail to verify the peer's claim to the address, it is 
unauthenticated i the IPsec context.

These are technically valid reasons for using the term 
"unauthenticated" in the charter, and for not using "anonymous."

The fact that the term "anonymous" often is is used to refer to a D-H 
exchange that does not employ certs is not germane to this 
IPsec-centric discussion. After all, we use precisely this form of 
exchange on IKE today, and then we authenticate the peers. Since we 
are not suggesting a change the D-H part of IKE, only to the later, 
authentication phase, it makes sense to refer to the result as an 
unauthenticated exchange.

The fact than an application may later verify a claimed identity for 
a peer with whom an SA has been created is not relevant to the 
characterization of the IPsec level communication. Moreover, if an 
application does authenticate the peer, then one would hardly refer 
to the overall communication as anonymous at that point!

Finally, long ago we changed the terminology in ESP and AH to refer 
to the service that is provided by the ICV as integrity, not 
authentication. Thus your closing comment about what 
"unauthenticated" implies (vs. encryption) also is not consistent 
with IPsec terminology.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 24 Mar 2005 13:00:34 -0600

> with how we're using the term to claim we didn't deliver what we

Further, we've had this discussion before, and I saw the name change
from "ANONSEC" to "BTNS" as agreement that "anon*" was too confusing or
controversial.  Why can't we just let it be and use "unauthenticated?"

Sure, in some circles "anon*" in the context of Diffie-Hellman refers to
an ephemeral-ephemeral DH exchange that is not authenticated.  But in
other circles "anonimity" refers to privacy protection.  Normally such
differences in terminology don't matter much because the relevant
communities work separately, but here that is not the case.  Oh well.

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 24 Mar 2005 11:18:24 -0800

Stephen Kent wrote:
| Joe,
|
| In IPsec, there are two forms of identity that we make use of as an
| input to access control: the IP address of a peer or a symbolic
| identity for the peer. This is reflected in the forms of peer ID that
| are supported in the SPD and in the PAD. We authenticate peers, based
| on one of these two forms of identity, as a precursor to the access
| control decisions that determine what traffic is allowed to flow
| across the IPsec barrier.
|
| Authentication is generically defined as verification of an
| attribute, and more commonly verification of a claimed identity.
| Thus, in the IPsec context, we authenticate a peer's identity either
| as an IP address or as a symbolic name. Thus unauthenticated IPsec
| communication is communication in which IPsec does not verify a
| claimed either of the two forms of identity attributes which we
| otherwise would verify.

Authentication is used throughout the security community to refer both
to the process of determining the validity of peer's identity as well as
to the process applied to ensure the integrety of data; this terminology
persists in 2401bis-05:

(glossary):
~   Authentication
~      This term is used informally to refer to the combination of two
~      nominally distinct security services, data origin authentication
~      and connectionless integrity.  See the definitions below for each
~      of these services.

Redefining it to mean only one of these in the revised IPsec
documentation is not going to change this ambiguity.

| This is precisely what we are proposing to explore when we say that
| we will consider accepting self-signed certs or raw keys. The
| identity in a self signed cert might be accurate, and thus provide no
| anonymity ion terms of a symbolic name, but it would be
| unauthenticated in the IPsec context.  The IP address of a peer may
| be accurate, and thus provide no anonymity in terms of that identity
| form, yet if we fail to verify the peer's claim to the address, it is
| unauthenticated i the IPsec context.

"might be accurate" is not a useful description of anonymity; it is the
fact that the name is not *known* accurate that means it is, by
definition, anonymous.

| These are technically valid reasons for using the term
| "unauthenticated" in the charter, and for not using "anonymous."
|
| The fact that the term "anonymous" often is is used to refer to a D-H
| exchange that does not employ certs is not germane to this
| IPsec-centric discussion. After all, we use precisely this form of
| exchange on IKE today, and then we authenticate the peers. Since we
| are not suggesting a change the D-H part of IKE, only to the later,
| authentication phase, it makes sense to refer to the result as an
| unauthenticated exchange.

"Unauthenticated" DH, even as used in IKE, is called "anonymous DH" more
commonly in the literature. DH as used in IKE is called "authenticated
DH" in the literature (at least where it isn't called STS), but the
converse is not the common term.

| The fact than an application may later verify a claimed identity for
| a peer with whom an SA has been created is not relevant to the
| characterization of the IPsec level communication. Moreover, if an
| application does authenticate the peer, then one would hardly refer
| to the overall communication as anonymous at that point!
|
| Finally, long ago we changed the terminology in ESP and AH to refer
| to the service that is provided by the ICV as integrity, not
| authentication. Thus your closing comment about what
| "unauthenticated" implies (vs. encryption) also is not consistent
| with IPsec terminology.
|
| Steve

It might be sufficient to clarify "anonymous SA" as omitting the
authentication phase in IKE, referring to the SAs as unauthenticated to
be consistent with IPsec terminology where it specifically applies.
(s/anonymous SA/unauthenticated SA/ in the 2nd, 4th, & 6th paragraphs;
it is already fixed in the 3rd).

In other places, the term is not used in an IPsec-specific way, and is
not inconsistent with IPsec terminology.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 24 Mar 2005 11:22:58 -0800

Nicolas Williams wrote:
| On Thu, Mar 24, 2005 at 10:18:15AM -0500, Bill Sommerfeld wrote:
|
|>On Thu, 2005-03-24 at 02:04, Joe Touch wrote:
|>
|>
|>>The following attempts to incorporate some of the revisions Sam
|>>suggested, excepting in particular the use of the term "unauthenticated"
|>>to replace the original "anonymous" (which is the term used more
|>>commonly to refer to Diffie-Hellman in the absence of signatures), as
|>>well as retaining the context and motivation of the previous versions of
|>>the charter.
|>
|>I support the removal of "anonymous".  it has implications which either
|>blow up the scope of our work or provide grounds for others not familiar
|>with how we're using the term to claim we didn't deliver what we
|>promised.
|
|
| Further, we've had this discussion before, and I saw the name change
| from "ANONSEC" to "BTNS" as agreement that "anon*" was too confusing or
| controversial.

When applied to the term "security", I agree. But not when applied to
the key exchange itself, when it is the term of art.

All these words are overloaded in other areas - as I've noted equally
applies to the term 'unauthenticated'.

IMO, if we're using an existing variant of anonymous DH key exchange, it
is more clear and less confusing to call it what it is already called.

Joe

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Thu, 24 Mar 2005 14:38:34 -0500

> mean, and is the more conventional term in the security literature.

two comments:

 - I recently stumbled across rfc2828, "Internet Security Glossary".
Admittedly it's an Informational document, but it's "one of ours".

 - Both "anonymous" and "unauthenticated" have ambiguity issues.

 - AH was misnamed.  Folks who are being careful tend to use "integrity"
and "confidentiality" to describe the services provided by AH/ESP.

the service that btns seems to want to make optional is the
"identification" part of "authentication"...

						- Bill

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 24 Mar 2005 11:56:45 -0800

Bill Sommerfeld wrote:
| On Thu, 2005-03-24 at 11:07, Joe Touch wrote:
|
|
|>The term "anonymous" when applied to Diffie-Hellman is precisely what I
|>mean, and is the more conventional term in the security literature.
|
|
| two comments:
|
|  - I recently stumbled across rfc2828, "Internet Security Glossary".
| Admittedly it's an Informational document, but it's "one of ours".
|
|  - Both "anonymous" and "unauthenticated" have ambiguity issues.
|
|  - AH was misnamed.  Folks who are being careful tend to use "integrity"
| and "confidentiality" to describe the services provided by AH/ESP.

FWIW, the term integrity is misused as well.

Integrity = unmodified
	E.g., CRCs protect against accidental integrity compromise
	but don't tell you WHO (endpoint address or endpoint identity)
	the data came from, which is why they are subject to
	modification en-route

Authentication = attributable to a source (whether the source's true
	indentity is known or not)

	this implies that the content has integrity protection, but
	integrity alone != authentication (even of just data)

| the service that btns seems to want to make optional is the
| "identification" part of "authentication"...

BTNS would use authenticated or encrypted data with unauthenticated
keys. An unauthenticated key means that the true endpoint identity is
not known, which makes it anonymous.

BTNS *does* want to retain some part of identification - to ensure that
an endpoint doesn't change, regardless of the 'identity' (in
people-terms, "which person" is constant, but "who" is not checked).

Granted that all these terms are being used ambiguously all over the
place, but there has not yet been a successful rescoping of terminology
that both avoids ambiguity and remains accurate.

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 24 Mar 2005 15:45:00 -0500

At 11:18 AM -0800 3/24/05, Joe Touch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Stephen Kent wrote:
>| Joe,
>|

note the term "informally in the definition. note that we explicitly 
moved away from using the term "authentication" to describe the 
service supported by the ICV in AH and ESP a few years ago.

>documentation is not going to change this ambiguity.

I don't share you perception of the ambiguity, and neither do lots of 
other folks who argued with you about this on the list the last time, 
as Nico noted.

>fact that the name is not *known* accurate that means it is, by

my examples show that, in the general case, an unauthenticated SA 
does not provide anonymity.  describing the goal of BTNS as anonymity 
makes no sense, given the reality of the forms of identity with which 
IPsec deals.

>converse is not the common term.

the DH exchange, in isolation is anonymous because the public keys 
are not bound to identities by certs. but we are not addressing the 
DH exchange in BTNS. we are talking about what IKE does and IPsec 
relies upon that provides authentication, and how we plan to remove 
the need for the authentication.

>not inconsistent with IPsec terminology.

BTNS may aspire to be more general than IPsec, but since the 
milestones and deliverables are all IPsec-specific, it makes sense to 
use terminology that is appropriate in the IPsec context.

Steve