Re: IPSRA charter (modified)

[Roy Pereira <royp@xxxxxxxxx>]

I unintentionally left out Dan's CRACK draft from the list of drafts at
the bottom; draft-ieft-ipsec-ike-crack

Roy Pereira wrote:
> 
> Here is an updated charter.  The modifications come from discussions
> with the AD.
> 
> IP Security Remote Access Charter (IPSRA)
> =================================
> 
> Chair(s):
> 
> Roy Pereira <royp@xxxxxxxxx>
> Sara Bitan <sarab@xxxxxxxxxxxx>
> 
> Security Area Director(s):
> 
> Jeffrey Schiller <jis@xxxxxxx>
> Marcus Leech <mleech@xxxxxxxxxxxxxxxxxx>
> 
> Security Area Advistor:
> 
> Marcus Leech <mleech@xxxxxxxxxxxxxxxxxx>
> 
> Mailing Lists:
> 
> Email: ietf-ipsra@xxxxxxxx
> 
> To subscribe: ietf-ipsra-request@xxxxxxxx
> In body: subscribe
> 
> Archive: http://www.vpnc.org/ietf-ipsra/mail-archive/
> 
> Proposed 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:
> 
> 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 non public-key end-user
> authentication technologies in the IPSEC remote-access space.
> 
> 2)  IPSEC makes it difficult to support dyamic resource assignment,
> particularly addresses, from within a private address space behind an
> IPSEC security gateway.  This is an operational property of the current
> IKE specification, and implementations.
> 
> 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 (2)
> above, 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 new IKE modes are required to
> securely support legacy user authentication then we will move forward to
> defining such new modes.
> 
> 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.
> 
> 2) Standards-track documents that fulfill the requirements outlined by
> the goals of this charter.  Specifically:
> 
> a) A PROPOSED STANDARD document describing extensions to IPSec and/or
> IKE to support existing end-user authentication, by itself or in
> conjuction with another IKE authentication mechanism, including, but not
> limited to:
> 
>   - RADIUS-based username/password
>   - Tokens: both Challenge/Response and SecurID-like
>   - OTP
>   - Non RADIUS-based username/password
> 
> b) A PROPOSED STANDARD 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.
> 
> 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 design to have no negative impact on the security
> of the underlying protocols (ESP, AH, and IKE), or the Internet in
> general.
> 
> There are existing, marketted,  implementations based on previous work
> in this 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. Thus, this work will be derived from, but not limited to, all or
> some of the following documents:
> 
>   draft-ietf-ipsec-ike-base-mode
>   draft-ietf-ipsec-isakmp-hybrid-auth
>   draft-ietf-ipsec-isakmp-mode-cfg
>   draft-ietf-ipsec-iskamp-xauth
>   draft-ietf-ipsec-dhcp
>   draft-gupta-ipsec-remote-access
>   draft-kelly-ipsra-userauth
> 
> Milestones:
> 
> November 1999: First WG meeting / Second BOF meeting
> November 1999: New drafts of addressing mechanisms
> November 1999: New drafts of authentication mechanisms
> December 1999: First draft of framework document
> February 2000: Framework document submitted for standards track
> April 2000:    Addressing mechanism document submitted for standard
> strack
> May 2000:      Authentication mechanism document submitted for standards
> track

-- 
Roy Pereira
Product Line Manager, VPN
Security Internet Services Unit
Cisco Systems