Re: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt
> "Dan" == Dan Harkins <[EMAIL PROTECTED]> writes: Dan> Sam, Dan> The keys in this hypothetical protocol are for network Dan> access and giving them to authenticators for that purpose Dan> would seem to fall under the "key scope" requirement. Key scope means giving an authenticator a key for a specific purpose--something like authentication for network access between peer foo and authenticator bar--not something general like network access. Dan> These are not session keys so the text relating the session Dan> keys is not applicable. O, I definitely think they are session keys. Dan> So the domino effect is the only text that could seem to Dan> prohibit this. As long as the same key wasn't given to more Dan> than one authenticator though then this is satisfied. A way Dan> to prevent the same key being sent to different Dan> authenticators is to allow the authenticator to choose an Dan> identity to advertise to the peer-- "I'm 'foo'"-- and to tell Dan> the server-- "give me a key specific to 'foo'". That identity Dan> is mixed into the key derivation function. This is Dan> essentially what 802.11r is doing. This has channel Dan> binding/lying NAS issues though. I'm not quite sure yet what Dan> HOKEY is doing in this regard (how is the distributed key Dan> separated from other keys) but it appears to suffer from the Dan> same problems since people are advocating solutions that do Dan> not fix this problem. Wait, what's wrong with giving 100 authenticators 100 different keys provided that each authenticator is authorized to claim the identity it plans to claim? Isn't that exactly the sort of thing we do want to do? BTW, I think your questions exploring what key scope and session keys mean are good. The only issue I'm asking you to step away from at this late point in the process is the question of whether clients should be involved in deciding who their keys are given to. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt
Sam, The keys in this hypothetical protocol are for network access and giving them to authenticators for that purpose would seem to fall under the "key scope" requirement. These are not session keys so the text relating the session keys is not applicable. So the domino effect is the only text that could seem to prohibit this. As long as the same key wasn't given to more than one authenticator though then this is satisfied. A way to prevent the same key being sent to different authenticators is to allow the authenticator to choose an identity to advertise to the peer-- "I'm 'foo'"-- and to tell the server-- "give me a key specific to 'foo'". That identity is mixed into the key derivation function. This is essentially what 802.11r is doing. This has channel binding/lying NAS issues though. I'm not quite sure yet what HOKEY is doing in this regard (how is the distributed key separated from other keys) but it appears to suffer from the same problems since people are advocating solutions that do not fix this problem. Finally, I'm not trying to delay anything. I said it before and I'll say it again: if the general feeling is that the I-D already addresses these issues or there is no consensus to solve the problem then publish it as an RFC. It is important to have an RFC talking about these things, it's just my personal opinion that it does not go far enough. Dan. On Tue, April 3, 2007 5:23 pm, Sam Hartman wrote: >> "Dan" == Dan Harkins <[EMAIL PROTECTED]> writes: > > Dan> Sam, > > Dan> I guess the question is, what text in this I-D would > Dan> prevent a new key distribution protocol based on AAA in which > Dan> the authentication server sent a copy of the peer's keys > Dan> willy-nilly to every authenticator it had a security > Dan> association with? > > First, note that I do not claim we have the text right; I'm asking > Russ and Bernard to evaluate that. > > So, I'll tell you what the closest text is for this, but you are > welcome to argue that the current text does not reflect our consensus. > > Under limit key scope: > >Following the principle of least privilege, parties MUST NOT >have access to keying material that is not needed to perform >their role. > Also see: > > Strong, fresh session keys > >While preserving algorithm independence, session keys MUST be >strong and fresh. Each session deserves an independent session >key. >A fresh cryptographic key is one that is generated specifically >for the intended use. In this situation, a secure association >protocol is used to establish session keys. The AAA protocol >and EAP method MUST ensure that the keying material supplied as >an input to session key derivation is fresh, and the secure >association protocol MUST generate a separate session key for >each session, even if the keying material provided by EAP is >cached. A cached key persists after the authentication >exchange has completed. For the AAA/EAP server, key caching >can happen when state is kept on the server. For the NAS or >client, key caching can happen when the NAS or client does not >destroy keying material immediately following the derivation of >session keys. > > Prevent the Domino effect > > Compromise of a single peer MUST NOT compromise keying material > held by any other peer within the system, including session > keys and long-term keys. Likewise, compromise of a single > authenticator MUST NOT compromise keying material held by any > other authenticator within the system. In the context of a key > hierarchy, this means that the compromise of one node in the > key hierarchy must not disclose the information necessary to > compromise other branches in the key hierarchy. Obviously, the > compromise of the root of the key hierarchy will compromise all > of the keys; however, a compromise in one branch MUST NOT > result in the compromise of other branches. > > I think given these requirements what you propose would not be > appropriate. > > > Dan> Another question: has the peer no say in to whom its > Dan> secrets are disclosed? If you think it does then what in the > Dan> I-D addresses that concern and if you don't think it does > Dan> then why? > > I find no requirements related to this. I do not believe there is > consensus to have such requirements nor do I believe it appropriate to > delay the document while you attempt to build such a consensus. > > --Sam > > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
> "Dean" == Dean Anderson <[EMAIL PROTECTED]> writes: Dean> On Mon, 2 Apr 2007, Sam Hartman wrote: >> The IETf learned of Brown's patent application on 2006-11-29. Dean> Can you elaborate? From whom or what source did the IETF Dean> learn of the application? The IETF learned through an IPR disclosure filed by Brown. You can see that disclosure on our IPR disclosure page. >> At the IESG telechat held the next day, the IESG decided to >> withdraw approval and the general direction of its mesage to >> the community. A significant delay was introduced while the >> IESG reviewed its note with the IETF's lawyer. >> >> >> Please note that Russ recused himself from the decisions >> regarding this draft. Also note that the 2006-11-30 meeting >> was well before Russ knew he would be appointed IETF chair. Dean> What was Housley's position on the earlier elliptic curve Dean> crypto patent discussion that was suppressed on DNSEXT, and Dean> was subsequently a topic of the PR action against me? Dean> I don't have a record of Housley recusing himself from those Dean> related issues. Dean> -- Av8 Internet Prepared to pay a premium for better Dean> service? www.av8.net faster, more reliable, better service Dean> 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon, You observed: > > Normal IPR disclosure process is to alert the IETF community via > > the IETF > > website that a patent has been filed. I mistakenly thought that > > adding the > > boilerplate IPR statement at the top of the ID was sufficient to > > say what > > needed to be said. However, I don't think IETF requires the > > disclosure of > > an unpublished patent application. > > I believe that is required even for patent applications. RFC 3979 > talks about patent applications in several places. You're right, please let me correct myself again here. My use of the term "disclosure" was sloppy. Here's what I was told by IESG: > >The IESG has been informed by Mark Brown that he had knowledge of the > >September 2005 patent application filed by his employer at the time > >he submitted draft-housley-tls-authz-extns. Accordingly, he was > >obligated to disclose the existence of this patent application upon > >making this submission. Making a required IPR disclosure after a > >draft is approved does not meet the requirement to promptly make the > >disclosure. According to section 7 of RFC 3979 failure to make a > >required disclosure is a failure of process. It should be noted that > >the above disclosure obligations apply to unpublished patent > >applications. When a patent application that is required to be > >disclosed is unpublished, the discloser must 'indicate that the claim > >is based on unpublished patent applications', but is not required to > >list the application number (see RFC 3978 Section 6.4.1). The content of the IETF-required IPR disclosure is this: 1. (YES) "the discloser must 'indicate that the claim is based on unpublished patent applications'" Not these: 2. (NO) "list the application number (see RFC 3978 Section 6.4.1)." 3. (NO) otherwise publish to the IETF the pending patent claims or description of the invention disclosed in any unpublished patent application(s) What I meant to say in my earlier email is that I don't think IETF requires disclosure of the body of the patent application, it's claims, etc. as in (3). I recognize that IETF does require the required IPR disclosure made via http://www.ietf.org/ipr-instructions as described in (1). This probably isn't news to any of you, but I wanted to correct my sloppy use of the term "disclosure". Thanks, mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Harald, I want to apologize again for screwing up the IPR disclosure process. Normal IPR disclosure process is to alert the IETF community via the IETF website that a patent has been filed. I mistakenly thought that adding the boilerplate IPR statement at the top of the ID was sufficient to say what needed to be said. However, I don't think IETF requires the disclosure of an unpublished patent application. I finally made my disclosure on the IETF website (what I mistakenly thought was a second disclosure) after my patent got published. And, in all honesty, even this disclosure got delayed because I sought advice. Please note that the filing's publication, the delay, and the IPR disclosure all happened after the last IETF approval for the ID. The right thing to do is to use the IETF website the very day your file your first ID, and not hope that the verbiage atop the ID will somehow disclose that IPR filings are in progress. As a result of my mistakes, the IETF withdrew approval of the ID and explained the process to me. That's fair. But please keep in mind that even for important things, it's easy to make mistakes your first time through a process. --mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
