Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j34I7KV20680 for ; Mon, 4 Apr 2005 11:07:21 -0700 Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id A54ED14C027 for ; Mon, 4 Apr 2005 19:07:14 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A07D0B8822B; Mon, 04 Apr 2005 19:07:14 +0100 Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id 73CB414C027 for ; Mon, 4 Apr 2005 19:07:14 +0100 (IST) Message-ID: <425182F0.9070906@cs.tcd.ie> Date: Mon, 04 Apr 2005 19:09:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.663) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A17D0B8822B Subject: [dtn-security] Thoughts from a phone call today... Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: Since we'd all read & commented Susan's document, Susan, Howie and I had a phone call today to chat about that. (If anyones interested in being part of any future such phone calls, let us know, though we've nothing planned right now.) Subject to Susan or Howie correcting me, I think we more-or- less agreed about the things below. We figured it'd be good to first have whatever discussion (if any) we need on this list and then forward the resulting concensus (if any!) to the main dtn-interest list, since some of these positions do represent changes. After that we can reflect the appropriate changes to the security overview and (TBD) protocol documents and go from there. So, you should comment here if you care about this stuff. (And if you don't: why are you reading this? :-) Anyway here goes:- - We think that whatever security primitives we define ought to be RECOMMENDED to implement and OPTIONAL to use (using RFC 2119 terminology). The main reasons for this are the very constrained hosts that may exist in some networks (e.g. sensor nets) which simply won't be able to implement crypto stuff, but also more practically, the fact that whatever key management scheme you care to define, there'll always be some cases where you can't get the keys in place before you want to send some bundles. - On a related topic, if some DTN nodes which don't implement security (e.g. a collection of sensors) send their bundles via some more capable gateway bundle router, then we believe that that router ought to be able to "turn on" security for those bundles, for both end-to-end and hop-by-hop services. (This is not quite the same as a VPN tunnel, since there is only one "middlebox" which is required.) - Due to the optional nature of security, we believe that each and every bundle router has to at least implicitly make a security policy decision as to how to handle all inbound bundles, and which (if any) security services to apply to outbound bundles. We think the PEP/PDP terminology common in AAA contexts might provide a useful way to think about this. We don't think that there's a need at this stage to define a standard way for DTNs to push/pull policy information around, given that there are standard ways to do that for many lower layers (e.g. RADIUS/DIAMETER/COPS etc.). This also calls into question the "special" category of security policy router, since every bundle router is making security policy decisions, even if for many routers, these are very, very simple ones (e.g. "well-formed=>forward"). - We think that DTNs ought to be able to provide more-or-less the same cryptographic security services as are provided by S/MIME or IPSec, but both for end-to-end and hop-by-hop uses (i.e. using PSH and BAH). In particular we consider that end-to-end confidentiality ought to be a security service that can be provided by DTNs. (If accepted, this would be a change to the status-quo.) - We think that DTN security requires some key management scheme(s) be defined, but we're not sure that it'd be correct to pick one key management scheme and mandate that everywhere, i.e. saying that a kerberos or PKI or IBE based scheme is the one and only correct way to do DTN key managment would be a mistake. However, we also feel that we will need to define at least one key management scheme which is geared towards interoperability, even if this is somewhat at the expense of security! We may end up doing something like what's done with SSH, where initial connections are highly vulnerable against active attacks, but where, if those initial connections were not attacked, subsequent connections can be considered strongly protected. - We still think that reactive fragmentation is a pain, but we can maybe handle it a bit better by having a flexible data structure for BAH which allows for inclusion of multiple authenticators each covering some headers and a (possibly empty) range of payload bytes. [Note: we're not sure where these'd be carried in the bundle.] This represents a slight generalisation of the "toilet paper" solution to reactive fragmentation. - I probably forgot other stuff:-) Stephen. Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j31KHcV13478 for ; Fri, 1 Apr 2005 12:17:38 -0800 Received: from [192.168.0.2] (c-24-5-195-71.hsd1.ca.comcast.net [24.5.195.71]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.4/8.13.3) with ESMTP id j31KHWj6016912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2005 12:17:34 -0800 (PST) Message-ID: <424DAC47.5060001@cs.berkeley.edu> Date: Fri, 01 Apr 2005 12:17:11 -0800 From: Rabin Patra User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org CC: sonesh@eecs.berkeley.edu References: <200503291631.j2TGV9j25051@smtp-bedford-dr.mitre.org> <424C6044.2070703@sparta.com> In-Reply-To: <424C6044.2070703@sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dtn-security] IBC for DTN Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: Hi Howard, Thanks a lot for your comments - my response is below. Meanwhile, a more complete version of the paper is here: http://deccan.cs.berkeley.edu/~rkpatra/cs261/dtnsec/docs/proposal/dtn_ibe.pdf The paper still needs cleanup, it is still a draft. Here is a web page we made for this: http://deccan.cs.berkeley.edu/~rkpatra/cs261/dtnsec/docs/proposal/ It also has comments from people (including Susan). I will also add the recent draft security overview from Susan. Howard Weiss wrote: > > I went thru Rabin's paper and your comments. Nothing I've seen so far > has changed my opinion regarding IBE - I don't think it solves anything > wrt DTN. For example: > > 1. On encrypting a transmission, the source gains a "win" by not having > to cache the destination's public key or consult a certificate > authority. However, the source does have to cache the destination ID > information (which is presumably much smaller than a certifcate but > nevertheless, its infomation that somehow has to be arrived at and > cached). The destination loses because its got to go to a PKG to get > a private key to match the source. I guess the private key could be > cached but there is still a first time penalty. Bottom line: a zero sum > gain. > > 2. On signing, the sender has to obtain a private key for the > destination from a PKG or have the private key already cached. The > destination "wins" by not having to consult with any server to > authenticate. Another zero sum gain. > > One side wins at the expense of the other side. This scheme seems like > it would work well if there are many encrypting sources but few > receivers. The win is that the sources don't have to consult with any > servers (or use precious cache space) before sending. But the > destination has to pay the piper because of the number of private keys > that have to be obtained or cached. Well there could be a difference in total number of key lookups. Suppose there 'n' hosts and they all want to talk to each other. In PKI there would be a total of n^2 public key lookups as each sender now has to lookup all the receivers. In IBE, each receiver has to get its private key only once - so we have around 'n' private keys lookups with the PKG (the trusted key server in IBE). This savings might be important in DTNs. > In either a PKI-like instantiation or an IBE-like instantiation, there > is still a trusted 3rd party server involved that must be consulted. I > can envision ways in a PKI instantiation where there are no servers > (e.g., I only have a DTN CA cert and I need to talk to entity A so I > first send a "hello" to A and attach my public signed by the DTN CA; A > replies with "how are you" and sends its public, also signed by the DTN > CA back to me; now I can send something encrypted - costs one round trip > but does not involve an 3rd party server than could also be a single > point of failure). I can't see how this could be done with IBE - at > least its not clear to me. This roundtrip might not be acceptable in DTNs. Its true that a 3rd party server is needed in IBE, but only to get private keys. Once everybody has their private keys, no round trip is necessary to setup communication. Infact we can send encrypted data to hosts without waiting for them to get private keys first. Even in PKI, you have to get your public key certificate once. Things are more complicated with revocation - which might be a desirable feature for DTNs. PKI supports explicit revocation either by publishing lists of revoked hosts that have to be pushed to all hosts or by requiring an explicit key lookup at the sender side for every send operation - might be difficult in DTNs. With an IBE system, revocation has to be implicit - by requiring hosts to get periodically get new private keys by adding date or time information in the public string. By using hierarchical IBE, hosts need to go only to their local PKG server to get their private keys. Thus, we can bring both the decision making for revocation (which also might be local to the receiver 'region') as well as the private key generation together in time and space. Now senders do not need to bother with any lookups for validation - at the cost of implicit certification of receivers over some time period. We also use the same hierarchy to achieve more fine grained control over revocation. There are still other issues with IBE - for example, hosts cannot generate their own key pairs - thus key escrow, the fact that identities are sort of fixed - cannot be easily changed (unlike public keys in PKI), need to have a common standard for format of the public ID string etc. - Rabin > Howie > > Susan F. Symington wrote: > >> Howie, >> >> I have attached the paper. I had thought it was sent out in >> dtn-interest but I just checked and you are right, it was sent to me >> and two other people. You may want to mention to Kevin to tell Rabin >> to add you to his list so if he ever updates it, you will be included >> in the mailing. >> >> I am also attaching the comments that I sent back to Rabin. >> >> -susan >> >> ------------------------------------------------------------------------ >> *From:* Howard Weiss [mailto:Howard.Weiss@sparta.com] >> *Sent:* Monday, March 28, 2005 5:38 PM >> *To:* Susan F. Symington >> *Subject:* Reference in DTN Security Overview and Motivation >> >> Susan, >> >> I am going through your DTN security overview and motivation and >> came across a reference to a paper: >> >> Patra, R.; "Using Identity Based Crytography for Security in >> DTNs," December 2004. >> >> I haven't seen this - I have only heard Kevin allude to someone >> looking at IBE. If you have it, can you send it to me? >> >> Thanks, >> >> Howie >> >>-- >>Howard Weiss >>SPARTA, Inc. >>7075 Samuel Morse Drive >>Columbia, MD 21046 >>410.872.1515 x201 >>410.872.8079 (fax) >> >> >> >>------------------------------------------------------------------------ >> >>Using Identity based Cryptography for Security in DTNs >>------------------------------------------------------ >> >>This proposal describes an architecture based on Hierarchical Identity Based >>Encryption for providing security features in DTNs. >>The aim is to provide confidentiality and integrity >>for end-to-end communication as well as protection of the DTN >>infrastructure and efficient implementation of access control in a >>heterogeneous environment of hosts having varied connectivity. >> >> >>The requirements for such a security architecture in DTNs are : >>1> Implicit certification: >> This means that a source(A) should be able to encrypt and send a bundle to the >> destination(B) by using only B's public information such that B will be able >> to decrypt the message only if it is currently certified [9]. >> Otherwise, senders will have to explicitly verify the current status of >> receivers (whether their public keys are still valid) from a third-party >> trusted authority. >> - we also don't want senders to store for each possible destination either >> a) a shared private symmetric key or b) a public key >> - third party certification queries may also be difficult in DTN like >> heterogeneous environment where the server that has the ability to certify B >> is in a different administrative region than A. >> - we also want to ensure that no single entity is forced to handle all >> certification queries/requests - this will lead to overload and increased >> latency for queries. >> >>2> Control over revocation over different time scales: >> Implicit certification eliminates the need for the sender to perform >> third-party certificate status queries. But in a DTN heterogeneous >> environment where hosts with different levels of vulnerability might >> exist, we also want allow the system ( or the certificate >> authorities) to choose between between fine grained or coarse grained >> revocation for each host. >> i.e if a user is more trusted, the system might want to re-certify >> keys only every month as opposed to doing it every day. >> >> >>3> Authentication for infrastructure access control: >> As already suggested in [1], bundles should carry two headers i.e PSH that >> is signed by the original source, and BAH that is signed at each hop by the >> sender router. >> Thus we need two different types of authentication mechanisms: >> Router authentication (in BAH): This is used by routers to authenticate >> the previous hop routers. Every router might have its own specific access >> control policy for each router it interacts with. >> Though this implies that it needs to be aware of their identities, >> it can be feasible as the routers might need to know only their >> immediate neighbors in the DTN. >> Source authenticating (in PSH): >> - This is used for end-to-end integrity of the bundles. >> - It is used by the destination host for authentication of the source of bundle. >> - It can also used by routers for global policy access control using >> the identity of source endpoints. As routers cannot be >> possibly be aware of all the sources in the world, it would make more sense >> if these rights are encoded in the credentials (or a certificate) >> presented by the source along with the bundle. >> For example, if a source is given permission to send all its traffic >> in the 'Urgent' class by the system, the all routers need to support this. >> - Instead of using certificates (which can be long) for encoding the >> rights of the source, we want these rights to be encoded in the >> identity of the source endpoint. >> Then a successful authentication of the identity of the >> source should mean that source has obtained that particular identity >> from the system. >> For example: A source 'A' possessing 'Urgent' class would have the >> identity 'A.Urgent'. We need to make sure that these identities can >> only be provided by the system and cannot be forged by some adversary. >> - This would also mean that identities of would have to be part of the >> bundle in the PSH. >> >>4> Complex access control policies: >> As DTNs can conceivably have multiple classes of service, >> we need efficient ways to represent more complex access control policies. >> One way is to support policies over simple boolean expressions. >> For example: for source A: Urgent OR Bulk class traffic. >> >> >>Assumptions and Threat Model: >>----------------------------- >>1> The DTN can have global access control policies that need to recognized by >> all routers in all administrative regions. However routers can have their >> own specific access control policies. (it is not clear if these should be >> allowed to override the former). >>2> There is a set of trusted servers in the DTN that cannot be compromised by >> adversaries. These servers will be used for key issuance, management and >> revocation. >> Other hosts (including routers) in the DTN can be compromised. >>3> Adversaries can eavesdrop on all traffic, they can capture bundles >> and also modify in flight bundles. >> >> >>Types of Attacks: >>1> Routing level attacks : Adversaries on compromising routers can >> can change routing entries to create routing dead-ends or loops. >>2> Infrastructure level attacks: Adversaries can try to access the DTN >> infrastructure without authorization. >> They can try to flood the network or send bundles with >> classes of service that are not allowed. >>3> Data level attacks: Adversaries can eavesdrop on traffic and try to compromise >> the confidentiality and integrity of the bundles in the DTN. >> They can replay bundles. >> >> >> >>Proposal: >>--------- >>The basic proposal is to use a combination of Hierarchical Identity based >>encryption (HIBE) and signatures (HIBS). >> >> >>IBE in brief: >> An Identity Base Encryption (IBE) scheme is a public-key cryptosystem where >> any string is a valid public key. In particular, email addresses and dates >> can be public keys. >> When Alice sends mail to Bob at bob@hotmail.com she simply encrypts her >> message using the public key string ``bob@hotmail.com''. There is no need for >> Alice to obtain Bob's public key certificate. When Bob receives the >> encrypted mail he contacts a third party, the Private Key Generator (PKG), >> Bob authenticates himself to the PKG in the same way he would authenticate >> himself to a CA and obtains his private key from the PKG. >> >> IBE scheme consists of four algorithms: >> (1) Setup: The PKG generates global system parameters and a master-key. >> The global system parameters need to be distributed to all hosts >> initially. >> (2) Extract: The PKG uses the master-key to generate the private key >> corresponding to an arbitrary public key string ID, >> (3) Encrypt: Source(A) encrypts messages using the public key ID of the >> destination, B. >> (4) Decrypt: B decrypts messages from A using the corresponding private key >> that it obtained from the PKG. >> >> IBE has been proven to be secure against chosen cipher-text attacks in the >> random oracle model. >> For more details please refer to [7] >> >> IBE based signatures schemes have also be proposed where the source can >> sign using its private key and the signature can be verified using the >> public ID string. >> >>Hierarchy IBE [9] in brief: >> The main problem of plain IBE where the single PKG has to issue private >> keys for all users is mitigated by creating a hierarchy of PKGs. >> Hierarchy is established in the form of a tree where each >> (and root) node can be a separate PKG. >> The identity of a particular node at level t is given by its >> ID-tuple (ID1,ID2..IDt) where ID_i corresponds to the i-th level node. >> For key extraction, each PKG(root or lower level one) at level t may >> obtain the private keys for its immediate children with ID tuple >> (ID1,ID2..IDt,ID_t+1). >> Encryption and decryption proceed similarly as IBE and the ID Tuple is used >> as the public key. >> Similar scheme can be developed for Hierarchical IB Signatures. >> It is also proven that HIBE is secure against collusion among lower level >> PKG servers. >> >>Bundle Transmission: >>1> The source first uses the destination node's public ID string to encrypt >> the bundle. This cipher-text forms the payload of the bundle. >>2> The PSH is then created over the payload and header (with appropriate >> fields zeroed out) by signing with the >> source endpoint ID ( that encapsulates the requisite access control permissions). >> The integrity can be verified and the source identity can be >> authenticated by all routers. >> This was one of the features desired in [1] (point 12). >>3> The BAH is created at each hop by the sending router. This can be done >> using some other cryptographic scheme (symmetric or assymmetric) also. >> >>Now lets see how the different requirements specified are solved: >>1> Implicit certification: >> As is clear from the basic definition of IBE, a source need not know the >> public key of the destination before sending a bundle. >> The burden of ensuring updated certification now rests on the >> destination that now has to obtain the current valid private key >> to be able to decrypt a received bundle. >> >>2> Use of hierarchy: >> This offers us two advantages: >> a> Efficient key distribution: Normal IBE has only one PKG server which >> possesses the master key. This PKG is responsible for extracting private >> keys of all the users of the system. >> By using hierarchy - a) we can first place local PKGs in every region so that >> destination nodes dont have to go far to get their private keys and >> also b) compromise of a lower level PKG does not compromise the whole >> system (as the master secret resides with the root PKG only). >> The naming scheme in HIBE also derives naturally from the naming in the DTN >> architecture where the endpoint address consists of two parts - region >> ID and the region-specific ID. >> For example: if the endpoint address for Bob is 'bundles://Earth/Bob_IP', then >> a PKG can be placed on Earth with ID:'Earth'. For larger regions, we can >> further create more levels in the hierarchy. >> >> b> Revocation control: >> We do this by creating a sub-hierarchy for each host (in addition to the >> hierarchy over multiple PKGs created for key distribution). >> The levels in this sub-tree would reflect the degree of control desired >> for revocation. Senders will use the ID tuples corresponding to the >> leaves of this tree for encryption. >> As this sub-tree is completely located at a particular >> host, the host can act as a PKG and extract private keys for this tree >> on its own. We can control the leaves for which the host is able to generate >> private keys for itself by providing it private keys for only selected >> internal nodes of this tree. >> For example: the first level could be month, the second level date and >> the third level: hour. Then the ID of a user Bob (in region Earth) would be >> Earth.Bob.May.24.12pm . >> - The Earth region PKG can extract private keys for all IDs of the form >> 'Earth.*'. The Earth PKG can then choose to give Bob the private key >> for 'Earth.Bob' if Bob is a highly trusted user. Now Bob can generate all >> keys of the form 'Earth.Bob.... >> - A less trusted user 'Alice' will be given the private key for >> 'Earth.Alice.Nov' only - this will allow Alice to read messages only for >> month of November. For a bundle encrypted with the full ID string >> Earth.Alice.Nov.25.12pm, Alice will be forced to ask a new private >> key every hour. >> - For more paranoid uses, an extra level of the this tree could be a >> random ID. This would force the receiver to acquire a new private key >> for each bundle it receives. A sender can now encrypt the bundle >> with 'Earth.Alice.Nov.25.12pm.'. >> - A sender that wishes lower security( and lower latency) for a >> session can now encrypt it with 'Earth.Alice.Nov.25.12pm.0000', and Alice >> would have to go to the Earth PKG only once to decrypt this bundle. >> In general, the PKG server responsible for a user needs to compute a >> subset cover over the user subtree i.e the minimum set of nodes that cover >> all the IDs that are allowed and none of the IDs that are not allowed >> for that user. Then it needs to extract private keys for only those >> nodes in the subset cover. >> >> c> Fine grained access control: >> A similar scheme as above can be used for forming ID strings needed for >> authentication and access control as well. >> For this source users sign the bundles with the correct privilege >> desired. For example, if Alice desires 'Urgent' class of service, it will >> need to sign the bundle with the identity 'Alice.Urgent'. For this it >> needs to possess the private key corresponding to 'Alice.Urgent'. >> Possession of a private key corresponding to an identity >> implies that the system also authorized you for the rights that are >> associated with that identity. >> This is possible in IBE because all private keys are generated by the PKGs. >> The same hierarchical ID structure can be used for revocation and >> granting of rights as well. The subtree below each host >> would now represent different privileges. >> For example: A highly valuable Bob can be given access to all classes >> of service by providing the private key for 'Earth.Bob.Nov.25' - Bob can >> then generate keys for 'Earth.Bob.Nov.25.Urgent' etc and use them for >> signing his bundles. >> A less valuable 'Alice' will only be given the private key for >> 'Earth.Alice.Nov.25.Bulk'. >> However this mechanism requires the ID string to be included >> in the bundle header(PSH) for routers to use the correct key >> for authentication. >> This issue was raised in [1] as well for key rollover. >> This overall method of encoding the permissions of the user in the ID >> string is very similar to using accompanying certificates in traditional PKI. >> >>Why not PKI?: >>------------- >>1> Implicit certification is not possible as a source host is forced to >> first acquire the identity(public key) of the destination before sending >> any bundle. It is also forced to check >> whether the destination is currently certified or not by making third-party >> queries. >>2> Revocation is made much difficult in DTN and solutions like maintaining >> a Certificate Revocation List(CRL) does not work for DTNs. >> >>Other issues and Disadvantages: >>------------------------------- >>1> Key escrow: >> In IBE, the PKG can generate private keys for all users and thereby decrypt >> bundles destined for all users. This may not be always desirable. >> A related property is 'non-repudiability' which means that a receiver can >> prove that only the sender could have signed the bundle. >> Also, the compromise of the root PKG jeopardizes the entire system >> and all messages that were sent in the past. >> >>2> Standards issue: >> Since we try to encode revocation control(date etc) and access control >> identifiers in the ID strings, all entities in the DTN need to agree on a >> common format. This is similar to the problem faced in traditional PKI >> over the format of certificates. >> >>3> Distribution of private keys: >> Since users ask the PKGs to generate private keys, they have to be transmitted >> securely from the PKGs. This might mean that the PKGs share another key >> with every user just for the purpose of sending private keys. >> >>5> Distribution of system wide public parameters >> An IBE system installation needs to bootstrap all hosts with >> the public system parameters of the PKG. >> This also might need to be updated if the root PKG is compromised. >> >>6> Replay attacks: >> Although we guarantee confidentiality and integrity, we do not have any >> mechanism to detect and handle replay attacks. >> >>Other options and optimizations: >>-------------------------------- >>1> Use of Certificate Based Encryption [8]: >> The 'key escrow' problem can be solved by using this variation where users >> are allowed to generate their own private keys. >> Senders are now able to user long lasting public keys without the need >> to worry about the current certification status of the destinations. >> This also solves the problem of securely delivering extracted private keys >> to each user. >>2> Reducing overhead of using hierarchical IBE: >> Normal HIBE, both the length of signatures and the number of steps required >> for encryption are proportional to the number of levels in the ID tree. >> Some techniques based on the BGLS aggregated signature scheme can be used >> to reduce the decryption complexity. >>3> If non-repudiability is not desired, them the scheme proposed in [10] can be >> used. Here the the MAC for authentication is same as the cipher-text for >> encryption. It also uses the same public IDs and private keys as the standard >> scheme. So we can get both authentication(+integrity) and secrecy with >> little extra cost. >> >> >>Implementation in DTN2 : >>----------------------- >>1> What are the basic building blocks that need to be supported in the DTN2 >> architecture. >>2> User management: [1] suggested that the DTN agent cannot possess the >> private keys. Applications should store the keys and call external >> entity to perform the encryption. >> >> >> >> >> >> >>References: >>----------- >>[1] Email correspondence on the dtn-interest mailing list >>[2] Draft: "Identity based Encryption for Delay Tolerant Networks" >> A. Chakrabarti and K Fall. >> summary: proposes the use of IBE for both confidentiality as well >> as access control management in DTNs. >>[3] Draft: "A Secure Tetherless Computing Architecture" by S.Keshav et al. >> summary: proposes a hierarchy of PKGs using HIBE and HIBS for efficient >> key management in the TCA. >>[4] "Exploiting Hierarchical IBE for Access Control to Pervasive Computing >> Information" >> Urs Hengartner and Peter Steenkiste >> summary: proposes use of HIBE for both "encryption-based" and >> "proof-based" access control for client-server interactions. >> More emphasis on preventing leakage of information about access control >> policies >>[5] "Hidden Credentials" >> >> summary: use of IBE for hidden credential trust negotiation. >>[6] "Identity based signatures" >> Paterson >> summary: one scheme for signatures based on the Boneh/Franklin scheme. >>[7] "Identity based Encryption based on the Weil Pairing" >> Boneh and Franklin >> summary: this introduces the first concrete IBE scheme. >>[8] "Certificate-Based Encryption and the Certificate Revocation Problem" >> Craig Gentry >> summary: this talks about mitigating problems in IBE by proposing >> Certificate based Encryption(CBE) in which users can choose their own >> private key. >>[9] "Hierarchical ID based Cryptography" >> Gentry and Silverberg >> summary: this extends the Boneh/Franklin IBE scheme >>[10]"Authenticated Identity-based Encryption" >> Ben Lynn >> summary: extends the Boneh/Franklin scheme to provide integrity of the >> message being encrypted. >> >> >> >> >> >>------------------------------------------------------------------------ >> >>Rabin, >> >>Thank you very much for sending me your draft proposal for using IBE for security in DTNs. I appreciate having the opportunity to review it. There are a lot of good things in this paper. Of course, I won't be dwelling on them in my comments, it being the nature of comments to focus on areas that could be improved or clarified. I just want to make clear that my general reaction is very positive before I start pointing out areas that got me thinking. >> >>1. In your "Requirements" section, it seems to me that you have an additional implicit requirement that you really should make explicit, and that is the reuqirement of "Implicit public key distribution". This may seem obvious to someone who has been immersing himself in papers on IBE, but for the rest of us it is a novel concept, and I don't think it should be conflated with the concept of "implicit certification" as it now seems to be. By "Implicit public key distribution" I mean the ability of a user to derive the public key of an arbitrary user from some known information, such as his identity, thus eliminating the need for the user to obtain the public key from a third-party. I think your proposal would be more clear if you were to explicitly list "implicit public key distribution" (or whatever you choose to call it) as a separate requirement. It would also help to clarify the essence of "implicit certification", which is to addresses the issue of how a user who uses a p >>ublic key derived from known information can be sure that the public key is still valid. The concept of getting the public key is separate from the concept of determining that the public key is still valid, and they should be treated as separate concepts. >> >>2. Also in the "Requirements" section (#3, Authentication for Infrastructure access control) you say that you want the source's rights (permissions) to be encoded in the identity of the source endpoint. But the permissions that are being requested are already encoded in the COS field. It seems a waste to also put the COS information in the source ID field. If the public key that is necessary to authenticate the bundle signature consists of a standard string composed of: >>source endpoint id.COS.day/month/year/time(depending on granularity desired) then there is no need to put the COS information in the source ID field. >>By using the COS field as part of the public key encoding, you would have a straightforward mapping between the public key used both to authenticate the bundle and to thereby certify the right of the source to use this class of service, and the class of service rights that the bundle is requesting. This way, only the source ID and the validity period need be encoded in the source ID field. (Also, you may want to consider having the validity period encoded in a separate field of the bundle header rather than encoding it as part of the source ID field.) >> >>3. In your section with the heading "Assumptions and Threat Model:" you have an aside stating that it is not clear if a given router's own specific access control policy should be allowed to override the global DTN access control policies that need to be recognized by all routers. My opinion is that a given router's own access control policy should be allowed to be more restrictive than the global access control policy, but it should not be allowed to be less restrictive than the global access control policy. In other words, all routers should be able to depend on all DTN bundle agents to enforce a given level of access control in determining what traffic they admit to the DTN from DTN applications; if a given router wants to be more restrictive on a given link within the DTN, that's its prerogative, and it should be able to do so (in fact, as I see it, the ability to be more restrictive is the whole point of having security policy routers). >> >>4.In the "Types of Attacks" section you mention that adversaries may create routing loops. It should be noted that this is a problem that we have not yet addressed. Right now we don't have a way in the protocol to detect such an attack, and we don't really plan to be able to detect replays, so it isn't clear if or how we are planning to address this threat. >> >>5. In the "Bundle Transmission" section, step 2 does not make sense to me, and I think it may be an error that needs correcting. You say that the PSH is signed with the source endpoint ID. Don't you mean that it is signed with the PRIVATE KEY that corresponds to the source endpoint ID (and, if you accept my suggestion in item 2 above, it would be the private key that corresponds to the string formed by "source endpoint ID.COS.validity_time_period")? Then, any receiver can authenticate the source identity and its permissions by using the public key that is derived from the source endpoint id (or that may be exactly the source endpoint ID). >> >>It should be noted (assuming I am understanding it correctly) that for any given validity time period, a single source may need to have as many as n private keys, where n is the number of different classes of service that can be represented. >> >>6. In the "Bundle Transmission" section, step 3 surprises me. Don't you want to make a suggestion about how the BAH should be authenticated, or are you just leaving this for a later paper? If you are going to leave it out, which would be fine, then you should probably go back and refocus the paper to make it clear that you are really "only" addressing the end-to-end confidentiality and integrity security features of DTNs as provided by the PSH and "efficient implementation of access control in a heterogeneous environment of hosts ..." as provided by the PSH, but that discussion of infrastructure protection isn't within the scope of this paper. >> >>7. In your "Now lets see how the different requirements specified are solved:" section, you don't step through all the requirements that you originally proposed. This sort of thing causes those of us who are obsessive compulsive to develop all sorts of ticks and twitches. Addressing each requirements as it was originally raised would give readers like me just the sort of false sense of security that I need to sleep well at night. >> >>8. In item 1 (Implicit certification) of the "Now lets see how the different requirements specified are solved:" section, you say that "a source need not know the public key of the destination before sending a bundle". I think you really mean two things (and this goes back to my suggestion that you separate the concepts of key distribution from key certification). I think you mean: >> a) a source need not "look up" (as opposed to "know") the public key of the destination, and >> b) a source need not obtain a destination's certification status before sending encrypted data to the destination as the bundle payload. >> >>9.In the "b> Revocation control:" section, it is worth noting (if I understandthe proposal correctly and completely) that the revocation mechanism being used is key expiration. There is no way to explicitly invalidate or revoke a private key from a user at an arbitrary time, once the key has been given to the user. Therefore, if a user Alice has been given a private key corresponding to the public key "Alice.October", this key will continue to work through midnight on October 31, even if this key is compromised on October 1. For 30 more days, sources sending to Alice will encrypt bundle payload destined for Alice and send it to her thinking that its confidentiality is being protected even though it isnt. Therefore, the selection of the duration of a key's validity time period is an important choice and it would be good to make this clear to the reader. >> >>Also, it isn't clear what the relationship is between the key's validity time period and the current real-world time. Is this relationship checked at the sender or at the recipient, or both? And how exactly is it checked? For example, >>If the current month is March, will a sender be allowed to encrypt a bundle that is being sent to Alice using the public key Alice.April? How about using the public key Alice.February? >>It seems that if the current month is March, senders should not be allowed to encrypt a bundle that is being sent to Alice using the public key Alice.February because the Alice.February key has expired and therefore it cannot be assumed to be safe to use it. >> >>If Alice receives a bundle in the month of April but the bundle had been encrypted during the previous month, with the Alice.March key (which may very well happen in DTN), then what should Alice do? If she has cached the Alice.March key, then she will be able to decrypt the message, but should she? is her private key still valid? >> >>In other words, validity time periods may be such that a message that is sent during a validity time period will not be received until after that period is over. How should this be dealth with? >> >>10. In the "Why not PKI?:" section, I am not convinced by your argument that the IBE scheme is better than the PKI scheme because when using PKI, the source host is forced to check whether the destination is currently certified or not by making third-party queries before it can send an encrypted bundle to the destination. (This is related to my comment in 9 above.) In a PKI scheme, when a source receives a destination's public key from the CA, can't that key come with a validity period, that says the key is good for the month of October, for example, and then it expires after that. If so, the source would not have to check the validity of that key before using it anytime during the month of October. The result is very similar to the result you get when using the IBE scheme using the sub-hierarchy scheme that corresponds to the month/day/hour of validity. In this respect, I don't see how the IBE scheme is any better than a PKI scheme that issues keys with validity time perio d >>s. Am I missing something? Both schemes seem to suffer from the fact that explicit revocation is not possible, making it impossible to revoke a certificate before its intended expiration date. At least in the PKI scheme it would be possible for a sender to query the CA to inquire whether the public key is still valid. There does not seem to be any analogous way for a sender using IBE to make such a query. To be safe, the user would have to use a random ID field in the ID string, in effect requiring a new public key to transmit each bundle (and therefore a new private key to decrypt each bundle). Distribution of the private key from the PKG to the DTN node is a not without its costs. Is there really an advantage to IBE over PKI in the respect that you mention in this section and, if so, can you please state it more clearly? >> >>11. In general, the paper would benefit if you were to make a more clear separation between the use of (and benefits of using) IBE for encrypting data versus for authenticating data, because those two operations are essentially the inverse of each other and they may be performed simultaneously on a given bundle sent in DTN. If the application data unit is encrypted and the bundle is signed using the PSH, then it isn't clear how the necessary public key and key validity information for both keys would be conveyed from source to destination. Your proposal talks of using the source ID field to convey the information necessary for the recipient to obtain the public key required to verify the bundle's PSH signature. How would the recipient know how to obtain the appropriate private key that it would also need to decrypt the application protocol data unit (APDU)? For example, if I understand your proposal correctly: >> >>On a bundle sent from Bob to Alice: >> >>Bob encrypts the APDU using the public key Alice.October and >>Bob signs the bundle (in the PSH) with the private key corresponding to Bob.October.25.Urgent >> >>Upon receipt of the bundle, Alice would first use the public key Bob.October.25.Urgent to verify the signature in the PSH. Assuming the signature verified correctly, Alice would now get from her PKG (if she doesn't already have it) the private key corresponding to Alice.October and use it to decrypt the APDU. >> >>According to your proposal, the source ID has the information "Bob.October.25.Urgent" in it, so this is how Alice knows what public key to use to verify the signature in the PSH. How does Alice know that she needs the Alice.October private key (as opposed to the Alice.October.25 private key) to decrypt the APDU? Is this string merely put into a new encryption keyID field that is carried in the bundle header? >> >>12. I hope IBE really woudl be secure in a DTN application and that that it will stand up to the test of time and increased scrutiny. It seems to be a genuine breakthrough that lots of folks have latched onto, but I don't feel qualified to make a judgement on its technical merits. Given that it hasn't had the scrutiny of PKI, I think it's important that DTN be designed so that it will work with both PKI and IBE. We need to be careful to define the protocols so that they don't have any hidden dependencies on the use of IBE. >> >>13. What about implementing IBE. Are there any implementations readily available that can be used with DTN2 or will this be something that will require a lot of development? >> >>Again, thanks for the opportunity to review this. I hope my comments help. >> >>-susan >> >>*********************************************************************** >> >>Using Identity based Cryptography for Security in DTNs >>------------------------------------------------------ >> >>This proposal describes an architecture based on Hierarchical Identity Based >>Encryption for providing security features in DTNs. >>The aim is to provide confidentiality and integrity >>for end-to-end communication as well as protection of the DTN >>infrastructure and efficient implementation of access control in a >>heterogeneous environment of hosts having varied connectivity. >> >> >>The requirements for such a security architecture in DTNs are : >>1> Implicit certification: >> This means that a source(A) should be able to encrypt and send a bundle to the >> destination(B) by using only B's public information such that B will be able >> to decrypt the message only if it is currently certified [9]. >> Otherwise, senders will have to explicitly verify the current status of >> receivers (whether their public keys are still valid) from a third-party >> trusted authority. >> - we also don't want senders to store for each possible destination either >> a) a shared private symmetric key or b) a public key >> - third party certification queries may also be difficult in DTN like >> heterogeneous environment where the server that has the ability to certify B >> is in a different administrative region than A. >> - we also want to ensure that no single entity is forced to handle all >> certification queries/requests - this will lead to overload and increased >> latency for queries. >> >>2> Control over revocation over different time scales: >> Implicit certification eliminates the need for the sender to perform >> third-party certificate status queries. But in a DTN heterogeneous >> environment where hosts with different levels of vulnerability might >> exist, we also want allow the system ( or the certificate >> authorities) to choose between between fine grained or coarse grained >> revocation for each host. >> i.e if a user is more trusted, the system might want to re-certify >> keys only every month as opposed to doing it every day. >> >> >>3> Authentication for infrastructure access control: >> As already suggested in [1], bundles should carry two headers i.e PSH that >> is signed by the original source, and BAH that is signed at each hop by the >> sender router. >> Thus we need two different types of authentication mechanisms: >> Router authentication (in BAH): This is used by routers to authenticate >> the previous hop routers. Every router might have its own specific access >> control policy for each router it interacts with. >> Though this implies that it needs to be aware of their identities, >> it can be feasible as the routers might need to know only their >> immediate neighbors in the DTN. >> Source authenticating (in PSH): >> - This is used for end-to-end integrity of the bundles. >> - It is used by the destination host for authentication of the source of bundle. >> - It can also used by routers for global policy access control using >> the identity of source endpoints. As routers cannot be >> possibly be aware of all the sources in the world, it would make more sense >> if these rights are encoded in the credentials (or a certificate) >> presented by the source along with the bundle. >> For example, if a source is given permission to send all its traffic >> in the 'Urgent' class by the system, the all routers need to support this. >> - Instead of using certificates (which can be long) for encoding the >> rights of the source, we want these rights to be encoded in the >> identity of the source endpoint. >> Then a successful authentication of the identity of the >> source should mean that source has obtained that particular identity >> from the system. >> For example: A source 'A' possessing 'Urgent' class would have the >> identity 'A.Urgent'. We need to make sure that these identities can >> only be provided by the system and cannot be forged by some adversary. >> - This would also mean that identities of would have to be part of the >> bundle in the PSH. >> >>4> Complex access control policies: >> As DTNs can conceivably have multiple classes of service, >> we need efficient ways to represent more complex access control policies. >> One way is to support policies over simple boolean expressions. >> For example: for source A: Urgent OR Bulk class traffic. >> >> >>Assumptions and Threat Model: >>----------------------------- >>1> The DTN can have global access control policies that need to recognized by >> all routers in all administrative regions. However routers can have their >> own specific access control policies. (it is not clear if these should be >> allowed to override the former). >>2> There is a set of trusted servers in the DTN that cannot be compromised by >> adversaries. These servers will be used for key issuance, management and >> revocation. >> Other hosts (including routers) in the DTN can be compromised. >>3> Adversaries can eavesdrop on all traffic, they can capture bundles >> and also modify in flight bundles. >> >> >>Types of Attacks: >>1> Routing level attacks : Adversaries on compromising routers can >> can change routing entries to create routing dead-ends or loops. >>2> Infrastructure level attacks: Adversaries can try to access the DTN >> infrastructure without authorization. >> They can try to flood the network or send bundles with >> classes of service that are not allowed. >>3> Data level attacks: Adversaries can eavesdrop on traffic and try to compromise >> the confidentiality and integrity of the bundles in the DTN. >> They can replay bundles. >> >> >> >>Proposal: >>--------- >>The basic proposal is to use a combination of Hierarchical Identity based >>encryption (HIBE) and signatures (HIBS). >> >> >>IBE in brief: >> An Identity Base Encryption (IBE) scheme is a public-key cryptosystem where >> any string is a valid public key. In particular, email addresses and dates >> can be public keys. >> When Alice sends mail to Bob at bob@hotmail.com she simply encrypts her >> message using the public key string ``bob@hotmail.com''. There is no need for >> Alice to obtain Bob's public key certificate. When Bob receives the >> encrypted mail he contacts a third party, the Private Key Generator (PKG), >> Bob authenticates himself to the PKG in the same way he would authenticate >> himself to a CA and obtains his private key from the PKG. >> >> IBE scheme consists of four algorithms: >> (1) Setup: The PKG generates global system parameters and a master-key. >> The global system parameters need to be distributed to all hosts >> initially. >> (2) Extract: The PKG uses the master-key to generate the private key >> corresponding to an arbitrary public key string ID, >> (3) Encrypt: Source(A) encrypts messages using the public key ID of the >> destination, B. >> (4) Decrypt: B decrypts messages from A using the corresponding private key >> that it obtained from the PKG. >> >> IBE has been proven to be secure against chosen cipher-text attacks in the >> random oracle model. >> For more details please refer to [7] >> >> IBE based signatures schemes have also be proposed where the source can >> sign using its private key and the signature can be verified using the >> public ID string. >> >>Hierarchy IBE [9] in brief: >> The main problem of plain IBE where the single PKG has to issue private >> keys for all users is mitigated by creating a hierarchy of PKGs. >> Hierarchy is established in the form of a tree where each >> (and root) node can be a separate PKG. >> The identity of a particular node at level t is given by its >> ID-tuple (ID1,ID2..IDt) where ID_i corresponds to the i-th level node. >> For key extraction, each PKG(root or lower level one) at level t may >> obtain the private keys for its immediate children with ID tuple >> (ID1,ID2..IDt,ID_t+1). >> Encryption and decryption proceed similarly as IBE and the ID Tuple is used >> as the public key. >> Similar scheme can be developed for Hierarchical IB Signatures. >> It is also proven that HIBE is secure against collusion among lower level >> PKG servers. >> >>Bundle Transmission: >>1> The source first uses the destination node's public ID string to encrypt >> the bundle. This cipher-text forms the payload of the bundle. >>2> The PSH is then created over the payload and header (with appropriate >> fields zeroed out) by signing with the >> source endpoint ID ( that encapsulates the requisite access control permissions). >> The integrity can be verified and the source identity can be >> authenticated by all routers. >> This was one of the features desired in [1] (point 12). >>3> The BAH is created at each hop by the sending router. This can be done >> using some other cryptographic scheme (symmetric or assymmetric) also. >> >>Now lets see how the different requirements specified are solved: >>1> Implicit certification: >> As is clear from the basic definition of IBE, a source need not know the >> public key of the destination before sending a bundle. >> The burden of ensuring updated certification now rests on the >> destination that now has to obtain the current valid private key >> to be able to decrypt a received bundle. >> >>2> Use of hierarchy: >> This offers us two advantages: >> a> Efficient key distribution: Normal IBE has only one PKG server which >> possesses the master key. This PKG is responsible for extracting private >> keys of all the users of the system. >> By using hierarchy - a) we can first place local PKGs in every region so that >> destination nodes dont have to go far to get their private keys and >> also b) compromise of a lower level PKG does not compromise the whole >> system (as the master secret resides with the root PKG only). >> The naming scheme in HIBE also derives naturally from the naming in the DTN >> architecture where the endpoint address consists of two parts - region >> ID and the region-specific ID. >> For example: if the endpoint address for Bob is 'bundles://Earth/Bob_IP', then >> a PKG can be placed on Earth with ID:'Earth'. For larger regions, we can >> further create more levels in the hierarchy. >> >> b> Revocation control: >> We do this by creating a sub-hierarchy for each host (in addition to the >> hierarchy over multiple PKGs created for key distribution). >> The levels in this sub-tree would reflect the degree of control desired >> for revocation. Senders will use the ID tuples corresponding to the >> leaves of this tree for encryption. >> As this sub-tree is completely located at a particular >> host, the host can act as a PKG and extract private keys for this tree >> on its own. We can control the leaves for which the host is able to generate >> private keys for itself by providing it private keys for only selected >> internal nodes of this tree. >> For example: the first level could be month, the second level date and >> the third level: hour. Then the ID of a user Bob (in region Earth) would be >> Earth.Bob.May.24.12pm . >> - The Earth region PKG can extract private keys for all IDs of the form >> 'Earth.*'. The Earth PKG can then choose to give Bob the private key >> for 'Earth.Bob' if Bob is a highly trusted user. Now Bob can generate all >> keys of the form 'Earth.Bob.... >> - A less trusted user 'Alice' will be given the private key for >> 'Earth.Alice.Nov' only - this will allow Alice to read messages only for >> month of November. For a bundle encrypted with the full ID string >> Earth.Alice.Nov.25.12pm, Alice will be forced to ask a new private >> key every hour. >> - For more paranoid uses, an extra level of the this tree could be a >> random ID. This would force the receiver to acquire a new private key >> for each bundle it receives. A sender can now encrypt the bundle >> with 'Earth.Alice.Nov.25.12pm.'. >> - A sender that wishes lower security( and lower latency) for a >> session can now encrypt it with 'Earth.Alice.Nov.25.12pm.0000', and Alice >> would have to go to the Earth PKG only once to decrypt this bundle. >> In general, the PKG server responsible for a user needs to compute a >> subset cover over the user subtree i.e the minimum set of nodes that cover >> all the IDs that are allowed and none of the IDs that are not allowed >> for that user. Then it needs to extract private keys for only those >> nodes in the subset cover. >> >> c> Fine grained access control: >> A similar scheme as above can be used for forming ID strings needed for >> authentication and access control as well. >> For this source users sign the bundles with the correct privilege >> desired. For example, if Alice desires 'Urgent' class of service, it will >> need to sign the bundle with the identity 'Alice.Urgent'. For this it >> needs to possess the private key corresponding to 'Alice.Urgent'. >> Possession of a private key corresponding to an identity >> implies that the system also authorized you for the rights that are >> associated with that identity. >> This is possible in IBE because all private keys are generated by the PKGs. >> The same hierarchical ID structure can be used for revocation and >> granting of rights as well. The subtree below each host >> would now represent different privileges. >> For example: A highly valuable Bob can be given access to all classes >> of service by providing the private key for 'Earth.Bob.Nov.25' - Bob can >> then generate keys for 'Earth.Bob.Nov.25.Urgent' etc and use them for >> signing his bundles. >> A less valuable 'Alice' will only be given the private key for >> 'Earth.Alice.Nov.25.Bulk'. >> However this mechanism requires the ID string to be included >> in the bundle header(PSH) for routers to use the correct key >> for authentication. >> This issue was raised in [1] as well for key rollover. >> This overall method of encoding the permissions of the user in the ID >> string is very similar to using accompanying certificates in traditional PKI. >> >>Why not PKI?: >>------------- >>1> Implicit certification is not possible as a source host is forced to >> first acquire the identity(public key) of the destination before sending >> any bundle. It is also forced to check >> whether the destination is currently certified or not by making third-party >> queries. >>2> Revocation is made much difficult in DTN and solutions like maintaining >> a Certificate Revocation List(CRL) does not work for DTNs. >> >>Other issues and Disadvantages: >>------------------------------- >>1> Key escrow: >> In IBE, the PKG can generate private keys for all users and thereby decrypt >> bundles destined for all users. This may not be always desirable. >> A related property is 'non-repudiability' which means that a receiver can >> prove that only the sender could have signed the bundle. >> Also, the compromise of the root PKG jeopardizes the entire system >> and all messages that were sent in the past. >> >>2> Standards issue: >> Since we try to encode revocation control(date etc) and access control >> identifiers in the ID strings, all entities in the DTN need to agree on a >> common format. This is similar to the problem faced in traditional PKI >> over the format of certificates. >> >>3> Distribution of private keys: >> Since users ask the PKGs to generate private keys, they have to be transmitted >> securely from the PKGs. This might mean that the PKGs share another key >> with every user just for the purpose of sending private keys. >> >>5> Distribution of system wide public parameters >> An IBE system installation needs to bootstrap all hosts with >> the public system parameters of the PKG. >> This also might need to be updated if the root PKG is compromised. >> >>6> Replay attacks: >> Although we guarantee confidentiality and integrity, we do not have any >> mechanism to detect and handle replay attacks. >> >>Other options and optimizations: >>-------------------------------- >>1> Use of Certificate Based Encryption [8]: >> The 'key escrow' problem can be solved by using this variation where users >> are allowed to generate their own private keys. >> Senders are now able to user long lasting public keys without the need >> to worry about the current certification status of the destinations. >> This also solves the problem of securely delivering extracted private keys >> to each user. >>2> Reducing overhead of using hierarchical IBE: >> Normal HIBE, both the length of signatures and the number of steps required >> for encryption are proportional to the number of levels in the ID tree. >> Some techniques based on the BGLS aggregated signature scheme can be used >> to reduce the decryption complexity. >>3> If non-repudiability is not desired, them the scheme proposed in [10] can be >> used. Here the the MAC for authentication is same as the cipher-text for >> encryption. It also uses the same public IDs and private keys as the standard >> scheme. So we can get both authentication(+integrity) and secrecy with >> little extra cost. >> >> >>Implementation in DTN2 : >>----------------------- >>1> What are the basic building blocks that need to be supported in the DTN2 >> architecture. >>2> User management: [1] suggested that the DTN agent cannot possess the >> private keys. Applications should store the keys and call external >> entity to perform the encryption. >> >> >> >> >> >> >>References: >>----------- >>[1] Email correspondence on the dtn-interest mailing list >>[2] Draft: "Identity based Encryption for Delay Tolerant Networks" >> A. Chakrabarti and K Fall. >> summary: proposes the use of IBE for both confidentiality as well >> as access control management in DTNs. >>[3] Draft: "A Secure Tetherless Computing Architecture" by S.Keshav et al. >> summary: proposes a hierarchy of PKGs using HIBE and HIBS for efficient >> key management in the TCA. >>[4] "Exploiting Hierarchical IBE for Access Control to Pervasive Computing >> Information" >> Urs Hengartner and Peter Steenkiste >> summary: proposes use of HIBE for both "encryption-based" and >> "proof-based" access control for client-server interactions. >> More emphasis on preventing leakage of information about access control >> policies >>[5] "Hidden Credentials" >> >> summary: use of IBE for hidden credential trust negotiation. >>[6] "Identity based signatures" >> Paterson >> summary: one scheme for signatures based on the Boneh/Franklin scheme. >>[7] "Identity based Encryption based on the Weil Pairing" >> Boneh and Franklin >> summary: this introduces the first concrete IBE scheme. >>[8] "Certificate-Based Encryption and the Certificate Revocation Problem" >> Craig Gentry >> summary: this talks about mitigating problems in IBE by proposing >> Certificate based Encryption(CBE) in which users can choose their own >> private key. >>[9] "Hierarchical ID based Cryptography" >> Gentry and Silverberg >> summary: this extends the Boneh/Franklin IBE scheme >>[10]"Authenticated Identity-based Encryption" >> Ben Lynn >> summary: extends the Boneh/Franklin scheme to provide integrity of the >> message being encrypted. >> >> >> >> >> > > -- > Howard Weiss > SPARTA, Inc. > 7075 Samuel Morse Drive > Columbia, MD 21046 > 410.872.1515 x201 > 410.872.8079 (fax) > > Received: from smtp-bedford-dr.mitre.org (smtp-bedford-dr-x.mitre.org [192.160.51.65]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j31JSUV12893 for ; Fri, 1 Apr 2005 11:28:30 -0800 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with SMTP id j31JSTj22524 for ; Fri, 1 Apr 2005 14:28:29 -0500 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (Postfix) with ESMTP id 7E13C4F8DB for ; Fri, 1 Apr 2005 14:28:29 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with ESMTP id j31JSTL22487; Fri, 1 Apr 2005 14:28:29 -0500 Message-Id: <200504011928.j31JSTL22487@smtp-bedford-dr.mitre.org> Received: from mm122433-pc.mitre.org (128.29.14.8) by mailhub1.mitre.org with SMTP id 14760360; Fri, 01 Apr 2005 14:28:22 -0500 From: "Susan F. Symington" To: Cc: "'Stephen Farrell'" , "'Howard Weiss'" Subject: RE: [dtn-security] Comments on DTN Security Overview] Date: Fri, 1 Apr 2005 14:28:19 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01C536C7.0D3B7780" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <424996C4.9080605@sparta.com> Thread-Index: AcU2E/ahVnnIYhSGRIynpFxVb5vjzgAzjLYA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_00D6_01C536C7.0D3B7780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Howie, Thanks for your comments. You zero in on some very important things that we need to clarify. I am interspersing my comments below. -susan _____ From: dtn-security-admin@mailman.dtnrg.org [mailto:dtn-security-admin@mailman.dtnrg.org] On Behalf Of Howard Weiss Sent: Tuesday, March 29, 2005 12:56 PM To: dtn-security@mailman.dtnrg.org Subject: [dtn-security] Comments on DTN Security Overview] Susan, I've gone through your DTN security overview. First, thanks for writing all of this down. This was good - we've talked about a lot of pieces of this in various fragments of other stuff and its nice that someone finally had the time and funding to sit down and seriously write it all down. At first I started reading it electronically but I hate to say it, I felt handicapped that it was a text file and that I didn't have the ability to insert comments and changes as in Word (wow did I just say I liked something that Microsoft produced??). So I ended up printing it out and writing stuff in the margins which I was going to type up. But then I just got lazy (the mark of a good engineer - so one of my undergrad EE professors always use to tell us) and I just scanned in the whole lot and made it into a PDF. It looks like you should be able to read my marginal comments - if you can read my handwriting that is. [Susan] Sorry the text format was such a handicap. Since it's intended to be an internet draft, I wrote it in xml; hence, the text file. I want to say up front that I have not read Stephen's comments - I wanted to go through this first without being "tainted" by another reviewer. And I still have not gone back to read his comments so I have no idea how much overlap there is. Some general comments: 1. While I think this was a good thing to do, I have some serious problems with what is being said. Sometimes its not clear who is doing what with whom. The whole notion of source, destination, sender, receiver needs to be revisited to make things clearer. Plus there are times when you don't use the term destination and use other terms in its place. Its still confusing without a road-map (which I had to draw to keep myself understanding). [Susan] Your diagram will be helpful in making the terminology clear. I will have to go through and make sure the terms are used consistently. 2. While you mention that public key or symmetric key crypto can be used, you state that the symmetric keys are between bundle router pairs. Youch - this implies that every two communicating entities would have to have a symmetric pair. Talk about an explosion of keying. Way back when we started talking about this we were thinking more along the lines of a net/group symmetric key to keep things simple. [Susan] I was trying as best I could to write generally so that the overview would hold true independent on the type of crypto being used and independent of any particular algorithms. At least in the overview document. Key management is a big problem that is simply not addressed in this document for now. But if there is to be source authentication, then the entity that possesses the key is what gets authenticated as the source. If multiple nodes hold the same key, then one can only authenticate down to the granularity of that group and not authenticate any particular source. I guess we have to decide if we think its okay to have net/group keys or not. In either case, I'm hoping we can write a document that works whether the keys are specific to each node or group keys, as well as whether the algorithms used require symmetric keys or public/private key pairs. 3. Speaking of more confusion, there are a number of "bundle" terms used. For example, "bundle agent," "bundle router," "bundle security policy router." Personally, I never envisioned a gaggle of devices - the bundle agent was the same thing as the bundle router - maybe w/o a convergence layer. Do you really see a bunch of different flavor devices being developed? [Susan] I see the bundle agent as the implementation of the bundle protocol -- as a bundle daemon. I envision a bundle agent operating at the bundle layer in a DTN end system (the source host has a bundle agent, and the destination host has a bundle agent) and in DTN routers (every DTN router along the way from source to destination also has a bundle agent). I do use the term "security policy router" to denote a DTN router that is configured in a certain way. So, it's not really a different device, but a device that is understood to be configured to make decisions regarding what bundles to forward based on the value of the authentication information in the PSH of the bundles. Stephen Farrel pointed out in his comments that in theory every bunde router can make decisions regarding what bundles to forward and I agree. I just find it useful to use the term security policy router to denote a bundle router that is configured in a specific way. That was my intention. I need to figure out a way to describe this in a way that is less confusing. In your comments you say that it seems like the security policy router acts like a front door firewall; yes, that is what I intended. 4. You've left out the use of keyed hashes - a la HMAC - that might suffice for the hop-by-hop authentication. [Susan] Yes. Sorry about that. It's hard to talk about this stuff in a general enough way that it applies correctly to different types of algorithms. We will need to address this specific solution when we define the security protocol. 5. Its also confusing who does payload security. In one place it sounds like its the application. But in another place it sounds like its the bundle agent. It looks like you've adopted a model of the bundle agent looking like a firewall/VPN router - that is, a standalone device acting like a front-end. However, I always envisioned a bundle "thing" more like IPSec which can be run in either tunnel or transport mode. It can be a separate box or it can be part of the end system depending on the environment. [Susan] This touches on an issue that I have brought up before and still am not clear if everyone agrees on. My question has always been, where does the PSH hash get signed? If the source bundle agent signs this hash, then the source bundle agent is the entity that is authenticated as the source of the bundle. Howeve, that bundle agent may serve several different DTN applications. Ideally, we would like the DTN application to do the signing and not have the bundle agent be privy to the secret key used to sign. This way the specific source application would be the entity that is authenticated as the source. [Susan] I didn't think of myself as having adopted a model of the bundle agent looking like a firewall/VPN router. I envision the bundle agent to be a daemon running at the layer just below the application layer, probably in the same box with the DTN application, but not necessarily. I have always wondered, though, just where (in the application or the bundle agent) the crypto for authentication was being performed. I don't believe we've ever discussed the option of being able to choose to do it either above the bundle layer or at the bundle layer a la transport versus network mode IPsec. If we did have such a choice, wouldn't we need a way to signal this in the protocol? This is obviously something fundamental that we need to all think about and come to agreement on. 6. The whole issue of "optional" security is coming back to haunt me. First, do we have a definition of "optional?" Is it like IPv4 where its optional to implement and use or like IPv6 where its mandatory to implement but optional to use? Then there is the discussion about mixing secure DTN elements with non-secure DTN elements. On a global scale, I don't know how that will work. It could work on private DTNs but not on an Internet-like DTN overlay where bundle agents sit on whatever network where-ever. [Susan] Great point! We need to think through and define exactly what is meant by "optional". The definition of "optional" that I had in mind was that an implementation of DTN would not necessarily have to include security features. However, any implementation of DTN that claims to implement security would have to do so as specified in the documents that we are developing. I guess this brings up the concept of such a node "operating" in secure mode or not. A node that does not even have security implemented can never operate in secure mode; that seems pretty obvious. A node that does have security implemented, though, could possibly operate in insecure mode or secure mode. (I guess; this is all off the top of my head here...) What is important is that in order for a network of interconnected nodes to provide security services, every one of those interconnected nodes must not only have security implemented, but be operating in secure mode. What does it mean to be operating in secure mode? If a node is operating in secure mode, then all bundles received must either have a BAH or be asserted as authenticated by the convergence layer. Whereas use of the PSH would be optional. If Security is optional in this way, then we have the possibility that a DTN implementation that includes security could be adjacent to a DTN implementation that doesn't include security or that does include security but that isn't operating in secure mode, and we have to address this. Ideally, a secure DTN must consist only of interconnected DTN nodes that do implement security. However, what happens at the perimeter, when a secure node may be adjacent to an insecure one? Can a sender who is not on a secure DTN send to a recipient that is, and vice versa? Where would the protections start and stop? All that would need to be addressed. With the overlay idea that I introduced (page 48) I was trying to have a way that two secure nodes could interoperate securely with one or more intervening insecure nodes. For now, as Stephen suggested, it is probably too much in this document to try to tackle a mixed case in which network has insecure nodes interspersed with secure ones. We should just define the network such that a secure DTN network must consist only of interconnected DTN nodes that implement security. Take a look at the comments and we can talk or meet or meet. [Susan] I also have some responses to the comments that you wrote on the draft itself. You ask why we do authentication but not confidentiality. I'm not sure, maybe we should do both. I agree key management is a major issue and needs closure, but I don't want to tackle it in this document. Do you think we need to address how access control policy is set and updated in this document (page 15) ? We have a way for the convergence layer to signal that a bundle has been authenticated based on the regional network that was used to to deliver it. How does a node's policy regarding whether to signal bundles received from a certain network as authenticated get set? I don't know. It needs to be addressed. The question is do we have to address it in this document. The bundle protocol specification as currently written allows doing hashing without signing, but in the overview document I eliminated this as a possibility. Do you think we should have the option fo hashing without signing? (page 20). I don't like it because it can be misunderstood to provide a false sense of security. We need better terminology. We all want to be able to say that a bundle = header + payload, but this is not consistent with the bundle protocol specification. In that, the payload is just one field in one of the bundle headers. It seems you think it would be unrealistic to use MACs between bundle routers to perform authentication because of the explosion of symmetric keys. And you may be right for most uses. I guess that I'm thinking we shouldn't disallow symmetric keying to be used just because we think it won't be realistic for most cases. If it makes sense for some cases, then it would be nice if we could write the specs so that it would be possible to do it in DTN. I guess I"m okay with deleting the last part of section 4.5, starting with 4.5.1. I think this would please Stephen as well. Stephen? I see your points (page 31) that instead of putting fields in the header to support confidentiality, we could just let this information be carries as part of the payload metadata instead. However, somewhere we would still have to specify how this information is formatted. Is there a disadvantage to having it be part of the payload instead of part of a header field? You ask why don't we provide encryption of we are already providing authentication at the bundle layer. I don't know. I believe Stephen had a similar comment. Maybe we should provide encryption at the bundle layer. Do you know if there was any specific reason it was left out of the bundle protocol originally? I'm not sure what you mean by you "keys are crown jewels" comment (page 34). I should delete mention of IBC from the document; key management won't be addressed in this overview document. I will also endeavor to look through Stephen's comments. [Susan] Please look through my responses to Stephen's comments too; I believe that some of my responses to his comments are also applicable to some of the points you raise. Thanks again. With you and Stephen getting so involved we are going to make great progress. -susan Regards, Howie -- Howard Weiss SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 410.872.1515 x201 410.872.8079 (fax) ------=_NextPart_000_00D6_01C536C7.0D3B7780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Howie,
 
