---------------------- Administrivia (Chairs) ---------------------- Note takers: Charles & Dave Nelson --------------------------- Problem Statement (Charles) --------------------------- - See presentation Clint: suggestion: include other group, 802.21, study group on security (issue created in tracker) -------------------- EMSK hierarchy (Joe) -------------------- - See presentation Vidya: DSUSRK from EMSK: peer needs to know how to derive key Joe: service either needs a way to signal which hierarchy to use, or specification should pick just one Charles: USRK distributed to an application, we don't have control over hierarchy from that point, so DSUSRK doesn't make sense. Could exist, but not normative. Joe: Agree Madjid: Want to avoid advocating the DSRK/DSUSRK hierarchy approach; should have a way to limit services DSRK can derive keys for Vidya: concerns about KDF for children to USRK -- services would need to use our KDF to ensure cryptographic seperation Lakshminath: are we done with the document, mostly? Madjid: why are we going down to DSUSRK? Charles: defining usage-specific keys, need to define until we get to usage-specific keys, which are DSUSRK and USRK ???: same concerns about hierarchy balance Charles: should we do EMSK-DSUSRK? Glen, ADs: fewer options = good -------------------------------- Key management/delivery (Madjid) -------------------------------- - see presentation Joe: DIK and DCK? What are they used for? Charles: D?K protects delivery of DSUSRK, ?K protects delivery of USRK and DSRK Sam, Glen: confused ... presentation continues, protocol described ... Charles: KCDS key needs to be somehow provisioned -- rely on AAA infrastructure instead? Sam: In order to meet 4107, you may need this, need key management solution to automatically provision the n^2 keys ... presentation continues ... Yoshi: major issue: how do we deal with proxies? Glen: RADIUS and MPPE allow end-to-end security, need a pairwise shared key Glen: could use Kerberos Tim: 3-party protocol needed? Lakshminath: what is 3 party protocol? Vidya: first authentication is 2 party, so why use 3 party for later authentications? 3 options arise: 1: hop-by-hop security with channel bindings 2: develop infrastructure to provision keys 3: investigate kerberos hums: eliminated #2 hand-count: #1: 23 votes, #2: 11 votes consensus to pursue option #1 ----------------- ERX (Lakshminath) ----------------- Tim: stick with current signalling, don't modify existing EAP messages - see presentation Glen: access reject may not close the connection according to other SDOs Vidya: are we interested in providing anonymity with key names (change with each use)? Room: no reaction or interest -------------------------- ERX Implementation (Kedar) -------------------------- - see presentation ---------------------------------------- RADIUS Attributes Document (Lakshminath) ---------------------------------------- Charles: just encapsulate protocol in key mgmt document Glen: use keyreq/keywrap Need further discussion on the list on how to best transport the key-mgmt protocol --------------- Preauth (Yoshi) --------------- - see presentation Charles: what types of protocols are you considering for signaling layers Yoshi: PANA or 802.21 over MIPSHOP protocols Discussion with ADs with regard to scope for inter-technology handoff Sam: not within scope Yoshi: develop problem statement, requirements, guidance document within HOKEY, and leave protocol implementation to other areas ADs: general agreement ... out of time, take to the list.