NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Paul Hoffman <phoffman@imc.org>
Sara Bitan <sarab@radguard.com>
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 |
One PowerPoint presentation (Scott Kelly, IPSRA Requirements) is attached.
IPSRA minutes
50th IETF, Minneapolis
Cochairs: Sara Bitan and Paul Hoffman
Sara led the meeting; Paul took the minutes.
WG general status
Low traffic on mailing list
New requirements draft came out in January
There were no comments
DHCP draft is waiting for IETF last call
Remote user authentication
PIC is using EAP
GetCert will change to use EAP
March Straw Poll
Few votes: 7 for GetCert, 6 for PIC
(Some votes were sent to Sara but not the whole mailing list.)
Is anyone interested???
Proposal
Advance requirements draft to Informational
Advance DHCP draft to Standards Track
Abandon PIC or GetCert due to low interest and inability to pick between them
Current status of remote user authentication
XAUTH, mode-cfg well-deployed, with some interoperability
Both of these have serious security considerations
This will probably not be fixed by son-of-IKE
"Group shared secret", other problems
Alternatives for moving forwards
Flip a coin and work on one
Move the problem to IPsec WG, try to work in son-of-IKE
But that will not be allowed
Change IPSRA charter to allow change IKE
But that will not be allowed
Leave things as they are, and get no protocol
Comments from the WG
Bernard Aboba
Why it's not working:
We don't have the right group of people
We're not cert people
Possibly move the work to PKIX
Marcus Leech
We only need one solution to succeed
Previously, vendors with proprietary VPN moved to IPsec
Therefore we will probably see reticent vendors go with whatever IPSRA picks
It will be failure if we don't pick one and make it a standard
Steve Bellovin
He is not attached to GetCert
Wanted to show that remote access authorization without changing IKE could be done
If it goes to PKIX, we have to hold their feet to the fire to actually do the work
Bill Sommerfeld
He would rather flip the coin than not do either
Also thinks the numbers of votes are high enough to indicate interest
Cheryl Madson
Too many things (the ones that need IKE changes) were thrown off the table
Interop happens even without standards (hinting at XAUTH)
Dan Harkins
The WG was doomed from the start because of the charter
Political problems cause current lack of solution
Eric Flieshman (apologies if I spelled this wrong!)
Customers want GetCert or PIC, not "no solution"
Magnus Nystrom
Maybe reuse the work being done in the SACRED WG
Steve Bellovin: SACRED does not have our legacy auth constraints
Sara and Paul and Marcus put their heads together and mumbled
There will be a new straw poll with different questions on the WG list in the near future
Bob Moskowitz on expected revisions to GetCert
Will go from SCEP to CMP
Will add EAP
Do we go with CMP or CMC?
Will still have ASN.1 coding
Nice feature: GetCert box can act like RA
Sara Bitan on PIC
Currently uses EAP on a transport that looks like IKE
Scott Kelly on requirements
Listed the changes from -02 to -03
Much more on L2TP/IPsec
IPSRA WG has lost focus, we should be emphasizing secure aspect of access, not just remote access
IPSRA WG has pushed the L2TP folks away
Is the current L2TP/IPsec sufficient for us?
Main security issues
Transit selectors are opaque to IPsec
Complexities of L2TP-IPsec interactions
User auth is not done until Phase 2: biggest problem
Our primary interest should be security: just try to secure the pipe
Should allow lower security if the customer understands it
Bernard Aboba
Using passwords to get a cert lowers security of certs
Need to be clearer about the security issues
General feeling
L2TP is not needed, but should not be shunned
Meeting adjourned
None received.