Sam, The problem I see is that when AAA is used as a key distribution protocol there are 3 parties involved (peer, AAA server and authenticator) and it's a 2 party model. For existing protocols-- the peer is speaking to a NAS and the NAS obtains a key for the peer from the AAA server-- the problem of identity lying is somewhat contained. The peer is going to do a full re-auth when he goes to a new authenticator anyway so the shenanigans a lying authenticator can do with this key are somewhat limited. But for things like HOKEY or 802.11r they want to have the AAA server create a key hierarchy rooted off the EMSK or the MSK, respectively, that contains keys for specific authenticators. These keys are going to be distributed using AAA (that seems to be the plan) and either proactively distributed-- "here have a key!"-- or distributed on demand-- "gimme a key!" The authenticator-specific key gets produced by mixing in some identity of the authenticator and that key is then sent under the protection of the security association between the AAA server and the authenticator. The problem is that the identity of the authenticator bound to that security association is most likely an IP address and the identity that gets bound into the key has to be something different since the peer doesn't necessarily know that IP address (imagine an access point with a wired IP connection to the AAA server and a wireless connection to the peer, the peer knows the access point by the radio's BSSID and is completely unaware of anything about the access point's wired port). Since there is no binding of identities it allows an authenticator to say "give me the key for authenticator FOO" even though it is actually authenticator BAR. For instance the NAS-Id is put into a RADIUS request to ask for a specific key and the key is sent back protected by the shared secret bound to the IP address of the authenticator. Since this network access credential is symmetric all security properties that it could've had are are lost-- the lying authenticator can impersonate the client to the real FOO authenticator, it can inject traffic into a connection between the peer and the FOO authenticator, it can inspect traffic on a connection between the peer and the FOO authenticator. HOKEY wants to distribute keys across domains too so an entity in the sprint.com network can request a key for the verizon.net network. There is nothing in this draft that prohibits such flawed key distribution protocols. This draft does say that entities MUST be authenticated and that keying material MUST be bound to a specific context. It is these two things that proponents of these flawed key distribution protocols point to as evidence of their compliance to the "Housley Criteria". The 802.11r task group is convinced that as long as there a security association between the authenticator and AAA server (regardless of the identity bound to that security association) and as long as they mix some identity into the key (and again it doesn't really matter whether that has any relation to the identity of the security association) then they are assured to be secure. I'm sensing the same trend in HOKEY. There needs to be an identity binding of the key that is going to be generated and distributed. The peer and AAA server (the two parties that authenticated each other and hold the root of the key hierarchy) have to agree on who the key is being distributed to. The only text in this draft that talks about identities deals with the generation of a session key which takes place AFTER key distribution. That was why I suggested that text, as a way to effect such a binding. I don't think it's problematic for existing protocols because existing protocols don't include key distribution. I keep on being told that "AAA is a 2 party protocol!" Fine, we can play that game. The split between the NAS and AAA server is logical and the NAS functionality and AAA server functionality can reside on one device. That's existing protocols today. But when there are multiple authenticators involved we can't play that game anymore. When AAA is used for key distribution to multiple distinct entities then I feel we have to meet a new standard. Dan. On Wed, March 7, 2007 10:53 am, Sam Hartman wrote: > Dan, again, with the text as it stands, what attacks do you see > permitted by these requirements that you believe should not be > permitted. > > The text changes you proposed were considered but are rather > problematic for existing protocols. I don't think we mind mandating > changing protocols for real problems but we do mind doing so if we > cannot understand the problem we're solving. > > > I do agree that the proposed changes would be better using RFC 2119 > language. If the authors want to fix that in auth48, I'll permit the > change. However I think the language is clear enough that it is a > requirement now so I will not hold up the document for that. > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf