idnits 2.17.1 draft-ietf-oauth-resource-indicators-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 date (October 19, 2018) is 2015 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 (-34) exists of draft-ietf-oauth-jwsreq-16 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group B. Campbell 3 Internet-Draft Ping Identity 4 Intended status: Standards Track J. Bradley 5 Expires: April 22, 2019 Yubico 6 H. Tschofenig 7 Arm Limited 8 October 19, 2018 10 Resource Indicators for OAuth 2.0 11 draft-ietf-oauth-resource-indicators-01 13 Abstract 15 An extension to the OAuth 2.0 Authorization Framework defining 16 request parameters that enable a client to explicitly signal to an 17 authorization server about the location of the protected resource(s) 18 to which it is requesting access. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 22, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Resource Parameter . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Authorization Request . . . . . . . . . . . . . . . . . . 5 59 2.2. Access Token Request . . . . . . . . . . . . . . . . . . 6 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 4.1. OAuth Parameters Registration . . . . . . . . . . . . . . 10 63 4.2. OAuth Extensions Error Registration . . . . . . . . . . . 10 64 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.1. Normative References . . . . . . . . . . . . . . . . . . 10 66 5.2. Informative References . . . . . . . . . . . . . . . . . 11 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 68 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 Several years of deployment and implementation experience with The 74 OAuth 2.0 Authorization Framework [RFC6749] has uncovered a need, in 75 some circumstances, for the client to explicitly signal to the 76 authorization server where it intends to use the access token it is 77 requesting. 79 Knowing the protected resource (a.k.a. resource server, application, 80 API, etc.) that will process the access token enables the 81 authorization server to construct the token as necessary for that 82 entity. Properly encrypting the token (or content within the token) 83 to a particular resource, for example, requires knowing which 84 resource will receive and decrypt the token. Furthermore, various 85 resources oftentimes have different requirements with respect to the 86 data contained in, or referenced by, the token and knowing the 87 resource where the client intends to use the token allows the the 88 authorization server to mint the token accordingly. 90 Specific knowledge of the intended recipient(s) of the access token 91 also helps facilitate improved security characteristics of the token 92 itself. Bearer tokens, currently the most commonly utilized type of 93 OAuth access token, allow any party in possession of a token to get 94 access to the associated resources. To prevent misuse, several 95 important security assumptions must hold, one of which is that an 96 access token must only be valid for use at a specific protected 97 resource and for a specific scope of access. Section 5.2 of 98 [RFC6750], for example, prescribes including the token's intended 99 recipients within the token to prevent token redirect. When the 100 authorization server is informed of the resource that will process 101 the access token, it can restrict the intended audience of that token 102 to the given resource such that the token cannot be used successfully 103 at other resources. 105 OAuth scope, from Section 3.3 of [RFC6749], is sometimes overloaded 106 to convey the location or identity of the protected resource, 107 however, doing so isn't always feasible or desirable. Scope is 108 typically about what access is being requested rather than where that 109 access will be redeemed (e.g. "email", "admin:org", "user_photos", 110 "channels:read", and "channels:write" are a small sample of scope 111 values in use in the wild that convey only the type of access and not 112 the location). 114 In some circumstances and for some deployments, a means for the 115 client to signal to the authorization server where it intends to use 116 the access token it's requesting is important and useful. A number 117 of implementations and deployments of OAuth 2.0 have already employed 118 proprietary parameters toward that end. Going forward, this 119 specification aspires to provide a standardized and interoperable 120 alternative to the proprietary approaches. 122 1.1. Requirements Notation and Conventions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 1.2. Terminology 132 This specification uses the terms "access token", "refresh token", 133 "authorization server", "resource server", "authorization endpoint", 134 "authorization request", "authorization response", "token endpoint", 135 "grant type", "access token request", "access token response", and 136 "client" defined by The OAuth 2.0 Authorization Framework [RFC6749]. 138 2. Resource Parameter 140 In requests to the authorization server, a client MAY indicate the 141 protected resource (a.k.a. resource server, application, API, etc.) 142 to which it is requesting access by including the following parameter 143 in the request. 145 resource 146 Indicates the location of the target service or resource where 147 access is being requested. Its value MUST be an absolute URI, as 148 specified by Section 4.3 of [RFC3986], which MAY include a query 149 component but MUST NOT include a fragment component. Multiple 150 "resource" parameters MAY be used to indicate that the requested 151 token is intended to be used at multiple resources. 153 The parameter value indicates the location of a protected resource, 154 typically as an https URL, where the client is requesting access. 155 This enables the authorization server to apply policy as appropriate 156 for the resource, such as determining the type and content of tokens 157 to be issued, if and how tokens are encrypted, and applying 158 appropriate audience restrictions. 160 The client SHOULD provide the most specific URI that it can for the 161 complete API or set of resources it intends to access. In practice a 162 client will know a base URI for the application or resource that it 163 interacts with, which is appropriate to use as the value of the 164 "resource" parameter. The client SHOULD use the base URI of the API 165 as the "resource" parameter value unless specific knowledge of the 166 resource dictates otherwise. For example, the value 167 "https://api.example.com/" would be used for a resource that is the 168 exclusive application on that host, however, if the resource is one 169 of many applications on that host, something like 170 "https://api.example.com/app/" would be used as a more specific 171 value. Another example, for an API like SCIM [RFC7644] that has 172 multiple endpoints such as "https://apps.example.com/scim/Users", 173 "https://apps.example.com/scim/Groups", and 174 "https://apps.example.com/scim/Schemas" The client would use 175 "https://apps.example.com/scim/" as the resource so that the issued 176 access token is valid for all the endpoints of the SCIM API. 178 The following error code is provided for an authorization server to 179 indicate problems with the requested resource(s) in response to an 180 authorization request or access token request. And can also be used 181 to inform the client that it has requested an invalid combination of 182 resource and scope. 184 invalid_target 185 The requested resource is invalid, unknown, or malformed. 187 The authorization server SHOULD audience restrict issued access 188 tokens to the resource(s) indicated by the "resource" parameter. 189 Audience restrictions can be communicated in JSON Web Tokens 190 [RFC7519] with the "aud" claim and the top-level member of the same 191 name provides the audience restriction information in a Token 192 Introspection [RFC7662] response. The authorization server may use 193 the exact "resource" value as the audience or it may map from that 194 value to a more general URI or abstract identifier for the given 195 resource. 197 2.1. Authorization Request 199 When the "resource" parameter is used in an authorization request to 200 the authorization endpoint, it indicates the location of the 201 protected resource(s) to which access is being requested. When an 202 access token will be returned directly from the authorization 203 endpoint via the implicit flow (Section 4.2 of OAuth 2.0 [RFC6749]), 204 the requested resource is applicable to that access token. In the 205 code flow (Section 4.1 of OAuth 2.0 [RFC6749]) where an an 206 intermediate representation of the authorization grant (the 207 authorization code) is returned from the authorization endpoint, the 208 requested resource is applicable to the full authorization grant. 210 For authorization requests sent as a JWTs, such as when using JWT 211 Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single 212 "resource" parameter value is represented as a JSON string while 213 multiple values are represented as an array of strings. 215 If the client omits the "resource" parameter when requesting 216 authorization, the authorization server MAY process the request with 217 no specific resource or by using a pre-defined default resource 218 value. Alternatively, the authorization server MAY require clients 219 to specify the resource(s) they intend to access and MAY fail 220 requests that omit the parameter with an "invalid_target" error. The 221 authorization server might use this data to inform the user about the 222 resources the client is going to access on her behalf, to meet policy 223 decision (e.g. refuse the request due to unknown resources), and 224 determine the set of resources that can be used in subsequent access 225 token requests. 227 If the authorization server fails to parse the provided value(s) or 228 does not consider the resource(s) acceptable, it should reject the 229 request with an an error response using the error code 230 "invalid_target" as the value of the "error" parameter and can 231 provide additional information regarding the reasons for the error 232 using the "error_description" and/or "error_uri" parameters. 234 An example of an authorization request where the client tells the 235 authorization server that it wants an access token for use at 236 "https://api.example.com/app/" is shown in Figure 1 below (extra line 237 breaks and indentation are for display purposes only). 239 GET /as/authorization.oauth2?response_type=token 240 &client_id=example-client 241 &state=XzZaJlcwYew1u0QBrRv_Gw 242 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb 243 &resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1 244 Host: authorization-server.example.com 246 Figure 1: Implicit Flow Authorization Request 248 Below in Figure 2 is an example of an authorization request using the 249 "code" response type where the the client is requesting access to the 250 resource owner's contacts and calendar data at 251 "https://cal.example.com/" and "https://contacts.example.com/" (extra 252 line breaks and indentation are for display purposes only). 254 GET /as/authorization.oauth2?response_type=code 255 &client_id=s6BhdRkqt3 256 &state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI 257 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb 258 &scope=calendar%20contacts 259 &resource=https%3A%2F%2Fcal.example.com%2F 260 &resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1 261 Host: authorization-server.example.com 263 Figure 2: Code Flow Authorization Request 265 2.2. Access Token Request 267 When the "resource" parameter is used on an access token request made 268 to the token endpoint, for all grant types, it indicates the location 269 of the target service or protected resource where the client intends 270 to use the requested access token. 272 The resource value(s) that are acceptable to an authorization server 273 in fulfilling an access token request are at its sole discretion 274 based on local policy or configuration. In the case of a 275 "refresh_token" or "authorization_code" grant type request, such 276 policy may limit the acceptable resources to those that were 277 originally granted by the resource owner or a subset thereof. In the 278 "authorization_code" case where the requested resources are a subset 279 of the set of resources originally granted, the authorization server 280 will issue an access token based on that subset of requested 281 resources while any refresh token that is returned is bound to the 282 full original grant. 284 When requesting a token, the client can indicate the desired target 285 service(s) where it intends to use that token by way of the 286 "resource" parameter and can indicate the desired scope of the 287 requested token using the "scope" parameter. The semantics of such a 288 request are that the client is asking for a token with the requested 289 scope that is usable at all the requested target services. 290 Effectively, the requested access rights of the token are the 291 cartesian product of all the scopes at all the target services. To 292 the extent possible, when issuing access tokens, the authorization 293 server should adapt the scope value associated with an access token 294 to the value the respective resource is able to process and needs to 295 know. This further improves privacy as scope values give an 296 indication of what services the resource owner uses and it improves 297 security as scope values may contain confidential data. As specified 298 in Section 5.1 of [RFC6749], the authorization server must indicate 299 the access token's effective scope to the client in the "scope" 300 response parameter value when it differs from the scope requested by 301 the client. 303 Following from the code flow authorization request shown in Figure 2, 304 the below examples show an "authorization_code" grant type access 305 token request and response where the client tells the authorization 306 server that it wants the access token for use at 307 "https://cal.example.com/" (extra line breaks and indentation are for 308 display purposes only). 310 POST /as/token.oauth2 HTTP/1.1 311 Host: authorization-server.example.com 312 Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ 313 Content-Type: application/x-www-form-urlencoded 315 grant_type=authorization_code 316 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb 317 &code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ 318 &resource=https%3A%2F%2Fcal.example.com%2F 320 Figure 3: Access Token Request 322 HTTP/1.1 200 OK 323 Content-Type: application/json 324 Cache-Control: no-cache, no-store 326 { 327 "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi 328 JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI 329 iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgwMCwic2NvcGUiOiJjYWxlbmRhciIs 330 ImF1ZCI6Imh0dHBzOi8vY2FsLmV4YW1wbGUuY29tLyJ9.nNWJ2dXSxaDRdMUK 331 lzs-cYIj8MDoM6Gy7pf_sKrLGsAFf1C2bDhB60DQfW1DZL5npdko1_Mmk5sUf 332 zkiQNVpYw", 333 "token_type":"Bearer", 334 "expires_in":3600, 335 "refresh_token":"4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2", 336 "scope":"calendar" 337 } 339 Figure 4: Access Token Response 341 A subsequent access token request, using the refresh token, where the 342 client tells the authorization server that it wants an access token 343 for use at "https://contacts.example.com/" is shown in Figure 5 below 344 with the response shown in Figure 6 (extra line breaks and 345 indentation are for display purposes only). 347 POST /as/token.oauth2 HTTP/1.1 348 Host: authorization-server.example.com 349 Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ 350 Content-Type: application/x-www-form-urlencoded 352 grant_type=refresh_token 353 &refresh_token=4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2 354 &resource=https%3A%2F%2Fcontacts.example.com%2Fapp%2F 356 Figure 5: Access Token Request 358 HTTP/1.1 200 OK 359 Content-Type: application/json 360 Cache-Control: no-cache, no-store 362 { 363 "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi 364 JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI 365 iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs 366 ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc 367 OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH 368 UowfmtNaA5EikYAw", 369 "token_type":"Bearer", 370 "expires_in":3600, 371 "scope":"contacts" 372 } 374 Figure 6: Access Token Response 376 3. Security Considerations 378 An access token that is audience restricted to a protected resource 379 that obtains that token legitimately cannot be used to access 380 resources on behalf of the resource owner at other protected 381 resources. The "resource" parameter enables a client to indicate the 382 protected resources where the requested access token will be used, 383 which in turn enables the authorization server to apply the 384 appropriate audience restrictions to the token. 386 Some servers may host user content or be multi-tenant. In order to 387 avoid attacks that might confuse a client into sending an access 388 token to a resource that is user controlled or is owned by a 389 different tenant, it is important to use a specific resource URI 390 including a path component. This will cause any access token issued 391 for accessing the user controlled resource to have a invalid audience 392 if replayed against the legitimate resource API. 394 Although multiple occurrences of the "resource" parameter may be 395 included in a request, using only a single "resource" parameter is 396 encouraged. A bearer token that has multiple intended recipients 397 (audiences) can be used by any one of those recipients at any other. 398 Thus, a high degree of trust between the involved parties is needed 399 when using access tokens with multiple audiences. Furthermore an 400 authorization server may be unwilling or unable to fulfill a token 401 request with multiple resources. 403 4. IANA Considerations 405 4.1. OAuth Parameters Registration 407 This specification registers the following value in the IANA "OAuth 408 Parameters" registry [IANA.OAuth.Parameters] established by 409 [RFC6749]. 411 o Parameter name: resource 412 o Parameter usage location: authorization request, token request 413 [[TODO: draft-ietf-oauth-token-exchange will have already 414 registered this for 'token request' and this draft has a more 415 generalized usage and needs to somehow either update that 416 registration or do a partial registration and reference]] 417 o Change controller: IESG 418 o Specification document(s): [[ this specification ]] 420 4.2. OAuth Extensions Error Registration 422 This specification registers the following error in the IANA "OAuth 423 Extensions Error Registry" [IANA.OAuth.Parameters] established by 424 [RFC6749]. 426 o Error name: invalid_target 427 o Error usage location: implicit grant error response, token error 428 response [[TODO: draft-ietf-oauth-token-exchange will have already 429 registered this for 'token error response' and this draft has a 430 more generalized usage and needs to somehow either update that 431 registration or do a partial registration and reference]] 432 o Related protocol extension: resource parameter 433 o Change controller: IESG 434 o Specification document(s): [[ this specification ]] 436 5. References 438 5.1. Normative References 440 [IANA.OAuth.Parameters] 441 IANA, "OAuth Parameters", 442 . 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, 446 DOI 10.17487/RFC2119, March 1997, 447 . 449 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 450 Resource Identifier (URI): Generic Syntax", STD 66, 451 RFC 3986, DOI 10.17487/RFC3986, January 2005, 452 . 454 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 455 RFC 6749, DOI 10.17487/RFC6749, October 2012, 456 . 458 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 459 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 460 May 2017, . 462 5.2. Informative References 464 [I-D.ietf-oauth-jwsreq] 465 Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization 466 Framework: JWT Secured Authorization Request (JAR)", 467 draft-ietf-oauth-jwsreq-16 (work in progress), April 2018. 469 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 470 Framework: Bearer Token Usage", RFC 6750, 471 DOI 10.17487/RFC6750, October 2012, 472 . 474 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 475 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 476 . 478 [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., 479 and C. Mortimore, "System for Cross-domain Identity 480 Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, 481 September 2015, . 483 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 484 RFC 7662, DOI 10.17487/RFC7662, October 2015, 485 . 487 Appendix A. Acknowledgements 489 This specification was developed within the OAuth Working Group under 490 the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with 491 Eric Rescorla and Benjamin Kaduk serving as Security Area Directors. 492 Additionally, the following individuals contributed ideas, feedback, 493 and wording that helped shape this specification: 495 Sergey Beryozkin, William Denniss, Vladimir Dzhuvinov, George 496 Fletcher, Dick Hardt, Phil Hunt, Michael Jones, Torsten Lodderstedt, 497 Anthony Nadalin, Justin Richer, Nat Sakimura, Filip Skokan, and Hans 498 Zandbelt. 500 Appendix B. Document History 502 [[ to be removed by the RFC Editor before publication as an RFC ]] 504 draft-ietf-oauth-resource-indicators-01 506 o Significant rework of the main section of the document attempting 507 to clarify a number of things that came up at, around and after 508 IETF 102 and the call for adoption. 509 o Change the "invalid_resource" error to "invalid_target" to align 510 with draft-ietf-oauth-token-exchange, which has some overlap in 511 functionality. 512 o Allow the "resource" parameter value to have a query component 513 (aligning with draft-ietf-oauth-token-exchange). 514 o Moved the Security Considerations section to before the IANA 515 Considerations. 516 o Other editorial updates. 517 o Rework the Acknowledgements section. 518 o Use RFC 8174 boilerplate. 520 draft-ietf-oauth-resource-indicators-00 522 o First version of the working group document. A replica of draft- 523 campbell-oauth-resource-indicators-02. 525 draft-campbell-oauth-resource-indicators-02 527 o No changes. 529 draft-campbell-oauth-resource-indicators-01 531 o Move Hannes Tschofenig, who wrote https://tools.ietf.org/html/ 532 draft-tschofenig-oauth-audience in '13, from Acknowledgements to 533 Authors. 534 o Added IANA Considerations to register the "resource" parameter and 535 "invalid_resource" error code. 537 draft-campbell-oauth-resource-indicators-00 539 o Initial draft to define a resource parameter for OAuth 2.0. 541 Authors' Addresses 543 Brian Campbell 544 Ping Identity 546 Email: brian.d.campbell@gmail.com 548 John Bradley 549 Yubico 551 Email: ve7jtb@ve7jtb.com 553 Hannes Tschofenig 554 Arm Limited 556 Email: hannes.tschofenig@gmx.net