HOKEY Working Group Meeting IETF 68 March 19, 2007, 9:00am - 11:30am Minutes Agenda - blue sheets - note takers WG status. done: - Re-auth problem statement v00 - EMSK keying hierarchy v00 - Many milestones before IETF69 - WGLC for problem statement - WGLC for EMSK hierarchy EMSK Keying Hierarchy (Joe Salowey) See presentation slides - [??]: how is the domain specified? - Joe: the domain label would have to be specified by another spec Out of scope for this draft. - Yoshi: this is a good approach - Glen: I think that the diagram is misleading. DSUSRK and DSRK should be at the same level. - Charles: we need domain-unspecific keys. e.g., cross-realm authentication, say in Kerberos - Hao: Always generate a DSRK, but generate it with a null domain. Discussion about why/how/if there is any point. - Madjid: May be able to derive DSUSRK from the USRK too! - Charles: specify minimum amount of things for interoperability. - Hao: Wouldn't it be better to specify one option? - Joe: DSRKs alone are sufficient. We can derive DSRKs with NULL domain. - Vidya: We could derive a Cross-domain root key and derive keys from there. But, in authors discussion it was considered spurious. - Hao: Easier to implement if there is a generic derivation. - Vidya: You can if the two inputs are NULL. - Glen: Let's move on. Conclusion: seemed like approach was generally okay, but we need to take it to the list for further discussion/consensus EAP-ER (Lakshminath Dondeti) See presentation slides - [??]: the initiate/finish is confusing. Isn't it query/response semantics. - Lakshminath: these are new protocol codes, and is a new protocol. "EAP-ER" is not an EAP method, it's a new protocol. - Glen: Is EAP-ER a viable candidate for HOKEY re-authentication protocol? Hum for: weak Hum against: none - Madjid: There are two items: Protocol and Key Hierarchy Is this being proposed as for both? Could we separate them? - Lakshminath: Just because there are 8 different items in the charter, we don't need to write separate docs. - Tim: It's a good thing to reduce the number of documents; it's the chairs' decision. Conclusion: some support, need to talk about 3-party protocols 3-Party Key Distribution (Yoshihiro Ohba) See presentation slides - Glen: At least 2 out of 3 things are not possible with AAA. The authenticator cannot lie to the server. It may to the peer. - Yoshi: If the deployment is not correct, the identity of the authenticator may not be bound to the AAA protocol SA. - Hao: Q on #6. Why is this needed? This doesn't work with AAA. - Yoshi: Peer can request a key before/after handover. Peer needs to consent - [??]: What is consent? - Yoshi: Peer says give the key to an authenticator and it is integrity-signed ... - Glen: Apparently some of these requirements need rationale. If there is one, put some rationale. Moving on ... we recognize the questions and we need to take that list. - Charles: Is the security association between HOKEY srvr and EAP server, AAA based or a new thing? - Yoshi: it could be anything One security association applicable to only this app - Glen: According to various AAA RFCs, there needs to be a preshared key between AAA server and AAA client. Are you trying to solve the problem of sharing passwords, like cisco123? Is that the kind of deployment you are talking about. - Yoshi: No. - Glen: then I don't understand the problem you are trying to solve. - Lakshminath: Are we reinventing AAA? - Yoshi: We can use the hierarchical trust relationships. - Hao: Doesn't solving the channel binding problem solve this issue? - Yoshi: If the AAA deployment is doing something wrong, it doesn't work. - Glen: if you are trying to protect against bad deployment, ... I don't think we need to worry about - Hao: A bad implementation cannot be fixed by a protocol. - Yoshi: if proxying stuff is broken, .... - Madjid: I am trying to provide clarification: we are not trying to solve shared secret problem. we are going to use the infrastructure. the other thing is, as part of the general handover keying problem ... AAA server to authenticator home to visited domain authentication and other stuff that may be out of scope. Peer consent and identity verification we are trying to see if 3-party key dist solutions work it is not new; putting identities in the key derivation ... we may have problems with hop-by-hop but that can be solved - Dan: channel binding needs to be solved for initial authentication. we need something like a 3-party key dist protocol - Glen: it is not clear to me ... It doesn't matter what the peer thinks the name is as long as it is the same. - Dan: the peer may not know ... - Glen: it doesn't matter what the identity is as long it is the same - Dan: one identity to the peer and another identity to the server; - Glen: what is the security threat does it enable. security mechanisms that do not address threats are play things; we don't have the time to waste. - Madjid: let's not worry about the threats; the identities are needed for key derivation. - Vidya: Agree with Glen. What is the effect of the vulnerability? different identities in different directions is a problem but can be solved with simple techniques. The peer may not want to reveal its identity to any network it enters; for instance to a hotspot provider. Are we talking about consistency of identities or correctoness also - Simon: the problem of lying authenticator to the peer has a security threat and that is solved by mutual authentication. - Glen: that threat doesn't exist in EAP. It will be impossible for the authenticator to force a peer to use a key without the peer's consent :) - Simon: If the authenticator is distributing keys, we need to authenticate it. - Glen: but the authenticator is not distributing keys. this is a problem if we are transfering keys. what we are transfering the moral equivalent of the MSK. Let's talk about it offline. - Joe: all the talk about identities; they are useful; but we need to talk about the relevance of identities in our protocols; in many cases, the authorization aspect is sufficient for network access. More discussion on Otway-Rees - Lakshminath: What are the identities? - Charles: we can use the pseudonyms like key names - Vidya: do we need a separate key between every b and S? - Madjid: Let's discuss that separately. - Yoshi: the actual issue is key distribution problem. If the key distribution part can be solved with AAA deployment. - Charles: As long as we are reusing the AAA security association, then there is no problem here. If people think that peer consent is an important issue, we need to discuss that. - Yoshi: security association for Kbs should be at a higher layer than AAA. - Charles: If this is a proposal for changing Kbs, then that may influence people's opinions. - Glen: after the HOKEY interim mtg is when the 3-party key dist solution came about but here we are and we don't have a completely fleshed out issue. - Dan: EAP-ER sends a message; what is in the message? - Glen: let me make this clear: I do not mean EAP-ER is a complete solution as it stands. what I am saying is that the two proposals are not at equal level of specification. - Madjid: there are other proposals on KH that are not even discussed here; and they have been out there for a long while - Glen: what I see in yoshi's presentation is a protocol There is my KH draft that does talk about KH. I need a more complete specification to call for consensus. - Madjid: combine stuff ... - Charles: Are the authors of the proposal ok with EAP-ER if ideas from here are picked up? - Madjid: that's my opinion. let's pick the parts that people agree on from EAP-ER and write a new document. - Yoshi: summarizing: we cannot use EAP as transport. EAP is 2-party and what we are proposing is a 3-party protocol. - Tim: A couple of observations: the timeline is important and the work is critical; we do want to see the group keep its momentum it seems to be that everything needs to be driven from PS the 3-party protocol seems to say that the PS is not complete; the WG needs to consider the new requirements and decide whether those things are in scope for this WG I'd recommend that you consider those issues. If the PS is correct, then it is clear where we need to go. - Madjid: may be we didn't consider all the requirements ..... - Glen: since we are giving opinions ... does the HOKEY protocol, do those things need to be more secure than the initial authentication? that trust model is fixed do we need to improve upon it? - Madjid: the new extension is not at the same level of security - Lakshminath: disputes it .. - Vidya: clarifies: 3748 and 3579 also covers it. - Glen: my sense of the consensus in San Jose is that there were keys distributed to the HOKEY server and the authenticator will not get them. You need to trust the HOKEY server ... If things are broken, we need to come up with a solution very quickly... (Yoshi and Glen debate) - Glen: Please say yes or no on the list. Do we need to rethink the entire the AAA/EAP trust model to include explicit authentication to the peer? If we don't, we can continue on the path of the consensus in San Jose. Conclusion: Chairs will draft a series of question to go to the list to help determine consensus