Thanks for your comments. You zero in on some = very=20 important things that we need to clarify.  I am interspersing my = comments=20 below.
 
-susan

From: = dtn-security-admin@mailman.dtnrg.org=20 [mailto:dtn-security-admin@mailman.dtnrg.org] On Behalf Of = Howard=20 Weiss
Sent: Tuesday, March 29, 2005 12:56 PM
To:=20 dtn-security@mailman.dtnrg.org
Subject: [dtn-security] = Comments on=20 DTN Security Overview]

Susan,

I've=20 gone through your DTN security overview.

First, thanks for = writing all=20 of this down.  This was good - we've talked about a lot of pieces = of this=20 in various fragments of other stuff and its nice that someone finally = had the=20 time and funding to sit down and seriously write it all = down.

At first=20 I started reading it electronically but I hate to say it, I felt = handicapped=20 that it was a text file and that I didn't have the ability to insert = comments=20 and changes as in Word (wow did I just say I liked something that = Microsoft=20 produced??).  So I ended up printing it out and writing stuff in = the=20 margins which I was going to type up.  But then I just got lazy = (the mark=20 of a good engineer - so one of my undergrad EE professors always use = to tell=20 us) and I just scanned in the whole lot and made it into a PDF.  = It looks=20 like you should be able to read my marginal comments - if you can read = my=20 handwriting that is. 
[Susan] Sorry the text format was such a = handicap. Since=20 it's intended to be an internet draft, I wrote it in xml; hence, the = text=20 file.  

