Network Working Group RK Smart Internet-Draft CSIRO Expires: June 28, 2000 December 29, 1999 Basic Internet Security Model draft-smart-sec-model-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 28, 2000. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract The first step in creating a secure Internet is to build a model of the security requirements of the real world entities involved and how those real world entities act on the Internet through the agency of networked computers. This document presents a minimal model as a starting point for discussion. In this model: o The real world is composed of entities, each being: (a) an independent legal entity; or (b) a sub-entity of another entity (creating a multi-level hierarchy). o Running code is characterized by: (a) the entity that it acts on behalf of; and (b) the entity that controls the environment in which the code executes. o The environment can run on a bare unmanaged machine or it can be a virtual environment which is code controlled by another entity. Smart Expires June 28, 2000 [Page 1] Internet-Draft draft-smart-sec-model-00 December 1999 Environments thus form another multi-level hierarchy. o We can model communication between machines as a sequence of requests and assertions. The security question becomes: which requests to honour. What is known about the provenance of the requests and assertions is typically crucial. o Security can take place at different network layers and security information must be passed between the layers along with the data. Smart Expires June 28, 2000 [Page 2] Internet-Draft draft-smart-sec-model-00 December 1999 1. The Real World Model In security, as in other matters, there are two different but related aspects: o The real world: unknowable, but no less important for that; o The participants model of the real world. Typically kept in a computer system and built up automatically. The latter is clearly related to the former in important ways. We first build a model of the real world even though that model can never be in any computer. 1.1 Entities There are real world entities which have objectives which they pursue. These are the legal entities which are naturally the main players in our security model. An entity can be clear-cut: an individual or a registered organization. An entity can be more diffuse, as in a set of entities acting together for some common purpose. An entity has to be more than a set of entities defined by a property: the litmus test is that it is reasonable to hold the entity responsible for its actions. These real-world entities often have, or are composed of, sub-entities which pursue sub-objectives. A sub-entity might be a subsidiary organization or an employee or partner, or a computer system. Sub-entities typically don't exist as separate legal entities. To give a concrete example: there is a real-world entity, a person, which we'll call Smart. There is another real-world entity called CSIRO which has an employee sub-entity CSIRO/smart. Now that sub-entity operates using the brain of Smart, with some part of the processing thereof acting on behalf of CSIRO, but remaining under the control of Smart. When the interests of CSIRO and the interests of Smart are not identical then there is a potential security problem here. This is a case of a recurring theme which will be discussed more later. 1.2 Devices The next thing in our model is the computing device. The human brain is one sort we have mentioned. The other sort is an artificial processor with associated memory. The important feature is indivisibility. If information is known to a computing device then it is known to all of it. You can't have two different people controlling the device in such a way that each can keep information Smart Expires June 28, 2000 [Page 3] Internet-Draft draft-smart-sec-model-00 December 1999 within the device which the other can't get at. If such separation is possible then we can look more closely and find 2 (or more) effective devices there. Devices which act independently can be regarded as sub-entities of their owner. Somewhere above a device there should be a legal entity responsible for its actions. Presumably a device acting independently on the Internet without anyone responsible for it represents a security problem in itself, apart from its actions. 1.3 Sub-entities and sub-worlds The real world has autonomous entities and the security issues that we wish to examine arise from the fact that these entities have objectives which are in conflict, or at least not in perfect agreement. Some of those entities, typically organizations, have internal structure composed of sub-entities. In that regard these entities act internally as if they were little worlds of their own. Partly this parallels the full world. Sub-entities have their own goals which may be somewhat in conflict. However there is another problem: the main sub-entities are employees who are also entities in the real world whose interests are not identical with those of the organizational entity. There is a need for the organizational entity to arrange its internal affairs to minimize its dependence on its sub-entities acting in the interests of the organization. That is a rather special security problem which is not incorporated in this basic model: indeed I don't know how it could be. 1.4 Sub-devices and on-behalf-of execution For practical purposes we don't need to distinguish between the owner and the manager of a computing device. We'll use "manager" because it makes more sense as we get to sub-devices. Suppose I log in to a Unix system managed by Ms Root. I seem to be in complete control of a virtual machine, a sub-device, defined by the Unix shell and the extensive and general capabilities it makes available. However in fact Root can alter any of my calculations to give answers that suit her in situations where our objectives are in conflict. In this example my code in the Unix shell acts on my behalf in a machine not under my control. This is an important and recurring theme. There can be further levels of "on behalf of" execution. For example in my Unix shell I could run a java virtual machine and run software obtained from elsewhere on behalf of some external entity. In that Smart Expires June 28, 2000 [Page 4] Internet-Draft draft-smart-sec-model-00 December 1999 case I can interfere with that execution, and of course Root can still do so as well. On Behalf Of execution requires some explicit or implicit requirement from the requester. It doesn't have to be the generality of executing code provided by the requester. The common case is simpler. For example suppose you go to a web page for the yellow pages and search for book stores with some criteria. The code that does the searching acts on your behalf. The manager of the site can cause the response to be skewed to favour some book stores over others, leading you to believe that some bookstores fit your criteria better than they in fact do. This is the typical risk of OBO execution, though of course much worse can happen. 1.5 The logic of On Behalf Of execution Suppose that code C is running On Behalf Of entity X. We say that X is C's OBO. Or OBO(C)==X. If code C is running in Device D then Dev(C)==D. A device typically has a manager and if the manager of device D is Y then we'll write Mgr(D)==Y. A device can be virtual as in a JVM or just a web-based program like the yellow pages. In that case D is just code and we see that OBO(D)==Y. That is Mgr and OBO are really the same. [Footnote: To see why Mgr and OBO are the same consider an example: X is accessing a search engine over the web. The code runs OBO(X). However suppose X now offers a web service which, accesses the search engine and returns a modified version of the returned result to the requester W. This new web service is a device in which W's request runs. However because X controls the device he can affect the returned result. So the OBO becomes an Mgr when the code becomes a service offered elsewhere.] This is always confused in real life by the reality of team management of many devices. This is handled by entities which are sets of other entities acting in concert (at least in the matter of managing the device and probably more widely). If the set of entities controlling a device are not acting in concert then that is a security problem: indeed the most likely way for that to arise is if someone acquires "root" access who isn't meant to have it. The hub of the problem arrives when our code C makes an external request. It might try to use a printer or read a file from a network file system. The external server code, S, has to make an authorization decision. S shouldn't authorize a request from code C just because X Smart Expires June 28, 2000 [Page 5] Internet-Draft draft-smart-sec-model-00 December 1999 [=OBO(C)] is authorized for that action. The obvious reason is that Y [=Mgr(Dev(C))] could easily take advantage of such authorization. So S should only allow the authorization if Y is also authorized for the action. Now if Y is authorized for the action then it can (if it chooses) let X use that authorization. The virtual machine Dev(C) can include an operation that lets X ask Dev(C) to make the request to S using Y's authorization. In the latter case Y might or might not tell S that the operation comes from code running OBO X. [And if Y does tell S that it is being done OBO X then S might or might not take that into account, and if it does take it into account it will only be to reduce S's willingness to perform the action.] If all that sounds a bit strange then it shouldn't. It is exactly the way things work today in many familiar environments. 1.6 Familiar Examples Typically in the computers we use the printing belongs to the system. The might be a permission check when we place a request in a queue, but once it is in the queue then no further checks are done. Placing the request in the queue is an example of a request from X [OBO(C)] to Y [Mgr(Dev(C))] asking Y to perform an action for X. The printer accepts the request once Y has OKed it. This is because the request, in some sense, comes from Y and Y has the required permission. Similarly when we read a file from an NFS mounted file system. The request goes to the operating system. The NFS server wouldn't honour the request at all if it didn't trust the manager of the client machine. However the server needn't completely trust it. NFS servers can work in a mode where a particular machine can only access files that the manager of the system can access. That is they only have Y's level of access to the NFS accessible files, no matter who requests. It is worth looking at how NFS works in this respect because it is not quite right, and this justifies the need to set out our security model carefully. Smart Expires June 28, 2000 [Page 6] Internet-Draft draft-smart-sec-model-00 December 1999 2. Participants Model In the previous section we shifted without much warning from real world people to things happening in computers. How are the two connected? The connection comes inside computers which try to model the real world by collecting information about the real world world: just as humans do. 2.1 Multiple Identities There are various reasons why one real world entity might appear to be several different entities when viewed from another entity's perspective: o Multiple identities preserve anonymity; o Many communications don't require exchanging enough information to allow identification at a later communication (anonymous web browsing being a typical example); o Entities change their identifying information, such as keys and e-mail addresses, and don't inform everyone of that change. o There are different ways to authenticate and they may not be linked. And this is a commonplace from the real world: we talk to someone on the phone, meet someone at a conference, realize eventually that it is the same person. Humans quickly merge the information from the different sources so that where we had two models of people they become one. In a similar way our participants will have objects modelling external entities. From time to time the participant may discover that two are one, or that one is a sub-entity of the other, and adjust their model accordingly. 2.2 Authentication Real world entities have atoms and molecules (typically) but in the world of computers and networks there are only bits. As an introduction here are some example authentication techniques: o A digital signature authenticates an individual message. The authenticator proves that the message was signed by someone in possession of the private key matching the public key of the signature. Smart Expires June 28, 2000 [Page 7] Internet-Draft draft-smart-sec-model-00 December 1999 o In kerberos an end user authenticates themself with a password to a central control: the Key Data Center (KDC). Subsequently requests for services are granted based on tickets obtained from the KDC. Assuming the tickets are held securely by the client the authentication act performed by the KDC identifies the user. o In SSL the user links to an authenticated service, and the subsequent communication with that service is authenticated. This means that the server knows that the client at the beginning of the conversation is still the same as the client later: the session can't be hijacked. This is important if authentication-related information is exchanged at some stage. In every case we have authenticated a set which is defined by the authentication method, and is rather arbitrary in relation to the real world. We know the other end: controls a private key, knows a password, held a continuous conversation with us. For the moment we just accept this. We call the thing authenticated a digital entity and postpone considering the relationship to real-world identities. 2.3 Digital Identities For sub-identities in a sub-world then the digital identity can have many forms. For example a Unix user id in an NIS world or a username in a windows NT domain. In this case we see that the bits which designate a particular digital identity are arbitrarily allocated by a higher authority. Now imagine that you have a system where external users can log in to your web site, as people do to Hotmail, Yahoo or Netcenter. In the registration process the user is given an arbitrary identity. However this identity only has local meaning. You have no way to convince a 3rd party that you are, for example the bob at hotmail. You can send mail that appears to come from "bob@hotmail.com" but apart from the e-mail insecurities that could come from you or from a hotmail administrator. The problem is that for identities, as opposed to sub-identities, there is no higher authority to allocate and adjudicate on arbitrary identification. Luckily the mathematicians have come to the rescue with public key cryptography. 2.4 Public Key With public key cryptography, keys come in pairs: a public key and a private key. The private key can be used to sign "messages" which can be any sequence of bits. Anyone with the public key can verify that the signature comes from the holder of the matching private key (and that the message hasn't been changed). Smart Expires June 28, 2000 [Page 8] Internet-Draft draft-smart-sec-model-00 December 1999 So a public key is an identifier, like a Unix uid, that is created by mathematics rather than authority, and thus exists in the wider world where there is no universal authority. The public key story is somewhat muddied by the fact that there are different sorts of public keys. In addition to the sort for signatures there are ones for encryption and ones for key agreement and there is significant overlap in capabilities. The digital signature type of public key is the sort most strongly connected to authentication and given a signature public key it is easy to use other sorts. For example the following signed statement: "for encryption use encryption public key EPK1" signed PK1 tells people what encryption public key to use for the digital identity specified by the public key PK1. 2.5 Indirect Identity Often others are only interested in an indirect aspect of identity. For example that a person is known to Mastercard who will honour a payment. A way to do this (similar to SET) is for the buyer to encrypt, with the banks encryption public key, information that identifies the buyer to Mastercard. The seller can use that to get a payment guarantee before delivering the goods, and need not know anything about the buyer. This mechanism could be based on a public key belonging to the buyer, or it could be based on a shared secret between the buyer and the bank. From a computer viewpoint there is a clear advantage in the public key based system. In particular it can extend to a universal identity instead of a bank-relative one. Also the private key can be securely locked up - perhaps in a tamper-proof chip from which it can't escape. By contrast the shared secret is a constant security problem. The trouble with private keys is that they are large and cumbersome. They certainly can't be remembered. Shared secrets can be more human: passwords or remembered faces. If remembered then they are more strongly linked to the person than a private key can be. Though a public key is the only universal identity scheme, there is much that can be done in an on-line environment to link indirect identities. Suppose that identity X has digital identity xp with server P and xq with server Q. Suppose that X wants to prove to Q that X is the identity know to P as xp. Using the SET-like technique described above X authenticates to P using an information flow that passes through Q, though any information that X doesn't want to surrender to Q is encrypted so that only P can see it. Q must, of Smart Expires June 28, 2000 [Page 9] Internet-Draft draft-smart-sec-model-00 December 1999 course, see enough to confirm that the authentication was successful. 2.6 Using a digital identity claims real world identity There are lots of forms of digital identity from ip addresses and e-mail addresses to public keys. There is a necessary fact about these, without which we will not be able to reason about security at all: Using a digital identity represents an implicit claim that there is a real world identity behind it. So if you sign something with a private key then it represents a claim that the public key does correspond to an entity which has sufficient coherence to be held responsible for its actions. Similarly if an e-mail address is used as a From address in an e-mail message then this represents a claim that a response message will come back to some one or some thing that is, in some sense, the same as the sender. The exception is if the message explicitly reports the fact that the digital entity is compromised. For example if you discover that someone has acquired a copy of your private key then the logical way to bring that to the attention of other entities is via a message signed by the public key saying "this public key is compromised". It is a notable factor in this sort of message that it doesn't matter if it comes from the original owner or the compromiser: the message is equally true either way. Smart Expires June 28, 2000 [Page 10] Internet-Draft draft-smart-sec-model-00 December 1999 3. Mechanics Digital entities communicate in a series of messages. Some care is needed. For example it is common to assume that a TCP stream has a single other end which can be authenticated once at the beginning. Software that hijacks TCP sessions has shown this to be false. This doesn't mean that every message has to separately authenticated. Setting up cryptographically authenticated streams is usually the efficient and sufficient solution. In a physically controlled part of the network with appropriate filters on incoming packets from the wider Internet, internal packets are secure without any extra mechanism. Without loss of generality we can regard messages sent as being assertions or requests. In real life most messages, such as CORBA method calls or responses, are a mixture of assertions and requests. We can regard these as separated out without implying any need to actually change the way things are done at a low level. So our participant acquires a set of assertions coming in from outside, each labelled with the identity - what our participant knows about it - of the sender. So all the external assertions have the form: asserts As such there is not a lot you can do with it. The pool of information needs to be fleshed out with information supplied by the participant manager. This will be of the form: trust for assertions matching For example trust for assertions matching and this will allow us to treat which are signed by as facts. Now we have something we can reason about. So the idea is that we: o take the external assertions that we've received; o combine with the business logic assertions that we put in; o then decide which requests to honour. Smart Expires June 28, 2000 [Page 11] Internet-Draft draft-smart-sec-model-00 December 1999 The process of deciding is equivalent to proving a theorem. There are problems with decidability. One proposed approach is that the requester supply the proof ("Proof-Carrying Authentication" Appel and Felten). I suspect that as long as there are no universal quantifiers ("for all" or "there exists") in the result to be proved that the problem is tractable in practice. At any rate for the moment we are trying to model existing mechanisms rather than invent new ones, though the model does suggest improved and more general ways to build future mechanisms. The real problem is: How does this all work in the context of multi-level identity and OBO (On Behalf Of) computation? First a clarifying example and an aside. 3.1 Example To clarify the assertion/request distinction consider the IP packet being processed at the Internet software layer. Is this an assertion "This packet is a genuine packet from the source address"? Or is it a request? The answer is the latter. At higher levels it might contain either. But at the Internet (network) layer it just says "Process this packet as per RFCxxx". The distinction is simple: assertions are remembered but cause no other action; requests cause action but leave no memory of themselves as such, though they do have side effects. 3.2 Known versus Provable The following are different things o I know this came from X. o I can prove to a 3rd party that this came from X. Digital signatures give the 2nd but are expensive to implement. Mostly this is unnecessary and we only authenticate to the simpler level. 3.3 Mechanics with OBO Our user code running OBO X is running in environment E (i.e. controlled by E). It wishes to make a request to server S. First the wrong way to do it: Suppose X moves its private key into the E environment so that the code running there can digitally sign a request to S. In that circumstance E can get access to the private key. The set of Smart Expires June 28, 2000 [Page 12] Internet-Draft draft-smart-sec-model-00 December 1999 entities that control the private key now includes E. Of course S might not know that. If S believes an assertion that X is the exclusive owner of the matching public key then it is acting under a misapprehension which E can exploit. This doesn't mean that public key can't be used in an OBO context. A secure approach would be as follows: X in its own environment generates a key pair for use in the E environment and creates a certificate, signed by X (i.e. the public key by which X is known) saying "This public key is controlled by X and used in environments controlled by E". The private key is then used in the OBO X code in the E environment. When a signed request is sent to S the accompanying certificate is sent. This gives the intersection of the rights of E and X: neither X nor E can use the private key to acquire access that they wouldn't otherwise have. One difficulty of this approach is that it may be hard for X to designate E. However the core fact is that the code running OBO X shouldn't have any access rights that E doesn't have. So why not provide a mechanism for X to ask its environment to make the request on X's behalf. E in this context behaves like the operating system, and in fact operating system calls are the most common way that these requests for OBO action are made. The way this is done in practice today is fraught with danger. What is currently done is that E uses its own knowledge to try to work out if X is allowed to make the specified request to S. If E decides that X is allowed to make the request then it sends the request to S as if it came from E without saying that it is being done OBO X. The correct way to do this is: o E decides whether it wants to use its access privileges to make this request OBO X. o If so then E sends the request, but asserting that it is OBO X. Of course the information that it is OBO X should only be used by S to reduce its willingness to honour the request. 3.4 Mechanics with sub-identities Suppose now that our server S is receiving requests from subentities X/a and X/b which are subentities of X. First we note that X/a and X/b don't have all the rights of X itself. For example Boeing might sell you a plane and some sub-entities (employees) of Boeing might be authorized to do that, but certainly not all. Also since X can tell its sub-entities to act for it, there is no sense in giving rights to X/a that wouldn't be Smart Expires June 28, 2000 [Page 13] Internet-Draft draft-smart-sec-model-00 December 1999 granted to X itself. So we see that the rights exercised by sub-entities are subsets of the rights of the entity. By default sub-entities don't have any of the rights of the parent but the parent can grant them rights. One way for this to be done would be for X to issue certificates of the form "X grants sub-entity X/a its rights in the following circumstances". From a legal point of view this, if confirmed, would make X liable for the actions of X/a in those circumstances. The next question is: Does it make sense for S to grant X/a and X/b different rights (in addition to differences specified by X's delegation)? The answer is no. Suppose X/a has a right that X/b doesn't have. If X/b wants to make a request requiring that right then that request must be in the interests of X. So X will make the request itself or instruct X/a to do so. So we see that external entities shouldn't distinguish between sub-entities of another entity, except in accordance with the instructions from the parent. 3.5 Blunt instrument? In the above we assume that identities are completely independent, or they are sub-entities who are completely subservient to the wishes of the parent entity. In the real world we don't see the split between people acting for themselves and people acting as employees in such a clearcut way. However I can't imagine any way to handle computer security other than m this extreme way. Smart Expires June 28, 2000 [Page 14] Internet-Draft draft-smart-sec-model-00 December 1999 4. API Considerations Network data is passed between different software modules. These often correspond to layering of the network. At any rate the mechanisms that transfers the data should also transfer information learnt about the provenance of the data, and other security-related matters, such as what is known about the privacy of the data. In the reverse direction when passing information to be sent it needs to be possible to inquire about security capabilities before passing, and then pass across security requirements when the data is passed. Smart Expires June 28, 2000 [Page 15] Internet-Draft draft-smart-sec-model-00 December 1999 5. Security Considerations The aim of this document is to create a model of the real world and how it interacts with the Internet that may allow the security considerations of Internet standards to be considered in a more consistent and comprehensive way. Author's Address Bob Smart Commonwealth Scientific and Industrial Research Organisation EMail: Bob.Smart@cmis.csiro.au Smart Expires June 28, 2000 [Page 16] Internet-Draft draft-smart-sec-model-00 December 1999 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Smart Expires June 28, 2000 [Page 17]