idnits 2.17.1 draft-ietf-aaa-authorization-reqs-01.txt: -(551): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 7 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 59 lines 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: ---------------------------------------------------------------------------- == 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). -- 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 (October 1999) is 8959 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) == Unused Reference: 'RFC2277' is defined on line 920, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'FRMW' ** Obsolete normative reference: RFC 2138 (Obsoleted by RFC 2865) -- Possible downref: Normative reference to a draft: ref. 'SAMP' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AAA Working Group S. Farrell 2 INTERNET-DRAFT Baltimore Technologies 3 Expires in six months J. Vollbrecht 4 Merit Network, Inc. 5 P. Calhoun 6 Sun Microsystems, Inc. 7 L. Gommans 8 Cabletron Systems EMEA 9 G. Gross 10 Lucent Technologies 11 B. de Bruijn 12 Interpay Nederland B.V. 13 C. de Laat 14 Utrecht University 15 M. Holdrege 16 Lucent Technologies 17 D. Spence 18 Merit Network, Inc. 19 October 1999 21 AAA Authorization Requirements 22 24 Status of this Memo 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of [RFC2026]. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. Internet-Drafts are draft documents valid for a maximum of 33 six months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet- Drafts 35 as reference material or to cite them other than as "work in 36 progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Abstract 46 This document specifies the requirements that AAA protocols must 47 meet in order to support authorization services in the Internet. The 48 requirements have been elicited from a study of a range of 49 applications including mobile-IP, roamops and others. 51 Table Of Contents 53 Status of this Memo.............................................1 54 Abstract........................................................1 55 Table Of Contents...............................................2 56 1. Introduction.................................................2 57 2. Requirements.................................................3 58 2.1 Authorization Information..............................3 59 2.2 Security of authorization information..................6 60 2.3 Time...................................................8 61 2.4 Topology...............................................9 62 2.5 Application Proxying..................................11 63 2.6 Trust Model...........................................11 64 2.7 Not just transactions.................................13 65 2.8 Administration........................................14 66 2.9 Bytes on-the-wire.....................................15 67 2.10 Interfaces............................................16 68 2.11 Negotiation...........................................16 69 3. Security Considerations.....................................18 70 4. References..................................................18 71 Author's Addresses.............................................19 72 Full Copyright Statement.......................................20 74 1. Introduction 76 <> 80 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 81 in this document are to be interpreted as described in [RFC2119]. 83 This document is one of a series of three documents prepared by the 84 AAA WG authorization subgroup dealing with the authorization 85 requirements for AAA protocols. The three documents are: 87 AAA Authorization Framework [FRMW] 88 AAA Authorization Requirements (this document) 89 AAA Authorization Application Examples [SAMP] 91 The process followed in producing this document was to analyze the 92 requirements from [SAMP] based on a common understanding of the AAA 93 authorization framework [FRMW]. This document assumes familiarity 94 with both the general issues involved in authorization and, in 95 particular, the reader will benefit from a reading of [FRMW] where, 96 for example, definitions of terms can be found. 98 2. Requirements 100 Requirements are grouped under headings for convenience; this 101 grouping is not significant. 103 Definitions and explanations of some of the technical terms used in 104 this document may be found in [FRMW]. 106 Each requirement is presented as a succinct (usually a sentence or 107 two) statement. Most are followed by a paragraph of explanatory 108 material, which sometimes contains an example. Fully described 109 examples may be found in [SAMP]. 111 The requirements presented are not intended to be "orthogonal", that 112 is, some of them repeat, or overlap, with others. 114 2.1 Authorization Information 116 2.1.1 Authorization decisions MUST be able to be based on information 117 about the requestor, the service/method requested, and the 118 operating environment (authorization information). AAA protocols 119 are required to transport this information. 121 This simply states the requirement for a protocol and an access 122 decision function, which takes inputs, based on the requestor, the 123 resource requested and the environment. 125 2.1.2 It MUST be possible to represent authorization information as 126 sets of attributes. It MAY be possible to represent authorization 127 information as objects. 129 This states that authorization information must be decomposable into 130 sets of attributes. It is not intended to imply any particular 131 mechanism for representing attributes. 133 2.1.3 It MUST be possible to package authorization information so 134 that the authorization information for multiple services or 135 applications can be carried in a single message in a AAA or 136 application protocol. 138 This states that a protocol, which always required separate AAA 139 messages/transactions for each service/application, would not meet 140 the requirement. For example, it should be possible for a single AAA 141 message/transaction to be sufficient to allow both network and 142 application access. 144 2.1.4 Standard attributes types SHOULD be defined which are relevant 145 to many Internet applications/services (e.g. identity 146 information, group information, ...) 148 There are many attributes that are used in lots of contexts, and 149 these should only be defined once, in order to promote 150 interoperability and prevent duplication of effort. 152 2.1.5 Authorization decisions MUST NOT be limited to being based on 153 identity information, i.e. AAA protocols MUST support the use of 154 non-identifying information, e.g. to support role based access 155 control (RBAC). 157 Authorization based on clearances, roles, groups or other 158 information is required to be supported. A AAA protocol that only 159 carried identity information would not meet the requirement. 161 2.1.6 Authorization data MAY include limits in addition to attributes 162 which are directly "owned" by end entities. 164 This states that some attributes do not simply represent attributes 165 of an entity, for example a spending limit of IR�1,000 is not an 166 intrinsic attribute of an entity. This also impacts on the access 167 decision function, in that the comparison to be made is not a simple 168 equality match. 170 2.1.7 It MUST be possible for other (non-AAA) protocols to define 171 their own attribute types, which can then be carried within an 172 authorization package in a AAA or application protocol. 174 This states that the attributes that are significant in an 175 authorization decision, may be application protocol dependent. For 176 example, many attribute types are defined by [RFC2138] and support 177 for the semantics of these attributes will be required. Of course, 178 only AAA entities that are aware of the added attribute types can 179 make use of them. 181 2.1.8 It SHOULD be possible for administrators of deployed systems to 182 define their own attribute types, which can then be carried within 183 an authorization package in a AAA or application protocol. 185 This states that the attributes that are significant in an 186 authorization decision, may be dependent on a closed environment. 187 For example, many organizations have a well-defined scheme of 188 seniority, which can be used to determine access levels. Of course, 189 only AAA entities that are aware of the added attribute types can 190 make use of them. 192 2.1.9 It SHOULD be possible to define new attribute types without 193 central administration and control of attribute name space. 195 A centralized or distributed registration scheme of some sort is 196 needed if collisions in attribute type allocations are to be 197 avoided. However a AAA protocol which always requires use of such a 198 centralized registration would not meet the requirement. Of course, 199 collisions should be avoided where possible. 201 2.1.10 It MUST be possible to define attribute types so that an 202 instance of an attribute in a single AAA message can have multiple 203 values. 205 This states that a protocol which does not allow multiple instances 206 of an attribute in a message/transaction would not meet the 207 requirement. For example it should be possible to have a "group" 208 attribute which contains more than one groupname (or number or 209 whatever). 211 2.1.11 If MUST be possible to distinguish different instances of the 212 same authorization attribute type or value, on the basis of 213 "security domain" or "authority". 215 This recognizes that it is important to be able to distinguish 216 between attributes based not only on their value. For example, all 217 NT domains (which use the English language) have an Administrators 218 group, an access decision function has to be able to determine to 219 which of these groups the requestor belongs. 221 2.1.12 AAA protocols MUST specify mechanisms for updating the rules 222 which will be used to control authorization decisions. 224 This states that a AAA protocol that cannot provide a mechanism for 225 distributing authorization rules is not sufficient. For example, 226 this could be used to download ACLs to a PDP. 228 Note that this is not meant to mean that this AAA protocol mechanism 229 must always be used, simply that it must be available for use. In 230 particular, storing authorization rules in a trusted repository (in 231 many cases an LDAP server) will in many cases be used instead of 232 such a AAA protocol mechanism. Neither does this requirement call 233 for a standardized format for authorization rules, merely that there 234 be a mechanism for transporting these. 236 2.1.13 The AAA protocol MUST allow for chains of AAA entities to be 237 involved in an authorization decision. 239 This states that more than one AAA server may have to be involved in 240 a single authorization decision. This may occur either due to a 241 decision being spread across more than one "domain" or in order to 242 distribute authorization within a single "domain". 244 2.1.14 The AAA protocol MUST allow for intermediate AAA entities to 245 add their own local authorization information to a AAA request or 246 response. 248 This states that where more than one AAA entity is involved in an 249 authorization decision each of the AAA entities may manipulate the 250 AAA messages involved either by adding more information or by 251 processing parts of the information. 253 2.1.15 AAA entities MAY be either be deployed independently or 254 integrated with application entities. 256 This states that the AAA entities may either be implemented as AAA 257 servers or integrated with application entities. 259 2.1.16 The AAA protocol MUST support the creation and encoding of 260 rules that are to be active inside one AAA server based on 261 attributes published by another AAA server. The level of 262 authorization of the requesting AAA Server MAY govern the view on 263 attributes. 265 This states that one AAA entity may have to distribute authorization 266 rules to another, and that the AAA entity that receives the rules 267 may only be seeing part of the story. 269 <> 270 2.1.17 AAA protocols MAY have to support the idea of critical and non- 271 critical attribute types. 273 This is analogous to the use of the criticality flag in public key 274 certificate extensions. 276 2.1.18 A AAA protocol MUST allow authorization rules to be expressed 277 in terms of combinations of other authorization rules which have 278 been evaluated. 280 For example, access may only be granted if the requestor is member 281 of the backup users group and not a member of the administrator's 282 group. Note that this requirement does not state which types of 283 combinations are to be supported. 285 2.1.19 It SHOULD be possible to make authorization decisions based on 286 the geographic location of a requestor, service or AAA entity. 288 This is just an example of an authorization attribute type, notable 289 because it requires different underlying implementation mechanisms. 291 2.1.20 It SHOULD be possible to make authorization decisions based on 292 the identity or the equipment used by a requestor, service or AAA 293 entity. 295 This is just an example of an authorization attribute type, notable 296 because it may require different underlying implementation 297 mechanisms (if IPSec isn't available). 299 <> 300 2.1.21 When there are multiple instances of a given attribute, there 301 must be an unambiguous mechanism by which a receiving peer can 302 determine the value of specified instance. 304 2.2 Security of authorization information 305 2.2.1 It MUST be possible for authorization information to be 306 communicated securely in AAA and application protocols. 307 Mechanisms that preserve authenticity, integrity and privacy for 308 this information MUST be specified. 310 This states that there must be a well-defined method for securing 311 authorization information, not that such methods must always be 312 used. Whether support for these mechanisms is to be required for 313 conformance is left open. In particular, mechanisms must be provided 314 so that a service administrator in the middle of a chain cannot read 315 or change authorization information being sent between other AAA 316 entities. 318 2.2.2 AAA protocols MUST allow for use of an appropriate level of 319 security for authorization information. AAA protocols MUST be able 320 to support both highly secure and less secure mechanisms for data 321 integrity/confidentiality etc. 323 It is important that AAA protocols do not mandate too heavy a 324 security overhead, thus the security mechanisms specified don�t 325 always need to be used (though not using them may affect the 326 authorization decision). 328 2.2.3 The security requirements MAY differ between different parts of 329 a package of authorization information. 331 Some parts may require confidentiality and integrity, some may only 332 require integrity. This effectively states that we require something 333 like selective field security mechanisms. For example, information 334 required to gain access to a network may have to be in clear, whilst 335 information required for access to an application within that 336 network may have to be encrypted in the AAA protocol. 338 2.2.4 AAA protocols MUST provide mechanisms that prevent intermediate 339 administrators breaching security. 341 This is a basic requirement to prevent man-in-the-middle attacks, 342 for example where an intermediate administrator changes AAA messages 343 on the fly. 345 2.2.5 AAA protocols MUST NOT open up replay attacks based on replay 346 of the authorization information. 348 For example, a AAA protocol should not allow flooding attacks where 349 the attacker replays AAA messages that require the recipient to use 350 a lot of CPU or communications before the replay is detected. 352 2.2.6 AAA protocols MUST be capable of leveraging any underlying peer 353 entity authentication mechanisms that may have been applied - this 354 MAY provide additional assurance that the owner of the 355 authorization information is the same as the authenticated entity. 357 For example, if IPSec provides sufficient authentication, then it 358 must be possible to omit AAA protocol authentication. 360 2.2.7 End-to-end confidentiality, integrity, peer-entity- 361 authentication, or non-repudiation MAY be required for packages of 362 authorization information. 364 This states that confidentiality, (resp. the other security 365 services), may have to be provided for parts of a AAA message, even 366 where it is transmitted via other AAA entities. It does allow that 367 such a AAA message may also contain non-confidential, resp. the 368 other security services), parts. In addition, intermediate AAA 369 entities may themselves be considered end-points for end-to-end 370 security services applied to other parts of the AAA message. 372 2.2.8 AAA protocols MUST be usable even in environments where no peer 373 entity authentication is required (e.g. a network address on a 374 secure LAN may be enough to decide). 376 This requirement (in a sense the opposite of 2.2.6), indicates the 377 level of flexibility that is required in order to make the AAA 378 protocol useful across a broad range of applications/services. 380 2.2.9 AAA protocols MUST specify "secure" defaults for all protocol 381 options. Implementations of AAA entities MUST use these "secure" 382 defaults unless otherwise configured/administered. 384 This states that the out-of-the-box configuration must be "secure", 385 for example, authorization decisions should result in denial of 386 access until a AAA entity is configured. Note that the 387 interpretation of "secure" will vary on a case-by-case basis, though 388 the principle remains the same. 390 2.3 Time 392 2.3.1 Authorization information MUST be timely, which means that it 393 MUST expire and in some cases MAY be revoked before expiry. 395 This states that authorization information itself is never to be 396 considered valid for all time, every piece of authorization 397 information must have associated either an explicit or implicit 398 validity period or time-to-live. 400 2.3.2 AAA protocols MUST provide mechanisms for revoking 401 authorization information, in particular privileges. 403 Where the validity or time-to-live is long, it may be necessary to 404 revoke the authorization information, e.g. where someone leaves a 405 company. Note that this requirement does not mandate a particular 406 scheme for revocation, so that it is not a requirement for 407 blacklists or CRLs. 409 2.3.3 A set of attributes MAY have an associated validity period - 410 such that that the set MUST only be used for authorization 411 decisions during that period. The validity period may be 412 relatively long, (e.g. months) or short (hours, minutes). 414 This states that explicit validity periods are, in some cases, 415 needed at the field level. 417 2.3.4 Authorization decisions MAY be time sensitive. Support for e.g. 418 "working hours" or equivalent MUST be possible. 420 This states that the AAA protocol must be able to support the 421 transmission of time control attributes, although it does not 422 mandate that AAA protocols must include a standard way of expressing 423 the "working hours" type constraint. 425 2.3.5 It MUST be possible to support authorization decisions that 426 produce time dependent results. 428 For example, an authorization result may be that service should be 429 provided for a certain period. In such cases a AAA protocol must be 430 able to transport this information, possibly as a specific result of 431 the authorization decision, or, as an additional "termination of 432 service" AAA message transmitted later. 434 2.3.6 It MUST be possible to support models where the authorization 435 information is issued in well in advance of an authorization 436 decision rather than near the time of the authorization decision. 438 This is required in order to support pre-paid (as opposed to 439 subscription) scenarios (e.g. for VoIP). 441 2.3.7 It SHOULD be possible to support models where the authorization 442 decision is made in advance of a service request. 444 This is for some applications such as backup, where actions are 445 scheduled for future dates. It also covers applications that require 446 reservation of resources. 448 2.3.8 A AAA mechanism must allow time stamp information to be carried 449 along with authorization information (e.g. for non-repudiation). 451 The PKIX WG is developing a time stamp protocol, which can be used 452 as part of a non-repudiation solution. In some environments it may 453 be necessary that certain AAA protocol messages are timestamped (by 454 a trusted authority) and that the timestamps are forwarded within 455 subsequent AAA messages. 457 2.4 Topology 459 2.4.1 AAA protocols MUST be able to support the use of the push, pull 460 and agent models. 462 This states that a protocol that only supported one model, say pull, 463 would not meet the requirements of all the applications. The models 464 are defined in [FRMW]. 466 2.4.2 In transactions/sessions, which involve more than one AAA 467 entity, each �hop� MAY use a different push/pull/agent model. 469 For example, in the mobile IP case, a "foreign" AAA server might 470 pull authorization information from a broker, whereas the broker 471 might push some authorization information to a "home" AAA server. 473 2.4.3 AAA Protocols MUST cater for applications and services where 474 the entities involved in the application or AAA protocols belong 475 to different (security) domains. 477 This states that it must be possible for any AAA protocol message to 478 cross security or administrative domain boundaries. Typically, 479 higher levels of security will be applied when crossing such 480 boundaries, and accounting mechanisms may also have to be more 481 stringent. 483 2.4.4 AAA protocols MUST support roaming. 485 Roaming here may also be thought of as "away-from-home" operation. 486 For example, this is a fundamental requirement for the mobile IP 487 case. 489 2.4.5 AAA protocols SHOULD support dynamic mobility 491 Dynamic mobility here means that a client moves from one domain to 492 another, without having to completely re-establish e.g. whatever AAA 493 session information is being maintained. 495 2.4.6 An authorization decision MAY have to be made before the 496 requestor has any other connection to a network. 498 For example, this means that the requestor can�t go anywhere on the 499 network to fetch anything and must do requests via an 500 application/service or via an intermediate AAA entity. The AAA 501 protocol should not overexpose such a server to denial-of-service 502 attacks. 504 2.4.7 AAA protocols MUST support the use of intermediate AAA entities 505 which take part in authorization transactions but which don�t 506 "own" any of the end entities or authorization data. 508 In some environments (e.g. roamops), these entities are termed 509 brokers (though these are not the same as bandwidth brokers in the 510 QoS environment). 512 2.4.8 AAA protocols MAY support cases where an intermediate AAA 513 entity returns a forwarding address to a requestor or AAA entity, 514 in order that the requestor or originating AAA entity can contact 515 another AAA entity. 517 This requirement recognizes that there will be routing issues with 518 AAA servers, and that this requires that AAA protocols are able to 519 help with such routing. For example, in the mobile IP case, a broker 520 may be required, in part to allow the foreign and home AAA servers 521 to get in contact. 523 2.4.9 It MUST be possible for an access decision function to discover 524 the AAA server of a requestor. If the requestor provides 525 information used in this discovery process then the access 526 decision function MUST be able to verify this information in a 527 trusted manner. 529 This states that not only do AAA servers have to be able to find one 530 another, but that sometimes an application entity may have to find 531 an appropriate AAA server. 533 2.5 Application Proxying 535 2.5.1 AAA protocols MUST support cases where applications use 536 proxies, that is, an application entity (C), originates a service 537 request to a peer (I) and this intermediary (I) also initiates a 538 service request on behalf of the client (C) to a final target (T). 539 AAA protocols MUST be such that the authorization decision made at 540 T, MAY depend on the authorization information associated with C 541 and/or with I. This "application proxying" must not introduce new 542 security weaknesses in the AAA protocols. There MAY be chains of 543 application proxies of any length. 545 Note that this requirement addresses application layer proxying - 546 not chains of AAA servers. For example, a chain of HTTP proxies 547 might each want to restrict the content they serve to the "outside". 548 As the HTTP GET message goes from HTTP proxy to HTTP proxy, this 549 requirement states that it must be possible that the authorization 550 decisions made at each stage can depend on the user at the browser, 551 and not say, solely on the previous HTTP proxy�s identity. Of course 552 there may only be a single AAA server involved, or there may be 553 many. 555 2.5.2 Where there is a chain of application proxies, the AAA protocol 556 flows at each stage MAY be independent, i.e. the first hop may use 557 the push model, the second pull, the third the agent model. 559 This simply restates a previous requirement (no. 2.4.7), to make it 560 clear that this also applies when application proxying is being 561 used. 563 2.6 Trust Model 564 2.6.1 AAA entities MUST be able to make decisions about which other 565 AAA entities are trusted for which sorts of authorization 566 information. 568 This is analogous to a requirement in pubic key infrastructures: 569 Just because someone can produce a cryptographically correct public 570 key certificate doesn�t mean that I should trust them for anything, 571 in particular, I might trust the issuer for some purposes, but not 572 for others. 574 2.6.2 AAA protocols MUST allow entities to be trusted for different 575 purposes, trust MUST NOT be an all-or-nothing issue. 577 This relates the packaging (no. 2.1.3) and trust (no. 2.6.1) 578 requirements. For example, a AAA entity may trust some parts of an 579 authorization package but not others. 581 2.6.3 A confirmation of authorization MAY be required in order to 582 initialize or resynchronize a AAA entity. 584 This states that a AAA entity may need to process some AAA protocol 585 messages in order to initialize itself. In particular, a AAA entity 586 may need to check that a previous AAA message remains "valid", e.g. 587 at boot-time. 589 2.6.4 A negation of static authorization MAY be required to shut down 590 certain services. 592 This is the converse of 2.6.5 above. It means that a AAA entity may 593 be "told" by another that a previous AAA message is no longer 594 "valid". See also 2.3.2 and 2.7.6. 596 2.6.5 It MUST be possible to configure sets of AAA entities that 597 belong to a local domain, so that they are mutually trusting, but 598 so that any external trust MUST be via some nominated subset of 599 AAA entities. 601 This states that for efficiency or organizational reasons, it must 602 be possible to set up some AAA servers through which all "external" 603 AAA services are handled. It also states that it must be possible to 604 do this without over-burdening the "internal-only" AAA servers with 605 onerous security mechanisms, just because some AAA servers do handle 606 external relations. 608 2.6.6 Intermediate AAA entities in a chain MUST be able to refuse a 609 connection approved by an earlier entity in the chain. 611 For example, in mobile IP the home network may authorize a 612 connection, but the foreign network may refuse to allow the 613 connection due to the settings chosen by the home network, say if 614 the home network will refuse to pay. 616 2.6.7 It SHOULD be possible to modify authorization for resources 617 while a session is in progress without destroying other session 618 information. 620 For example, a "parent" AAA server should be able to modify the 621 authorization state of sessions managed by a "child" AAA server, say 622 by changing the maximum number of simultaneous sessions which are 623 allowed. 625 2.7 Not just transactions 627 2.7.1 Authorization decisions MAY be context sensitive, AAA protocols 628 MUST enable such decisions. 630 This states that AAA protocols need to support cases where the 631 authorization depends, (perhaps even only depends), on the current 632 state of the system, e.g. only seven sessions allowed, seventh 633 decision depends on existence of six current sessions. Since the 634 context might involve more than one service, the AAA protocol is 635 likely to have to offer some support. 637 2.7.2 AAA protocols SHOULD support both the authorization of 638 transactions and continuing authorization of sessions. 640 This states that AAA entities may have to maintain state and act 641 when the state indicates some condition has been met. 643 2.7.3 Within a single session or transaction, it MUST be possible to 644 interleave authentication, authorization and accounting AAA 645 messages. 647 This states, that e.g. a session may have to use initial 648 authentication, authorization and accounting AAA message(s), but 649 also have to include e.g. re-authentication every 30 minutes, or a 650 continuous "drip-drip" of accounting AAA messages. 652 2.7.4 Authorization decisions may result in a "not ready" answer. 654 This states that yes and no are not the only outcomes of an 655 authorization decision. In particular, if the AAA entity cannot yet 656 give a decision, it might have to return such a result. This is 657 analogous to how public key certification requests are sometimes 658 handled in PKI management protocols. 660 2.7.5 A AAA entity MAY re-direct a AAA request that it has received. 662 This states that if entity "a" asks "b", then "b" may say: "don't 663 ask me, ask 'c'". This is analogous to HTTP re-direction (status 664 code 307). 666 2.7.6 AAA protocols SHOULD allow a AAA entity to "take back" an 667 authorization. 669 The expectation is that AAA protocols will support the ability of a 670 AAA entity to signal an application or other AAA entity that an 671 authorization (possibly previously granted by a third AAA entity) is 672 no longer valid. 674 2.8 Administration 676 2.8.1 It MUST be possible for authorization data to be administered 677 on behalf of the end entities and AAA entities. 679 This requirement indicates that administration of AAA has to be 680 considered as part of protocol design - a AAA protocol, which 681 required all AAA entities act independent of all other AAA entities, 682 would not meet the requirement. 684 2.8.2 Centralizable administration of all features SHOULD be 685 supported. 687 It should be possible (if it meets the domain requirements) to 688 centralize or distribute the administration of AAA. 690 2.8.3 AAA protocols SHOULD support cases where the user (as opposed 691 to an administrator) authorizes a transaction. 693 For example, a user might want to control anti-spam measures or 694 authorize things like a purchase. In such cases, the user is acting 695 somewhat like an administrator. 697 2.8.4 One AAA entity MAY create authorization rules for another AAA 698 entity. 700 This is required to properly support delegation of authority, 701 however when allowed, this must be able to be done in a secure 702 fashion. 704 2.8.5 AAA protocols SHOULD support failure recovery when one AAA 705 entity in a chain of AAA entities that maintain state about a 706 session fails. 708 For example, in a network access situation it may be required that a 709 AAA server which has crashed be able to determine how many sessions 710 are in progress, in order to make the "next" authorization decision. 712 2.8.6 It SHOULD be possible for a AAA entity to query the 713 authorization state of another AAA entity. 715 This may be required as part of a failure recovery procedure. 717 2.8.7 AAA protocols MUST be able to support "hot fail-over" for 718 server components without loss of state information. 720 This states that AAA protocols must be able to support cases where, 721 when a server is no longer operable, a secondary server can 722 automatically be brought "live" without losing important state 723 information. 725 2.9 Bytes on-the-wire 727 2.9.1 Authorization separate from authentication SHOULD be allowed 728 when necessary, but the AAA protocols MUST also allow for a single 729 message to request both authentication and authorization. 731 AAA protocols have to allow a split between authentication and 732 authorization so that different mechanisms are used for each. This 733 states that sometimes both types of information need to be carried 734 in the same message. 736 2.9.2 In order to minimize resource usage (e.g. reduce roundtrips) it 737 MUST be possible to embed AAA PDUs into other protocols. 739 This states that the AAA protocol authorization packages must be 740 defined so that they can also be carried in other protocols. For 741 example, depending on AAA protocol header information in order to 742 reference an authorization package could cause a protocol to fail to 743 meet the requirement. 745 2.9.3 A AAA protocol MAY provide mechanisms for replication of state 746 information. 748 This can be required e.g. to support resiliency in cases where hot 749 fail-over is required. Note that AAA protocols are of course, 750 subject to normal protocol design requirements to do with 751 reliability, no single-point-of-failure etc even though these are 752 not all specified here. 754 2.9.4 A AAA protocol SHOULD allow the possibility for implementation 755 of a gateway function between the AAA protocol and other legacy 756 AAA related protocols. 758 For example, some form of support for [RFC2138] as a legacy protocol 759 is very likely to be required. Of course, the use of such a gateway 760 is almost certain to mean not meeting some other requirements, (e.g. 761 end-to-end security), for transactions routed through the gateway. 762 There is no implication that such gateway functionality needs to be 763 a separate server. 765 2.9.5 A AAA protocol MUST be able to support use of a wide range of 766 primitive data types, including RFC2277. 768 For example, various sized, signed and unsigned integers, possibly 769 including multi-precision integers will almost certainly need to be 770 transported. Floating point support according to ANSI IEEE 754-1985 771 may also be required. 773 2.9.6 A AAA protocol transport SHOULD support being optimized for a 774 long-term exchange of small packets in a stream between a pair of 775 hosts. 777 NASes typically have a high number of transactions/second, so the 778 AAA protocol MUST allow the flow of requests to be controlled in 779 order for the server to make efficient use of it's receive buffers. 781 2.9.7 A AAA protocol MUST provide support for load balancing. 783 In the event that a peer's cannot receive any immediate requests, 784 the AAA protocol MUST allow for an implementation to balance the 785 load of requests among a set of peers. 787 2.10 Interfaces 789 2.10.1 It SHOULD be possible that authorization data can be used for 790 application purposes. 792 For example, in web access, if the authorization data includes a 793 group name, mechanisms to make this data available to the 794 application so that it can modify the URL originally requested are 795 desirable. 797 2.10.2 It SHOULD be possible that authorization data can be used to 798 mediate the response to a request. 800 For example, with web access the clearance attribute value may 801 affect the content of the HTTP response message. 803 2.10.3 AAA protocols SHOULD be able to operate in environments where 804 requestors are not pre-registered (at least for authorization 805 purposes, but possibly also for authentication purposes). 807 This is necessary to be able to scale a AAA solution where there are 808 many requestors. 810 2.10.4 AAA protocols MUST be able to support a linkage between 811 authorization and accounting mechanisms. 813 Motherhood and apple-pie. 815 2.10.5 AAA protocols MUST be able to support accountability (audit/ 816 non-repudiation) mechanisms. 818 Sometimes, an authorization decision will be made where the 819 requestor has not authenticated. In such cases, it must be possible 820 that the authorization data used is linked to audit or other 821 accountability mechanisms. Note that this requirement does not call 822 for mandatory support for digital signatures, or other parts of a 823 non-repudiation solution. 825 2.11 Negotiation 826 2.11.1 AAA protocols MUST support the ability to refer to sets of 827 authorization packages in order to allow peers negotiate a common 828 set. 830 Given that peers may support different combinations of authorization 831 attribute types and packages, the requirement states that protocol 832 support is required to ensure that the peers use packages supported 833 by both peers. 835 2.11.2 It MUST be possible to negotiate authorization packages between 836 AAA entities that are not in direct communication. 838 This states that where, e.g. a broker is involved, the end AAA 839 servers might still need to negotiate. 841 2.11.3 Where negotiation fails to produce an acceptable common 842 supported set then access MUST be denied. 844 For example, a server cannot grant access if it cannot understand 845 the attributes of the requestor. 847 2.11.4 Where negotiation fails to produce an acceptable common 848 supported set then it SHOULD be possible to generate an error 849 indication to be sent to another AAA entity. 851 If negotiation fails, then some administrator intervention is often 852 required, and protocol support for this should be provided. 854 2.11.5 It MUST be possible to pre-provision the result of a 855 negotiation, but in such cases, the AAA protocol MUST include a 856 confirmation of the "negotiation result". 858 Even if the supported packages of a peer are configured, this must 859 be confirmed before assuming both sides are similarly configured. 861 2.11.6 For each application making use of a AAA protocol, there MUST 862 be one inter-operable IETF standards-track specification of the 863 authorization package types that are "mandatory to implement". 865 This requirement assures that communicating peers can count on 866 finding at least one IETF specified inter-operable AAA protocol 867 dialect provided they are doing authorization for a common 868 application specific problem domain. This does not preclude the 869 negotiation of commonly understood but private AAA protocol 870 authorization package types (e.g. vendor specific). 872 2.11.7 It SHOULD also be possible to rank AAA negotiation options in 873 order of preference. 875 This states that, when negotiating, peers must be able to indicate 876 preferences as well as capabilities. 878 2.11.8 The negotiation mechanisms used by AAA protocols SHOULD NOT be 879 vulnerable to a "bidding-down" attack. 881 A "bidding-down" attack is where an attacker forces the negotiating 882 parties to choose the "weakest" option available. This is analogous 883 to forcing 40-bit encryption on a link. The requirement highlights 884 that protocol support is needed to prevent such attacks, for example 885 by including the negotiation messages as part of a later MAC 886 calculation, if authentication has produced a shared secret. 888 <> 889 2.11.9 A peer MUST NOT send an attribute within an authorization 890 package or attribute that was not agreed to by a prior successful 891 negotiation. If this AAA protocol violation occurs, then it MUST 892 be possible to send an error indication to the misbehaving peer, 893 and generate an error indication to the network operator. 895 <> 896 2.11.10 A peer MUST declare all of the sets of the authorization 897 packages that it understands in its initial negotiation bid 898 message. 900 3. Security Considerations 902 This document includes specific security requirements. 904 This document does not state any detailed requirements for the 905 interplay with authentication, accounting or accountability (audit). 906 A AAA protocol, which meets all of the above requirements, may still 907 leave vulnerabilities due to such interactions. Such issues must be 908 considered as part of AAA protocol design. 910 4. References 912 [FRMW] Vollbrecht et al., "AAA Authorization Framework", 913 draft-ietf-aaa-authz-arch-00.txt, October 1999. 914 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 915 3", RFC 2026, BCP 9, October 1996. 916 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 917 Requirement Levels", BCP 14, March 1997. 918 [RFC2138] Rigney, C., et al., "Remote Authentication Dial In User 919 Service (RADIUS)", RFC2138, April 1997. 920 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 921 Languages", RFC2277, January 1998. 922 [SAMP] Vollbrecht et al., "AAA Authorization Application 923 Examples", draft-ietf-aaa-authz-samp-00.txt, October 924 1999. 926 Author's Addresses 928 Stephen Farrell John R. Vollbrecht 929 Baltimore Technologies Merit Network, Inc. 930 61/62 Fitzwilliam Lane 4251 Plymouth Rd., Suite 2000 931 Dublin 2, Ann Arbor, MI 48105 932 IRELAND USA 933 Phone: +353-1-647-7300 Phone: +1 734 763 1206 934 Fax: +353-1-647-7499 Fax: +1 734 647 3745 935 stephen.farrell@baltimore.ie EMail: jrv@merit.edu 937 Pat R. Calhoun Leon Gommans 938 Network and Security Research Cabletron Systems EMEA 939 Center, Sun Labs Kerkplein 24 940 Sun Microsystems, Inc. 2841 XM Moordrecht 941 15 Network Circle The Netherlands 942 Menlo Park, California, 94025 Phone: +31 182 379278 943 USA Email: gommans@cabletron.com 944 Phone: +1 650 786 7733 945 Fax: +1 650 786 6445 946 EMail: pcalhoun@eng.sun.com 948 George M. Gross Betty de Bruijn 949 Lucent Technologies Interpay Nederland B.V. 950 184 Liberty Corner Road, m.s. Eendrachtlaan 315 951 LC2N-D13 3526 LB Utrecht 952 Warren, NJ 07059 The Netherlands 953 USA Phone: +31 30 2835104 954 Phone: +1 908 580 4589 Email: betty@euronet.nl 955 Fax: +1 908 580 7430 956 Email: gmgross@lucent.com 958 Cees T.A.M. de Laat Matt Holdrege 959 Physics and Astronomy dept. Lucent Technologies 960 Utrecht University 1701 Harbor Bay Pkwy. 961 Pincetonplein 5, Alameda, CA 94502 962 3584CC Utrecht USA 963 Netherlands Phone: +1 510 747 2711 964 Phone: +31 30 2534585 Email: holdrege@lucent.com 965 Phone: +31 30 2537555 966 EMail: delaat@phys.uu.nl 968 David W. Spence 969 Merit Network, Inc. 970 4251 Plymouth Rd., Suite 2000 971 Ann Arbor, MI 48105 972 USA 973 Phone: +1 734 615 2630 974 Fax: +1 734 647 3745 975 EMail: dwspence@merit.edu 977 Full Copyright Statement 979 Copyright (C) The Internet Society (date). All Rights Reserved. 981 This document and translations of it may be copied and furnished to 982 others, and derivative works that comment on or otherwise explain it 983 or assist in its implementation may be prepared, copied, published 984 and distributed, in whole or in part, without restriction of any 985 kind, provided that the above copyright notice and this paragraph 986 are included on all such copies and derivative works. In addition, 987 the ASN.1 module presented in Appendix B may be used in whole or in 988 part without inclusion of the copyright notice. However, this 989 document itself may not be modified in any way, such as by removing 990 the copyright notice or references to the Internet Society or other 991 Internet organizations, except as needed for the purpose of 992 developing Internet standards in which case the procedures for 993 copyrights defined in the Internet Standards process shall be 994 followed, or as required to translate it into languages other than 995 English. 997 The limited permissions granted above are perpetual and will not be 998 revoked by the Internet Society or its successors or assigns. This 999 document and the information contained herein is provided on an "AS 1000 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1001 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1002 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1003 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1004 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.