I want to say up front = that I=20 have not read Stephen's comments - I wanted to go through this first = without=20 being "tainted" by another reviewer.  And I still have not gone = back to=20 read his comments so I have no idea how much overlap there = is.

Some=20 general comments:

1. While I think this was a good thing to do, = I have=20 some serious problems with what is being said.  Sometimes its not = clear=20 who is doing what with whom.  The whole notion of source, = destination,=20 sender, receiver needs to be revisited to make things clearer.  = Plus=20 there are times when you don't use the term destination and use other = terms in=20 its place.  Its still confusing without a road-map (which I had = to draw=20 to keep myself understanding).
[Susan] Your diagram will be helpful = in making=20 the terminology clear. I will have to go through and make sure the = terms are=20 used consistently. 

2. While you mention = that public=20 key or symmetric key crypto can be used, you state that the symmetric = keys are=20 between bundle router pairs.  Youch - this implies that every two = communicating entities would have to have a symmetric pair.  Talk = about=20 an explosion of keying.  Way back when we started talking about = this we=20 were thinking more along the lines of a net/group symmetric key to = keep things=20 simple. 
[Susan] I was trying as best I could = to write=20 generally so that the overview would hold true independent = on the=20 type of crypto being used and independent of any particular=20 algorithms. At least in the overview document. Key management is a big = problem=20 that is simply not addressed in this document for now.=20
 
