idnits 2.17.1 draft-bradner-pbk-frame-06.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 135 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 (June 2003) is 7620 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 June 2003 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 (2003). 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 and that successive messages in the 44 communication come from the same source. This memo defines the use 45 of specially generated public/private key pairs, known as Purpose- 46 Built Keys (PBKs), to provide this assurance. This memo is not a 47 full specification of a PBK protocol, but rather a model or framework 48 for development of PBK in applications. 50 1.0 Introduction 52 There are many cases in Internet protocols where cryptographic 53 mechanisms can add significant security improvement. However most 54 such mechanisms rely on associating keys to entities, ultimately 55 requiring an enterprise-wide, multi-enterprise, or even more widely 56 deployed Public Key Infrastructure (PKI). 58 In the absence of security mechanisms, many protocols are 59 continuously vulnerable to attack. However, there are many 60 circumstances where we can improve overall security by narrowing the 61 window of vulnerability, so that if we assume that some operation is 62 performed securely, we can secure all future transactions. 64 There are also cases where the actual identity of the initiator of a 65 network communication is not an important piece of information, yet 66 it is important to know that successive packets are from that same 67 source. One example of this is in mobile IPv6. Mobile IPv6 contains 68 a rebinding option that enables a mobile node to tell the other end 69 of a communication that the IP address for the mobile node has 70 changed. It is clearly important to know that any such rebinding 71 request actually came from the correct mobile node even if the 72 identity of the user of that mobile node does not need to be known. 74 Note that it is not that the identity of the user here is unimportant 75 to the network (the node user may well authenticate to an 76 Authentication, Authorization and Accounting (AAA) service or other 77 access manager at the start of network activity), but rather that it 78 is unimportant to accomplish that level of authentication for the 79 purpose of rebinding. 81 This memo describes the use of a temporary public/private key pair 82 that is generated by a host for each case where the consistency of 83 authentication needs to be assured. For example, if mobile IP 84 binding were to use this technique, then a new key pair would be 85 generated before each mobile ip session in which the mobile was 86 roaming, and discarded after the session was completed. 88 This use of host-generated temporary keys is confined to the parties 89 in a communication and does not require that the keys be registered 90 with or known by any third party. Thus this mechanism does not 91 require that any support infrastructure exist outside of the protocol 92 support in the corresponding hosts, and it 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, the PBK mechanism preserves user 98 pseudonymity as long as the identities of the users are not disclosed 99 by some other process during the communication. There is extensive 100 literature about the lack of anonymity of persons stemming from their 101 IP addresses ([Syverson] is a good starting point) as well as work 102 that has kinship to the pseudonyms in this work [Brands], [Chaum88], 103 [HIP], [SUCV]. 105 The PBK mechanism is susceptible to man-in-the-middle attacks which 106 affect its initialization. Such attacks may make it possible for a 107 pseudonymous identity to be used by a party other than the party that 108 generated the public/private key pair and then sent it to the 109 recipient. There is an "initial leap of faith" about the 110 pseudonymous identity since it has no parties, other than the party 111 that generated the public/private key pair, vouching for it, and 112 though only the party that generated the public/private key pair 113 holds the private key, a man-in-the-middle attacker may appear to 114 hold and use the identity without good care being taken in a protocol 115 design that makes use of PBK. Therefore, the designer of such a 116 protocol should be aware of this risk and include a challenge- 117 response confirmation step. The challenge-response step should have 118 the property of needing the private key for decryption and include a 119 nonce. 121 The PBK mechanism is intended to used with transport or application 122 protocols. It differs from IPSec in that it is applied on demand by 123 an application or by a transport protocol. 125 2.0 Conceptual Overview 127 Following is a conceptual step-by-step description of the PBK process 128 when operating below the transport layer. 130 First some definitions: 131 Initiating Node: the node initiating the conversation 132 Receiving Node: the node at the other end of the conversation 134 Before an Initiating Node initiates a connection during which it will 135 need to prove that it is the same node that started the connection, 136 it creates a public/private key pair for use during the connection. 137 This is known as a purpose-built key (PBK) pair. 139 The Initiating Node then creates a Purpose-Built ID (PBID) by 140 performing a cryptographic hash of the public part of the PBK pair. 141 This PBID will be used as an identity token for the node. 143 The Initiating Node then initiates the connection. The PBID is sent 144 along with the initial packets in the connection. In IPv6 this could 145 be done in an end-to-end option header, in IPv4 as a header option. 146 (These option ideas are for transport level use of the PBK - if the 147 PBK was used from within HTTP or another application, the PBID's 148 location would be in the application protocol.) The PBID does not 149 need to appear in all of the packets; it just has to be reliably 150 conveyed to the Receiving Node. Reliability may be obtained by 151 carrying it on enough packets so that a return packet indicates it 152 was received eventually. This is the simplest approach; depending on 153 requirements and the application, the PBID may well be sent using a 154 reliable transport protocol. Retransmission algorithms, where they 155 are needed, must be conformant with RFC 2914 [RFC2914]. 157 The Receiving Node stores the PBID and the source IP address from the 158 received packet in a table. 160 At some time in the connection before the proof of identity is 161 needed, the Initiating Node sends its public key to the Receiving 162 Node. This again could be done in IP-level options or in an 163 application-level exchange. The public key could be sent as part of 164 the initialization or anytime before it is needed for proof of 165 identity. The Receiving Node verifies that the received public key 166 hashes to the previously provided PBID. 168 When the Initiating Node wants to perform some operation for which it 169 wants to prove its identity, it sends the PBID along with the 170 operation request. The message is signed using the private part of 171 the PBK. If replay protection is necessary, a nonce value (a 172 monotonically increasing value) or timestamp may be included with the 173 operation request. 175 When the Receiving Node gets such an operation request it verifies 176 the digital signature using the saved public key and returns a 177 challenge packet. The challenge packet is sent to the IP address 178 that was in the source IP address field of the packet that contained 179 the request. The challenge packet contains a random number test 180 value generated by the Receiving Node. 182 When the Initiating Node receives the challenge packet it encrypts 183 the test value in its private key and sends the result back to 184 Receiving Node. 186 When the Receiving Node gets the challenge response it decrypts the 187 test value using the stored public key associated with the PBID. If 188 the results match then the Receiving Node can be sure that the node 189 that sent the operation request was the correct Initiating Node. 191 The PBKs would normally be discarded at the end of the communication 192 but in those cases where a continuity of identity is needed over 193 multiple sessions the PBKs could be retained until the requirement 194 was over. 196 3.0 Notes on the design 198 The hash of the public key is used as the PBID so that the 199 relationship between an offered PBID and public key can be 200 established. If a Receiving Node is in possession of the private key 201 and the hash of the corresponding public key matches an offered PBID, 202 it can be sure that it has the correct PBID for that public key. 204 The challenge / response exchange has to be synchronized within the 205 data stream if the processing of packets after the operation request 206 would be different than before the operation request, as it would be 207 for mobile IPv6. This would mean suspending normal transmission 208 until the challenge / response exchange was completed. 210 The challenge is sent to the source address in the packet, and this 211 address is not included in the digital signature on the operation 212 request packet so that this mechanism can work through any address- 213 modifying devices that may be in the path. 215 In the cases where commands could be issued by both ends of a 216 communication, as would be the case in mobile IPv6 if both ends were 217 mobile, separate PBKs would be created by each end and the mechanism 218 would be run independently by each end. 220 4.0 Security Considerations 222 This whole document is about security. Specifically the memo 223 discusses how to perform authenticated operations in an environment 224 where there is no existing security infrastructure or an environment 225 where network addresses might change during the course of the 226 communication. 228 In the absence of a security infrastructure such as a PKI, it is not 229 always possible to authenticate one party to another. In the absence 230 of any cryptographic security mechanism, internet transactions are 231 continuously at risk of compromise. With PBKs it is possible to 232 leverage an initial "leap of faith" so that presuming an initial 233 transaction has not been tampered with (say the exchange of PBID's at 234 the beginning of an association between two parties), future 235 transactions can be secured. 237 5.0 Acknowledgements 238 We owe credit for some of the concepts in this draft to Bob Moskowitz 239 and also (as anyone working in the area of privacy does) to David 240 Chaum. 242 6.0 Author's Addresses 244 Scott Bradner 245 Harvard University 246 29 Oxford St. 247 Cambridge MA 02138 249 Phone +1 617 495 3864 250 email sob@harvard.edu 252 Allison Mankin 253 Bell Labs, Lucent 254 Phone: +1 301 728 7199 255 email: mankin@psg.com 257 Jeffrey I. Schiller 258 Massachusetts Institute of Technology 259 MIT Room W92-190 260 77 Massachusetts Avenue 261 Cambridge, MA 02139-4307 262 Phone: +1 617 253 0161 263 email: jis@mit.edu 265 Informative References 267 [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, 268 September 2000. 270 [Syverson] Syverson, P., Goldschlag, D. and Reed, M., "Anonymous 271 Connections and Onion Routing," in 18th Annual Symposium on Security 272 and Privacy, Oakland CA, 1997. http://www.onion- 273 router.net/Publications/SSP-1997.pdf 275 [Brands] Brands, S.A., "Rethinking Public Key Infrastructures and 276 Digital Certificates - Building In Privacy," MIT Press, 2000. 278 [Chaum88] Chaum, D., Fiat, A., and Naor, M. "Untraceable Electronic 279 Cash", in S. Goldwasser, Editor, Advances in Cryptology - CRYPTO '88. 280 Lecture Notes in Computer Science Volume 403, Springer-Verlag, 1988. 282 [HIP] Moskowitz, R., "Host Identity Payload Architecture", "Host 283 Identity Payload Protocol", http://homebase.htt-consult.com/~hip, 284 2001. 286 [SUCV] Montenegro, G., Castellucia, C., "SUCV Identifiers and 287 Addresses", IETF Work in Progress, July 2002. 289 Full Copyright statement 291 Copyright (C) The Internet Society (2003). All Rights Reserved. 292 This document and translations of it may be copied and furnished to 293 others, and derivative works that comment on or otherwise explain it 294 or assist in its implementation may be prepared, copied, published 295 and distributed, in whole or in part, without restriction of any 296 kind, provided that the above copyright notice and this paragraph are 297 included on all such copies and derivative works. However, this 298 document itself may not be modified in any way, such as by removing 299 the copyright notice or references to the Internet Society or other 300 Internet organizations, except as needed for the purpose of 301 developing Internet standards in which case the procedures for 302 copyrights defined in the Internet Standards process must be 303 followed, or as required to translate it into languages other than 304 English. 306 The limited permissions granted above are perpetual and will not be 307 revoked by the Internet Society or its successors or assigns. 309 This document and the information contained herein is provided on An 310 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 311 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 312 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INFORMATION HEREIN 313 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 314 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.