idnits 2.17.1 draft-bradner-pbk-frame-03.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 145 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.) -- The document date (November 2002) is 7834 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Scott Bradner 3 Harvard University 4 Allison Mankin 5 USC/ISI 6 Jeffrey I. Schiller 7 Massachusetts Institute of Technology 8 November 2002 10 A Framework for Purpose Built Keys (PBK) 12 14 Status of this Memo 16 This document is an Internet-Draft and is subject to the provisions 17 of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2002). All Rights Reserved. 39 Abstract 41 This memo considers the need to authenticate the source of a network 42 communication where the actual identity of the source is not 43 important but it is important to be sure that the source can not be 44 spoofed and that successive messages in the communication come from 45 the same source. This memo defines the use of specially generated 46 public/private key pairs, known as Purpose Built Keys (PBKs), to 47 provide this assurance. This memo is not a full specification of a 49 Purpose Built Keys Framework November 2002 51 PBK protocol, but rather a model or framework for development of PBK 52 in applications. 54 1.0 Introduction 56 There are many cases in Internet protocols where cryptographic 57 mechanisms can add significant security improvement. However most 58 such mechanisms rely on associating keys to entities, ultimately 59 requiring an enterprise-wide, multi-enterprise, or even more widely 60 deployed Public Key Infrastructure (PKI). 62 In the absence of security mechanisms, many protocols are 63 continuously vulnerable to attack. 65 However there are many circumstances where we can improve overall 66 security by narrowing the window of vulnerability, so that if we 67 assume that some operation is performed securely, we can secure all 68 future transactions. 70 There are also cases where the actual identity of the initiator of a 71 network communication is not an important piece of information, yet 72 it is important to know that successive packets are from that same 73 source. One example of this is in mobile IPv6. Mobile IPv6 contains 74 a rebinding option that enables a mobile node to tell the other end 75 of a communication that the IP address for the mobile node has 76 changed. It is clearly important to know that any such rebinding 77 request actually came from the correct mobile node even if the 78 identity of the user of that mobile node does not need to be known. 80 Note that it is not that the identity of the user here is unimportant 81 to the network (the node user may well authenticate to an AAA service 82 or other access manager at the start of network activity), but rather 83 that it is unimportant to accomplish that level of authentication for 84 the purpose of rebinding. 86 This memo describes the use of a temporary public/private key pair 87 that is generated by a host for each case where the consistency of 88 authentication needs to be assured. For example, if mobile IP 89 binding were to use something like this technique, then a new key 90 pair would be generated before each mobile ip session in which the 91 mobile was roaming, and discarded after the session was completed. 93 This use of these host-generated temporary keys is confined to the 94 parties in a communication and does not require that the keys be 95 registered with or known by any third party. Thus this mechanism 96 does not require that any support infrastructure exist outside of the 98 Purpose Built Keys Framework November 2002 100 protocol support in the corresponding hosts and it can be deployed 101 incrementally as host support becomes available. It also scales well 102 since the operations are confined to the end systems involved in the 103 communication. 105 By not using registered keys, this mechanism preserves user 106 pseudonymity as long as the identities of the users are not obtained 107 by some other process during the communication. There is extensive 108 literature about the lack of anonymity of persons stemming from their 109 IP addresses ([Syverson] is just a good starting point) as well as 110 work that has kinship to the pseudonyms in this in this work 111 [Brands], [Chaum88], [HIP], [SUCV]. 113 The PBK mechanism is susceptible to man-in-the-middle attacks that 114 affect its initialization and make it possible without care for the 115 pseudonymous identity to be used by a party other than the issuer. 116 There is an "initial leap of faith" about the identity since it has 117 no parties other than the issuer vouching for it, and though only the 118 issuer holds the private key, a man-in-the-middle attacker may appear 119 to hold and use the identity without good care taken in the protocol 120 design that uses PBK. Therefore, the using protocol should be aware 121 of this risk and design a challenge-response confirmation step. It 122 should have the property of needing the private key for decryption 123 and including a nonce. 125 The PBK mechanism does not require the use of a reliable protocol. 126 It is intended to used with transport or application protocols. It 127 differs from IPSec in that it is applied on demand by an application 128 or by a transport protocol. 130 When this mechanism is used with applications the PBK's public key 131 can be used in an identity for a web-cookie like function, but the 132 use is under the control of the node that initiates the connection 133 rather than under the control of the server. 135 2.0 Conceptual Overview 137 Following is a conceptual step-by-step description of the PBK process 138 when operating below the transport layer. 140 First some definitions: 141 initiating node: the node initiating the conversation 142 receiving node: the node at the other end of the conversation 144 Before an initiating node initiates a connection during which it will 145 need to prove that it is the same node that started the connection, 146 it creates a public/private key pair for use during the connection. 147 This is known as a purpose-built key (PBK) pair. 149 Purpose Built Keys Framework November 2002 151 The initiating node then creates a Purpose-Built ID (PBID) by 152 performing a cryptographic hash of the public part of the PBK pair. 153 This PBID will be used as an identity token for the node. 155 The initiating node then initiates the connection. The PBID is sent 156 along with the initial packets in the connection. In IPv6 this could 157 be done in an end-to-end option header, in IPv4 as a header option. 158 (These option ideas are for transport level use of the PBK - if the 159 PBK was used from within HTTP or another application, the PBID's 160 location would be in the application protocol.). The PBID does not 161 need to appear in all of the packets; it just has to be reliably 162 conveyed to the receiving node. Reliability may be obtained by 163 carrying it on enough packets so that a return packet indicates it 164 was received eventually. This is the simplest approach; depending on 165 requirements and the application, the PBID may well be transported 166 reliably. 168 The receiving node stores the PBID and the source IP address that 169 were in the received packet in a conceptual table. 171 At some time in the connection before the proof of identity is 172 needed, the initiating node sends its public key to the receiving 173 node. This again could be done in IP-level options or in an 174 application-level exchange. The receiving node verifies that the 175 received public key hashes to the previously provided PBID. 177 When the initiating node wants to perform some operation it sends the 178 operation request along with the PBID. The message is signed using 179 the private part of the PBK. If replay protection is necessary, a 180 nonce value (a monotonically increasing value) or timestamp may be 181 included with the operation request. 183 When the receiving node gets such an operation request it verifies 184 the digital signature and returns a challenge packet. The challenge 185 packet is sent to the IP address that was in the source IP address 186 field of the packet that contained the request. The challenge packet 187 contains a random number test value generated by the receiving node. 189 When the initiating node receives the challenge packet it encrypts 190 the test value in its private key and sends the result back to 191 receiving node. 193 When the receiving node gets the challenge response it decrypts the 194 test value using the stored public key associated with the PBID. If 195 the results match then the receiving node can be sure that the node 196 that sent the operation request was the correct initiating node. 198 The PBKs would normally be discarded at the end of the communication 200 Purpose Built Keys Framework November 2002 202 but in those cases where a continuity of identity is needed over 203 multiple sessions the PBKs could be retained until the requirement 204 was over. 206 3.0 Notes on the design 208 The hash of the public key is used as the PBID so that the 209 relationship between an offered PBID and public key can be 210 established. If a receiving node is in possession of the private key 211 and the hash of the corresponding public key matches an offered PBID, 212 it can be sure that it has the correct PBID for that public key. 214 Retransmission algorithms, where they are needed, must be conformant 215 with RFC 2914 [RFC2914]. 217 The challenge / response exchange has to be synchronized within the 218 data stream if the processing of packets after the operation request 219 would be different that before the operation request, as it would be 220 for mobile IPv6. This would mean suspending normal transmission 221 until the challenge / response exchange was completed. 223 The challenge is sent to the source address in the packet and this 224 address is not included in the digital signature on the operation 225 request packet so that this mechanism can work through any address 226 modifying devices that may be in the path. 228 In the cases where commands could be issued by both ends of a 229 communication, as would be the case in mobile IPv6 if both ends were 230 mobile, separate PBKs would be created by each end and the mechanism 231 would be run independently by each end. 233 4.0 Security Considerations 235 This whole document is about security. Specifically the memo 236 discusses how to perform authenticated operations in an environment 237 where there is no existing security infrastructure or an environment 238 where network addresses might change during the course of the 239 communication. 241 In the absence of a security infrastructure such as a PKI, it is not 242 always possible to authenticate one party to another. In the absence 243 of any cryptographic security mechanism, internet transactions are 244 continuously at risk of compromise. With PBKs it is possible to 245 leverage an initial "leap of faith" so that presuming an initial 246 transaction has not been tampered with (say the exchange of PBID's at 247 the beginning of an association between two parties), future 248 transactions can be secured. 250 Purpose Built Keys Framework November 2002 252 5.0 Acknowledgements 254 Some of these same concepts are explored in [HIP]. We owe concepts 255 in this draft to Bob Moskowitz and also (as any working in privacy 256 to) to David Chaum. 258 6.0 Author's Addresses 260 Scott Bradner 261 Harvard University 262 Cambridge MA 02138 264 Phone +1 617 495 3864 265 email sob@harvard.edu 267 Allison Mankin 268 University of Southern California, Information Sciences Institute 269 Phone: +1 703 812 3706 270 email: mankin@psg.com 272 Jeffrey I. Schiller 273 Massachusetts Institute of Technology 274 MIT Room W92-190 275 77 Massachusetts Avenue 276 Cambridge, MA 02139-4307 277 Phone: +1 617 253 0161 278 email: jis@mit.edu 280 Informative References 282 [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, 283 September 2000. 285 ([Syverson] is just a good starting point) as well as work that has 286 kinship to the pseudonyms in this in this work [Brands], [Chaum88], 287 [HIP], [SUCV]. 289 [Syverson] Syverson, P., Goldschlag, D. and Reed, M., "Anonymous 290 Connections and Onion Routing," in 18th Annual Symposium on Security 291 and Privacy, Oakland CA, 1997. http://www.onion- 292 router.net/Publications/SSP-1997.pdf 294 [Brands] Brands, S.A., "Rethinking Public Key Infrastructures and 295 Digital Certificates - Building In Privacy," MIT Press, 2000. 297 [Chaum88] Chaum, D., Fiat, A., and Naor, M. "Untraceable Electronic 299 Purpose Built Keys Framework November 2002 301 Cash", in S. Goldwasser, Editor, Advances in Cryptology - CRYPTO '88. 302 Lecture Notes in Computer Science Volume 403, Springer-Verlag, 1988. 304 [HIP] Moskowitz, R., "Host Identity Payload Architecture", "Host 305 Identity Payload Protocol", http://homebase.htt-consult.com/~hip, 306 2001. 308 [SUCV] Montenegro, G., Castellucia, C., "SUCV Identifiers and 309 Addresses", IETF Work in Progress, July 2002. 311 Full Copyright statement 313 Copyright (C) The Internet Society (2002). All Rights Reserved. 314 This document and translations of it may be copied and furnished to 315 others, and derivative works that comment on or otherwise explain it 316 or assist in its implementation may be prepared, copied, published 317 and distributed, in whole or in part, without restriction of any 318 kind, provided that the above copyright notice and this paragraph are 319 included on all such copies and derivative works. However, this 320 document itself may not be modified in any way, such as by removing 321 the copyright notice or references to the Internet Society or other 322 Internet organizations, except as needed for the purpose of 323 developing Internet standards in which case the procedures for 324 copyrights defined in the Internet Standards process must be 325 followed, or as required to translate it into languages other than 326 English. 328 The limited permissions granted above are perpetual and will not be 329 revoked by the Internet Society or its successors or assigns. 331 This document and the information contained herein is provided on An 332 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 333 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 334 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INFORMATION HEREIN 335 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 336 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.