Chairs: Paul Krumviede (
[email protected]), Brian LLoyd (
[email protected])
Minutes: Steve Moulton and Dave Mitton
Brian Lloyd introduced the new chairs and started a discussion of purpose
of the group as currently chartered. A list of "nots" was presented:
- not a protocol development group
- not the Diameter WG
- not the COPS WG
- not the RADIUS WG
Want to look at the applications and services that need to use AAA
and look at their characteristics and requirements. An initial,
non-exclusive list was presented to start with:
Remote Access, L2TP
VPNs (IPsec and others)
Bandwidth Broker
VoIP
Mobile IP
others?
Additional suggestions from the floor included: web repositories,
information repositories, e-commerce, news servers,
management control services, system login, printing.
Authentication access to content and administrative data suggested;
not clear if this in scope.
Someone asked if we should/could work on definitions first, but consensus
favored working applications requirements as we were proceeding.
Should we define applications that are out-of-scope? like POP/IMAP which
have their own mechanisms.
While we should try not to overlap other groups efforts, we should stay open
to other groups adapting our mechanisms.
It was suggested that we should try to fit into applicable current security
mechanisms (like GSS-API). There was also a concern that we may end up
duplicating other work (e.g., don't re-invent Kerberos).
Paul K indicated that he thought the charter too ambitious in some respects
and we will have to work on a subset of the general problem.
A discussion of authentication started by pointing out the multiple
existing techniques for authentication (e.g.: assertion, password,
shared secret). We need to define what persistent date is required
so that we can figure out what features are required in the
protocol(s). It's likely that we will need more than one protocol.
It was further suggested that we consider not just algorithms but
frameworks too (e.g.: EAP, Xauth, GSS-API). SASL has 13 different
techniques in draft status. It was pronounced that this WG isn't currently
working with transports, and will not discuss transports issues (e.g.,
UDP vs. TCP) at this time. Want to see what RUTS/SLUMS does.
The discussion of accounting started with enumerating some of the
different types of accounting services and practices.
transaction vs session oriented services
types of services
needs for billing
needs for resource and allocation, usage and network engineering
Brian claimed he believed accounting was a separable problem, unlike
authentication and authorization which seem to be intertwined.
There was disagreement from the floor, authorization may be dependent
on accounting data. Brian explained that state information dependencies
should not be tied to accounting services. Just because some RADIUS
implementations use accounting to compensate for lack of state, that
is not what I mean here.
A comment was made that billing doesn't need dollars counts,
just usage information. It was explained that this was the
intention of the item. That is collecting data for external
usage, but the requirements of different users will affect
the delivery and dissemination of the information.
Accounting definitions get fuzzy, we need to work the sources,
but not necessarily all of the uses. It was requested that
we will want to address both real-time and batch needs.
There will be desires to want to gather information together,
and do correlation and trend analysis. The information
should hold up to this kind of operation. This led to needs
for accounting correlation for the purposes of tracking
intrusion detection, yes?
Bernard: Needs may be different, but we should explore them.
MarkB: Need to separate accounting from monitoring. Not a byte/packet monitor
JohnV: Should put in the need for fraud detection system. Should keep that in mind.
This framework will generate lots of information for different users;
are we going to include mechanisms for customizing the information (views, cuts) ?
- PaulK: maybe, but that might be something we deal with later
Authorization
-least understood
- what is the relationship to Policy? they will interact
and we will have to define this
- Does it require authentication?
- Not always... sometimes entities may be talking among themselves
- authentication by assertion is sometimes used
m: more experience today... ACLs, etc.... policies that are used based
on your identity are often very service dependent. Hard to standardize
this... should look at common frameworks for authorization models.
ACL related: LDAP, IMAP, ACAP.... have these design features.
authentication can be implicit example mandatory tunnel setup,
sets up tunnel based on your phone number.
Denis Pinkas: authorization maybe interested in roles as a
dimension of authorization (role-based authentication).
CAT is working authentication - BrianL we are overlapping, and not doing protocols
<break>
m: scope? real -time payment methods - PaulK: not payment per-se,
but certainly a discussion topic there are other schemes in this
area (e.g.: IOTP) that we could tie into but not try to recreate it ourselves.
Will not rule it out, but won't rule it in either.
Protocols are referred to in the charter - we are trying to stall
that for now, as people are jumping straight into protocol messages
and data elements. Eventually we will push protocol issues out to
other groups and/or re-charter when we are ready.
JohnV - single or multiple authorizing parties; maybe more.
Accounting requires an identity not just a authentication,
distinct for tracking instances, and unauthenticated users.
Also authorization by role.
m: Non-repudiation? - PK: not going to devise a protocol, but the
accounting data may need this (as may other forms of data, such as
requests, approvals or denials, and authorizations).
How this is provided is open for discussion. Some authentication
methods may not allow non-repudiation.
FredB: could be certificates, could be detecting missing data
m: non-repudiation could be handled by transactions
Marcus: non-repud is a legal problem with soft boundaries, we don't want to go there.
Technical problems are difficult to satisfy.
Paul: the cost of supporting this is also an issue.
PatC: must take brokering into account, RoamOps would make this requirement.
Tomorrow:
- give presentations from subgroups
people to split up into subgroups and pursue initial issues
3:30 pm AAA
- groups to produce draft-documents by end of April
Strawman architecture diagram presented by Brian Lloyd and discussed
- Application AAA Focus Group (Alex, Siggy Maier)
Note that in some cases authentication and authorization may be based on
payment info rather than identity.
- Bandwidth Broker (Sue Hares, Shai Herzog)
note the desire to support multicast applications here.
includes dynamic allocation of bandwidth resources
domain chaining process
Basic Operations:
Requestor has authentication requirements
Grantor performs admission control to domain
Updates/Notification - needs may change, availability may change
SLAs - diagram of chaining
application to campus net to backbone provider(s) to remote lab net
wants to account for bandwidth used by connection
Question arose as to whether or not denial of service should be considered
in AAA. Marcus suggests solving the obvious cases first.
- Mobile IP (Stuart Jacobs)
Authentication requirements
scaleability
performance: at most 1 sec, inter-domain; less than 1 sec intra-domain
non-repudiation
two-way
One-way: mobile node to visited network
authentication data exchange
expedited re-registration authentication
Authorization requirements
Policy driven
QoS;location hiding; Tunneling; Dynamic/non HAs; other
Bandwidth broker?
Accounting
per mobile node
reconciliation
network port and addresses
traffic handled; bytes, packets, tunneled packets
NAIs used
integrity, accuracy
retention time
privacy
Fraud
RoamOps model
VoIP (Pat C, Ping Pan, Rosenberg)
AAA server is used to centralize the user VoIP profile, call handling features
support both user owned SIP client as well as public telephones
in public case, the authentication must be done between user and the home server
discussions on whether roaming is a suitable topic for discussion here
voip may require additional dynamic authorization and authentication to
setup fancy call features (3way bridging, etc.)
VoIP may involve billing requirements, and certainly inter-domain issues
SIP AAA server can return users profile, which can include calling
features, speed dial, etc.
Successful sequence indicates willingness to pay
AAA may/will keep state information about previous calls
Accounting; Start and Stop records (some SIP problems here)
E-Commerce (Jason Eaton)
diagram of Http/ssl exchange to Merchant server
Merchant talks SCMP, S/Mime, SSL to E-commerce provider
E-commerce provider does fraud detection, payment processing,
Fulfillment, address verification
Merchant and E-commerce Provider talk to Merchant bank
The bank needs to setup trust relationship and authenticate
NASreq (Dave Mitton - Nortel)
Need to support transition from existing RADIUS services.
Authentication (Mark Stevens - Lucent)
Examine current authentication technology
Outline the authentication requires of a good sample of application
correlate various authentication methods with requirements of applications
evaluate existing protocols and authentication for fit
publish informational document
BrianCarp: Do need to know identity of authenticatee before attempting authentication?
No, we don't want to go down rathole of distinguished names.
How many methods?, performance issues; should be a matter of policy
But the design goal should include performance issues, if there are
lots of iterations of authentications over the life of the individual
sessions. e.g.: Kerberos is considered a good approach because it
aids performance (can do local verification of tickets).
do we care about the survey?, we have to support existing techniques
yes, and some protocols have not chosen yet and may want to use whatever
this group may provide
Accounting (Nevil Brownlee)
references aboba and arkko drafts as pre-existing
19 I-Ds and 8 RFCs concerned with Accounting
Examples:
- RADIUS Accounting (RFC 2139)
- RoamOps ietf-roamops-acctng-05.txt
- Atommib (RFC2512) MIB
- Atommib (RFC2513) Collection & Storage
- ISDN (RFC2573) MIB
- RTFM (RFC 2063) Measurement Architecture
- RTFM (RFC 2064) Meter MIB
work on a generalized form for describe accounting data, maybe a file format
Accounting terminology (Bernard)
Application usage characteristics and needs: sensitivity to data loss,
delay, security needed. Differences between flat-rate billing and usage
sensitive or transactional billing used as example to demonstrate
different requirements.
Scaling and Reliability issues - contributing causes
attack the storage issue not the network protocol problems
Why not SNMP?
polling model is efficient
SNMP v3 provides security
adequate for intra-domain accounting
Issues with inter-domain accounting
access rights issues
index table by provider, or context use
but most MIBs are not structured this way
Bob Stewart; SNMP can be used in file transfer mode
Bulk transfer issues
high volume accounting
Push model needed in some cases; high value transactions,
fraud detect, sparse contact
m: some systems (ex: hotel checkout) will require push, as immediate
billing is required
mailing list
[email protected]
Interim meetings & teleconference: expect to have, will be discussed on list
Paul Krumvide <
[email protected]>
Brian Lloyd <
[email protected]>
Authorization Requirements (Pat C presenting)
6 drafts and RFC2477
George Gross discusses diagram of Policy Decision Points, PEPs, PDPs.
Notion of attribute certificates as possible approach for authorization.
Pat C discusses Inter-Domain AAA
