idnits 2.17.1 draft-ietf-tls-ac509prof-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-03-28) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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. 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 83 has weird spacing: '...erifier any...' == (4 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 1. the time of evaluation MUST be within validity (if the evaluation time is equal to either notBefore or notAfter then the AC is timely, i.e. this check succeeds) 2. the signature must be valid - based on a PKC for the AC issuer 3. the AC validity.notBefore must be within the validity period of the AC issuer's PKC 4. if an AC contains attributes apparently encrypted for the AC verifier then the decryption process MUST not fail - if decryption fails then the AC MUST be rejected 5. the AC targeting check MUST pass (see section 4.4.3 above) 6. the AC issuer MUST be explicitly trusted - this is NOT the same as the AC having a valid PKC - the AC verifier will require some additional configuration/parameterisation in order to determine this 7. if the AC contains any "unsupported" critical extensions then the AC MUST be rejected. -- 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 9352 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 598 -- Looks like a reference, but probably isn't: '1' on line 484 == Outdated reference: A later version (-13) exists of draft-ietf-smime-cms-05 == Outdated reference: A later version (-12) exists of draft-ietf-smime-ess-05 == Outdated reference: A later version (-11) exists of draft-ietf-pkix-ipki-part1-07 Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 4 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 An Internet AttributeCertificate 6 Profile for 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, please 25 check the "1id-abstracts.txt" listing contained in the 26 Internet-Drafts Shadow Directories on ftp.is.co.za 27 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 29 West Coast). 31 <> 33 Abstract 35 Authorization support is required for various Internet 36 protocols, for example, TLS, CMS and their consumers, 37 and others. The X.509 AttributeCertificate provides a 38 structure which can form the basis for such services 39 [X.509]. This specification defines two profiles (a 40 simple one and a "full" one) for the use of X.509 41 AttributeCertificates to provide such authorization 42 services. 44 1. Introduction 46 The provision of authentication, data integrity and 47 confidentiality services for current Internet protocols 48 is well understood and many secure transports are defined 49 (e.g. TLS, IPSEC etc.). In many applications these 50 services are not sufficient (or too cumbersome to 51 administer) to provide the type of authorization services 52 required. 54 Farrell, S. Expires Feb. 20, 1999 [Page 1] 55 AttributeCertificates (ACs) provide a method of 56 overcoming these problems. An AC is a structure which is 57 similar to an X.509 public key certificate with the main 58 difference being that it contains no public key. The AC 59 typically contains group membership, role, clearance and 60 other access control information associated with the AC 61 owner. 63 In conjunction with authentication services ACs provide 64 the means to securely transport authorization information 65 to applications. 67 The next section introduces some simple terminology. This 68 is followed a brief statement of requirements, then by 69 the definition of the "full" profile. The following 70 section describes an algorithm for AC validation. Next a 71 very limited, "simple" profile is defined and this is 72 followed by a description of security considerations 73 related to use of this specification. Appendices contain 74 sample ACs and a compilable ASN.1 module. 76 2. Terminology 78 Term Meaning 80 AC AttributeCertificate 81 AC user any entity that parses or processes an 82 AC 83 AC verifier any entity that checks the validity of 84 an AC and then makes use of the result 85 AC issuer the entity which signs the AC 86 AC owner the entity indicated (perhaps 87 indirectly) in the subject field of the 88 AC 89 Client the entity which is requesting the 90 action for which authorization checks 91 are to be made 92 PKC Public Key Certificate - uses the type 93 ASN.1 Certificate defined in X.509. This 94 (non-standard) acronym is used in order 95 to avoid confusion about the term "X.509 96 certificate". 97 Server the entity which requires that the 98 authorization checks are made 100 Farrell, S. Expires Feb. 20, 1999 [Page 2] 101 3. Requirements 103 The following are the requirements which the "full" 104 profile defined here meets. 106 Time/Validity requirements: 108 1. Support for short-lived or long-lived ACs is 109 required. Typical validity periods might be measured in 110 hours, as opposed to months for X.509 certificates. Short 111 validity periods mean that ACs can be usable without 112 mandating a revocation scheme. 114 Attribute Types: 116 2. Issuers of ACs should be able to define their own 117 attribute types for use within closed domains. 118 3. Some standard attribute types should be defined 119 which can be contained within ACs, for example "access 120 identity", "group", "role", "clearance", "audit 121 identity", "charging id" etc. 122 4. Standard attribute types should be defined so that 123 it is possible for an AC verifier to distinguish between 124 e.g. the "Administrators group" as defined by SSE and the 125 "Administrators group" as defined by Widgets inc. 126 5. ACs should support the encryption of some, or all, 127 attributes (e.g. passwords for legacy applications). It 128 should be possible for such an encrypted attribute to be 129 deciphered by an appropriate AC verifier even where the 130 AC has not been received directly from the AC owner (i.e. 131 where the AC is delegated). 133 Targeting of ACs: 135 6. It should be possible to "target" an AC. This means 136 that a given AC may be "targeted" at one, or a number of, 137 servers/services in the sense that a trustworthy non- 138 target will reject the AC for authorization decisions. 140 Delegation: 142 7. It should be possible for a server to delegate an AC 143 when it acts as a client (for another server) on behalf 144 of the AC owner. 145 8. Delegation should be under the AC issuer's control, 146 so that not every AC is delegatable and so that a given 147 delegatable AC can be delegated in a targeted fashion. 148 9. Delegation should support chains of delegation where 149 more than one intermediate server is used. 151 Farrell, S. Expires Feb. 20, 1999 [Page 3] 152 Push vs. Pull 154 10. ACs should be defined so that they can either be 155 "pushed" by the client to the server, or "pulled" by the 156 server from a network service (whether the AC issuer or a 157 directory service). 159 This profile specifically imposes no requirements for: 161 1. The meaning of a chain of ACs 162 2. AC revocation 163 3. AC translation 165 Support for such features may be part of some other 166 profile. 168 From this point in the document, the use of MUST, SHOULD 169 etc. is in conformance to [RFC2119] 171 4. The AC Profile 173 This section specifies the profile of the X.509 AC which 174 is to be supported by conforming implementations. 176 4.1 X.509 AttributeCertificate Definition 178 X.509 contains the definition of an AttributeCertificate 179 given below. Types which are not defined can be found in 180 [PKIX-1] 182 AttributeCertificate ::= 183 SIGNED AttributeCertificateInfo 185 AttributeCertificateInfo ::= SEQUENCE { 186 version Version DEFAULT v1, 187 subject CHOICE { 188 baseCertificateID [0] IssuerSerial, 189 subjectName [1] GeneralNames 190 }, 191 issuer GeneralNames, 192 signature AlgortihmIdentifier, 193 serial CertificateSerialNumber, 194 validity AttrCertValidityPeriod, 195 attributes SEQUENCE OF Attribute, 196 issuerUID UniqueIdentifier OPTIONAL, 197 extensions Extensions OPTIONAL 198 } 200 Farrell, S. Expires Feb. 20, 1999 [Page 4] 201 AttrCertValidityPeriod ::= SEQUENCE { 202 notBefore GeneralizedTime, 203 notAfter GeneralizedTime 204 } 206 IssuerSerial ::= SEQUENCE { 207 issuer GeneralNames, 208 serial INTEGER, 209 issuerUID UniqueIdentifier OPTIONAL 210 } 212 4.2 Object Identifiers 214 The following OIDs are used: 216 ietf-ac OBJECT IDENTIFIER ::= <> 217 ietf-ac-extensions OBJECT IDENTIFIER ::= { ietf-ac 1} 218 ietf-ac-attributes OBJECT IDENTIFIER ::= { ietf-ac 2} 220 4.3 Profile of Standard Fields. 222 4.3.1 version 224 This must be the default value of v1, i.e. not present in 225 encoding. 227 4.3.2 subject 229 For any protocol where the AC is passed in an 230 authenticated message or session, and where the 231 authentication is based on the use of an X.509 public key 232 certificate (PKC), the subject field MUST use the 233 baseCertificateID. 235 With the baseCertificateID option, the subject's PKC 236 serialNumber and issuer MUST be identical to the AC 237 subject field. The PKC issuer MUST have a non-NULL X.500 238 name which is to be present as the single value of the of 239 the subject.issuerSerial.issuer construct in the 240 directoryName field. The subject.issuerSerial.issuerUID 241 field MUST only be used if the subject's PKC contains an 242 issuerUniqueID field. 244 The above means that the baseCertificateID is only usable 245 with PKC profiles (like PKIX) which mandate that the PKC 246 issuer field contain a value. 248 If the subject field uses the subjectName option then 249 only one name should be present. 251 Farrell, S. Expires Feb. 20, 1999 [Page 5] 252 For all GeneralName fields in this profile the otherName, 253 x400Address, ediPartyName and registeredId options MUST 254 NOT be used 256 Any protocol which uses this profile SHOULD specify which 257 AC subject option is to be used and how this fits with 258 e.g. peer-entity authentication in the protocol. 260 4.3.3 issuer 262 ACs conforming to this profile MUST contain one and only 263 one GeneralName which must contain its value in the 264 directoryName field. This means that all AC issuers MUST 265 have non-NULL X.500 names. 267 4.3.4 validity 269 The validity field specifies the period for which the AC 270 issuer expects that the binding between the subject and 271 the attributes fields will be valid. There is no implied 272 guarantee that the binding will actually be valid at any 273 given moment during the validity period. 275 GeneralizedTime encoding is restricted as specified in 276 [PKIX-1] for the corresponding fields in a PKC. 278 Note that AC users MUST be able to handle the case where 279 an AC is issued, which (at the time of parsing), has its 280 entire validity period in the future (a "post-dated" AC). 281 This is valid for some applications, e.g. backup. 283 4.3.5 signature 285 Contains the algorithm identifier used to validate the AC 286 signature. 288 This MUST be one of: 290 algorithm OID 292 rsaWithSHA1 tbs - from PKIX/CMS 293 rsaWithMD5 tbs 294 dsaWithSHA1 tbs 295 dsaWithMD5 tbs 297 dsaWithSHA1 MUST be supported by all AC users. The other 298 algorithms SHOULD be supported. 300 Farrell, S. Expires Feb. 20, 1999 [Page 6] 301 4.3.6 serial 303 For any given AC issuer, the issuer/serial pair MUST form 304 a unique combination, even if ACs are very short-lived 305 (one second is the shortest possible validity according 306 to the above). 308 AC issuers MUST force the serial number to be a positive 309 integer, that is, the topmost bit in the DER encoding of 310 the INTEGER value MUST NOT be a `1'B - this is done by 311 adding a leading (leftmost) `00'H octet if necessary. 312 This removes a potential ambiguity in mapping between an 313 string of octets and a serial number. 315 Given the uniqueness and timing requirements above serial 316 numbers can be expected to contain long integers, i.e. AC 317 users MUST be able to handle more than 32 bit integers 318 here. 320 There is no requirement that the serial numbers used by 321 any AC issuer follow any particular ordering, e.g. they 322 needn't be monotonically increasing with time. 324 4.3.7 attributes 326 The attributes field gives information about the AC 327 owner. When the AC is used for authorization this will 328 often contain a set of privileges. However, authorization 329 may also require support for "restrictions" - these are 330 not carried within the attributes field (though they 331 "belong" to the AC owner) but in the extensions field. 333 The attributes field contains a SET OF Attribute. For a 334 given AC each attribute type in the set MUST be unique, 335 that is, only one instance of each attribute type can 336 occur in a single AC. Each instance can however, be multi- 337 valued. 339 AC consumers MUST be able to handle multiple values for 340 all attribute types. 342 Standard attribute types are defined in section 4.5. 344 4.3.8 issuerUID 346 This field MUST NOT be used. 348 Farrell, S. Expires Feb. 20, 1999 [Page 7] 349 4.3.9 extensions 351 The extensions field generally gives information about 352 the AC as opposed to information about the AC owner. The 353 exception is where restrictions are to be supported. If 354 one regards a restriction as a qualification on a 355 privilege then it is clear that restrictions must be 356 implemented as a critical extension. 358 Section 4.4 defines the extensions which MAY be used with 359 this profile. An AC which has no extensions conforms to 360 the profile. If any other critical extension is used, 361 then the AC does not conform to this profile. An AC which 362 contains additional non-critical extensions still 363 conforms. 365 4.4 Extensions. 367 4.4.1 Restrictions 369 A restriction is a "negative" privilege, for example an 370 AC may "state" that the AC owner is a member of the 371 administrative group except for purposes of backup. 372 Restrictions would more properly be implemented as a 373 separate field of the AC, but with the current version 374 can only be supported via the use of a critical 375 extension. 377 The value of this extension will be a SEQUENCE OF 378 Attribute. The rules stated above for the AC attributes 379 field (only one instance of each type etc.) apply here 380 also. 382 In addition an attribute type which occurs in the 383 attributes field MUST NOT occur in the restrictions field 384 (if present). This ensures that the entire AC contains 385 only one instance of any attribute type at the expense of 386 forcing the definition of new OIDs for some restrictions. 388 OID { ietf-ac-extensions 1 } 389 syntax SEQUENCE OF Attribute 390 criticality MUST be TRUE 392 4.4.2 Audit Identity 394 In some circumstances it is required (e.g. by data 395 protection/data privacy legislation) that audit trails do 396 not contain records which identify individuals. This 397 makes the use of the subject field of the AC unsuitable 398 for use in audit trails. 400 Farrell, S. Expires Feb. 20, 1999 [Page 8] 401 In order to allow for such cases an AC MAY contain an 402 audit identity extension. Ideally it SHOULD be impossible 403 to derive the AC owner's identity from the audit identity 404 value. 406 The value of the audit identity plus the AC issuer/serial 407 should then be used for audit/logging purposes. If the 408 value of the audit identity is suitably chosen then a 409 server/service administrator can track the behaviour of 410 an AC owner without being able to identify the AC owner. 412 The server/service administrator in combination with the 413 AC issuer can presumably identify the AC owner in cases 414 where mis-behaviour is detected. 416 Of course, auditing could be based on the AC 417 issuer/serial pair, however, this method doesn't allow 418 tracking the same AC owner across different ACs. This 419 means that an audit identity is only useful if it lasts 420 for longer than the typical AC lifetime - how much longer 421 is an issue for the AC issuer implementation. 423 As the AC verifier might otherwise use the AC subject or 424 some other identifying value for audit purposes, this 425 extension MUST be critical when used. 427 Protocols which use ACs will often expose the identity of 428 the AC owner in the bits on-the-wire. In such cases, an 429 "opaque" audit identity does not make use of the AC 430 anonymous, it simply ensures that the ensuing audit 431 trails are "semi-anonymous". 433 OID { ietf-ac-extensions 3 } 434 syntax OCTET STRING 435 criticality must be TRUE 437 4.4.3 AC Targeting 439 In order to allow that an AC is "targeted" the delegation 440 information extension specifies a number of 441 servers/services. The intent is that the AC should only 442 be usable at these servers/services - an (honest) AC 443 verifier who is not amongst the named servers/services 444 MUST reject the AC. 446 This extension also controls delegation. 448 Farrell, S. Expires Feb. 20, 1999 [Page 9] 449 If this extension is not present then the AC is not 450 delegatable. Any server which receives the AC such that 451 the subject and the authenticated peer-entity do not 452 match MUST reject the AC. 454 When this extension is present we are essentially 455 checking that the entity from which the AC was received 456 was allowed to send it and that the AC is allowed to be 457 used by this recipient. 459 The targeting information consists of the direct 460 information (targets field) and an optional set of 461 delegate information (delegates field). If the "direct 462 check" or any of the "delegate" checks (see below) pass 463 then the "targeting check" as a whole is successful. 465 Though the rules given below look complex, they aren't - 466 the effect is that the AC owner can send to any valid 467 target which can then only delegate to targets which are 468 in one of the same delegate sets as itself. 470 The following data structure is used to represent the 471 targeting/delegation information. 473 DelegationInfo ::= SEQUENCE { 474 owner CHOICE { 475 baseCertificateID [0] IssuerSerial, 476 subjectName [1] GeneralNames 477 }, 478 targets Targets OPTIONAL, 479 delegates SEQUENCE OF Targets OPTIONAL 480 } 481 Targets ::= SEQUENCE OF Target 482 Target ::= CHOICE { 483 targetName [0] GeneralName, 484 targetGroup [1] GeneralName 485 } 487 We represent a special target, called "ALL" which is a 488 wildcard as a targetName with the OID choice and a value 489 of {ietf-ac-extensions 4 1}. 491 The direct check passes if: 493 the identity of the client as established by the 494 underlying authentication service matches the owner 495 field 496 and 497 ( 498 the targets field contains one targetName which 499 is the "ALL" value 500 or 501 the current server (recipient) is one of the 502 targetName fields in the targets part 503 or 504 the current server is a member of one of the 505 targetGroup fields in the targets part. 506 ) 508 How the membership of a target within a targetGroup is 509 determined is not defined here. It is assumed that any 510 given target "knows" the names of the targetGroup's to 511 which it belongs or can otherwise determine its 512 membership. 514 A delegate check succeeds if 516 ( 517 the identity of the sender as established by 518 the underlying authentication service matches 519 the owner field 520 and 521 ( 522 the current server "matches" any one of 523 the delegate sets (where "matches" is as 524 for the direct check above) 525 ) 526 ) 527 or 528 ( 529 the identity of the sender as established by 530 the underlying authentication service "matches" 531 one of the delegate sets (call it set "A") 532 and 533 ( 534 the current server is one of the targetName 535 fields in the set "A" 536 or 537 the current server is a member of one of the 538 targetGroup fields in set "A". 539 ) 540 ) 542 Where an AC is delegated more than once a number of 543 targets will be on the path from the original client 544 which is normally, but not always, the AC owner. In such 545 cases prevention of AC "stealing" requires that the AC 546 verifier MUST check that all targets on the path are 547 members of the same delegate set. It is the 548 responsibility of the AC using protocol to ensure that a 549 trustworthy list of targets on the path is available to 550 the AC verifier. 552 OID { ietf-ac-extensions 4 } 553 syntax DelegationInfo 554 criticality must be TRUE 556 4.4.4 authorityKeyIdentifier 558 The authorityKeyIdentifier extension as profiled in [PKIX- 559 1] MAY be used to assist the AC verifier in checking the 560 signature of the AC. The [PKIX-1] description should be 561 read as if "CA" meant "AC issuer". As with PKCs this 562 extension SHOULD be included in ACs. 564 OID { id-ce 35 } 565 syntax AuthorityKeyIdentifier 566 criticality MUST be FALSE 568 4.5 Attribute Types 570 <> 574 Some of the attribute types defined below make use of the 575 IetfAttrSyntax type defined below. The reasons for using 576 this type are: 578 1.It allows a separation between the AC issuer and the 579 attribute policy authority. This is useful for situations 580 where a single policy authority (e.g. an organisation) 581 allocates attribute values, but where multiple AC issuers 582 are deployed for performance, network or other reasons. 583 2.It allows the type of the attribute (privilege, 584 restriction) to be made explicit which helps server 585 implementations which provide an API on top of an AC 586 validation module. 587 3.The syntaxes allowed for values are restricted to 588 OCTET STRING and OID which reduces some of the matching 589 complexities associated with GeneralName. 591 IetfAttrSyntax ::= SEQUENCE OF { 592 type INTEGER { 593 privilege(0), 594 restriction(1), 595 other(2) 596 } 597 DEFAULT privilege, 598 policyAuthority[0] GeneralNames OPTIONAL, 599 values SEQUENCE OF CHOICE { 600 octets OCTET STRING, 601 oid OBJECT IDENTIFIER 602 } 603 } 605 4.5.1 Service Authentication Info 607 This attribute type identifies the AC owner to the 608 server/service by a name and with optional authentication 609 information. Typically this will contain a 610 username/password pair for a "legacy" application (and 611 hence MAY need to be encrypted). 613 OID { ietf-ac-attributes 1} 614 Syntax SvceAuthInfo 615 values: Multiple allowed 617 SvceAuthInfo ::= SEQUENCE { 618 service GeneralName, 619 ident GeneralName, 620 authInfo OCTET STRING OPTIONAL 621 } 623 4.5.2 Access Identity 625 An access identity identifies the AC owner to the 626 server/service. For this attribute the authInfo field 627 MUST NOT be present. 629 OID { ietf-ac-attributes 2} 630 syntax SvceAuthInfo 631 values: Multiple allowed 633 4.5.3 Charging Identity 635 This attribute type identifies the AC owner for charging 636 purposes. 638 OID { ietf-ac-attributes 3} 639 syntax IetfAttrSyntax 640 values: Multiple allowed 642 4.5.4 Group 644 This attribute carries information about group 645 memberships of the AC owner. 647 <> 650 OID { ietf-ac-attributes 4} 651 syntax IetfAttrSyntax 652 values: Multiple allowed 654 4.5.5 Role 656 This attribute carries information about role allocations 657 of the AC owner. 659 OID { ietf-ac-attributes 5} 660 syntax IetfAttrSyntax 661 values: Multiple allowed 663 4.5.6 Clearance 665 This attribute carries clearance (security labelling) 666 information about the AC owner. 668 OID { id-aa-securityLabel } 669 { iso(1) member-body(2) us(840) rsadsi(113549) 670 pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} 671 syntax ESSSecurityLabel - imported from [ESS] 672 values Multiple allowed 674 4.5.7 EncryptedAttributes 676 Where an AC will be carried in clear within an 677 application protocol or where an AC which may be 678 delegated contains some sensitive information (e.g. a 679 legacy application username/password) then encryption of 680 AC attributes MAY be needed. 682 When a set of attributes are to be encrypted within an 683 AC, the cryptographic message syntax, EnvelopedData 684 structure [CMS] is used to carry the ciphertext(s) and 685 associated per-recipient keying information. 687 This type of attribute encryption is targeted which means 688 that before the AC is signed the attributes have been 689 encrypted for a set of predetermined recipients. 691 The AC then contains the ciphertext(s) inside its signed 692 data. 694 The "enveloped-data" (id-envelopedData) ContentType is 695 used and the content field will contain the EnvelopedData 696 type. 698 Only one encrytpedAttributes attribute can be present in 699 an AC - however it MAY be multi-valued and each of its 700 values will contain an EnvelopedData. 701 Each value can contain a set of attributes (each possibly 702 a multi-valued attribute) encrypted for a set of 703 recipients. 705 The cleartext which is encrypted has the type: 707 ACClearAttrs ::= SEQUENCE { 708 acIssuer GeneralName, 709 acSerial INTEGER, 710 attrs SEQUENCE OF Attribute 711 } 713 The DER encoding of the ACClearAttrs structure is used as 714 the encryptedContent field of the EnvelopedData, i.e. the 715 DER encoding MUST be embedded in an OCTET STRING. 717 The acIssuer and serial fields are present to prevent 718 ciphertext stealing - when an AC verifier has 719 successfully decrypted an encrypted attribute it MUST 720 then check that the AC issuer and serial fields contain 721 the same values. This prevents a malicious AC issuer from 722 copying ciphertext from another AC issuer's AC into an AC 723 issued by the malicious AC issuer. 725 The procedure for an AC issuer when encrypting attributes 726 is illustrated by the following (any other procedure 727 which gives the same result is fine): 729 1.Identify the sets of attributes which are to be 730 encrypted for each set of recipients. 731 2.For each attribute set which is to be encrypted: 732 2.1. Create an EnvelopedData structure for the data for 733 this set of recipients. 734 2.2. Encode the EnvelopedData as a value of the 735 EncryptedAttributes attribute 736 2.3. Ensure the cleartext attribute(s) are not present in 737 the to-be-signed AC 738 3.Add the EncryptedAttribute (with its multiple 739 values) to the AC 741 OID { ietf-ac-attributes 6} 742 Syntax ContentInfo 743 values Multiple Allowed 745 5. AttributeCertificate Validation 747 This section describes a basic set of rules which all 748 "valid" ACs MUST satisfy. Some additional checks are also 749 described which AC verifiers MAY choose to implement. 751 To be valid an AC MUST satisfy all of the following: 753 1. the time of evaluation MUST be within validity (if 754 the evaluation time is equal to either notBefore or 755 notAfter then the AC is timely, i.e. this check succeeds) 756 2. the signature must be valid - based on a PKC for the 757 AC issuer 758 3. the AC validity.notBefore must be within the 759 validity period of the AC issuer's PKC 760 4. if an AC contains attributes apparently encrypted 761 for the AC verifier then the decryption process MUST not 762 fail - if decryption fails then the AC MUST be rejected 763 5. the AC targeting check MUST pass (see section 4.4.3 764 above) 765 6. the AC issuer MUST be explicitly trusted - this is 766 NOT the same as the AC having a valid PKC - the AC 767 verifier will require some additional 768 configuration/parameterisation in order to determine this 769 7. if the AC contains any "unsupported" critical 770 extensions then the AC MUST be rejected. 772 "Support" for an extension in this context means: 774 1.the AC verifier MUST be able to parse the extension 775 value 776 2.where the extension value SHOULD cause the AC to be 777 rejected, the AC verifier MUST reject the AC 779 Additional Checks: 781 1.The AC MAY be rejected on the basis of further AC 782 verifier configuration, for example an AC verifier may be 783 configured to reject ACs which contain or lack certain 784 attribute types 785 2.If the AC verifier provides an interface which 786 allows applications to query the contents of the AC, then 787 the AC verifier MAY filter the attributes from the AC on 788 the basis of configured information, e.g. an AC verifier 789 might be configured not to return certain attributes to 790 certain targets. 792 6. Conformance 794 This specification defines two levels of conformance, 795 simple and full. For each level the actors involved must 796 meet different requirements. The intention is that 797 support for the simple level should allow for freely 798 interoperable but fairly inflexible and "featureless" AC 799 based authorization. Full conformance requires more 800 effort from implementors, may not be as widely 801 interoperable and is harder to administer, but does offer 802 much more flexibility and many more features. 804 A fully conformant AC issuer MUST be able to produce all 805 of the attribute types and extensions specified above. A 806 fully conformant AC verifier MUST "support" all of the 807 attribute types and extensions specified above. "Support" 808 in the previous sentence means more than just parsing - 809 it means that the AC verifier (which is part of a target) 810 MUST be able to reject any AC which should not be valid 811 at that target and MUST be able to make any attributes 812 and extensions which were not fully processed available 813 to the calling application. 815 A fully conformant AC issuer is responsible to ensure 816 that no AC produced could be accepted by a simply 817 conformant AV verifier in such a way as to cause a 818 security breach. 820 <> 822 Simple conformance for an AC issuer means support for 823 production of ACs which: 825 1.always use the baseCertificateID subject name 826 alternative 827 2.are never post-dated 828 3.can contain AccessIdentity, Group and/or Role 829 attributes with multiple values 830 4.do not contain any other attributes which cannot 831 safely be ignored by an AC verifier 832 5.can contain the AuthorityKeyIdentifier extension 833 6.contain no critical extensions (and hence is not 834 delegatable) 835 7.do not contain encrypted attributes 837 Simple conformance for an AC verifier means support for 838 the validation of ACs which are produced by simply 839 conformant AC issuers. A simply comformant AC verifier 840 can ignore the presence of any unsupported attributes or 841 extensions (of course it must reject all ACs which 842 contain critical extensions) and need only make the 843 values of the above attributes available to applications. 845 7. Security Considerations 847 tbs 849 8. References 851 [CMS] Housley, R., "Cryptographic Message Syntax", 852 draft-ietf-smime-cms-05.txt, May 1998. 853 [ESS] Hoffman, P., "Enhanced Security Services for 854 S/MIME", 855 draft-ietf-smime-ess-05.txt, April 1998. 856 [PKIX-1] Housley, R., Ford, W., Polk, T, & Solo, D., 857 "Internet Public Key Infrastructure - X.509 858 Certificate and CRL profile", 859 draft-ietf-pkix-ipki-part1-07.txt, March 860 1998. 861 [RFC2119] Bradner, S., "Key words for use in RFCs to 862 Indicate Requirement Levels", RFC 2119, March 863 1997. 865 Author's Address 867 Stephen Farrell, 868 SSE Ltd. 869 Fitzwilliam Court, 870 Leeson Close, 871 Dublin 2, 872 IRELAND 874 tel: +353-1-676-9089 875 email: stephen.farrell@sse.ie 877 Appendix 1: Samples 879 tbs 881 Appendix 2: "Compilable" ASN.1 Module 883 tbs 885 Farrell, S. Expires Feb. 20, 1999 [Page 18]