But if = there is to be=20 source authentication, then the entity that possesses the key is what = gets=20 authenticated as the source. If multiple nodes hold the same key, then = one can=20 only authenticate down to the granularity of that group and not = authenticate=20 any particular source. I guess we have to decide if we think its okay = to have=20 net/group keys or not. In either case, I'm hoping we can write a = document that=20 works whether the keys are specific to each node or group keys, as = well as=20 whether the algorithms used require symmetric keys or public/private = key=20 pairs.

3. Speaking of more confusion, there are a = number=20 of "bundle" terms used.  For example, "bundle agent," "bundle = router,"=20 "bundle security policy router."  Personally, I never envisioned = a gaggle=20 of devices - the bundle agent was the same thing as the bundle router = - maybe=20 w/o a convergence layer.   Do you really see a bunch of = different=20 flavor devices being developed?
[Susan] I see the bundle agent as = the=20 implementation of the bundle protocol -- as a bundle daemon. I = envision a=20 bundle agent operating at the bundle layer in a DTN end system (the = source=20 host has a bundle agent,  and the destination host has a bundle = agent)=20 and in DTN routers (every DTN router along the way from source to = destination=20 also has a bundle agent). 
 
I do use the term "security policy = router" to=20 denote a DTN router that is configured in a certain way. So, it's not = really a=20 different device, but a device that is understood to be configured to = make=20 decisions regarding what bundles to forward based on the value of the=20 authentication information in the PSH of the bundles. Stephen Farrel = pointed=20 out in his comments that in theory every bunde router can make = decisions=20 regarding what bundles to forward and I agree. I just find it useful = to use=20 the term security policy router to denote a bundle router that is = configured=20 in a specific way. That was my intention. I need to figure out a way = to=20 describe this in a way that is less confusing. In your comments you = say that=20 it seems like the security policy router acts like a front door = firewall; yes,=20 that is what I intended.

4. You've = left out=20 the use of keyed hashes - a la HMAC - that might suffice for the = hop-by-hop=20 authentication.
[Susan] Yes. Sorry about that. It's hard to talk = about this=20 stuff in a general enough way that it applies correctly to different = types of=20 algorithms. We will need to address this specific solution when we = define the=20 security protocol. 

5. Its also confusing = who does=20 payload security.  In one place it sounds like its the = application. =20 But in another place it sounds like its the bundle agent.  It = looks like=20 you've adopted a model of the bundle agent looking like a firewall/VPN = router=20 - that is, a standalone device acting like a front-end.  However, = I=20 always envisioned a bundle "thing" more like IPSec which can be run in = either=20 tunnel or transport mode.  It can be a separate box or it can be = part of=20 the end system depending on the environment.
[Susan] This=20 touches on an issue that I have  brought up = before and=20 still am not clear if everyone agrees on. My question has=20 always been, where does the PSH hash get signed? If=20 the source bundle agent signs this hash, then the source bundle = agent is=20 the entity that is authenticated as the source of the=20 bundle. Howeve, that bundle agent may serve several different DTN = applications. Ideally, we would like the DTN application to do the = signing and=20 not have the bundle agent be privy to the secret key used to sign. = This way=20 the specific source application would be the entity that is=20 authenticated as the source.

[Susan] I didn't think of myself as having = adopted a=20 model of the bundle agent looking like a firewall/VPN router. I = envision the=20 bundle agent to be a daemon running at the layer just below the=20 application layer, probably in the same box with the DTN application, = but not=20 necessarily. I have always wondered, though, just where (in the=20 application or the bundle agent) the crypto for authentication = was being=20 performed. I don't believe we've ever discussed the option = of being able=20 to choose to do it either above the bundle layer or at the = bundle=20 layer a la transport versus network mode IPsec. If we did have = such a=20 choice, wouldn't we need a way to signal this in the = protocol? This=20 is obviously something fundamental that we need to all think about and = come to=20 agreement on. 

6. The whole issue of = "optional"=20 security is coming back to haunt me.  First, do we have a = definition of=20 "optional?"  Is it like IPv4 where its optional to implement and = use or=20 like IPv6 where its mandatory to implement but optional to use?  = Then=20 there is the discussion about mixing secure DTN elements with = non-secure DTN=20 elements.  On a global scale, I don't know how that will = work.  It=20 could work on private DTNs but not on an Internet-like DTN overlay = where=20 bundle agents sit on whatever network where-ever.
[Susan] Great=20 point!  We need to think through and define exactly what is = meant by=20 "optional".
 
The definition of "optional" that I had in mind was = that an=20 implementation of DTN would not necessarily have to include security = features.=20 However, any implementation of DTN that claims to implement security = would=20 have to do so as specified in the documents that we are developing.=20
 
I guess this brings up the concept of such a node = "operating" in=20 secure mode or not. A node that does not even have security = implemented can=20 never operate in secure mode; that seems pretty obvious. A node that = does have=20 security implemented, though, could possibly operate in insecure mode = or=20 secure mode. (I guess; this is all off the top of my head here...) = What is=20 important is that in order for a network of interconnected nodes to = provide=20 security services, every one of those interconnected nodes must not = only have=20 security implemented, but be operating in secure mode.=20
 
What does it mean to be operating in secure = mode? If a node=20 is operating in secure mode, then all bundles received must either = have a BAH=20 or be asserted as authenticated by the convergence layer. Whereas use = of the=20 PSH would be optional.
 
If=20 Security is optional in this way, then we have the possibility = that=20 a DTN implementation that includes security could be adjacent to = a DTN=20 implementation that doesn't include security or that does include = security but=20 that isn't operating in secure mode, and we have to address this.=20  Ideally, a secure DTN must consist only of interconnected DTN = nodes that=20 do implement security. However, what happens at the perimeter, when a = secure=20 node may be adjacent to an insecure one?  Can a sender who = is not on=20 a secure DTN send to a recipient that is, and vice versa?  Where = would=20 the protections start and stop?  All that would need to be=20 addressed. 
 
With=20 the overlay idea that I introduced (page 48) I was trying to have a = way that=20 two secure nodes could interoperate securely with one or more = intervening=20 insecure nodes. For now, as Stephen suggested, it is = probably too=20 much in this document to try to tackle a mixed case in which network = has=20 insecure nodes interspersed with secure ones. We should just define = the=20 network such that a secure DTN network must consist only of = interconnected DTN=20 nodes that implement security.

Take a look at the comments and we can talk or = meet or=20 meet. 

[Susan] I also have some responses to the = comments that you=20 wrote on the draft itself. You ask why we do authentication but not=20 confidentiality.  I'm not sure, maybe we should do=20 both. 
 
I agree key management is a major issue and needs = closure,=20 but I don't want to tackle it in this = document.
 
Do you think we need to address how access control = policy is set=20 and updated in this document (page 15) ? We have a way for the convergence layer to signal = that a=20 bundle has been authenticated based on the regional network that was = used to=20 to deliver it. How does a node's policy regarding whether to signal = bundles=20 received from a certain network as authenticated get set? I don't = know. It=20 needs to be addressed. The question is do we have to address it in = this=20 document.

The bundle protocol specification as currently written = allows=20 doing hashing without signing, but in the overview document I = eliminated this=20 as a possibility. Do you think we should have the option fo hashing = without=20 signing? (page 20). I don't like it because it can be misunderstood=20 to provide a false sense of security.
 
We=20 need better terminology.  We all want to be able to say that a = bundle =3D=20 header + payload, but this is not consistent with the bundle protocol=20 specification. In that, the payload is just one field in one of the = bundle=20 headers.
 
It=20 seems you think it would be unrealistic to use MACs between bundle = routers to=20 perform authentication because of the explosion of symmetric keys. And = you may=20 be right for most uses. I guess that I'm thinking we shouldn't = disallow=20 symmetric keying to be used just because we think it won't be = realistic for=20 most cases. If it makes sense for some cases, then it would be = nice if we=20 could write the specs so that it would be possible to do it in=20 DTN.  
 
I=20 guess I"m okay with deleting the last part of section 4.5, starting = with=20 4.5.1. I think this would please Stephen as well. = Stephen?
 
I=20 see your points (page 31) that instead of putting fields in the header = to=20 support confidentiality, we could just let this information be carries = as part=20 of the payload metadata instead. However, somewhere we would still = have to=20 specify how this information is formatted. Is there a disadvantage to = having=20 it be part of the payload instead of part of a header field? You ask = why don't=20 we provide encryption of we are already providing authentication at = the bundle=20 layer. I don't know. I believe Stephen had a similar comment. Maybe we = should=20 provide encryption at the bundle layer. Do you know if there was any = specific=20 reason it was left out of the bundle protocol = originally?
 
I'm not sure what you mean by you "keys are crown = jewels"=20 comment (page 34). 

I should delete mention of IBC from the document; key = management=20 won't be addressed in this overview=20 document. 

I will also endeavor to look = through=20 Stephen's comments.
[Susan] Please look through my responses to = Stephen's=20 comments too; I believe that some of my responses to his=20 comments are also applicable to some of the points you raise. =  =20 Thanks again. With you and Stephen getting so involved we are = going to=20 make great progress.
 
-susan 

Regar= ds,

Howie

