> __________________________________________ > > From: Brian Eaton [mailto:bea...@google.com] > Sent: Thursday, June 02, 2011 3:45 PM > To: Thomas Hardjono > Cc: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 > > On Thu, Jun 2, 2011 at 11:40 AM, Thomas Hardjono <hardj...@mit.edu> > wrote: > Well, not to belabor this point :) but in Kerberos it is the proof of > possession of the client secret key which _is_ the authentication > mechanism. There is also PKINIT (RFC4556) which can be used to "pre- > authenticate" the user via Diffie-Hellman (anonymous) or a full X509 > certificate. > > The kerberos notion of "client" is not the same thing as the OAuth > notion of "client". The "client" in kerberos maps to the OAuth > "user". The "client" in OAuth is the application the user is using. > > Kerberos does not, for example, try to authenticate the kinit > binary. It just tries to authenticate the person using the kinit > binary.
Oh ok, now I get what "authenticating the client" means here. My bad. Perhaps the term "authenticating" is not accurate. Maybe "integrity verification" of client code is a better phrase. And yes, integrity-verification of the kinit binary in MIT Kerberos is not performed prior to execution (in Linux-based systems). Actually, generally speaking integrity-verification of binaries (either in store/disk or during run-time) is not the job of a client code like kinit. The OS should be doing this. Thanks. /thomas/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
