Subject: Fwd: Minutes from AAA BOF

From: James Rafferty <[email-masked]>
Date: Thu, 17 Sep 1998 12:30:04 -0400

Folks, 

While at the IETF, I sat in for while in a BOF on access, authorization and
authentication .   This activity may be relevant for our WG later on when
we take a closer look at offramp issues, especially considering matters of
who is authorized to use an offramp that will in GSTN phone charges. 

In reading Larry Masinter's goals document, I noticed that the issue was
raised there, although we have not pursued this to date.    

I've attached the BOF minutes as a backgrounder.   

So, if you are interested in tracking this, you may want to subcribe to
their mailing list:  

>aliases: [email-masked]
>		   [email-masked]

I think it would be good for at least some of the Fax WG people 
to participate, so that the end results can be used to help solve 
some of our offramp problems.   

Also, If you plan to be quite active in this area, please let me
know so that we can draw upon what you have learned
when (if) the time comes to tackle this within the WG.   

Thanks, 

James 

>X-Sender: [email-masked]
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
>Date: Thu, 03 Sep 1998 11:17:21 -0700
>To: [email-masked]
>From: Fred Baker <[email-masked]>
>Subject: Minutes from AAA BOF
>Cc: [email-masked]
>
>Courtesy of Michael Speer, here are the minutes from the AAA BOF held on
Friday last week. Please read them and drop me a note on any issues you
see, points missed, etc.
>
>Minutes from AAABOF (IETF 42, Chicago, 8/28/1998)
>=================================================
>
>Chairs:  Sue Hares, Merit
>	   Fred Baker, Cisco Systems, Inc.
>
>What are we trying to do? (Fred Baker)
>
>	What is the AAA problem space?  Other protocols have attempted what
>	could be considered some part of this problem space:
>
>		RAP ---> Intra-domain QoS policy
>		Radius ---> Access, Authorization and Accounting
>		Diameter ---> Access, Authorization, and Accounting
>	
>	- Want to understand the problems that a AAA protocol needs to
>	  address:
>
>		Intra-domain vs Inter-domain problems?
>
>		What is the AAA Framework?
>
>
>
>Overview of Bandwidth Broker Model (Sue Hares)
>
>	Summary of Bandwidth Broker Model
>
>		- Inter-domain problem!
>		- Dynamic SLA allocations
>		- Mutual Distrust Relationship
>		- Flows are aggregates not individual flows
>		- Authentication
>
>	Sample Client/Server
>		- Policy enforcement and policy decision points
>		- Policy database exchange issue.
>
>	Intra-Domain
>		- Trusted, multiple servers, common or shared policy
>		  databases
>
>	Inter-Domain
>		- Not trusted
>		- Public vs. Private polices
>			- Subset of policy is exchanged
>			- Policy may be derived.
>			- Hints for alternative policies
>
>
>
>Clarifying  Policy Exchange (COPS, Raj Yavatkar)
>
>	RAP working Group is solving the Intra-domain policy exchange
>	problem for QoS.  COPS is the transport protocol for that policy
>	exchange.  Policies are of the yes/no nature.	
>	
>	Questions,Comments:  
>		Sue Hares - Definitions of policy needs to be explained.
>		
>		Fred Baker - Kid analogy.  Policy maybe that you may have
>			the bandwidth, but conditions on which you can have
>			more bandwidth.
> 
>		Shai Herzog/Iphighway - Is policy parameters vs no parameters?
>			Law vs. Decision?  Or, Pre Decision vs Post-Decision?
>
>Two Tier Resource Management (Lixia Zhang, UCLA)
>
>	- Today's Internet is no longer simple
>		- Routing Protocols are not the same for the entire Internet
>		- Scalable Resource Management
>
>	- With a domain, Bandwidth Brokers are not necessarily a single box.
>	  Bandwidth Broker function may be distributed.
>
>	- AAA Requirements
>
>		- Mutual Authentication across domains.
>		- Bi-lateral agreements only.  No cascading
>		- Need credential based authentication.
>		- Authorization
>			- peer-to-peer to setup SLA for aggregate
>		- Accounting
>			- Information on the SLA usage
>			- Per-customer information not passed
>		- End-to-End Quality of Service
>			- Concatenation of Intra-Domain and Inter-Domain
>			  SLA's gives end-to-end QoS support
>
>Ip Security (IPSEC) (Roy Pereria)
>