--=20
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)
------=_NextPart_000_00D6_01C536C7.0D3B7780-- Received: from smtp-bedford-dr.mitre.org (smtpproxy2.mitre.org [192.160.51.65]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j31HWnV12053 for ; Fri, 1 Apr 2005 09:32:49 -0800 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with SMTP id j31HWmi19897 for ; Fri, 1 Apr 2005 12:32:48 -0500 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (Postfix) with ESMTP id 38A174F8E6 for ; Fri, 1 Apr 2005 12:32:48 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with ESMTP id j31HWlQ19788; Fri, 1 Apr 2005 12:32:48 -0500 Message-Id: <200504011732.j31HWlQ19788@smtp-bedford-dr.mitre.org> Received: from mm122433-pc.mitre.org (128.29.14.8) by mailhub1.mitre.org with SMTP id 14753794; Fri, 01 Apr 2005 12:32:40 -0500 From: "Susan F. Symington" To: Cc: "'Stephen Farrell'" , "'Howard Weiss'" Subject: RE: [dtn-security] draft security overview and motivations document Date: Fri, 1 Apr 2005 12:32:37 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00D3_01C536B6.E34C1890" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <42401B26.60503@cs.tcd.ie> Thread-Index: AcUu4X9oKdkE2H6oQH2npXQ081tdbwH/qrXQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_00D3_01C536B6.E34C1890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stephen, Thanks for your comments. I am attaching my responses. -susan -----Original Message----- From: dtn-security-admin@mailman.dtnrg.org [mailto:dtn-security-admin@mailman.dtnrg.org] On Behalf Of Stephen Farrell Sent: Tuesday, March 22, 2005 8:19 AM To: dtn-security@mailman.dtnrg.org Subject: Re: [dtn-security] draft security overview and motivations document Hi Susan, Susan F. Symington wrote: > Attached is a first attempt at a security overview and motivations > document for DTN security. > > Review and comment by all is solicited. Turns out I've a plethora of comments! First though: well done preparing this, I think its really valuable and about time for us to seriously consider this stuff. Second, I guess I have to confess, that I saw Susan's document about a week ago so I been working on it on&off since then. Anyway, here ya go! Stephen. ------=_NextPart_000_00D3_01C536B6.E34C1890 Content-Type: text/plain; name="sym_response_to_motiv-notes-20050322.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="sym_response_to_motiv-notes-20050322.txt" Overall: -------- 0. Brevity is good. The document's not brief enough:-) Susan: Agree. 1. I'd suggest that this document be recast as something that describes = a snapshot of the DTNRG view on bundling security, rather than (as = currently seems to be the case) a requirements-type document. The main reason is = that its already very useful as-is, but we don't necessarily need to finalise = every detail before putting this to bed. Also, revisiting this to take account = of the final prtocool would be a pain, and not very worthwhile. Where necessary = and useful text from this could be inserted into the protocol document. = Getting this to the state where everyone's happy to decide any controversy by = referring back to this might be counterproductive. If this were agreed, I'd = suggest a quick tidy up, followed by submission to the RFC editor (maybe this'll = be the 1st DTNRG RFC!). Susan: This works for me. 2. The document seems (understandably given previous discussion) to = focus too much on cryptographic protection. I'd like to see more emphasis on = specific authorisation mechanisms. For example, it'd be nice to say why using = SAML+XACML at each bundle agent to decide whether or not to forward the bundle is = good or bad. Even if that combination isn't ideal, (which'd take a bit of = thought to establish), if it, or similar, could work, then the requirement for = source authentication may be easier to meet. In particular, if we assume that = the SAML assertions consumed by the policy enforcement point (PEP) are "fresh" = then we no longer need to bother thinking about source-credential revocation = within the network. A successful case of kicking-to-touch/punting! Basically, = maybe I'm saying we ought to try think along the lines of rfc2906/7/8 about PDPs = and PEPs and DTN-AAA, that than take what I could term the current DTNSec type = model. (Ok, I confess - I'm a co-author on those RFCs, but it'd be interesting = to see the extent to which they, or the general PDP/PEP model, might usefully = apply to DTNs!) Susan: Do you want to take a crack at writing text to express these = ideas?=20 3. I'm not entirely comfortable with the "protect the infrastructure" = argument, (e.g. as stated at the start of section 2). While I don't disagree with = lots of the conclusions, I do believe that infrastructure is only provided for applications, and infrasructure security likewise, so ultimately we do = want to protect application data. I'm not sure how I'd suggest restating this, = but I do think that we want to provide security tools for application data, (e.g. key-mgmt for end2end integ). Susan: I see your point that it only makes sense to protect the = infrastructure from unauthorized use if you can also provide some = security protections for the application data that is authorized to use = the infrastructure. The DTN Architecture document states that the DTN = security model is aimed at protecting the infrastructure from = unauthorized use. Would it make you more comfortable if we took out the = language about "the focus of security" and "secondary emphasis" and just = talked about all the security protections without ranking them by = importance?=20 4. The security goals, as stated, are open to being attacked on a number = of fronts (as happened in Minneapolis!). For example, the ability to = disable a compromised agent probably implies (giving someone) the ability to = prevent an authorized agent from forwarding bundles, so items 2 and 6 (from the = list at the start of section 2) are somewhat contradictory. Similarly, we saw at = the meeting that not detecting payload modification or replay is in conflict = with item 3 from the above list. I think that recasting DTN security along = the lines of the PDP/PEP model may help out here, but I also think that we do need = to be able to provide tools/techniques that do address e.g. payload = modification and replay. Susan: Yes, I agree that the goals are open to attack. I thought it = would be desirable to state the goals but I didn't mean to imply that we = meet all the goals. For example, there is nothing in the document at all = about how to achieve goal 6. Do you suggest that we not state the goals = or that we restate them with qualifiers or what? Susan: I also agree that we've got a fundamental and very difficult = problem insofar as reactive fragmentation (which we want to be able to = do) is not compatible with providing payload integrity on a hop-by-hop = basis using the BAH authentication information field as currently = defined in the Bundle Protocol Specification. This is a key issue that = we need to address. A long time ago Bob Durst suggested a "toilet paper" = approch to payload authentication that would enable bundles to be = reactively fragmented and at the same time provide hop-by-hop payload = authentication. We had dismissed this in favor of just not providing = payload authentication at all. Now it seems that we may want to = reconsider Bob's toilet paper approach, which basically involved = formatting the payload as a series of segments of payload each followed = by a MAC/Digital signature that authenticates that segment of payload. = Addressing this issue needs to be a high priority for us. 5. Other than being a bit silly, is there a specific reason not to = provide mechanisms that can be used to make it harder to do traffic analysis? If = all it amounted to was defining a "pad" bundle payload, and allowing agents to = send that whenever they want, then I can't see a good reason to not do this = (even if its not a compelling thing to be doing). I would agree that defining DTN security so that it can provide something like a mix network with nymity = is not a serious goal (OTOH, if someone had a great idea for doing that, would = it be bad? Note: I don't have such an idea:-) Susan: You have a good point. If all it amounts to is defining a "pad" = payload, then we should probably do so to make it possible for folks to = protect against traffic analysis if they want to.=20 6. Security is (correctly) stated as being optional. Therefore use of = BAH is optional. Therefore an authorized agent can simply send bundles which do = not contain a BAH. Therefore agents which support incoming BAH, MUST have a = policy DB (or rules, whatever) which determine whether a given DTN peer is, or = is not, allowed to send me this bundle, with this content and set of headers = now. That's a lot to get right. We might be able to tie this down a bit = better later on, say if BAH is turned on iff PSH is. Susan: I agree with everything you say in 6 but you lose me when you = say "BAH is turned on iff PSH is". I don't understand why you would = require BAH iff PSH is used. I consider use of BAH and PSH to be = independent. Susan: On another note, Howie Weiss has pointed out that we haven't = really defined what we mean by security being "optional", and I fear = that we may each have something a little different in mind. For example, = I had in mind that security would be optional to implement. That is, an = implementation could call itself an implementation of DTN but not = implement security at all. However, if an implementation of DTN claimed = to be secure, it would have to conform to the DTN security = specifications. However, there is another possible understanding of = "optional" a la IPv6 and IPsec, meaning that security in DTN would be = mandatory to implement, but optional to use. My feeling is that it = should be optional to implement and use. Is this how you envision it = also? 7. This is almost a nit, but...Both IPSec and TLS provide for some = ability to do payload padding in order to disguise payloads where the payload = length determines the payload content, e.g. if the only options are "yes" and = "no" then length=3D2=3D>"no". If we're supporting confidentiality, then I'd = be for allowing the same thing here. Mind you, no-one ever uses this since = there's no sensible way to provide an API that anyone'd want to call. Susan: If I understand you, then this is similar, but not exactly the = same as your comment 5 above, and it seems reasonable to me. 8. I disagree with the "security policy router is a special agent" idea. Basically, every agent has to make these decisions (by integrating a = PEP), and anything after that is a matter of local configuration (unless and until = we provide ways to signal in-band about some agent being a bottleneck for a = region or something). Susan: Yes, I think you are right. Security Policy routers are really = just DTN routers. They aren't a different species. They have the same = bundle agent capabilities as other DTN routers.=20 Susan: At the same time, I guess I like having the term "security policy = routers is that it conveys that these entities are distinguished from = "generic" DTN routers by the fact that their policies regarding what = bundles to forward may depend on being able to verify the PSH = authentication information in the bundles that they receive for = forwarding. This means that then they will require the cryptographic = keys necessary to verify the validity of the PSH authentication = information and also that they will have to receive all fragments of a = PSH-protected bundle in order to be able to allow any portion of the = bundle to be forwarded. If they don't have access to the proper keys or = they don't receive all fragments of a bundle, then they will just be = black holes for the affected bundles that they receive. Any DTN router = can become a security policy router by configuring it properly and = giving it access to the keys it will need to validate PSH authentication = information. Susan: So while I agree that security policy routers aren't special = agents, I'm not clear about how I should change the text to get this = across and also get across how they are different also. I'm not sure of = what portion of the document inspired comment 8, so I'm not sure what = exactly I have to fix to address your concern, but I would appreciate = suggestions. Do you think we shouldn't have a special term called = "security policy routers"? What changes to the text would make this = feel right to you? 9. Replay. I may or may not convince you, but I believe we do have to = provide replay detection mechanisms and maybe the Wed morning discussion in MSP = went some way towards us agreeing that. In any case, I don't think that this document should be so deterministic (if you accept #1 above that is), so = its ok to say "replay: we're not sure yet" :-) Susan: I think this is a good solution for now--that is, discuss replay = and say we aren't sure. The only reason we haven't protected against = replay so far is that it seemed to require too much state--more than the = benefits were worth. I do worry that unintended routing loops could = cause lots and lots of replays and that this situation might go = undetected. Perhaps a good compromise would be to come up with a way to = enable replays to be optionally detected. That is, if you wanted to = configure a bundle agent to detect replays, you could. I guess this = would mean that implementing replay detection would be mandatory, but = using it would be optional. For now saying we're not sure is probably = the best we can do.=20 Susan: Do you want to take a stab at defining how replay detection = should be accomplished? I think that everyone agrees that providing = replay detection has a lot of merits, but in past DTN RG discussions it = just seemed that every way that we could come up with to provide replay = detection required maintaining so much state that it wasn't worth it. In = order to go back to the larger DTN RG and make a case for replay = detection, we need to make clear the types of threats the infrastructure = is vulnerable to without it, as well as how we propose it should be = provided, so that it's cost/benefits could be better weighed. 10. I don't know but we may need to do more to support routing. Say if a = new route is announced, then a) that might be a sort-of broadcast message = and hence might e.g. have a different set of immutable headers (it'd certainly = have to use signing and not MACing) and b) an agent who's "installing" that = route, might have to make some kind of DTN connection to a security server if = he's never before been in touch with one of the regions in the announcement, = for example. At that stage we'd maybe have to define additional security = rules say matching values from the announced route and some of the stuff from the security interchange. I know this is all very vague, but basically, the = point is that we might have to define specific routing security, which'd best = be done in a routing docuement and not here. For example, I'm not sure the = discussion of compromised routers and (presumably) MACing keys is in the right = place (all DTN agents are routers really, aren't they?) Susan: So would an acceptable response to this comment be to replace all = the text in 3.6 with the following: "Router and routing protocol = security services will be vital to DTN security. However, this document = does not yet address router or routing protocol security in DTNs"?=20 11. Traffic padding. While it may be silly in many DTN contexts to want = to do traffic padding, there will be contexts when it may make sense. For = example, if a DTN bundle traverses the terrestrial Internet (which is highly = likely for many DTNs), then there may be reasons to disguise the existence of real traffic. For example, if the "sensor" end of that DTN were of the presence-detecting kind and takes a lot of trouble (e.g. via = spread-spectrum) to try to hide a presence-detection, then it'd be a pity to leak the = detection to someone who only has to watch the SNMP counts on some bundle agent or router. As section 4.1 implies, being able to support traffic padding = requires payload confidentiality but also requires confidentiality for some = header fields (mainly the destination addreess and port equivalents). I believe = we ought to make this possible, but I don't believe that we particularly = need a fully worked out, standard way to actually do traffic padding (e.g. I = don't think we need to specify bahaviour for using delays for bundles just to = diguise routing behaviour). If we can figure out how to provide basic support = for this, then it could be appropriate to include it in an appendix, it certainly oughtn't be anywhere near mandatory. Susan: Unless you have a proposal that you want to write up, why don't = we just for now say that the document does not provide for this, but it = could be done at lower layers? 12. I believe that section 4.2 reflects a slightly unusual use of = terminology. In my mind at least, every bundle agent is making a network access = control choice whenever it decides to forward or deliver a bundle. So, of course = I don't buy the security policy router special category. Susan: This comment seems to be the same as comment 8, so I won't reply = separately.=20 13. Fragmentation is a pain, that's clear. Combining fragmentation with = almost any other service casues grief (e.g. aside from securtiy, CoS/QoS stuff = has to get confusing). So why don't we define a don't-fragment bit in the = header, just like in IP? That way, at least we can avoid the nasty cases where = network provisioning allows.=20 Susan: This is a suggestion for the larger DTN group and is not = specific to security. I will say that it doesn't seemt to solve = anything, as reactive fragmentation is felt to be an essential part of = DTN to enable data that does make it across a connection before it = breaks can proceed without having to be resent. =20 14. Fragmentation again. I see a note from some "disruption" folks which implies that maybe we've been thinking about only a subset of the types = of disruption they're considering. In particular, they seem to envisage = more but shorter outages. I think its fair to say (at least in my case) that I've generally been thinking if the link went down, then it'd be down for the remainder of the contact. So maybe we ought to try to figure out a = scheme which nicely handles mid-bundle outages. This changes the requirement for = digesting the payload from one where our ideal mechanism is "Verify MAC on first N = bytes, for any N", to one where we're after a scheme which allows "Verify MAC = on entire object minus some (probably contiguous) bytes". These are perhaps sufficiently different problems that different approaches should be = taken. I don't know. Susan: I see your point. I think the "toilet paper" approach could be = made to work in this scheme if we numbered the consecutive = segment,authentication field pairs, but that's just off the top of my = head. I don't really like the complicated nature of the toilet paper = approach, and numbering the segments would just make it further = complicated, so I'm not really advocating it, but it may be the best we = can do. 15. Section 4.4 points out the correct fact that successfully verifying = a MAC means that either the claimed sender or else the verifier created the = MAC. While it might be impossible (given the protocol context) to get these confused, its also considered good practice to ensure at the = crypto-mechanism level that this cannot occur. There are two ways to do this, either = derive keys based on the direction of communication, or else ensure that the = to-be-MACed data includes the sender-id. The former is the preferred way to achieve = this, since the latter is more vulnerable to evolutionary changes to the = protocol, or other re-uses of the MACing keys which don't identify the direction of communication. In this context, where we probably cannot mandate a = single key derivation scheme for all DTNs, maybe the best we can do is to impose a requirement that all key distribution schemes derive different keys for = each direction of communication. (If/when we specify key management schemes = we should really ensure that they all have this property of using different = keys for each purpose in each direction. This is done in TLS and IPSec and = many other reputable protocols and has little or no overhead.) To give = another example, and one that could easily happen, it would be potentially very = bad to use the same symmetric key to authenticate both a BAH and a PSH.=20 Susan: okay. This is not a subject that I know a lot about. Assuming you = are right, we should probably make a note to include this as a = requirement in a key management paper and mention it in section 4.4. 15. The DoS discussion focuses on whether senders are legitimate or not. Generally the more interesting distinction is whether the originator is = on-path or off-path. On-path DoS attacks are harder to make hard, whereas using = random values in counters etc. is quite effective in reducing the probability = of successful off-path attacks. At one stage it is also stated the replays = are difficult to mount; well that may be true or false, depending on the = network in question, but the point is that once you can send in a single packet its = easy to arrange to send in a million, and replaying is your first target if = there's a way for recipients to turn on authentication checks! Susan: Perhaps we need to come up with an explicit description of what = types of DoS attacks we are trying to protect against and what types we = are willing to live with. 16. DoS and replay again. My main concern with the bundling protocol is = to make it harder to mount a battery depletion attack via replays (or more = generally via an adaptive attack). The problem is that many many DTNs will have = nodes which are vulnerable to battery depletion so we just have to do our best = to prevent those nodes being flooded. If bundles can be inserted into the = DTN at some other point(s) with a high probability that they'll eventually = cause traffic (and not even direct traffic, it could be NACKs or equivalent) = to be routed via the target node, then we've got a live DoS vulnerability = which will often partition an entire network. (Note that this is another strong = argument to integrity check the entire payload even hop-by-hop, so that = application layer cheating cannot result in the aimed-for misbehaviour.) Susan: I don't recall battery depletion coming up in previous DTN RG = discussion. It's probably worth bringing up to the larger group. 17. Application layer services. We seem to be agreed on the provision of = data integrity, origin authentication and application layer anti-replay = protection, all of which can be provided using the same mechanism, i.e. digital signature/MAC, most likely using signature due to the ability validate = the signature at multiple locations. All good so far, but let's see the consequences.=20 First, to be able to use MACing end-to-end (which is quite useful, even = if end-to-middle MACing isn't so useful), you need a key distribution = scheme. The examples of IPSec, Bluetooth and WEP, show that failing to provide such = a key distribution scheme limits the scope for deploying networks (ok, this = can be argued since the proximate causes differ in each case, but I belive its substantially true). That means that we need (at some point) to define = one or more ways to distribute symmetric keys end-to-end. Now we could punt on = this and only allow that to occur out of band (e.g. during node = provisioning), but then we'd face the issue of key rollover which really has to be done = in-band. If we do provide in-band key rollover, the we absolutely require (an = equivalent to) an end-to-end confidentiality mechanism to be provided by the DTN, = and not by the applications. Remember that all of this is to maintain end-to-end = MACing to support data integrity, origin authentication and application layer anti-replay, so the lesson is: if you provide end-to-end MACing and want = the network to scale, then you require an end-to-end data confidentiality = mechanism (note, a mechanism, not necesarily a service for applications). Ok, someone who doesn't like this will say that this isn't needed to = support digital signatures. There are, however, cases where an equivalent = mechanism is required. For example, not all nodes can generate key pairs, and when = one of those nodes requires a new private key (required by good cryptographic practice) that must be provided to such a node using a confidentiality mechanism; if a private key must be moved from one node to another, say = when node hardware is being upgraded then again a confidentiality mechanism = is required. If an IBC scheme were to be used, then again the decyptor = would have to deal with the security server and may require a confidentiality = mechanism. There are also some schemes which make use of symmetric keys in order to distribute new trusted public key information. Standard public key = managment protocols like CMP, CMC and XKMS all do include such confidentiality mechanisms. Certainly, this does not mean that every DTN node must include an implementation of a confidentiality mechanism, nor does it mean that the confidentiality mechanism must use the bundling protocol, nor the same = routing, nor need the key distribution protocols necessarily be delay or = disruption tolerant. However, it does require either the secret keys required are = exposed between the endpoints in question, or else that an end-to-end standard = set of key management data structures are required, which provide a fairly = generic confidentialtiy mechanism, at least for small, infrequently sent amounts = of data. The first option was tried by WAP (using TLS and then WTLS) but = was one of the main things which (it was claimed) caused reluctance amongst e.g. = banks to deploy secure banking via WAP (it may be more to the point that = network operators and banks have different buisness models, but nonetheless the = claims were made). And traditionally, end-to-end proponents (most Internet = developers) would argue strongly not to expose keying material in mid-network. So, it appears that at least some, and arguably many, DTN nodes require = an end-to-end confidentiality mechanism, though not necessarily an = end-to-end confidentiality service for applications. The question to ask though = is: given the above, is it really hard to extend this to provide key distribution = for such an end-to-end confidentiality service?=20 Susan: So you are suggesting that it may make sense to provide = confidentiality at the bundle layer instead of requiring applications to = perform their own encryption and decryption? In other words, bundle = agents would perform encryption and decryption? =20 18. Combining end-to-end integrity and confidentiality. The document = currently allows for a flag indicating that the payload is encrypted. It also says = that the PSH digest is calculated over the cleartext payload. This means that whenever the payload is encrpyted, the no middle-host can validate the = PSH, e.g. none of the "security policy routers" get to do their job. There = are good arguments for both ways of doing this (i.e. signing cleartext or signing ciphertext), but signing the cleartext, then encrypting and including = the signature in clear is uncommon and has weaknesses. For example, if the cleartext is guessable, then the signature allows for checking of = guesses. As it stands (i.e. if we reject my #17 above on an end-to-end = confidentiality service), probably best is for the PSH to contain a signature over = ciphertext and for data-origin-authentication to be provided in the same way as confidentiality. (Note the PSH as reforumulated here doesn't provide origin-authentication for the cleartext payload, since its possible that = the signer has stolen the ciphertext if the key managemnet scheme allows = this.) Susan: Does the document really say that the PSH digest is calculated = over the cleartext payload? I did not intend for it to say this and = this is not what I had in mind. Please let me know where it says this. 19. Keys expire in any reasonable setting. Bundles expire too. Therefore = one of the things we have to do is define how these expiries relate. For = example: is it ok for a bundle expiry to succeed the expiry of the key with which = you're about to validate the bundle so long as the key was valid when the = bundle was protected? (SF's answer: probably.) There are a couple of these timing = issues that are fairly easy, but need addressing. Basically, everywhere a key = is used (BAH, PSH and application layer confid or whatever), you have to define = how the key lifecycle and bundle expiry match up. Susan: Yes, these expiration cases would need to be defined. Let's add = it to the list of things to do. 20. The security policy router as sinkhole threat is very serious. If I = could arrange (or know) that fragmentation will occur, as currently = forumulated this probably makes it pretty easy to DoS such a router by simply binning the = last fragment from all bundles that pass you by. (And the you here may not be = a DTN router, but some intra-regional node.) I'm not sure of the best approach = to take here, since it'll depend on the network, but I believe that if we = abandon the idea of "special" security policy routers and allow every router to = have a policy enforcment point, then we may make the problem more tractable. = OTOH, this is probably just a hard problem and hard cases will always exist regardless of how a particular network looks (unless you totally turn = off fragmentation). Susan: I don't understand how allowing every router to have a policy = enforcement point would make this problem more tractable. Susan: Fragmentation is felt to be extremely important in DTNs, = particularly reactive fragmentation, so that the part of the bundle that = was transferred successfully before a connection is lost can proceed on = toward its destination without having to be resent. Turning off = fragmentation is not going to be acceptable; we need to think in terms = of fragmentation being something we need to accomodate. Maybe the right thing (TM) here is to go back to the requirement and momentarily forget about this solution. I belive that fragmentation and = ingress controls were largely motivated by earthstations, where the Earth's = rotation means you have to use >1 station to upload some data to a spacecraft, = but you really want strict ingress controls on the long haul links involved. If = you take the PEP model, then that requirement could be met by having a = single PDP for all of the Earthstations and which is stateful where each of the = PEPs contacts the PDP to check if sending this fragment is ok or not. I'm not entirely sure this is the way to go, but it may well offer benefits = compared to the current "get all the fragments back together" approach. Susan: If I understand you, then for this to work, each Earthstation = would have to provide the fragments that it receives to the PDP so the = PDP could reassemble the payload, verify the PSH, and make the decision. = I've got no problem with defining something like this. In the absence of = such a scheme being defined, however, users need should be forwarned = that unless they pin the bundle's route through the security policy = router (using source routing), the security policy router could become a = sinkhole.=20 21. Combining algorithms. We support either signatures or MACs. Could it = happen that an originator mightn't know which to use for a certain destination? Usually there are a few corner cases where its hard to code this up = correctly. In that case, one might want the option to include both a signature and = a MAC. Personally though I wouldn't do that, its probably better to either = stick to one or else allow any number of independent authenticators (e.g. = including two MACs with successive keys can be useful during rollover periods, and = then a signature for middle boxes to check en-route). For now, I'd be ok with = just a single authenticator in a PSH and this can probably be ignored for BAH = (though if the delay is significant enough, the key rollover problem might hit = MACs occasionally). Susan: I prefer to stick with a single authenticator now also, but good = to bring this up. Do other protocols deal with rollover by allowing two = authenticators, for example, to be included? 22. Using region-native security instead of BAH. This needs to be done a = bit differently. Firstly, to be useful, the interface would have to expose something about how the region secured the bundle - there's a big = difference between WEP and IPSec! There may also be a need to expose some naming information too, e.g. if regional security used SSL, then it may help to = know the name or other stuff from the client certificate if one was used. = Secondly, 10.2 states the either the bundle has a good BAH or else it MUST have = been secured by the region, or else it MUST be discarded. This is wrong, even = with a "NULL security is ok for this region" modifier. Basically, BAH should be optional, as would regional security and the router's PEP has to decide = if the presence or absence of these is required or not in each case. Finally, = IPSec VPNs unfortunately do not offer this information, esp. if the = convergence layer isn't in the kernel, so there's a big class of region security that can = be used but cannot really be asserted to have been used at this layer. (The fix = here is to push up the IP addresses & ports and for the PEP to have a synched-up = view of the IPSec rules. Ugly, but there ya go.) Susan: Is it really required that we expose how the region secured the = bundle? Why is it inadequate to simply have the bundle layer rely on = the assertion of security made by the convergence layer? 23. As an input for section 11: Some DTNs will have a bunch of really challenged nodes at their edges (say sensors) and its only when you get = off that network that the next DTN router ("Alice") will have sufficient CPU = etc. to be able to add a PSH or BAH. I'd like this to be allowed, but = currently the PSH case seems to be prevented. There was some mention of treating this = as a VPN tunnel in Minneapolis, i.e. running bundling in bundling and then = having Alice add a PSH to the outer layer of bundling, but that'd mean there = needs to be another router ("Bob") who's expecting Alice to do this and who's = going to act as the other end of the tunnel. I don't think this works! What I'd = like is for Alice to be able to add a PSH and for the middleboxes and final = destination to be able to decide (via their PEPs) whether that's ok or not for this = bundle. There may also be cases where PSH validation would similarly be done at = a middlebox (say if revocation support is turned on) and the final = destination is in the sensor network. This might also be a useful mechanism to support = some security for sort-of broadcast bundles, where we separately secure the = bundle up to the equivalent of the mail-list exploder and thereafter. Susan: Ahhhhh! (not that I don't like the idea; it's just that = everything keeps getting more and more complicated.) This is sort of = like a "tunnel-mode" DTN security.=20 Itsy-bitsy things: ----------------- Susan: I only responded to those comments below that I didn't understand = or didn't generally agree with.=20 1. LTP and Bundling. I think this document is just addressing bundling. = It ought to be clear that LTP is out of scope here. Having said that, at = some point we ought consider common features, esp. wrt key distribution - I = see no reason for that to differ between LTP and bundling - the inclusion of = some sort of "key purpose" field should be enough to allow handling both. 2. p4, mainly the last para. X.509 certificates already expire, I think = you're saying that short-lived certificates without revocation support may be a = better option than long-lived certificates + revocation. 3. s1.1, para1. I don't think the weakest link argument is that good for networks these days, given the way we use firewalls/VPN-gateways and = other middleboxes. Nor is that text really needed - I'd rephrase the para. to = say that DTN security depends on region security which depends on = intra-region security which depends on host security... 4. s1.3, end. Is secure-DTN-muticast a bridge-too-far? Seems v. = ambitious for this round of work, though perhaps you need it for darpa purposes. 5. s1.4, if this is a standards track document, then this section ought = to be using MUST/MAY/SHOULD, but if its a snapshot, must etc. are fine. 6. s1.4, definition of "source": is this deliberately silent as to the distinction between the "proper" source and a potential spoofer? If = not, then "source" needs to be re-defined to be the originator of the bundle when = first transmitted or similar. I think I'd prefer that definition. Should we = also give name to an attacking network entity? Susan: what terminology do you suggest?=20 7. s1.4: "refers to [3] and [8]" I prefer not to use this style myself, = rather "refers to the bundle protocol specification [3] and the (still TBD) = bundle protocol security specification [8]." 8. s1.4, last para: This seems to be somewhat circular, since we're = motivating security here by referring to the PDUs which are motivated by this. = Maybe this text really belongs in the TBD security protocol spec. 9. s2, 1st sentence: I'm a bit uneasy with language like this that = implies that we "include the capability to...prevent access by unauthorized = applications" - basically, since this is, in general, impossible! Restating this and = others along the lines of "include services and/or mechanisms which...aid in preventing or detecting access by unauthorized applications" would be = better IMO. 10. s3: why are we providing an overview of services that are not = provided? Susan: I thought there was merit in being explicit about what is = included and what is not included as part of the overview. Perhaps that = can be done without saying as much about the services that aren't = provided. 11. s3.1: Arguably, there is no such security service as "protection = against DoS" - the argument being that you cannot prevent or really protect = against all DoSes. Instead, we should aim to provide tools which can mitigate = attempted DoS. So item 4 in the list at the start of 3.1 isn't really right. 12. s3.1.1, 3rd list item: bundle integrity allows detection of = modifications which are not supposed to occur, not those which are. Susan: I'm not sure I get your point. 13. s3.2: The name of this section is odd. Sticking to the "goals" too = closely perhaps. 14. s3.3, 1st sentence: Regardless of what we end up doing *some* DTNs = might well include a security service for replay detection, so the sentence as currently written, is false. 15. Crypto key terminology. The terms "public" and "private" should only = IMO be used wrt asymmetric algorithms like RSA, for symmetric algorithms like = AES, using "secret" is better. This is pretty much the normal usage. 15. Bundle integrity. The term as currently used is somewhat misleading. = I thought that it did include the payload even for the BAH. However, I now realise it doesn't. If we keep this kind of protection, then we ought = not refer to it as bundle integrity but rather as bundle header integrity. Susan: I see your point. This is a terminology problem that has to be = cleared up with the larger DTN group. Scott Burleigh alluded to it at = the last meeting. Technically, there is no concept of a DTN bundle = consisting of a bundle header and a payload (though that is the way we = tend to think about it). A bundle is a collection of headers, and the = payload is just a field in one of the bundle headers. 16. Section 4.3, says: "Therefore, if the private keys of all of the = nodes along the path from source to destination have not been compromised, = then the bundle (except its payload) sent along this path from source to = destination can be verified by the destination node not to have been modified while = in-transit on the path from source to destination." This is false. The missing = clause is something like "and if all the bundle agents are operating correctly, = and without cheating". Note that software integrity is not the only issue, = since sometimes people do include malicious code in the original software, = either accidentally, or perhaps more commonly, intentionally (e.g. spyware of = the various commercial or governmental types:-). 17. Section 4.3, last para: This restates the fallacy from nit #16. 18. Section 4.4.1 and elsewhere. The use of the phrase "decrypt the hash = value" isn't quite correct, for example with HMAC the key is prepended to the to-be-MACed data and CBC-residue schemes use the key for each cipher-block-sized chunk of to-be-MACed data. In both cases, there is no = stage of calculation where there's an unkeyed digest. This isn't a problem for someone used to MACs, signatures etc., but could mislead a naive reader. = Better to talk of MACing/signing and MAC/signature checking. If you simply = explain first time you say "sign" that you include both signatures and MACs then = that's ok (its also done in the xmldsig specifications for example). 19. Section 4.4, "If private key cryptography...", this is an example of = where you really ought say "If secret key cryptography..." 20. Section 4.5, correctly says that you cannot prevent DoS, but goes = wrong in some of the discussion. For example, stating that: "Without valid, = current keys, a secure network can be brought to a standstill" is misguided. In = actual fact, the use of cryptography enables new DoSes (flipping one bit kills = the entire protected block of bytes). I think the right thing to do is just = state the DoS cannot be prevented, but can be ameliorated, and certainly that protocols can be designed to be more or less DoS resistant. There can be = no reason to argue that a DTN should be a priori less DoS resistant. (Ok, I = can't resist: "Despite how futile..." is probably worse than even my = English:-) 21. Setion 4.5.3, 5th list element, says that signatures are more easily = replayed which is true. However, this could be prevented by including (a hash of) the recipient tuple within the signature. (Though note that this isn't standard PKCS#1 padding, it has been done in the past.) Basically, most signatures (esp RSA) involve values significantly larger than the hash-OID+hash-Value which PKCS#1 block type 1 uses and = therefore contain a number of random bytes (from memory about 90+ bytes of random data). There's plenty of room there to include an additional digest or two! Susan: You've lost me here. 22. Section 4.5.3, 6th list element. Its not really good to argue that = DTNs are both more replay resistant and harder-to-protect due to the extended = lifetimes of bundles. In particular, each replayed bundle has a magnified effect = since it'll perhaps persist in the network much longer than in non DTN cases. 23. Section 4.5.3, 6th list element. There are purely local ways in = which a node can protect itself (and not the DTN in general!) against replays. = Simply keep a replay cache of the digests of the inbound bytes, perhaps with additional counts and timing information (though that's not ususally = done). The node can then tailor its response based on the replay status of the incoming message. (Note that the bytes input to digesting can be = ecverything receieved or else some sensible subset, or even multiple subsets so that different partial replays can be spotted and handled as such). The cost = of doing this is memory and CPU for digesting which is normally not that = bad. The hard part here is knowing when to flush the replay cache entries. There = are a range of options,s can be spotted and handled as such). The cost of = doing this is memory and CPU for digesting which is normally not that bad. The hard = part here is knowing when to flush the replay cache entries. There are a = range of options, e.g., simply bounding the cache by size, or else more complex = schemes which flush entries based on age and the number of replay occurrences, = or whatever. (Since this is not an interoperability issue, programmers can = more or less do what they like here.) Finally, if a number of such nodes can = share information about their individual replay caches then the network as a = whole can be given relative good protection. Again this can be done without = impacting the basic protocol except that the rules for what is and is not an = unexpected replay need to be figured out. (This one's probably not really a nit is = it;-) Susan: Are you suggesting that since each node can perform its own = replay detection without impacting the protocol, that we should just = leave it at that and not mention replay detection as part of the = protocol? In other words, it's just something optional that a person = administering a node can do if it occurs to him? (I'm just trying to = understand what you are getting at.) 24. Section 4.5.3.1.1. Each bundle/fragment in the network is uniquely identifiable - by running its bytes through a digest. See #23 above. Susan: Isn't it a lot more overhead to run a bundle through a digest = than simply look at the contents of a small number of its fields? 25. Section 4.5.3.1.2. This only works if the same keying material is in = place allowing the BAH to be validated in both destinations. While it might = happen for signatures, I'd expect MACing to be far more common for BAH. There's = no good reason to have the same symmetric key usable for validation at two different routers. 25. Section 5, 1st sentence: As before (#16) this also requires that the = DTN nodes on the path don't cheat. 26. Section 5.2.1. The description here is a little wrong. The main = problem with originator key compromise is that you don't know where copies of = the key are now available, and therefore you don't get origin authentication. Modifying the bundle in-flight is also possible, but less likely. 27. Section 5.2.2. I think its not really necessary to say things like = this.=20 28. Section 5.3.1. Again, too many words. This could all have been said = in section 5.2. 29. Section 5.4. This has all been said already! 30. Section 6. Again I think this has all been said already. 31. Page 40, says: "A source may use the Source Routing Header to ensure = that a given bundle, and therefore all fragments that may result from that = bundle, will pass through one or more specified security policy routers en route = to its destination." The problem with this is that the "will" is really a = "should" since the header is asking for something and not enforcing it. So if = there's a bad node somewhere on the (DTN or intra-regional) path, it'll still = cheat, maybe by deleting both this header and the BAH, and it may still be able = to arrange a DoS on the "security policy router." 32. Page 40, last para: what's this doing in a section about security policy routers? Susan: Crashing the party. 33. Section 7. This was probably changed after Minneapolis. I'm not sure = if its worthwhile trying to keep it up-to-date or not. Maybe it'd be ok to move = the 2nd para to an earlier section and then delete the section entirely. 34. Section 10.1. The list of algorithms isn't quite right. Using HMAC = means only having one algorithm for #2 and #3, and when using signatures given = the pkcs#1 padding scheme includes the hashing OID in the signature block, = its usual to call e.g. rsaWithSha1 a signature algorithm, rather than saying = we're using sha-1 and we're using rsa. Main thing though is that with MACing constructs you usually can't separate #2 from #3 (nor #4 from #5). Susan: When we write the protocol document we are going to have to come = up with a header format that is versatile enough that it includes the = appropriate fields as determined by the algorithms used. I hope you have = a better idea how to do this than I do. ------=_NextPart_000_00D3_01C536B6.E34C1890-- Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j31EFdV10992 for ; Fri, 1 Apr 2005 06:15:39 -0800 Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id DA7E314C035 for ; Fri, 1 Apr 2005 15:15:28 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A06556C84DC; Fri, 01 Apr 2005 15:15:28 +0100 Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id 7AFD214C035 for ; Fri, 1 Apr 2005 15:15:28 +0100 (IST) Message-ID: <424D5819.4060609@cs.tcd.ie> Date: Fri, 01 Apr 2005 15:18:01 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Subject: Re: [dtn-security] Re: Reference in DTN Security Overview and Motivation References: <200503291631.j2TGV9j25051@smtp-bedford-dr.mitre.org> <424C6044.2070703@sparta.com> In-Reply-To: <424C6044.2070703@sparta.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.660) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A16556C84DC Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: Hi Howie, I agree with you, but I think its even a little worse. Firstly, PEM was an existence proof that rigidly binding naming and key management hierarchies together is liable to not scale. Assuming that all nodes in all DTNs will be named to match some IBE scheme's hierarchal requirements is IMO not wise at all. And once there are multiple independent PKGs in the universe then the encryptor has to map from the decryptor's name to the relevant PKG parameter set (and I don't believe that any current scheme allows arbitrary numbers of independent PKGs to have the same parameter sets, though I could be wrong there, if not now then maybe in future). So, you need a form of "domain-cert" in any case, which maps something like an X.509 NameConstraint extension into a PKG parameter set. That structure had better have origin authentication and integrity or else a bogus PKG can start decrypting intercepted messages. So, hey: we probably need it to be signed. And then, maybe it'll have to be revoked, say whenever the relevant domain installs a new PKG with different parameters. So the encryptor still has to do a status check, i.e. get a CRL or equivalent. The fact that the certificate involved covers an entire domain could be useful for some applications, but only where the encryptor is going to be sending encrypted messages to many different entities in the target domain within a single cache-period. (Given that many IBE schemes attempt to avoid end entity revocation by requiring the decrytor to re-contact the PKG periodically, it may be the case that any such "domain-cert" can also only be cached for a short cache-period.) So I don't believe that this actually helps that much, if at all, for many applications but I guess it might for some. Secondly, I also believe there would be issues with nodes which move from one PKG-domain (whether hierarchical or independent) to another, which would be more likely in a DTN since you'll want to talk to your local PKG in a relatively-non-delayed manner. I don't believe that the IBE schemes currently handle this kind of thing at all, though again, I'm open to being educated some more here. Thirdly, the mandatory-escrow aspect of IBE is an extremely serious disadvantage. While some applications and environments can live with key-escrow there was (in response to the US clipper and other initiatives) a clear concensus amongst at least IETF participants that mandatory key escrow is not something to build into your core protocols. (I no longer have a reference for that list, but there was a raging debate a few years ago on this and the concensus was overwhelming that the IETF at least ought not go there. I don't believe the outcome would differ were the debate to be had now.) Fourthly, while PKI has its problems, it does represent a technology that's mature enough and well enough understood that there are lots of folks available that can figure out how to tweak it to satisfy DTN requirements. (And there's code there too!) We also know how to do things like register into PKIs and kerberos domains, handle changing passwords and keys etc. none of which are solved problems for IBE schemes. Basically, IBE is still much more bleeding-edge compared to other key management schemes. For this last reason and others, there is I believe a winning case to be made for requiring fleixibility in how key management is done in DTNs. Though we will need to define at least one specifc way to do key management - which has IMO to be primarily aimed at supporting interoperability (with lesser emphases on other factors, like crypto-cuteness;-). My own guess is that starting with a PKI or kerberos-like approach is probably best, but I wouldn't rule out someone else figuring out an IBE approach that satisfies some niche at a later date. I'd note in passing though that affording such flexibility means that no "one-size-fits-all" scheme can work, and I believe the IBE scheme proposed below is inherently a "one-size- fits-all" scheme and I'm not sure if there is an existing IBE scheme which doesn't have that property. To summarise: I think IBE is cute and we ought to encourage folks to work on how it might be applied to DTNs (with the contstraint the it has to work as one of possibly many key management approaches). However, I don't believe we should depend on IBE, nor should we wait for the development of a DTN-friendly IBE scheme - we ought to press ahead and define a key management scheme that can work in the nearer term and we ought to focus on a scheme that'll promote interoperability, perhaps even at the expense of other traditionally required features of key management schemes (and there's a separate discussion to be had about that!). Regards, Stephen. Howard Weiss wrote: > Susan, > > I went thru Rabin's paper and your comments. Nothing I've seen so far > has changed my opinion regarding IBE - I don't think it solves anything > wrt DTN. For example: > > 1. On encrypting a transmission, the source gains a "win" by not having > to cache the destination's public key or consult a certificate > authority. However, the source does have to cache the destination ID > information (which is presumably much smaller than a certifcate but > nevertheless, its infomation that somehow has to be arrived at and > cached). The destination loses because its got to go to a PKG to get > a private key to match the source. I guess the private key could be > cached but there is still a first time penalty. Bottom line: a zero sum > gain. > > 2. On signing, the sender has to obtain a private key for the > destination from a PKG or have the private key already cached. The > destination "wins" by not having to consult with any server to > authenticate. Another zero sum gain. > > One side wins at the expense of the other side. This scheme seems like > it would work well if there are many encrypting sources but few > receivers. The win is that the sources don't have to consult with any > servers (or use precious cache space) before sending. But the > destination has to pay the piper because of the number of private keys > that have to be obtained or cached. > > In either a PKI-like instantiation or an IBE-like instantiation, there > is still a trusted 3rd party server involved that must be consulted. I > can envision ways in a PKI instantiation where there are no servers > (e.g., I only have a DTN CA cert and I need to talk to entity A so I > first send a "hello" to A and attach my public signed by the DTN CA; A > replies with "how are you" and sends its public, also signed by the DTN > CA back to me; now I can send something encrypted - costs one round trip > but does not involve an 3rd party server than could also be a single > point of failure). I can't see how this could be done with IBE - at > least its not clear to me. > > Just my 2 cents. > > Howie > > Susan F. Symington wrote: > >> Howie, >> >> I have attached the paper. I had thought it was sent out in >> dtn-interest but I just checked and you are right, it was sent to me >> and two other people. You may want to mention to Kevin to tell Rabin >> to add you to his list so if he ever updates it, you will be included >> in the mailing. >> >> I am also attaching the comments that I sent back to Rabin. >> >> -susan >> >> ------------------------------------------------------------------------ >> *From:* Howard Weiss [mailto:Howard.Weiss@sparta.com] >> *Sent:* Monday, March 28, 2005 5:38 PM >> *To:* Susan F. Symington >> *Subject:* Reference in DTN Security Overview and Motivation >> >> Susan, >> >> I am going through your DTN security overview and motivation and >> came across a reference to a paper: >> >> Patra, R.; "Using Identity Based Crytography for Security in >> DTNs," December 2004. >> >> I haven't seen this - I have only heard Kevin allude to someone >> looking at IBE. If you have it, can you send it to me? >> >> Thanks, >> >> Howie >> >>-- >>Howard Weiss >>SPARTA, Inc. >>7075 Samuel Morse Drive >>Columbia, MD 21046 >>410.872.1515 x201 >>410.872.8079 (fax) >> >> >> >>------------------------------------------------------------------------ >> >>Using Identity based Cryptography for Security in DTNs >>------------------------------------------------------ >> >>This proposal describes an architecture based on Hierarchical Identity Based >>Encryption for providing security features in DTNs. >>The aim is to provide confidentiality and integrity >>for end-to-end communication as well as protection of the DTN >>infrastructure and efficient implementation of access control in a >>heterogeneous environment of hosts having varied connectivity. >> >> >>The requirements for such a security architecture in DTNs are : >>1> Implicit certification: >> This means that a source(A) should be able to encrypt and send a bundle to the >> destination(B) by using only B's public information such that B will be able >> to decrypt the message only if it is currently certified [9]. >> Otherwise, senders will have to explicitly verify the current status of >> receivers (whether their public keys are still valid) from a third-party >> trusted authority. >> - we also don't want senders to store for each possible destination either >> a) a shared private symmetric key or b) a public key >> - third party certification queries may also be difficult in DTN like >> heterogeneous environment where the server that has the ability to certify B >> is in a different administrative region than A. >> - we also want to ensure that no single entity is forced to handle all >> certification queries/requests - this will lead to overload and increased >> latency for queries. >> >>2> Control over revocation over different time scales: >> Implicit certification eliminates the need for the sender to perform >> third-party certificate status queries. But in a DTN heterogeneous >> environment where hosts with different levels of vulnerability might >> exist, we also want allow the system ( or the certificate >> authorities) to choose between between fine grained or coarse grained >> revocation for each host. >> i.e if a user is more trusted, the system might want to re-certify >> keys only every month as opposed to doing it every day. >> >> >>3> Authentication for infrastructure access control: >> As already suggested in [1], bundles should carry two headers i.e PSH that >> is signed by the original source, and BAH that is signed at each hop by the >> sender router. >> Thus we need two different types of authentication mechanisms: >> Router authentication (in BAH): This is used by routers to authenticate >> the previous hop routers. Every router might have its own specific access >> control policy for each router it interacts with. >> Though this implies that it needs to be aware of their identities, >> it can be feasible as the routers might need to know only their >> immediate neighbors in the DTN. >> Source authenticating (in PSH): >> - This is used for end-to-end integrity of the bundles. >> - It is used by the destination host for authentication of the source of bundle. >> - It can also used by routers for global policy access control using >> the identity of source endpoints. As routers cannot be >> possibly be aware of all the sources in the world, it would make more sense >> if these rights are encoded in the credentials (or a certificate) >> presented by the source along with the bundle. >> For example, if a source is given permission to send all its traffic >> in the 'Urgent' class by the system, the all routers need to support this. >> - Instead of using certificates (which can be long) for encoding the >> rights of the source, we want these rights to be encoded in the >> identity of the source endpoint. >> Then a successful authentication of the identity of the >> source should mean that source has obtained that particular identity >> from the system. >> For example: A source 'A' possessing 'Urgent' class would have the >> identity 'A.Urgent'. We need to make sure that these identities can >> only be provided by the system and cannot be forged by some adversary. >> - This would also mean that identities of would have to be part of the >> bundle in the PSH. >> >>4> Complex access control policies: >> As DTNs can conceivably have multiple classes of service, >> we need efficient ways to represent more complex access control policies. >> One way is to support policies over simple boolean expressions. >> For example: for source A: Urgent OR Bulk class traffic. >> >> >>Assumptions and Threat Model: >>----------------------------- >>1> The DTN can have global access control policies that need to recognized by >> all routers in all administrative regions. However routers can have their >> own specific access control policies. (it is not clear if these should be >> allowed to override the former). >>2> There is a set of trusted servers in the DTN that cannot be compromised by >> adversaries. These servers will be used for key issuance, management and >> revocation. >> Other hosts (including routers) in the DTN can be compromised. >>3> Adversaries can eavesdrop on all traffic, they can capture bundles >> and also modify in flight bundles. >> >> >>Types of Attacks: >>1> Routing level attacks : Adversaries on compromising routers can >> can change routing entries to create routing dead-ends or loops. >>2> Infrastructure level attacks: Adversaries can try to access the DTN >> infrastructure without authorization. >> They can try to flood the network or send bundles with >> classes of service that are not allowed. >>3> Data level attacks: Adversaries can eavesdrop on traffic and try to compromise >> the confidentiality and integrity of the bundles in the DTN. >> They can replay bundles. >> >> >> >>Proposal: >>--------- >>The basic proposal is to use a combination of Hierarchical Identity based >>encryption (HIBE) and signatures (HIBS). >> >> >>IBE in brief: >> An Identity Base Encryption (IBE) scheme is a public-key cryptosystem where >> any string is a valid public key. In particular, email addresses and dates >> can be public keys. >> When Alice sends mail to Bob at bob@hotmail.com she simply encrypts her >> message using the public key string ``bob@hotmail.com''. There is no need for >> Alice to obtain Bob's public key certificate. When Bob receives the >> encrypted mail he contacts a third party, the Private Key Generator (PKG), >> Bob authenticates himself to the PKG in the same way he would authenticate >> himself to a CA and obtains his private key from the PKG. >> >> IBE scheme consists of four algorithms: >> (1) Setup: The PKG generates global system parameters and a master-key. >> The global system parameters need to be distributed to all hosts >> initially. >> (2) Extract: The PKG uses the master-key to generate the private key >> corresponding to an arbitrary public key string ID, >> (3) Encrypt: Source(A) encrypts messages using the public key ID of the >> destination, B. >> (4) Decrypt: B decrypts messages from A using the corresponding private key >> that it obtained from the PKG. >> >> IBE has been proven to be secure against chosen cipher-text attacks in the >> random oracle model. >> For more details please refer to [7] >> >> IBE based signatures schemes have also be proposed where the source can >> sign using its private key and the signature can be verified using the >> public ID string. >> >>Hierarchy IBE [9] in brief: >> The main problem of plain IBE where the single PKG has to issue private >> keys for all users is mitigated by creating a hierarchy of PKGs. >> Hierarchy is established in the form of a tree where each >> (and root) node can be a separate PKG. >> The identity of a particular node at level t is given by its >> ID-tuple (ID1,ID2..IDt) where ID_i corresponds to the i-th level node. >> For key extraction, each PKG(root or lower level one) at level t may >> obtain the private keys for its immediate children with ID tuple >> (ID1,ID2..IDt,ID_t+1). >> Encryption and decryption proceed similarly as IBE and the ID Tuple is used >> as the public key. >> Similar scheme can be developed for Hierarchical IB Signatures. >> It is also proven that HIBE is secure against collusion among lower level >> PKG servers. >> >>Bundle Transmission: >>1> The source first uses the destination node's public ID string to encrypt >> the bundle. This cipher-text forms the payload of the bundle. >>2> The PSH is then created over the payload and header (with appropriate >> fields zeroed out) by signing with the >> source endpoint ID ( that encapsulates the requisite access control permissions). >> The integrity can be verified and the source identity can be >> authenticated by all routers. >> This was one of the features desired in [1] (point 12). >>3> The BAH is created at each hop by the sending router. This can be done >> using some other cryptographic scheme (symmetric or assymmetric) also. >> >>Now lets see how the different requirements specified are solved: >>1> Implicit certification: >> As is clear from the basic definition of IBE, a source need not know the >> public key of the destination before sending a bundle. >> The burden of ensuring updated certification now rests on the >> destination that now has to obtain the current valid private key >> to be able to decrypt a received bundle. >> >>2> Use of hierarchy: >> This offers us two advantages: >> a> Efficient key distribution: Normal IBE has only one PKG server which >> possesses the master key. This PKG is responsible for extracting private >> keys of all the users of the system. >> By using hierarchy - a) we can first place local PKGs in every region so that >> destination nodes dont have to go far to get their private keys and >> also b) compromise of a lower level PKG does not compromise the whole >> system (as the master secret resides with the root PKG only). >> The naming scheme in HIBE also derives naturally from the naming in the DTN >> architecture where the endpoint address consists of two parts - region >> ID and the region-specific ID. >> For example: if the endpoint address for Bob is 'bundles://Earth/Bob_IP', then >> a PKG can be placed on Earth with ID:'Earth'. For larger regions, we can >> further create more levels in the hierarchy. >> >> b> Revocation control: >> We do this by creating a sub-hierarchy for each host (in addition to the >> hierarchy over multiple PKGs created for key distribution). >> The levels in this sub-tree would reflect the degree of control desired >> for revocation. Senders will use the ID tuples corresponding to the >> leaves of this tree for encryption. >> As this sub-tree is completely located at a particular >> host, the host can act as a PKG and extract private keys for this tree >> on its own. We can control the leaves for which the host is able to generate >> private keys for itself by providing it private keys for only selected >> internal nodes of this tree. >> For example: the first level could be month, the second level date and >> the third level: hour. Then the ID of a user Bob (in region Earth) would be >> Earth.Bob.May.24.12pm . >> - The Earth region PKG can extract private keys for all IDs of the form >> 'Earth.*'. The Earth PKG can then choose to give Bob the private key >> for 'Earth.Bob' if Bob is a highly trusted user. Now Bob can generate all >> keys of the form 'Earth.Bob.... >> - A less trusted user 'Alice' will be given the private key for >> 'Earth.Alice.Nov' only - this will allow Alice to read messages only for >> month of November. For a bundle encrypted with the full ID string >> Earth.Alice.Nov.25.12pm, Alice will be forced to ask a new private >> key every hour. >> - For more paranoid uses, an extra level of the this tree could be a >> random ID. This would force the receiver to acquire a new private key >> for each bundle it receives. A sender can now encrypt the bundle >> with 'Earth.Alice.Nov.25.12pm.'. >> - A sender that wishes lower security( and lower latency) for a >> session can now encrypt it with 'Earth.Alice.Nov.25.12pm.0000', and Alice >> would have to go to the Earth PKG only once to decrypt this bundle. >> In general, the PKG server responsible for a user needs to compute a >> subset cover over the user subtree i.e the minimum set of nodes that cover >> all the IDs that are allowed and none of the IDs that are not allowed >> for that user. Then it needs to extract private keys for only those >> nodes in the subset cover. >> >> c> Fine grained access control: >> A similar scheme as above can be used for forming ID strings needed for >> authentication and access control as well. >> For this source users sign the bundles with the correct privilege >> desired. For example, if Alice desires 'Urgent' class of service, it will >> need to sign the bundle with the identity 'Alice.Urgent'. For this it >> needs to possess the private key corresponding to 'Alice.Urgent'. >> Possession of a private key corresponding to an identity >> implies that the system also authorized you for the rights that are >> associated with that identity. >> This is possible in IBE because all private keys are generated by the PKGs. >> The same hierarchical ID structure can be used for revocation and >> granting of rights as well. The subtree below each host >> would now represent different privileges. >> For example: A highly valuable Bob can be given access to all classes >> of service by providing the private key for 'Earth.Bob.Nov.25' - Bob can >> then generate keys for 'Earth.Bob.Nov.25.Urgent' etc and use them for >> signing his bundles. >> A less valuable 'Alice' will only be given the private key for >> 'Earth.Alice.Nov.25.Bulk'. >> However this mechanism requires the ID string to be included >> in the bundle header(PSH) for routers to use the correct key >> for authentication. >> This issue was raised in [1] as well for key rollover. >> This overall method of encoding the permissions of the user in the ID >> string is very similar to using accompanying certificates in traditional PKI. >> >>Why not PKI?: >>------------- >>1> Implicit certification is not possible as a source host is forced to >> first acquire the identity(public key) of the destination before sending >> any bundle. It is also forced to check >> whether the destination is currently certified or not by making third-party >> queries. >>2> Revocation is made much difficult in DTN and solutions like maintaining >> a Certificate Revocation List(CRL) does not work for DTNs. >> >>Other issues and Disadvantages: >>------------------------------- >>1> Key escrow: >> In IBE, the PKG can generate private keys for all users and thereby decrypt >> bundles destined for all users. This may not be always desirable. >> A related property is 'non-repudiability' which means that a receiver can >> prove that only the sender could have signed the bundle. >> Also, the compromise of the root PKG jeopardizes the entire system >> and all messages that were sent in the past. >> >>2> Standards issue: >> Since we try to encode revocation control(date etc) and access control >> identifiers in the ID strings, all entities in the DTN need to agree on a >> common format. This is similar to the problem faced in traditional PKI >> over the format of certificates. >> >>3> Distribution of private keys: >> Since users ask the PKGs to generate private keys, they have to be transmitted >> securely from the PKGs. This might mean that the PKGs share another key >> with every user just for the purpose of sending private keys. >> >>5> Distribution of system wide public parameters >> An IBE system installation needs to bootstrap all hosts with >> the public system parameters of the PKG. >> This also might need to be updated if the root PKG is compromised. >> >>6> Replay attacks: >> Although we guarantee confidentiality and integrity, we do not have any >> mechanism to detect and handle replay attacks. >> >>Other options and optimizations: >>-------------------------------- >>1> Use of Certificate Based Encryption [8]: >> The 'key escrow' problem can be solved by using this variation where users >> are allowed to generate their own private keys. >> Senders are now able to user long lasting public keys without the need >> to worry about the current certification status of the destinations. >> This also solves the problem of securely delivering extracted private keys >> to each user. >>2> Reducing overhead of using hierarchical IBE: >> Normal HIBE, both the length of signatures and the number of steps required >> for encryption are proportional to the number of levels in the ID tree. >> Some techniques based on the BGLS aggregated signature scheme can be used >> to reduce the decryption complexity. >>3> If non-repudiability is not desired, them the scheme proposed in [10] can be >> used. Here the the MAC for authentication is same as the cipher-text for >> encryption. It also uses the same public IDs and private keys as the standard >> scheme. So we can get both authentication(+integrity) and secrecy with >> little extra cost. >> >> >>Implementation in DTN2 : >>----------------------- >>1> What are the basic building blocks that need to be supported in the DTN2 >> architecture. >>2> User management: [1] suggested that the DTN agent cannot possess the >> private keys. Applications should store the keys and call external >> entity to perform the encryption. >> >> >> >> >> >> >>References: >>----------- >>[1] Email correspondence on the dtn-interest mailing list >>[2] Draft: "Identity based Encryption for Delay Tolerant Networks" >> A. Chakrabarti and K Fall. >> summary: proposes the use of IBE for both confidentiality as well >> as access control management in DTNs. >>[3] Draft: "A Secure Tetherless Computing Architecture" by S.Keshav et al. >> summary: proposes a hierarchy of PKGs using HIBE and HIBS for efficient >> key management in the TCA. >>[4] "Exploiting Hierarchical IBE for Access Control to Pervasive Computing >> Information" >> Urs Hengartner and Peter Steenkiste >> summary: proposes use of HIBE for both "encryption-based" and >> "proof-based" access control for client-server interactions. >> More emphasis on preventing leakage of information about access control >> policies >>[5] "Hidden Credentials" >> >> summary: use of IBE for hidden credential trust negotiation. >>[6] "Identity based signatures" >> Paterson >> summary: one scheme for signatures based on the Boneh/Franklin scheme. >>[7] "Identity based Encryption based on the Weil Pairing" >> Boneh and Franklin >> summary: this introduces the first concrete IBE scheme. >>[8] "Certificate-Based Encryption and the Certificate Revocation Problem" >> Craig Gentry >> summary: this talks about mitigating problems in IBE by proposing >> Certificate based Encryption(CBE) in which users can choose their own >> private key. >>[9] "Hierarchical ID based Cryptography" >> Gentry and Silverberg >> summary: this extends the Boneh/Franklin IBE scheme >>[10]"Authenticated Identity-based Encryption" >> Ben Lynn >> summary: extends the Boneh/Franklin scheme to provide integrity of the >> message being encrypted. >> >> >> >> >> >>------------------------------------------------------------------------ >> >>Rabin, >> >>Thank you very much for sending me your draft proposal for using IBE for security in DTNs. I appreciate having the opportunity to review it. There are a lot of good things in this paper. Of course, I won't be dwelling on them in my comments, it being the nature of comments to focus on areas that could be improved or clarified. I just want to make clear that my general reaction is very positive before I start pointing out areas that got me thinking. >> >>1. In your "Requirements" section, it seems to me that you have an additional implicit requirement that you really should make explicit, and that is the reuqirement of "Implicit public key distribution". This may seem obvious to someone who has been immersing himself in papers on IBE, but for the rest of us it is a novel concept, and I don't think it should be conflated with the concept of "implicit certification" as it now seems to be. By "Implicit public key distribution" I mean the ability of a user to derive the public key of an arbitrary user from some known information, such as his identity, thus eliminating the need for the user to obtain the public key from a third-party. I think your proposal would be more clear if you were to explicitly list "implicit public key distribution" (or whatever you choose to call it) as a separate requirement. It would also help to clarify the essence of "implicit certification", which is to addresses the issue of how a user who uses a p >>ublic key derived from known information can be sure that the public key is still valid. The concept of getting the public key is separate from the concept of determining that the public key is still valid, and they should be treated as separate concepts. >> >>2. Also in the "Requirements" section (#3, Authentication for Infrastructure access control) you say that you want the source's rights (permissions) to be encoded in the identity of the source endpoint. But the permissions that are being requested are already encoded in the COS field. It seems a waste to also put the COS information in the source ID field. If the public key that is necessary to authenticate the bundle signature consists of a standard string composed of: >>source endpoint id.COS.day/month/year/time(depending on granularity desired) then there is no need to put the COS information in the source ID field. >>By using the COS field as part of the public key encoding, you would have a straightforward mapping between the public key used both to authenticate the bundle and to thereby certify the right of the source to use this class of service, and the class of service rights that the bundle is requesting. This way, only the source ID and the validity period need be encoded in the source ID field. (Also, you may want to consider having the validity period encoded in a separate field of the bundle header rather than encoding it as part of the source ID field.) >> >>3. In your section with the heading "Assumptions and Threat Model:" you have an aside stating that it is not clear if a given router's own specific access control policy should be allowed to override the global DTN access control policies that need to be recognized by all routers. My opinion is that a given router's own access control policy should be allowed to be more restrictive than the global access control policy, but it should not be allowed to be less restrictive than the global access control policy. In other words, all routers should be able to depend on all DTN bundle agents to enforce a given level of access control in determining what traffic they admit to the DTN from DTN applications; if a given router wants to be more restrictive on a given link within the DTN, that's its prerogative, and it should be able to do so (in fact, as I see it, the ability to be more restrictive is the whole point of having security policy routers). >> >>4.In the "Types of Attacks" section you mention that adversaries may create routing loops. It should be noted that this is a problem that we have not yet addressed. Right now we don't have a way in the protocol to detect such an attack, and we don't really plan to be able to detect replays, so it isn't clear if or how we are planning to address this threat. >> >>5. In the "Bundle Transmission" section, step 2 does not make sense to me, and I think it may be an error that needs correcting. You say that the PSH is signed with the source endpoint ID. Don't you mean that it is signed with the PRIVATE KEY that corresponds to the source endpoint ID (and, if you accept my suggestion in item 2 above, it would be the private key that corresponds to the string formed by "source endpoint ID.COS.validity_time_period")? Then, any receiver can authenticate the source identity and its permissions by using the public key that is derived from the source endpoint id (or that may be exactly the source endpoint ID). >> >>It should be noted (assuming I am understanding it correctly) that for any given validity time period, a single source may need to have as many as n private keys, where n is the number of different classes of service that can be represented. >> >>6. In the "Bundle Transmission" section, step 3 surprises me. Don't you want to make a suggestion about how the BAH should be authenticated, or are you just leaving this for a later paper? If you are going to leave it out, which would be fine, then you should probably go back and refocus the paper to make it clear that you are really "only" addressing the end-to-end confidentiality and integrity security features of DTNs as provided by the PSH and "efficient implementation of access control in a heterogeneous environment of hosts ..." as provided by the PSH, but that discussion of infrastructure protection isn't within the scope of this paper. >> >>7. In your "Now lets see how the different requirements specified are solved:" section, you don't step through all the requirements that you originally proposed. This sort of thing causes those of us who are obsessive compulsive to develop all sorts of ticks and twitches. Addressing each requirements as it was originally raised would give readers like me just the sort of false sense of security that I need to sleep well at night. >> >>8. In item 1 (Implicit certification) of the "Now lets see how the different requirements specified are solved:" section, you say that "a source need not know the public key of the destination before sending a bundle". I think you really mean two things (and this goes back to my suggestion that you separate the concepts of key distribution from key certification). I think you mean: >> a) a source need not "look up" (as opposed to "know") the public key of the destination, and >> b) a source need not obtain a destination's certification status before sending encrypted data to the destination as the bundle payload. >> >>9.In the "b> Revocation control:" section, it is worth noting (if I understandthe proposal correctly and completely) that the revocation mechanism being used is key expiration. There is no way to explicitly invalidate or revoke a private key from a user at an arbitrary time, once the key has been given to the user. Therefore, if a user Alice has been given a private key corresponding to the public key "Alice.October", this key will continue to work through midnight on October 31, even if this key is compromised on October 1. For 30 more days, sources sending to Alice will encrypt bundle payload destined for Alice and send it to her thinking that its confidentiality is being protected even though it isnt. Therefore, the selection of the duration of a key's validity time period is an important choice and it would be good to make this clear to the reader. >> >>Also, it isn't clear what the relationship is between the key's validity time period and the current real-world time. Is this relationship checked at the sender or at the recipient, or both? And how exactly is it checked? For example, >>If the current month is March, will a sender be allowed to encrypt a bundle that is being sent to Alice using the public key Alice.April? How about using the public key Alice.February? >>It seems that if the current month is March, senders should not be allowed to encrypt a bundle that is being sent to Alice using the public key Alice.February because the Alice.February key has expired and therefore it cannot be assumed to be safe to use it. >> >>If Alice receives a bundle in the month of April but the bundle had been encrypted during the previous month, with the Alice.March key (which may very well happen in DTN), then what should Alice do? If she has cached the Alice.March key, then she will be able to decrypt the message, but should she? is her private key still valid? >> >>In other words, validity time periods may be such that a message that is sent during a validity time period will not be received until after that period is over. How should this be dealth with? >> >>10. In the "Why not PKI?:" section, I am not convinced by your argument that the IBE scheme is better than the PKI scheme because when using PKI, the source host is forced to check whether the destination is currently certified or not by making third-party queries before it can send an encrypted bundle to the destination. (This is related to my comment in 9 above.) In a PKI scheme, when a source receives a destination's public key from the CA, can't that key come with a validity period, that says the key is good for the month of October, for example, and then it expires after that. If so, the source would not have to check the validity of that key before using it anytime during the month of October. The result is very similar to the result you get when using the IBE scheme using the sub-hierarchy scheme that corresponds to the month/day/hour of validity. In this respect, I don't see how the IBE scheme is any better than a PKI scheme that issues keys with validity time peri od >>s. Am I missing something? Both schemes seem to suffer from the fact that explicit revocation is not possible, making it impossible to revoke a certificate before its intended expiration date. At least in the PKI scheme it would be possible for a sender to query the CA to inquire whether the public key is still valid. There does not seem to be any analogous way for a sender using IBE to make such a query. To be safe, the user would have to use a random ID field in the ID string, in effect requiring a new public key to transmit each bundle (and therefore a new private key to decrypt each bundle). Distribution of the private key from the PKG to the DTN node is a not without its costs. Is there really an advantage to IBE over PKI in the respect that you mention in this section and, if so, can you please state it more clearly? >> >>11. In general, the paper would benefit if you were to make a more clear separation between the use of (and benefits of using) IBE for encrypting data versus for authenticating data, because those two operations are essentially the inverse of each other and they may be performed simultaneously on a given bundle sent in DTN. If the application data unit is encrypted and the bundle is signed using the PSH, then it isn't clear how the necessary public key and key validity information for both keys would be conveyed from source to destination. Your proposal talks of using the source ID field to convey the information necessary for the recipient to obtain the public key required to verify the bundle's PSH signature. How would the recipient know how to obtain the appropriate private key that it would also need to decrypt the application protocol data unit (APDU)? For example, if I understand your proposal correctly: >> >>On a bundle sent from Bob to Alice: >> >>Bob encrypts the APDU using the public key Alice.October and >>Bob signs the bundle (in the PSH) with the private key corresponding to Bob.October.25.Urgent >> >>Upon receipt of the bundle, Alice would first use the public key Bob.October.25.Urgent to verify the signature in the PSH. Assuming the signature verified correctly, Alice would now get from her PKG (if she doesn't already have it) the private key corresponding to Alice.October and use it to decrypt the APDU. >> >>According to your proposal, the source ID has the information "Bob.October.25.Urgent" in it, so this is how Alice knows what public key to use to verify the signature in the PSH. How does Alice know that she needs the Alice.October private key (as opposed to the Alice.October.25 private key) to decrypt the APDU? Is this string merely put into a new encryption keyID field that is carried in the bundle header? >> >>12. I hope IBE really woudl be secure in a DTN application and that that it will stand up to the test of time and increased scrutiny. It seems to be a genuine breakthrough that lots of folks have latched onto, but I don't feel qualified to make a judgement on its technical merits. Given that it hasn't had the scrutiny of PKI, I think it's important that DTN be designed so that it will work with both PKI and IBE. We need to be careful to define the protocols so that they don't have any hidden dependencies on the use of IBE. >> >>13. What about implementing IBE. Are there any implementations readily available that can be used with DTN2 or will this be something that will require a lot of development? >> >>Again, thanks for the opportunity to review this. I hope my comments help. >> >>-susan >> >>*********************************************************************** >> >>Using Identity based Cryptography for Security in DTNs >>------------------------------------------------------ >> >>This proposal describes an architecture based on Hierarchical Identity Based >>Encryption for providing security features in DTNs. >>The aim is to provide confidentiality and integrity >>for end-to-end communication as well as protection of the DTN >>infrastructure and efficient implementation of access control in a >>heterogeneous environment of hosts having varied connectivity. >> >> >>The requirements for such a security architecture in DTNs are : >>1> Implicit certification: >> This means that a source(A) should be able to encrypt and send a bundle to the >> destination(B) by using only B's public information such that B will be able >> to decrypt the message only if it is currently certified [9]. >> Otherwise, senders will have to explicitly verify the current status of >> receivers (whether their public keys are still valid) from a third-party >> trusted authority. >> - we also don't want senders to store for each possible destination either >> a) a shared private symmetric key or b) a public key >> - third party certification queries may also be difficult in DTN like >> heterogeneous environment where the server that has the ability to certify B >> is in a different administrative region than A. >> - we also want to ensure that no single entity is forced to handle all >> certification queries/requests - this will lead to overload and increased >> latency for queries. >> >>2> Control over revocation over different time scales: >> Implicit certification eliminates the need for the sender to perform >> third-party certificate status queries. But in a DTN heterogeneous >> environment where hosts with different levels of vulnerability might >> exist, we also want allow the system ( or the certificate >> authorities) to choose between between fine grained or coarse grained >> revocation for each host. >> i.e if a user is more trusted, the system might want to re-certify >> keys only every month as opposed to doing it every day. >> >> >>3> Authentication for infrastructure access control: >> As already suggested in [1], bundles should carry two headers i.e PSH that >> is signed by the original source, and BAH that is signed at each hop by the >> sender router. >> Thus we need two different types of authentication mechanisms: >> Router authentication (in BAH): This is used by routers to authenticate >> the previous hop routers. Every router might have its own specific access >> control policy for each router it interacts with. >> Though this implies that it needs to be aware of their identities, >> it can be feasible as the routers might need to know only their >> immediate neighbors in the DTN. >> Source authenticating (in PSH): >> - This is used for end-to-end integrity of the bundles. >> - It is used by the destination host for authentication of the source of bundle. >> - It can also used by routers for global policy access control using >> the identity of source endpoints. As routers cannot be >> possibly be aware of all the sources in the world, it would make more sense >> if these rights are encoded in the credentials (or a certificate) >> presented by the source along with the bundle. >> For example, if a source is given permission to send all its traffic >> in the 'Urgent' class by the system, the all routers need to support this. >> - Instead of using certificates (which can be long) for encoding the >> rights of the source, we want these rights to be encoded in the >> identity of the source endpoint. >> Then a successful authentication of the identity of the >> source should mean that source has obtained that particular identity >> from the system. >> For example: A source 'A' possessing 'Urgent' class would have the >> identity 'A.Urgent'. We need to make sure that these identities can >> only be provided by the system and cannot be forged by some adversary. >> - This would also mean that identities of would have to be part of the >> bundle in the PSH. >> >>4> Complex access control policies: >> As DTNs can conceivably have multiple classes of service, >> we need efficient ways to represent more complex access control policies. >> One way is to support policies over simple boolean expressions. >> For example: for source A: Urgent OR Bulk class traffic. >> >> >>Assumptions and Threat Model: >>----------------------------- >>1> The DTN can have global access control policies that need to recognized by >> all routers in all administrative regions. However routers can have their >> own specific access control policies. (it is not clear if these should be >> allowed to override the former). >>2> There is a set of trusted servers in the DTN that cannot be compromised by >> adversaries. These servers will be used for key issuance, management and >> revocation. >> Other hosts (including routers) in the DTN can be compromised. >>3> Adversaries can eavesdrop on all traffic, they can capture bundles >> and also modify in flight bundles. >> >> >>Types of Attacks: >>1> Routing level attacks : Adversaries on compromising routers can >> can change routing entries to create routing dead-ends or loops. >>2> Infrastructure level attacks: Adversaries can try to access the DTN >> infrastructure without authorization. >> They can try to flood the network or send bundles with >> classes of service that are not allowed. >>3> Data level attacks: Adversaries can eavesdrop on traffic and try to compromise >> the confidentiality and integrity of the bundles in the DTN. >> They can replay bundles. >> >> >> >>Proposal: >>--------- >>The basic proposal is to use a combination of Hierarchical Identity based >>encryption (HIBE) and signatures (HIBS). >> >> >>IBE in brief: >> An Identity Base Encryption (IBE) scheme is a public-key cryptosystem where >> any string is a valid public key. In particular, email addresses and dates >> can be public keys. >> When Alice sends mail to Bob at bob@hotmail.com she simply encrypts her >> message using the public key string ``bob@hotmail.com''. There is no need for >> Alice to obtain Bob's public key certificate. When Bob receives the >> encrypted mail he contacts a third party, the Private Key Generator (PKG), >> Bob authenticates himself to the PKG in the same way he would authenticate >> himself to a CA and obtains his private key from the PKG. >> >> IBE scheme consists of four algorithms: >> (1) Setup: The PKG generates global system parameters and a master-key. >> The global system parameters need to be distributed to all hosts >> initially. >> (2) Extract: The PKG uses the master-key to generate the private key >> corresponding to an arbitrary public key string ID, >> (3) Encrypt: Source(A) encrypts messages using the public key ID of the >> destination, B. >> (4) Decrypt: B decrypts messages from A using the corresponding private key >> that it obtained from the PKG. >> >> IBE has been proven to be secure against chosen cipher-text attacks in the >> random oracle model. >> For more details please refer to [7] >> >> IBE based signatures schemes have also be proposed where the source can >> sign using its private key and the signature can be verified using the >> public ID string. >> >>Hierarchy IBE [9] in brief: >> The main problem of plain IBE where the single PKG has to issue private >> keys for all users is mitigated by creating a hierarchy of PKGs. >> Hierarchy is established in the form of a tree where each >> (and root) node can be a separate PKG. >> The identity of a particular node at level t is given by its >> ID-tuple (ID1,ID2..IDt) where ID_i corresponds to the i-th level node. >> For key extraction, each PKG(root or lower level one) at level t may >> obtain the private keys for its immediate children with ID tuple >> (ID1,ID2..IDt,ID_t+1). >> Encryption and decryption proceed similarly as IBE and the ID Tuple is used >> as the public key. >> Similar scheme can be developed for Hierarchical IB Signatures. >> It is also proven that HIBE is secure against collusion among lower level >> PKG servers. >> >>Bundle Transmission: >>1> The source first uses the destination node's public ID string to encrypt >> the bundle. This cipher-text forms the payload of the bundle. >>2> The PSH is then created over the payload and header (with appropriate >> fields zeroed out) by signing with the >> source endpoint ID ( that encapsulates the requisite access control permissions). >> The integrity can be verified and the source identity can be >> authenticated by all routers. >> This was one of the features desired in [1] (point 12). >>3> The BAH is created at each hop by the sending router. This can be done >> using some other cryptographic scheme (symmetric or assymmetric) also. >> >>Now lets see how the different requirements specified are solved: >>1> Implicit certification: >> As is clear from the basic definition of IBE, a source need not know the >> public key of the destination before sending a bundle. >> The burden of ensuring updated certification now rests on the >> destination that now has to obtain the current valid private key >> to be able to decrypt a received bundle. >> >>2> Use of hierarchy: >> This offers us two advantages: >> a> Efficient key distribution: Normal IBE has only one PKG server which >> possesses the master key. This PKG is responsible for extracting private >> keys of all the users of the system. >> By using hierarchy - a) we can first place local PKGs in every region so that >> destination nodes dont have to go far to get their private keys and >> also b) compromise of a lower level PKG does not compromise the whole >> system (as the master secret resides with the root PKG only). >> The naming scheme in HIBE also derives naturally from the naming in the DTN >> architecture where the endpoint address consists of two parts - region >> ID and the region-specific ID. >> For example: if the endpoint address for Bob is 'bundles://Earth/Bob_IP', then >> a PKG can be placed on Earth with ID:'Earth'. For larger regions, we can >> further create more levels in the hierarchy. >> >> b> Revocation control: >> We do this by creating a sub-hierarchy for each host (in addition to the >> hierarchy over multiple PKGs created for key distribution). >> The levels in this sub-tree would reflect the degree of control desired >> for revocation. Senders will use the ID tuples corresponding to the >> leaves of this tree for encryption. >> As this sub-tree is completely located at a particular >> host, the host can act as a PKG and extract private keys for this tree >> on its own. We can control the leaves for which the host is able to generate >> private keys for itself by providing it private keys for only selected >> internal nodes of this tree. >> For example: the first level could be month, the second level date and >> the third level: hour. Then the ID of a user Bob (in region Earth) would be >> Earth.Bob.May.24.12pm . >> - The Earth region PKG can extract private keys for all IDs of the form >> 'Earth.*'. The Earth PKG can then choose to give Bob the private key >> for 'Earth.Bob' if Bob is a highly trusted user. Now Bob can generate all >> keys of the form 'Earth.Bob.... >> - A less trusted user 'Alice' will be given the private key for >> 'Earth.Alice.Nov' only - this will allow Alice to read messages only for >> month of November. For a bundle encrypted with the full ID string >> Earth.Alice.Nov.25.12pm, Alice will be forced to ask a new private >> key every hour. >> - For more paranoid uses, an extra level of the this tree could be a >> random ID. This would force the receiver to acquire a new private key >> for each bundle it receives. A sender can now encrypt the bundle >> with 'Earth.Alice.Nov.25.12pm.'. >> - A sender that wishes lower security( and lower latency) for a >> session can now encrypt it with 'Earth.Alice.Nov.25.12pm.0000', and Alice >> would have to go to the Earth PKG only once to decrypt this bundle. >> In general, the PKG server responsible for a user needs to compute a >> subset cover over the user subtree i.e the minimum set of nodes that cover >> all the IDs that are allowed and none of the IDs that are not allowed >> for that user. Then it needs to extract private keys for only those >> nodes in the subset cover. >> >> c> Fine grained access control: >> A similar scheme as above can be used for forming ID strings needed for >> authentication and access control as well. >> For this source users sign the bundles with the correct privilege >> desired. For example, if Alice desires 'Urgent' class of service, it will >> need to sign the bundle with the identity 'Alice.Urgent'. For this it >> needs to possess the private key corresponding to 'Alice.Urgent'. >> Possession of a private key corresponding to an identity >> implies that the system also authorized you for the rights that are >> associated with that identity. >> This is possible in IBE because all private keys are generated by the PKGs. >> The same hierarchical ID structure can be used for revocation and >> granting of rights as well. The subtree below each host >> would now represent different privileges. >> For example: A highly valuable Bob can be given access to all classes >> of service by providing the private key for 'Earth.Bob.Nov.25' - Bob can >> then generate keys for 'Earth.Bob.Nov.25.Urgent' etc and use them for >> signing his bundles. >> A less valuable 'Alice' will only be given the private key for >> 'Earth.Alice.Nov.25.Bulk'. >> However this mechanism requires the ID string to be included >> in the bundle header(PSH) for routers to use the correct key >> for authentication. >> This issue was raised in [1] as well for key rollover. >> This overall method of encoding the permissions of the user in the ID >> string is very similar to using accompanying certificates in traditional PKI. >> >>Why not PKI?: >>------------- >>1> Implicit certification is not possible as a source host is forced to >> first acquire the identity(public key) of the destination before sending >> any bundle. It is also forced to check >> whether the destination is currently certified or not by making third-party >> queries. >>2> Revocation is made much difficult in DTN and solutions like maintaining >> a Certificate Revocation List(CRL) does not work for DTNs. >> >>Other issues and Disadvantages: >>------------------------------- >>1> Key escrow: >> In IBE, the PKG can generate private keys for all users and thereby decrypt >> bundles destined for all users. This may not be always desirable. >> A related property is 'non-repudiability' which means that a receiver can >> prove that only the sender could have signed the bundle. >> Also, the compromise of the root PKG jeopardizes the entire system >> and all messages that were sent in the past. >> >>2> Standards issue: >> Since we try to encode revocation control(date etc) and access control >> identifiers in the ID strings, all entities in the DTN need to agree on a >> common format. This is similar to the problem faced in traditional PKI >> over the format of certificates. >> >>3> Distribution of private keys: >> Since users ask the PKGs to generate private keys, they have to be transmitted >> securely from the PKGs. This might mean that the PKGs share another key >> with every user just for the purpose of sending private keys. >> >>5> Distribution of system wide public parameters >> An IBE system installation needs to bootstrap all hosts with >> the public system parameters of the PKG. >> This also might need to be updated if the root PKG is compromised. >> >>6> Replay attacks: >> Although we guarantee confidentiality and integrity, we do not have any >> mechanism to detect and handle replay attacks. >> >>Other options and optimizations: >>-------------------------------- >>1> Use of Certificate Based Encryption [8]: >> The 'key escrow' problem can be solved by using this variation where users >> are allowed to generate their own private keys. >> Senders are now able to user long lasting public keys without the need >> to worry about the current certification status of the destinations. >> This also solves the problem of securely delivering extracted private keys >> to each user. >>2> Reducing overhead of using hierarchical IBE: >> Normal HIBE, both the length of signatures and the number of steps required >> for encryption are proportional to the number of levels in the ID tree. >> Some techniques based on the BGLS aggregated signature scheme can be used >> to reduce the decryption complexity. >>3> If non-repudiability is not desired, them the scheme proposed in [10] can be >> used. Here the the MAC for authentication is same as the cipher-text for >> encryption. It also uses the same public IDs and private keys as the standard >> scheme. So we can get both authentication(+integrity) and secrecy with >> little extra cost. >> >> >>Implementation in DTN2 : >>----------------------- >>1> What are the basic building blocks that need to be supported in the DTN2 >> architecture. >>2> User management: [1] suggested that the DTN agent cannot possess the >> private keys. Applications should store the keys and call external >> entity to perform the encryption. >> >> >> >> >> >> >>References: >>----------- >>[1] Email correspondence on the dtn-interest mailing list >>[2] Draft: "Identity based Encryption for Delay Tolerant Networks" >> A. Chakrabarti and K Fall. >> summary: proposes the use of IBE for both confidentiality as well >> as access control management in DTNs. >>[3] Draft: "A Secure Tetherless Computing Architecture" by S.Keshav et al. >> summary: proposes a hierarchy of PKGs using HIBE and HIBS for efficient >> key management in the TCA. >>[4] "Exploiting Hierarchical IBE for Access Control to Pervasive Computing >> Information" >> Urs Hengartner and Peter Steenkiste >> summary: proposes use of HIBE for both "encryption-based" and >> "proof-based" access control for client-server interactions. >> More emphasis on preventing leakage of information about access control >> policies >>[5] "Hidden Credentials" >> >> summary: use of IBE for hidden credential trust negotiation. >>[6] "Identity based signatures" >> Paterson >> summary: one scheme for signatures based on the Boneh/Franklin scheme. >>[7] "Identity based Encryption based on the Weil Pairing" >> Boneh and Franklin >> summary: this introduces the first concrete IBE scheme. >>[8] "Certificate-Based Encryption and the Certificate Revocation Problem" >> Craig Gentry >> summary: this talks about mitigating problems in IBE by proposing >> Certificate based Encryption(CBE) in which users can choose their own >> private key. >>[9] "Hierarchical ID based Cryptography" >> Gentry and Silverberg >> summary: this extends the Boneh/Franklin IBE scheme >>[10]"Authenticated Identity-based Encryption" >> Ben Lynn >> summary: extends the Boneh/Franklin scheme to provide integrity of the >> message being encrypted. >> >> >> >> >> > > -- > Howard Weiss > SPARTA, Inc. > 7075 Samuel Morse Drive > Columbia, MD 21046 > 410.872.1515 x201 > 410.872.8079 (fax) > >