[LinkSec] notes from teleconference July 1, 2003
7/1/03 LinkSec 802.1 Meeting
Chair Dolors Sala, dolors@ieee.org
Notes Allyn Romanow, allyn@cisco.com
Summary:
Discussion of authentication issues as in Bob Moskowitz's note.
Please look at Bob's architecture slides and send comments to Bob or
the mailing list
Also send comments on the authentication doc
Next week teleconference meeting - go thru Bob's architecture slides
===================
Attendees:
Tom Dineen, Dolors Sala, Dan Romascanu, Bob Moskowitz, Mani Mahalingam
Bob Moskowitz just sent out slideson architecture
Bob updated slides based on people's comments
he has a better understanding of authentication
see his write-up clarifying components of authentication
Client server or peer to peer authentication relationship
how to handle race conditions, when both sides start at the same time?
does it constrain key management?
separate from authentication, but sometimes key management is buried inside
may follow after identity exchange
peer to peer - if one is always the responder, i.e., server
HIP is Bob's protocol
needed in ad hoc peered network, bridges
Problems, how do you handle race condition - who starts?
sometimes doesn't matter
maybe matters who starts
If you have the peer state machine, how can you work in client server mode?
no control over which end station starts the process. It is stochastic,
either one can start, may both start - then you have a race condition,
How resolve? one station needs to function as server, determining flow
IKE is a peer model, doesn't matter who starts, produces interesting problems
There is a billing issue- Bob will state it more clearly later
With client server model, you know who is doing the billing
With peer model, it's not so clear who's doing the billing
Tom - billing is done in software above authentication
Authentication just confirms who the parties are
A higher level of software does billing, policy, QoS
It may be that the policy determines what role is taken in
authentication, in order to work properly
Tom - let billing be part of the session layer
Why did .1x do client/server?
Bob- it was low hanging fruit
They were looking at a device on switch, not looking at trunks
Client server is easy to do, easy to think about
Bob - last week Ad Hoc .11i meeting - 15 people, the key people
major issues with Ad Hoc, race condition, two SAs, will fail...
All of ad hoc .11i needs to be changed
Pre-shared key works, but .1x doesn't work
A few people feel this way, not accepted by the whole group, yet
Tom - software state machine, a couple of extra states not
significant, so there shouldn't be much of an issue moving from peer
to peer to client/server model.
If client server and need to do peer to peer - difficult, race conditions
Emulating client/server from a peer to peer model is easier, because it's a
subset
Bob is working with Paul Congdon and Jim Burns on PAR for changes to .1x
Bob will have a presentation at the Plenary
how discover who you are going to set up your security with
.11i it's clear
but on an ethernet, how find the bridges
Interim meeting - Why was it we are not going to Italy?
Because resort is too small for both groups at the same time
Some people think this group should meet in conjunction with .3, for
economy
Dolors will check with Tony to confirm that it's not possible to meet
in Italy back to back with .3
Please look at Bob's architecture slides and send comments to Bob
Also send comments on the authentication doc
Next week teleconference meeting - go thru Bob's architecture slides