Path: utzoo!attcan!uunet!lll-winken!ames!pasteur!ucbvax!decwrl!shelby!ATHENA.MIT.EDU!jtkohl
From: jtkohl@ATHENA.MIT.EDU (John T Kohl)
Newsgroups: comp.protocols.kerberos
Subject: [Steve Miller: RE: Distinguishing "users" and "services"]
Message-ID: <8905091425.AA16385@LYCUS.MIT.EDU>
Date: 9 May 89 14:25:54 GMT
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 63



------- Forwarded Message

Date: Tue, 9 May 89 07:15:56 PDT
From: miller%erlang.DEC@decwrl.dec.com (Steve Miller)
To: jtkohl@ATHENA.MIT.EDU
Subject: RE: Distinguishing "users" and "services"

Re: 

>>From:	DECWRL::"jtkohl@ATHENA.MIT.EDU" "John T Kohl  8-May-89 1436 EDT"  8-MAY-1989 15:07:12.63
>>To:	kerberos@ATHENA.MIT.EDU, krb-protocol@ATHENA.MIT.EDU
>>CC:	
>>Subj:	Distinguishing "users" and "services"
>>
>>Several times in the last year I've been discussing Kerberos and the
phrase "well, if we distinguished between services and users, we could
>>..." popped up (This idea was recently resurfaced by conversations with
>>Jeff Schiller and L. Gong).

We had such a distinction, based on different forms of the name, in an
early pre-release draft of Kerberos, but decided to remove it. It seemed,
and still seems, more appropriate to treat all principals uniformly.
A principal, such as an intermediate service, may concurrently serve both
as a service and a client of another service. It should also be possible
for two users (clients) to directly setup an authenticated communications
session for whatever purpose, such as private communication.

>>I propose allocating a flag bit in the KDC database to indicate that the
>>indicated principal is not allowed to provide direct service, i.e. the
>>TGS will reject any requests to issue a ticket which the principal can
>>decrypt.  This bit, when turned on, means essentially "this is a user".
>>This differentiation between users and services can help plug known
>>plaintext attacks against a user's private key, by preventing an
>>attacker from obtaining a ticket with a large amount of known plaintext
>>encrypted in the private key of the principal under attack.  Combined
>>with some other proposals to modify the response to the initial ticket
>>request, this could reduce a principal's private key exposure to
>>encryption of essentially random data.  [And with the use of some public
>>key cryptography for initial ticket requests, even that could be
>>eliminated.]

The original assumption of Kerberos was not to worry about cryptanalysis,
and I believe that still holds. Despite much criticism of DES, after ten
years there is still no public evidence of vulnerability to cryptanalysis
or any other attack other than brute force. (Maybe NSA and the KGB have
special engines to break it.) So I wouldn't introduce any additional
complexity, user or administrative burden to address cryptanalysis threats.
Lack of secure key storage is a much more fundamental and immediate
problem for current Kerberos implementations. If the ticket format
is rearranged to put less predictable data at the front, as was suggested
in some of the other proposals, I think that is fine- it doesn't effect
users or administrators, but makes cryptanalysis more difficult.
(Changing the ticket layout requires changes in the integrity mechanisms
as well, as has been discussed previously.)

Summary: punt.


Steve

------- End Forwarded Message