1. EAP in Unauthenticated Network Access to Emergency Services draft-schulzrinne-ecrit-unauthenticated-access-06 H. Schulzrinne, S. McCann, G. Bajko, H. Tschofenig, D. Kroeselberg IETF #76, EMU WG Dirk Kroeselberg

2. Motivation: Why Unauthenticated Emergency This is about – requesting emergency services – without a (valid) subscription: “Unauthenticated” – special handling required during network attachment Status of unauthenticated emergency (112/911) calls – substantial misuse (e.g. SIM-less calls are “convenient” to test phones) – some countries require support for this by law

3. Motivation for this Presentation In general there are two categories to consider – Application-level aspects (e.g. for VoIP) – Network-level aspects (network attachment) This presentation is about the latter: The -06 revision of the draft comes with a new section 6 with considerations for how to indicate emergency in network access Basic approaches include L2 indication, and EAP based indication Goals: – Present EAP-specific aspects – Seek feedback and additional comments by EAP experts The draft should finally give recommendations for unauthenticated access. Not clear yet what this will be for network attachment.

4. Overview Methods to indicate emergency during network attachment – L2 indications adding TLVs to wireless MAC messages switching off any L2 security over-the-air – EAP-based indications Special NAI – decorated: “{sm=2} user@realm.com” – dedicated emergency NAI: “emergency@emergency.com” Emergency EAP method – Dedicated new EAP method for emergency – Existing EAP method, but special EAP method type for emergency – Implicit indication in existing EAP method (e.g. host does not present TLS client certificate)

5. L2 considerations L2 indications – allow to handle emergency at an earlier stage of network attachment (better for prioritization) – are specific to each access technology – depend on the network architecture: link layer indications need to be distributed and translated between the different involved protocol layers and entities conclusion: hard to recommend anything in the draft

6. Considerations for EAP (1) Generic solution, no dependency on the specific access Emergency integrated into A&A procedures Still comes early in NW attachment: good for most cases, but may be late in radio overload situation Conflicts may arise in some special cases (e.g. with MAC-based filtering on L2)

7. How to best use EAP? Special NAI – decorated NAI: not a common standard – emergency NAI: conflicts with network entry procedures in some systems; creates special case compared to “authenticated” network attachment – otherwise a minimal-impact solution Emergency EAP method – Dedicated new EAP method: should be key-generating to minimize impact on network attachment procedures – Existing EAP method, but special EAP method type for emergency: similar to decoration? – Implicit indication in existing EAP method (e.g. host does not present TLS client certificate): rather a deployment- specific solution?

8. Comments welcome!