idnits 2.17.00 (12 Aug 2021) /tmp/idnits1870/draft-mrw-abfab-trust-router-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 24, 2011) is 3861 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) == Missing Reference: 'RFC4627' is mentioned on line 240, but not defined ** Obsolete undefined reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Missing Reference: 'TBD' is mentioned on line 401, but not defined -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Wasserman 3 Internet-Draft Painless Security 4 Intended status: Standards Track October 24, 2011 5 Expires: April 26, 2012 7 Application Bridging for Federation Beyond the Web (ABFAB) Trust Router 8 Protocol 9 draft-mrw-abfab-trust-router-00.txt 11 Abstract 13 A Trust Router is an infrastucture element used to construct multihop 14 Application Bridging for Federated Authentication Beyond the Web 15 (ABFAB) federations, as discussed in 16 draft-mrw-abfab-multihop-fed-01.txt. This document defines both the 17 Trust Router Protocol and the Trust Path Query, as discussed in the 18 multihop federation document. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 26, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 56 3. Trust Router Protocol . . . . . . . . . . . . . . . . . . . . 4 57 4. Trust Router Messages . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Hello Message . . . . . . . . . . . . . . . . . . . . . . 5 59 4.2. Trust Link Database Message . . . . . . . . . . . . . . . 5 60 4.3. Trust Link Update Message . . . . . . . . . . . . . . . . 5 61 5. Trust Router Operation . . . . . . . . . . . . . . . . . . . . 5 62 5.1. Hello Message Exchange . . . . . . . . . . . . . . . . . . 5 63 5.2. Exchanging Initial Trust Link Databases . . . . . . . . . 5 64 5.3. Trust Link Updates . . . . . . . . . . . . . . . . . . . . 5 65 5.4. Serial Numbers . . . . . . . . . . . . . . . . . . . . . . 5 66 5.5. TCP Connection Handling . . . . . . . . . . . . . . . . . 6 67 5.6. Conceptual Data Structures . . . . . . . . . . . . . . . . 6 68 5.6.1. Peer Table . . . . . . . . . . . . . . . . . . . . . . 6 69 5.6.2. Trust Link Database . . . . . . . . . . . . . . . . . 6 70 6. Trust Path Query . . . . . . . . . . . . . . . . . . . . . . . 6 71 6.1. Trust Path Query Messages . . . . . . . . . . . . . . . . 6 72 6.1.1. Trust Path Query Request . . . . . . . . . . . . . . . 6 73 6.1.2. Trust Path Query Response . . . . . . . . . . . . . . 6 74 6.2. Trust Path Query Operation . . . . . . . . . . . . . . . . 6 75 7. Message Representation . . . . . . . . . . . . . . . . . . . . 7 76 7.1. Message Encoding . . . . . . . . . . . . . . . . . . . . . 7 77 7.2. Hello Message Representation . . . . . . . . . . . . . . . 7 78 7.3. Trust Link Database/Update Representation . . . . . . . . 7 79 7.3.1. Trust Link Ordering . . . . . . . . . . . . . . . . . 8 80 7.3.2. Entity Identity . . . . . . . . . . . . . . . . . . . 8 81 7.3.3. Trust Link Entry . . . . . . . . . . . . . . . . . . . 8 82 7.3.4. Trust Link Database Message . . . . . . . . . . . . . 9 83 7.3.5. Trust Link Update Message . . . . . . . . . . . . . . 9 84 7.4. Trust Path Query Representation . . . . . . . . . . . . . 9 85 7.4.1. Trust Link Query Request . . . . . . . . . . . . . . . 9 86 7.4.2. Trust Link Query Response . . . . . . . . . . . . . . 9 87 7.5. Message Examples . . . . . . . . . . . . . . . . . . . . . 10 88 7.5.1. Hello Message Example . . . . . . . . . . . . . . . . 10 89 7.5.2. Trust Link Database Example . . . . . . . . . . . . . 10 90 7.5.3. Trust Link Update Example . . . . . . . . . . . . . . 10 91 7.5.4. Trust Path Query Request Example . . . . . . . . . . . 10 92 7.5.5. Trust Path Query Response Example . . . . . . . . . . 10 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 97 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 98 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 101 1. Introduction 103 A Trust Router is an infrastucture element used to construct multihop 104 Application Bridging for Federated Authentication Beyond the Web 105 (ABFAB) federations, as discussed in 106 draft-mrw-abfab-multihop-fed-01.txt. This document defines both the 107 Trust Router Protocol and the Trust Path Query, as discussed in the 108 multihop federation document. 110 This document defines the protocol used between Trust Routers to 111 exchange information about Trust Paths available within an ABFAB 112 federation. It also defines the messages that a federated service 113 will use to obtain Trust Path information from its local Trust 114 Router, so that it can use the ABFAB Key Negotiation Protocol (KNP) 115 to forge a Chain of Trust across a federation. The Chain of Trust 116 will lead to an Authentication, Authorization and Accounting (AAA) 117 Server for a user's Identity Provider, which will then be used to 118 authenticate and authorize the user. 120 2. Requirements Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 3. Trust Router Protocol 128 The Trust Router protocol is a TCP-based protocol that is used to 129 exchange information between Trust Routers about available Trust 130 Links within an ABFAB Federation. 132 As discussed in the multihop federation document, When a Trust Router 133 advertises a Trust Link, such as A(T) -> B(T), it is making an 134 assertion that Trust Router A is able, and willing, to provide 135 temporary identities (via KNP) that can be used to reach Trust Router 136 B. 138 Trust Routers use the information they receive about available Trust 139 Links to construct Trust Paths that can be used to reach AAA Servers 140 (i.e. RADIUS or DIAMETER servers) for a set of Identity Providers 141 (IDPs) within a ABFAB federation. They then return the shortest path 142 to a specific IDP in response to Trust Path Queries. 144 4. Trust Router Messages 146 4.1. Hello Message 148 Hello Messages are the first messages exchanged by Trust Routers when 149 they bring up a new TCP connection, and they may be exchanged at 150 other times to ensure that database information is synchronized, or 151 to trigger a full Trust Link Database download. The first Hello 152 messages exchanged over a new TCP connection are also used as the 153 vehicle to establish an authenticated and encrypted GSS-API session. 155 TBD: We need to discuss how GSS-API will be used with this protocol. 156 Maybe we need separate authentication messages before the Hello 157 messages are exchanged? 159 4.2. Trust Link Database Message 161 A Trust Link Database Message contains a full (potentially filtered) 162 set of Trust Links that can be reached through the sending Trust 163 Router. This message may be quite large, and is only sent when 164 solicited by the receiver. 166 4.3. Trust Link Update Message 168 Trust Routers send Trust Link Update messages to other Trust Routers 169 to whom they are connected whenever their Trust Link Database is 170 updated. Trust Link Update messages contain the portions of the 171 Trust Link Database that have changed since the last update. They 172 also contain a serial number that can be used by the receiving Trust 173 Router to determine if any updates have been missed, in which case a 174 full Trust Router Database download is needed. 176 5. Trust Router Operation 178 This section describes how Trust Routers work, in general. Detailed 179 message formats are described in later sections of the document. 181 5.1. Hello Message Exchange 183 5.2. Exchanging Initial Trust Link Databases 185 5.3. Trust Link Updates 187 5.4. Serial Numbers 188 5.5. TCP Connection Handling 190 Trust Routers communicate by exchanging full JSON-encoded messages 191 over a TCP connection. If incomplete messages are received, or if 192 the TCP connection is interrupted before a complete message is 193 received, the incomplete messages will be discarded, and no protocol 194 actions will be taken based on the contents of the incomplete 195 message. 197 In the Trust Router Protocol, no information about the availability 198 of Trust Links is inferred from a TCP reset, or a retransmission 199 timeout on the TCP connection to another Trust Router. A Trust 200 Router is only considered unreachable after an attempt to reestablish 201 a TCP connection to that Trust Router is reset or times out. 203 When a Trust Router is found to be unreachable, the Trust Links 204 supplied by that Trust Router are not removed from the local Trust 205 Link Database. They will however, be marked as deprecated until a 206 connection can be reestablished with the Trust Router that sent them, 207 and it can be verified that the sequence number of that Trust 208 Router's Database still matches the sequence number of the most 209 recent Trust Link information received. 211 When Trust Links are marked as deprecated, they will not be used if 212 another, non-deprecated path exists to reach the target Identity 213 Provider. If there are no paths to the target Identity Provider that 214 traverse only non-deprecated Trust Links, a path containing a 215 deprecated Trust Link will be used. 217 5.6. Conceptual Data Structures 219 5.6.1. Peer Table 221 5.6.2. Trust Link Database 223 6. Trust Path Query 225 6.1. Trust Path Query Messages 227 6.1.1. Trust Path Query Request 229 6.1.2. Trust Path Query Response 231 6.2. Trust Path Query Operation 232 7. Message Representation 234 This section provides details about the contents and encoding of both 235 Trust Router Protocol messages and Trust Path Query messages. 237 7.1. Message Encoding 239 The Trust Router Protocol and Trust Path Query messages are encoded 240 in JavaScript Object Notation (JSON) [RFC4627]. 242 7.2. Hello Message Representation 244 Name or Realm (??) Auth-Token (??) Database-Serial-Number Database- 245 Request 247 TBD: It is unclear what sort of authentication information needs to 248 be in this message for GSS-API authentication. 250 Database-Serial-Number field contains the current serial number of 251 the sending Trust Router's Trust Link Database. This information may 252 be used by a receiving Trust Router to determine whether it should 253 request a full Trust Link Database download. 255 The Database-Request field indicates whether the receiving Trust 256 Router should respond to this message with a Trust Link Database 257 message, to share its full Trust Link Database with the sending Trust 258 Router. If this field has a value of "true", a download is 259 requested. If it is "false", a download is not requested. 261 7.3. Trust Link Database/Update Representation 263 In the Trust Router Protocol, each Trust Router will send a 264 (potentially filtered) set of Trust Links to its neighboring Trust 265 Routers. The representation of these Trust Links is designed for 266 efficient encoding, and to allow easy population of a conceptual 267 Trust Link Table on the receiving Trust Router. Each Trust Router 268 will only distribute a set of Trust Links that form a connected tree 269 rooted at the sending Trust Router. 271 Conceptually, a Trust Link consists: 273 o A Trust Router that is willing to provide a temporary identity. 275 o The Trust Router or AAA Server which the identity can be provided 277 o The Communities-of-Interest to whom the link is available. 279 o A lifetime for this link, in seconds. 281 However, the actual Trust Links passed in the Trust Router protocol 282 rely on inference and ordering to eliminate the need to include the 283 first Trust Router identity in each distributed link. Instead, we 284 use an Index variable, which indicates each Trust Link's level in a 285 conceptual tree, and we order the Trust Links, so that a Trust Link 286 with an Index of N is subordinate to the closest previous Trust Link 287 with an index of N-1 that applies to the same Community-of-Interest. 288 Each conceptual tree is rooted at the sending Trust Router, which is 289 represented by an an entry with an Index value of 0. 291 7.3.1. Trust Link Ordering 293 7.3.2. Entity Identity 295 When we send Trust Router or AAA Server identities in the Trust 296 Router Protocol, that information will be sent in an Entity Identity 297 structure containing the following fields: 299 o Name 301 o Type 303 o Realm 305 The Name field will typically contain a fully-qualified domain name 306 (FQDN) that can be used to reach the indicated entity (e.g. "tr- 307 A.example.net"). 309 The Type field indicates that the entity is a Trust Router (Type = 310 "T") or a AAA Server (Type = "R"). 312 The Realm field contains the security realm associated with the 313 entity (e.g. "example.net"). 315 7.3.3. Trust Link Entry 317 As transmitted in the Trust Router Protocol, a Trust Link entry will 318 have the following fields: 320 o Index 322 o Target-Entity 324 o Communities-of-Interest 325 o Lifetime 327 The Index field contains a non-zero integer value, indicating the 328 depth of this Trust Link in a conceptual tree of links rooted at the 329 sending Trust Router. The maximum value of this field is 255. 331 The Target-Entity field contains a the Trust Router or AAA Server for 332 which temporary identities can be generated. This also represents 333 the Trust Router that can generate identities for any directly 334 subordinate nodes in the conceptual tree. 336 The Communities-of-Interest field contains an array of strings, each 337 containing a Community-of-Interest for which this link is available. 339 The Lifetime field contains an integer that indicates the lifetime of 340 this Trust Link in seconds. Links are removed from the the 341 conceptual Trust Link Table if their lifetime expires. 343 7.3.4. Trust Link Database Message 345 A Trust Link Databases will consist two fields: 347 o Serial-Number 349 o Trust-Links 351 The Serial-Number field contains an integer indicating the version of 352 the information contained in this database. The maximum value for 353 this field is (2^32 - 1). 355 The Trust-Links field contains an array of Trust Link Entries. 357 7.3.5. Trust Link Update Message 359 7.4. Trust Path Query Representation 361 7.4.1. Trust Link Query Request 363 TBD: Pending resolution of open architectural questions regarding 364 what will be queried/returned in these messages. 366 7.4.2. Trust Link Query Response 368 TBD: Pending resolution of open architectural questions regarding 369 what will be queried/returned in these messages. 371 7.5. Message Examples 373 This section contains example of Trust Router Protocol and Trust 374 Query messages encoded in JSON, as they will be sent over the nework. 376 7.5.1. Hello Message Example 378 7.5.2. Trust Link Database Example 380 7.5.3. Trust Link Update Example 382 7.5.4. Trust Path Query Request Example 384 TBD: Pending resolution of open architectural questions regarding 385 what will be queried/returned in these messages. 387 7.5.5. Trust Path Query Response Example 389 TBD: Pending resolution of open architectural questions regarding 390 what will be queried/returned in these messages. 392 8. Security Considerations 394 [TBD] 396 9. IANA Considerations 398 IANA has allocated the following TCP port numbers for use by 399 protocols described in this document: 401 [TBD] 403 10. Acknowledgements 405 This document was written using the xml2rfc tool described in RFC 406 2629 [RFC2629]. 408 The following people provided useful comments or feedback on this 409 document: Sam Hartman, Josh Howlett. 411 11. References 412 11.1. Normative References 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, March 1997. 417 11.2. Informative References 419 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 420 June 1999. 422 Author's Address 424 Margaret Wasserman 425 Painless Security 426 356 Abbott Street 427 North Andover, MA 01845 428 USA 430 Phone: +1 781 405 7464 431 Email: mrw@painless-security.com 432 URI: http://www.painless-security.com