idnits 2.17.1 draft-dwc-abfab-trust-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 5) being 334 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 79 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** There are 40 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (16 June 2013) is 3967 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 286 looks like a reference -- Missing reference section? 'BCP 78' on line 278 looks like a reference -- Missing reference section? 'RFC 2119' on line 281 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D.W.Chadwick 2 Internet-Draft University of Kent 3 Intended status: Informational 16 June 2013 4 Expires: 16 December 2013 6 A Trust Model for ABFAB Trust Routers 7 9 Abstract 11 Trust routers form an integral part of the ABFAB infrastructure for 12 determining routes between IdPs and RPs and determining CoI membership. 13 Since it is inherent in their name that they are to be trusted, this 14 Internet Draft specifies a trust model for their operation, so that IdPs 15 and RPs can rely on them to perform the tasks that they are trusted to 16 perform. These tasks are: 18 - form a trusted route between an IdP and RP 19 - ensure that a community of interest (CoI)only has the members that it 20 should have 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 This document is not intended to be an Internet Standards Track 28 specification; it is published for informational purposes. 30 Internet-Drafts are working documents of the Internet Engineering Task 31 Force (IETF). Note that other groups may also distribute working documents 32 as Internet-Drafts. The list of current Internet-Drafts is at 33 http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months and 36 may be updated, replaced, or obsoleted by other documents at any time. It 37 is inappropriate to use Internet-Drafts as reference material or to cite 38 them other than as "work in progress". 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. 52 Table of Contents 54 1. Introduction 2 55 2. Basic Assumptions and Definitions 2 56 3. The Trust Model 3 57 3.1 TR Roles 3 58 3.2 Inputting CoI information 4 59 3.3 Handshake Protocol 4 60 3.4 CoI Distribution Protocol 4 61 3.5 An Example 4 62 4. References 5 63 4.1 Normative References 5 64 4.2 Informative References 5 66 1. Introduction 68 If trust routers (TRs) are to be trusted by their trustors, then it must be 69 clear to the trustors on what basis this trust is established. A trust 70 model provides such a basis for showing who trusts whom for what purpose. A 71 trust model has been defined as "the defined trust relationships and 72 orientation of the communities participating with (an) organization.." [1]. 74 The trust model described in this document is concerned with trust in trust 75 routers for two purposes: 77 i) to provide a trusted path between an RP and an IdP/AA, and 78 ii) to ensure that a community of interest (CoI)only has the members 79 that it should have. 81 2. Basic Assumptions and Definitions 83 The authorisation model and assumptions that underlie this document are as 84 follows: 86 i) The Service Provider, being the Relying Party, is the trustor, and 87 therefore must be in control of, and decide, who it trusts. 89 ii) The RP uses an attribute based access control model, in which users 90 are granted access to its resources bases on their identity attributes 92 iii) Attributes may be globally defined, e.g. visa attributes, or locally 93 defined e.g. member of club X. Globally defined attributes are often 94 specified in international standards and may be used in several different 95 CoIs and federations. Their syntax and semantics are fixed, regardless of 96 which Attribute Authority (AA) issues them. Local attributes are defined by 97 their issuing AA and usually are only valid in the CoI or federation in 98 which the AA is a member. For locally defined attributes the attribute 99 authority (issuer) must be globally identifiable (in the CoI or 100 federation). The attribute then becomes globally identifiable through 101 hierarchical naming (AA.attribute). It is therefore assumed that all 102 attributes can be globally recognised. 104 iv) The RP's software comprises a Policy Enforcement Point (PEP), 105 Credential Validation Service (CVS), and Policy Decision Point (PDP). The 106 PEP is the application specific code which traps users' requests and 107 enforces access control decisions. The CVS is the component which takes as 108 input the user's credentials, claims, attribute assertions (synonymous 109 terms for the purpose of this document) and returns to the PEP a list of 110 validated user identity attributes. The PDP takes the list of user 111 attributes and returns an access control decision. 113 v) The RP trusts its CVS to correctly validate the user's identity 114 attributes based on its policy and to discard untrustworthy ones. 116 vi) The RP trusts its PDP to correctly make access control decisions 117 based on its policy and the user's valid identity attributes. 119 vii) The CVS may have a local trust policy specifying which AAs are 120 trusted to issue which attributes, along with the metadata necessary to 121 validate digitally signed assertions from these AAs. In this case trust 122 routers are not needed. If a router falsely directs the CVS to a fake AA, 123 then the CVS can tell this (by signature validation) and will discard all 124 the attributes it issues. 126 viii) The CVS may have a local trust policy specifying which attributes to 127 accept from a federation or CoI, but may rely on the federation or CoI to 128 control its membership and ensure that all AAs are trusted to issue these 129 attributes. In this case the CVS trusts the TRs to connect it to trusted 130 AAs, and not to connect it to untrusted AAs. Note that the CVS is not able 131 to validate (digitally signed) assertions from these AAs since it does not 132 have any meta data associated with them. So the CVS has to rely on the TRs 133 to set up a trusted channel to an AA, via Diffie Hellman key exchange, then 134 it does not need digitally signed assertions. The CVS should be able to 135 trust everything that comes down the trusted path. 137 The TR trust model described in this document is based on the following 138 assumptions: 140 A. Each TR admin is absolutely in charge of his local TR and can 141 configure it how he wants to (though it may not work properly if he 142 does not follow some set procedures). He does not need to trust 143 anyone else, i.e. he is his own root of trust. He can determine which 144 remote entities to trust, and how much to trust them. 146 B. Trust relationships between TRs can only be mutual and not one way. 147 It makes little sense for one TR to trust messages from another TR 148 but the other TR to not trust any message at all from the former. 149 This is similar to the fact that a mutual trust relationship exists 150 between an SP and an IdP in a federation. 152 C. Trust relationships can be symmetrical or asymmetrical. Symmetrical 153 trust relationships are when each party trusts the other to perform 154 the same set of actions. Asymmetrical trust relationships are when 155 each party trusts the other to perform different sets of actions. An 156 example of an asymmetrical trust relationship is that between an IdP 157 and an SP in a SAML federation. An example of a symmetrical trust 158 relationship is that between two peers in a group. 160 D. All TRs are members of the same federation, and this is agreed at 161 initial configuration time. 163 E. CoI membership information is dynamically propagated between TR 164 federation members. 166 3. The Trust Model 168 3.1 TR Roles 170 A TR may perform one or more of the following roles: 172 Master - a master TR is responsible for keeping the CoI information up to 173 date in its associated slave TRs. A Master CoI gets all its CoI information 174 from its administrator. 176 Slave - a slave TR gets all its CoI information from its master TR. A slave 177 TR administrator has no further work to do after initially configuring 178 his/her slave TR. 180 Peer - a peer TR gets its CoI information from both its administrator and 181 from its other peer TRs. When it receives any CoI information it propagates 182 this to all its associated peer TRs, unless it already has this information 183 stored in its local database, in which case it does no further propagation. 185 3.2 Inputting CoI information 187 All CoI information originates from TR administrators. The trust model 188 allows for one or many CoI members to input this information to their 189 managed TRs. It is then propagated to all other TRs in the federation. 191 3.3 Handshake Protocol 193 When a TR is initially configured, it is provided with: the name of its 194 federation, its role, its metadata, and the associated TR(s) along with its 195 (their) metadata. It then establishes an active trust association with its 196 associated TR(s), passing each one: the name of the federation, its role, 197 its metadata, the role of the associated TR and its metadata. The receiving 198 TR checks that the received information matches the information that has 199 been configured into it by its administrator, and if all matches, it 200 acknowledges that the trust association has been established. From then 201 onwards each TR will trust any CoI information received from its associated 202 TR, providing it agrees with the relationship type (master/slave or peer to 203 peer). 205 3.4 CoI Distribution Protocol 207 Once an active trust association between two TRs has been established, the 208 CoI CRUD protocol can take place. This allows a TR to create, read, update 209 and delete the CoI information in its associated TRs. 210 3.5 An Example 211 O O 212 _|_ __ _|_ ___ 213 ^ | ^ | 214 / \ | / \ |5.CoI B 215 |1.CoI A | 216 | | 217 v V 218 ------------ ----------- ----------- 219 | Master | 2. CoI A | Master/ | 2. CoI A | Peer TR | 220 | Peer TR | <--------------> | Peer TR | <-------------------->| (c) | 221 | (a) | 7. CoI B | (b) | 6. CoI B | | 222 ------------ ----------- ----------- 223 ^ ^ ^ ^ 224 | \ | | 225 |3.CoI A \ 3. CoI A |2 |3. CoI A 226 |8.CoI B \ 8. CoI B |7.CoI B |6. CoI B 227 v \ v v 228 ------------ \ ----------- ----------- 229 | | \ | | | Peer TR | 230 | Slave TR | \ | Slave TR | | (f) | 231 | (d) | \ | (e) | | | 232 ------------ \ ----------- ----------- 233 \ ^ 234 \ | 235 \ | 236 \ |4. CoI A 237 \ |7. CoI B 238 \ | 239 V V 240 ------------ ----------- ----------- 241 | | 4.CoI A | | 4.CoI A X| Peer TR | 242 | Peer TR |<---------->| Peer TR |<-------------------------->| (i) | 243 | (g) | 9.CoI B | (h) |X 8.CoI B | | 244 ------------ ----------- ----------- 246 Figure 1. An example TR federation 248 We assume that a set of TRs in a federation have been configured with the 249 following trust associations, as shown in figure 1: 250 i) TR(a) is the peer of TR(b) and the master of TR (d) 251 ii) TR(b) is the master of TR(e) and the peer of TR (c) 252 iii) TR(c) is the peer of TRs(b) and (f) 253 iv) TR(d) is the slave of TR(a) 254 v) TR(e) is the slave of TR(b) 255 vi) TR(f) is the peer of TRs(c) and (i) 256 vii) TR(g) is the peer of TR(h) 257 viii) TR(h) is the peer of TRs(g) and (i) 258 ix) TR(i) is the peer of TRs(f) and (h) 260 The administrator of TR(b) configures it with information about CoI A (step 261 1). TR(b) now propagates this information to all its peers and slaves (step 262 2). Any peers who receive this information now propagate it to their peers 263 and slaves (step 3). This continues recursively until all TRs in the 264 federation have received this information. Any peer who receives this 265 information more than once from different peers discards the subsequent 266 messages (step 4) (shown with an X in the diagram). The administrator of 267 TR(c) configures it with information about CoI B (step 5). TR(c) now 268 propagates this to all its peers (step 6). All peers who receive this 269 information now propagate it to all their peers and slaves (step 7). This 270 continues recursively until all TRs in the federation have received this 271 information (steps 8 and 9), with peers discarding subsequent occurrences 272 of the same message (shown with an X in the diagram). 274 4. References 276 4.1 Normative References 278 [BCP 78] S. Bradner, Ed. Et al. "Rights Contributors Provide to the IETF 279 Trust" November 2008. 281 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 282 Requirement Levels", March 1997. 284 4.2 Informative References 286 [1] http://www.ocio.gov.nl.ca/ocio/im/glossary.html#Trust_Model 288 5. Author's Address 290 David W Chadwick 291 School of Computing 292 University of Kent 293 Canterbury 294 CT2 7NF 295 England 297 d.w.chadwick@kent.ac.uk