jtkohl@ATHENA.MIT.EDU (John T Kohl) (05/09/89)
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). 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.] It might be desirable to allow any principal to remotely change its own bit (assuming it is properly authenticated to the KDC). Comments? John Kohl <jtkohl@ATHENA.MIT.EDU> Digital Equipment Corporation/Project Athena
jhs%computer-lab.cambridge.ac.uk@NSFNET-RELAY.AC.UK (Jerome H Saltzer) (05/09/89)
> 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. I presume that the new restriction would be that Kerberos would reject all requests by A to be authenticated to B where B is flagged as a user. The only way to get any data encrypted in B's password would be by claiming to be B and asking for authentication to some (real) service. The proposal seems weird, because it seems to be more or less equivalent to a bald statement that "there is no need for direct user-to-user authentication". Does anyone believe that? Or can it be demonstrated the proposal is not equivalent to that statement? I also worry that it might interfere with another need that we don't have much experience in meeting. A user with a private workstation needs to be able to provide authenticable services--a private data service, or maybe just NFS export of a private file system. At the moment, although the capability is residual within Kerberos, we don't have any good way to administer authentication for a privately delivered service. The proposals to replace the xhost crock also open some of the same issues. There are a couple of ideas kicking around, including a suggestion I made recently about user-created subsidiary principals. Perhaps if we could bring one or more of those user-provided service ideas into a complete scenario, then it would be clear whether or not there is any interference between meeting the requirement of authenticating user-provided services and the idea of distinguishing users from services. Jerry
swick@ATHENA.MIT.EDU (Ralph R. Swick) (05/09/89)
> 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. Hmm. What does "provide direct service" really mean in the long run? Does reading a mail message consisting of credentials and a body encrypted in a session key constitute a "service"? I suspect that a side-effect of this flag will be to increase the size of the db substantially by forcing all users to have two instances; one that provides "service" and correspondingly is denied service by others (authorization again... :-) and one that doesn't. Smells suspiciously similar to public/private key to me.
jtkohl@ATHENA.MIT.EDU (John T Kohl) (05/09/89)
"providing direct service" is not a good way to describe what I meant. What I meant was that if the flag were set for my principal (e.g. joe.foo@realm), no other principal would be able to get a ticket _sealed in joe.foo@realm's key_ authenticating him to joe.foo@realm. This can be separated from the Davis/Swick proposal for presenting two TGT's to the KDC, since in that case the key used for authenticating to joe.foo@realm is the TGT session key, not the private key. The intent here is to reduce the exposure of a user's password-based private key (by using it for encryption) to as few messages as possible. The intent is NOT to interfere with user-to-user authentication. John
jtkohl@ATHENA.MIT.EDU (John T Kohl) (05/09/89)
------- 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
steiner@osf.org (05/09/89)
Perhaps there ought to be pairs of keys - one key for the principal-as-client; the other for principal-as-server. For example, I could have a key K-steiner-c which corresponds to my password and which I use to decrypt ticket replies from the authentication server, and a key K-steiner-s which I use to decrypt tickets from would-be clients of a service I am providing. This way, if someone compromises my K-steiner-s key, they can falsely "authenticate" themselves to me, but they cannot impersonate me. The two keys can be protected at different levels of paranoia accordingly: I don't want to write down my password or store it on disk, but I do want to be able to remember it. My server key, on the other hand, I might be willing to keep in a file, and I don't care if it's hard to remember (it can just be a big random number). Similarly, a server could use one key, K-server-s, to decrypt and verify tickets from prospective clients, and use another key, K-server-c, to obtain tickets for other servers from Kerberos. This might also be useful for peer servers (e.g. two Zephyrs exchanging data, if they authenticated to each other), because they could use different keys depending on who was acting as client (initiator) and who was acting as server (responder). Jennifer
tmal%CL.CAM.AC.UK@MITVMA.MIT.EDU (Mark Lomas) (05/10/89)
In a recent message, Steve Miller commented: > 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. The most important distinction between users and services, from the point of view of security, is that users are notoriously bad at choosing passwords. In an environment which has moderate security requirements, rather than those of military establishments, the DES algorithm is probably adequate for the moment. Provided all keys are well chosen an attacker is unlikely to be able to discover the values of those keys by cryptographic means. I would emphasise the phrase `provided all keys are well chosen'; the DES algorithm is not suitable for encrypting known-plaintext with user chosen keys. In designing an authentication protocol you should be more realistic. Breaking a user chosen key is far easier because a brute-force search doesn't have to test all 256 key values. For example the password scheme supplied with UNIX encrypts known-plaintext using a slight modification of the DES algorithm. It then encrypts the ciphertext using the same key repeatedly until a total of 25 encryptions have been performed. A brute-force search lasting one afternoon determined 10% of the passwords in use at this site; this search was possible because the keys were user chosen, not because the DES algorithm was used. The Kerberos protocol has neither of the features of the UNIX password scheme which were intended to slow down searches so I would assert that searching should be even faster. Do not underestimate the processing resources which an undergraduate could use to determine passwords. I agree whole-heartedly with the suggestion that users and services should be treated differently. Mark Lomas (tmal@cl.cam.ac.uk) University of Cambridge Computer Laboratory
lg@cl.cam.ac.uk (Li GONG) (05/19/89)
Here I'd like to add another reason why I consider distinguishing "users" and "services" is useful. In a recent work at our Lab, a notion of "verifiable-plaintext attacks" was recognised. We proposed a fix using public-key system in one direction, the initial messages from client A and B to server S. If B is a server which has a well-chosen key shared with S, there is no need to use public-key system between B and S. Also the configuration of the authentication protocol (the order of messages) can be different which may make the protocol cheaper. Just simple as that. ____________________________________________________________________________ | Li GONG (+44223-334650) University of Cambridge, Computer Laboratory | | Pembroke Street, Cambridge CB2 3QG, England | | InterNet/CSnet : lg%cl.cam.ac.uk@cunyvm.cuny.edu (or @nss.cs.ucl.ac.uk) | | UUCP : ...!ukc!nss.cs.ucl.ac.uk!cam-cl!lg Bitnet/EAN : lg%cl.cam@ac.uk | ----------------------------------------------------------------------------