802.1AF - directions

1. 802.1AF - directions • define requirements to find and create connections in terms of Discovery - Authentication - Enable • Discover of what can be done and rule based decision resulting in specific requests for Action • Authenticate entities required for the connection requested by discovery • Enable [turn on] the actual connection

2. example of proposed sequence • Discovery • find what devices are available for connection • get capabilities of possible connections • request connection(s) as define by rules • Authentication • execute an EAP method requested remote • get session key • do authorization with remote • Enable • authorize based on AS requirements (not EAP authorization) • do four way handshake using key info from Authentication

3. 802.1AF Model Discovery Discovery backend(s) Authen Authen dev dev Enable Enable

4. Beginnings of Interface Requirements - Discovery • Intent is to find what opportunities for connection exist and request connection to what is best • Implies ability to find possible remote connection points • May imply knowing what each connection point can provide (e.g. what addresses it can reach) • Implies rules about how decisions are made • Group should review what is currently done and what people want to do [e.g. connect/disconnect to wired ethernet when wireless is available]

5. Beginnings of Requirements -Authentication • Assume that EAP style interface is preference • EAP methods allowed will have specific requirements and will include a “required” method • may have it define a required method and have it vetted by security community • Authentication will create keying material that will be passed to other elements which will use it to create keys for other devices • this should use well defined keying hierarchy model to be published by IETF • Authentication will have the ability [in appropriate circumstances] to reauth using key generated rather than reauthenticating and creating a new key

6. Beginnings of Requirements -Enable • This will do 4-way handshake • It will check some rules allowing connection [e.g. is it after 5pm] • It tracks connection establishment and points to physical connection info • It may get attribute information from the Authentication phase • It derives keys and Security Association for session(s) from material sent by Authentication phase • It tracks multiple connections based on the key from the Authentication phase

7. Enable - issues • what is the ouput of an enable - • just the connection, or other things like firewall • is the decision for framework or just for AF? • what elements are enabled e.g. - • time of connection • bandwidth • etc. • how is connect information maintained

8. Beginnings of Requirements-General • elements will talk to backend • may use RADIUS or Diameter or LDAP as appropriate. May also consider using SAML as is used by much WEB access and by Global Grid Forum • Security association is required between all elements talking to each other - possibilities: • secure connection between elements in machine • Security association between elements • Assertions of Attributes with proof of origin

9. Some other assumptions • Framework will provide tools to use in specific instances • each instance will use a limited number of tools which are specified for the instance • Architecture allows work on specific subjects independently of others • discovery can be defined independently of authorization • authorization can be vetted by security experts without knowledge of discovery or device specifics • 4-way handshake can is done independently of authorization • key derivation for Sessions is done outside EAP methods

10. Other applications to investigate • 802.11 connection and reconnection • EAP key hierarchy • EAP Network Selection Draft • Global Grid Forum • Discover required resources/ Reserve/ Enable • 802.1X • Oasis and WEB services • Other ??