NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Paul Hoffman <paul.hoffman@vpnc.org>
Sara Bitan <sarab@cs.technion.ac.il>
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Marcus Leech <mleech@nortelnetworks.com>
General Discussion:ietf-ipsra@vpnc.org
To Subscribe: ietf-ipsra-request@vpnc.org
In Body: subscribe
Archive: http://www.vpnc.org/ietf-ipsra/mail-archive/
The work of the IPSec working group is almost concluded at the time this charter is being written. The IPSEC working group has produced three proposed-standard protocols: AH, ESP, and IKE.
When the IPSec WG considered requirements for the protocols it produced, inadequate attention was given to the support for so-called "road warriors"-- remote users that use personal portable computing devices, or who use Internet "kiosks" to access private networks on the other side of an IPSEC gateway. Such users will typically connect to the Internet at a point most convenient to them at the time of connection:
o Dial-in to a local ISP
o Wireless or wired LAN access at a conference, hotel or airport
There are some fundamental differences, that are relevant to IPSec usage, between these remote access scenarios and scenarios where both parties reside in fixed locations:
- The authenticated entity must be a human user, i.e. human interaction is required during the authentication process.
- In each session the remote access entity interacts with at least two access points- the Internet access point and the organization entry point. The authentication must be established between the remote access entity and the entry point to its organization (and not into the ISP).
- The remote access entity wishes to connect to its organization's distributed network. This network might be large and complex and with multiple remote access entry points. Although the user physical location is not changing during the remote access session, he might use different entry points during the same session.
- In the above scenario, the entry points don't have information on all the entities that are allowed to access the network. When the remote access begins the entry point should obtain information on the remote access entity that will enable it to grant secure access to the network. This information might be credentials supplied by the remote access entity itself, or information supplied by some other server.
- Several human users can share the same physical machine.
- The remote access entity doesn't have its configuration information. This information must be transported securely to the remote access implementation after the entity's identity has been authenticated.
- There are systems that rely on different identities for access control - examples are IP address, users names and others. Most of the time the user's remote access implementation won't have this information available to it before the connection begins. Organizations will not change their access control systems. Hence this information must be conveyed securely to the remote access's implementation after the authentication.
IKE supports four authentication methods; one method is based on pre- shared secrets, while the other three are all public-key variants, with various desirable properties. The use of pre-shared secrets scales very badly, requiring O(N**2) keys to be managed to provide effective security. The authentication methods based on public-key technology assume, to a certain extent, that the organization involved has deployed its own public-key infrastructure for authentication of individual human users. This assumption is taking much longer to reach fruition than one would hope.
Most organizations have legacy authentication systems that are adequate for providing authentication of individual human users (OTP, username/password, hardware authentication tokens, etc). Most organizations insist on the ability to continue to to support such legacy authentication mechanisms as they deploy an IPSEC infrastructure at the perimeter of their networks.
The goals of this working group are:
- to define a remote access architecture. The entities participating in the remote access and their relationships will be defined in a framework document. This document will be published as an Informational RFC.
- to define a standard mechanism to accomplish human user authentication to an IPSec device running IKE, using legacy authentication mechanisms. One of the goals of introducing this mechanism is to allow for an easy migration path to PKI. The mechanism will be published as a standards-track protocol document.
- to define a standard mechanism to convey user configuration information from user's own private network to its local IPSec implementation. This mechanism will be published as a standards-track protocol document.
- to provide a standard mechanism to convey user information required for access control from the user's own private network to its local IPSec implementation, while answering the special requirements of remote access users. This mechanism will be published as a standards- track protocol document.
- to work closely with the MOBILEIP Working Group so that the respective protocols work together.
The WG strongly prefers mechanisms that require no changes to AH, ESP or IKE protocols. If such changes are deemed necessary, the IPSec WG is contracted to carry out such changes. Pursuing this approach is most likely to produce mechanisms that are easy to implement and deploy.
Mar 00 |
|
Submit Internet-Drafts of requirements and framework documents |
Mar 00 |
|
First WG meeting |
Jul 00 |
|
Requirements document submitted for Informational |
Jul 00 |
|
Remote access framework submitted for standards track |
Dec 00 |
|
User authentication to IKE mechanism submitted for standard track |
Dec 00 |
|
User configuration mechanism submitted for standard track |
Mar 01 |
|
User access control mechanism submitted for standard track |
· DHCPv4 Configuration of IPSEC Tunnel Mode
· Requirements for IPsec Remote Access Scenarios
IPSRA Meeting minutes
---------------------
Meeting date : 7-Aug-2001
Meeting led by Paul Hoffman.
Paul opened the meeting, the whole session will devoted to PIC discussion.
Marcus gave a short clarification on the IKE position statement : PIC is not excluded, but should be run on a port other than 500, and PIC implementations should not share code with IKE implementations on the same box.
Hugo gave a presentation of PIC.
Questions:
William Dixon (MS): Is PIC going to support Tero's revised hash?
Hugo: The problem that the revised hash is solving doesn't appear in PIC
William: Stateless DOS prevention - since there is no DH computation in the first two message
Hugo: We don't plan - DOS protection was not part of the requirement.
William: Will you include certificate request? The problem is that is might create UDP fragmentation, which from our experience caused problems in IKE implementation: Try to avoid fragmentation. The certificate request shouldn't be long, but the PKCS#12 might include long certificate chain.
William : Proposal - add wording saying that messages are not longer than 1500 bytes.If you can avoid fragmentation - than avoid it.
William: What about CMC support?
Hugo: No
Scott (Cisco): Another server increases complexity of the network and architecture
Hugo: A separate AS is optional.
Scott: That is an RA or an embedded CA
Hugo: This architecture is actually the only one possible within the boundaries of the charter
Scott: Shouldn't this protocol moved to PKIX since it is an enrollment protocol
Hugo : Enrolment protocols are over functional in some aspects, and under functional in other aspects for PIC, and they are to complex for the purpose.
Andrew (Alcatel): Lesson from IKE : don't allow arbitrary payloads and arbitrary lengths
Question: have you implemented PIC. What are the CPU requirements of PIC
Hugo: No. There are some performance issues. But human authentication should be rare.
Q: So this is a simplified CA, with CA authentication being EAP
Hugo: Right.
End of PIC discussion, beginning of general discussion.
Marcus : who has implemented DHCP draft ?
Scott (RedCreek): RedCreek + I know there one another implementation - but don't remember whose.
Moving forward:
Six weeks working group last call - till the end September. If we have significant remarks - period will stretch, After that - IETF last call.
We don't need two implementation to move proposed draft.
We might not have to meet in Salt lake city
--Paul Hoffman, Director
--VPN Consortium