1 / 7

Update -06 of draft-schulzrinne-ecrit-unauthenticated- access

Update -06 of draft-schulzrinne-ecrit-unauthenticated- access. H. Schulzrinne, S. McCann, G. Bajko, H. Tschofenig, D. Kroeselberg IETF #76, ECRIT WG Dirk Kroeselberg. Motivation. The -06 draft has a new section 6 for network attachment considerations in the NAA case

lecea
Download Presentation

Update -06 of draft-schulzrinne-ecrit-unauthenticated- access

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Update -06 of draft-schulzrinne-ecrit-unauthenticated- access H. Schulzrinne, S. McCann, G. Bajko, H. Tschofenig, D. Kroeselberg IETF #76, ECRIT WG Dirk Kroeselberg

  2. Motivation • The -06 draft has a new section 6 for network attachment considerations in the NAA case • In general there are two categories to consider • Application-level aspects (SIP etc.) • Network-level aspects (network attachment) • Basic approaches include L2 indication, and EAP based indication of emergency during network attachment • Goals: • Discuss L2- and EAP-specific aspects • Collect feedback and additional comments • Not yet clear whether any useful recommendations can be given.

  3. 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: e.g. “{sm=2} user@realm.com” • dedicated emergency NAI: e.g. “sos” • 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)

  4. 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

  5. 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)

  6. 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?

  7. Comments welcome!

More Related