idnits 2.17.00 (12 Aug 2021) /tmp/idnits16369/draft-lear-ietf-sasl-openid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Line 345 has weird spacing: '...ecified by OA...' -- The document date (January 19, 2010) is 4505 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'OpenID' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems GmbH 4 Intended status: Standards Track H. Tschofenig 5 Expires: July 23, 2010 Nokia Siemens Networks 6 H. Mauldin 7 Cisco Systems, Inc. 8 January 19, 2010 10 A SASL Mechanism for OpenID 11 draft-lear-ietf-sasl-openid-00.txt 13 Abstract 15 OpenID has found its usage on the Internet for Web Single Sign-On. 16 Simple Authentication and Security Layer (SASL) is an application 17 framework to generalize authentication. This memo specifies a SASL 18 mechanism for OpenID that allows the integration of existing OpenID 19 Identity Providers with applications using SASL. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on July 23, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Applicability for non-HTTP Use Cases . . . . . . . . . . . . . 5 64 2.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 10 66 3.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 10 67 3.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.3. Authentication Request . . . . . . . . . . . . . . . . . . 10 69 3.4. Server Response . . . . . . . . . . . . . . . . . . . . . 10 70 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 5.1. Binding OpenIDs to Authorization Identities . . . . . . . 14 73 5.2. RP redirected by malicious URL to take an improper 74 action . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 5.3. Session Swapping (Cross-Site Request Forgery) . . . . . . 14 76 5.4. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 15 77 5.5. Collusion between RPs . . . . . . . . . . . . . . . . . . 15 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 80 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 81 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 OpenID [OpenID] is a three-party protocol that provides a means for a 87 user to offer identity assertions and other attributes to a web 88 server (Relying Party) via the help of an identity provider. The 89 purpose of this system is to provide a way to verify that an end user 90 controls an identifier. 92 Simple Authentication and Security Layer (SASL) [RFC4422] (SASL) is 93 used by application protocols such IMAP, POP and XMPP, with the goal 94 of modularizing authentication and security layers, so that newer 95 mechanisms can be added as needed. This memo specifies just such a 96 mechanism. 98 As currently envisioned, this mechanism is to allow the interworking 99 between SASL and OpenID in order to assert identity and other 100 attributes to relying parties. As such, while servers (as relying 101 parties) will advertise SASL mechanisms, clients will select the 102 OpenID mechanism. 104 The OpenID mechanism described in this memo aims to re-use the 105 available OpenID specification to a maximum extent and therefore does 106 not establish a separate authentication, integrity and 107 confidentiality mechanism. It is anticipated that existing security 108 layers, such as Transport Layer Security (TLS), will continued to be 109 used. 111 Figure 1 describes the interworking between OpenID and SASL. This 112 document requires enhancements to the Relying Party and to the Client 113 (as the two SASL communication end points) but no changes to the 114 OpenID Provider (OP) are necessary. To accomplish this goal indirect 115 messaging required by the OpenID specification is tunneled within 116 SASL. 118 +-----------+ 119 | | 120 >| Relying | 121 / | Party | 122 // | | 123 // +-----------+ 124 // ^ 125 OpenID // +--|--+ 126 // | O| | 127 / S | p| | 128 // A | e| | 129 // S | n| | 130 // L | I| | 131 // | D| | 132 | Client | 137 | | | | 138 +------------+ +----------+ 140 Figure 1: Interworking Architecture 142 1.1. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 The reader is assumed to be familiar with the terms used in the 149 OpenID 2.0 specification. 151 2. Applicability for non-HTTP Use Cases 153 OpenID was originally envisioned for HTTP/HTML based communications, 154 and with the associated semantic, the idea being that the user would 155 be redirected by the Relying Party to an identity provider who 156 authenticates the user, and then sends identity information and other 157 attributes (either directly or indirectly) to the Relying Party. The 158 actual protocol flow, as copied from the OpenID 2.0 specification, is 159 as follows: 161 1. The end user initiates authentication by presenting a User- 162 Supplied Identifier to the Relying Party via their User-Agent 163 (e.g., http://user.example.com). 165 2. After normalizing the User-Supplied Identifier, the Relying Party 166 performs discovery on it and establishes the OP Endpoint URL that 167 the end user uses for authentication. It should be noted that 168 the User-Supplied Identifier may be an OP Identifier, which 169 allows selection of a Claimed Identifier at the OP or for the 170 protocol to proceed without a Claimed Identifier if something 171 else useful is being done via an extension. 173 3. The Relying Party and the OP optionally establish an association 174 -- a shared secret established using Diffie-Hellman Key Exchange. 175 The OP uses an association to sign subsequent messages and the 176 Relying Party to verify those messages; this removes the need for 177 subsequent direct requests to verify the signature after each 178 authentication request/response. 180 4. The Relying Party redirects the end user's User-Agent to the OP 181 with an OpenID Authentication request. This occurs as stated in 182 Section 10.3 of [RFC2616]. 184 5. The OP authenticates the end user and establishes whether the end 185 user will authenticate to, and share specific attributes with, 186 the Relying Party. For instance, the OP often asks the user what 187 to do. The manner in which the end user authenticates to their 188 OP and any policies surrounding such authentication is out of 189 scope of OpenID. 191 6. The OP redirects the end user's User-Agent back to the Relying 192 Party with either an assertion that authentication is approved or 193 a message that authentication failed. 195 7. The Relying Party verifies the information received from the OP 196 including checking the Return URL, verifying the discovered 197 information, checking the nonce, and verifying the signature by 198 using either the shared key established during the association or 199 by sending a direct request to the OP. 201 When considering this flow in the context of SASL, we note that while 202 the RP and the client both must change their code to implement this 203 SASL mechanism, the OP must remain untouched. Hence, an analog flow 204 that interfaces the three parties needs to be created. In the 205 analog, we note that unlike a web server, the SASL server already has 206 some sort of session (probably a TCP connection) established with the 207 client. However, it may be necessary to redirect a SASL client to 208 another application. This will be discussed below. By doing so, we 209 externalize much of the authentiction from SASL. 211 The steps are shown from below: 213 1. The Relying Party or SASL server advertises support for the SASL 214 OpenID mechanism to the client. 216 2. The client initiates a SASL authentiation and transmits the 217 User-Supplied Identifier as well as an optional return_to 218 parameter. 220 3. After normalizing the User-Supplied Identifier, the Relying 221 Party performs discovery on it and establishes the OP Endpoint 222 URL that the end user uses for authentication. 224 4. The Relying Party and the OP optionally establish an association 225 -- a shared secret established using Diffie-Hellman Key 226 Exchange. The OP uses an association to sign subsequent 227 messages and the Relying Party to verify those messages; this 228 removes the need for subsequent direct requests to verify the 229 signature after each authentication request/response. 231 5. The Relying Party transmits an authentication request to the OP 232 to obtain an assertion in the form of an indirect request. 233 These messages are passed through the client rather than 234 directly between the RP and the OP. OpenID defines two methods 235 for indirect communication, namely HTTP redirects and HTML form 236 submission. Both mechanisms are not directly applicable for 237 usage with SASL. To ensure that a standard OpenID 2.0 capable 238 OP can be used a new method is defined in this document that 239 requires the OpenID message content to be encoded using a 240 Universal Resource Idenitifier (URI). [RFC3986] 242 6. The SASL client now sends an empty response, as authentication 243 continues via the normal OpenID flow. 245 7. At this point the client application MUST construct a URL 246 containing the content received in the previous message from the 247 RP. This URL is transmitted to the OP either by the SASL client 248 application or an appropriate handler, such as a browser. 250 8. Next the client optionally authenticates to the OP and then 251 approves or disapproves authentication to the Relying Party. 252 The manner in which the end user is authenticated to their 253 respective OP and any policies surrounding such authentication 254 is out of scope of OpenID and and hence also out of scope for 255 this specification. This step happens out of band from SASL. 257 9. The OP will convey information about the success or failure of 258 the authentication phase back to the RP, again using an indirect 259 response via the client browser or handler. The client 260 transmits over HTTP the redirect of the OP result to the RP. 261 This step happens out of band from SASL. 263 10. The RP MAY send an OpenID check_authentication request directly 264 to the OP, if no association has been established, and the OP 265 should be expected to respond. Again this step happens out of 266 band from SASL. 268 11. The SASL server sends an appropriate SASL response to the 269 client, with optional Open Simple Registry (SREG) attributes. 271 SASL Serv. Client OP 272 |>-----(1)----->| | Advertisement 273 | | | 274 |<-----(2)-----<| | Initiation 275 | | | 276 |> - - (3) - - - - - - - - - ->| Discovery 277 | | 278 |>- - -(4)- - - - - - - - - - >| Association 279 |<- - -(4)- - - - - - - - - - <| 280 | | | 281 |>-----(5)----->| | Indirect Auth Request 282 | | | 283 |<-----(6)-----<| | Client Empty Response 284 | | | 285 | |>- - (7)- - ->| Client GET to the OP (ext) 286 | | | 287 | |<- - (8)- - ->| Client / OP Auth. (ext.) 288 | | | 289 |<- - -(9)- - - + - - - - - - <| HTTP(s) Indirect id_res 290 | | | 291 |<- - -(10)- - - - - - - - - ->| Optional check_authenticate 292 | | | 293 |>-----(11)---->| | SASL completion with status 295 ----- = SASL 296 - - - = HTTP or SSL 298 Note the directionality in SASL is such that the client MUST send an 299 empty response. Specifically, it processes the redirect and then 300 awaits a final SASL decision, while the rest of the OpenID 301 authentication process continues. 303 2.1. Discussion 305 As mentioned above OpenID is primarily designed to interact with web- 306 based applications. Portions of the authentication stream are only 307 defined in the crudest sense. That is, when one is prompted to 308 approve or disapprove an authentication, anything that one might find 309 on a browser is allowed, including JavaScript, fancy style-sheets, 310 etc. Because of this lack of structure, implementations will need to 311 invoke a fairly rich browser in order to insure that the 312 authentication can be completed. 314 Once there is an outcome, the SASL server needs to know about it. 315 The astute will hopefully by now have noticed an empty client SASL 316 challenge. This is not to say that nothing is happening, but rather 317 that authentication flow has shifted from SASL to OpenID, and will 318 return when the server has an outcome to hand to the client. The 319 alternative to this flow is some signal from the HTML browser to the 320 SASL client of the results that is in turn passed to the SASL server. 321 The IPC issue this raises is substantial. Better, we conclude, to 322 externalize the authentication to the browser, and have an empty 323 client challenge. 325 3. OpenID SASL Mechanism Specification 327 Based on the previous figure, the following operations are performed 328 with the OPENID SASL mechanism: 330 3.1. Advertisement 332 To advertise that a server supports OpenID, during application 333 session initiation, it displays the name "OPENID" in the list of 334 supported SASL mechanisms. 336 3.2. Initiation 338 A client initiates an OpenID authentication with SASL by the XRI or 339 URI, as specified in the OpenID specification. Additionally, the 340 supported version of OpenID is indicated. 342 initial-response = Identifier UTF8NUL openid-version 343 Identifier = URI | XRI ; Identifer is specified in 344 ; Sec. 7.2 of the OpenID 2.0 spec. 345 ; XRI as specified by OASIS 2.0 Syntax 346 ; URI is specified in RFC 3986. 347 openid-version = 1*DIGIT [ "." 1*DIGIT ] 349 The XRI syntax is defined in [XRI2.0]. 351 3.3. Authentication Request 353 The SASL Server sends an OpenID message that contains an openid.mode 354 of either "checkid_immediate" or "checkid_setup", as specified in 355 Section 9.1 of the OpenID 2.0 specification. 357 The client now sends that request via an HTTP GET to the OP, as if 358 redirected to do so from an HTTP server. 360 The client MUST handle both user authentication to the OP and 361 confirmation or rejection of the authentiation of the RP. 363 After all authentication has been completed by the OP, and after the 364 response has been sent to the client, the client will relay the 365 response to the Relying Party via HTTP or SSL. 367 3.4. Server Response 369 The Relying Party now validates the response it received from the 370 client via HTTP or SSL, as specified in the OpenID specification. 372 The response by the Relying Party consists of an application specific 373 response code indicating success or failure of authentication. In 374 the additional data, the server MAY include OpenID Simple Registry 375 (SREG) attributes that are listed in Section 4 of [SREG1.0]. They 376 are encoded as follows: 378 1. Strip "openid.sreg." from each attribute name. 380 2. Treat the concatentation of results as URI parameters that are 381 separated by an ambersand (&) and encode as one would a URI, 382 absent the scheme, authority, and the question mark. 384 For example: email=lear@example.com&fullname=Eliot%20Lear 386 More formally: 388 outcome_data = [ sreg_avp *( "," sreg_avp ) ] 389 sreg_avp = sreg_attr "=" sreg_val 390 sreg_attr = sreg_word 391 sreg_val = sreg_word 392 sreg_word = 1* ( unreserved / pct-encoded ) 393 ; pct-encoded from Section 2.1 of RFC 3896 394 ; unreserved from Section 2.3 of RFC 3896 396 If the application protocol allows, openid.error and 397 openid.error_code and any other useful diagnostic information SHOULD 398 be included in authentication failures. 400 4. Example 402 Suppose one has an OpenID of http://openid.example, and wishes to 403 authenticate his IMAP connection to mail.example (where .example is 404 the top level domain specified in [RFC2606]). The user would input 405 his Openid into his mail user agent, when he configures the account. 406 In this case, no association is attempted between the OpenID Consumer 407 and the OP. The client will make use of the return_to attribute to 408 capture results of the authentication to be redirected to the server. 409 The authentication on the wire would then look something like the 410 following: 412 (S = IMAP server; C = IMAP client) 414 C: < connects to IMAP port> 415 S: * OK 416 C: C1 CAPABILITY 417 S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID 418 S: C1 OK Capability Completed 419 C: C2 AUTHENTICATE OPENID aHR0cDovL29wZW5pZC5leGFtcGxlLwAy 420 [ This is the base64 encoding of "http://openid.example/\02" 421 with line breaks and spaces added here for readibility. 422 Server performs discovery on https://openid.example/ ] 423 S: + aHR0cDovL29wZW5pZC5leGFtcGxlL29wZW5pZC8/b3BlbmlkLm5zPWh 424 0dHA6Ly9zcGVjcy5vcGVuaWQubmV0L2F1dGgvMi4wJm9wZW5pZC5yZX 425 R1cm5fdG89aHR0cHM6Ly9tYWlsLmV4YW1wbGUvY29uc3VtZXImb3Blb 426 mlkLmNsYWltZWRfaWQ9aHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS8mb3Bl 427 bmlkLmlkZW50aXR5PWh0dHBzOi8vb3BlbmlkLmV4YW1wbGUvJm9wZW5 428 pZC5yZWFsbT1pbWFwOi8vbWFpbC5leGFtcGxlJm9wZW5pZC5tb2RlPW 429 NoZWNraWRfc2V0dXA= 430 [ This is the base64 encoding of http://openid.example/openid/ 431 ?openid.ns=http://specs.openid.net/auth/2.0 432 &openid.return_to=https://mail.example/consumer 433 &openid.claimed_id=https://openid.example/ 434 &openid.identity=https://openid.example/ 435 &openid.realm=imap://mail.example 436 &openid.mode=checkid_setup 438 ] 439 C: 440 [ The client now sends the URL it received to a browser for 441 processing. The user logs into http://openid.example, and 442 agrees to authenticate imap://mail.example. A redirect is 443 passed back to the client browser who then connects to 444 https://imap.example/consumer via SSL with the results. 445 From an IMAP perspective, however, the client sends an empty 446 response, and awaits mail.example. 447 Server mail.example would now contact openid.example with an 448 openid.check_authenticate message. After that... 449 ] 450 S: C2 OK [OPENID ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbW 451 U9RWxpb3QlMjBMZWFy] authenticated. 452 [ Here the IMAP server has returned an SREG attribute of 453 email=lear@mail.example,fullname=Eliot%20Lear. 454 Line break added in this example for clarity. ] 456 5. Security Considerations 458 This section will address only security considerations associated 459 with the use of OpenID with SASL applications. For considerations 460 relating to OpenID in general, the reader is referred to the OpenID 461 specification and to other literature. Similarly, for general SASL 462 Security Considerations, the reader is referred to that 463 specification. 465 5.1. Binding OpenIDs to Authorization Identities 467 As specified in [RFC4422], the server is responsible for binding 468 credentials to a specific authorization identity. It is therefore 469 necessary that either some sort of registration process takes place 470 to register specific OpenIDs, or that only specific trusted OpenID 471 Providers be allowed. Some out of band knowledge may help this 472 process along. For instance, users of a particular domain may 473 utilize a particular OP that enforces a mapping. 475 5.2. RP redirected by malicious URL to take an improper action 477 In the initial SASL client response a user or host can transmit a 478 malicious to the RP for purposes of taking advantage of weaknesses in 479 the RP's OpenID implementation. It is possible to add port numbers 480 to the URL so that the outcome is the RP does a port scan of the 481 site. The URL could send the connection to an internal host or even 482 the local host, which the attacker would not normally have access to. 483 The URL could contain a protocol other than http or https, such as 484 file or ftp. 486 To mitigate this attack, implementations should carefully analyze 487 URLs received, eliminating any that would in some way be privileged. 488 A log of those sites that fail SHOULD be kept, and limitations on 489 queries from clients should be imposed, just as with any other 490 authentication attempt. 492 5.3. Session Swapping (Cross-Site Request Forgery) 494 There is no defined mechanism in the OpenID protocol to bind the 495 OpenID session to the user's browser. An attacker may forge a cross- 496 site request in the log-in form, which has the user logging into a 497 proper RP as the attacker. The user would not recognize they are 498 logged into the site as the attacker, and so may reveal information 499 at the RP. Cross-site request forgery is a widely exploited 500 vulnerability at web sites. This is only concern in the context SASL 501 in as much as the client is not configured with the Relying Party 502 (e.g., SASL server) in a safe manner. 504 5.4. User Privacy 506 The OP is aware of each RP that a user logs into. There is nothing 507 in the protocol to hide this information from the OP. It is not a 508 requirement to track the visits, but there is nothing that prohibits 509 the collection of information. SASL servers should be aware that 510 OpenID Providers will be track - to some extent - user access to 511 their services and any additional information that OP provides. 513 5.5. Collusion between RPs 515 It is possible for RPs to link data that they have collected on you. 516 By using the same identifier to log into every RP, collusion between 517 RPs is possible. In OpenID 2.0, directed identity was introduced. 518 Directed identity allows the OP to transform the identifier the user 519 typed in to another identifier. This way the RP would never see the 520 actual user identifier, but a randomly generated identifier. This is 521 an option the user has to understand and decide to use if the OP is 522 supporting it. 524 6. IANA Considerations 526 The IANA is requested to register the following SASL profile: 528 SASL mechanism profile: OPENID 530 Security Considerations: See this document 532 Published Specification: See this document 534 For further information: Contact the authors of this document. 536 Owner/Change controller: the IETF 538 Note: None 540 7. Acknowledgments 542 The authors would like to thank Alexey Melenkov, Joe Hildebrand, Mark 543 Crispin, and Klaas Wierenga for their review and contributions. 545 8. Normative References 547 [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", 548 December 2007. 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, March 1997. 553 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 554 Names", BCP 32, RFC 2606, June 1999. 556 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 557 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 558 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 560 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 561 Resource Identifier (URI): Generic Syntax", STD 66, 562 RFC 3986, January 2005. 564 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 565 Security Layer (SASL)", RFC 4422, June 2006. 567 [SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension 568 version 1.0", June 2006. 570 [XRI2.0] Reed, D. and D. McAlpin, "Extensible Resource Identifier 571 (XRI) Syntax V2.0", OASIS Standard xri-syntax-V2.0-cs, 572 September 2005. 574 Appendix A. Changes 576 This section to be removed prior to publication. 578 o 00 Initial Revision. 580 Authors' Addresses 582 Eliot Lear 583 Cisco Systems GmbH 584 Richtistrasse 7 585 Wallisellen, ZH CH-8304 586 Switzerland 588 Phone: +41 44 878 9200 589 Email: lear@cisco.com 591 Hannes Tschofenig 592 Nokia Siemens Networks 593 Linnoitustie 6 594 Espoo 02600 595 Finland 597 Phone: +358 (50) 4871445 598 Email: Hannes.Tschofenig@gmx.net 599 URI: http://www.tschofenig.priv.at 601 Henry Mauldin 602 Cisco Systems, Inc. 603 170 West Tasman Drive 604 San Jose, CA 95134 605 USA 607 Phone: +1 (800) 553-6387 608 Email: hmauldin@cisco.com