Subject: RE: The need for two grades of time data.

From: Mathew Butler <[email-masked]>
Date: Thu, 14 Sep 2000 19:10:55 -0700

(Just a note, I prefer to have my name shortened to 'Mat', not 'Matt'.  Is
all okay. :>)

Federal computer systems have the banner that states that activity on those
systems may be monitored, etc.  However, the federal law applies to any
computer system that has any impact at all on interstate commerce.  (Which
is, to be perfectly honest, any system that downloads a single banner ad
from the Web, or any system that is purchased from someone else.)  This is
why the FBI gets involved in prosecuting web site vandalism.

Second, with SSH, the bitstream -is- verified as being from the host in
question.  (Why do you think there are 'host keys'?)  With SSL, the
bitstream -is- verified as being from the host in question.  (Why do you
think there are 'server certificates'?)  SSL is the more applicable standard
here, but it's still a two-way authentication street.

Third, there is a presumption that you are aware of the fact that you're
authorizing whatever digital signature is generated for the purpose that
it's being generated -- in this case, doing something to give you access to
whatever it is that you want access to.  You may not be aware of all the
details, but to expect a common user to be aware of all the details that
we're trying to specify in PKIX is sheer folly.

The act of attempting to authenticate to a remote system is, by its nature,
a non-repudiable act.  (Logs are generated, etc, even for attempts that
provide the wrong authentication token.)  The only difference is that you
are not uniquely identified by your attempt to log in, if you do not use the
signature-generation authority of something that you have agreed uniquely
represents you.  (like a password.)

Nothing is -absolutely- secure.  Smart cards will eventually have exploited
vulnerabilities, as well.  Most users will store their signature keys on
their PC, because it's easier for them.  (Especially since this work cannot
specify 'the key MUST NOT be stored on any computer system that is used for
any other processing', because that's a trust issue and not a validation
issue.)

-Mat Butler

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, September 14, 2000 4:36 PM
To: Mathew Butler
Cc: [email-masked]
Subject: RE: The need for two grades of time data.

Matt,

>Yes, there is.  Under the rules of the US Code of Federal Regulations,
>"Unauthorized access to computer systems shall be a felony."  When you sign
>an authentication challenge with a private key, you're attesting to the
fact
>that you're authorized to use the private key, and that if the signature is
>accepted by the server, you are (to the best of your knowledge) utilizing
>resources which you are authorized to access.

First, I thought this applied only to federal computer systems, but I 
may be wrong. Second,  signing the authentication challenge is not a 
non-repudiable act. The security function is authentication, an input 
to an access control function. There is no presumption that I am 
aware of what is being signed, because it may be (in some protocols) 
random looking data that was generated under the control of the 
system that issued the challenge.  Worse yet, if this is typical, 
one-way authentication, I don't even know that the challenge was 
issued by the system in question.  So, from a technical perspective, 
I'm comfortable that this is not a legally binding digital signature, 
and that position is consistent with our document on technical 
aspects of NR.

>The same could be said of typing a password to a terminal -- "I am
>authorized to use this password, and if you accept this password, I shall
be
>utilizing resources which I am authorized to access."
>
>The problem is, with passwords the user can't truly take due diligence to
>prevent the theft of their authentication credential.  With PK, they can.

In most respects, this is a quantitative difference, not a 
qualitative one. With SSL or SSH, we usually protect the password in 
transit, if we send it as a raw password. Yes, it's true that I never 
need to share a private key with the system to which I authenticate 
myself, but there are numerous password-based schemes that have the 
same property.  So long as we store private keys in software, which 
is common practice, there are many equivalent ways to steal my 
private key or my password from my PC.

The bottom line is that a real time user authentication process is 
characterized by many features that distinguish it from a NR 
signature process.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 15 Sep 2000 12:04:16 -0400

Mat,

>(Just a note, I prefer to have my name shortened to 'Mat', not 'Matt'.  Is

Sorry 'bout that!

>why the FBI gets involved in prosecuting web site vandalism.

OK.

>here, but it's still a two-way authentication street.

The verification for both SSH and SSL is authentication, but not 
non-repudiation. In SSL, client certs are rarely used. Without their 
use, the strong authentication is just one way, from serve to client. 
User authentication, when performed via password, is not even part of 
SSL; no aspect of the protocol addresses password authentication. If 
client certs are used,  the signature generated by the client, which 
covers a hash of handshake messages, would not be my idea of NR. It 
certainly does not provide NR for the later SSL session, where the 
messages are covered by a MAC generated using a symmetric key that is 
SHARED by both ends of the session. Any application data sent to the 
system, after establishment of the secure session, would thus be 
repudiable.

>we're trying to specify in PKIX is sheer folly.

The awareness presumption applied to SSL is rather questionable. If a 
user is issued a client cert for authentication with his browser, he 
activates it, and all others he may have, by entering a password once 
per session. (At least that's the way it work in my version of 
Netscape.) Thus the user could find himself vectored to site B as a 
side effect of visiting site A, and have the browser automatically 
log him into site B, without any explicit user authorization to log 
into site B. Hardly informed consent, right?

>represents you.  (like a password.)

Look at my example above and reconsider the assertion that logon is 
intrinsically an NR act. Logs maintained by the system are NOT a 
sound technical basis for NR, as they could be tamperer with by the 
system. Technical NR mechanisms are based on designs which, in 
principle., preclude manipulation of the NR evidence by the RP.

>any other processing', because that's a trust issue and not a validation

Yes, it's jyst a matter of degree. And, by the way, smart cards HAVE 
been exploited and the exploits have been discussed in the public 
literatire for several years.

Steve