HOKEY Meeting minutes: ---------------------- Key Management Document ------------------------ * Discuss overview of document * Discuss open issues Charles : Delivering EMSK is not part of this document. Should be in ERX. Yoshi : Is there going to be only one way to distribute the key ? It should depends on the security requirements. Charles : ERX already meets the same requirements as this document. We better have a good reason of having more than one method Yoshi : This problem is related AAA proxy issue as well Glenn : It is impossible to use this in any other network than a network where everybody knows everybody. So I don't think we have to worry about that. Sam : What is the name of the key I'm encrypting ? Yoshi : CK(??) is the key name Sam : If backend auth can find CK, how does the party thats doing to do the decryption going to get that key Yoshi : Distributing the kye is based on pre-existing trust relationship. Sam : Sure but no protocol is currently doing that. Charles : That is a correct statement. The keys are provisioned. Sam : You need to look at RFC3147 and explain how to deploy in this in an inter-organizational scenario. There are details that are missing. Yoshi : Agree that explanation is missing for that. Lakshminath : I see a lot of interesting new keys in this presentation but its clear that some keys are not yet decided. So why is it here ? Paul : How open are the remaining open issues ? It seems some issues are still being added. Charles : The issue list on the slides are for 00. New issues will be added for 01. Yoshi : For Issue 28, 01 still mandate key encryption between server and 3rd party. We would need end-to-end security for this. Glenn : If we don't allow hop-by-hop encryption, there does'nt seem to be a big difference between hop-by-hop and end-to-end security. Sam : What are identical ? Trust models are not the same. Lakshminath: We already had a consensus in the last IETF. We should not rehash this again. Proxies in AAA Key Management ----------------------------- * Housely criteria became RFC 4962 * Presentations offers personal opinion on AAA proxy and not some sort of mandate * Two environments to consider - Enterprise - Service Provider Glenn : In very large enterprise, proxies are also used so environment categoris may not be accurate Russ : At the least, we get the point that in more complicated environment, the difficult exist * In server provider proxies, key sharing cannot be avoided * We take a pragmatic approach - Limit key scope - Authenticate all parties Subir : Is it a consideration for proxies for stateless and stateful. Russ : Have not considered this but the bottom line is that they can have a key regardless if they are stateless or not. Dan : In the service provider scenarios the client does'nt really care as long as service and billing are consistent. Why is it troubling case to have proxies ? Russ : Your right. To re-word, what troubles me is the key sharing. It is also better to have one solution that fits both environment. Bernard : Its not clear to me what the point of this exercise is. People should understand the consequences of a security architecture; i.e. if they have proxies in their network. IETF does not/cannot enforce security requirements of a deployment or architecture. Sam : RFC4962 does not mean the same thing for everybody who reads it. Some subtle things are going on. It is important that we generate documents that is consistent with established security requirements. There are also additional questions on Channel Binding. There are areas where there is no consensus. We should solve the problem correctly rather than piece meal. I think it cannot be solved in this area and without re-interpreting 4692. We need to uderstand what it means in a practical deployable system. We can discuss it here but we cannot resolve it here. Tim : I agreed in some ideas in the presentation. We need serious effort to to sort the details and requirements. People really do deploy proxies so we need to figure this out. Yoshi : AAA proxies is indistinguishable to other parties. Are we saying we cannot distinguish this on the network side ? Russ : From the client side, it is indistinguishable. Bernard : I just want to make sure that the IETF does not enshrine the use of proxies in its architecture. Lakshminath: What are the next steps ? Seems like were going down a slow boat. Bernard : I strongly disagree that there is no consensus on this. There has been many discussion in the past. Sam : If you have a document that supports credible end-to-end keying then its clearly within RFC4962. Paul : There seems to be a process issue, we have two(2) authors who does not agree and two(2) security ADs who do not agree. So folks should consider a reset until we do get some consensus. Lakshminath: There was reasonable amount of consensus in the mailing list. The mis-understanding was limited to two(2) documents. The only thing I see is the quest for perfection on everything. The only thing your trying to protect is service. We need to step back and see what were actually solving. Tim : The group is doing good work and making progress. Some guidance is needed. Glenn : What Russ is talking about is an authorized provider masquerading about the cost of service. A service provider that is lying. ERP --- * Carrying ERP message over AAA - easy part Glenn : TLS is a SHOULD in the diameter base. You MUST specify TLS in this document because 3588bis won't do it for you. Yoshi : I'd like to make sure that if this is used as a key managmenet transport. This means that a radius/diameter attribute that is key encrypted and integrity protected. Charles : Yes. Joe : I dont understand the question. Charles : The quesiton was that if you have a separate key for securing transport. Joe : Are we saying that security is provided by the transport or this mechanism ? Not clear if this is sufficient. Charles : We need to look through the requirements. Still some open question and consolidation needed. Lakshminath: It make sense to have a group of people to work on this. Yoshi : Key wrap and hokey have some overlap Charles : I dont want to have multiple protocols. Keep it simple, single consolidated solution. We have to preseve the properties that exist in 3 party keying Yoshi : Not sure what would be the outcome of considering key wrap and key managment. Charles : Need more discussion. Lakshminath: There is an alternative solution for a 3 party protocol. Glen : We had decided that 3 party protocol was not going to work. We had a strong consensus on that. I have repeated this to the authors many times but its ignored. Sam : You and Charles should agree first. Charles : This maybe some terminology issues in the presentation. Subir : There are many different views. Other say we don't need 3 party some say its ok. Charles : 3-party is channel binding and end-to-end security. You can do hop-by-hop or end-to-end but you end up with 3-party. Sam : If radius/diameter gives an end-to-end solution then channel binding should be enough Glenn : radius/diameter does not give us such solution. radext people claim they have something like that. Yoshi : I'm confused about the position of the hokey on key managment. Is WG going to duplicate the work on this document or simplify it ? Glen : If a 3-party protocol is desired then it must work in all of the situation we talked about. I have asked the authors about this but nobody has done it yet. Lakshminath: We have two models. hop-by-hop and end-to-end. We want to design for both models. hop-by-hop maybe good enough for now and end-to-end sometime in the future. We should look at it as two(2) models and two(2) solutions. Tim : I'm surpprised to see 3-party back. I thought it had to do with confusion with RFC4962. Perosnally hop-by-hop is ok. As AD, we need to focus and get things done. We need some kind of consensus call. Maybe something to sort on the list. WG charis have to have a clear summary as a goal. Charles : I guess the first step is remove 3-party from the title. Sam : I don't udnerstand. First, why is this hokey problem ? Second, why are we solving this for DSRK. Why are the requirements here different from MSRK. Is this maybe charter issue ? Is this somehow hokey specific ? Lakshminath: I agree. It's still key delivery in the AAA context. Its good to solve this in the AAA level. Charles : An assessment is that the key manangment doc has two much and ERP doc which has too little. Glen : I see the point of channel binding but I dont see the point of NAS name. I propose that we try to discover the qualities that would be interest to a HOKEY client ... not just a NAS name Lakshminath: Just a clarification, the attributes are a blob; i.e, there are the types of channel binding that say, 3gpp can use for example Glen : The point is that ts gotta be knowable to each system involved. I think we need to be more specific about what is not meaningful. Dan : If there is some attribute in the network that you want to bind, AAA has to know whether the NAS should be advertising the service thats being bound. Sam : Some of the attributes don't need to verified by all the parties. It may not actually matter whether the AAA can verify that. The guy at other end of an SA is where the key would be given. Its sounding messy if other parites get involved. Laksminaht: It is simple and interoperable since we don't build architecture here. We just build building blocks. As long as we are clear on how to use these blocks. Glen : As long as you dont require things in the attribute that others may not understand. I just dont want to specify things that wont be used. What does domain mean --------------------- * Related to EMSK key derivation document * The EMSK derives DSRK (domain), what is domain really means ? * Proposal - define general key management domain - specific usage define how entities are organized into doomains Joe : Is this a good definition ? Glen : A quick comment, EAP will never be used without AAA anyway. Joe : That maybe fine, so domain maybe a hokey specific term. I would not make it as generic as it is now. Paul : I'm confused with the text. Is it saying a member of the domain must not make use of keying material ? I think this is a bad thing if its saying "Your really not suppose to use this key but it may be a good value to you". Charles : The keying material should have a scope and context. Joe : We can work on the definition and there are deployment models. There are parties that see that key. Going back to earlier discussion, a proxy maybe consider part of the domain. Lakshminath: I think this is a word smithing problem so we should be direct about it. We should be direct about are the requirements. Joe : We need a threat model supporting the definition. Dan : If we say must not do something then we should have a way of enforcing. We should say what the impact of not following. Joe : We often say "must not" but IETF cannot enforce it. Dan : Here we are assuming that were giving the key to other parties. Beranrd : The definition of a domain is more than one system. Tim : A proposal is that you can replace two sentence with a must not to something positive. Charles : We might also want to add scope and context. We can take it to the list. This is the only open issue. Pre-Auth Problem Statement -------------------------- * Status - Merged document with AAA requiement draft by Madjid * Reviewed by two IEEE 802.21 WG members * 01 submitted in October * Changes - link layer description is out of scope - description on the provisioning of servers - recommendation on non-cryptographic filtering Charles : Bring it to the list for review. Tim : Folks wishing to discuss EMSK document will disucss offline (after meeting)