1 2 3NETWORK WORKING GROUP L. Zhu 4Internet-Draft A. Medvinsky 5Updates: 4120 (if approved) Microsoft Corporation 6Intended status: Standards Track J. Altman 7Expires: May 11, 2007 Secure End Points 8 November 7, 2006 9 10 11 Public Key Cryptography based User to User Authentication - (PKU2U) 12 draft-zhu-pku2u-00 13 14Status of this Memo 15 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 25 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on May 11, 2007. 38 39Copyright Notice 40 41 Copyright (C) The Internet Society (2006). 42 43Abstract 44 45 This document defines the Public Key Cryptography based User to User 46 authentication protocol - PKU2U. PKU2U is based on RFC4456 and 47 RFC4120. This enables peer to peer authentication using Kerberos 48 messages without requiring an online trusted third party. In 49 addition, the binding of PKU2U for the Generic Security Service 50 Application Program Interface (GSS-API) per RFC2743 is defined based 51 52 53 54Zhu, et al. Expires May 11, 2007 [Page 1] 55 56Internet-Draft PKU2U November 2006 57 58 59 on RFC4121. 60 61 62Table of Contents 63 64 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2 Conventions Used in This Document . . . . . . . . . . . . . . . 3 66 3 Protocol description . . . . . . . . . . . . . . . . . . . . . . 3 67 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 4 68 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 69 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 70 7 Normative References . . . . . . . . . . . . . . . . . . . . . . 5 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 72 Intellectual Property and Copyright Statements . . . . . . . . . . 7 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110Zhu, et al. Expires May 11, 2007 [Page 2] 111 112Internet-Draft PKU2U November 2006 113 114 1151 Introduction 116 117 Peer-to-peer systems are increasingly popular today. In a peer-to- 118 peer system, all clients provide resources that contribute positively 119 to the total capacity of the overall system and there is no single 120 point of failure. This distributed nature makes the system highly 121 scalable and robust. In addition, the peer-to-peer system is self- 122 organized. These enable services that just work. 123 124 In a peer-to-peer system, if the initiator can authenticate the 125 acceptor and then establish trust in the information received from 126 the peer, many attacks such as poisoning (e.g. providing data 127 contents are different from the description) and polluting (e.g. 128 inserting "bad" chunks/packets) can be mitigated or eliminated. 129 However, currently there is no interoperable GSS-API mechanism for 130 use in these environments. 131 132 The PKU2U protocol defined in this document extends PKINIT to support 133 peer-to-peer authentications without the use of Key Distribution 134 Center (KDC) [RFC4120]. Thus it enables peer to peer authentication 135 based on public key cryptography. In addition, this document defines 136 the binding for GSS-API based on [RFC4121] and [WS-KERB], which makes 137 PKU2U readily available to the widely deployed GSS-API applications. 138 139 1402 Conventions Used in This Document 141 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 145 146 1473 Protocol description 148 149 The PKU2U realm name is a reserved name that is defined according to 150 [KRB-NAME]. It has the value of "RESERVED:PKU2U". 151 152 PKU2U replaces the KDC in [RFC4556] with the identity of the 153 acceptor, and it updates the protocol with the following changes: 154 155 All the realm names in Kerberos messages are filled with the PKU2U 156 reserved realm. 157 158 The client name in AS-REQ [RFC4120] contains the name of the 159 initiator, and the server name contains the Kerberos name of the 160 acceptor. 161 162 The initiator signs the pre-authentication data as needed per 163 164 165 166Zhu, et al. Expires May 11, 2007 [Page 3] 167 168Internet-Draft PKU2U November 2006 169 170 171 [RFC4120] and constructs an AS-REQ, and then sends the request to the 172 acceptor using the same GSS-API encapsulation defined in [WS-KERB], 173 except the mechanism Objection Identifier (OID) for PKU2U is id- 174 kerberos-pku2u. 175 176 id-kerberos-pku2u ::= 177 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 178 pku2u(7) } 179 180 The client fills out the realm field in the ProxyData [WS-KERB] using 181 the reserved PKU2U realm. Upon receipt of the WS_KRB_PROXY message, 182 the GSS-API acceptor processes the Kerberos message (an AS-REQ) that 183 follows the WS_KRB_PROXY header. 184 185 The acceptor validates the pre-authentication data in the request per 186 Section 3.2.2 of [RFC4556] and it MUST verify the binding between the 187 client name and the client's signing key, if the pre-authentication 188 data in the request is signed. The client's X.509 certificate, if 189 present, MUST contain id-pkinit-KPClientAuth [RFC4556] or id-kp- 190 clientAuth [RFC3280]. If the client is authenticated as expected, 191 the acceptor issues a service ticket to the initiator per [RFC4120]. 192 193 Upon receipt of the reply, the initiator validates the pre- 194 authentication data in the reply per Section 3.2.4 of [RFC4556]. As 195 stated earlier, there is no KDC in PKU2U, thus the requirement of the 196 id-pkinit-KPKdc is not applicable when PKU2U is used. The initiator 197 MUST verify the binding between the signing key in the reply and the 198 acceptor. When the GSS-API acceptor is identified using the 199 targ_name parameter of the GSS_Init_sec_context() call, the signing 200 key MUST be bound with the targ_name. The acceptor's X.509 201 certificate MUST contain id-kp-clientAuth [RFC3280] or id-kp- 202 serverAuth [RFC3280] or id-pkinit-KPClientAuth [RFC4556]. 203 204 The Kerberos principal name form and the host-based service Name 205 described in [RFC1964] MUST be supported by conforming 206 implementations of this specification. 207 208 Once the AS-REP in the reply is accepted, the initiator can use the 209 obtained service to construct an AP-REQ and communicate with the 210 acceptor. The rest of the protocol and the GSS-API binding are the 211 same as defined in [WS-KERB] and [RFC4121]. 212 213 2144 Security Considerations 215 216 The security considerations in [RFC4556] apply here. In addition, 217 the initiator and the acceptor MUST be able to verify the binding 218 between the signing key and the associated identity. 219 220 221 222Zhu, et al. Expires May 11, 2007 [Page 4] 223 224Internet-Draft PKU2U November 2006 225 226 2275 Acknowledgements 228 229 The authors would like thanks Jeffery Hutzelman for his comments with 230 regarding to unifying [WS-KERB] with PKU2U . 231 232 2336 IANA Considerations 234 235 Section 3 defines the PKU2U realm. The IANA registry for the 236 reserved names should be updated to reference this document. 237 238 2397. Normative References 240 241 [KRB-NAME] L. Zhu, "Additional Kerberos Naming Constraints", 242 draft-ietf-krb-wg-naming, work in progress. 243 244 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 245 RFC 1964, June 1996. 246 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, March 1997. 249 250 [RFC2743] Linn, J., "Generic Security Service Application Program 251 Interface Version 2, Update 1", RFC 2743, January 2000. 252 253 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 254 X.509 Public Key Infrastructure Certificate and 255 Certificate Revocation List (CRL) Profile", RFC 3280, 256 April 2002. 257 258 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 259 Kerberos Network Authentication Service (V5)", RFC 4120, 260 July 2005. 261 262 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 263 Version 5 Generic Security Service Application Program 264 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 265 July 2005. 266 267 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 268 Simple and Protected Generic Security Service Application 269 Program Interface (GSS-API) Negotiation Mechanism", 270 RFC 4178, October 2005. 271 272 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 273 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 274 275 276 277 278Zhu, et al. Expires May 11, 2007 [Page 5] 279 280Internet-Draft PKU2U November 2006 281 282 283 [WS-KERB] L. Zhu, "Kerberos for Web Services", draft-zhu-ws-kerb, work 284 in progress. 285 286Authors' Addresses 287 288 Larry Zhu 289 Microsoft Corporation 290 One Microsoft Way 291 Redmond, WA 98052 292 US 293 294 Email: lzhu@microsoft.com 295 296 297 Ari Medvinsky 298 Microsoft Corporation 299 One Microsoft Way 300 Redmond, WA 98052 301 US 302 303 Email: arimed@microsoft.com 304 305 306 Jeffery 307 Secure End Points 308 612 West 115th Street Room 716 309 New York, NY 10025 310 US 311 312 Email: jaltman@secureendpoint.com 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337Zhu, et al. Expires May 11, 2007 [Page 6] 338 339Internet-Draft PKU2U November 2006 340 341 342Full Copyright Statement 343 344 Copyright (C) The Internet Society (2006). 345 346 This document is subject to the rights, licenses and restrictions 347 contained in BCP 78, and except as set forth therein, the authors 348 retain all their rights. 349 350 This document and the information contained herein are provided on an 351 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 352 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 353 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 354 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 355 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 356 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 357 358 359Intellectual Property 360 361 The IETF takes no position regarding the validity or scope of any 362 Intellectual Property Rights or other rights that might be claimed to 363 pertain to the implementation or use of the technology described in 364 this document or the extent to which any license under such rights 365 might or might not be available; nor does it represent that it has 366 made any independent effort to identify any such rights. Information 367 on the procedures with respect to rights in RFC documents can be 368 found in BCP 78 and BCP 79. 369 370 Copies of IPR disclosures made to the IETF Secretariat and any 371 assurances of licenses to be made available, or the result of an 372 attempt made to obtain a general license or permission for the use of 373 such proprietary rights by implementers or users of this 374 specification can be obtained from the IETF on-line IPR repository at 375 http://www.ietf.org/ipr. 376 377 The IETF invites any interested party to bring to its attention any 378 copyrights, patents or patent applications, or other proprietary 379 rights that may cover technology that may be required to implement 380 this standard. Please address the information to the IETF at 381 ietf-ipr@ietf.org. 382 383 384Acknowledgment 385 386 Funding for the RFC Editor function is provided by the IETF 387 Administrative Support Activity (IASA). 388 389 390 391 392 393Zhu, et al. Expires May 11, 2007 [Page 7] 394 395 396