AAARG BOF Notes - Munich, Aug 13, 1997

Editor's Note:
---
The notes for this BOF were very difficult to take.  Conversation
digressed very often and did not really follow any structure.  This
seemed to be 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 editorialize 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.

Agenda:
---
1. Agenda bashing, administrative stuff - Paul Krumviede <[email protected]>

2. Problem statement

3. Requirements

4. Password change protocol

5. Authentication protocol proposals

6. Next steps
---

2.  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 were 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 acceptible for
     retrofitting the install base as a manditory 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.


3.  Requirements (some collected during the problem definition).

   * requirement that it ease administrative load - should support
     centralized management of distributed servers.
   * it must scale to large user numbers
   * it must interoperate
   * it must have a base line of security
   * it 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 was actually being said by the individual
   speaking, 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

 - discusses the requirement for migration strategy.   Key to
   deployment of a new baseline model.

 - is using the existing authentication database is 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 vs. raising the bar
     a lot.  Probably we 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.

4.  Discussion on working group future.

 - concensus 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 - 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.

- first order of business is to draft a charter for the group.
---
Steve Hole                      VP,  Research and Development
The Esys Corporation            EMail: [email protected]
900 10040 - 104 St.             Phone: 403-424-4922
Edmonton, AB, Canada            Fax:   403-424-4925
T5J 0Z6


------- =_aaaaaaaaaa0--