Subject: RE: Authentication or integrity?

From: Mike Just <[email-masked]>
Date: Wed, 4 Apr 2001 15:40:06 -0400

Are you questioning whether the user needs to authenticate to the server
(e.g. provide a password) or simply identify themselves to the server (e.g.
provide their name).  

Regarding the necessity of authentication, I would state the following. A
user will typically only know a password.  I think it is insufficient to
rely on a key generated from a low-entropy password to protect a user's
credentials.  Hence, we also want the server to authenticate the user.  This
ensures that an attacker has to perform an online attack to gain a user's
credentials, as opposed to making the credentials susceptible to an offline
attack.  An online attack is constrained in several ways, including the
number of login attempts (e.g. 5 failed attempts and you're locked out) that
may be made. 

Regarding the use of a name or any identifier, it only serves as an index.
It doesn't have to necessarily identify the user in some other context. 

Mike J. 

> -----Original Message-----
> From: Eric Norman [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2001 3:23 PM
> To: Sacred list
> Subject: Authentication or integrity?
> 
> 
> 
> 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: Eric Norman <[email-masked]>
Date: Wed, 4 Apr 2001 16:09:46 -0500 (CDT)

> (e.g. provide a password) or simply identify themselves to the server (e.g.

Yes, I am questioning that.  I am claiming that I need to prove my
identity to nobody other than myself (which I can do by pinching
myself) in order to know that what I'm reading now (or here) is
identical to what I wrote then (or there).
 
> credentials.

Since all the user has available and knows and can remember is a
(possibly low entropy) password, how can a message that the user
constructs be protected by any more entropy than that?

Eric Norman

---

From: Dale Gustafson <[email-masked]>
Date: Wed, 04 Apr 2001 16:57:00 -0500

Eric Norman wrote:

[snip]

> constructs be protected by any more entropy than that?

The credential is protected by a credential password (password-based-encryption).

The client-server session is protected by an access password (a 2nd layer of pbe)
during transfer from server to client or vice versa.

It is reasonable to assume that credential servers will apply an additional layer
of strong encryption before transfer to long-term storage, split the credential
among several credential stores, etc.

Client software could ensure the use of access passwords with adequate entropy
levels.

---

From: David Jablon <[email-masked]>
Date: Wed, 04 Apr 2001 18:43:01 -0400

Dale,

Your suggestion does not address Eric's question of how a credential
in transit can be protected with *more entropy* than what's in the password.

However, if Dale protects the credential in an encrypted transmission keyed
by a negotiated password-authenticated key (instead of using standard
password-based symmetric encryption), he can get there from here.

Even though the credential stored at the server may be password-crackable,
the transmitted form can be protected with a guaranteed-strong key.

-- David

>Client software could ensure the use of access passwords with adequate entropy

---------------------------------------------------
David P. Jablon
[email-masked]
www.IntegritySciences.com
www.Phoenix.com

---

From: Dale Gustafson <[email-masked]>
Date: Wed, 04 Apr 2001 17:51:56 -0500

David,

> password-based symmetric encryption), he can get there from here.

If by "negotiated password-authenticated key" you mean the symmetric key derived
during the strong-pw exchange then I think we are saying the same thing.  Assuming
your terminology is more accurate, it should be added to the framework definitions.

---

From: David Jablon <[email-masked]>
Date: Wed, 04 Apr 2001 20:01:11 -0400

Dale,

> >Client software could ensure the use of access passwords with adequate entropy

I didn't know if "adequate" meant "strong enough to directly create a PKCS #12 key",
or rather "strong enough to prevent on-line guessing in a well-designed system".

The term "password-based encryption" seems to refer to the common practice
of deriving a symmetric encryption key based on just a password
(e.g. PKCS #5 and PKCS #12).

And now that you mention it, the framework definitions of "Credential formats",
doesn't really distinguish between stored and transmitted formats,
and it doesn't specifically mention the impact of using a low-entropy password
alone to derive a PKCS #12 key.

However, the framework does clearly define "strong password-based protocol", which seems
to be used interchangeably with "strong password algorithm".  (I personally prefer "protocol",
since "algorithm" seems more appropriate for a single party computation.)

But is this clearly distinct from a "strong-password based protocol" (<-- note the hyphen)
which might require large-entropy passwords to work?  I think we have to be careful
because "strong passwords" has been used to refer to either cryptographically-large
passwords or "pretty good" passwords, which has caused quite a bit of confusion
in this field.  "Password-authenticated key negotiation" seems a bit clearer.

-- David

---

From: Dale Gustafson <[email-masked]>
Date: Tue, 10 Apr 2001 10:25:04 -0500

Hi David,

This msg got placed in a drafts folder -- sorry for the late reply.  Comments
inline.

Regards,

--dg

> or rather "strong enough to prevent on-line guessing in a well-designed system".

By "access password", I meant the password used with the strong password
protocol.

Adequate as in "guidelines for selection of passwords".  A server-administered
password policy
that is delivered to and enforced by client software, would be one example of
how this might be
done.  Outside the strong password protocol but related.

> (e.g. PKCS #5 and PKCS #12).

Yes, as defined in PKCS#5.

> alone to derive a PKCS #12 key.

We're assuming PKCS#12 and PKCS#15 as written (e.g., salted password is used to
derive the
credential decryption key).  There has been a suggestion that we need to profile
the credential formats used
which is a very good idea.

I think we tried to distinguish stored from transmitted formats -- we'll clarify
definitions further.

> since "algorithm" seems more appropriate for a single party computation.)

OK, strong password protocol.

> in this field.  "Password-authenticated key negotiation" seems a bit clearer.

We'll add "password-authenticated key negotiation" to the definitions.