Minutes of the AAARG BOF
Reported by: Steve Hole
Editor's Note: The notes for this BOF were very difficult to take. Conversation digressed often and did not follow any structure. This seemed OK with everyone, because we were trying to feel out what the problem was and why we needed to discuss it. As a result, I was forced to edit the notes after the fact so that they made sense. Some of the items are presented out of order, specifically any potential requirements that were collected into Part 3. I apologize if anything is misrepresented, misquoted or missed from the discussion. If I did, it was unintentional.
I. Agenda
1. Agenda bashing, Administrative - Paul Krumviede <paul@mci.net>
2. Problem Statement
3. Requirements
4. Password Change Protocol
5. Authentication Protocol Proposals
6. Next Steps
II. Problem Statement
Paul outlines authentication problem as originally discussed on the list.
· Each application does its own authentication.
· The discussion quickly digresses to discussion on individual existing authentication mechanisms.
· Started identifying requirements for the system. This happened sporadically, and was collected into the following section.
Discussion on OTP
· OTP is raised as a mechanism that meets the requirement for lightweight infrastructure.
· Problem identified that for certain application protocols (IMAP, ACAP, SMTP/AUTH) that the password list is burned quickly and there is currently no mechanism defined for resetting it.
Discussion on "single login" requirement
· Problematic because it forces use of the strongest mechanism by all applications.
· Implies that deployment be made for all applications using the strong mechanism at the same time.
Discussion about the TLS and IPSec solutions
· They do provide secure authentication.
· There are interface libraries available now or soon that will allow the application to query for and get the authentication identifier to use for authorization purposes.
· Requires public key infrastructure to run reliably.
· Many opinions expressed that TLS is not acceptable for retrofitting the install base as a mandatory to implement for application protocols.
Discussion on "why we are here."
· Security Area Director will not allow any new protocols to implement a plaintext authentication mechanism.
· New protocols MUST implement a stronger mechanism.
· We need to provide a deployable mechanism that is stronger than plaintext.
Review of existing authentication mechanisms at the application level. What are the requirements?
· Opinion that there really is no solution right now.
· Opinion that the mandate for this group really should be to define the requirements.
Question: What is the authorization part of the group about?
· Chris Newman - applications bind authentication to authorization information.
III. Requirements (some collected during the problem definition)
· Requirement that it ease administrative load - should support centralized management of distributed servers.
· Must scale to large user numbers
· Must interoperate
· Must have a base line of security
· Must have a generic interface
· Must support the nomadic user
· Must be able to bundle in a shrink-wrapped box
· Must be resistant to passive attack
· Should be resistant to active attack
· Should support mutual authentication
· Should support password synchronization (password change)
· Is proxying a requirement?
· Without knowing the trust model, it is very hard to identify the requirements for the base security level. Editor's Note: I really didn't understand what the individual speaking was actually saying, so I hope that what I wrote is at least in the ballpark.
· Solution should reduce to a specified security level that is comparable to some other known protocol.
· Likely that we will reuse or combine existing authentication solutions.
· The list of requirements discussed in the meeting probably results in the null set for solutions.
· Proposal for a minimized set:
- no passive attacks.
- minimize active attacks.
- be compatible with existing password infrastructure
- be easy to use
· Looked at Tweke as a migration mechanism
· Discussed other alternatives for UNIX password file support
· Discussed the requirement for migration strategy. Key to deployment of a new baseline model.
· Is using the existing authentication database not really important? Same form factor for deployment.
· History on the problem from Jeff Schiller. The IAB is concerned that a weak solution promoted by the IETF will be very embarrassing when it is compromised.
· Possibility of doing nothing -- results in passwords over SSL? Better than nothing, but not something that would be standardized.
· Discussion on base level of security:
- Argument over raising the bar a little versus raising the bar a lot. Probably should split between them.
- Opinion the bar is being dropped from proprietary to open systems, so we are just raising the Internet app bar, not the user application bar.
· Opinion that Kerberos is already there and will be widely deployed with NT v5.
· We must do something for the work in progress application protocols.
· GSSAPI does provide a framework for plug and play authentication support by applications. The underlying mechanisms remain the base level problem on the wire. The problem is deployment and availability of the underlying strong mechanisms that make up the current GSSAPI base. It moves the problem to the GSSAPI level.
IV. Working Group Future
· Consensus is that something must be done.
· Keith conducted a straw poll on how many were interested in working on this. There was sufficient response from Keith's point of view.
AAARG Design Meeting - Aug 14, 1997
Keith Moore
Steve Hole
Jan Pachl
Chris Newman
John Myers
Charlie Kaufman
Randy Gellens
Paul Krumviede
Goal is to do the base work for establishing the characteristics of a general application authentication solution.
In reaction to the IAB edict against plaintext passwords with no obvious replacement solution being deployed.
Keith - limit the scope of the group to select a security mechanism that meets the requirements of the Application Area. Understand the shape of the solution space.
Problem #1 - we need a new lower limit to authentication mechanism.
Problem #2 - we need a transition strategy from the old lower level to some higher level authentication.
The output of the group is intended for application protocol designers and security protocol designers.
1. Define the desired characteristics for security solutions to be used by application protocol designers. Can be one or more somethings.
- technical characteristics
- political characteristics
- economic characteristics
2. Define the characteristics of existing security solutions.
3. Identify any gaps between the existing security solutions and desired characteristics for application protocols.
4. Provide guidance (recommendations) for making choices from existing security solutions for application protocol designers.
The first order of business is to draft a charter for the group.