idnits 2.17.1 draft-ietf-oauth-device-flow-04.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 date (February 27, 2017) is 2615 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 (-10) exists of draft-ietf-oauth-discovery-05 == Outdated reference: A later version (-12) exists of draft-ietf-oauth-native-apps-07 ** Downref: Normative reference to an Informational RFC: RFC 6755 ** Downref: Normative reference to an Informational RFC: RFC 6819 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth W. Denniss 3 Internet-Draft Google 4 Intended status: Standards Track J. Bradley 5 Expires: August 31, 2017 Ping Identity 6 M. Jones 7 Microsoft 8 H. Tschofenig 9 ARM Limited 10 February 27, 2017 12 OAuth 2.0 Device Flow for Browserless and Input Constrained Devices 13 draft-ietf-oauth-device-flow-04 15 Abstract 17 This OAuth 2.0 authorization flow for browserless and input 18 constrained devices, often referred to as the device flow, enables 19 OAuth clients to request user authorization from devices that have an 20 Internet connection, but don't have an easy input method (such as a 21 smart TV, media console, picture frame, or printer), or lack a 22 suitable browser for a more traditional OAuth flow. This 23 authorization flow instructs the user to perform the authorization 24 request on a secondary device, such as a smartphone. There is no 25 requirement for communication between the constrained device and the 26 user's secondary device. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 31, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Device Authorization Request . . . . . . . . . . . . . . 5 66 3.2. Device Authorization Response . . . . . . . . . . . . . . 6 67 3.3. User Instruction . . . . . . . . . . . . . . . . . . . . 7 68 3.4. Device Access Token Request . . . . . . . . . . . . . . . 7 69 3.5. Device Access Token Response . . . . . . . . . . . . . . 8 70 4. Discovery Metadata . . . . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 5.1. User Code Brute Forcing . . . . . . . . . . . . . . . . . 10 73 5.2. Device Trustworthiness . . . . . . . . . . . . . . . . . 10 74 5.3. Remote Phishing . . . . . . . . . . . . . . . . . . . . . 10 75 5.4. Non-confidential Clients . . . . . . . . . . . . . . . . 10 76 5.5. Non-Visual Code Transmission . . . . . . . . . . . . . . 10 77 6. Usability Considerations . . . . . . . . . . . . . . . . . . 11 78 6.1. User Code Recommendations . . . . . . . . . . . . . . . . 11 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 7.1. OAuth URI Registration . . . . . . . . . . . . . . . . . 11 81 7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 11 82 7.2. OAuth Extensions Error Registration . . . . . . . . . . . 12 83 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 12 84 7.3. OAuth 2.0 Authorization Server Metadata . . . . . . . . . 12 85 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 12 86 8. Normative References . . . . . . . . . . . . . . . . . . . . 12 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 88 Appendix B. Document History . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 This OAuth 2.0 protocol flow for browserless and input constrained 94 devices, often referred to as the device flow, enables OAuth clients 95 to request user authorization from devices that have an internet 96 connection, but don't have an easy input method (such as a smart TV, 97 media console, picture frame, or printer), or lack a suitable browser 98 for a more traditional OAuth flow. This authorization flow instructs 99 the user to perform the authorization request on a secondary device, 100 such as a smartphone. 102 The device flow is not intended to replace browser-based OAuth in 103 native apps on capable devices (like smartphones). Those apps should 104 follow the practices specified in OAuth 2.0 for Native Apps OAuth 2.0 105 for Native Apps [I-D.ietf-oauth-native-apps]. 107 The only requirements to use this flow are that the device is 108 connected to the Internet, and able to make outbound HTTPS requests, 109 be able to display or otherwise communicate a URI and code sequence 110 to the user, and that the user has a secondary device (e.g., personal 111 computer or smartphone) from which to process the request. There is 112 no requirement for two-way communication between the OAuth client and 113 the user-agent, enabling a broad range of use-cases. 115 Instead of interacting with the end-user's user-agent, the client 116 instructs the end-user to use another computer or device and connect 117 to the authorization server to approve the access request. Since the 118 client cannot receive incoming requests, it polls the authorization 119 server repeatedly until the end-user completes the approval process. 121 +----------+ +----------------+ 122 | |>---(A)-- Client Identifier --->| | 123 | | | | 124 | |<---(B)-- Verification Code, --<| | 125 | | User Code, | | 126 | | & Verification URI | | 127 | Device | | | 128 | Client | Client Identifier & | | 129 | |>---(E)-- Verification Code --->| | 130 | | polling... | | 131 | |>---(E)-- Verification Code --->| | 132 | | | Authorization | 133 | |<---(F)-- Access Token --------<| Server | 134 +----------+ (w/ Optional Refresh Token) | | 135 v | | 136 : | | 137 (C) User Code & Verification URI | | 138 : | | 139 v | | 140 +----------+ | | 141 | End-user | | | 142 | at |<---(D)-- User authenticates -->| | 143 | Browser | | | 144 +----------+ +----------------+ 146 Figure 1: Device Flow. 148 The device flow illustrated in Figure 1 includes the following steps: 150 (A) The client requests access from the authorization server and 151 includes its client identifier in the request. 153 (B) The authorization server issues a verification code, an end- 154 user code, and provides the end-user verification URI. 156 (C) The client instructs the end-user to use its user-agent 157 (elsewhere) and visit the provided end-user verification URI. The 158 client provides the end-user with the end-user code to enter in 159 order to grant access. 161 (D) The authorization server authenticates the end-user (via the 162 user-agent) and prompts the end-user to grant the client's access 163 request. If the end-user agrees to the client's access request, 164 the end-user enters the end-user code provided by the client. The 165 authorization server validates the end-user code provided by the 166 end-user. 168 (E) While the end-user authorizes (or denies) the client's request 169 (D), the client repeatedly polls the authorization server to find 170 out if the end-user completed the end-user authorization step. 171 The client includes the verification code and its client 172 identifier. 174 (F) Assuming the end-user granted access, the authorization server 175 validates the verification code provided by the client and 176 responds back with the access token. 178 2. Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 182 "OPTIONAL" in this document are to be interpreted as described in 183 [RFC2119]. 185 Device Endpoint: 186 The authorization server's endpoint capable of issuing 187 verification codes, user codes, and verification URLs. 189 Device Verification Code: 190 A short-lived token representing an authorization session. 192 End-User Verification Code: 193 A short-lived token which the device displays to the end user, is 194 entered by the end-user on the authorization server, and is thus 195 used to bind the device to the end-user. 197 3. Protocol 199 3.1. Device Authorization Request 201 The client initiates the flow by requesting a set of verification 202 codes from the authorization server by making an HTTP "POST" request 203 to the device endpoint. The client constructs a request URI by 204 adding the following parameters to the request: 206 response_type 207 REQUIRED. The parameter value MUST be set to "device_code". 209 client_id 210 REQUIRED. The client identifier as described in Section 2.2 of 211 [RFC6749]. 213 scope 214 OPTIONAL. The scope of the access request as described by 215 Section 3.3 of [RFC6749]. 217 For example, the client makes the following HTTPS request (line 218 breaks are for display purposes only): 220 POST /token HTTP/1.1 221 Host: server.example.com 222 Content-Type: application/x-www-form-urlencoded 224 response_type=device_code&client_id=459691054427 226 3.2. Device Authorization Response 228 In response, the authorization server generates a verification code 229 and an end-user code and includes them in the HTTP response body 230 using the "application/json" format with a 200 (OK) status code. The 231 response contains the following parameters: 233 device_code 234 REQUIRED. The verification code. 236 user_code 237 REQUIRED. The end-user verification code. 239 verification_uri 240 REQUIRED. The end-user verification URI on the authorization 241 server. The URI should be short and easy to remember as end- 242 users will be asked to manually type it into their user-agent. 244 expires_in 245 OPTIONAL. The duration in seconds of the verification code 246 lifetime. 248 interval 249 OPTIONAL. The minimum amount of time in seconds that the client 250 SHOULD wait between polling requests to the token endpoint. 252 For example: 254 HTTP/1.1 200 OK 255 Content-Type: application/json 256 Cache-Control: no-store 258 { 259 "device_code":"GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8", 260 "user_code":"WDJB-MJHT", 261 "verification_uri":"https://www.example.com/device", 262 "expires_in" : 1800, 263 "interval": 5 264 } 266 3.3. User Instruction 268 After receiving a successful Authorization Response, the client 269 displays or otherwise communicates the "user_code" and the 270 "verification_uri" to the end-user, and instructs them to visit the 271 URI in a user agent on a secondary device (for example, in a browser 272 on their mobile phone), and enter the user code. 274 The end-user navigates to the "verification_uri" and authenticates 275 with the authorization server. The authorization server prompts the 276 end-user to identify the device authorization session by entering the 277 "user_code" provided by the client. The authorization server should 278 then inform the user about the action they are undertaking, and ask 279 them to approve or deny the request. Once the user interaction is 280 complete, the server informs the user to return to their device. 282 During this user interaction, the device continuously polls the token 283 endpoint with the "device_code", as detailed in Section 3.4, until 284 the user completes the interaction, the code expires, or another 285 error occurs. 287 Authorization servers supporting this specification MUST implement a 288 user interaction sequence that starts with the user navigating to 289 "verification_uri" and continues with them supplying the "user_code" 290 at some stage during the interaction. Other than that, the exact 291 sequence and implementation of the user interaction is up to the 292 authorization server, and is out of scope of this specification. 294 Devices and authorization servers MAY negotiate an alternative code 295 transmission and user interaction method in addition to the one 296 described here. Such an alternative user interaction flow could 297 obviate the need for a browser and manual input of the code, for 298 example, by using Bluetooth to transmit the code to the authorization 299 server's companion app. Such interaction methods can utilize this 300 protocol, as ultimately, the user just needs to identify the 301 authorization session to the authorization server, however user 302 interaction other than via the "verification_uri" is outside the 303 scope of this specification. 305 3.4. Device Access Token Request 307 After displaying instructions to the user, the client makes an Access 308 Token Request to the token endpoint with a "grant_type" of 309 "urn:ietf:params:oauth:grant-type:device_code". This is an extension 310 grant type (as defined by Section 4.5 of [RFC6749]) with the 311 following parameters: 313 grant_type 314 REQUIRED. Value MUST be set to "urn:ietf:params:oauth:grant- 315 type:device_code". 317 device_code 318 REQUIRED. The device verification code, "device_code" from the 319 Device Authorization Response, defined in Section 3.2. 321 client_id 322 REQUIRED, if the client is not authenticating with the 323 authorization server as described in Section 3.2.1. of [RFC6749]. 325 For example, the client makes the following HTTPS request (line 326 breaks are for display purposes only): 328 POST /token HTTP/1.1 329 Host: server.example.com 330 Content-Type: application/x-www-form-urlencoded 332 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code 333 &device_code=GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8 334 &client_id=459691054427 336 If the client was issued client credentials (or assigned other 337 authentication requirements), the client MUST authenticate with the 338 authorization server as described in Section 3.2.1 of [RFC6749]. 339 Note that there are security implications of statically distributed 340 client credentials, see Section 5.4. 342 The response to this request is defined in Section 3.5. Unlike other 343 OAuth grant types, it is expected for the client to try the Access 344 Token Request repeatedly in a polling fashion, based on the error 345 code in the response. 347 3.5. Device Access Token Response 349 If the user has approved the grant, the token endpoint responds with 350 a success response defined in Section 5.1 of [RFC6749]; otherwise it 351 responds with an error, as defined in Section 5.2 of [RFC6749]. 353 In addition to the error codes defined in Section 5.2 of [RFC6749], 354 the following error codes are specific for the device flow: 356 authorization_pending 357 The authorization request is still pending as the end-user hasn't 358 yet completed the user interaction steps (Section 3.3). The 359 client should repeat the Access Token Request to the token 360 endpoint. 362 slow_down 363 The client is polling too quickly and should back off at a 364 reasonable rate. 366 expired_token 367 The "device_code" has expired. The client will need to make a new 368 Device Authorization Request. 370 The error codes "authorization_pending" and "slow_down" are 371 considered soft errors. The client should continue to poll the token 372 endpoint by repeating the Device Token Request (Section 3.4) when 373 receiving soft errors, increasing the time between polls if a 374 "slow_down" error is received. Other error codes are considered hard 375 errors; the client should stop polling and react accordingly, for 376 example, by displaying an error to the user. 378 The interval at which the client polls MUST NOT be more frequent than 379 the "interval" parameter returned in the Device Authorization 380 Response (see Section 3.2). 382 The assumption of this specification is that the secondary device the 383 user is authorizing the request on does not have a way to communicate 384 back to the OAuth client. Only a one-way channel is required to make 385 this flow useful in many scenarios. For example, an HTML application 386 on a TV that can only make outbound requests. If a return channel 387 were to exist for the chosen user interaction interface, then the 388 device MAY wait until notified on that channel that the user has 389 completed the action before initiating the token request. Such 390 behavior is, however, outside the scope of this specification. 392 4. Discovery Metadata 394 Support for the device flow MAY be declared in the OAuth 2.0 395 Authorization Server Metadata [I-D.ietf-oauth-discovery] with the 396 following metadata: 398 device_authorization_endpoint 399 OPTIONAL. URL of the authorization server's device authorization 400 endpoint defined in Section 3.1. 402 5. Security Considerations 403 5.1. User Code Brute Forcing 405 Since the user code is typed by the user, the entropy is typically 406 less than would be used for the device code or other OAuth bearer 407 token types. It is therefore recommended that the server rate-limit 408 user code attempts. The user code SHOULD have enough entropy that 409 when combined with rate limiting makes a brute-force attack 410 infeasible. 412 5.2. Device Trustworthiness 414 Unlike other native application OAuth 2.0 flows, the device 415 requesting the authorization is not the same as the device that the 416 user grants access from. Thus, signals from the approving user's 417 session and device are not relevant to the trustworthiness of the 418 client device. 420 5.3. Remote Phishing 422 It is possible for the device flow to be initiated on a device in an 423 attacker's possession. For example, the attacker they might send an 424 email instructing the target user to visit the verification URL and 425 enter the user code. To mitigate such an attack, it is RECOMMENDED 426 to inform the user that they are authorizing a device during the user 427 interaction step (see Section 3.3), and to confirm that the device is 428 in their possession. 430 The user code needs to have a long enough lifetime to be useable 431 (allowing the user to retrieve their secondary device, navigate to 432 the verification URI, login, etc.), but should be sufficiently short 433 to limit the usability of a code obtained for phishing. This doesn't 434 prevent a phisher presenting a fresh token, particularly in the case 435 they are interacting with the user in real time, but it does limit 436 the viability of codes sent over email or SMS. 438 5.4. Non-confidential Clients 440 Most device clients are incapable of being confidential clients, as 441 secrets that are statically included as part of an app distributed to 442 multiple users cannot be considered confidential. For such clients, 443 the recommendations of Section 5.3.1 of [RFC6819] and Section 8.9 of 444 [I-D.ietf-oauth-native-apps] apply. 446 5.5. Non-Visual Code Transmission 448 There is no requirement that the user code be displayed by the device 449 visually. Other methods of one-way communication can potentially be 450 used, such as text-to-speech audio, or Bluetooth Low Energy. To 451 mitigate an attack in which a malicious user can bootstrap their 452 credentials on a device not in their control, it is RECOMMENDED that 453 any chosen communication channel only be accessible by people in 454 close proximity. E.g., users who can see, or hear the device, or 455 within range of a short-range wireless signal. 457 6. Usability Considerations 459 This section is a non-normative discussion of usability 460 considerations. 462 6.1. User Code Recommendations 464 For many users, their nearest Internet-connected device will be their 465 mobile phone, and typically these devices offer input methods that 466 are more time consuming than a computer keyboard to change the case 467 or input numbers. To improve usability (improving entry speed, and 468 reducing retries), these limitations should be taken into account 469 when selecting the user-code character set. 471 One way to improve input speed is to restrict the character set to 472 case-insensitive A-Z characters, with no digits. These characters 473 can typically be entered on a mobile keyboard without using modifier 474 keys. Further removing the I and O characters due to potential 475 confusion with numbers results in the base-24 character set: 476 "ABCDEFGHJKLMNPQRSTUVWXYZ". Dashes or other punctuation may be 477 included for readability. 479 An example user code following this guideline, with 24^8 bits of 480 entropy, is "WDJB-MJHT". 482 The server should ignore any characters like punctuation that are not 483 in the user-code character set. Provided that the character set 484 doesn't include characters of different case, the comparison should 485 be case insensitive. 487 7. IANA Considerations 489 7.1. OAuth URI Registration 491 This specification registers the following values in the IANA "OAuth 492 URI" registry [IANA.OAuth.Parameters] established by [RFC6755]. 494 7.1.1. Registry Contents 496 o URN: urn:ietf:params:oauth:grant-type:device_code 497 o Common Name: Device flow grant type for OAuth 2.0 498 o Change controller: IESG 499 o Specification Document: Section 3.1 of [[ this specification ]] 501 7.2. OAuth Extensions Error Registration 503 This specification registers the following values in the IANA "OAuth 504 Extensions Error Registry" registry [IANA.OAuth.Parameters] 505 established by [RFC6749]. 507 7.2.1. Registry Contents 509 o Error name: authorization_pending 510 o Error usage location: Token endpoint response 511 o Related protocol extension: [[ this specification ]] 512 o Change controller: IETF 513 o Specification Document: Section 3.5 of [[ this specification ]] 515 o Error name: slow_down 516 o Error usage location: Token endpoint response 517 o Related protocol extension: [[ this specification ]] 518 o Change controller: IETF 519 o Specification Document: Section 3.5 of [[ this specification ]] 521 o Error name: expired_token 522 o Error usage location: Token endpoint response 523 o Related protocol extension: [[ this specification ]] 524 o Change controller: IETF 525 o Specification Document: Section 3.5 of [[ this specification ]] 527 7.3. OAuth 2.0 Authorization Server Metadata 529 This specification registers the following values in the IANA "OAuth 530 2.0 Authorization Server Metadata" registry [IANA.OAuth.Parameters] 531 established by [I-D.ietf-oauth-discovery]. 533 7.3.1. Registry Contents 535 o Metadata name: device_authorization_endpoint 536 o Metadata Description: The Device Authorization Endpoint. 537 o Change controller: IESG 538 o Specification Document: Section 4 of [[ this specification ]] 540 8. Normative References 542 [I-D.ietf-oauth-discovery] 543 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 544 Authorization Server Metadata", draft-ietf-oauth- 545 discovery-05 (work in progress), January 2017. 547 [I-D.ietf-oauth-native-apps] 548 Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", 549 draft-ietf-oauth-native-apps-07 (work in progress), 550 January 2017. 552 [IANA.OAuth.Parameters] 553 IANA, "OAuth Parameters", 554 . 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, 558 DOI 10.17487/RFC2119, March 1997, 559 . 561 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 562 RFC 6749, DOI 10.17487/RFC6749, October 2012, 563 . 565 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 566 for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, 567 . 569 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 570 Threat Model and Security Considerations", RFC 6819, 571 DOI 10.17487/RFC6819, January 2013, 572 . 574 Appendix A. Acknowledgements 576 The -00 version of this document was based on draft-recordon-oauth- 577 v2-device edited by David Recordon and Brent Goldman. The content of 578 that document was initially part of the OAuth 2.0 protocol 579 specification but was later removed due to the lack of sufficient 580 deployment expertise at that time. We would therefore also like to 581 thank the OAuth working group for their work on the initial content 582 of this specification through 2010. 584 The following individuals contributed ideas, feedback, and wording 585 that shaped and formed the final specification: 587 Roshni Chandrashekhar, Marius Scurtescu, Breno de Medeiros, Stein 588 Myrseth, and Simon Moffatt. 590 Appendix B. Document History 592 [[ to be removed by the RFC Editor before publication as an RFC ]] 594 -04 595 o Security & Usability sections. OAuth Discovery Metadata. 597 -03 599 o device_code is now a URN. Added IANA Considerations 601 -02 603 o Added token request & response specification. 605 -01 607 o Applied spelling and grammar corrections and added the Document 608 History appendix. 610 -00 612 o Initial working group draft based on draft-recordon-oauth- 613 v2-device. 615 Authors' Addresses 617 William Denniss 618 Google 619 1600 Amphitheatre Pkwy 620 Mountain View, CA 94043 621 USA 623 Email: wdenniss@google.com 624 URI: http://wdenniss.com/device-flow 626 John Bradley 627 Ping Identity 629 Email: ve7jtb@ve7jtb.com 630 URI: http://www.thread-safe.com/ 632 Michael B. Jones 633 Microsoft 635 Email: mbj@microsoft.com 636 URI: http://self-issued.info/ 637 Hannes Tschofenig 638 ARM Limited 639 Austria 641 Email: Hannes.Tschofenig@gmx.net 642 URI: http://www.tschofenig.priv.at