idnits 2.17.1 draft-zhu-negoex-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 339. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4178, but the abstract doesn't seem to directly say this. It does mention RFC4178 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC4178, updated by this document, for RFC5378 checks: 2004-11-29) -- 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 (July 7, 2008) is 5766 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 180 == Unused Reference: 'RFC2743' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 257, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP L. Zhu 3 Internet-Draft K. Damour 4 Updates: 4178 (if approved) D. McPherson 5 Intended status: Informational Microsoft Corporation 6 Expires: January 8, 2009 July 7, 2008 8 The Extended GSS-API Negotiation Mechanism (NEGOEX) 9 draft-zhu-negoex-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on January 8, 2009. 36 Abstract 38 This document defines the Extended Generic Security Service 39 Application Program Interface (GSS-API) Negotiation Mechanism 40 (NegoEx). NegoEx is a pseudo-security mechanism that logically 41 extends the SPNEGO protocol as defined in RFC4178. 43 The NegoEx protocol itself is a security mechanism negotiated by 44 SPNEGO. When selected as the common mechanism, NegoEx OPTIONALLY 45 adds a pair of meta-data messages for each negotiated security 46 mechanism. The meta-data exchange allows security mechanisms to 47 exchange auxiliary information such as trust configurations, thus 48 NegoEx provides additional flexibility beyond the negotiation 49 capabilities based on exchanging object identifiers offered by 50 SPNEGO. 52 NegoEx preserves the optimistic token semantics of SPNEGO and applies 53 that recursively. Consequently a context establishment mechanism 54 token can be included in the initial NegoEx message, and NegoEx does 55 not require an extra round-trip when the initiator's optimistic token 56 is accepted by the target. 58 Similar to SPNEGO, NegoEx defines a few new GSS-API extensions that a 59 security mechanism MUST support in order to be negotiated by NegoEx. 60 This document defines these GSS-API extensions. 62 Unlike SPNEGO however, NegoEx defines its own way for signing the 63 protocol messages in order to protect the protocol negotiation. The 64 NegoEx message signing or verification can occur before the security 65 context for the negotiated real security mechanism is fully 66 established. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 6 72 3. Presentation Language . . . . . . . . . . . . . . . . . . . . . 6 73 4. Cryptographic Computations . . . . . . . . . . . . . . . . . . 6 74 5. The NegoEx Protocol . . . . . . . . . . . . . . . . . . . . . . 7 75 6. Supporting GSS-API Extensions . . . . . . . . . . . . . . . . . 7 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 79 10. Normative References . . . . . . . . . . . . . . . . . . . . . 7 80 Appendix A. Apendix A. Protocol Data Structures and Constant 81 Values . . . . . . . . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 83 Intellectual Property and Copyright Statements . . . . . . . . . . 9 85 1. Introduction 87 If more than one GSS-API mechanism is shared between the client and 88 the server, the Simple and Protected (GSS-API) Negotiation Mechanism 89 (SPNEGO) as defined in [RFC4178] can be deployed to choose a mutually 90 preferred one. This pseudo mechanism does well in the most basic 91 scenarios but suffers from a couple of drawbacks, notably: 93 o First, the SPNEGO negotiation model is inefficient when 94 negotiating based on mechanism specific configuration information. 95 SPNEGO negotiation is based on by exchanging object identifiers 96 only, and it does not allow exchange of auxiliary information in 97 any other from. This is inefficient and often impractical in that 98 one object identifier effectively conveys only one bit of 99 information. 101 o Secondly, the SPNEGO negotiation model is inadequate when the 102 choice cannot be made by the acceptor in the initial response. In 103 SPNEGO, the negotiation information is sent one-way from the 104 initiator for the acceptor to make a choice, and the acceptor must 105 choose one when it makes the initial response. This negotiation 106 model is counter intuitive. The selection of a security mechanism 107 is typically the result of selecting one type of credentials from 108 the available set, and the initiator typically does not wish to 109 reveal credentials information often associated with user 110 identities. In practice, in order to operate in this model, the 111 Kerberos GSS-API mechanism [RFC4121] must acquire the context 112 establishment token in the initial call to GSS_Init_sec_context(). 113 If the initiator fails to acquire the Kerberos token, it must not 114 offer Kerberos; otherwise the SPNEGO context negotiation will fail 115 without being able to select the next available mechanism that 116 could work. Obtaining the initial Kerberos GSS-API context token 117 may require multiple round-trips of network calls and the cost of 118 the operation can be substantial. It is evidently suboptimal when 119 multiple GSS-API mechanisms have to operate this way. The cost of 120 authentication of any real security mechanism should be avoided or 121 minimized by SPNEGO when the security mechanism is not negotiated 122 eventually but such considerations are not facilitated by the 123 SPNEGO negotiation model. 125 The Extended Generic Security Service Application Program Interface 126 (GSS-API) Negotiation Mechanism (NegoEx) is defined to address these 127 concerns. NegoEx is a pseudo security mechanism that is negotiated 128 by SPNEGO and when negotiated, it can recursively negotiate real 129 security mechanisms. 131 Any security mechanism negotiated by NegoEx MUST support integrity 132 protection. 134 The basic form of NegoEx works as follows: 136 1. The initiator proposes a list of mechanisms in decreasing 137 preference order. For each of these mechanism, NegoEx 138 OPTIOINALLY includes a mechanism specific meta-data token. GSS- 139 API extensions are defined later in this document for NegoEx to 140 query the meta-data token for inclusion in the NegoEx message. 142 2. The acceptor then passes the meta-data token from the initiator 143 to the intended security mechanism. A meta-token for a security 144 mechanism not supported on the acceptor side is ignored. New 145 GSS-API extensions are defined later in this document for a 146 security mechanism to consume the meta-data token. When 147 processing the received meta-data token, a security mechanism 148 that reports a failure is removed from the set of mutually 149 supported mechanisms. The acceptor then responds with the list 150 of mutually supported mechanisms in decreasing preference order. 151 For each of these mechanism, NegoEx again OPTIOINALLY supplies a 152 mechanism specific meta-data token in the response. These meta- 153 data tokens are returned to NegoEx via new GSS-API extensions as 154 described in the initial step. 156 3. The initiator then passes the meta-data token to the intended 157 security mechanism by invoking the new GSS-API extensions. When 158 processing the received meta-data token, a security mechanism 159 that reports a failure is removed from the set of mutually 160 supported mechanisms. The initiator then selects a security 161 mechanism from the set of mutually-supported ones. If more than 162 one security mechanism is available, unless otherwise specified, 163 the preferred one in the server preference order SHOULD be 164 selected. Once the common security mechanism is identified, the 165 security mechanism may also negotiate mechanism-specific options 166 during its context establishments. This will be inside the 167 mechanism tokens, and invisible to the NegoEx protocol. 169 4. The selected security mechanism provides keying materials to 170 NegoEx, and NegoEx then signs and verifies the negotiation NegoEx 171 messages to protect the negotiation. 173 5. The initiator and the acceptor proceed to exchange tokens till 174 the GSS-API context for selected security mechanism is 175 established, Once the security context is established, the per- 176 message tokens are generated and verified in accordance with the 177 selected security mechanism. 179 NegoEx does not work outside of SPNEGO. When negotiated by SPNEGO, 180 NegoEx uses the concepts developed in the GSS-API specification [1]. 181 The negotiation data is encapsulated in context-level tokens. 183 Therefore, callers of the GSS-API do not need to be aware of the 184 existence of the negotiation tokens but only of the SPENGO pseudo- 185 security mechanism. 187 In its basic form NegoEx requires at least one extra round-trip. 188 Network connection setup is a critical performance characteristic of 189 any network infrastructure and extra round trips over WAN links, 190 packet radio networks, etc. really make a difference. In order to 191 avoid such an extra round trip the initial security token of the 192 preferred mechanism for the initiator may be embedded in the initial 193 NegoEx token. The optimistic mechanism token may be accompanied by 194 the meta-data tokens and the optimistic mechanism token MUST be that 195 of the first mechanism in the list of the mechanisms proposed by the 196 initiator. The signature of NegoEx messages for protecting the 197 NegoEx negotiation can also be included along with the mechanism 198 token. If the target preferred mechanism matches the initiator's 199 preferred mechanism, and when the NegoEx negotiation protection 200 messages are included along with the mechanism token, no additional 201 round trips are incurred by using the negotiation protocol. 203 2. Requirements Terminology 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 3. Presentation Language 211 This document deals with the formatting of data in an external 212 representation. The following very basic and somewhat casually 213 defined presentation syntax will be used. The syntax draws from 214 several sources in its structure. Although it resembles the 215 programming language "C" in its syntax, it would be risky to draw too 216 many parallels. The purpose of this presentation language is to 217 document NegoEx only; it has no general application beyond that 218 particular goal. 220 4. Cryptographic Computations 222 The message signing and verificaiton in NegoEx is based on[RFC3961]. 223 [RFC3961] is used here as a generic framework and this application is 224 not Kerberos specifc. 226 5. The NegoEx Protocol 228 TBD. 230 6. Supporting GSS-API Extensions 232 TBD. 234 7. Security Considerations 236 TBD 238 8. Acknowledgements 240 TBD. 242 9. IANA Considerations 244 There is no action required for IANA. 246 10. Normative References 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, March 1997. 251 [RFC2743] Linn, J., "Generic Security Service Application Program 252 Interface Version 2, Update 1", RFC 2743, January 2000. 254 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 255 Kerberos 5", RFC 3961, February 2005. 257 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 258 Kerberos Network Authentication Service (V5)", RFC 4120, 259 July 2005. 261 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 262 Version 5 Generic Security Service Application Program 263 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 264 July 2005. 266 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 267 Simple and Protected Generic Security Service Application 268 Program Interface (GSS-API) Negotiation Mechanism", 269 RFC 4178, October 2005. 271 Appendix A. Apendix A. Protocol Data Structures and Constant Values 273 TBD 275 Authors' Addresses 277 Larry Zhu 278 Microsoft Corporation 279 One Microsoft Way 280 Redmond, WA 98052 281 US 283 Email: lzhu@microsoft.com 285 Kevin Damour 286 Microsoft Corporation 287 One Microsoft Way 288 Redmond, WA 98052 289 US 291 Email: kdamour@microsoft.com 293 Dave McPherson 294 Microsoft Corporation 295 One Microsoft Way 296 Redmond, WA 98052 297 US 299 Email: davemm@microsoft.com 301 Full Copyright Statement 303 Copyright (C) The IETF Trust (2008). 305 This document is subject to the rights, licenses and restrictions 306 contained in BCP 78, and except as set forth therein, the authors 307 retain all their rights. 309 This document and the information contained herein are provided on an 310 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 311 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 312 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 313 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 314 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 315 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 317 Intellectual Property 319 The IETF takes no position regarding the validity or scope of any 320 Intellectual Property Rights or other rights that might be claimed to 321 pertain to the implementation or use of the technology described in 322 this document or the extent to which any license under such rights 323 might or might not be available; nor does it represent that it has 324 made any independent effort to identify any such rights. Information 325 on the procedures with respect to rights in RFC documents can be 326 found in BCP 78 and BCP 79. 328 Copies of IPR disclosures made to the IETF Secretariat and any 329 assurances of licenses to be made available, or the result of an 330 attempt made to obtain a general license or permission for the use of 331 such proprietary rights by implementers or users of this 332 specification can be obtained from the IETF on-line IPR repository at 333 http://www.ietf.org/ipr. 335 The IETF invites any interested party to bring to its attention any 336 copyrights, patents or patent applications, or other proprietary 337 rights that may cover technology that may be required to implement 338 this standard. Please address the information to the IETF at 339 ietf-ipr@ietf.org.