WG on anonymous IPSec (fwd from hal@finney.org)) User-Agent: Mutt/1.4.1i Sender: owner-cryptography@metzdowd.com On Sat, Sep 11, 2004 at 11:38:00AM -0700, Joe Touch wrote:
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.
And you cannot determine whether that IP address came from the authentic owner of that address or is spoofed. I'll try to be more careful - you're right, in that it's not anonymous access. It IS anonymous security, though.
I think you are confusing a weak potential for a technical ambiguity of identity under attack conditions with anonymity. (The technical ambiguity would likely disappear in most practical settings). Anonymity implies positives steps to avoid linking with PII. With anonymity you want not just technical ambiguity, but genuinely pluasible deniability from an anonymity set -- preferably a large set of users who could equally plausibly have established a given connection, participated in an authentication protocol etc. We don't after all call TCP anonymous, and your system is cleary _less_ "anonymous" than TCP as there are security mechanisms involved with various keys and authentication protocols which will only reduce ambiguity.
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.
If I know the IP address you used, I still know NOTHING, FWIW. This is no more distinguishable than the port number is in identifying something behind a NAT.
Practically, knowing the IP address conveys a lot. Many ISPs have logs, some associated with DSL subscriber and phone records, for billing, bandwidth caps, abuse complaints, spam cleanup etc etc. The IP may be used for many different logged activities and some of those activites may involve directly identified authentication. People go to lengths to hide their IP precisely because it does typically convey all too much.
And to be clear also anonymous means unlinkable anonymous across multiple connections (which SSH type of authentication would not be)
That might be more specifically "per-connection anonymous", but the term 'anonymous' is too general for that usage. However, there's still nothing associated across connections in ANONSEC, IMO.
You cannot know whether two connections from 10.0.0.1 on two different ports with two different cookies are from the same endpoint. The point of ANONSEC is that you don't care.
If one wants this to be true in practice it has to propogate up the
stack. (Not the problem of ANONSEC, a problem for the higher level
app).
But even at the authentication protocol level one has to be quite
careful. There are many gotchas if you really do want it to be
unlinkable. (eg. pseudo random sequences occur in many settings at
different protocol levels which are in fact quite linkable). I'll
give you one high level example. At ZKS we had software to remail
MIME mail to provide a pseudonymous email. But one gotcha is that
mail clients include MIME boundary lines which are pseudo-random
(purely to avoid string collision). If these random lines are
generated with a non-cryptographic RNG it is quite likely that so
called unlinkable mail would in fact be linkable because of this
higher level protocol. (We cared about unlinkability even tho' I said
pseudonymous because the user had multiple pseudonyms which were
supposed to be unlinkable across).
I would say if your interest in fixing such pseudo random sequeneces
is not present you should not be calling this anonymous.
But if it is part of your threat model, then you may in fact be using
anonymous authentication and that would be interesting to me at least
to participate.
Adam
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
--- end forwarded text
--
-----------------
R. A. Hettinga