Subject: Authentication or integrity?

From: Eric Norman <[email-masked]>
Date: Wed, 4 Apr 2001 14:22:57 -0500 (CDT)

I'm still not sure that all this debate about how to authenticate
yourself to a server is addressing the right question.  In my view,
the question is more one of integrity than authentication.  Here's
how I see the problem.  I have a bunch of bits (my credentials)
that I want to store somewhere so that I can load them back into
the same or some other machine later (integrity over time), or that
I want to transfer from one machine to another (integrity over space).

Isn't the question that needs to be answered this:  is the bit
blob that I'm loading today the same as the bit blob that I stored
yesterday?  And since private keys are involved: has anyone else
been able to read and comprehend (part of) that bit blob?

I do not see why this implies that some service needs to know who
I am; all it really implies is that I need to know who I am.
In the physical world, my analogy is a bank of storage lockers
at an airport.  The storage locker doesn't need to know who
you are, all it needs to know is that you can open it.  All you
need to know is to bring the key and to remember the locker's
location (i.e. its name).

Eric Norman

	"Congress shall make no law restricting the size of integers
	that may be multiplied together, or the number of times that
	an integer may be multiplied by itself, or the modulus by
	which an integer may be reduced".

---

From: Menno Pieters <[email-masked]>
Date: Wed, 4 Apr 2001 21:57:37 +0200

At 14:22 -0500 04-04-2001, Eric Norman wrote:
>the question is more one of integrity than authentication.

Well, it is at least *a* right question. Both may be important. 
However, knowing if the data is still valid requires you to have at 
least something to validate the data with (a private key, a checksum, 
etc.). That would result in another problem, a bit like the 'chicken 
and egg' problem, especially in case of a new device to be configured 
using the sacred-server.

>  Here's

Authentication does not mean that the server needs to know who you 
really are, it just means you have some valid means (like a 
username/password combination) to 'prove' your identity, i.e. you are 
the owner of the credentials. Your userid could just be some number 
or a fake name you choose, as long as it uniquely identifies you.

Menno Pieters

<CUT>

-- 
---------------------------------------------------
Menno Pieters
M&I/STELVIO bv - Adviseurs voor Internettechnologie
Postbus 2171             |              Zonnehof 41
3800 CD Amersfoort       |      3811 ND  Amersfoort
The Netherlands
telefoon/phone: +31-33-4.349.340
telefax:        +31-33-4.349.341
XOIP:           +31-20-8.720.349
e-mail          [email-masked]
website         http://www.stelvio.nl/
---------------------------------------------------

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 Apr 2001 23:04:44 +0200 (METDST)

> location (i.e. its name).

The sacred server need to know which locker you want try opening,
so that it can prevent you checking every key from a large keyring
that you brought along.  :)

The risk of largs sacred servers would be that someone will not
try to iterate a spectrum of keys over a fixed locker, but
a fixed key over a spectrum of lockers.  The higher the number
of lockers and the lower the entropy of the key, the  greater
is the chance of succeeding to open an arbitrary locker...

Most online-banking is susceptible to this kind of attack
without ringing alarms ...

-Martin

---

From: Eric Norman <[email-masked]>
Date: Wed, 4 Apr 2001 16:55:29 -0500 (CDT)

> without ringing alarms ...

So if you want to deter or detect brute force attacks on a
username/password authentication mechanism by counting repeated
failures, the suggestion is that it's better to count failures
of the same password instead of the same username?  Interesting.

Eric Norman

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Apr 2001 00:13:32 +0200 (METDST)

> of the same password instead of the same username?  Interesting.

Want I wanted to say is that in order to protect against brute
force, the user needs to supply two pieces of information,
the name of the (user|account|locker) _and_ the password.

While it seems to be obvious for everyone and simple to
implement a protection of brute forcing a particular account,
it seems to be less obvious, less simple and less common
to protect against brute forcing of an arbitrary account.

-Martin