Reported By: Michael C. Richardson [email@example.com]
IPSRA meeting at Tuesday 17:00 in the Blue Room.
Filled with a lot of people.
$Id: IPSRA-minutes,v 1.2 1999/11/22 19:21:23 mcr Exp mcr $
2. High Level Goals
High Level Goals:
1. existing legacy user authentication system
2. remote configuration
Roy talked about why we need existing legacy user authentication systems. He mentioned that they should make IKE stronger not weaker. Roy talked about seemless migration to a PKI.
- Dynamic assign a private IP address.
- VPN configuration (e.g. allowed subnets, IPsec policy)
- Distribution of VPN configuration.
CHARTER (see slides and http://www.ietf.org/ for full text)
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 requirements 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....
2) IPsec makes it difficult to support dynamic resource assignment, particularl 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.
3) The 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 cannont 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 (a) below, creates a list of new problems (among them -- man in the middle...)
The output of this working group will include:
1) Framework document
a) proposed standard (or BCP) to support existing end-user authentication to support: - username/password (radius PAP)
- tokens Challenge/Response and Synchronous
b) proposed standard/bcp to remote configuration
These protocols will not negatively affect the security of the base protocols. There are existing marketed implementations in this area.
- Nov. 1999:second BOF meeting, new drafts for stuff
- Jan. 2000:first draft of framework document
- Feb. 2000:framework document submitted for standards track
- Mar. 2000:first WG meeting
- May 2000:addressing mechanism
- May 2000:authentication mechanism
- May 2000:enhanced IKE document
Hoffman: One points 2a/2b. Are we expected to put out "1" or "many" proposals?
Sara: there will be seperation of problems.
Karl Fox: PAP should be removed from the list of proposed protocols, as it has been deprecated.
Kent: IKE requires widespread PKI. This usually applies to S/MIME, etc. Since they are closed communities, there isn't the same kind of widespread need, so the wording in the charter should be changed. The word "widespread" is not the one that you use in the context.
Roy: please send us text
Bill Simpson: once upon a time we had BOFs to discuss the kinds of things that we would like to work on. I would like to advocate the position that there is no need for this working group. There are three other working groups already working in this problem space. Radius assumed IPsec. MobileIP assumed IPsec.
IPsec doesn't do a good job of authenticating remote users. It is best to keep this orthogonal. I would not like to see another mode to support legacy modes.
Roy: we aren't trying to do this. There was a strawman at the last BOF. Implementers would disagree.
Orman: there is a flip in charter. We need to fix some things, then support legacy issues. The legacy stuff needs to go further up in the charter. Hillery doesn't feel comfortable with this charter. Lots of collisions with other WGs.
Bellovin: second some of Bill Simpson and Stephen Kent said. IKE is complicated enough. If the desire is to support legacy authentication modes, then we should use a specialized protocol takes the specialized legacy mode of one's choice and generates a short-lived public/private key pair.
Roy: do you agree that Main-Mode with shared-secret is not a good thing.
Bellovin: that's why I need certificates. You don't need a PKI, you just use PK.
Roy: please write a draft.
Glen Zorn: agree a little with Steve/Bill. Note all the technical requirements are fullfilled by existing protocols. Last time I said this the AD mentioned the word "engineering" --- good engineering takes existing tools and uses them. The only requirement that isn't fullfilled is in the financial/political layer.
Sara: we don't intend to invent new protocols here. Just pick a standard. There are lot of protocols that one can choose. Need a standard combination.
Shawn Mamros: charter needs to be clarified to say that IKE modifications are not mandantory. If we can get away without them, we should do that.
Marcus (SAD): anything that meets the requirements without adding new IKE modes would preferable to anything else. Fix bugs, not add new features. DOS issues raised by Bill Simpson. I can certainly envision solutions that don't involve changing IKE. HTTP over SSL with legacy auth to get a certificate.
Roy: those are really good options. Don't open the box. Just solve the problem.
Bernard: if the purpose is to find the best solution to the problem, then that is what should be in the charter.
Sara: please provide replacement text
Pryda Srisuresh:slight different opinion. Charter requirements are on par. Problem of this workgroup is not just legacy auth, other issues are: address assignment, routing info, etc. Need to depend upon a mechanism that works and can scale by service providers. This is the first attempt to link the routing, addressing and security issues of the remote users.
Ted T'so: insert into the charter the requirements document. IPsec made the mistake of not doing requirements. If by Nov. we have a whole series of new mechanisms then without any way to judge which is best. "what's important and what's not"
Roy: need volunteers to put together requirements.
Ted: if things are fixing flaws in IKE, then IPsec WG will buy them. No new features.
Mark Townsley: L2TP extensions. L2TP and IPsec. Invitation.
Hoffman: need focus. It seems the place of last resort for IKE. This is not all bad, but some belongs back in IPsec.
Sara: problems are more apparent when IKE is used in remote access.
Sara: VPN configuration?
Minute taker left at this point.