idnits 2.17.1 draft-ietf-tls-attr-cert-01.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-24) 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 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([TLS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '... peer [0] GeneralName OPTIONAL,...' RFC 2119 keyword, line 146: '... template [1] SEQUENCE OF Attribute OPTIONAL,...' RFC 2119 keyword, line 148: '... ac [2] AttributeCertificate OPTIONAL,...' RFC 2119 keyword, line 149: '... pps [3] PairingProofs OPTIONAL,...' RFC 2119 keyword, line 150: '... certs [4] Certificates OPTIONAL...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...-Drafts are...' == Line 13 has weird spacing: '...cuments of th...' == Line 19 has weird spacing: '... of six mo...' == Line 21 has weird spacing: '...afts as refer...' == Line 24 has weird spacing: '...atus of any ...' == (2 more instances...) -- 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 (August 20, 1998) is 9379 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) -- Looks like a reference, but probably isn't: '0' on line 145 -- Looks like a reference, but probably isn't: '1' on line 146 -- Looks like a reference, but probably isn't: '2' on line 148 -- Looks like a reference, but probably isn't: '3' on line 149 -- Looks like a reference, but probably isn't: '4' on line 150 == Missing Reference: 'ChangeCipherSpec' is mentioned on line 371, but not defined -- Possible downref: Normative reference to a draft: ref. 'AC509' == Outdated reference: A later version (-13) exists of draft-ietf-smime-cms-05 == Outdated reference: A later version (-06) exists of draft-ietf-tls-protocol-05 ** Downref: Normative reference to an Historic draft: draft-ietf-tls-protocol (ref. 'TLS') Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Transport Layer Security Working Group S. Farrell 2 INTERNET-DRAFT SSE 3 Expires Feb. 20, 1999. August 20, 1998 5 TLS extensions for AttributeCertificate 6 based authorization 8 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum 19 of six months and may be updated, replaced, or 20 obsoleted by other documents at any time. It is 21 inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To learn the current status of any Internet-Draft, 25 please check the "1id-abstracts.txt" listing contained 26 in the Internet-Drafts Shadow Directories on 27 ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ftp.ietf.org (US 29 East Coast), or ftp.isi.edu (US West Coast). 31 Abstract 33 This document describes extensions to [TLS] providing 34 authorization support based on the use of X.509 35 AttributeCertificates. 37 1. Introduction 39 TLS provides authentication, data integrity and 40 confidentiality services for Internet protocols. In many 41 applications these services are not sufficient to provide 42 the type of authorization services required. 44 For example, it may be that access to a resource should 45 be controlled on the basis of the client's clearance or 46 role. 48 An additional requirement is support for delegation, 49 where a intermediate TLS server acts as a client but 50 where the final target TLS server must make its access 51 decision on the basis of the initial client's rights. 53 Farrell, S. Expires Feb. 20, 1999 [Page 1] 54 While TLS doesn't provide support for these features, 55 AttributeCertificates (ACs) in conjunction with TLS do 56 provide a solution. [AC509] defines a profile of the 57 X.509 AttributeCertificate which can be used in this 58 context. 60 In the remainder of this document we describe the 61 operational models, then the new messages and data 62 structures and finally describe a method for embedding AC 63 exchange into the TLS handshake. 65 2. Operational Models 67 In some environments it is suitable for the client to 68 "push" an AC to a server. This means that no new 69 connections between the client and server domains are 70 required. It also means that no search burden is imposed 71 on servers, which improves performance. 73 In other cases it is more suitable for the client simply 74 to authenticate to the server and for the server to 75 request ("pull") the client's AC from the AC issuer or a 76 repository. A major benefit of the "pull" model is that 77 it can be implemented without changes to the client. It 78 is also more suitable for some extranet cases, where the 79 client's rights should be assigned within the server's 80 domain. 82 There are a number of possible exchanges which can occur 83 and three entities involved (client, server and AC 84 issuer). In addition the use of a directory service as a 85 repository for AC retrieval may be supported. 87 Farrell, S. Expires Feb. 20, 1999 [Page 2] 88 The diagram below shows the exchanges defined which are 89 described in later sections. 91 +--------------+ +---------------+ 92 | | | | 93 | AC Issuer +----+ | Directory | 94 | | | | | 95 +--+-----------+ | Server +-------+-------+ 96 | | Acquisition | 97 |Client | |Server 98 |Acquisition +----------------------+ |Lookup 99 | | | 100 +--+-----------+ +--+----+-------+ 101 | | AC "push" | | 102 | Client +------------------------+ Server | 103 | | (part of TLS h/shake) | | 104 +--------------+ +---------------+ 105 | 106 | Client Lookup 107 +--+-----------+ 108 | | 109 | Directory | Figure 1: AC Exchanges 110 | | 111 +--------------+ 113 Of the above exchanges, the most important to embed in 114 the TLS protocol is that between client and server. AC 115 acquisition (from an issuer or directory) is handled as a 116 higher layer protocol (a payload protocol from the TLS 117 perspective). 119 An AC carrier structure (acinfo) is defined which allows 120 for requests for ACs, responses to same and for pushing 121 ACs plus external controls in a standard manner. This 122 structure is used in all messages. 124 Farrell, S. Expires Feb. 20, 1999 [Page 3] 125 3. Data Structures 127 acinfo is the data structure which is used to "push" or 128 "pull" an AC and/or associated control information. 129 acinfo may also be used when requesting an AC from an 130 issuer. 132 A set of public key certificates may also be "pushed" 133 with an acinfo in order to assist the recipient in 134 certificate handling. 136 ACInfo ::= SEQUENCE { 137 type INTEGER { 138 clientAcquire (0), 139 clientAcquireResp (1), 140 serverAcquire (2), 141 serverAcquireResp (3), 142 acRequest (4), 143 acResponse (5) 144 }, 145 peer [0] GeneralName OPTIONAL, 146 template [1] SEQUENCE OF Attribute OPTIONAL, 147 -- only one occurrence of each attr type 148 ac [2] AttributeCertificate OPTIONAL, 149 pps [3] PairingProofs OPTIONAL, 150 certs [4] Certificates OPTIONAL 151 } 153 When an intermediate server (IS) delegates an AC to a 154 target server (TS) then the target (TS) must be able to 155 verify that the intermediate (IS) hasn't "stolen" the AC. 156 This is achieved by having the IS produce the following 157 signed ASN.1 structure: 159 PairingProof ::= SIGNED SEQUENCE { 160 init GeneralName, 161 target GeneralName, 162 issuer GeneralName, 163 serial INTEGER, 164 time GeneralizedTime, 165 nonce BIT STRING, 166 sigalg AlgorithmIdentifier 167 } 169 If traced delegation is required (ensuring that no entity 170 in the chain stole the AC) then a sequence of pairing 171 proofs must be sent (with the current one left most): 173 PairingProofs ::= SEQUENCE OF PairingProof 175 Farrell, S. Expires Feb. 20, 1999 [Page 4] 176 So long as TS can verify this data then it can check (via 177 whatever targeting is included in the AC) that IS hasn't 178 stolen the AC. 180 <> 185 <> 189 4. AC Acquisition 191 4.1 Client Acquisition 193 This exchange occurs when a client requires a new AC from 194 an issuer. The AC issuer MUST ensure that the client is 195 authenticated, most simply via TLS with client 196 authentication. This exchange may occur at network login 197 time or may happen automatically during (or before) the 198 client handshake with a TLS server (e.g. upon receipt of 199 the ACRequest message from the server - see section 8 200 below). 202 <> 207 The client sends the following message to the server (the 208 syntax used is described in [TLS]): 210 struct { 211 opaque acinfo<1..2^24-1> 212 } ClientACRequest 214 acinfo field contents are specified below. 216 Field Description 217 ===== =========== 218 type clientAcquireResp 219 peer server name or missing 220 template attributes which the client wishes to be 221 present in the AC 222 ac missing 223 pps missing 224 certs missing 226 Farrell, S. Expires Feb. 20, 1999 [Page 5] 227 The server responds with: 229 struct { 230 enum { 231 success(0), 232 success_with_changes(1), 233 failure(2), 234 denied(3), 235 (255) 236 } acstatus; 237 opaque acinfo<1..2^24-1> 238 } ClientACResponse 240 acinfo field contents are specified below. 242 Field Description 243 ===== =========== 244 type clientAcquireResp 245 peer missing 246 template missing 247 ac the AC or missing 248 pps missing 249 certs missing 251 4.2 Server Acquisition 253 Server acquisition occurs where a client has established 254 a TLS connection to the server, but hasn't provided (or 255 can't provide) an AC. The case where the client provides 256 a PairingProof is also supported. 258 Note that the server may keep a TLS session open (or 259 resume a session) with the issuer for multiple exchanges. 260 AC issuers MUST support this feature, servers MAY make 261 use of this feature. 263 Farrell, S. Expires Feb. 20, 1999 [Page 6] 264 The server sends the following message to the issuer: 266 struct { 267 opaque acinfo<1..s^24-1> 268 } ServerACRequest 270 Field Description 271 ===== =========== 272 type serverAcquire 273 peer missing if pps supplied 274 mandatory containing client name if pps 275 missing 276 template missing 277 ac missing 278 pps missing if peer supplied 279 mandatory if peer missing 280 certs may be present if pps supplied 282 The issuer responds with: 284 struct { 285 enum { 286 success(0), 287 success_with_changes(1), 288 failure(2), 289 denied(3), 290 (255) 291 } acstatus; 292 opaque acinfo<1..2^24-1> 293 } ServerACResponse 295 The fields here are as described for the ClientACResponse 296 except that the type is serverAcquireResp. 298 4.3 Client and Server Lookup 300 ACs are retrieved via LDAP. The LDAP connection MAY be 301 secured with TLS according to local policy. 303 Given a GeneralName for the peer a client or server will 304 perform the following lookup. 306 <> 309 Farrell, S. Expires Feb. 20, 1999 [Page 7] 310 Once the directory entry has been identified then the 311 value(s) of the attributeCertificateAttribute should be 312 retrieved. This is defined in [X.509] as: 314 attributeCertificateAttribute ATTRIBUTE ::= { 315 WITH SYNTAX AttributeCertificate 316 EQUALITY MATCHING-RULE certificateExactMatch 317 ID id-at-attributeCertificate 318 } 320 id-at-attributeCertificate ::= OBJECT IDENTIFIER 321 { 2 5 4 58 } 323 The selection of which of the values of the attribute are 324 to be read is out of scope of this specfication. 326 5. TLS Protocol Extensions 328 The basic requirement is to be able to include an acinfo 329 structure into TLS handshakes. 331 5.1 Session Management 333 The TLS session state (section 7, p22) now requires a new 334 item: 336 authorization information 337 An acinfo structure containing the 338 authorization information for the session. This 339 element of the state may be null. 341 5.2 Use of TLS Alerts 343 No new TLS alerts are required. 345 5.3 Handshake Protocol Extensions 347 The basic approach is to handle the acinfo structure in 348 the same way as X.509 public key certificates are 349 handled. This means that we define an ACRequest which the 350 server can send to the client and an ACInfo with which 351 the client can respond. These are analogous to the 352 existing CertificateRequest and CertificateResponse 353 messages. The extension to the interworking diagram from 354 TLS (section 7.3) is shown on the next page. 356 Farrell, S. Expires Feb. 20, 1999 [Page 8] 357 Client Server 358 ClientHello -----> 359 ServerHello 360 Certificate* 361 ServerKeyExchange* 362 CertificateRequest* 363 ACRequest* 364 <----- ServerHelloDone 365 Certificate* 366 ACInfo* 367 ClientKeyExchange 368 CertificateVerify* 369 [ChangeCipherSpec] 370 Finished -----> 371 [ChangeCipherSpec] 372 Finished 373 ApplicationData <----> ApplicationData 375 <> 381 It is to be expected that a typical scenario would be 382 where a client establishes a session with a server 383 without authorization support. At some point the client 384 requests access to a resource which can only be granted 385 if a client AC is verified. At this point the server may 386 cause a renegotiation using a HelloRequest message. 388 This is similar to cases where a client first establishes 389 anonymously and is then forced into mutual 390 authentication. 392 The following sections define the new messages in more 393 detail. 395 5.3.1 ACRequest message 397 When this message will be sent: 398 A server can optionally request an AC from the 399 client. This message, if sent, will immediately 400 follow the CertificateRequest (if it is sent). 402 Structure of this message: 403 struct { 404 opaque acinfo<1..2^24-1> 405 } ACRequest 407 Farrell, S. Expires Feb. 20, 1999 [Page 9] 408 Field Description 409 ===== =========== 410 type acRequest 411 peer missing 412 template a hint to show the client which attributes 413 are required 414 ac missing 415 pps missing 416 certs missing 418 The client MAY ignore the template field if present. 420 5.3.2 ACInfo message 422 When this message will be sent: 423 This message must be sent if the client has received 424 an ACRequest message from the server. If sent, it 425 will immediately follow the Certificate message sent 426 by the client (if sent). 428 Structure of this message: 429 struct { 430 opaque acinfo<1..2^24-1> 431 } ACInfo 433 Field Description 434 ===== =========== 435 type acResponse 436 peer missing 437 template missing 438 ac the AC ; may be missing if a pps is present 439 pps optionally present 440 certs optionally present 442 If the ac is missing but the pps is present then the 443 server may attempt to acquire or lookup the AC on the 444 basis of validation of the pps signature. Note however 445 that the pps signature does not authenticate the client 446 to the server as it is not necessarily tied to the TLS 447 session. 449 Upon receipt of this message the server can now validate 450 the AC. However the server may have to wait until after 451 the Finished message in order to trust the AC (i.e. when 452 the client is authenticated). 454 6. Conformance 456 Both clients and servers MUST support the AC "push" and 457 the relevant acquisition exchanges. Client and servers 458 MAY support the lookup exchanges. 460 A signing algorithm is required for the PairingProof 461 structure, dsaWithSHA1 MUST be supported. Other signature 462 algorithms specified in [CMS] MAY be supported. 464 7. Security Considerations 466 A server which accepts an AC from an unauthenticated 467 client may be using a stolen AC. For this reason it is 468 strongly recommended that servers only accept ACs from 469 authenticated clients. 471 A server which is presented with an AC which is 472 delegatable will be able to masquerade as the AC owner to 473 any of the other servers to which the AC can be 474 delegated. This means that the client is effectively 475 trusting the server to the extent that the AC is 476 delegatable by that server. For this reason it is 477 recommended to limit the delegation scope of ACs to the 478 minimum required. 480 8. References 482 [AC509] Farrell, S,"An Internet AttributeCertificate 483 Profile for Authorization", 484 draft-ietf-tls-ac509prof-00.txt, August 1998. 485 [CMS] Housley, R., "Cryptographic Message Syntax", 486 draft-ietf-smime-cms-05.txt, May 1998. 487 [TLS] Dierks, T., Allen C., "The TLS Protocol 488 Version 1.0", draft-ietf-tls-protocol-05.txt, 489 November 1997. 490 [X.509] ITU-T Recommendation X.509 (1997 E): 491 Information Technology - Open Systems 492 Interconnection - The Directory: 493 Authentication Framework, June 1997. 495 Author's Address 497 Stephen Farrell, 498 SSE Ltd. 499 Fitzwilliam Court, 500 Leeson Close, 501 Dublin 2, 502 IRELAND 504 tel: +353-1-676-9089 505 email: stephen.farrell@sse.ie