Subject: [anonsec] Name for this work

From: Black_David at emc.com ([email-masked])
Date: Mon Sep 20 12:40:27 2004

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
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue Sep 21 11:05:47 2004

[email-masked] wrote:
> 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

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.

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

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