idnits 2.17.1 draft-barton-gss-api-sec-party-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 a Security Considerations section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (22 February 1996) is 10292 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 11 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft D. Barton (CRC for DST) 3 22 February 1996 5 Multi-party Security Contexts Within the GSS-API 7 STATUS OF THIS MEMO 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet- Drafts as reference 17 material or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 21 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 22 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 23 Rim). 25 ABSTRACT 27 The Generic Security Service Application Program Interface (GSS-API), 28 as defined in RFC-1508 and subsequent Internet Draft documents, 29 provides security services to callers (applications) in a generic 30 fashion, supportable with a range of underlying mechanisms and 31 technologies, allowing source-level portability of applications to 32 different environments. 34 Multi-party security contexts, where security context information is 35 shared amongst more than two session peers, have received little 36 consideration within the scope of the GSS-API. This document 37 describes details of one approach for supporting multi-party security 38 services within the GSS-API. 40 1. Introduction 42 Multi-party security contexts have been overlooked in the past, 43 possibly due in part to the emphasis on the client-server paradigm 44 where only two parties need be involved in the context. There is a 45 growing need for the ability to seamlessly include multiple parties 46 in a single security context. This draft defines a number of simple 47 modifications and additions to the GSS-API enabling multi-party 48 context support. 50 2. Multi-party security 52 In some situations it is desirable to share security context 53 information between a group of parties (entities, individuals, peers, 54 what have you). For example, multi-object bindings, secure 55 conversations or even electronic contract negotiation may require 56 multi-party security contexts for authentication, confidentiality, 57 integrity, and other security services. 59 The existing specifications for the GSS-API provide no support for 60 multi-party contexts. Separate contexts must be set up between each 61 pair of parties, simulating multi-party contexts. This approach 62 requires N(N-1)/2 contexts, where N is the number of parties. As N 63 increases the management complexity and overheads increase to 64 unmanagable levels. This is a limiting factor in scaling this 65 "solution". The method proposed within this document provides a 66 single context handle for each multi-party context, simplifying the 67 management required by the application, and maintaining the paradigm 68 of the GSS-API. 70 There are two methods of establishing a multi-party security context. 71 Firstly, initiating a context directly with all of the parties via a 72 single call, and secondly, establishing a two or more party context 73 and subsequently adding parties to the context over time. These 74 approaches are respectively called "static" and "dynamic". 75 Definitions for calls supporting both approaches will be provided in 76 the following sections, with discussion of each call's behaviour, 77 input and output parameters. 79 Throughout the following discussion the term "party" will be used to 80 refer to a participating, authenticated entity. The GSS-API terms 81 these entities as "peers" or "principals", and other systems may use 82 other names. The term "party" is intended to be interchangeable with 83 any of these terms. 85 2.1 Static Multi-party Contexts 87 Static multi-party context establishment occurs via a single call 88 interface, yielding a handle to context data which, upon successful 89 completion of the initialisation process, is shared by all 90 participating parties. This behaviour is a generalisation of the 91 standard GSS-API context initialisation interface enables context 92 initialisation between two parties. The interface for this call is 93 based largely on the gss_init_sec_context() call. 95 Only one call is required for static multi-party context initiation. 96 Without the additional extensions defined for dynamic security 97 contexts, the group of parties involved in the context cannot change, 98 hence the term "static". 100 A new call for the GSS-API is defined which enables multi-party 101 context initialisation. This call is named 102 gss_init_group_sec_context() and has the following interface 103 characteristics: 105 Inputs: 107 o name_list NAME_LIST, 109 o other inputs as per gss_init_sec_context(). 111 Outputs: 113 o all outputs correspond to gss_init_sec_context(). 115 This call processes the input parameter, name_list, and attempts to 116 initialise a security context shared with each nominated party. 117 Network interactions (where necessary) may cause this call to block 118 as is the case with gss_init_sec_context(). 120 Return major_status codes: 122 o GSS_S_GROUP_UNSUPPORTED indicates that the underlying mechanism 123 has no support for multi-party contexts. 125 o others as per gss_init_sec_context(). 127 This call behaves similarly in all ways to the gss_init_sec_context() 128 call. The initiator calls this function, supplying a list of names 129 for inclusion in the context. A token is returned which must be 130 passed to all named parties for context acceptance. Multi-phase 131 token exchange (continuation) may occur between the initiator and 132 acceptors if required. 134 2.2 Dynamic Multi-party Contexts 136 Dynamic multi-party contexts are somewhat more complicated than 137 standard two party or static multi-party contexts due to extra 138 management and maintenance requirements. Addition of new parties 139 requires access control and a process by which a party external to 140 the context may gain entry to the context. Context data must be 141 maintained consistently across the group of parties in the context, 142 and parties should have a simple way of determining the list of 143 parties with whom they are sharing the context. Specifications are 144 given below for the interface characteristics of three calls 145 supporting some of the services mentioned previously; 146 gss_add_party(), gss_vote() and gss_context_parties() respectively. 148 The gss_add_party() call effectively performs a context initiation 149 with the nominated party using existing context data. This call will 150 therefore behave similarly to the gss_init_sec_context() call in many 151 ways. Continuation may occur in the intialisation phase, and 152 multi-phase token exchange may be required for context data 153 initialisation (sharing). The gss_add_party() call is intended to 154 yield tokens which can be fed as input directly into the 155 gss_accept_sec_context() call by the acceptor, rather than requiring 156 a separate API call for accepting addition to a context. 158 The gss_add_party() call: 160 Inputs: 162 o new_member_name INTERNAL NAME specifies the name of the new 163 member to add to the group. 165 o context_handle CONTEXT HANDLE group context data established using 166 gss_init_group_sec_context() or gss_init_sec_context(). 168 o output_token OCTET STRING context token generated by successful 169 call, to be passed to the new peer for processing by 170 gss_accept_sec_context() or used as input data for multi-phase 171 initiation (continuation). 173 Outputs: 175 o output_token OCTET STRING as above. 177 Return major_status codes: 179 o GSS_S_SUCCESS Successful completion 181 o GSS_S_FAILURE Failure. See minor_status for more information. 183 o GSS_S_CONTEXT_EXPIRED The context has already expired 184 o GSS_S_CREDENTIALS_EXPIRED The context is recognized, but 185 associated credentials have expired 187 o GSS_S_NO_CONTEXT The context_handle parameter did not identify a 188 valid context 190 o GSS_S_NO_CRED The supplied credentials did not reference any 191 credentials. 193 o GSS_S_BAD_NAME The target_name value provided in the input_token 194 was ill-formed. 196 o GSS_S_VOTING_INCOMPLETE Indicates that voting is not yet 197 finalised. 199 o GSS_S_CONTINUE_NEEDED as per gss_init_sec_context(). 201 The initiator calls gss_add_party(), supplying the context handle and 202 details of the party to be added. The initiator must then pass an 203 application message to all other parties, voters, informing them, at 204 the application level, that an add request has been made. The voters 205 must then register their vote using gss_vote(). Meanwhile the 206 initiator is polling the mechanism using gss_add_party(), and 207 continues to do so until all votes are registered. Once all votes 208 are registered, addition success can be determined. If addition is 209 successful, gss_add_party() returns a token which must be passed to 210 the party being added, for context acceptance using 211 gss_accept_sec_context(). 213 The process by which the application calling gss_vote() determines 214 the value of the vote it casts can be determined in a number of ways. 215 Firstly, the application could arbitrarily acknowledge all add 216 requests. Secondly, an access control list or trust scheme may be 217 used to determine whether or not to acknowledge an add request. 218 Alternatively, the user (if the application is a user-level process) 219 may be prompted for a response, particularly in the case of an 220 on-line, multi-party conversation. 222 The gss_vote() call: 224 Inputs: 226 o context_handle CONTEXT HANDLE group context data established using 227 gss_init_group_sec_context or gss_init_sec_context. 229 o vote_status BOOLEAN indicating either "yes"/TRUE or "no"/FALSE 230 response to the addition of the specified party. 232 Outputs: 234 o none 235 Return major_status codes: 237 o GSS_S_SUCCESS Successful completion 239 o GSS_S_FAILURE Failure. See minor_status for more information. 241 o GSS_S_CONTEXT_EXPIRED The context has already expired 243 o GSS_S_CREDENTIALS_EXPIRED The context is recognized, but 244 associated credentials have expired 246 o GSS_S_NO_CONTEXT The context_handle parameter did not identify a 247 valid context 249 o GSS_S_NO_CRED The supplied credentials did not reference any 250 credentials. 252 There are alternatives to the voting-based style of access control. 253 Access control lists could be used, trust-based methods or even 254 simply security policy. However, the design attempts to allow for 255 the greatest flexibility, whilst providing a useful means of access 256 control. The voting scheme was seen to satisfactorily address these 257 requirements. 259 The third call defined for the dynamic multi-party contexts 260 specification enables a party to determine the list of parties 261 sharing the context. The gss_context_parties() call consults the 262 mechanism for an authoritative reply as to the participating members 263 of the context at the current time. On successful completion the 264 call returns a list of the names of all context members. 266 The gss_context_parties() call: 268 Inputs: 270 o context_handle CONTEXT HANDLE group context data established 271 using gss_init_group_sec_context() or gss_init_sec_context(). 273 Outputs: 275 o party_list NAME LIST The list of internal names of all parties 276 sharing the context data 278 Return major_status codes: 280 o GSS_S_SUCCESS Successful completion 282 o GSS_S_FAILURE Failure. See minor_status for more information. 284 o GSS_S_CONTEXT_EXPIRED The context has already expired 285 o GSS_S_CREDENTIALS_EXPIRED The context is recognized, but 286 associated credentials have expired 288 o GSS_S_NO_CONTEXT The context_handle parameter did not identify a 289 valid context 291 o GSS_S_NO_CRED The supplied credentials did not reference any 292 credentials. 294 3 New Data Structures 296 A new data structure is necessary for multi-party context support to 297 enable a list of names to be passed into the 298 gss_init_group_sec_context() call and return from 299 gss_context_parties(). This data structure is a compound of an 300 existing GSS-API structure in a basic list data type. A C binding 301 for this data structure might be defined as follows: 303 typedef struct _name_list { 304 gss_name_type name; 305 struct _name_list *next; 306 } 307 name_list; 309 Only one other possible change to GSS-API data structures might be 310 required. The context data structure is typically highly mechanism 311 dependant, but generally contains the names of all parties involved 312 in the context. This data structure may, in some cases, need to be 313 generalised to enable the storage of more than two party names, 314 typically in the form of a single local name, and a list of the names 315 of all other parties in the context. This data type must also be 316 dynamic and able to be updated throughout the lifetime of the 317 context, to enable appropriate handling of addition of new parties to 318 the context. 320 4 References 322 Linn, J., "Generic Security Service Application Program Interface", 323 RFC 1508, September 1993. 325 Wray, J., "Generic Security Service API : C-Bindings", RFC 1509, 326 September 1993. 328 5 Acknowledgements 330 The author would like to acknowledge the assistance in preparing this 331 draft and designing the original forms of multi-party security for 332 implementation. The thanks of the author are extended to: Dr. Luke 333 O'Connor (DSTC), Gary Gaskell (DSTC), John Linn (OpenVision), David 334 Arnold (DSTC) and many others. 336 6 Appendix A : C-Bindings 338 OM_uint32 gss_init_group_sec_context( 339 OM_uint32*, /* minor_status */ 340 gss_cred_id_t, /* claimant_cred_handle */ 341 gss_ctx_id_t*, /* context_handle */ 342 gss_name_list_t, /* target_name list */ 343 const_gss_OID, /* mech_type */ 344 int, /* req_flags */ 345 OM_uint32, /* time_req */ 346 gss_channel_bindings_t, 347 /* input_chan_bindings */ 348 gss_buffer_t, /* input_token */ 349 gss_OID*, /* actual_mech_type */ 350 gss_buffer_t, /* output_token */ 351 int*, /* ret_flags */ 352 OM_uint32* /* time_rec */ 353 ); 355 OM_uint32 gss_add_party( 356 OM_uint32*, /* minor_status */ 357 gss_name_t, /* add party's name */ 358 gss_ctx_id_t, /* context_handle */ 359 gss_buffer_t* /* return GSS token */ 360 ); 362 OM_uint32 gss_vote( 363 OM_uint32*, /* minor_status */ 364 gss_ctx_id_t, /* context_handle */ 365 OM_uint32, /* operation ADD/DELETE/ETC */ 366 OM_uint32 /* vote preference */ 367 ); 369 OM_uint32 gss_context_parties( 370 OM_uint32*, /* minor_status */ 371 gss_ctx_id_t, /* context_handle */ 372 );