idnits 2.17.00 (12 Aug 2021) /tmp/idnits57983/draft-tschofenig-secure-the-web-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. 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 (July 15, 2012) is 3596 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5849' is defined on line 523, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2109 (Obsoleted by RFC 2965) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) == Outdated reference: draft-ietf-oauth-v2 has been published as RFC 6749 -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) == Outdated reference: draft-ietf-websec-origin has been published as RFC 6454 == Outdated reference: draft-ietf-websec-strict-transport-sec has been published as RFC 6797 -- Obsolete informational reference (is this intentional?): RFC 2069 (Obsoleted by RFC 2617) == Outdated reference: draft-ietf-abfab-arch has been published as RFC 7831 == Outdated reference: draft-ietf-httpbis-p7-auth has been published as RFC 7235 == Outdated reference: draft-ietf-rtcweb-overview has been published as RFC 8825 == Outdated reference: draft-ietf-rtcweb-security has been published as RFC 8826 Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational S. Turner 5 Expires: January 16, 2013 IECA, Inc. 6 S. Farrell 7 Trinity College Dublin 8 M. Hanson 9 Mozilla 10 July 15, 2012 12 An Inquiry into the Nature and the Causes of Web Insecurity 13 draft-tschofenig-secure-the-web-02.txt 15 Abstract 17 The year 2011 has been quite exciting from a Web security point of 18 view: a number of high-profile security incidents have gotten a lot 19 of press attention but also new initiatives, such as the National 20 Strategy for Trusted Identities in Cyberspace (NSTIC), had been 21 launched to improve the Web identity eco-system. The NSTIC strategy 22 paper, for example, observes problems with Internet security due to 23 the widespread usage of low-entropy passwords and the lack of widely 24 deployed authentication and attribute assurance services. 26 With this memorandum we try to develop a shared vision for how to 27 deal with the most pressing Web security problems. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 16, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5. From Two-Party to N-Party . . . . . . . . . . . . . . . . . . 12 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 70 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction 78 HTTP is an IETF standard and documented in RFC 2616 [RFC2616] and 79 provides the core foundation of the browser-based platform but is 80 also widely used for non-browser-based applications in smart phones 81 and Internet tablets. Like any other specification in the IETF HTTP 82 also comes with various security mechanims. Digest authentication 83 support in HTTP was published in 1997 with RFC 2069 [RFC2069] and 84 later updated in 1999 by RFC 2617 [RFC2617]. The HTTP state 85 management mechanism, namely cookies, was initially published in 1997 86 with RFC 2109 [RFC2109], and re-written in 2000 by RFC 2965 87 [RFC2965]. 89 For client side authentication two different solution tracks have 90 therefore been offered from the IETF, namely TLS client side 91 authenication (at that time the usage of client certificates was 92 envisioned) and also application level authentication via HTTP basic 93 and digest. TLS-based client authentication using certificates was 94 quite complex for end users to configure (and still is complex 95 today). HTTP based authentication on the other hand did not found 96 widespread usage either for a number of reasons. First, the user 97 interface was rendered differently than in regular Web application 98 form making it less attractive for users. At that time HTTP had a 99 semantic that was closer to file system access control and therefore 100 the decision making process was binary, either the user was granted 101 access to the resource or it wasn't. With the HTTP 401 there was no 102 way for a user to, for example, recover from a lost password or other 103 forms of failure cases. The authentication and authorization process 104 was not seen as continuium but rather as a binary decision. For 105 these reasons form-based authentication mechanisms had found 106 widespread acceptance by the Web application developer community. 107 Additionally, many Web sites decided to deploy their own 108 authentication infrastructure and to store cleartext credentials (in 109 most cases a username and a password) into a database. To add to 110 this problem cookies were and still are the most common mechanism for 111 session management, i.e., a non-cryptographic way to bind the initial 112 authentication to the subsequent HTTP protocol exchanges. Cookies 113 introduce various weaknesses into HTTP, including the ability for 114 attackers to perform session hijacking. In the last few years we 115 have seen many press anouncements of password leakage due to 116 unauthorized access to these credential databases. 118 In the last few years a few other standardization efforts were 119 started: RFC 2965 HTTP state management specification was recently 120 revised to capture deployment reality [RFC6265]. HTTP Strict 121 Transport Layer Security (HSTS) 122 [I-D.ietf-websec-strict-transport-sec] allows Web sites to declare 123 themselves accessible only via secure connections, and the attemp to 124 clarify the Web Origin Concept [I-D.ietf-websec-origin], which covers 125 the principles that underlies the concept of origin as used to scope 126 of authority or privilege by user agents. The HTTPbis Working Group 127 [I-D.ietf-httpbis-p7-auth] revises RFC 2616 plus those parts from RFC 128 2617 that describe the authentication schemes. 130 A lot has changed over the last 10 years in the Web eco-system, as 131 briefly described in the sub-sections below, and various efforts are 132 still ongoing or have recently been started to provide make Web 133 applications even more powerful. Unfortunately, the underlying Web 134 platform had not been able to keep up with these changes and the 135 security weaknesses will only became more apparent. It is time to 136 tackle this problem and to develop a common understanding of the 137 problem and the desired design goals. 139 From Documents to Mobile Code During the last 10 years the Web has 140 changed quite fundamentally with the widespread usage of 141 JavaScript. While Web pages have for a long time been dynamically 142 generated the ever increasing capabilities of JavaScript, with 143 respect to functionality and performance, have changed the 144 security model. A typical Website collects content from multiple 145 other Web sites and delivers it to the user's browser and by 146 delivering code inside HTML new security challenges have emerged. 147 Also the standardization landscape had been challenged by this new 148 development and [I-D.tschofenig-post-standardization] documents 149 architectural implications. 151 Mashups and Data Sharing With the increasing specialization of Web 152 sites developers started to outsource functionality to other 153 sites. Partially this is a user-convenience aspect (e.g., users 154 do not want to create a new address book with every site, publish 155 their latest status on each and every site again and again) but 156 often also driven by business interestes. In any case, the need 157 to access resources hosted on other sites emerged and often these 158 resources were not visible to everyone. Sharing long-term 159 passwords is considered a bad habit and consequently the Web 160 Authorization (OAuth) protocol [I-D.ietf-oauth-v2] started to 161 become used widely. OAuth avoids the need to share long-term 162 credentials with random Web sites. 164 The Real-Time Web As HTTP became the protocol of choice for many 165 application developers, also because of it's ability to go through 166 firewalls and NATs, requirements for asynchronous protocol 167 communication had to be addressed as well. HTTP, as a request/ 168 response protocol, was initially not designed for pushing data 169 from the server-side to the client as soon as it is available. 170 Long polling requests and other tricks had been used to allow bi- 171 directional communication between the HTTP client and the HTTP 172 server. More recently the BiDirectional or Server-Initiated HTTP 173 (hybi) working group was created, which only concerns one aspect 174 of real-time communication. To allow one Web browser to 175 communicate directly with another Web browser the same-origin 176 security framework utilized by the browser has to be bypassed and 177 the work on Real-Time Communication in WEB-browsers (rtcweb) was 178 chartered very recently to develop a architecture. More details 179 can be found in [I-D.ietf-rtcweb-security] and in 180 [I-D.ietf-rtcweb-overview]. Extending Web clients with real-time 181 communication capabilities opens the doors for a large number of 182 applications that had previously only been available for 183 downloadable applications. 185 While astonishing progress has been made in getting the Web 186 application eco-system on a par with native applications the 187 foundation of the Web platform is still unable to address many of the 188 most common security vulnerabilities; problems the Internet community 189 had been fighting against for over a decade and had solved for other 190 application protocol frameworks and Internet deployment environments. 191 This document aims to provide an introduction to the problem that 192 will serve as input to an upcoming Web authentication workshop. 194 2. Terminology 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in [RFC2119]. 200 3. Passwords 202 Passwords have a long history in authentication protocols on the 203 Internet. They appear to be convient for users and are easy to 204 provision to users by many Web site. Still, passwords present a 205 number of challenges, including: 207 o Users re-use the same password at multiple sites. This allows a 208 rouge Website provider to attempt to impersonate users on other 209 sites. It also allows a hacker to use stolen passwords obtained 210 from one site to be used at a non-compromised site. 212 o Password are stored in cleartext in most cases. In case of a data 213 breach account information, including the password, becomes 214 accessible to an attacker. 216 o Users are tricked in typing their password into a Website 217 maintained by phishing attempts. Furthermore, some Websites 218 request username and password for access to protected resources 219 maintained by other Websites. While there are technical ways to 220 avoid the need for such long-term password sharing practice using 221 OAuth some Websites still ask users. 223 o Many password based authenication protocols are not secure against 224 eavesdropping, or allow easy ways for offline dictionary attacks. 226 o When end systems are compromised as well then a keyboard logger 227 can capture any password sequence a user enters. 229 So, why do we need passwords at all? It is easy to come up with 230 solutions that use hardware-based mechanisms (e.g., such as OTP 231 tokens), mobile phones, etc. [Quest] lists some of these mechanisms 232 and makes an attempt to classify them. There are, however, reasons 233 why alternatives have not found widespread deployment on the 234 Internet, such as 236 o Passwords are cheap (at least the primary costs) for user's and 237 service providers. Hardware tokens on the other hand have a 238 certain amount of cost associated with them. 240 o Provisioning new users with passwords is easy. Tools and 241 processes exist and are widely accepted. 243 o Service providers have no external dependency when they manage 244 user accounts themselves (unlike with many third party identity 245 management solutions). 247 o Users are familiar with password-based systems and the acceptance 248 is good. 250 o Passwords can easily be delegated to others. 252 o Users typically feel quite secure when they are using shared 253 secrets and it fits into their mental model of self-securing. 255 o Passwords can easily be transferred to multiple devices used by a 256 single user. 258 Note that the credential type and the actual form of where these 259 credentials are stored (e.g., software, hardware) is orthogonal to 260 the actual identity proofing process. Stronger forms of identity 261 proofing (e.g., requiring in-person passport verification) can be 262 quite expensive. There are also secondary costs in the form of 263 support calls and education if credential provisioning is more 264 complicated, as it is often the case with client certificates. 266 Regardless how many disadvantages passwords have they will be with us 267 for a long time. As such, out attempt is therefore to start from the 268 currently deployment and to look towards a future where fewer of them 269 are used, and if they are used then in a more secure fashion. 271 4. Roadmap 273 It is our aim to accomplish three types of goals: 275 1. Reduce the number of passwords used on the Web 277 2. Increase security of how passwords are used 279 3. Broaden the use of other, non-password-based credentials 281 A non-goal of this document is to evaluate ways for improving 282 identity proofing, which is a requirement for accomplishing higher 283 levels of assurance. 285 We do not believe that the technical community should be attempting 286 to come up with the single and best solution to satisfy these three 287 goals. We would like to leave room for innovation and allow many 288 different solutions to co-exist to best suite their deployment. 290 Subsequently, we try to highlight a few guiding principles in an 291 attempt to come with a way forward. 293 Move Authentication down into the Platform: 295 Exposing authentication protocol functionality to the user and 296 requiring Web application developers to write security related 297 code has proven to lead to problems. Avoid user interaction 298 related to security whenever possible but keep in mind that 299 authorization decisions, particularly with regard to data sharing, 300 require a consent. Ensure that library support is available for 301 Web developers to allow them easy integration of security 302 functionality into their applications. Unfortunately a protocol 303 design also needs to consider the transition scenario where the 304 Web endpoints are not yet upgraded to support the new 305 functionality and that the authentication functionality is not yet 306 available. 308 Design for Growth: 310 No single authentication mechanism nor credential type is able to 311 fulfill all use cases. Design for later extensions and develop 312 the protocol architecture in such a way that components are 313 interchangable. In particular, there are a number of 314 authentication mechanisms already in use in other deployment 315 environments. 317 Context Matters: 319 Users require context for all disclosures and the sequence of 320 interactions matters. A monolitic authentication protocol that 321 provides mutual authentication is less likely going to capture the 322 context related disclosures. Server-side authentication is the 323 first interaction that will have to be provided to guarantee 324 genuine content as well as the prerequisity of an early setup for 325 a confidentiality protected channel. Client side authentication 326 may, however, come at a much later stage of the application 327 interaction. It is often bundled with an authorization decision 328 where different application execution paths depend on the level of 329 authorization. 331 Discussion: Is it indeed given that client authentication will 332 have to happen at a later stage given that platform-level 333 authentication proliferates and "authenticated by default" 334 becomes the norm? If so, then strong signals in UIs of 335 authenticated status, identity selection, and anonymous/ 336 pseudonymous modes become more important. One could compare 337 this to the evolution in the telephony communication where 338 caller ID information was initially not provided but became the 339 norm later and blocking the caller ID instead became the 340 expection. 342 Transform Long-Term Passwords to Short-Term Credentials: 344 One of the function of authentication protocols is to transform 345 long-term credentials into short term secrets. Long-term 346 credentials, such as passwords, require substantial protection in 347 a protocol exchange and therefore this interaction often leads to 348 a computationally expensive, multi-roundtrip protocol exchange. 349 We do, however, encourage protocol designers to make heavier use 350 of this transformation step into short term credentials. 351 Furthermore, the initial step of entity authentication cannot be 352 seen in isolution of the ultimate purpose of application protocol 353 interaction that requires session management to take place. While 354 this session management today happens in most cases in a non- 355 cryptographic way (i.e., without data origin authentication) we 356 believe it is time revisit this practice. 358 Keep the User Experience in Mind: 360 Design your protocol stack in such a way that developers up the 361 stack can give good advice to users. The use case analysis should 362 include common failure scenarios since error paths need as much 363 expressiveness as success paths, whereby expressiveness refers to 364 the ability to communicate with the user about failure cases. 366 5. From Two-Party to N-Party 368 It would be short sighted to write about a topic like this without 369 touching a commonly desired way to reduce the number of long term 370 credentials: federated logins 372 Federated login allows a user to utilize his credential obtained from 373 one organization, acting as the Identity Provider, for accessing a 374 resource at another entity, who acts as a Relying Party. While this 375 approach addresses some of our design goals it causes secondary 376 problems to appear - particularly related to privacy. 378 The following issues in this transition from a two-party to a three- 379 party model are to observe: 381 Introduction: 383 How do the three parties find each other? In particular, how does 384 the user (via his user agent) inform the relying party about the 385 identity provider it wants to use? How does the relying party 386 inform the user agent (and user) about the identity providers it 387 is able and willing to interact with? How does the relying party 388 find the identity provider for a given user? 390 Mutual Authentication: 392 How do we ensure that each party is authenticated to each other? 394 Authorization and Trust: 396 What information should the user share with the relying party and 397 how can he be reassured that the information is used in the way he 398 permitted? What information is needed by the Relying Party for 399 the application specific functionality? How is the identity 400 provider able to protect its users against misbehaving relying 401 parties? 403 Collusion: 405 How should a user be protected against identity providers and 406 relying parties conspiring? 408 Security: 410 How can it be ensured that the interactions between the three 411 parties are not manipulated or attacked? 413 Note: While this text talks about three parties there may well be 414 more parties involved in the exchange. The role of the identity 415 consists of a credential provider and an attribute provider that may 416 be provided by different parties. Furthermore, attributes associated 417 with personal data may be contributed by multiple attribute 418 providers, not just by a single entity. There may also be additional 419 parties involved in the communication between the identity provider 420 and the relying party the trust path from the identity provider to 421 the relying party. 423 6. IANA Considerations 425 This document does not require actions by IANA. 427 7. Acknowledgments 429 The content of this document has been created based on discussions 430 with a number of persons, including 432 o Jeff Hodges 434 o Michael Garcia 436 o Adam Barth 438 o Brad Hill 440 o Dan Mills 442 o Ed Felton 444 o Tara Whalen 446 o Andy Steingruebl 448 o Tim Polk 450 o Dirk Balfanz 452 o Nico Williams 454 o Tobias Gondrom 456 o Julian Reschke 458 We would like to thank them for their input. We would also like to 459 thank the participants of the May 2011 W3C Identity in the Browser 460 workshop for their discussion feedback. 462 8. Open Issues 464 This document version serves as a starting point for a discussion. 465 As such, there are several things not yet mentioned, such as 467 o The introduction section should also point to SPDY as recent 468 development in the are of HTTP evolution. 470 o The browser security model should be briefly described. As a 471 comparison, in the browser, we use cross-site communication 472 techniques (redirects, JavaScript) and SSL. In the OS/platform, 473 we use trusted APIs, e.g., signed code, OS-level APIs. In the 474 hardware, we use trusted computing bases (e.g., SIM cards or 475 locked-down platforms). 477 o The current document does not discuss how the relying party can 478 trust the information it receives from the identity provider nor 479 how the identity provider makes sure that the relying party adhere 480 to any privacy requirements it has. Various models for 481 accomplishing this trust have been mentioned in the past, 482 including trust frameworks as used by the General Services 483 Administration (GSA) Identity, Credential and Access Management 484 (ICAM), or the work envisioned by Application Bridging for 485 Federated Access Beyond web (abfab) [I-D.ietf-abfab-arch]. 487 o The document should also discuss the problems related to the PKI 488 as used by web browsers, the procedures for how trust anchors are 489 provisioned, and the lack of liability in the PKI. 491 9. References 493 9.1. Normative References 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, March 1997. 498 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 499 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 500 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 502 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 503 Leach, P., Luotonen, A., and L. Stewart, "HTTP 504 Authentication: Basic and Digest Access Authentication", 505 RFC 2617, June 1999. 507 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 508 Mechanism", RFC 2109, February 1997. 510 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 511 April 2011. 513 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 514 Mechanism", RFC 2965, October 2000. 516 9.2. Informative References 518 [I-D.ietf-oauth-v2] 519 Hardt, D. and D. Recordon, "The OAuth 2.0 Authorization 520 Framework", draft-ietf-oauth-v2-29 (work in progress), 521 July 2012. 523 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 524 April 2010. 526 [I-D.ietf-websec-origin] 527 Barth, A., "The Web Origin Concept", 528 draft-ietf-websec-origin-06 (work in progress), 529 October 2011. 531 [I-D.ietf-websec-strict-transport-sec] 532 Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 533 Transport Security (HSTS)", 534 draft-ietf-websec-strict-transport-sec-11 (work in 535 progress), July 2012. 537 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 538 Luotonen, A., Sink, E., and L. Stewart, "An Extension to 539 HTTP : Digest Access Authentication", RFC 2069, 540 January 1997. 542 [I-D.ietf-abfab-arch] 543 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 544 Schaad, "Application Bridging for Federated Access Beyond 545 Web (ABFAB) Architecture", draft-ietf-abfab-arch-03 (work 546 in progress), July 2012. 548 [I-D.ietf-httpbis-p7-auth] 549 Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 550 7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in 551 progress), March 2012. 553 [I-D.tschofenig-post-standardization] 554 Tschofenig, H., Aboba, B., Peterson, J., and D. McPherson, 555 "Trends in Web Applications and the Implications on 556 Standardization", draft-tschofenig-post-standardization-02 557 (work in progress), May 2012. 559 [I-D.ietf-rtcweb-overview] 560 Alvestrand, H., "Overview: Real Time Protocols for Brower- 561 based Applications", draft-ietf-rtcweb-overview-04 (work 562 in progress), June 2012. 564 [I-D.ietf-rtcweb-security] 565 Rescorla, E., "Security Considerations for RTC-Web", 566 draft-ietf-rtcweb-security-03 (work in progress), 567 June 2012. 569 [Quest] "The Quest to Replace Passwords: A Framework for 570 Comparative Evaluation of Web Authentication Schemes, In 571 Proc. IEEE Symp. on Security and Privacy 2012 (Oakland 572 2012)", July 2012. 574 Authors' Addresses 576 Hannes Tschofenig 577 Nokia Siemens Networks 578 Linnoitustie 6 579 Espoo 02600 580 Finland 582 Phone: +358 (50) 4871445 583 Email: Hannes.Tschofenig@gmx.net 584 URI: http://www.tschofenig.priv.at 586 Sean Turner 587 IECA, Inc. 588 3057 Nutley Street, Suite 106 589 Fairfax, VA 22031 590 USA 592 Phone: 593 Email: turners@ieca.com 595 Stephen Farrell 596 Trinity College Dublin 597 Dublin, 2 598 Ireland 600 Phone: +353-1-896-2354 601 Email: stephen.farrell@cs.tcd.ie 603 Mike Hanson 604 Mozilla 606 Phone: 607 Email: mhanson@mozilla.com