idnits 2.17.00 (12 Aug 2021) /tmp/idnits47831/draft-winterbottom-ecrit-priv-loc-00.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 7, 2012) is 3604 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) == Unused Reference: 'I-D.ietf-geopriv-deref-protocol' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'RFC4079' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'RFC5012' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'RFC5774' is defined on line 544, but no explicit reference was found in the text == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 == Outdated reference: draft-ietf-geopriv-deref-protocol has been published as RFC 6753 == Outdated reference: draft-ietf-geopriv-res-gw-lis-discovery has been published as RFC 7216 ** Downref: Normative reference to an Informational RFC: RFC 5687 ** Downref: Normative reference to an Informational RFC: RFC 6443 == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-rough-loc-04 == Outdated reference: draft-ietf-ecrit-trustworthy-location has been published as RFC 7378 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT J. Winterbottom 3 Internet-Draft CommScope 4 Intended status: Standards Track H. Tschofenig 5 Expires: January 8, 2013 Nokia Siemens Networks 6 July 7, 2012 8 Out of Jurisdiction Emergency Routing 9 draft-winterbottom-ecrit-priv-loc-00 11 Abstract 13 Some countries and regions require location information be 14 constrained to emergency service applications and do not permit 15 location information to traverse the end-point at all. This document 16 describes the requirements of these countries and provides a solution 17 based on an extension to the HELD location protocol. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 8, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5 56 4. Key Observations . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Available Building Blocks . . . . . . . . . . . . . . . . . . 7 58 6. The Missing Link . . . . . . . . . . . . . . . . . . . . . . . 8 59 6.1. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 9 60 6.2. Domain Breakdown . . . . . . . . . . . . . . . . . . . . . 10 61 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 64 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 67 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 70 1. Introduction and Motivation 72 The Internet emergency calling architecture specified in 73 [I-D.ietf-ecrit-phonebcp] describes two main models for emergency 74 call processing. The first is a device-centric model, where a device 75 obtains location information using a location configuration protocol, 76 such a HELD [RFC5985], and then proceeds to determine the address of 77 the next hop closer to the local PSAP using LoST [RFC5222]. Figure 1 78 shows this model in a simplified form. 80 +---Location Request---+ 81 | (1) | 82 +---+----+ +---V---+ 83 | |<--Location--| LIS | 84 | Caller | (2) +-------+ +--------+ 85 | | | ESRP/ | 86 | |----Find Service-------+ | PSAP | 87 +------^-+ (3) | +--------+ 88 | | +--------V----+ ^ 89 | +-----Service----| LoST Server | | 90 | (4) +-------------+ +---+---+ 91 +-------------Call Initiation------------>| VSP | 92 (5) +-------+ 94 Figure 1: Device-Centric Emergency Services Model 96 With the ever increasing deployment of smart phones and tablet 97 devices a variation of the device-centric model is the ability to use 98 location available to the device for routing and then consult a LIS 99 when location is needed for dispatch. Location can come in various 100 forms to the device, e.g., from GPS, third party location databases, 101 as well as IP-to-geolocation services. 103 The second approach is a softswitch-centric model, where a device 104 initiates and emergency call and the serving softswitch detects that 105 the call is an emergency and initiates retrieving the caller's 106 location from a Location Information Server (LIS) using HELD 107 [RFC5985] with identity extensions [RFC6155] and then determining the 108 route to the local PSAP using LoST [RFC5222]. Figure 2 shows the 109 high-level protocol interactions. 111 +---Location Request---+ 112 | (2) | 113 +---V---+ | 114 | LIS | | 115 +----+--+ +----+----+ 116 | | | 117 +----Location--->| Soft | 118 +--------+ (3) | Switch | 119 | Caller |------Call Initiation------------> | | 120 +--------+ (1) +-+-^---+-+ 121 +-------------+ | | | 122 | LoST Server |<-Find Service--+ | | 123 +------+------+ (4) | | 124 | | | 125 +----------Service--------+ | 126 (5) | 127 +-----------+ | 128 | ESRP/PSAP |<------Call----+ 129 +-----------+ (6) 131 Figure 2: Softswitch-Centric Calling Model 133 In the softswitch-centric model when a VSP receives an emergency call 134 it will encounter several difficulties. The first hurdle is for the 135 VSP to determine the correct LIS to ask for location information. 136 Having obtained the location, the VSP must then determine the correct 137 PSAP using a LoST server and this requires wide-spread deployment of 138 forest guides. This leads to a failure in the softswitch-centric 139 approach to deliver emergency calls correctly because the VSP is 140 unable to determine the correct PSAP to route the call to. The 141 softswitch-centric model should therefore seen only as a transition 142 architecture towards the end-device model where end devices have not 143 been upgraded. Software updates of end devices are, however, not a 144 problem anymore since software updates have to be provided to end 145 devices on a regular basis to patch security vulnerabilities. Any 146 service provider that does not have an ability to update devices will 147 not only put their own customers at risk but also other Internet 148 users as well since those can become the victims of attacks as well. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443]. 158 The term "Access Network Provider" is used as defined in [RFC5687] 159 and incompasses both the Internet Access Provider (IAP) and Internet 160 Service Provider (ISP). 162 3. Problem Description 164 There is a significant faction in the emergency services and the 165 regulatory community that do not want to rely on emergency calls 166 solutions with end-device provided location. This includes location 167 information that is determined by the network but subsequently 168 traverses the end-point prior to being delivered to the emergency 169 organization. 171 There are two concerns: 173 Security: One concern is about the possibility of the software of 174 the end device being able to tamper with location. This can lead 175 to denial of service attacks against the emergency services 176 infrastructure. [I-D.ietf-ecrit-trustworthy-location] describes 177 these concerns in detail. 179 Privacy: There is the desire to allow location information to be 180 provided to emergency organizations rather than any other party, 181 including the end device or a VSP. In the softswitch model the 182 VSP would have to ask the access provider for location 183 information. However, the number of VSPs asking for location 184 information could, at least in theory depending on the scope of 185 emergency services regulation be very large and is likely to 186 include VSPs that are located in a jurisdiction that is different 187 from the one of the access network provider. Allowing VSPs to ask 188 for location information of end devices at access network 189 providers in a third party fashion without the ability to present 190 the user's consent or the emergency service nature calls for 191 privacy problems. [RFC6155] discusses some of these privacy 192 challenges as part of the third party requests. 194 These arguments may, however, also jacked into place to hide another 195 reason, namely the desire to create an artifical relationship between 196 the VSP and the access network provider. [RFC6444] provides a 197 problem description and [I-D.ietf-ecrit-rough-loc] even offers a 198 solution based on rough location. This solutions, however, requires 199 the access network provider to compute these rough location shapes. 200 Countries that have a large number of PSAPs and neither an ESRP nor a 201 stage-1 PSAP architecture may encounter problems computing these 202 shapes. 204 The Internet calling model does not constrain the call to a single 205 jurisdictional boundary nor does it assume that the Voice Service 206 provider (VSP) role is provided by the access provider. This allows 207 the VSP to be located anywhere on the Internet without requiring any 208 association with Internet access providers. 210 +----------------+ +----------------+ +----------------+ 211 | Jurisdiction 1 | | Jurisdiction 2 | | Jurisdiction 3 | 212 | | | | | | 213 | | | | | | 214 | +--------------+--+----------------+--+--------------+ | 215 | | EMERGENCY CALL CENTRES | | 216 | +--------------+--+----------------+--+--------------+ | 217 | ^ ^ ^ | | | | | 218 | | | | | | | | | 219 | +-----+ | | | | +-----+ | | +-----+ | 220 | | VSP | | +--------| VSP | | | | VSP | | 221 | +--^--+ | | | +---^-+ | | +-----+ | 222 | | | | | | | | | 223 | +--------+-----+--+-------+--------+--+--------------+ | 224 | | | | | INTERNET | | 225 | +--------+-----+--+-----+----------+--+--------------+ | 226 | | | | | | | | | 227 | +--------+-----+--+-------+--------+--+--------------+ | 228 | | | | ACCESS | NETWORKS | | 229 | +--------------+--+-------+--------+--+--------------+ | 230 | | | | | | | | | 231 | | | +-------------+ | | | 232 | | | | | | | | | 233 | +------------+ | | | | | 234 | | EMERGENCY | | | | | | 235 | | CALLS | | | | | | 236 | +------------+ | | | | | 237 | +--------+-----+--+-----+----------+--+--------------+ | 238 | | | | DEVICES | | 239 | +--------------+--+-----+----------+--+--------------+ | 240 | | | | | | 241 +----------------+ +----------------+ +----------------+ 242 e.g US State e.g. Australia e.g. European 243 Country 245 Figure 3: Internet Calling Models 247 4. Key Observations 249 When these security and privacy requirements are taken into 250 consideration then the emergency calling architecture and associated 251 procedures described in [I-D.ietf-ecrit-phonebcp] and [RFC6443] 252 require some adaptation in some configurations to ensure universal 253 operation. The softswitch model fails to meet the privacy 254 requirements and the end-device model has to wrangle with security 255 challenges. 257 Several observations have been posed thus far: 259 Problem#1: Rough location information is required to route emergency 260 calls. 262 Problem#2: The VSP needs the ability to determine the correct LIS to 263 retrieve location information. 265 Problem#3: The VSP needs the ability to contact a LoST server to 266 acquire routing information from. 268 Problem#4: The end host does not acquire or convey location to the 269 emergency network. 271 Problem#5: Access network provider aim to provide location only to 272 emergency service authorities. 274 Problem#6: Precise location information is required to dispatch 275 first responders. 277 5. Available Building Blocks 279 To fulfill A number of building blocks are already available. There 280 is no need to start from a clean sheet. 282 Location: Location standards have existed for mobile cellular 283 networks since the mid to late 1990s, and location standards for 284 the Internet have existed since the mid to late 2000s. The exact 285 determination techniques for each access technology are different 286 but the ability to direct communications across a communications 287 network is inherenetly premised on being able to reach a specific 288 device and this requires some knowledge of where the device is 289 physically located. The term Location Information Server (LIS) is 290 used to identify the element in an access network responsible for 291 providing the location of a device in its administrative domain. 292 LIS service discovery techniques are described in [RFC5986] and 293 [I-D.ietf-geopriv-res-gw-lis-discovery]. 295 Call Routing: The LoST protocol [RFC5222] specifies a means to map 296 location and service information into a destination URI. Next 297 generation emergency services architectures and procedures, such 298 as those defined in [RFC6443], NENA i3, and the EENA NG112 299 document, use LoST for providing routing to local emergency 300 service authorities. LoST servers are discovered using DNS 301 U-NAPTR [RFC4848] to obtain a service URI. The discovered LoST 302 server services the domain in which the device is resident, or is 303 able to provide the identity of a LoST server that can service the 304 request. A access network provider that operates in an area 305 capable of receiving next generation emergency calls is able to 306 include a U-NAPTR record in their DNS servers that identifies the 307 local serving LoST server able to resolve emergency routing 308 requests. 310 LIS Discovery: [I-D.ietf-geopriv-res-gw-lis-discovery] provides a 311 means for discovering a LIS based on the IP address of a device 312 and this could be used in conjunction with [RFC6155] to provide a 313 solution to problem 2. The domain name discovered for the LIS 314 could be reused to discover the correct LoST server to contact 315 thereby solving problem 3. 317 6. The Missing Link 319 Problem 5 does not allow the LIS to provide location information 320 except to emergency authorities, and while the HELD protocol 321 [RFC5985] does allow a location URI to be returned to the requesting 322 entitiy, the LoST protocol [RFC5222] requires a location value and 323 does not support a location reference. 325 One possible solution to problem 5 is to extend LoST to support a 326 location URI in the findService request method. In this case a VSP 327 would detect that a device was making an emergency call, determine 328 the correct LIS to contact using 329 [I-D.ietf-geopriv-res-gw-lis-discovery], contact the LIS using HELD 330 [RFC5985] using the IP address of the calling device as an identity 331 extension [RFC6155] and the LIS would respond with a location URI 332 that requires client-side authentication for dereferencing Using the 333 LIS domain identifier the VSP would then determine the correct LoST 334 server and request emergency services using the location URI as the 335 location reference. The LoST server must have permission to 336 dereference the location URI, if any form of recurision is 337 encountered then the URI must be dereferenced multiple times 338 increasing the likelihood of failure. 340 An alternative approach is to leave LoST unchanged, but extend the 341 HELD protocol and requirements of the local LIS. In this solution, 342 when the LIS receives the third-party request, it performs the 343 necessary LoST request using the location of the device. The LIS 344 responds with a location URI and the destination URI of the correct 345 emergency service authority. The Location URI will only yield 346 location information to the authorized emergency authority. This 347 solution addresses problem 1 problem 3, problem 4, problem 5. 348 Problem 2 is solved using a combination of 349 [I-D.ietf-geopriv-res-gw-lis-discovery] and HELD with identity 350 extensions. 352 6.1. Call Flow 354 1. Device initiates an emergency call to home VSP 356 2. Home VSP detects emergency call and uses IP address to determine 357 the correct LIS to query using 358 [I-D.ietf-geopriv-res-gw-lis-discovery]. 360 3. Home VSP queries the LIS using HELD and the IP address of the 361 calling device as an identity extension. 363 4. The LIS determines the location and uses it request routing 364 information for the local LoST server. 366 5. The LIS return a location URI and the local Emergency Service 367 Routing Proxy (ESRP) URI to the home VSP. 369 6. The VSP follows the guidance from [I-D.ietf-ecrit-phonebcp] and 370 routes the call to the ESRP. 372 7. The ESRP authenticates itself with the LIS when it dereferences 373 the location URI. 375 8. The returns location information to the ESRP allowing it route 376 the call to the correct PSAP. 378 +------(2)Find LIS-----+ 379 | | 380 +---V---+ | 381 | DNS | | 382 +----+--+ +----+---------+ 383 | | | 384 +----LIS URI---->| Home | 385 +--------+ | VSP | 386 | Caller |------(1)-Call Initiation--------> | | 387 +--------+ +-+--^-------+-+ 388 | | | 389 +-------------+ | | | 390 | |<------(3)-locationReq(IP)-------+ | | 391 | LIS | | | 392 | |--(5)-locationResp(locURI,EcrfURI)--+ | 393 +-+--^---+--^-+ | 394 | | | | +-------------+ | 395 | | | +-----Service----+ | | 396 | | | | LoST Server | | 397 | | +-(4)-Find Service->| | | 398 | | +-------------+ | 399 | | | 400 | | +-----------+ | 401 | +--(7)-locReq(Auth)--+ | | 402 | | ESRP/PSAP |<--(6)-Call(locURI)-+ 403 +---(8)-locResp(Loc)--->| | 404 +-----------+ 406 Figure 4: Modified Softswitch-Centric Emergency Call Flow 408 6.2. Domain Breakdown 410 The key advantage of the call flow show in Section 6.1 is that it 411 separates the entities into two clear groups, those that are inside 412 the regulatory emergency jurisdiction and those that are in the 413 Internet. This is evident in Figure 5. 415 +------(2)Find LIS-----+ 416 | | 417 +---V---+ | 418 | DNS | | 419 +----+--+ +----+---------------+ 420 | | | 421 +----LIS URI---->| Home | 422 | VSP | 423 | | 424 +-^---+----^-------+-+ 425 I N T E R N E T | | | | 426 =========================================|===|====|=======|=== 427 LOCAL JURISDICTION | | | | 428 +--------+ | | | | 429 | Caller |------(1)-Call Initiation------+ | | | 430 +--------+ | | | 431 | | | 432 +-------------+ | | | 433 | |<------(3)-locationReq(IP)-----+ | | 434 | LIS | | | 435 | |--(5)-locationResp(locURI,EcrfURI)--+ | 436 +-+--^---+--^-+ | 437 | | | | +-------------+ | 438 | | | +-----Service----+ | | 439 | | | | LoST Server | | 440 | | +-(4)-Find Service->| | | 441 | | +-------------+ | 442 | | | 443 | | +-----------+ | 444 | +--(7)-locReq(Auth)--+ | | 445 | | ESRP/PSAP |<--(6)-Call(locURI)-+ 446 +---(8)-locResp(Loc)--->| | 447 +-----------+ 449 Figure 5: Emergency Call Domains 451 7. Privacy Considerations 453 [[TBD.]] 455 8. Security Considerations 457 [[TBD.]] 459 9. IANA Considerations 461 [[TBD.]] 463 10. Acknowledgements 465 We would like to thank Wilfried Lange for sharing his views with us. 467 11. References 469 11.1. Normative References 471 [I-D.ietf-ecrit-phonebcp] 472 Rosen, B. and J. Polk, "Best Current Practice for 473 Communications Services in support of Emergency Calling", 474 draft-ietf-ecrit-phonebcp-20 (work in progress), 475 September 2011. 477 [I-D.ietf-geopriv-deref-protocol] 478 Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M. 479 Thomson, "A Location Dereferencing Protocol Using HELD", 480 draft-ietf-geopriv-deref-protocol-05 (work in progress), 481 May 2012. 483 [I-D.ietf-geopriv-res-gw-lis-discovery] 484 Thomson, M. and R. Bellis, "Location Information Server 485 (LIS) Discovery using IP address and Reverse DNS", 486 draft-ietf-geopriv-res-gw-lis-discovery-03 (work in 487 progress), March 2012. 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, March 1997. 492 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 493 Tschofenig, "LoST: A Location-to-Service Translation 494 Protocol", RFC 5222, August 2008. 496 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 497 Location Configuration Protocol: Problem Statement and 498 Requirements", RFC 5687, March 2010. 500 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 501 RFC 5985, September 2010. 503 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 504 Location Information Server (LIS)", RFC 5986, 505 September 2010. 507 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 508 Barnes, "Use of Device Identity in HTTP-Enabled Location 509 Delivery (HELD)", RFC 6155, March 2011. 511 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 512 "Framework for Emergency Calling Using Internet 513 Multimedia", RFC 6443, December 2011. 515 11.2. Informative References 517 [I-D.ietf-ecrit-rough-loc] 518 Barnes, R. and M. Lepinski, "Using Imprecise Location for 519 Emergency Context Resolution", 520 draft-ietf-ecrit-rough-loc-04 (work in progress), 521 March 2011. 523 [I-D.ietf-ecrit-trustworthy-location] 524 Tschofenig, H., Schulzrinne, H., and B. Aboba, 525 "Trustworthy Location Information", 526 draft-ietf-ecrit-trustworthy-location-03 (work in 527 progress), April 2012. 529 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 530 10646", STD 63, RFC 3629, November 2003. 532 [RFC4079] Peterson, J., "A Presence Architecture for the 533 Distribution of GEOPRIV Location Objects", RFC 4079, 534 July 2005. 536 [RFC4848] Daigle, L., "Domain-Based Application Service Location 537 Using URIs and the Dynamic Delegation Discovery Service 538 (DDDS)", RFC 4848, April 2007. 540 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 541 Emergency Context Resolution with Internet Technologies", 542 RFC 5012, January 2008. 544 [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic 545 Addresses in the Presence Information Data Format Location 546 Object (PIDF-LO): Guidelines and IANA Registry 547 Definition", BCP 154, RFC 5774, March 2010. 549 [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and 550 A. Kuett, "Location Hiding: Problem Statement and 551 Requirements", RFC 6444, January 2012. 553 Authors' Addresses 555 James Winterbottom 556 CommScope 557 Suit 1, Level 2 558 iC Enterprise 1, Innovation Campus 559 Squires Way 560 North Wollongong, NSW 2500 561 AU 563 Phone: +61 242 212938 564 Email: james.winterbottom@commscope.com 566 Hannes Tschofenig 567 Nokia Siemens Networks 568 Linnoitustie 6 569 Espoo 02600 570 Finland 572 Phone: +358 (50) 4871445 573 Email: Hannes.Tschofenig@gmx.net 574 URI: http://www.tschofenig.priv.at