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