idnits 2.17.1 draft-mrw-abfab-trust-router-01.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 2011) is 4577 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 244, but not defined ** Obsolete undefined reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Missing Reference: 'TBD' is mentioned on line 406, 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 S. Hartman 4 Intended status: Standards Track Painless Security 5 Expires: April 3, 2012 J. Howlett 6 JANET(UK) 7 October 2011 9 Application Bridging for Federation Beyond the Web (ABFAB) Trust Router 10 Protocol 11 draft-mrw-abfab-trust-router-01.txt 13 Abstract 15 A Trust Router is an infrastucture element used to construct multihop 16 Application Bridging for Federated Authentication Beyond the Web 17 (ABFAB) federations, as discussed in 18 draft-mrw-abfab-multihop-fed-01.txt. This document defines both the 19 Trust Router Protocol and the Trust Path Query, as discussed in the 20 multihop federation document. 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 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 3, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 58 3. Trust Router Protocol . . . . . . . . . . . . . . . . . . . . 4 59 4. Trust Router Messages . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Hello Message . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. Trust Link Database Message . . . . . . . . . . . . . . . 5 62 4.3. Trust Link Update Message . . . . . . . . . . . . . . . . 5 63 5. Trust Router Operation . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Hello Message Exchange . . . . . . . . . . . . . . . . . . 5 65 5.2. Exchanging Initial Trust Link Databases . . . . . . . . . 5 66 5.3. Trust Link Updates . . . . . . . . . . . . . . . . . . . . 5 67 5.4. Serial Numbers . . . . . . . . . . . . . . . . . . . . . . 5 68 5.5. TCP Connection Handling . . . . . . . . . . . . . . . . . 6 69 5.6. Conceptual Data Structures . . . . . . . . . . . . . . . . 6 70 5.6.1. Peer Table . . . . . . . . . . . . . . . . . . . . . . 6 71 5.6.2. Trust Link Database . . . . . . . . . . . . . . . . . 6 72 6. Trust Path Query . . . . . . . . . . . . . . . . . . . . . . . 6 73 6.1. Trust Path Query Messages . . . . . . . . . . . . . . . . 6 74 6.1.1. Trust Path Query Request . . . . . . . . . . . . . . . 6 75 6.1.2. Trust Path Query Response . . . . . . . . . . . . . . 6 76 6.2. Trust Path Query Operation . . . . . . . . . . . . . . . . 6 77 7. Message Representation . . . . . . . . . . . . . . . . . . . . 7 78 7.1. Message Encoding . . . . . . . . . . . . . . . . . . . . . 7 79 7.2. Hello Message Representation . . . . . . . . . . . . . . . 7 80 7.3. Trust Link Database/Update Representation . . . . . . . . 7 81 7.3.1. Trust Link Ordering . . . . . . . . . . . . . . . . . 8 82 7.3.2. Entity Identity . . . . . . . . . . . . . . . . . . . 8 83 7.3.3. Trust Link Entry . . . . . . . . . . . . . . . . . . . 8 84 7.3.4. Trust Link Database Message . . . . . . . . . . . . . 9 85 7.3.5. Trust Link Update Message . . . . . . . . . . . . . . 9 86 7.4. Trust Path Query Representation . . . . . . . . . . . . . 9 87 7.4.1. Trust Link Query Request . . . . . . . . . . . . . . . 9 88 7.4.2. Trust Link Query Response . . . . . . . . . . . . . . 9 89 7.5. Message Examples . . . . . . . . . . . . . . . . . . . . . 10 90 7.5.1. Hello Message Example . . . . . . . . . . . . . . . . 10 91 7.5.2. Trust Link Database Example . . . . . . . . . . . . . 10 92 7.5.3. Trust Link Update Example . . . . . . . . . . . . . . 10 93 7.5.4. Trust Path Query Request Example . . . . . . . . . . . 10 94 7.5.5. Trust Path Query Response Example . . . . . . . . . . 10 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 98 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 99 11.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 11 100 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 101 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 102 12.2. Informative References . . . . . . . . . . . . . . . . . . 11 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 105 1. Introduction 107 A Trust Router is an infrastucture element used to construct multihop 108 Application Bridging for Federated Authentication Beyond the Web 109 (ABFAB) federations, as discussed in 110 draft-mrw-abfab-multihop-fed-01.txt. This document defines both the 111 Trust Router Protocol and the Trust Path Query, as discussed in the 112 multihop federation document. 114 This document defines the protocol used between Trust Routers to 115 exchange information about Trust Paths available within an ABFAB 116 federation. It also defines the messages that a federated service 117 will use to obtain Trust Path information from its local Trust 118 Router, so that it can use the ABFAB Key Negotiation Protocol (KNP) 119 to forge a Chain of Trust across a federation. The Chain of Trust 120 will lead to an Authentication, Authorization and Accounting (AAA) 121 Server for a user's Identity Provider, which will then be used to 122 authenticate and authorize the user. 124 2. Requirements Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 3. Trust Router Protocol 132 The Trust Router protocol is a TCP-based protocol that is used to 133 exchange information between Trust Routers about available Trust 134 Links within an ABFAB Federation. 136 As discussed in the multihop federation document, When a Trust Router 137 advertises a Trust Link, such as A(T) -> B(T), it is making an 138 assertion that Trust Router A is able, and willing, to provide 139 temporary identities (via KNP) that can be used to reach Trust Router 140 B. 142 Trust Routers use the information they receive about available Trust 143 Links to construct Trust Paths that can be used to reach AAA Servers 144 (i.e. RADIUS or DIAMETER servers) for a set of Identity Providers 145 (IDPs) within a ABFAB federation. They then return the shortest path 146 to a specific IDP in response to Trust Path Queries. 148 4. Trust Router Messages 150 4.1. Hello Message 152 Hello Messages are the first messages exchanged by Trust Routers when 153 they bring up a new TCP connection, and they may be exchanged at 154 other times to ensure that database information is synchronized, or 155 to trigger a full Trust Link Database download. The first Hello 156 messages exchanged over a new TCP connection are also used as the 157 vehicle to establish an authenticated and encrypted GSS-API session. 159 TBD: We need to discuss how GSS-API will be used with this protocol. 160 Maybe we need separate authentication messages before the Hello 161 messages are exchanged? 163 4.2. Trust Link Database Message 165 A Trust Link Database Message contains a full (potentially filtered) 166 set of Trust Links that can be reached through the sending Trust 167 Router. This message may be quite large, and is only sent when 168 solicited by the receiver. 170 4.3. Trust Link Update Message 172 Trust Routers send Trust Link Update messages to other Trust Routers 173 to whom they are connected whenever their Trust Link Database is 174 updated. Trust Link Update messages contain the portions of the 175 Trust Link Database that have changed since the last update. They 176 also contain a serial number that can be used by the receiving Trust 177 Router to determine if any updates have been missed, in which case a 178 full Trust Router Database download is needed. 180 5. Trust Router Operation 182 This section describes how Trust Routers work, in general. Detailed 183 message formats are described in later sections of the document. 185 5.1. Hello Message Exchange 187 5.2. Exchanging Initial Trust Link Databases 189 5.3. Trust Link Updates 191 5.4. Serial Numbers 192 5.5. TCP Connection Handling 194 Trust Routers communicate by exchanging full JSON-encoded messages 195 over a TCP connection. If incomplete messages are received, or if 196 the TCP connection is interrupted before a complete message is 197 received, the incomplete messages will be discarded, and no protocol 198 actions will be taken based on the contents of the incomplete 199 message. 201 In the Trust Router Protocol, no information about the availability 202 of Trust Links is inferred from a TCP reset, or a retransmission 203 timeout on the TCP connection to another Trust Router. A Trust 204 Router is only considered unreachable after an attempt to reestablish 205 a TCP connection to that Trust Router is reset or times out. 207 When a Trust Router is found to be unreachable, the Trust Links 208 supplied by that Trust Router are not removed from the local Trust 209 Link Database. They will however, be marked as deprecated until a 210 connection can be reestablished with the Trust Router that sent them, 211 and it can be verified that the sequence number of that Trust 212 Router's Database still matches the sequence number of the most 213 recent Trust Link information received. 215 When Trust Links are marked as deprecated, they will not be used if 216 another, non-deprecated path exists to reach the target Identity 217 Provider. If there are no paths to the target Identity Provider that 218 traverse only non-deprecated Trust Links, a path containing a 219 deprecated Trust Link will be used. 221 5.6. Conceptual Data Structures 223 5.6.1. Peer Table 225 5.6.2. Trust Link Database 227 6. Trust Path Query 229 6.1. Trust Path Query Messages 231 6.1.1. Trust Path Query Request 233 6.1.2. Trust Path Query Response 235 6.2. Trust Path Query Operation 236 7. Message Representation 238 This section provides details about the contents and encoding of both 239 Trust Router Protocol messages and Trust Path Query messages. 241 7.1. Message Encoding 243 The Trust Router Protocol and Trust Path Query messages are encoded 244 in JavaScript Object Notation (JSON) [RFC4627]. 246 7.2. Hello Message Representation 248 Name or Realm (??) Auth-Token (??) Database-Serial-Number Database- 249 Request 251 TBD: It is unclear what sort of authentication information needs to 252 be in this message for GSS-API authentication. 254 Database-Serial-Number field contains the current serial number of 255 the sending Trust Router's Trust Link Database. This information may 256 be used by a receiving Trust Router to determine whether it should 257 request a full Trust Link Database download. 259 The Database-Request field indicates whether the receiving Trust 260 Router should respond to this message with a Trust Link Database 261 message, to share its full Trust Link Database with the sending Trust 262 Router. If this field has a value of "true", a download is 263 requested. If it is "false", a download is not requested. 265 7.3. Trust Link Database/Update Representation 267 In the Trust Router Protocol, each Trust Router will send a 268 (potentially filtered) set of Trust Links to its neighboring Trust 269 Routers. The representation of these Trust Links is designed for 270 efficient encoding, and to allow easy population of a conceptual 271 Trust Link Table on the receiving Trust Router. Each Trust Router 272 will only distribute a set of Trust Links that form a connected tree 273 rooted at the sending Trust Router. 275 Conceptually, a Trust Link consists: 277 o A Trust Router that is willing to provide a temporary identity. 279 o The Trust Router or AAA Server which the identity can be provided 281 o The Communities-of-Interest to whom the link is available. 283 o A lifetime for this link, in seconds. 285 However, the actual Trust Links passed in the Trust Router protocol 286 rely on inference and ordering to eliminate the need to include the 287 first Trust Router identity in each distributed link. Instead, we 288 use an Index variable, which indicates each Trust Link's level in a 289 conceptual tree, and we order the Trust Links, so that a Trust Link 290 with an Index of N is subordinate to the closest previous Trust Link 291 with an index of N-1 that applies to the same Community-of-Interest. 292 Each conceptual tree is rooted at the sending Trust Router, which is 293 represented by an an entry with an Index value of 0. 295 7.3.1. Trust Link Ordering 297 7.3.2. Entity Identity 299 When we send Trust Router or AAA Server identities in the Trust 300 Router Protocol, that information will be sent in an Entity Identity 301 structure containing the following fields: 303 o Name 305 o Type 307 o Realm 309 The Name field will typically contain a fully-qualified domain name 310 (FQDN) that can be used to reach the indicated entity (e.g. "tr- 311 A.example.net"). 313 The Type field indicates that the entity is a Trust Router (Type = 314 "T") or a AAA Server (Type = "R", "D", or "S" for a RADIUS Server, 315 DIAMETER Server or RADSEC Server, respectively). 317 The Realm field contains the security realm associated with the 318 entity (e.g. "example.net"). 320 7.3.3. Trust Link Entry 322 As transmitted in the Trust Router Protocol, a Trust Link entry will 323 have the following fields: 325 o Index 327 o Target-Entity 329 o Communities-of-Interest 330 o Lifetime 332 The Index field contains a non-zero integer value, indicating the 333 depth of this Trust Link in a conceptual tree of links rooted at the 334 sending Trust Router. The maximum value of this field is 255. 336 The Target-Entity field contains a the Trust Router or AAA Server for 337 which temporary identities can be generated. This also represents 338 the Trust Router that can generate identities for any directly 339 subordinate nodes in the conceptual tree. 341 The Communities-of-Interest field contains an array of strings, each 342 containing a Community-of-Interest for which this link is available. 344 The Lifetime field contains an integer that indicates the lifetime of 345 this Trust Link in seconds. Links are removed from the the 346 conceptual Trust Link Table if their lifetime expires. 348 7.3.4. Trust Link Database Message 350 A Trust Link Databases will consist two fields: 352 o Serial-Number 354 o Trust-Links 356 The Serial-Number field contains an integer indicating the version of 357 the information contained in this database. The maximum value for 358 this field is (2^32 - 1). 360 The Trust-Links field contains an array of Trust Link Entries. 362 7.3.5. Trust Link Update Message 364 7.4. Trust Path Query Representation 366 7.4.1. Trust Link Query Request 368 TBD: Pending resolution of open architectural questions regarding 369 what will be queried/returned in these messages. 371 7.4.2. Trust Link Query Response 373 TBD: Pending resolution of open architectural questions regarding 374 what will be queried/returned in these messages. 376 7.5. Message Examples 378 This section contains example of Trust Router Protocol and Trust 379 Query messages encoded in JSON, as they will be sent over the nework. 381 7.5.1. Hello Message Example 383 7.5.2. Trust Link Database Example 385 7.5.3. Trust Link Update Example 387 7.5.4. Trust Path Query Request Example 389 TBD: Pending resolution of open architectural questions regarding 390 what will be queried/returned in these messages. 392 7.5.5. Trust Path Query Response Example 394 TBD: Pending resolution of open architectural questions regarding 395 what will be queried/returned in these messages. 397 8. Security Considerations 399 [TBD] 401 9. IANA Considerations 403 IANA has allocated the following TCP port numbers for use by 404 protocols described in this document: 406 [TBD] 408 10. Acknowledgements 410 This document was written using the xml2rfc tool described in RFC 411 2629 [RFC2629]. 413 The following people provided useful comments or feedback on this 414 document: Daniel Kouril, Linus Nordberg, Rhys Smith, Kevin Wasserman. 416 11. Change Log 417 11.1. Changes between -00 and -01 419 o Minor revisions, added authors. 421 12. References 423 12.1. Normative References 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, March 1997. 428 12.2. Informative References 430 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 431 June 1999. 433 Authors' Addresses 435 Margaret Wasserman 436 Painless Security 437 356 Abbott Street 438 North Andover, MA 01845 439 USA 441 Phone: +1 781 405 7464 442 Email: mrw@painless-security.com 443 URI: http://www.painless-security.com 445 Sam Hartman 446 Painless Security 447 356 Abbott Street 448 North Andover, MA 01845 449 USA 451 Email: hartmans@painless-security.com 452 URI: http://www.painless-security.com 454 Josh Howlett 455 JANET(UK) 457 Email: 458 URI: josh.howlett@ja.net