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

2. IPsec Remote Access BOF 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

3. November 9 1999IPsec Remote Access BOF 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

4. November 9 1999IPsec Remote Access BOF 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.

5. November 9 1999IPsec Remote Access BOF IPSRA requirements Generic 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

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

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

8. November 9 1999IPsec Remote Access BOF 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:

9. November 9 1999IPsec Remote Access BOF 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.

10. November 9 1999IPsec Remote Access BOF 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.

11. November 9 1999IPsec Remote Access BOF 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).

12. November 9 1999IPsec Remote Access BOF 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.

13. November 9 1999IPsec Remote Access BOF 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.

14. November 9 1999IPsec Remote Access BOF 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.

15. November 9 1999IPsec Remote Access BOF 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.

16. November 9 1999IPsec Remote Access BOF 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

17. November 9 1999IPsec Remote Access BOF 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