EAP in Unauthenticated Network Access to Emergency Services

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 sm2 user_at_realm.com
• dedicated emergency NAI emergency_at_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 AA 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!