idnits 2.17.1 draft-bradner-pbk-frame-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 122 has weird spacing: '...o prove that ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-13 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Scott Bradner 2 Harvard University 3 Allison Mankin 4 USC/ISI 5 Jeffrey I. Schiller 6 Massachusetts Institute of Technology 7 Feb, 2001 9 A Framework for Purpose Built Keys (PBK) 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2001). All Rights Reserved. 38 Abstract 40 This memo defines a framework for the consideration of a particular 41 class of the need to authenticate the source of a network 42 communication. The class consists of those cases where the actual 43 identity of the source is not important but the knowledge that the 44 source is the same one as started the communication and the assurance 45 that the source cannot be spoofed are important. This memo defines 46 the use of specially generated public/private key pairs, known as 47 Purpose Built Keys (PBKs), to provide this knowledge and assurance. 49 1.0 Introduction 51 There are many cases in Internet protocols where cryptographic 52 mechanisms can add significant security improvement. However most 53 such mechanisms rely on associating keys to entities, ultimately 54 requiring an enterprise wide or potentially globally deployed Public 55 Key Infrastructure (PKI). 57 In the absence of security mechanisms, many protocols are 58 continuously vulnerable to attack. 60 However there are many circumstances where we can improve overall 61 security by narrowing the window of vulnerability, so that if we 62 assume that some operation is performed securely, we can secure all 63 future transactions. 65 There are also cases where the actual identity of the initiator of a 66 network communication is not an important piece of information, yet 67 it is important to know that successive packets are from that same 68 source. One example of this is in mobile IPv6. Mobile IPv6 contains 69 a rebinding option that enables a mobile node to tell the other end 70 of a communication that the IP address for the mobile node has 71 changed. It is clearly important to know that any such rebinding 72 request actually came from the correct mobile node even if the 73 identity of the user of that mobile node does not need to be known. 75 Note that it is not that the identity of the user here is unimportant 76 to the network (the node user may well authenticate to a AAA server 77 at the start of network activity), but rather that it is unimportant 78 to accomplish that level of authentication for the purpose of 79 rebinding. Another example of this class of authentication would be 80 continuing a connection through local renumbering of its site. 82 This memo describes the use of a temporary public/private key pair 83 which is generated by a host for each case where the consistency of 84 authentication needs to be assured. For example, a new key pair 85 would be generated before each mobile IP session and discarded when 86 the session was complete. 88 This use of these host-generated temporary keys is confined to the 89 parties in a communication and does not require that the keys be 90 registered with or known by any third party. Thus this mechanism 91 does not require that any support infrastructure exist outside of the 92 protocol support in the corresponding hosts and can be deployed 93 incrementally as host support becomes available. It also scales well 94 since the operations are confined to the end systems involved in the 95 communication. 97 By not using registered keys, this mechanism preserves user anonymity 98 as long as the identity of the users are not obtained by some other 99 process during the communication. 101 This mechanism does not require the use of a reliable protocol and it 102 is a mechanism that fits under transports or under applications, and 103 differs from IPSec in that it is applied on demand by an application 104 or transport. 106 When this mechanism is used with applications it can be used in ways 107 similar to the use of web cookies but the use is under the control of 108 the node that initiates the connection rather than under the control 109 of the server. This mechanism gives the user control over the scope 110 of the use of a particular identity. 112 2.0 Conceptual Overview 114 Following is a conceptual step-by-step description of the PBK process 115 when operating below the transport layer. 117 First some definitions: 118 initiating node: the node initiating the conversation 119 receiving node: the node at the other end of the conversation 121 Before a initiating node initiates a connection during which it will 122 need to prove that it is the same node that started the connection 123 it creates a public/private key pair for use during the connection. 124 This is known as a purpose-built key (PBK) pair. 126 The initiating node then creates an Endpoint ID (EID) by performing a 127 cryptographic hash of the public part of the PBK. This EID will be 128 used as an identity token for the node. 130 The initiating node then initiates the connection. The EID is sent 131 along with the initial packets in the connection. In IPv6 this could 132 be done in an end-to-end option header, in IPv4 as a header option. 133 (These option ideas are for transport level use of the PBK - if the 134 PBK was used from within HTTP or another application, its position 135 would not be have to be in the IP header). The EID does not need to 136 appear in all of the packets; it just has to be reliably conveyed to 137 the receiving node. 139 The receiving node stores the EID and the source IP address in the 140 received packet in a table. 142 At some time in the connection before the proof of identity is 143 needed, the initiating node sends its public key to the receiving 144 node. This again could be done in IP-level options or in an 145 application-level exchange. The receiving node verifies that the 146 received public key hashes to the previously provided EID. 148 When the initiating node wants to perform some operation, such as a 149 mobile IPv6 address rebinding, it sends the operation request along 150 with the EID. The message is signed using the private part of the 151 PBK. If replay protection is necessary, a nonce value (a 152 monotonically increasing value) or timestamp may be included with the 153 operation request. 155 When the receiving node gets such an operation request, it fetches 156 the previously sent public key from session state. This key is then 157 used to verify the digital signature on the operation request. If the 158 protocol calls for a nonce value, it verifies that the nonce value is 159 larger then any previously received nonce. The protocol may use a 160 timestamp, in which case the receiving node determines if the 161 timestamp is timely for the operation request. 163 The PBKs would normally be discarded at the end of the communication 164 but in those cases where a continuity of identity is needed over 165 multiple sessions the PBKs could be retained until the requirement 166 was over. 168 3.0 Notes on the design 170 The hash of the public key is used as the EID so that the 171 relationship between an offered EID and public key can be 172 established. If a receiving node is in possession of the private key 173 and the hash of the corresponding public key matches an offered EID, 174 it can be sure that it has the correct EID for that public key. 176 Retransmission algorithms, where they are needed, must be conformant 177 with RFC 2914 [RFC2914]. 179 In the cases where commands could be issued by both ends of a 180 communication, as would be the case in mobile IPv6 if both ends were 181 mobile, separate PBKs would be created by each end and the mechanism 182 would be run independently by each end. 184 3.0 Security Considerations 186 This whole document is about how to perform authenticated operations 187 in an environment where there is no security infrastructure and one 188 where network addresses might change during the communication. 190 In the absence of infrastructure, it is not always possible to 191 authenticate one party to another. In the absence of any 192 cryptographic security mechanism, internet transactions are 193 continuously at risk of compromise. With PBKs it is possible to 194 leverage an initial "leap of faith" so that presuming an initial 195 transaction has not been tampered with (say the exchange of EID's at 196 the beginning of an association between two parties), future 197 transactions can be secured. 199 6.0 Author's Addresses 201 Scott Bradner 202 Harvard University 203 Cambridge MA 02138 205 Phone +1 617 495 3864 206 email sob@harvard.edu 208 Allison Mankin 209 University of Southern California, Information Sciences Institute 210 4350 N. Fairfax Drive, Suite 620 211 Arlington, VA 22203 212 Phone: +1 703 812 3706 213 email: mankin@isi.edu 215 Jeffrey I. Schiller 216 Massachusetts Institute of Technology 217 MIT Room W92-190 218 77 Massachusetts Avenue 219 Cambridge, MA 02139-4307 220 Phone: +1 617 253 0161 221 email: jis@mit.edu 223 Appendix A - Mobile IPv6 Example 225 Let's start by discussing briefly how Mobile IPv6 works. Note: This 226 is not intended to be a comprehensive description of the protocol, 227 and important details are left out for brevity. Full information can 228 be obtained from [MobileIPv6]. 230 In a Mobile IPv6 world, a node may move from location to location. As 231 it does, the best IP address to reach it may change, as IP addresses 232 are integral to the operation of routing. As a node changes its 233 topological location on the Internet, it needs to be reached at a 234 different IP address. 236 Yet, TCP and other transport protocols expect an IP address to remain 237 stable for the duration of a session. Mobile IP deals with this by 238 having a router close to a node's "home" address be in a position to 239 intercept and forward any traffic for the mobile node to the IP 240 address that it is currently reachable at. A mobile node's normal IP 241 address is called its "home" address and the IP address where it is 242 currently reachable is its "in care of" address. 244 When a mobile IP node sends a packet, it labels its return address 245 with that of its normal home address (via the Home Address Option), 246 knowing that the home router, called the "home agent" will forward 247 packets to it at its current "in care of" address. However this 248 results in a routing triangle with the home agent as the third 249 vertex. This is obviously inefficient from a router perspective, and 250 if the difference, topologically, between a node's home address and 251 current care of address is large, it can be very inefficient. 253 To deal with this, mobile IPv6 introduces the notion of a "Binding 254 Update" (BU) message. This message informs the mobile node's 255 correspondent that it is now really located at a different IP 256 address, the "in care of" address, and that packets destined for it 257 should be instead routed to the care of address. This eliminates the 258 triangle, resulting in efficient routing. 260 However it introduces a security problem. An attacker can source a 261 bogus BU message to cause a sender to route traffic for a particular 262 recipient via the attacker's infrastructure. This can be used for 263 denial of service (the attacker discards packets). Or it can be used 264 to eavesdrop on traffic (the attacker peruses the packets and then 265 forwards them on to their intended recipient). 267 This attack can be thwarted by using PBK. Specifically when a session 268 is initiated, the mobile node provides its EID in the first several 269 packets of the session. This can be done via an IPv6 option header. 270 This EID is noted and stored by the mobile node's correspondent. Now 271 when the mobile node moves, it can provide its public key and send a 272 BU signed with the corresponding private key. Note: Doing this will 273 require changes to the BU message as currently defined in 274 [MobileIPv6]. 276 The correspondent can verify that the EID and public key go together 277 by hashing the public key and verifying that the resultant hash 278 matches the EID. It can then verify the signature on the BU using the 279 public key. 281 Once a destination learns a mobile node's (or any node for that 282 matter) EID, it is impossible for a third party attacker to forge 283 signed messages. If correspondents refused unsigned BUs, then it is 284 not possible to divert traffic. 286 References 288 [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, 289 September 2000. 291 [MobileIPv6] Johson, David B., and Charles Perkins, "Mobility Support 292 in IPv6", draft-ietf-mobileip-ipv6-13.txt, November 2000. 294 Moskowitz, R., "Host Identity Payload Architecture", "Host Identity 295 Payload Protocol", http://homebase.htt-consult.com/~hip, 2001. 297 Full Copyright statement 299 Copyright (C) The Internet Society (2001). All Rights Reserved. 300 This document and translations of it may be copied and furnished to 301 others, and derivative works that comment on or otherwise explain it 302 or assist in its implementation may be prepared, copied, published 303 and distributed, in whole or in part, without restriction of any 304 kind, provided that the above copyright notice and this paragraph are 305 included on all such copies and derivative works. However, this 306 document itself may not be modified in any way, such as by removing 307 the copyright notice or references to the Internet Society or other 308 Internet organizations, except as needed for the purpose of 309 developing Internet standards in which case the procedures for 310 copyrights defined in the Internet Standards process must be 311 followed, or as required to translate it into languages other than 312 English. 314 The limited permissions granted above are perpetual and will not be 315 revoked by the Internet Society or its successors or assigns. 317 This document and the information contained herein is provided on An 318 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 319 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 320 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INFORMATION HEREIN 321 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 322 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.