IPsec Remote Access BOF

1. IPsec Remote AccessBOF Washington D.C. November 9 1999 IPsec Remote Access BOF

2. Co-chairs: Roy Pereira royp@cisco.com Sara Bitan sarab@radguard.com Mailing list : ietf-ipsra@vpnc.org Subscribe : ietf-ipsra-request@vpnc.org Archive : http://www.vpnc.org/ietf-ipsra/mail-archive IPsec Remote Access BOF

3. Agenda 5 mins Agenda bashing 5 mins High level goals and requirements 10 mins Reading of the Charter 35 mins Discussion of Charter & requirements 5 mins Finalize Charter IPsec Remote Access BOF

4. High Level Goals 1)Provide support for non-PKI scalable legacy end-user authentication technologies. 2)Support dynamic resource assignment. 3)Enhance IKE to support mobile remote users. IPsec Remote Access BOF

5. IPSRA requirementsGeneric • Maintain or exceed security strength • Complement current and future IKE specifications • Maintain compatibility with current and future IKE specification • Seamless migration from direct-dial remote access • User perspective IPsec Remote Access BOF

6. IPSRA requirementsAuthentication • Support existing legacy user authentication system (e.g. SecurID, RADIUS,CHAP) • seamless integration into an organization’s existing infrastructure. • Seamless migration to a PKI IPsec Remote Access BOF

7. IPSRA requirementsConfiguration • Resource allocation (specifically private IP address) • Should be referenceable to IKE IDs. • VPN configuration (e.g. allowed subnets, IPsec policy) ???? • Distribution of VPN configuration ??? IPsec Remote Access BOF

8. Charter The rapid growth of remote access and the subsequent transition from older direct-dial remote access to Internet-based remote access carries with it a requirement for secure communications. While IPsec is an obvious solution in this space, it has several easy-to-fix shortcomings: IPsec Remote Access BOF

9. 1) IPsec, and particular, IKE, assumes the widespread deployment of public-key technology to achieve mutual authentication between parties. There exists a large demand for the support of scalable non (public-key)certificate end-user authentication technologies in the IPsec remote-access space. IPsec Remote Access BOF

10. 2) IPsec makes it difficult to support dynamic resource assignment, particularly addresses, based on authenticated user identity, from within a private address space behind an IPsec security gateway. This is an operational property of the current IKE specification, and implementations. IPsec Remote Access BOF

11. 3) The current IKE protocol does not properly answer the requirements of remote access users when non-certificate based authentication is used. Main mode with shared secret authentication cannot be used with dynamic IP addresses. Aggressive mode is exposed to a wide range of denial of service attacks (unlike main mode). In addition, the use of all the existing modes with the authentication mechanism listed in (2a) below, creates a list of new problems (among them - man in the middle, binding IKE authentication to the user authentication). (If the working group will reach the conclusion that) We will define new IKE modes (are required) to securely support legacy user authentication (then we will move forward to defining such new modes). IPsec Remote Access BOF

12. The outputs of this working group will include: 1) A framework document that specifies the requirements for secure IPsec remote access. This document will identify all the entities participating in the secure remote access, and define the secure remote access architecture. IPsec Remote Access BOF

13. 2) Standards-track documents that fulfill the requirements outlined by the goals of this charter. Specifically: a) A PROPOSED STANDARD (or BCP or Informational) document describing extensions to IPsec and/or IKE to support existing end-user authentication, by itself or in conjunction with another IKE authentication mechanism, including, but not limited to: - username/password (eg. RADIUS PAP) - Tokens: both Challenge/Response and SecurID-like - OTP b) A PROPOSED STANDARD (or BPC or informational) document describing a mechanism for providing secure configuration for remote users needing access to a private network on the other side of an IPsec gateway. At a minimum, this would involve address assignment for the user-side virtual interface. IPsec Remote Access BOF

14. The proposed work items for this group would yield standards that are compatible with the existing IPsec architecture [RFC 2401] and IKE, complementing the standards work achieved by the IPsec Working Group. Since this working group is focusing on IP Security, its protocol specifications will be designed to have no negative impact on the security of the underlying protocols (ESP,AH, and IKE), or the Internet in general. IPsec Remote Access BOF

15. There are existing, marketed, implementations based on previous work in (this field)the user authentication field and thus a major focus for this working group will be to leverage the existing practice and operational experience, and extract from the implementations a scheme that is flexible, and architecturally sound. IPsec Remote Access BOF

16. Thus, this work will be derived from, but not limited to, all or some of the following documents: • draft-gupta-ipsec-remote-access • draft-aboba-ipsra-req • draft-kelly-ipsra-userauth • draft-ietf-ipsec-isakmp-hybrid-auth • draft-harkins-ipsec-ike-crack • draft-ietf-ipsec-iskamp-xauth • draft-ietf-ipsec-ike-base-mode • draft-ietf-ipsec-isakmp-mode-cfg • draft-ietf-ipsec-dhcp • draft-ietf-pppext-l2tp-security • draft-ietf-pppext-secure-ra IPsec Remote Access BOF

17. Milestones: November 1999: Second BOF meeting November 1999: New drafts of addressing mechanisms November 1999: New drafts of authentication mechanisms January 2000: First draft of framework document February 2000: Framework document submitted for standards track March 2000: First WG meeting May 2000: Addressing mechanism document submitted for standards track May 2000: Authentication mechanism document submitted for standards track May 2000: Enhanced IKE document submitted for standards track IPsec Remote Access BOF