>	- IPSEC uses IKE
>	- IKE:
>
>		- Can authenticate as well as negotiate.
>		- Authentication is bi-lateral.
>		- Authentication is Gateway to Gateway, not the hosts
>		  they are protecting.
>		- Extended Authentication in IKE:
>			- Allows for unidirectional authentication
>			- Supports all mechanisms (???)
>
>	Questions/Comments:
>
>		Raj Yavatkar, Intel - What is your input to this BOF?
>			Answer: transport for authentication, ....
>
>		Pat Calhoun, Sun - EAP can be carried to control server via
>			IPSEC 
>
>Mobile IP (Charles Perkins, Sun)
>
>	- Diameter used for Mobile IP for Authentication and Authorization of
>	  Host Agent and Foreign Agent exchanges.
>
>	- Proceeds with developing trust relationships.  These relationships
>	  are not long term  in nature.  They are also Dynamic.
>
>	- Local hand off -->>  Associations can move.
>
>	Questions/Comments:
>
>		Shai Herzog:  Are the associations per client or cached or ..?
>			How do you view relationship between caching of per
>			client vs aggregate.
>
>PINT (Steve Bellovin, AT&T)
>
>	PINT 
>		- Click to call protocol
>		- Requires authentication and authorization.
>
>	Payment Models
>		- PINT authenticates the customer
>		- Telephone network authorizes PINT client
>		- End-to-end customer signs request
>
>	Requirements:
>
>		- Authentication PINT client by PINT server
>		- Authentication of PINT client
>		- Robust and fast!!
>
>RAP Considerations for AAA (Tim O'Malley, GTE Internetworking)
>
>	- Ignorance acknowledged.  Policy architecture for RAP for RSVP
>	  in a domain only.
>
>	- Requirements:
>
>		- Mother May I ...
>		- Lightweight for client
>		- Stateful
>			- duration based policies
>			- Preemption of users in preference to other users
>			- Effective accounting benefits
>			- RSVP is soft state and merging doesn't effective
>			  track state.
>		- QoS Signalling is complicated problem space
>			- Admission control and merging
>			- Hop-by-hop decisions of RSVP must combine coherently.
>		- RAP Extensible to other domains such as non-RSVP clouds
>		- Granularity of resources
>			- Per User / Per resource
>
>	- Questions/Comments:
>
>		Glenn Zorn, Microsoft - What is unique about RSVP?
>			Answer: Tim agrees that RSVP is NOT unique and
>				is applicable to other domains.
>
>Roaming Operations (Glenn Zorn, Microsoft)
>	
>	- Authentication, authorization, and accounting for Roaming
>	  Operations.
>
>	- End-to-End security is a requirement
>
>	- Questions/Comments:
>		Dave Durham, Intel: Is the public infrastructure in place or
>			not?
>
>		Paul K.:  Can you clarify what is meant end-to-end
>			security?
>
>		Markus Leach: No end-to-end security mechanisms exist today.
>			It's wrong to go off and develop another when we
>			haven't deployed the one we have.
>
>		Raj Yavatkar, Intel: What are the requirements for ROAMOPS? Is
>			there working group consensus?
>
>			Yes, we have requirements and there is working group
>			consensus.  The requirements document is in working
>			group last call.
>
>		Charlie Perkins:  Mobility is not the same as roaming.
>

>SS7 (Nancy Green, Nortel)
>
>	[email-masked]
>
>	Signalling Gateway, MC, NAS are all described in:
>		draft-bell-signalling-00.txt
>
>	Requirements of AAA Protocol:
>
>		- MC to MG associations
>		- MG reboot and configuration
>		- User authentication
>		- Enable billing/resource auditing
>		- Device control actions
>		- Efficient for PSTN imposed timing constraints, hence 
>		  protocol should run over UDP
>		- Large space for parameters and commands
>		- Be symmetric
>		- Resource discovery
>		- Negotiation of capabilities
>
>	Questions/Comments:
>		
>		Shai Herzog: Is there a Framework Document?
>
>		   N.G -- framework documents is draft-green-ss7-arch-00.txt
>
>		   What of the chain of trust?
>		   Other Solutions?  SGCP, IPC, Diameter
>
>		Henry Sinnreich(spell?) 
>			General comment - 13 protocols to solve this problem!!
>			Can we simplify this?
>
>		Char, Cisco Systems:
>			- SS7 group doesn't have consensus on the approach
>			- Signalling transport has some requirements as well
>			  authorization requirements for signalling.
>
>		Christian Prehofer, Siemens - Authentication and control is
>			overloading diameter.
>
>			PEP and PDP may be presumptive.
>
>		Tim O'Malley, GTE Internetworking - Why is radius not
>			sufficient?
>
>Requirements for ROAMOPS (Aydin Edguer, Ascend Communications)
>
>	- Requirements of AAA
>
>		- Mandatory authorization and authentication.
>		- Hidden attributes
>		- Arbitrary attributes for associating messages
>		- Server initiated messages.
>		- Decoupled authentication and authorization
>		- Roaming security
>		- Roaming reliability
>		- Non-user based AAA
>
>NAS Requirements (David Milton)
>
>	- NAS small limited systems with no storage
>	- Requirements:
>
>		- Callback and Demand Dial out
>		- Call Management
>			- make policy decisions based on usage
>		- New network access:
>			- VPN's and Tunnels
>			- IPSEC
>			- VOIP Gateway
>		- New authentications systems
>		- Real-time authorization and resource controls
>			- IP Address Assignment
>			- Packet filters
>			- Concurrent user limits
>			- ...
>	- Summary:
>		NAS not just for dial-in anymore.  Need enhanced service
>		capabilities.  Solutions need to scale.
>
>Accounting Management (Arrko, Ericsson)
>
>	Accounting Management
>		
>		- draft-aboba-acct-00.txt  identifies the requirements
>		- draff-arkko-acctreq-00.txt identifies the scalable 
>			accounting requirements.
>
>	Questions/Comments:
>		- Connection based accounting not the only model.  File
>		  transfer models need to be taken into account as well.
>
>Protocol Overviews
>==================
>
>Overview of COPS (Raj Yavatkar, Intel)
>
>	- draft-ietf-rap-cops-02.txt
>
>	- Protocol solves the QoS intra-domain policy exchange problem.
>	- Front End
>		- Standard device policy infrastructure
>		- Simple for PEPs
>	- Back End
>	- Stateful request/policy decision functionality.
>	- Securable with IPSEC
>	- Re-uses RSVP objects where possible
>	- Fault Tolerant
>	- Accounting information specified in reports.  Provides information
>	  not service.
>	- Extensible
>	- COPS is not a AAA protocol

>	- COPS does not resolve the BB-BB problem.
>	- Authorization
>		- policy based admission control
>		- bi-lateral agreements
>
>Diameter Overview (Pat Calhoun, Sun Microsystems, Inc)
>
>	- General purpose AAA protocol
>		- draft-calhoun-diameter-framework-01.txt
>	- Code from Merit 
>	- Uses RSA Encryption, hooks for digital signatures
>	- Diameter is a peer-to-peer protocol
>		- Server can initiate requests of client
>	- Makes use of SLP for service discovery
>	- Proxy support
>	- Resource Management capable
>
>General Discussion
>==================
>
>	Fritz/??: Some operations for centralized management are requiring
>		  LDAP and RADIUS for AAA.
>
>	Ed Reed/Novell: Infrastructure of Trust vs Chains of trust.  Look
>		at and understand end-to-end trust.
>
>	Scott Petrack/Vocatel: 
>		- No AAA pixie dust.  We may need current and future
>		  Internet drafts to state it's AAA issues and requirements.
>		- Separate the problems of AAA as much as possible.  
>		- Time considerations are very important especially for call
>		  set-up. 
>		- AAA solutions with regard to resource management, need
>		  to consider the future resource reservation problem.
>
>	Rich Vetlay/WorldCom: 
>		- The Internet is a network of multiple spheres.  Hence,
>		  operational requirements need to be addressed.
>		- Accounting and security are very important.
>
>	Shai Herzog/Iphighway:
>		- We are on a slippery slope.  Have we figured out what the
>		  problem space and requirements yet?
>		- AAA is not one size fits all.
>
>	Glenn Zorn/Microsoft:
>		- There is a class of problems that be solved by a AAA
>		  protocol.  Let's get started.
>
>	Matt Holdredge/Ascend Communications:
>		- Modularity of the protocol is important.
>		- Service providers need to give input to the process.
>
>
>	Charlie Perkins/Sun Microsystems
>		- We can classify the problem width regard to Mobile IP.
>
>	Scott Perkins/????
>		- What are the requirements of the AAA protocol?
>
>	Alan O'Neil/IIT
>		- Diff-serv needs to supply requirements when they have a
>		  notion of their requirements.
>
>	John Halbreck/Merit
>		- AAA needs to be stateful.
>		- Size of the problem space that gets solved with AAA is
>		  of concern.
>
>	Shai Herzog/IpHighway:
>		- A previous attempt to solve Inter-Domain policy exchange
>		  was the Internet Policy Control working group.  Let's learn
>		  from this failure.
>
>Actions:
>========
>
>	- Open a mailing list
>	- BOF in Orlando
>	- Outcome of the BOF is a requirements document
>	- AAA Working Group in General or Ops Area with a view to solving the
>	  AAA problem
>	
>	- aliases: [email-masked]
>		   [email-masked]
>
>	- Drafts open for consideration:
>
>		draft-calhoun-*
>		draft-ietf-rap-*
>		draft-<yourname>-aaa*
>		draff-aboba-acct-req-00.txt
>
>	
>	
> 
*------------------------------------------------*
James Rafferty			
President, Human Communications 	
12 Kevin Drive			
Danbury, CT  06811-2901		
USA					
Voice/Fax:  +1-203-746-4367
Email:  [email-masked]
	 [email-masked]

HC Web Site:  http://www.humancomm.com  
*---------------------------------------------------