idnits 2.17.00 (12 Aug 2021) /tmp/idnits2634/draft-mrw-abfab-multihop-fed-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 (July 11, 2011) is 3966 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) == Outdated reference: A later version (-02) exists of draft-howlett-radsec-knp-01 ** Downref: Normative reference to an Informational draft: draft-howlett-radsec-knp (ref. 'I-D.howlett-radsec-knp') ** Downref: Normative reference to an Informational draft: draft-lear-abfab-arch (ref. 'I-D.lear-abfab-arch') == Outdated reference: draft-ietf-karp-threats-reqs has been published as RFC 6862 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Wasserman 3 Internet-Draft Painless Security 4 Intended status: Standards Track H. Tschofenig 5 Expires: January 12, 2012 Nokia Siemens Networks 6 S. Hartman 7 Painless Security 8 July 11, 2011 10 Multihop Federations for Application Bridging for Federation Beyond the 11 Web (ABFAB) 12 draft-mrw-abfab-multihop-fed-01.txt 14 Abstract 16 This document describes a mechanism for establishing trust across a 17 multihop federation within the Application Bridging for Federation 18 Beyond the Web (ABFAB) framework. 20 This document introduces a new entity, the Trust Router. Trust 21 Routers exchange information about the availability of Trust Paths 22 across a multihop federation. They can be queried by a Relying Party 23 to obtain the best Trust Path to reach an Identity Provider. They 24 also provide temporary identities that can be used by a Relying Party 25 to traverse a Trust Path. 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 12, 2012. 44 Copyright Notice 46 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Multihop Federation Example . . . . . . . . . . . . . . . . . 7 65 5. Trust Router Protocol . . . . . . . . . . . . . . . . . . . . 9 66 6. Trust Path Query . . . . . . . . . . . . . . . . . . . . . . . 10 67 7. Temporary Identity Request . . . . . . . . . . . . . . . . . . 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 12 70 8.2. Security Requirements . . . . . . . . . . . . . . . . . . 13 71 8.3. Data Origin validation and signatures . . . . . . . . . . 13 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 This document describes a mechanism for establishing trust across a 82 multihop federation within the Application Bridging for Federation 83 Beyond the Web (ABFAB) framework [I-D.lear-abfab-arch]. 85 This document introduces a new ABFAB entity, the Trust Router. Trust 86 Routers exchange information about the availability of Trust Paths 87 across a multihop federation. ABFAB entity, the Trust Router. These 88 paths are used by RPs to contruct transitive trust chains across a 89 federation to a Radius or Diameter server within a target IdP. 91 A Trust Path consists of one or more Trust Links. A Trust Link is an 92 assertion that a specific Trust Router is capable of providing 93 temporary identies that can be used to access another entity in the 94 ABFAB system. At this point, we anticipate that there will be two 95 types of Trust Links in ABFAB: a Trust Link that indicates that one 96 Trust Router can be used to reach another Trust Router, and a Trust 97 Link that indicates that a Trust Router can be used to reach a Radius 98 or Diameter Server. The first type (Trust Router Links) are shown as 99 A->B(T), which indicates that the Trust Router in realm A can create 100 identities to reach the trust router in Realm B. The second type 101 (Radius/Diameter Links) are shown as A->B(R), to indicate that a 102 trust router in Realm A can be used to reach a Radius, RadSec or 103 Diameter server in Realm B. 105 Trust Routers exchange information about available Trust Links within 106 a federation, and each Trust Router maintains a tree of available 107 paths to reach all of the IdPs within the federation that can be 108 reached from the local realm of the Trust Router. 110 When an RP receives a request from a party within a realm that not 111 known directly to the RP, the RP will query its local Trust Router to 112 obtain the best Trust Path to reach that IdP. Note that we use the 113 term 'best' here to highlight that there may well be multiple paths 114 to reach an IdP from a given RP, and the selection of the 'best' path 115 may involve several factors in addition to the length of the path, 116 such as security and privacy practices, or monetary costs. 118 The RP will travers the Trust Path obtained from it's local Trust 119 Router. At each step, the RP will request a temporary identity to 120 access the next step in the Trust Path, contructing a transitive 121 chain of trust to a Radius or Diameter server within the target IdP. 123 To summarize, the Trust Router performs three functions: 125 o Trust Routers peer with other Trust Routers to exchange 126 information about available Trust Links, and Trust Paths. This 127 information is exchanged between Trust Routers using the Trust 128 Router Protocol. The Trust Router Protocol is described in more 129 detail in Section 5. 131 o Trust Routers respond to queries from Relying Parties to make 132 information about Trust Paths available. This exchange is 133 referred to as a Trust Path Query Protocol, which is described in 134 Section 6. 136 o To follow the Trust Path across a federation, the RP will use KNP 137 to ask each Trust Router along the path to provision a temporary 138 identity that can be used to gain access to the next step in the 139 path. This mechanism is called a Temporary Identity Request, 140 which is described in Section 7. 142 2. 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 This document introduces the following terms: 150 Trust Router: 152 This is a logical ABFAB entity that exchanges information about 153 Trust Paths that Relying Parties can use to create transtitive 154 chains of trust across multihop ABFAB federations. 156 Trust Link: 158 A Trust Link is an assertion that a given Trust Router is capable 159 of providing a temporary identity to communicate with another 160 ABFAB entity (either another Trust Router, or a Radius/Diameter 161 server within an IdP). 163 Trust Path: 165 A Trust Path is a concatenation of Trust Links that can be used by 166 an RP to contruct a transitive trust chain across a federation to 167 a target IdP. 169 Trust Router Protocol: 171 The Trust Router Protocol is the mechanism used by two Trust 172 Routers to exchange information about Trust Links and Trust Paths. 174 The terms Identity Provider (IdP), Relying Party (RP), Subject, and 175 Federation are used as defined in [I-D.lear-abfab-arch]. 177 3. Motivation 179 Figure 1 shows an example federation where the Relying Party Foo, has 180 established relationships with various Identity Providers. 182 +---------------+ 183 | Identity | 184 | Provider | `.. 185 | Example-A.org | `-._ 186 +---------------+ `.. 187 `-._ 188 +---------------+ `._ +-----------+ 189 | Identity | `- | Relying | 190 | Provider | ------------------ | Party Foo | 191 | Example-B.org | _.- +-----------+ 192 +---------------+ _,-' 193 ,,' 194 +---------------+ _.-' o 195 | Identity | _,-' \|/ 196 | Provider | ' | 197 | Example-C.org | / \ 198 +---------------+ Subject 200 Figure 1: One-to-many Federation Example 202 When an RP receives a request to access a protected resource (or 203 requires authentication and authorization for other purposes) the 204 request includes a realm name that indicates the IdP the Subject has 205 selected for this exchange. Offering the Subject the ability to 206 choose among many different IdPs is necessary because a Subject may 207 have, and want to maintain, uncorrelated identities in several 208 different realms within a single federation (i.e. work, school, 209 social networking, etc.). However, this also places a burden on the 210 RPs to establish and maintain business agreements and exchange 211 security credentials with a potentially large number of Identity 212 Providers. 214 In order for a single-hop federation to function, each IdP needs to 215 maintain business agreements and exchange credentials with every RP 216 that its Subjects are authorized to access. Figure 2, shows the 217 likely outcome, which is that a single-hop federation will come to 218 resemble a dense mesh topology. 220 +---------------+ 221 | Identity | 222 | Provider |-.._ 223 | Example-A.org |`. ``-.._ 224 +---------------+ `-. ``-..__ +-----------+ 225 `. `--.| Relying | 226 +---------------+ `. __..--| Party Foo | 227 | Identity | __:.--'' .-'+-----------+ 228 | Provider |_..--'' `. .-' 229 | Example-B.org | .-'. 230 +---------------+ .' '. +-----------+ 231 .-' -. | Relying | 232 +---------------+ .-' `-.| Party Bar | 233 | Identity |.-' ____....---''+-----------+ 234 | Provider |.----''' 235 | Example-C.org | 236 +---------------+ o 237 \|/ 238 | 239 / \ 240 Subject 242 Figure 2: Mesh Federation Example 244 As discussed in section 2.1.1 of [I-D.lear-abfab-arch], as the number 245 of organizations involved in a ABFAB federation increase, static 246 configuration may not scale sufficiently. Also, using a Trust Broker 247 to establish keys between entities near the RP and entities near the 248 IDP with improve the security and privacy of an ABFAB federation. 249 Figure 3 shows the structure of a federation where each IdP and RP 250 has a single connection to the Trust Router infrastructure. 252 +---------------+ 253 | Identity | 254 | Provider |\ 255 | Example-A.org | `. 256 +---------------+ \ +-----------+ 257 \ .-'| Relying | 258 +---------------+ `. +---------------+ .' | Party Foo | 259 | Identity | \| Trust |.-' +-----------+ 260 | Provider |........| Broker | 261 | Example-B.org | /| |`-. 262 +---------------+ .' +---------------+ `. +-----------+ 263 / `-.| Relying | 264 +---------------+ / | Party Bar | 265 | Identity | .' +-----------+ 266 | Provider |/ O 267 | Example-C.org | \|/ 268 +---------------+ | 269 / \ 270 Subject 272 Figure 3: Federation Broker 274 To improve the operational scalability and security of large ABFAB 275 federations, this document proposes a Trust Broker solution 276 consisting of of a set of Trust Routers, as described in this 277 document, and the Key Negotiation Protocol (KNP), as described in 278 [I-D.howlett-radsec-knp]. 280 4. Multihop Federation Example 282 The diagram below shows an example of a successful exchange in a 283 multihop federation using the Trust Router Protocol and KNP: 285 Realm D | Realm C | Realm B | Realm A 287 | | | 288 +----------+ +----------+ +----------+ +----------+ 289 | Trust | | | Trust | | | Trust | | | Trust | 290 | Router D |<-1->| Router C |<-1->| Router B |<-1->| Router A | 291 +----------+ | +----------+ | +----------+ | +----------+ 292 ^ ^ ^ ^ 293 | | | | | | | 294 | | +---4------------ + | 295 | | | | | | | 296 | +----------------5---------------+ | 3 297 | | | | | | | 298 +----------------6------------------------------+ | | | 299 | | | | | | | 300 v v v v 301 +----------+ | | | +----------+ 302 | Identity |<---------7--------------------------->| Relying | 303 | Provider | | | | | Party | 304 +----------+ +----------+ 305 ^ | | | ^ 306 1 | 307 | | | | | 308 v | 309 +----------+ | | | | 310 | Subject |----------2---------------------------------+ 311 | | | | | 312 +----------+ 313 | | | 315 A multihop federation exchange matching the above diagram can be 316 summarized as follows: 318 1. We start with a single federation including four realms, each 319 containing a single Trust Router. The Trust Routers are peered, 320 such that their interconnections form a multihop federation. 322 2. A Subject (with an identity in Realm D) attempts to access a 323 service provided by a Relying Party in Realm A. 325 3. The Relying Party does not have direct access to a Radius or 326 Diameter server in Realm D that it can use to authenticate the 327 Subject, so it asks its local Trust Router for a Trust Path to 328 reach Realm D. The Trust Router in Realm A returns the path 329 A->B(T)->C(T)->D(T)->D(R), which indicates that the Relying Party 330 should use the Trust Routers in Realms B, C and D to reach a 331 RADIUS or RADSEC server in Realm D, which could then be used to 332 authenticate the Subject. 334 4. The Relying Party contacts a Trust Router in Realm B (using its 335 permanent identity in Realm A), and requests the creation of a 336 temporary identity that can be used to communicate with the Trust 337 Router in Realm C. 339 5. The Relying Party then contacts the Trust Router in Realm C 340 (using the temporary identity returned in the previous step), and 341 asks for a temporary identity that can be used to communicate 342 with the Trust Router in realm D. 344 6. The Relying Party then contacts the Trust Router in Realm D 345 (using the temporary identity returned in the previous step), and 346 asks the Trust Router to provision an identity that it can use to 347 speak to the Radius or Diameter server in Realm D (which is part 348 of Realm D's Identity Provider). 350 7. At this point, the Relying Party can reach the Subject's Identity 351 provider, and the rest of the ABFAB exchange can continue, as 352 described in [I-D.lear-abfab-arch]. 354 5. Trust Router Protocol 356 Trust Routers use the Trust Router Protocol to exchange information 357 about available Trust Links, and Trust Paths across a federation. 359 The Trust Router Protocol differs from an Internet Routing Protocol 360 in a couple of important ways: 362 o Trust Links are unidirectional. It can not be assumed that the 363 fact that a Trust Router in Realm A is authorized to create 364 temporary identities to access a Trust Router in realm B, that the 365 opposite is also true (A -> B(T) does not imply B->A(T)). 367 o Realm names are not necessarily hierarchical. Although 368 aggregation might be possible as a later optimization, the ability 369 to aggregate realm names based on shared roots is not currently 370 assumed. 372 In addition to the existence of the links themselves, Trust Links 373 have a set of associated attributes that can be used for filtering 374 and tree computation, including: 376 o The cost of the link. 378 o Any security and privacy characteristics associated with the link. 380 o Information indicating how/if the link should be propagated across 381 the federation. 383 Current thinking is that we will use a BGP-based algorithm for 384 computation of the local tree at each Trust Router, and that we will 385 communicate a similar set of information between Trust Routers as 386 would be communicated between Internet Routers running BGP. 388 6. Trust Path Query 390 A Trust Path Query is generated by a RP to request a Trust Path to 391 reach a specific realm within a given Policy Regime. If possible, 392 the Trust Router will reply with a Trust Path that consists of zero 393 or more Trust Router steps and ends with a Radius or Diameter server 394 within the IdP for the indicated realm. 396 The Trust Path Query is initiated by the RP, and the initial query 397 message will contain the destination realm and Policy Regime. 399 When a Trust Path Query is received by a Trust Router, the router 400 will first authenticate the RP, and check local policy information to 401 determine whether or not to reply. 403 Assuming that the RP is successfully authenticated and the request 404 passes local policy checks, the Trust Router will search it's tree of 405 Trust Path information to determine whether a Trust Path exists that 406 will reach the destination Realm within the indicated Policy Regime. 407 If so, the shortest/best Trust Path will be returned to the Relying 408 Party. 410 A Trust Path will consist of a list of steps, each of which will 411 contain: The type of the step (Trust Router or Radius/Diameter), the 412 Policy Regime associated with each step, information needed to reach 413 the indicated Trust Router or server (domain name or IP address), and 414 any special attributes associated with that step. 416 7. Temporary Identity Request 418 A Temporary Identity Request is issued by a Relying Party in order to 419 obtain an identity that can be used to traverse each step in the 420 Trust Path. When a Temporary Identity is requested, a Trust Router 421 will provision a new identity in its local Radius or Diameter 422 infrastructure that can be used by the Relying Party to communicate 423 with the Trust Router or Radus/Diameter server that represents the 424 next step in the Trust Path. Current thinking is that KNP will be 425 used as the protocol mechanism for these requests. 427 These Temporary Identities will have a finite lifetime and, when 428 authenticated, will include a Radius Attribute/Diameter AVP 429 indicating that they were generated based on a Temporary Identity 430 Request. This attribute will inlcude the chain of identities that 431 preceeded the current identity in the traversal of the Trust Path. 433 The details of how these messages will be encoded has not yet been 434 determined. However, it is expected that, for each Trust Router step 435 in the Trust Path, the following actions will take place: 437 1. The Relying Party will send a Temporary Identity Request message 438 to the Trust Router, containing the identity of the next step in 439 the Trust Path, the destination realm that it is trying to reach, 440 and the Policy Regime in use. This request will be sent using 441 the identity that the Trust Router obtained from the previous 442 step in the Trust Path (or the Trust Router's permanent identity 443 in it's home realm, if this is the first step). 445 2. The Trust Router will authenticate the Relying Party. 447 3. If the authentication is successful, the Trust Router will check 448 local policy to determine whether it should provision an identity 449 for the Relying Party for the indicated purpose (details of this 450 check may be implementation dependent). 452 4. If the request passes any policy requirements, the Trust Router 453 will provision a temporary identity for the Relying Party within 454 the Trust Router's local realm that can be used to access the 455 next-hop Trust Router or RADIUS/RADSEC server in the Trust Path. 457 8. Security Considerations 459 As discussed in [I-D.lear-abfab-arch], the trust broker architecture 460 is a mechanism for establishing technical trust in an ABFAB 461 federation. Technical trust mechanisms have three primary 462 responsibilities in ABFAB. They are responsible for integrity 463 protection of AAA traffic. They are responsible for constraining the 464 naming of ABFAB entities: for example the technical trust mechanism 465 assures that the entity claiming to be the IDP is authenticated and 466 authorized to act as the IDP for the realm containing the subject. 467 The technical trust mechanism also determines where AAA messages are 468 routed. 470 The trust broker architecture described in this document is designed 471 to meet the security and operational requirements of federations and 472 groups of federations with large numbers of organizations. In these 473 environments depending on any common credentials or trust mechanism 474 does not make sense. While federations are expected to interconnect, 475 they are not expected to have a common set of trust anchors for a 476 public-key infrastructure. Each realm needs to be able to choose the 477 appropriate credentials and security policies to use when 478 establishing a relationship with another realm. 480 by design, this approach provides flexibility. Parts of the 481 interconnected set of realms can use high-assurance processes and 482 mechanisms including strong authentication mechanisms and rigorous 483 credentialing and enrollment processes. Other realms can use lower- 484 assurance mechanisms and processes, balancing cost and speed against 485 security. However this flexibility complicates the security policy. 486 Just because the local realm has a high-assurance trust link does not 487 mean that the path is high-assurance. Operational mechanisms are 488 required in order for RPs to express their security requirements and 489 for the trust routers to make sure that resulting trust paths meet 490 these requirements. Similarly, trust routers need to make sure that 491 paths to a given IDP are not announced unless that IDP's security 492 requirements will be met. 494 8.1. Threat Model 496 Like all Internet protocols, the trust router protocols and KNP need 497 to have strong protection against parties who are not authorized to 498 be part of an exchange. Such attackers do not start out knowing 499 credentials necessary to participate in the system. However these 500 attackers can be assumed to observe trust router, KNP, AAA and ABFAB 501 exchanges. The system needs to maintain integrity of all data, 502 confidentiality of keys and in some cases confidentiality of other 503 data even when these attackers can insert, suppress, modify or replay 504 packets. Reasonable defenses against attacks on the availability of 505 the system are required, although obviously there are limits to these 506 defenses. An attacker who can disrupt connectivity with a realm can 507 impact availability. 509 The interesting threat model surrounds malicious participants 510 authorized to participate in the system. The threat model is similar 511 to that of routing protocols [I-D.ietf-karp-threats-reqs]. Defending 512 against a compromised actor announcing a trust link that actor would 513 be permitted to announce were it functioning correctly is out of 514 scope. Similarly, defending against an compromised actor performing 515 some action that actor is authorized to take is out of scope for this 516 threat model. 518 However, it is a requirement that the system needs to provide tools 519 to limit the authorization of actors. For example if a particular 520 session between two trust routers is not authorized to announce a 521 trust link to a given realm or with certain properties, then attacks 522 permitting such a link to be announced are in scope. Similarly an 523 attack permitting a temporary identity with properties inconsistent 524 with administrative limits would be in scope. 526 The system must permit zones of more or less trust to be created. An 527 attack that permits insiders in the zones of less trust to compromise 528 a zone of higher trust beyond what the zone of lesser trust is 529 permitted is within the scope of threats. However, trust can only 530 decrease as distance across the transitive network of trust routers 531 increases. A peer two hops away cannot be permitted to make any 532 statement that a peer one hop away cannot make. In general, it is 533 unknown whether the peer two hops away actually made the statement. 535 8.2. Security Requirements 537 TBD 539 8.3. Data Origin validation and signatures 541 TBD 543 9. IANA Considerations 545 There are no IANA actions required for this document at this time. 547 10. Acknowledgements 549 This document was written using the xml2rfc tool described in RFC 550 2629 [RFC2629]. 552 11. References 554 11.1. Normative References 556 [I-D.howlett-radsec-knp] 557 Howlett, J. and S. Hartman, "Key Negotiation Protocol for 558 RadSec (KNP)", draft-howlett-radsec-knp-01 (work in 559 progress), March 2011. 561 [I-D.lear-abfab-arch] 562 Howlett, J., Hartman, S., Tschofenig, H., and E. Lear, 563 "Application Bridging for Federated Access Beyond Web 564 (ABFAB) Architecture", draft-lear-abfab-arch-02 (work in 565 progress), March 2011. 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, March 1997. 570 11.2. Informative References 572 [I-D.ietf-karp-threats-reqs] 573 Lebovitz, G., Bhatia, M., and R. White, "The Threat 574 Analysis and Requirements for Cryptographic Authentication 575 of Routing Protocols' Transports", 576 draft-ietf-karp-threats-reqs-03 (work in progress), 577 June 2011. 579 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 580 June 1999. 582 Authors' Addresses 584 Margaret Wasserman 585 Painless Security 586 356 Abbott Street 587 North Andover, MA 01845 588 USA 590 Phone: +1 781 405 7464 591 Email: mrw@painless-security.com 592 URI: http://www.painless-security.com 594 Hannes Tschofenig 595 Nokia Siemens Networks 596 Linnoitustie 6 597 Espoo 02600 598 Finland 600 Phone: +358 (50) 4871445 601 Email: Hannes.Tschofenig@gmx.net 602 URI: http://www.tschofenig.priv.at 603 Sam Hartman 604 Painless Security 605 356 Abbott Street 606 North Andover, MA 01845 607 USA 609 Email: hartmans@painless-security.com 610 URI: http://www.painless-security.com