1 / 11

IPsec Remote Access Requirements

IPsec Remote Access Requirements. Scott Kelly IPsec Remote Access Working Group 48th IETF. Document Change Overview. Deleted mobility requirements Added accounting requirements Modified endpoint/user/machine auth discussion

Télécharger la présentation

IPsec Remote Access Requirements

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. IPsec Remote Access Requirements Scott Kelly IPsec Remote Access Working Group 48th IETF

  2. Document Change Overview • Deleted mobility requirements • Added accounting requirements • Modified endpoint/user/machine auth discussion • Deleted roaming/wireless users, and user-to-user connections from scenarios

  3. Document Change Overview, continued • Added discussion of threats and mitigation to telecommuter scenario discussion • Added statement about encouraging migration to stronger authentication systems to legacy compatibility section • Clarified language in Security Policy Configuration section (2.3)

  4. Mobility Requirements Deletion • "mobility" somewhat ill-defined; could mean user enters through multiple access points, or that user address changes • seems obvious that in case of dynamic client address, new tunnel should be instantiated when address changes due to lease renewal failure, etc.

  5. Accounting Requirements • Basic definition: collection/reporting of connection status info • connection start/stop times • incoming/outgoing octets • others?

  6. User/Machine Authentication • Difficult distinction to make in many cases • In general, must assume private key is secured, but if this is assumed, why not assume encrypted private key authenticates user whose password decrypts it? • Requires assumptions regarding overall IRAC system security

  7. User/Machine Authentication, continued • Need to determine whether clearcut distinction exists • There do appear to be cases where independent assurance of both the user and system identity are required • Working group participants are invited to think about this and comment

  8. Deletion of Scenarios • Roaming users • no justification for treating these any differently than telecommuter • User-to-User • Since users are virtually on corporate net, it is not clear that additional access controls are necessary (or that if they are, it is up to ipsra to provide them)

  9. Modification of Telecommuter Scenario Discussion • Threats • joyriding/hijacking active connection • credential compromise and impersonation • passive monitoring (trojan horse, etc.)

  10. Migration to Stronger Authentication Systems • added to "goals" statements: • should encourage migration from existing low-entropy password-based systems to more secure systems • Rationale: • this is consistent with charter • the point of this group is not to perpetuate weak mechanisms; rather, we want to strengthen them.

  11. Open Issues • IRAC policy config: should IRAS control IRAC policy? • Machine/user auth: are these clearly distinguishable? • Mobility requirement: is there still some basis for this (single entry in load-balance or failover situations)?

More Related