Re: IETF Diversity
On Wed, June 19, 2013 9:25 am, Melinda Shore wrote: On 6/19/13 8:12 AM, Peter Saint-Andre wrote: On 6/19/13 10:00 AM, Melinda Shore wrote: On 6/19/13 7:56 AM, Peter Saint-Andre wrote: Why do you believe that my opinions are unexamined? I have been thinking and reading about social, cultural, and personal change for a very long time. You made an assertion that's at least a little ahistorical, That depends on which historians you've been reading. Peter, it's a fact in the US and Canada that court cases preceded civil rights protections which preceded social change. This has been true for racial minorities, women, glbt folk, etc. I expect that there are historians who'd argue otherwise but allow me to suggest that if so they are very, very far out of the mainstream. Civil rights? A whites only lunch counter or drinking fountain is a matter of civil rights. When there is active prohibition on a class there is a matter of civil rights. But the mere fact that the numbers are overwhelmingly one-sided does not make a civil rights issue. Between 1995 and 2008, 84% of the people killed by lighting strikes were male. Is that evidence of discrimination? Is that a civil rights issue? What do you propose to do to rectify that statistic? Dan.
Re: IETF Diversity
On Tue, June 18, 2013 9:52 am, Phillip Hallam-Baker wrote: I am rather disappointed that there hasn't been any followup to the diversity discussion that took place at the plenary. I do applications and I do security and so having a diverse range of input is critical if the final product is going to be useful. There are no gender or cultural issues in packet routing that I am aware of. But once we get to the application layer they become central. Interesting. Can you explain what it is about the application layer that introduces gender and cultural issues? We seem to have interminable discussions about how to help some hypothetical dissident in (pick your authoritarian state). But I can't remember the last time we discussed Internet stalking which has been an issue women have been complaining about since I started getting involved in IETF. This is just one security issues that has a big gender bias and it is a problem that I think can be usefully addressed in an open consensus seeking organization. Internet stalking? Maybe you should call for a BoF to address the issue. I'm not sure what protocol can be developed, or modification to an existing protocol, that can address the stalking problem but I'm all ears! It does not take 100 people to write a specification but it does take a large number of people to adequately gather requirements. Taking requirements from 100 people from almost the same background and perspective is not very productive. I am aware that I have a limited personal perspective which is why I actively seek out other perspectives. Some backgrounds and perspectives aren't all that helpful. Would you like my liddite father's perspective? How about the brother of a friend of mine who has been institutionalized and is quite insane? We need to get requirements from people who understand and will use our protocols. If those people are all the same background then oh well, but creating diversity by just adding people of the correct background will not make our standards better. Which says nothing about having more women in I* leadership positions. That may be great. Or it might not be. It depends on whether the people have clue or not. See, that's the thing. IETF needs people who have clue not people who are members of some protected group that has been declared to be underrepresented. At the plenary I pointed out that there have been women involved in IETF ever since I started in IETF over 20 years ago now. Yet we have an IAB and an IESG with only one female member who is not ex-officio (according to their Web sites) Can you restate that as a problem? And also explain why it is a problem? The IETF is a community known for valuing consensus rather than seeking diverse views. I see a real risk that the consensus being built here is a false consensus built by excluding opposing views rather than a real consensus built on reconciling them. Bringing opposing views to this forum is invariably a thankless task. The assumption is that if you can't hack it here well that is your fault and your problem. Case in point, each time I get something wrong in RFC2HTML and I get the error message 'You Lose', my natural response is 'why the heck am I bothering wasting my time here'. An opposing view is one that thinks this whole diversity issue is crap. Do you want to ensure that people who view the diversity issue as crap are included in the consensus being built? How many people who are currently on the diversity mailing list view the whole endeavor as crap? If it's zero (which is my prediction), then isn't that a problem with the diversity of the diversity group? Won't the output of that group suffer because they are all of the same mindset? I do not think that gender is the only diversity problem in IETF but it is one that can be measured and the IETF is conspicuously failing. We also have a rather severe age problem, twenty years ago EKR and myself were among the youngest participants in most discussions and setting aside the grad students the same is usually true today. Gosh. I feel so left out. I'm as old as EKR (and probably you) and have been involved in the IETF for about as long as he has yet you do not include me in your measure of diversity. Do you think that maybe you have a problem with measurement of the problem? The perspective is going to need to change. Rather than looking for ways to encourage a few token women to work their way up through the existing selection regime we need to look at what sort of selection and participation and representation structures will encourage diversity. The IETF is a weird lot. We are predominantly type A personalities. There are quite a few Asbergers cases and many more borderline functional Asbergers cases. There are probably also quite a bit of people who have OCD and maybe a mild case of Tourettes). So you have to explain how the general studies of diversity mean anything here. How
Re: IETF Diversity Question on Berlin Registration?
On Mon, April 29, 2013 12:39 pm, Sam Hartman wrote: For what it's worth, I'm not finding the current discussion is providing me useful information for making decisions. It doesn't really matter to me whether the problem is selection of WG chairs or selection of IAB/IESG/IAOC after WG chairs are selected. I think it is valuable to attempt to improve both situations in parallel, and the sorts of conclusions being drawn from the statistical discussion we're currently having cannot possibly change my opinion on that issue. I'm not saying that my mind is closed to being changed; simply that I've considered all the possible conclusions that I think could be drawn from the analysis being considered and from my standpoint they don't affect how I'd feel about various proposals that could be brought forward. Sounds to me like you have the cart in front of the horse. You already have in mind various proposals (interestingly left unstated) and are looking for data that can justify them being brought forward. Apparently, this data does not help you justify these proposals so you find no use discussing in it. Maybe we should let the data drive the proposals instead of the other way around. Dan.
Re: IETF Diversity Question on Berlin Registration?
On Mon, April 29, 2013 2:28 pm, Dave Crocker wrote: On 4/29/2013 2:20 PM, Michael StJohns wrote: At 04:40 PM 4/29/2013, Dave Crocker wrote: Actually, I don't think this is even a mostly correct statement - that AD select chairs. It is a long-standing, simple, objective, unvarying management fact of IETF procedure: ADs hire and fire wg chairs. The AD's do have the final say. No question. But select implies that the own the entire process of creating and staffing a WG. Nope. They do own it; that's a formal truth. That they often delegate details and concur with self-organizing choices means nothing, in terms of their authority. But it might mean something in terms of the discussion at hand. If the ADs are concurring with self-organizing choices as opposed to selecting WG chairs, then they aren't really imposing a looks like me bias into the selection process. Dan.
Re: IETF Diversity Question on Berlin Registration?
Hi Eliot, On Wed, April 17, 2013 12:48 pm, Eliot Lear wrote: Dan, On 4/17/13 9:21 PM, Dan Harkins wrote: We already know who we are. I disagree. We make a whole lot of assumptions about who we are, but we don't actually know, and that's why the question is being asked. I would clarify that IMHO the only reason this question should be asked is for demographic purposes, along with others. Pardon me, but that makes no sense. Asking about the gender make-up of those who elect to register for a future meeting is going to tell us little about who we are. It will be a snapshot in time and it will not representative of who we are because we are more than just the people who register to go to any particular meeting. And ...the only reason...along with others? So then it's not only for demographic purposes. Those other purposes aside from the only one are what, exactly? This question is trying to decide our gender make up and nothing good can come of it. It will provide more evidence for people to make use of logical fallacies-- if P implies Q then look we now have evidence of Q therefore P-- which really have no place in an organization devoted to engineering. This would be putting the cart before the horse. We first need to understand facts. If we don't understand facts, then people will continue on assumptions. The facts are already not in dispute. The I* leadership is predominantly white and male. The fallacy works like this: If there was bias in favor of white males then we would have a leadership that is predominantly white and male. We have a leadership that is predominantly white and male, therefore we have bias. All this question will do is provide a snapshot in time of just how predominant it is-- 5% female, oh that's bad, 8% female, oh my look how skewed the I* leadership is. See, it's skewed therefore we have bias! If P then Q, and Q (we now have the numbers!) therefore P. And it will be used as a baseline for doing work towards some goal that has not been justified, work whose very nature requires treating people according to what they are instead of who they are. Look, bias stinks and when it exists its stench is detectable. I don't recall seeing any evidence of bias being presented on this list. And I don't believe there is any problem has been mentioned that we had or have that is caused by this predominance of white men. It's just been stated as a problem itself. We must have less white men. Why? Because, that's why. Nobody has proposed that, and I think you can put a bit more faith in your peers to not make important decisions based on because. What has been accepted is that diversity is good. Further, it has been stated that we cannot remove the race and gender from the problem statement about our lack of diversity. As Margaret said, I don't think it is possible for [sic] remove race and gender from the list of axes, though, since there is a notable lack of diversity in those areas. So a problem statement has been made: there is a notable lack of diversity in the areas of race and gender. Why is this a problem? What problem can we point to, now or in the past, that is the result of this lack of race and gender diversity? Well? Hmmm? Anyone? Bueller? No, nothing. So in lieu of nothing all we have is because. If you don't like because as a reason then fine, I will concede the point: decisions will be made for no reason at all! That hardly seems better. And now the only action I see out of this whole diversity discussion on the list is a plan to ask the gender of registrants for the Berlin meeting. If this is just some innocent question to find out who we are then why don't we ask about the size of the organization we work for? We all agree that we have a diversity problem on that axis and there is a skew for large corporations. No, the question is just about gender. Sadly, I can't put much faith in my peers to make important decisions because they're asking the wrong questions so they can gather data while working on addressing a non-problem. regards, Dan.
Re: IETF Diversity Question on Berlin Registration?
On Thu, April 18, 2013 8:34 am, Carsten Bormann wrote: On Apr 18, 2013, at 17:17, Dan Harkins dhark...@lounge.org wrote: Why is this a problem? I think you are more likely to ask this question if you think that if it is a problem, then we *have* to solve it, e.g. by shooting enough of the white male people in the IETF that the numbers balance. It is not that kind of problem. Well that's a relief! As a white male (I know, a surprise, right?) I'm glad to know I am not going to get shot. It is, however, a situation that a sizable part of the community have experience with. I have been attended at least 40 IETFs over the past 18 years or so. I certainly have experience with this situation. What is new, though, is the statement that this situation is, in fact, a problem. The experience that, if you find ways to improve diversity where the cure is *not* worse than the ailment, the quality of the work actually improves from that. What is this cure of which you speak? This diversity discussion has included statements like: If the intent is to emphasize diversity (for some metric) over one of the core skills [technical clue, admin skills, ability to work with others], that's certainly possible. and, A small point to watch for, if there is a focus on a defined list of groups [and there certainly appears to be one-- gender], is the difference between discriminating /against/, versus ensuring representation /from/. So? Are we going to emphasize diversity over core skills? Say that one's gender or skin color matters more than their technical clue or their ability to work with others? By what method are we going to ensure representation? And what do we do if these efforts have not resulted in the proportions that are deemed to be acceptable? Use a little more force? Quotas? Nobody has stated what the cure is for this situation so we don't know whether it will be worse than the ailment. There is a huge gap between encouraging more women to volunteer and shooting white men. And I really don't think we need to count the gender make-up of a meeting if our cure was going to something close to encouraging more women to volunteer. regards, Dan.
Re: IETF Diversity Question on Berlin Registration?
On Thu, April 18, 2013 1:51 pm, Pete Resnick wrote: On 4/17/13 2:21 PM, Dan Harkins wrote: Look, bias stinks and when it exists its stench is detectable. Dan, leaving aside all of your other comments for the moment (many of which are straw men that nobody but you have suggested, speaking of fallacies), this one comment is a serious problem since it is so demonstrably false. I'm sure I speak alone when I say that I hope you are only leaving my other comments aside for a moment and will return to them later. I would actually like to see a response that doesn't snip a 30-40 line post into 1 sentence. If you would like to engage me off-list, I welcome that. Bias creeps in in all sorts of undetectable ways; if it was always detectable, lots of statisticians and psychologists and survey designers would be out of jobs. Aside from simple methodological data collection problems, bias is often caused by completely unconscious (and sometimes well intentioned) behaviors when it comes to human endeavors. The literature on this topic is so extensive that I can't even imagine why you would even suggest the opposite. Now we're playing a subtle word game here. A bias that a statistician might add is demonstrably different than what Melinda Shore has _repeatedly_ referred to as gender bias. So when I'm talking about bias I'm talking about a form of discrimination based on gender. It is the intentional passing over of a more qualified woman in favor of a less qualified man. Exactly the same thing that is being referred to when she says: I'm telling you that I think the numbers are highly suggestive of bias. What numbers are those? The observable numbers about I* leadership. What is the bias being suggested? It is a bias against women. Straw man? I think not. A statistician might put bias in his statistical result and a survey designer might put bias in a question to elicit a favored result, intentionally or unintentionally. But we both know that is not what we're talking about here. We already know who we are. That's an interesting claim, and at least at first glance given other comments on the list, again seemingly false. As Adrian commented, perception is important. If it seems to some folks that the ratio of men to women throughout the IETF is 70:1, should it turn out that it is closer to 10:1 and the numbers in leadership are closer to 30:1, that would not only indicate that we don't already know 'who we are', but it could also be an interesting indication of why there might be statistical bias in the selection of leadership. (Or not. But it seems worthy of examination.) We are a volunteer standards organization that operates on a consensus basis. For the purposes of who we are the number of women that register for a meeting should be as relevant as the number of people who register that are left handed, flat footed or double jointed (for the record I am all three). In other words, not at all. There may be a statistical bias in the selection of leadership that favors left-handedness or maybe it disfavors left-handedness. Is that interesting? Maybe to someone. Is it worthwhile in finding out who we are? No. Dan.
Re: IETF Diversity Question on Berlin Registration?
On Thu, April 18, 2013 3:24 pm, Pete Resnick wrote: So, do we need to start this entire conversation over, overtly stating that we are not interested in looking at *intentional* gender (or corporate affiliation or other sorts of) bias? Actually I think it would be better to explicitly state what is intended to be done. If you think that we are subconsciously influenced when it comes to gender bias then I'd like to know what is going to be done about it. And if it's more than nothing then I'd like to know what our goal is vis-a-vis the gender breakdown of leadership positions and the lengths that we will go to ensure we reach it. If we're just gathering data to make a pie chart for the plenary then it seems like a waste of time. Dan.
Re: IETF Diversity Question on Berlin Registration?
On Thu, April 18, 2013 6:44 pm, Andrew Sullivan wrote: On Thu, Apr 18, 2013 at 08:17:21AM -0700, Dan Harkins wrote: So a problem statement has been made: there is a notable lack of diversity in the areas of race and gender. Why is this a problem? Because some people report that they experience a chilly environment, and we respect those people for their other contributions and would like more people like them to contribute in similar ways, and therefore we want to make the environment less chilly. I'm sort of surprised that that problem, which has been stated in my view quite plainly more than once in this thread, isn't evident to anyone participating. Well, that is certainly not the message that I read. What I read was that the I* leadership is 97% male (and 97% white) and that alone puts into question the legitimacy of the IETF as an International Standards Development Organization. If people are encountering a chilly environment then that is a different issue. It has been a few IETFs since I've heard someone approach the mic and say that is the stupidest idea I've heard in a long time and a few more since it was said to me. That kind of brusqueness is part of our culture but I think it can be off-putting and a barrier to contributing. New people get intimidated around a bunch of aggressive type-A personalities and may be reluctant to present or contribute for fear of being put down. If we want to make the IETF a less chilly place that is more inviting and we want to encourage participation maybe we should address our cultural tics and idiosyncrasies that represent a barrier to entry rather than enumerate the women who have registered for a meeting. (And yes, I am talking about myself). regards, Dan.
Re: IETF Diversity Question on Berlin Registration?
Hi Elliot, On Wed, April 17, 2013 7:52 am, Eliot Lear wrote: Dan, On 4/16/13 2:00 AM, Dan Harkins wrote: Under the belief of garbage in, garbage out, I tend to lie on these sorts of repugnant questions. I invite others to join me. The more suspect the quality of the data, the less value it has. Dan. Please don't. We are trying to understand who we are. Is that SO unreasonable? We already know who we are. This question is trying to decide our gender make up and nothing good can come of it. It will provide more evidence for people to make use of logical fallacies-- if P implies Q then look we now have evidence of Q therefore P-- which really have no place in an organization devoted to engineering. And it will be used as a baseline for doing work towards some goal that has not been justified, work whose very nature requires treating people according to what they are instead of who they are. Look, bias stinks and when it exists its stench is detectable. I don't recall seeing any evidence of bias being presented on this list. And I don't believe there is any problem has been mentioned that we had or have that is caused by this predominance of white men. It's just been stated as a problem itself. We must have less white men. Why? Because, that's why. This question is the first step down a path we really should not go down. If I can't stop the question from being asked then all I can hope for is that the resulting data are so obviously wrong that they will be of no use to anyone-- e.g. Berlin registration is 63% female. regards, Dan.
Re: IETF Diversity Question on Berlin Registration?
On Fri, April 12, 2013 7:22 pm, Melinda Shore wrote: On 4/12/13 1:26 PM, Lou Berger wrote: No argument from me, I'm just asking that a comment/position/question that I don't understand be substantiated. And I'm telling you that I think the numbers are highly suggestive of bias. This is the classic fallacy of Affirming the Consequent. And like all fallacies, the reasoning is just plain wrong. Dan.
Re: IETF Diversity Question on Berlin Registration?
On Sat, April 13, 2013 8:18 am, Ray Pelletier wrote: On Apr 13, 2013, at 8:46 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 04/13/2013 01:09 PM, Lou Berger wrote: gender bias ... western white guys. It may be that the latter phrase is a common term in north America, (I dunno) but fwiw it grates on me at least. If the issue we're talking about relates to gender, That's the question: Optional question: Check the block. Male/Female Under the belief of garbage in, garbage out, I tend to lie on these sorts of repugnant questions. I invite others to join me. The more suspect the quality of the data, the less value it has. Dan.
Re: Diversity of IETF Leadership
On Wed, March 20, 2013 7:16 am, Jorge Contreras wrote: On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman m...@lilacglade.orgwrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. I would strongly recommend that legal counsel be consulted before any such list is produced or used by IETF/IESG/Nomcom. (FYI, this is totally outside my own area of legal expertise, so IAOC would need to incur some expense to hire competent counsel in this area) Great, now the lawyers are getting involved. A sure sign this has gone way too far. The factors listed above are those that an employer cannot discriminate on. It says nothing about diversity or the alleged benefits that diversity brings to a group. For example, a company is prohibited from not hiring someone because he or she is Catholic but it does not mean that the company must work to have some arbitrary percentage of Catholics in leadership positions or among the general workforce. Absent any evidence of discrimination there is Disparate Impact Theory which says that the mere fact that a process produces a result that does not satisfy an arbitrary goal with respect to a protected group is justification for actively discriminating in favor of that protected group to balance it all out. I really, really hope that is not where we are going in the IETF. It would wreck this organization if we had a committee that performed such a blatantly political activity. If that is not where the IETF is going, then the categories listed above should not have anything to do with selection of candidates for leadership positions. It doesn't matter to the IETF if the candidate is a disabled, pregnant, lesbian, Wiccan. What matters to the IETF is whether the candidate is qualified. Dan.
Re: Diversity of IETF Leadership
Hi Dave, On Wed, March 20, 2013 8:35 am, Dave Crocker wrote: ps. A small point to watch for, if there is a focus on a defined list of groups, is the difference between discriminating /against/, versus ensuring representation /from/. Active prohibition vs. active solicitation. The exchange between Margaret and Stuart seemed to mix these. We need to be careful about the distinction. I have been viewing this as the difference between discriminating against versus discriminating for. And I am against discrimination, even that done for the best of intentions. Active solicitation is all well and good but how do you _ensure_ representation of members from a defined list of groups if your active solicitation does not result in the favored mix? Dan. -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Diversity of IETF Leadership
On Wed, March 20, 2013 10:01 am, Jeffrey Haas wrote: On Wed, Mar 20, 2013 at 09:01:01AM -0700, Dan Harkins wrote: On Wed, March 20, 2013 8:35 am, Dave Crocker wrote: ps. A small point to watch for, if there is a focus on a defined list of groups, is the difference between discriminating /against/, versus ensuring representation /from/. Active prohibition vs. active solicitation. The exchange between Margaret and Stuart seemed to mix these. We need to be careful about the distinction. I have been viewing this as the difference between discriminating against versus discriminating for. And I am against discrimination, even that done for the best of intentions. This is certainly the biggest challenge of any intent to include diversity (of any form) in the mix. In general, we want the best people in the job in question. What is best depends on the position (chair, I*, etc.) but as a technical organization that runs on documents, several things will bubble to the top: - Technical clue in the matter at hand. - Reasonable administrative skills. - Ability to work with others. - Solid communication skills. For candidates wherein the above things are roughly equal - or have exceeded the requirements - diversity is a possible tie-breaker. If the intent is to emphasize diversity (for some metric) over one of the core skills, that's certainly possible. By that, I take it you mean it's certainly possible to discriminate in favor some metric of diversity and against a core skill. So? Is that the intent? There is quite a bit of dancing around this subject and it would be nice to say what we all mean here. If you're proposing that IETF start the practice of discriminating against certain people then say so. The primary challenge then is making sure there is a diverse candidate pool that satisfies the minimum core skills needed for the positions. See prior discussion on mentoring. You snipped my other question. So let me ask again. What do we do if, after ensuring that there's a diverse candidate pool that satisfies the minimum core skills needed for positions, the end result is more white men? Do we stop with the pretense of ensuring diversity of opportunity and just proceed to diversity of result? Do we enshrine the soft bigotry of low expectations? Dan.
Re: Diversity of IETF Leadership
On Mon, March 11, 2013 10:08 pm, Margaret Wasserman wrote: On Mar 11, 2013, at 6:54 PM, Dan Harkins dhark...@lounge.org wrote: In other words, the statement that gender and racial diversity in groups makes them smarter has no basis in fact. Do you feel that an all-female group is stupider than a similarly sized group that is equal parts male and female? Really? Actually, Dan, there are well-regarded academic studies that show that groups that contain women are smarter than all-male groups, regardless of the relative intelligence of the group members. Surprising, perhaps, but true. Here is a pointer to a discussion of one of them: http://www.antonioyon.com/group-intelligence-and-the-female-factor There are also numerous studies, of various types, that show that more diverse groups make better decisions and/or perform better than less diverse groups. Here is a description of one such study: http://insight.kellogg.northwestern.edu/article/better_decisions_through_diversity So, as illogical as these statements may seem on the surface, they are well-established facts. Both of the articles I've sited give some insight into why this is true. I will readily admit that a group whose members have diverse backgrounds, diverse experience, and diverse opinions will generally produce better decisions than a group whose members are all of the same background, experience, and opinion. That is generally what the Northwestern article promotes (and what the papers that Rhys pointed me to earlier) say. But that is far different from saying that having less white males would make for a better IETF. In fact, the makeup of the IESG is already diverse. If it was entirely comprised of security people it would make horrible decisions. It's not, and that's because diversity is good. Regarding the CMU/MIT study, that is very provocative. There is converging evidence from 2 studies of groups of 2-5 people who scored higher in general collective intelligence when social sensitivity was higher in the group, when group conversation was done in turns, and there were more females in the group. OK. We can all draw our own conclusions about that and more women = smarter certainly does get your study reported in Forbes and Business Weekly et cetera. I believe there is also a bell curve of human intelligence that shows a preponderance of men at both ends-- i.e. there are more male idiots and male geniuses. Which would seem to suggest that adding women to a group of men would, on average, increase the group's intelligence. That study also showed that east asians scored higher than whites and whites scored higher than blacks on IQ tests. An that current immigrants to the USA are less hard-working and less imaginative than past immigrants. Also very provocative. Now before anyone accuses me of any more -isms, let me say that these studies make very bad social policy recommendations. I don't think we should strive to make groups more east asian or less black or to favor past immigrants over recent immigrants. That would be wrong, and I hope we are in agreement there. It would also be wrong to strive to make groups more female for exactly the same reason. While these studies are interesting and thought provoking, I think it is wrong, and very dangerous, to use these studies to justify blanket statements about intelligence, group or otherwise. If there's some bias involved in the Nomcom's selection process then point it out and let's address it. The mere fact that there are is preponderance of white males being selected does not mean bias exists and the notion that a cherry-picked study (or selectively interpreting the results of a cherry-picked study) justifies imposing bias on the selection process to derive some ideal diversity is crazy. regards, Dan.
Re: Diversity of IETF Leadership
On Tue, March 12, 2013 10:35 am, Randall Gellens wrote: At 3:54 PM -0700 3/11/13, Dan Harkins wrote: Do you feel that an all-female group is stupider than a similarly sized group that is equal parts male and female? Based on my own experience, I believe that a broad range of background and experience improves the quality of decision making of a group. This is not to say that administering a standardized IQ test to a group would result in outcomes predictable by gender diversity of the group. But it is to say that, for example, having some people with implementation experience is a good thing in protocol design discussions. I share your belief that diversity of background and experience makes a group function better. I'm glad you mentioned implementation experience. The small corner of the IETF that I lurk in seems to be becoming less diverse in that respect and I think it's to the detriment of our protocols. We've been veering into narrow discussions of race and gender diversity, but earlier messages in this thread discussed diversity along other lines, for example, type of employer (large, small, equipment vendor, university) and operational experience with networks in different geographic regions. Let's not fall into a rat-hole of narrow considerations of diversity. The problem was stated in the open letter thusly: In February of 2013, there were 32 members of the IETF leadership (12 IAB members, 15 IESG members and 5 IAOC members). Of those 32 members, there was one member of non-European descent, there were no members from countries outside of North America or Europe, and there was only one woman. There were only 19 companies represented (out of a total of 32 seats). Out of 32 members there's only 1 who is of non-European descent (i.e. not white) and only 1 woman. So the problem, aside from corporate representation, is that the IETF leadership is too white and too male. I'd love to get out of this rat hole. Perhaps the signatories of the open letter can restate the problem they see so it isn't made in terms of race and gender. regards, Dan.
Re: Diversity of IETF Leadership
In addition to the moral and social issues involved, diversity of leadership across several axes (race, geographic location, gender and corporate affiliation) is important for three practical reasons: - It is a well-established fact that diverse groups are smarter and make better decisions than less-diverse groups. I would really like to see this statement either backed up by peer-reviewed apolitical scientific research or withdrawn by the signatories of the open letter. It is highly offensive. While it should be self-evident that a group whose homogeneity was of corporate affiliation might not make the best decisions for the IETF as a whole, to say that a racially homogenous group is somehow dumber than a racially diverse group smacks of racism. The group comprised of winners of the Nobel Prize for Physics is overwhelmingly north american and european males. Just the makeup that is being asserted as a problem here in the IETF. But it is not viewed as a problem, and for good reason because science would suffer if it was subordinated in any way to any other consideration. - Lack of diversity in our leadership becomes a self-perpetuating problem, because people who are not represented in the IETF leadership are less likely to dedicate their time and effort to the IETF. Another ipse dixit fallacy! A mere assertion masquerading as a sociological fact. As if we are just sheeple who are motivated to only join groups whose makeup resembles us. We are supposed to be individuals here engaging in consensus-based work to get the best technical solution to the Internet's problems. Disparate impact theory has no place in the IETF. Dan.
Re: Diversity of IETF Leadership
On Mon, March 11, 2013 1:39 pm, Rhys Smith wrote: On 11 Mar 2013, at 16:02, Dan Harkins dhark...@lounge.org wrote: - It is a well-established fact that diverse groups are smarter and make better decisions than less-diverse groups. I would really like to see this statement either backed up by peer-reviewed apolitical scientific research or withdrawn by the signatories of the open letter. It is highly offensive. I'm in no way an expect in any of this, but I've heard it said (in other contexts than this discussion) that diversity increases the quality of decision making in groups. Your message piqued my interest as to whether there is valid evidence for whether this was actually the case or not. Well, you snipped the part where I copied the explicit mention of race and gender as being axes of diversity. To cut a long story short, after a bit of investigation, I'd have to say that current scientific thought definitely leans towards this in fact being the case. I detect a bait and switch here. We're told that there is a lack of diversity at the IETF involving race, gender, geographic location and corporate affiliation and that this is a problem because diverse groups are smarter than non-diverse groups. Yet these studies talk about diversity in a much broader sense that includes things like formal credentials and attention and recall and seeking and receiving social information and support as well as age, membership in a formal religion and, yes, race. So unless this diversity problem at the IETF also involves the makeup of Catholics, teenagers, people with just a grammar school education, and those with attention deficit disorder, in the general IETF population, I don't think these studies lean towards the statement in the open letter as being a fact. A selection of references that seem to appear quite often in the various bits of literature I've had a browse around for anyone who is interested: I don't want to go through all of these but the first one presents a framework with which to understand the dynamics of diversity. It says, Our discussion in this chapter is guided by the heuristic of a theoretical framework that identifies primary constructs and connects them to form a meaningful territorial map. Within this framework, diversity is placed as a construct that appears early in the causal chain of phenomena considered. What happens if diversity is placed as a construct that appears later in the causal chain of phenomena? Dunno. But it should be unremarkable that diversity strongly affects the causal chain of phenomena because it has been designed to be that way. Not very scientific. Scanning down to the one study that mentioned race, I see the abstract describes confirmation bias: Deliberation analyses supported the prediction that diverse groups would exchange a wider range of information than all-White groups. And the finding is not anything that would lead us to the conclusion that a racially diverse group is smarter than a racially homogenous group as it was related to the willingness to discuss racism and was not wholly attributed to the performance of black participants versus all-white groups. In other words, the statement that gender and racial diversity in groups makes them smarter has no basis in fact. Do you feel that an all-female group is stupider than a similarly sized group that is equal parts male and female? Really? Dan. Jackson, S. E. May, K. E. Whitney, K. (1995) Understanding the Dynamics of diversity in decision making teams in R.A. Guzzo et al, (1995) Team effectiveness and decision making in organisations: San Fransisco: Jossey-Bass. Johnson, W. B. Packer, A. E. (1987) Workforce 2000, Work and workers for the 21st century: Washington DC: Department of Labour12. Krause, S., James, R., Faria, J. J., Ruxton, G. D. and Krause, J., 2011. Swarm intelligence in humans: diversity can trump ability. Animal Behaviour, 81 (5), pp. 941-948. Lumby, J. (2006) Conceptualizing diversity and leadership: evidence from ten cases: Educational management and administration, Vol. 34, (2), 151-165. Phillips, Katherine W., Katie A. Liljenquist and Margaret A. Neale. 2009. Is the pain worth the gain? The advantages and liabilities of agreeing with socially distinct newcomers. Personality and Social Psychology Bulletin 35: 336-350. Mohammed, S., Ringseis, E., Cognitive Diversity and Consensus in Group Decision Making: The Role of Inputs, Processes, and Outcomes, Organizational Behavior and Human Decision Processes, Volume 85, Issue 2, July 2001, Pages 310-335, Sommers, S.R. ( 2006). On racial diversity and group decision making: Identifying multiple effects of racial composition on jury deliberations. Journal of Personality and Social Psychology, 90, 597-612. Watson, W. E. Kumar, K. Michaelsen, L. K.(1993) Cultural Diversity impact on interaction process
Re: [IPsec] Last Call: draft-kivinen-ipsecme-secure-password-framework-01.txt (Secure Password Framework for IKEv2) to Informational RFC
Paul, The existence of this draft shows a failure of YOUR leadership (and that of your co-chairman) of the working group. Consensus was achieved to add an authentication method based on a simple password yet you seemingly worked to do everything possible to create division in the working group and then stepped in to declare failure because no consensus existed. We could've had a single standards-track solution to this problem over a year ago if you had treated the singular draft used to argue for addition of this work to the charter in the same way that you treated the singular draft used to argue for addition of EAP only authentication to the charter. The latter (authored by one of the chairmen) was advanced to standards track after receiving a whopping ZERO comments from the WG and the former was killed by the chairmen because the only comments on the list were from authors of competing drafts (after manufacturing the competition in the first place). There was hostility by the IPsecME chairmen to this work item from the beginning and you worked to ensure its failure in the WG. Now you're against advancement of Tero's draft to forge the best possible outcome now? Not a surprise! Put that hat back on, along with a sackcloth and ashes, and say mea culpa. Dan. On Wed, July 27, 2011 5:12 pm, Paul Hoffman wrote: hat location=off On Jul 27, 2011, at 6:30 PM, Yoav Nir wrote: I think this is a terrible idea. +.5. I think is is a bad idea. IKEv2 has a way for mutual authentication with a shared key. A concern was raised that this method was vulnerable to guessing if trivial shared keys were configured. There were several proposals for a better cryptographic method. The IPsecME working group failed to choose between them. This is not so surprising, because most participants are engineers, not cryptographers. Even those with some cryptographic background stayed silent because choosing between several cryptographic protocols is hard. IETF last calls and the IESG did not help much either. This draft represents a total shirking of our responsibility. +.5. I think think it represents a shirking of our leadership's responsibility. Our leadership said that they would deal with the issue if the WG could not come to consensus, and the WG could not come to consensus. Adding a layer of indirection that is mostly transparent is not dealing with it. Rather than decide on one protocol that is best or even arbitrarily choosing one that is good enough, it proposes to build a framework so that everyone and their dog can have their own method. This is a nightmare for developers: since you can't know what method the peer will support, you have to implement all of them. If this had been a hierarchical organization, some manager would decide which of the methods gets developed (or published) and the others would be relegated to the recycle bin. The IETF is not like that and we seek to reach consensus. That's a good thing, but this time it's leading us to a really bad solution for interoperability, and a really bad solution for implementers. I am opposed to this draft. +1 On Jul 27, 2011, at 6:52 PM, Tero Kivinen wrote: Yoav Nir writes: This draft represents a total shirking of our responsibility. Rather than decide on one protocol that is best or even arbitrarily choosing one that is good enough, it proposes to build a framework so that everyone and their dog can have their own method. This is a nightmare for developers: since you can't know what method the peer will support, you have to implement all of them. Partially yes, but unfortunately all of the authors of those actual protocols decided that they wanted to continue publishing those drafts as individual RFCs, and each of them used different way to negotiate them, so there was no way to even implement multiple of them. Is this true? Because each has it's own way to negotiate its use, one should be able to implement multiple of the competing proposals as-is, yes? At least this drafts gives you that option to implement multiple of them if you want. This draft only provides instructions for those other draft authors so they can at least common methods to negotiate the feature and use common method to trasmit data between peers. True, but it is still punting the problem of us having just one. --Paul Hoffman ___ IPsec mailing list ip...@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-harkins-ipsecme-spsk-auth-03
Hi Roni, Thank you for reviewing my draft. Comments inline On Mon, April 11, 2011 5:11 am, Roni Even wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Minor issues: 1.In section 8.5 and 8.6 the draft says that If no more password pre-processing techniques are supported the exchange MUST be terminated. Reading section 6, I thought that NONE MUST be supported for interoperability purpose. One of the valid techniques for password pre-processing is none. That doesn't mean that there isn't a technique, it means the technique is to perform no pre-processing on the password (treat it as a raw blob of bits). 2.In section 8.1 and in figure 1 and figure 2 is there a maximum value for counter? No there isn't, but it is doubtful the number will get very large. The probability that more than n iterations is necessary will be roughly (1-(r/2p))^n, where r is the order and p is the prime, and that number rapidly approaches zero as n increases. Nits/editorial comments: 1. In section 1 just before 1.1 you have suceed instead of succeed 2. In section 4 third bullet an instead of and 3. In section 4.2 Two elementx instead of Two elements 4. In section 5 second row authenticaiton should be authentication 5. In section 6 fourth row identitcal instead of identical Thank you for catching all of these. regards, Dan. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-harkins-ipsecme-spsk-auth-03.txt (Secure PSK Authentication for IKE) to Informational RFC
Hi Mykyta, Thank you for reviewing my draft. Responses inline On Sat, March 26, 2011 10:06 pm, Mykyta Yevstifeyev wrote: Hello, A question on the flowing extract: This memo contains a new numberspace to be managed by IANA, a registry used to indicate a password preprocessing technique. The initial layout of this registry SHALL be: o 0x00 : None o 0x01 :RFC2759 http://tools.ietf.org/html/rfc2759 o 0x02 : SASLprep The Prep field is 8 bits long and all other values are available through assignment by IANA. IANA is instructed to assign values based on Specification Required (see [RFC5226 http://tools.ietf.org/html/rfc5226]). It contains the description of new registry. but it fails to give it the distinctive definition. Among other, what is the exact name of the registry? How are the fields named? The sentence The Prep field is 8 bits long and all other values are available through assignment by IANA. also makes me confusing. This means that the Prep field is not assigned by IANA? Finally, 0x00 is Unassigned or Reserved? Thus, this extract needs more clarification. How would the following look to you: This memo contains a new numberspace to be managed by IANA, the password preprocessing method (Prep) registry. The initial layout of this registry SHALL be: o 0x00 : None (no preprocessing is performed) o 0x01 : RFC2759 o 0x02 : SASLprep The Prep field is 8 bits long and all other values are available through assignment by IANA. IANA is instructed to assign values based on Specification Required (see [RFC5226]). regards, Dan. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kuegler-ipsecme-pace-ikev2-05.txt (Password Authenticated Connection Establishment with IKEv2) to Experimental RFC
Hello, I believe there is a problem with this draft that can void a claimed security property: namely, resistance to dictionary attack. The issue is not with the underlying key exchange itself, but with the way the key exchange was added to IKEv2. In this protocol, a random nonce is encrypted using the encryption algorithm negotiated in IKEv2 with a key that is based on a password and data known to an adversary launching an active attack. The initiator of the protocol produces the encrypted random nonce and sends it to the responder. If an adversary, acting as the responder, is able to determine whether a decryption of the nonce is successful he is able to launch an off-line dictionary attack. When the negotiated encryption algorithm is used in an authenticated encryption mode, like -GCM or -CCM, an integrity check value (ICV) is encoded into the ciphertext produced by the encryption operation (see RFC 5282). This provides a way for an adversary to determine whether a decryption was successful and therefore whether the guessed password is correct. The attack is simply to try each candidate password from the dictionary, use it to compute a candidate key, and if the authenticated decryption operation using the candidate key does not return FAIL then exit, the password has been found. There are many ways to address this issue. The simplest would be to just forbid use of an AAD cipher mode when using this method of authentication. That would be regrettable though due to the wide appeal of GCM (less so with CCM). A better solution would be to just use ECB mode of the underlying block cipher. The nonce is uniformly random and there is no need to inject additional randomness into the encryption operation (i.e. no IV needed). I feel it is necessary to fix this issue before publication. regards, Dan. On Sat, 26 Mar 2011 09:38:11 -0700, the IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Password Authenticated Connection Establishment with IKEv2' draft-kuegler-ipsecme-pace-ikev2-05.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf at ietf.org mailing lists by 2011-04-23. Exceptionally, comments may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-kuegler-ipsecme-pace-ikev2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kuegler-ipsecme-pace-ikev2/ No IPR declarations have been submitted directly on this I-D. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: All these discussions about meeting venues
Uhm, no. If someone wants to put a little salt in their soup do you suggest that the whole shaker be poured into the bowl? Taking a position to an absurd extreme is fallacious. Dan. On Sun, August 29, 2010 5:21 am, Phillip Hallam-Baker wrote: Ah so the salt lake city model where everyone stayed at the same hotel and there was only one bar in town would be ideal... On Sat, Aug 28, 2010 at 7:41 PM, Dan Harkins dhark...@lounge.org wrote: Â Hi Hannes, Â Maastricht is definitely an interesting city and I'm glad I can say I've been there (Aachen was cool too!). But the venue there sucked. It was in the middle of a cultural dead zone (which says something because Maastricht has lots to offer) and the hotels were all scattered around town. My hotel was great and well situated from a city-center perspective (I would consider staying there if I went back as a tourist) but to get to the venue required a 20 minute hike or a bus. Coordination among people to go out to dinner or meet up after dinner was a pain-in-the-ass because everyone scattered out in a 5km radius to freshen-up/stow-bags/whatever. And then there's the multi-stop cab ride back to everyone's dispersed hotels, not very conducive to extra-IETF activities which are helped by close hotel proximity. Â Yea, I did see my fellow IETFers but that holds true anywhere (if you hold an IETF in city X then there will be lots of IETFers in city X) so that is hardly a positive aspect about the particular IETF venue. Â Don't take it as a negative about the city. It's the venue in the city and the displacement of hotels that matter. For instance, I've been to San Diego, California, USA for different meetings and some were great and others really sucked because the venue was not convenient and/or in a cultural wasteland or to get to/from there was a pain-in-the-ass. Same city, different conference, totally different experience. Â Two hops plus a train or 3 hops or whatever may be a negative but to me that's a one-off (actually a two-off since I have to leave too) and I really don't care too much about that. More important, to me, is the overhead required for day-to-day activities during the IETF-- effort to get to the venue from my hotel, how easy is it to find food during the day, what's required to coordinate extra-IETF meetings with fellow IETFers in the city, that kinda stuff. Â regards, Â Dan. And yes, I did see alot of my IETF friends again. On Sat, August 28, 2010 12:54 am, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Hi Jordi, Hi all, I have not seen an IETF meeting where people have not complained about the layout of the venue, how to get there, the city itself, the proximity to some nearby countries, the weather, the hotel, the number of offered hotels, the high crime rate, etc. etc. The place that makes 95% of the typical IETF meetings participants happy does not even exist. Maybe it would be useful to highlight the positive aspects of traveling instead. Maastricht is an interesting city and you saw lots of your IETF friends again. Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: All these discussions about meeting venues
Hi Hannes, Maastricht is definitely an interesting city and I'm glad I can say I've been there (Aachen was cool too!). But the venue there sucked. It was in the middle of a cultural dead zone (which says something because Maastricht has lots to offer) and the hotels were all scattered around town. My hotel was great and well situated from a city-center perspective (I would consider staying there if I went back as a tourist) but to get to the venue required a 20 minute hike or a bus. Coordination among people to go out to dinner or meet up after dinner was a pain-in-the-ass because everyone scattered out in a 5km radius to freshen-up/stow-bags/whatever. And then there's the multi-stop cab ride back to everyone's dispersed hotels, not very conducive to extra-IETF activities which are helped by close hotel proximity. Yea, I did see my fellow IETFers but that holds true anywhere (if you hold an IETF in city X then there will be lots of IETFers in city X) so that is hardly a positive aspect about the particular IETF venue. Don't take it as a negative about the city. It's the venue in the city and the displacement of hotels that matter. For instance, I've been to San Diego, California, USA for different meetings and some were great and others really sucked because the venue was not convenient and/or in a cultural wasteland or to get to/from there was a pain-in-the-ass. Same city, different conference, totally different experience. Two hops plus a train or 3 hops or whatever may be a negative but to me that's a one-off (actually a two-off since I have to leave too) and I really don't care too much about that. More important, to me, is the overhead required for day-to-day activities during the IETF-- effort to get to the venue from my hotel, how easy is it to find food during the day, what's required to coordinate extra-IETF meetings with fellow IETFers in the city, that kinda stuff. regards, Dan. And yes, I did see alot of my IETF friends again. On Sat, August 28, 2010 12:54 am, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Hi Jordi, Hi all, I have not seen an IETF meeting where people have not complained about the layout of the venue, how to get there, the city itself, the proximity to some nearby countries, the weather, the hotel, the number of offered hotels, the high crime rate, etc. etc. The place that makes 95% of the typical IETF meetings participants happy does not even exist. Maybe it would be useful to highlight the positive aspects of traveling instead. Maastricht is an interesting city and you saw lots of your IETF friends again. Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How to get onto the IETF authenticated LAN?
The IETF 78 LAN is using 802.1X (w/EAP) for authentication. The wpacracker only works if the AP is doing PSK authentication. These things seem to get propagated because people punt the hard problems with statements like well the PSK is required to be a uniformly random 128 bit string and if you don't configure it that way it's your own damned fault. And IETF is not blameless in this regard. But to answer your other question, this is being addressed in IEEE 802.11 by adding another PSK-based authentication technique using a zero knowledge proof. Coming soon to an AP near you! Dan. On Tue, July 27, 2010 8:08 am, Phillip Hallam-Baker wrote: Will hack for food gets more professional. Anyone want to try it out for me on the IETF 78 LAN? http://www.wpacracker.com/faq.html It seems doubtful to me that this would work against a really well deployed network. But the fact that WPA2 can be deployed in dufus configuration should be considered a major protocol flaw. WPA2 was after all the fourth attempt the group made at making the protocol secure. It is not at all clear to me what level of expertise is required to do the job right or how to be confident that it is done right. The endpoints used in these protocols all have the ability to perform public key cryptography at acceptable speeds. Even if they did not, the price of 64Mb of flash memory is negligible these days and that is sufficient to store more than enough keys to maintain tens of thousands of session keys in the access point. We have the resources and the technology to do the job right. Why do we keep doing half measures that we know are wrong? I know this particular issue is an IEEE funeral, but isn't there a point where others decide to take responsibility? -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: review of draft-ietf-ipsecme-eap-mutual
in the draft. Thanks, Yaron On 05/27/2010 12:22 AM, Dan Harkins wrote: Hello, Here are some comments on this draft for IETF LC. There are some editorial nits, some errors that might be considered editorial but there is a serious issue with the Security Considerations that I think needs addressing. I'll start with the security issue since it's the most serious (and some may stop reading after getting to the editorial complaints). Issue in Security Considerations: In IKEv2 both sides present identities in the form of an ID payload. EAP also has an identity exchange that is not useful for authentication so EAP methods typically include their own, separate, identity exchange. In many cases that identity is in a protected channel from the EAP peer to the EAP server. When the EAP server is not co-located with the IKEv2 implementation (i.e. EAP is offloaded to a separate server) the identities that are actually authenticated are unknown and/or unverified. Section 6.2 mentions this from the client's point-of-view-- after the client has verified the AUTH payload sent by the IKEv2 gateway, it knows that it is talking to SOME gateway trusted by the home AAA server, but not which one. This is used as a segue to the lying NAS problem, which I have note below is not really solved so this problem isn't really addressed properly. But the problem is worse. The point-of-view of the gateway is never mentioned. The gateway may know some anonymous identity, or an identity that is colored or obfuscated that is useful only by the EAP server to determine which EAP method to offer. It does not know what the real client identity is. The identity that gets authenticated is unknown to the gateway! Unfortunately, it is the authenticated identity that the gateway must use to look up an entry in the IPsec Security Policy Datbase (see RFC 4301) that says what kind of security (bypass, drop, protect rules, etc) to apply to the client's packets. It is therefore not possible to properly support RFC 4301 when using this EAP-only method of authentication. Furthermore, the only identity available to the gateway can be forged so the client can achieve more favorable access to the protected network (a more generous security policy) than the gateway would have given it had it known its _real_ identity. I think there has to be a top-down analysis of RFC 4301 and how this scheme impacts it. Each part of RFC 4301 that cannot be supported or can only be supported in a limited manner must be spelled out and the impact of the lack, or limit, of support has to be presented in this draft's Security Considerations so a reader/implementer knows what he's getting into if he decides to implement this scheme. I would advise a DISCUSS on this draft until this has been worked out. Errors: - the draft states IEEE 802.11i uses EAP without any PKI for authenticating the WLAN access points. That is just plain wrong. IEEE 802.11 is agnostic about particular EAP methods but requires they provide mutual authentication and key generation. The Wi-Fi Alliance certifies IEEE 802.11 implementations (and the EAP methods they use). Of the EAP methods certified for use in IEEE 802.11-- EAP-TLS, EAP-TTLS w/MSCHAPv2, PEAPv0 w/MSCHAPv2, PEAPv1 w/GTC, and EAP-SIM-- only EAP-SIM does not require a PKI. Having been involved in that particular industry for most of the past decade I can assure the authors that PKIs of some sort are used in most every deployment of IEEE 802.11i. I have yet to see a pure EAP-SIM deployment anywhere. - in section 6.2 the draft mentions the lying NAS problem and says that EAP methods that provide what is called 'connection binding' or 'channel binding' transport some identity or identities of the gateway (or WLAN access point/NAS). The table in section 4 lists EAP methods that supposedly support channel binding but none of methods with a yes in that column do what section 6.2 says. The closest is EAP-SAKE (RFC 4763) which includes identities in a MIC but that won't solve the lying NAS problem and RFC 4763 even says, EAP-SAKE does not claim channel binding (so the table in section 4 is wrong). The others provide a protected channel but don't say how this can be used to actually solve the lying NAS problem. The draft really needs to say that this problem has not been solved yet and remains an issue that must be taken into account if someone decides to implement this scheme. Editorial nits: - this draft really does not justify its existence well at all. I know the WG decided to pursue this work item but the reasoning
review of draft-ietf-ipsecme-eap-mutual
Hello, Here are some comments on this draft for IETF LC. There are some editorial nits, some errors that might be considered editorial but there is a serious issue with the Security Considerations that I think needs addressing. I'll start with the security issue since it's the most serious (and some may stop reading after getting to the editorial complaints). Issue in Security Considerations: In IKEv2 both sides present identities in the form of an ID payload. EAP also has an identity exchange that is not useful for authentication so EAP methods typically include their own, separate, identity exchange. In many cases that identity is in a protected channel from the EAP peer to the EAP server. When the EAP server is not co-located with the IKEv2 implementation (i.e. EAP is offloaded to a separate server) the identities that are actually authenticated are unknown and/or unverified. Section 6.2 mentions this from the client's point-of-view-- after the client has verified the AUTH payload sent by the IKEv2 gateway, it knows that it is talking to SOME gateway trusted by the home AAA server, but not which one. This is used as a segue to the lying NAS problem, which I have note below is not really solved so this problem isn't really addressed properly. But the problem is worse. The point-of-view of the gateway is never mentioned. The gateway may know some anonymous identity, or an identity that is colored or obfuscated that is useful only by the EAP server to determine which EAP method to offer. It does not know what the real client identity is. The identity that gets authenticated is unknown to the gateway! Unfortunately, it is the authenticated identity that the gateway must use to look up an entry in the IPsec Security Policy Datbase (see RFC 4301) that says what kind of security (bypass, drop, protect rules, etc) to apply to the client's packets. It is therefore not possible to properly support RFC 4301 when using this EAP-only method of authentication. Furthermore, the only identity available to the gateway can be forged so the client can achieve more favorable access to the protected network (a more generous security policy) than the gateway would have given it had it known its _real_ identity. I think there has to be a top-down analysis of RFC 4301 and how this scheme impacts it. Each part of RFC 4301 that cannot be supported or can only be supported in a limited manner must be spelled out and the impact of the lack, or limit, of support has to be presented in this draft's Security Considerations so a reader/implementer knows what he's getting into if he decides to implement this scheme. I would advise a DISCUSS on this draft until this has been worked out. Errors: - the draft states IEEE 802.11i uses EAP without any PKI for authenticating the WLAN access points. That is just plain wrong. IEEE 802.11 is agnostic about particular EAP methods but requires they provide mutual authentication and key generation. The Wi-Fi Alliance certifies IEEE 802.11 implementations (and the EAP methods they use). Of the EAP methods certified for use in IEEE 802.11-- EAP-TLS, EAP-TTLS w/MSCHAPv2, PEAPv0 w/MSCHAPv2, PEAPv1 w/GTC, and EAP-SIM-- only EAP-SIM does not require a PKI. Having been involved in that particular industry for most of the past decade I can assure the authors that PKIs of some sort are used in most every deployment of IEEE 802.11i. I have yet to see a pure EAP-SIM deployment anywhere. - in section 6.2 the draft mentions the lying NAS problem and says that EAP methods that provide what is called 'connection binding' or 'channel binding' transport some identity or identities of the gateway (or WLAN access point/NAS). The table in section 4 lists EAP methods that supposedly support channel binding but none of methods with a yes in that column do what section 6.2 says. The closest is EAP-SAKE (RFC 4763) which includes identities in a MIC but that won't solve the lying NAS problem and RFC 4763 even says, EAP-SAKE does not claim channel binding (so the table in section 4 is wrong). The others provide a protected channel but don't say how this can be used to actually solve the lying NAS problem. The draft really needs to say that this problem has not been solved yet and remains an issue that must be taken into account if someone decides to implement this scheme. Editorial nits: - this draft really does not justify its existence well at all. I know the WG decided to pursue this work item but the reasoning around that decision does not come through in this draft. The introduction says that [P]ublic key signatures and shared secrets are not flexible enough to meet the requirements of many deployment scenarios. OK, so
Re: review of draft-ietf-ipsecme-eap-mutual
Hi Paul, What I said was: I think there has to be a top-down analysis of RFC 4301 and how this scheme impacts it. Each part of RFC 4301 that cannot be supported or can only be supported in a limited manner must be spelled out and the impact of the lack, or limit, of support has to be presented in this draft's Security Considerations so a reader/implementer knows what he's getting into if he decides to implement this scheme. That's really what's needed, an enumeration of the issues and impacts. The gateway cannot learn the authenticated identity and therefore the assumptions RFC 4301 is making about that identity (viz, that it be authenticated) no longer apply. The client can't learn the authenticated identity but it does know that the entity asserting the unauthenticated identity is trusted in some capacity (it got the key after all) by the server it just authenticated. I think the ramifications of all that has to be stated in the Security Considerations and I'd expect it to not be a perfunctory statement. I don't expect this draft to solve the lying NAS problem. But it should not say it's solved by EAP methods with a yes in the table in section 4. Such a statement is not true. It should say something to the effect that some EAP methods have the capability to pass blobs of data and at some time in the future there may be a use of this capability to solve the 'lying NAS' problem but until that time the following considerations must be taken into account by people who implement this scheme: blah blah blah. What is the impact of a client having this transitively authenticated, but not really authenticated, identity of the NAS even if the NAS is not lying? Does this impact change if there's a human behind the client (who just wants network access) or if it's a device protecting some of its own resources? The draft doesn't say. Basically, the Security Consideration section doesn't take into consideration the full impact on security that will be caused by implementation of this protocol; it should. regards, Dan. On Wed, May 26, 2010 3:39 pm, Paul Hoffman wrote: At 2:22 PM -0700 5/26/10, Dan Harkins wrote: I would advise a DISCUSS on this draft until this has been worked out. Can you say more about what you mean by worked out? More text in the Security Considerations? If so, at least an outline would be helpful. Or maybe you mean one or more changes to the protocol? If so, some specific suggestions would be helpful. Specifically, are you asking for this document to solve the lying NAS problem? --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Advance travel info for IETF-78 Maastricht
I have had cab drivers in the US try to force me to pay cash in similar situations. Saying they don't accept credit cards and then, when I say that's all I have, telling me how much longer it will take to get me out of their cab if I really want to use a credit card. In these cases I just kept insisting on the card and eventually (like, within a minute) all was settled the way I wanted it to be settled: with the credit card. It may seem anachronistic to some, but the rule of law does apply in the US today and asking to have a police officer settle the dispute is a good way of getting quick resolution. If all else fails maybe taking a picture or two (driver and taxi permit) with a camera phone might tend to elicit a change of attitude. Dan. On Sun, May 9, 2010 5:29 pm, Glen Zorn wrote: Iljitsch van Beijnum [mailto:iljit...@muada.com] writes: On 8 mei 2010, at 1:50, Glen Zorn wrote: More than once, I _have_ asked the driver specifically if he accepts credit cards (the advertised policy notwithstanding) only to have him refuse it upon arrival... Curious way to engage in commerce. Where was this? Several places, all in the US; most recently, Dallas. ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: review of draft-sheffer-emu-eap-eke-06
Hi Simon, On Mon, May 3, 2010 3:32 pm, Simon Josefsson wrote: Dan Harkins dhark...@lounge.org writes: Issues with prf and prf+ - In sections 5.1 and 5.2 the password is passed directly into prf+ (which is the same as the one from RFC 2409 and uses HMAC-SHA1 or HMAC-SHA256). This is a key derivation type function and assumes it has been passed a key having properties, like a uniformly random distribution, that a low-entropy password does not have. I recommend deriving a key for Encr() in a 2-step process using and extractor and expander KDF. It might also be good to mention that the first, leftmost, length-of-cipher-key bits are used as the cipher key. I agree with your comments. However would not salting and an iterative design, as provided by PKCS#5 PBKDF2, be more appropriate than extract-and-expand? See section 4 of the extract-and-expand document to see why it is not always appropriate for passwords. I don't believe so. PBKDF2 does 1000 iterations of HMAC-ing to increase the work factor of brute force guessing the password. This is useful when the protocol using the password is not based on a zero knowledge proof. In this case it is, and an active attacker gets only one guess at the password per attack (a passive attacker gets zero guesses) and that would be the case even if the password is used directly as a key to an HMAC-based KDF. Section 4 of the extract-and-expand document says, In the case of password-based KDFs, a main goal is to slow down dictionary attacks using two ingredients: a salt value and the intentional slowing of the key derivation computation. HKDF naturally accommodates the use of salt; however, a slowing down mechanism is not part of this specification. But in the case of EAP-EKE a dictionary attack is foiled outright by the protocol. There is no need to use a KDF to slow one down. My recommendation was simply to use an HMAC-based KEF with the assumptions that it was built on. This allows the protocol to be analyzed without placing strong assumptions on the underlying hash function (basically, you get the security of HMAC when you use it correctly, whether you get it when you use it incorrectly is an open question that I am not qualified to answer). PBKDF2 is also much more computationally intensive and there doesn't seem to be a bang for that buck :-) - Section 5.1 says If the password is non-ASCII, it SHOULD be normalized by the sender before the EAP-EKE message is constructed. The normalization method is SASLprep, [RFC4013]. Note that the password is not null-terminated. I don't think this will work. The SHOULD should be a MUST and the mention of SASLprep should use normative language-- i.e. it MUST be SASLprep. Is there a mandatory-to-implement format? Is support for ASCII a MUST? Also, there's no mention of unassigned code points? What happens if one of these is hit during normalization? I don't believe the text as written will assure interoperability and it will also be a DISCUSS target, said using the voice of experience :-) I agree strongly with this comment as well. Issues with elliptic curves cryptography This raises a question. What is the patent status of the technologies used by this document? I recall concerns with some non-HMAC-based password based authentication protocols. I believe it has been submitted: https://datatracker.ietf.org/ipr/1071/ regards, Dan. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
On Tue, April 27, 2010 3:23 am, Dean Anderson wrote: On Mon, 26 Apr 2010, Nicolas Williams wrote: On Mon, Apr 26, 2010 at 04:18:33PM -0500, Marsh Ray wrote: Taking ietf@ietf.org off of CC list as this seems to be very TLS specific. This is an IETF LC, not a WG LC; IETF LC comments should be sent to i...@ietf.org. If anything, we might want to drop t...@ietf.org. I cannot post to IETF@IETF.org, for dishonest and apparently unlawful reasons. I won the consensus call in the PR Action, but the consensus was fraudulently reported. But the PR Action itself is not consistent with the legal requirements to suspend member rights in a member corporation: The law requires a vote of the membership, and that 51% of the membership vote for the suspension/expulsion. There are other legal issues (e.g. antitrust) involved with preventing corporations from participating in a standards body, but I won't go into those here. However, fact remains that I cannot post to i...@ietf.org. All the more reason to drop t...@ietf.org! Dan. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
Hi Jari, I don't believe the simpler solution will increase code size or complexity when compared to the the reuse EAP solution. In fact, it will be less on both counts. In both cases the core key exchange will have to be implemented and in both cases some configuration glue will be needed. But in the reuse EAP solution there is the added code to implement an EAP client and its accompanying state machine, which no IKEv2 gateway currently needs to implement. In addition, a true EAP server, and accompanying state machine, will need to be implemented and IKEv2 gateways will no longer get away with just being a pass through authenticator. The reuse EAP solution will also have to implement some new fragmentation/reassembly code since EAP methods (like ones supporting weak shared secrets) have to roll-their-own. The reuse EAP solution will also have to implement other, unneeded, exchanges (which is why the roundtrips/overhead are greater). When you compare the two, it really is obvious that trying to use EAP in this case increases code size and complexity versus just doing the exchange as part of IKE. EAP is attractive because it provides a generic authentication solution, but here there is really only one type of authentication to do-- using a weak shared secret. It is also attractive because authentication can be centralized with one server serving many network access points. But in this case both sides must have possession of the shared secret and both sides must be capable of initiating the exchange so use of a centralized server is not possible. So all of the attractive features of EAP do not apply and we're left with the undesirable features of EAP-- duplicate identity exchanges, yet more fragmentation/reassembly code, and pointless overhead. I don't think it's better architecturally to reuse EAP in this situation. EAP is a network access protocol where one side attempts to obtain network access from another. There are strict roles played in EAP. In this situation there are no roles and creating a host-to-host SA or network- to-network SA is not really the same thing as obtaining network access. There are some things that EAP is not appropriate for and this is one of them. regards, Dan. On Fri, February 19, 2010 5:39 am, Jari Arkko wrote: Pasi, (Adding the working group mailing list to the discussion; previous discussion has been at i...@ietf.org.) You're right that implementing a weak shared secret EAP method (both the EAP peer and EAP server roles) on both IPsec nodes, combined with the EAP mutual authentication work item (also in the new charter) could be used in this situation, and would result in roughly the same functionality (perhaps with slightly more roundtrips/other overhead -- but that's probably not a critical factor here). OK. And yes, I agree about the significance of roundtrips. NEW: However, user-configured shared secrets are still useful for many other IPsec scenarios, such as authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either peer can initiate an IKEv2 SA. While it would be possible to use EAP in such situations (by having both peers implement both the EAP peer and the EAP server roles of an EAP method intended for weak shared secrets) with the mutual EAP-based authentication work item (above), a simpler solution may be desirable in many situations. This formulation is better than what we had previously. I can live with this. But for the record, I am still surprised that I am the only one worried about this. In my view this additional solution, while perhaps simpler on its own, will increase code size and complexity for most implementations. For instance, a device that serves remote access clients has to implement at least parts of EAP. To support gateway-gateway weak secrets it now has to add support for another, completely different authentication mode and associated configuration mechanisms policies. Architecturally, it would be better to rely on few general solutions than to build special case simpler solutions that taken together, actually become more complex. Not to mention the impact on interoperability. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Proposed Standard
Hi Hannes, As you know EAP-pwd was presented to EMU and the ADs ruled that it was out of scope. Since the ADs are the same, and the EMU charter is the same then EAP-pwd must still be out of scope for EMU. So that course is not available. What Bernard says makes a lot of sense. Unfortunately, that was tried already and it failed. The reason EAP-pwd should be Standards Track is because it is important for the Internet community to recommend a _secure_ way of doing authentication using only a shared key (i.e. no certificate needed). Today we have an Internet recommendation for that practice that is susceptible to a passive off-line dictionary attack. EAP-pwd is not susceptible to such an attack. There is no official policy about Standards track EAP methods only coming out of EMU. And following such an unwritten policy will produce the following bizarre situation for authenticating using a shared key: INSECURE is on Standards Track (EAP-GPSK) SECURE is Informational (EAP-pwd) That makes no sense. Informational RFCs are for edification purposes. Proposed Standards represent a recommendation of the Internet community and if the Internet community is going to recommend a practice (and it obviously is doing that) then it should recommend a secure practice and not an insecure one. Why is that so puzzling? regards, Dan. On Sat, July 25, 2009 2:55 am, Tschofenig, Hannes (NSN - FI/Espoo) wrote: In the past EAP method authors could publish their EAP methods as Informational or Experimental RFCs. For Standards Track EAP methods we had to go through the EMU working group. This is what we did, for example, with the pre-shared key EAP method: * EAP-PSK http://www.rfc-editor.org/rfc/rfc4764.txt was published as an Experimental RFC. * EAP-PAX http://tools.ietf.org/html/rfc4746 was published as an Informational RFC. * EAP-GPSK http://tools.ietf.org/html/rfc5433 was an effort done in the EMU working group with input from various pre-shared EAP method proposals, including EAP-PSK and EAP-PAX. Hence, I agree with Bernard and I am a bit puzzled why draft-harkins-emu-eap-pwd was planned for Proposed Standard. Ciao Hannes From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Bernard Aboba Sent: 23 July, 2009 03:37 To: ietf@ietf.org Subject: Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Proposed Standard I would like to comment on the process aspect of this IETF last call. A subsequent post will provide comments on the protocol. Overall, I believe that the appropriate process for handling this document is not to bring it to IETF last call as an individual submission, but rather to charter a work item within an IETF WG. There are two current EAP method drafts that are based on zero-knowledge algorithms: 1. http://tools.ietf.org/html/draft-harkins-emu-eap-pwd (this document) 2. http://tools.ietf.org/html/draft-sheffer-emu-eap-eke Previously there was also an EAP method submission utilizing SRP: 3. http://tools.ietf.org/html/draft-ietf-pppext-eap-srp-03 All three of these documents were slated for inclusion on the IETF standards track. Given the number of EAP method RFCs that have already been published, I do not believe that it serves the Internet community for the IETF to publish multiple EAP method specifications of a similar genre on the Standards Track, while bypassing the WG process. If the standardization of zero-knowledge algorithms is an important area of work for the IETF (and I believe this to be true), then work in this area should be chartered as a working group work item, with the goal to select a single method for standardization. Prior to the EMU WG re-charter, Dan Harkins made an argument for chartering of work in this area. His arguments were sound then, and they are (even more) sound today. However, Dan did not succeed in getting the work added to the EMU WG charter. It is time for the IESG to re-consider its decision to delay standardization of zero knowledge algorithms, which was made in the earlier part of the decade. If the EMU WG is not suitable for handling this work, then another security area WG should be created for the purpose. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Informational RFC
Hi John, On Wed, July 22, 2009 10:27 am, John Leslie wrote: The difference may not be as great as you seem to think. Appeal if you must, but it's really not unusual to change proposed status as a result of LastCall comments. It might be more helpful to simply post (polite) LastCall comments of your own about why Proposed Standard would be more appropriate than Informational. You make a very good suggestion. So let me make some Last Call comments of my own about why Proposed Standard is more appropriate that Informational. Shared keys (including passwords) are the preeminent access method for the Internet today. EAP is a very popular protocol for providing network access. I believe the Internet community needs to recommend a way to _securely_ use this wildly popular credential in this hugely popular authentication protocol. An Informational RFC is published just for the general information of the Internet community and does not represent a recommendation of the Internet community. So Informational doesn't seem like the right level. The importance of this subject, and the need to have a recommendation by the Internet community, can be seen by the fact that a Standards Track RFC already exists to use shared keys in EAP, RFC5433, but it is insecure and is vulnerable to passive dictionary attack. Therefore I believe it is necessary to recommend a way to use shared keys securely; it is necessary to publish another RFC at the same level as RFC5433 that does not have the flaws of RFC5433. It would not make much sense to have the Internet community recommend an insecure way of using shared keys with EAP and then publish a secure way of using shared keys with EAP merely for edification purposes only. No, a Standards Track RFC is really needed. As Joe Salowey noted, there is another draft that specifies use of the Encrypted Key Exchange (EKE) as an EAP method. Unfortunately, that protocol must define its own special finite cyclic groups, and it cannot use finite cyclic groups based on elliptic curve cryptography, or it will suffer from the same flaw as RFC5433. EAP-pwd can use any of the two score or so finite cyclic groups defined by for use in IKE and TLS, both elliptic curve groups and, more traditional, groups based on exponentiation modulo a large prime number. These groups have seen broad use and received scrutiny by the academic and cryptographic community, so it is important to use them and not roll your own. EAP-pwd is a much more general purpose solution to the problem and is, in my opinion, a better candidate for recommendation. EAP-pwd has received about as much scrutiny as it can in the IETF. When presented at an EMU meeting it received quite a bit of interest but was ruled out-of-scope due to EMU's charter. There were also concerns that there was no definitive statement that EAP-pwd was not IPR encumbered (which is nearly impossible to provide anyway). There is community interest in secure shared-secret authentication with EAP and EAP-pwd provides that. To sum, I think the Internet community must recommend a way to use shared keys (including passwords) securely with EAP (RFC5433 does not recommend a _secure_ way to use them); it must publish an RFC at the Standards Track level. And EAP-pwd is the best choice to do that because it is a more robust and general purpose solution that EAP-EKE. I would like to hear other comments on this topic (with the exception of those over the irrelevant topic of IPR-- for which there is none in this draft). Why shouldn't it be a Proposed Standard? best regards, Dan. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Informational RFC
Hi Joe, As I mentioned in the EMU meeting at IETF-71 I have not patented this exchange, my employer has not patented this exchange, Glen has not patented this exchange, and neither has his employer. I am unaware of any patents on this exchange by others and I believe no existing patents apply. Of course, reasonable people can disagree on whether other known patents apply (and trolls may pop up making claims to hold relevant IPR) but I don't know why that would have an impact on it being published as a Proposed Standard. Let's see how the subject of IPR is being handled _right now_ with other drafts: - TLS extractors: I know you know about this draft because you're the document shepherd. This draft is the subject of an IPR disclosure and is still on the Standards Track in Last Call. EAP-pwd is NOT the subject of any IPR disclosure. - draft-green-secsh-ecc: this specifies how to implement a patented key exchange (ECMQV) in SSH and it is on the Standards Track in Last Call. If specification of patented algorithms and drafts subject to IPR disclosure is not enough to knock a draft of the Standards Track then I don't know why FUD about a possible patent _maybe_ existing that _might_ apply is. I guess I don't understand your logic. Can you explain it in a way that justifies the different treatment for these drafts? Regarding the flaws, yes the -00 version of this draft had a flaw. But then, so did draft-sheffer-emu-eap-eke-00. So if the fact that a flaw was found and fixed is enough to cause you to spoil on a draft then why do you think draft-sheffer-emu-eap-eke is an alternative to consider? Again, I don't understand your logic. EAP-EKE has the additional drawback that it must define its own groups to use because using the standard Diffie-Hellman groups from the IANA registry for IKE or TLS gives an attacker a significant advantage in guessing the password by simply passively observing an exchange. EAP-pwd does not suffer from this and can use groups that have received extensive use and review. Forcing people to use new groups that have not received scrutiny is a recipe for trouble. Furthermore, I do not think that EAP-EKE satisfies its security claims when used with an elliptic curve group. Specifically, I believe it is subject to passive dictionary attack when using an ECC group. Small memory- and processor-constrained devices may not be able to efficiently do operations in a multiplicative field of 3072 bits (to get a suitably strong AES key) while it may in one of 256 bits. Forcing them to use weaker groups is not appropriate. The relevant AD handling advancement of this draft received a private request asking that it be Informational like other EAP methods. He has asked this individual to take the request public but that has not happened. Let me take this opportunity to address that individual in the hopes that he or she speaks up. There is no known policy of which EAP methods get advanced how. It seems very bizarre that an EAP method for authentication using a shared secret that is subject to PASSIVE OFF-LINE DICTIONARY ATTACK is a Proposed Standard (EAP-GPSK) but an EAP method for authentication using a shared secret that is resistant to passive, active and all forms of off-line dictionary attack should be Informational. If it's flawed it's Standards Track, if it's not flawed it's Informational. That doesn't make sense much sense to me. I respectfully request this draft to be published on the track it was intended to be published on. Given that drafts with considerable IPR considerations, both individual submissions and products of a WG, are on the Standards Track, IPR FUD should not be used as a way to prevent this draft from advancing as a Proposed Standard. EAP-pwd is a general purpose solution for the broader Internet community to do EAP authentication using only a password; EAP-EKE is not. EAP-EKE is not an alternative to consider because of it's limited use. There do not seem to be consistently applied policies regarding why a draft has to be Informational so I think it is only fair to treat this draft the way other drafts are being treated (see above): the way it intends to be advanced, as a Proposed Standard. regards, Dan. On Tue, July 21, 2009 3:19 pm, Joseph Salowey (jsalowey) wrote: I object to this document being published as a Proposed Standard. When this document was discussed in the EMU meeting at IETF-71 there was much concern raised with respect to existing IPR in the area of secure password methods used by this draft. Additionally, soon after its initial publication and announcement on the CFRG list, flaws were found with the draft. The authors were very responsive in addressing the issues, but this points out that the algorithms used in this draft have had less review than other secure password mechanisms developed over the years. Another approach to a secure password only EAP method,
Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Informational RFC
Hi Steve, On Tue, July 21, 2009 6:16 pm, Steven M. Bellovin wrote: On Tue, 21 Jul 2009 17:54:23 -0700 (PDT) Dan Harkins dhark...@lounge.org wrote: If specification of patented algorithms and drafts subject to IPR disclosure is not enough to knock a draft of the Standards Track then I don't know why FUD about a possible patent _maybe_ existing that _might_ apply is. I'm no longer an AD, but if I were, I'd propose a policy that the IESG automatically disregard any objection to a spec on the grounds that it uses a patented protocol. I completely agree. I am on the record stating that the TLS Extractors draft should be advanced on the Standards Track. All I'm saying is that the policy applied to it (and others) should apply to mine. Folks, the IETF, via the IPR WG (of which I used to be co-chair) explicitly declined to adopt that standard. The policy under which it operates, *by IETF consensus*, is that the WG should decide for any given document if the (vast) disadvantages of an encumbered technology are outweighed by the abilities it grants. I see no reason whatsoever to even consider a generic objection.; that's not what our explicit policy says. And in this case there is not even a statement that this draft uses encumbered technology, only the lack of a statement that it does not (and given that it's really hard to prove a negative, that is an unreasonable bar to set, in my opinion). I really hope this IPR nonsense as it relates to EAP-pwd can be dispatched. regards, Dan. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard
Certicom's IPR statement dated 13 October 2008 lists some patents that may be necessary and essential to implementations of... the TLS extractor draft when used with either: RFC4492, RFC5289 or draft-rescorla-tls-suiteb. Check it out: http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf Don't use it with RFC4492, RFC5289 or draft-rescorla-tls-suiteb and then the IPR statement does not apply. If it's possible to use the TLS extractor draft in a way that the IPR statement doesn't apply then I don't think you can say the TLS Extractor draft is patent-encumbered. I support free software* and I have no problem with this draft being advanced as a Proposed Standard. regards, Dan. * http://www.lounge.org/siv_for_openssl.tgz is a free version of RFC5297 for OpenSSL, and check out the authsae project on Source Forge. On Mon, July 20, 2009 12:15 pm, Dean Anderson wrote: I am against this standard because of its patent encumbrances and non-free licencing terms. The working group did not get any clear answers on what particular patents this draft may infringe, but a patent holder (Certicom) did assert an IPR disclosure (1004) listing many patents. We have no alternative but to accept the Certicom disclosure statements as meaning that the TLS Extractor draft is patent-encumbered without a universal, free defensive license. The statement by https://datatrackerietf.org/ipr/1004/ referring to http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf which states: Certicom will, upon request, provide a nonexclusive, royalty free patent license, to manufacturers to permit end users (including both client and server sides), to use the patents in schedule A when implementing any of these protocols, including those requiring third party certificates provided the certificate is obtained from a licensed Certificate Authority (CA). This license does not cover the issuing of certificates by a Certification Authority (CA). That is not a free license, since Certicom must respond to the request before any license is granted. After the IETF finally approves the necessary standards, Certicom is free to stop approving the requests. I ask others who support free software to join me in opposing this document by sending a message stating opposition to the IETF@IETF.ORG mailing list. IETF participation is open to the public, and anyone may voice their view on IETF standards. It is also substantive to oppose a document because of its patent status, and in fact, any topic that is considered during or related to the IETF process is substantive. --Dean On Mon, 20 Jul 2009, The IESG wrote: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Keying Material Exporters for Transport Layer Security (TLS) ' draft-ietf-tls-extractor-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-08-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16821rfc_flag=0 ___ TLS mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tls -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ TLS mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-dharkins-siv-aes (SIV Authenticated Encryption using AES) to Proposed Standard
Hi Jouni,
Thank you very much for your review of my I-D and for identification
of the issues you describe below.
I have updated the draft to incorporate your suggested modifications:
- mention S2V before CTR in the description of SIV keying.
- define bitand in section 2.1 as the logical AND of two equal
length strings, then use bitand in sections 2.6 and 2.7 as
you suggest.
- fixed the test vector in section A.2
I also verified that my SIV implementation generates the correct test
vectors and this matches the test vectors sent to NIST.
The draft has been updated and a -03 should be in the repository
right now.
Once again, thanks for your review and for identifying these issues
before the draft got published.
regards,
Dan.
On Wed, May 14, 2008 6:38 am, Jouni Malinen wrote:
- 'SIV Authenticated Encryption using AES '
draft-dharkins-siv-aes-02.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2008-06-10.
It looks like there are couple of small errors in the draft that can
result in incorrect interpretation of the design:
2.2. Overview
SIV-AES uses AES in counter mode (CTR) and in CMAC mode (S2V). SIV-
AES takes either a 256, 384, or 512 bit key (which is broken up into
two equal-sized keys, one for CTR and the other for S2V), a variable
While this is not strictly speaking incorrect statement, it would be
clearer to swap the order of CTR and S2V in the description of the keys
here since the first half of the key is actually used for S2V as
specified in more formal description later in the draft.
2.5. CTR
Before beginning counter mode the 32nd and 64th bits (where the
rightmost bit is the 0th bit) of the counter are cleared. This
2.6. SIV Encrypt
SIV-ENCRYPT(K, P, AD1, ..., ADn) {
Q = V xor (1^64 || 0^1 || 1^31 || 0^1 || 1^31)
2.7. SIV Decrypt
SIV-DECRYPT(K, Z, AD1, ..., ADn) {
Q = V xor (1^64 || 0^1 || 1^31 || 0^1 || 1^31)
The description of pre-processing for the counter is in conflict here.
Chapter 2.5 clears two bits while the SIV-ENCRYPT and SIV-DECRYPT
algorithms are actually swapping lots of bits and not changing the bits
that should have been cleared. It looks like the 'xor' in these
algorithms was supposed to be 'and' which would achieve the desired
clearing of the two bits as defined in 2.5. In addition to this change,
'and' should be added into chapter 2.1 with similar description to 'xor'
since this is the first use of 'A and B' notation in the draft.
A.2. Nonce-based Authenticated Encryption Example
Plaintext:
74686973 20697320 74686520 706c6169
6e746578 7420746f 20656e63 72797074
20757369 6e672053 49562d41 4553
xorend:
74686973 20697320 736f6d65 20706c61
696e7465 78742074 6f20656e 63727966
2d0c6201 f3341575 342a3745 f5c625
ciphertext:
cb900f2f ddbe4043 26601965 c889bf17
dba77ceb 094fa663 b7a3f748 ba8af829
ea64ad54 4a272e9c 485b62a3 fd5c0d
There seems to be a typo here in the second test vector. The lengths of
the plaintext, xorend, and ciphertext should be the same. However, the
described plaintext is one octet shorter than xorend/ciphertext. Based
on the ASCII presentation of the plaintext and beginning of xorend
value, it looks like the plaintext value should start this is some
plaintext, not this is the plaintext in order to end up with the
described output of the test case. In other words, the Plaintext for A.2
should be changed to:
Plaintext:
74686973 20697320 736f6d65 20706c61
696e7465 78742074 6f20656e 63727970
74207573 696e6720 5349562d 414553
With the changes described above, I can reproduce matching results for
the test vectors.
--
Jouni MalinenPGP id EFC895FA
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
Hi Avi, I agree that simply removing the MOARK (aka the DSRK) will not prevent EMSK misuse but it will remove a large temptation to misuse. The sole purpose I can see in the DSRK is to get around the fact that we do not export the EMSK. If there are valid reasons to not export the EMSK then those reasons apply equally to the DSRK and it should be eliminated. If there are no valid reasons to not export the EMSK then let's just export it and then the need for the DSRK goes away. Either way the DSRK should be eliminated. If WiMAX wants constructive instruction from the IETF I suggest it make a request through the 802.16 liaison to IETF. regards, Dan. On Thu, March 20, 2008 7:58 am, Avi Lior wrote: FYI. In WiMAX we derive keys directly from EMSK. We don't use the MOARKs ;-) It maybe a good idea or a bad idea -- we haven't had a chance to look at it because we did our stuff before the MOARK was conceived. We did align at one point with Joe's draft. I am not sure whether defining a MOARK is the root of all evil. It maybe a good idea to derive keys from it in general or it maybe a good idea for HOAKEY to derive its keys from it. Simply removing MOARK is not sufficient to prevent the EMSK to be missused. I think we need to provide the text to describe the pitfalls of EMSK missuse. Also to note, in WiMAX the keys we derive from EMSK are for MIP and other network centric applications such as over the air provisioning. I don't want to give the impression that in WiMAX we are using the EMSK for anything and everything. At the same time, I don't want to give the impression that that is all that WiMAX will use the EMSK for in the future. To be sure it is very tempting indeed to have a source of keying material that is known at the mobile and at the network. That is why I look forward to *constructive* instructions from the IETF. -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 4:52 PM To: Jari Arkko Cc: Avi Lior; ietf@ietf.org; Bernard Aboba Subject: Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet) Hi Jari, On Thu, March 13, 2008 8:49 pm, Jari Arkko wrote: Avi, For what it is worth, this ex-EAP co-chair also thinks that the use of EAP keys for applications is a very bad idea. Why? For a number of reasons. Take this from someone who has actually tried to do this in the distant past and has realized that it was a bad idea. But first let me clarify that I'm not criticizing HOKEY for EAP keys in any way; HOKEY is a fine application for EAP keys. The document that started this thread can be fixed by better IANA and applicability sections. I've also changed the subject to reflect the new topic. Actually I think it's a little more technical than editorial. This problem is due to the fact that HOKEY is extracting a key derived from the EMSK and making that The Mother Of All Root Keys (MOARK), which can be used to derive all keys for all purposes to solve all problems in the world. The document can be fixed by removing the MOARK from the draft and having HOKEY define a _HOKEY-specific_ key derived from the EMSK. That HOKEY-specific key is used for HOKEY and HOKEY only. If some other key usage is needed then it can define another way to extract it's needed keying material from the EMSK, and hopefully that process would be done in the IETF (at least the chances are greater that it would be done in the IETF if it's based on the EMSK and not the MOARK). This has the added benefit of simplifying the key hierarchy. regards, Dan. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
EMSK key hierarchy and the DSRK
Hello, My apologies for being obtuse. This Mother of All Root Keys I've been describing is what the EMSK Key Hierarchy calls the DSRK. The HOKEY key that the ERP/ERX draft uses can be derived in one of two ways: EMSK | USRK-- the HOKEY key, aka rRK or like this: EMSK | DSRK--- the MOARK | DSUSRK -- the HOKEY key, aka rRK This latter derivation is the one that will be used in practice, I believe. This DSRK is not properly defined and cannot be properly scoped. It really has nothing to do with Handover Keying which is what HOKEY is supposed to be working on. I believe the DSRK is problematic and the ability to derive a DSRK should be removed from the ESMK key hierarchy draft and the corresponding change be made to the ERP/ERX draft to remove reference to using a DSRK to derive HOKEY keys. This change would also simplify the key hierarchy and remove a you can do it this way, or you can do it that way option which experience has shown is a really bad idea. regards, Dan. On Tue, March 18, 2008 6:22 pm, Dan Harkins wrote: Hi Avi, On Tue, March 18, 2008 3:13 pm, Avi Lior wrote: [snip] I suggest we discuss the issues with deriving keys from EMSK so that people can make informed decisions. Lets keep the FUD factor low. Good idea. Can we start with the Mother Of All Root Keys (MOARK) that is derived from the EMSK? This seems like a particularly un-scope-able and undefined key. It is not needed for Handover Keying; all HOKEY needed to do was define a HOKEY-specific key from the EMSK but it didn't, it defined a MOARK, and then a HOKEY-specific key is being derived from the MOARK. Since the MOARK is really the only key being derived from the EMSK I guess this makes for a nicely constrained discussion. Dan. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: EMSK key hierarchy and the DSRK
On Wed, March 19, 2008 9:53 am, Lakshminath Dondeti wrote: The DSRK can be scoped just as the EMSK can be scoped. Really? Is there any context that it can be bound to? Furthermore, what is the _purpose_ of this key? Why would someone choose to derive a DSRK or choose not to derive a DSRK for some particular hierarchy? If it's just a some like coke while others like pepsi kind of argument then that's just more reason to get rid of it. Experience from the glamor ciphers and hash algorithms in IKE shows that such pointless options really have a deleterious affect on the standard. regards, Dan. regards, Lakshminath On 3/19/2008 9:45 AM, Dan Harkins wrote: Hello, My apologies for being obtuse. This Mother of All Root Keys I've been describing is what the EMSK Key Hierarchy calls the DSRK. The HOKEY key that the ERP/ERX draft uses can be derived in one of two ways: EMSK | USRK-- the HOKEY key, aka rRK or like this: EMSK | DSRK--- the MOARK | DSUSRK -- the HOKEY key, aka rRK This latter derivation is the one that will be used in practice, I believe. This DSRK is not properly defined and cannot be properly scoped. It really has nothing to do with Handover Keying which is what HOKEY is supposed to be working on. I believe the DSRK is problematic and the ability to derive a DSRK should be removed from the ESMK key hierarchy draft and the corresponding change be made to the ERP/ERX draft to remove reference to using a DSRK to derive HOKEY keys. This change would also simplify the key hierarchy and remove a you can do it this way, or you can do it that way option which experience has shown is a really bad idea. regards, Dan. On Tue, March 18, 2008 6:22 pm, Dan Harkins wrote: Hi Avi, On Tue, March 18, 2008 3:13 pm, Avi Lior wrote: [snip] I suggest we discuss the issues with deriving keys from EMSK so that people can make informed decisions. Lets keep the FUD factor low. Good idea. Can we start with the Mother Of All Root Keys (MOARK) that is derived from the EMSK? This seems like a particularly un-scope-able and undefined key. It is not needed for Handover Keying; all HOKEY needed to do was define a HOKEY-specific key from the EMSK but it didn't, it defined a MOARK, and then a HOKEY-specific key is being derived from the MOARK. Since the MOARK is really the only key being derived from the EMSK I guess this makes for a nicely constrained discussion. Dan. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call on Walled Garden Standard for the Internet
Hi Avi, On Tue, March 18, 2008 3:13 pm, Avi Lior wrote: [snip] I suggest we discuss the issues with deriving keys from EMSK so that people can make informed decisions. Lets keep the FUD factor low. Good idea. Can we start with the Mother Of All Root Keys (MOARK) that is derived from the EMSK? This seems like a particularly un-scope-able and undefined key. It is not needed for Handover Keying; all HOKEY needed to do was define a HOKEY-specific key from the EMSK but it didn't, it defined a MOARK, and then a HOKEY-specific key is being derived from the MOARK. Since the MOARK is really the only key being derived from the EMSK I guess this makes for a nicely constrained discussion. Dan. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
Hi Jari, On Thu, March 13, 2008 8:49 pm, Jari Arkko wrote: Avi, For what it is worth, this ex-EAP co-chair also thinks that the use of EAP keys for applications is a very bad idea. Why? For a number of reasons. Take this from someone who has actually tried to do this in the distant past and has realized that it was a bad idea. But first let me clarify that I'm not criticizing HOKEY for EAP keys in any way; HOKEY is a fine application for EAP keys. The document that started this thread can be fixed by better IANA and applicability sections. I've also changed the subject to reflect the new topic. Actually I think it's a little more technical than editorial. This problem is due to the fact that HOKEY is extracting a key derived from the EMSK and making that The Mother Of All Root Keys (MOARK), which can be used to derive all keys for all purposes to solve all problems in the world. The document can be fixed by removing the MOARK from the draft and having HOKEY define a _HOKEY-specific_ key derived from the EMSK. That HOKEY-specific key is used for HOKEY and HOKEY only. If some other key usage is needed then it can define another way to extract it's needed keying material from the EMSK, and hopefully that process would be done in the IETF (at least the chances are greater that it would be done in the IETF if it's based on the EMSK and not the MOARK). This has the added benefit of simplifying the key hierarchy. regards, Dan. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 -- Dublin!
Hi Edward, On Wed, February 6, 2008 10:29 am, Edward Lewis wrote: At 8:37 -0800 2/6/08, $someone wrote: The descriptions of the venue make clear that, once again, the IETF is meeting in a ghetto. Periodic bus service doesn't counteract that. I really have a hard time being sympathetic to this complaint. If the purpose of the IETF is open discussion and cross-pollination, what does it matter where we are so long as there's comfortable access to the expertise needed? Is there an unwritten requirement that IETFs are placed to afford us sightseeing? To afford us access to restaurants? Think about why a beer in a bar in a city center costs 1/4 the price of a beer in the airport of that same city-- captive audience, it's not like you can go anywhere else. Now, this IETF is at a premier golf resort, 15km outside of city center. That means we'll be a captive audience and we will all eat at the hotel restaurant day in and day out and most likely pay far more than we should. The issue isn't about sightseeing, although that's always nice, it's about forcing people to choose between the same overpriced food you ate for the past two days and possibly missing a session (so you can go out and get a reasonable meal at a reasonable price). [snip] Calling any venue that I have ever been in for any kind of a conference a ghetto is quite an insult to folks that do live in ghettos or other unfortunate places that I have seen. I don't know if it is true now, but as of a few years ago, the IETF had never ventured to a country or economy where the expected life span of a person was below the global mean/average. Other conferences do regularly, even ICANN. That's where you can see a ghetto - on the way from the airport to the 5-star hotel. Please. A ghetto is a homogeneous region for some sort of homogeneity. That could be ethnic but ghetto is not necessarily some slur against poor people or people of some ethnic background. In this case the ghetto is going to be golfers, most likely affluent ones, in their plus-fours and some plaid nightmare of an outfit. We've already lost the word niggardly and the phrase chocolate soldier, neither of which have ethnic or racial connotation, to political correctness. Let's not toss out ghetto too. Dan. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
So there's something else besides key name that is used to identify keys. Great, so that means these hashed key names are unnecessary. No need to do HMAC-SHA256 to generate a random string, throw away 3/4 of that result and come up with something that is unusable. Let's get rid of this stuff since it serves no useful purpose and is computationally expensive. Yes, EAP Session ID (or Username, as Glen suggests) will be hashed. So if you have an rIK and an rRK and 5 or 6 rMSKs all derived from the same EMSK then the EAP Session ID (or Username, as Glen suggests) that identifies that EMSK can be used as the index in the hash table and all the derivatives are guaranteed to end up in the same bucket. You look up based on an identifier on the root and everything is right there in your hands. If the namespace is completely flat then searching for all related keys is a pain. Dan. On Tue, February 5, 2008 12:02 pm, Joseph Salowey (jsalowey) wrote: There is nothing in the document that says you must index keys only by key id. I don't really understand the problem here, there is other context associated with a key besides a name that can be used for indexing. The key name provides a fixed length unique identifier for the key. EAP Session-ID is not fixed length and can be awkward to use in protocols, most likely you will end up hashing it anyway. Joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Harkins Sent: Friday, February 01, 2008 5:46 PM To: Dan Harkins Cc: ietf@ietf.org; [EMAIL PROTECTED] Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard Hello again, Pardon my repetition but I have come up with a very valid reason why naming keys using HMAC-SHA-256 is a bad idea. If one wants to administratively remove all keys in a particular key hierarchy (which seems like an entirely reasonable request) one must do a linear search of all keys in all key hierarchies that a particular server maintains! This is because HMAC-SHA-256 has mapped all identifying key information for all key hierarchies to the same name space. It precludes using something like a hash table for fast lookup of all related keys. If keys were named by concatenating the EAP Session-ID with a string that identified the particular key in the key hierarchy rooted at the MK derived in that EAP Session-ID then the EAP Session-ID could be used as an index into a hash table and all keys for that particular key hierarchy could be looked up very efficiently. regards, Dan. On Fri, February 1, 2008 5:16 pm, Dan Harkins wrote: Hello, I believe this is a well organized and complete document. On numerous occasions while reviewing it I made a mental question regarding something only to have the question answered in a subsequent paragraph. I do have several comments though: 1. this protocol can be used in the presence of AAA proxies. Due to the nature of AAA proxies a peer or authenticator may not even know whether they are part of the communication chain. Therefore, from the view of a security threat their presence must be assumed by the peer and authenticator. The Domain referred to in section 2 (part of the EMSK key hierarchy draft) specifically allows for proxies as part of the distributed system of computers that define the Domain. This brings up many significant issues that are not addressed in this draft. - It cannot be claimed that a key is being bound to its context when the context cannot even be scoped. (Section 6) - The domino effect is not prevented because compromise of a proxy will compromise keying material on (other) authenticators. - A pairwise key is being given by one of the entities that share it, e.g. the server, to a 3rd entity, e.g. a proxy, without the consent of the other peer that shares the key, e.g. the peer. This brings up security considerations that are not discussed. - During discussions at a HOKEY meeting and on the list the rationale that justified proxies was that the peer is more concerned about receiving network access (which is confirmed in the ERP document when it says, The primary purpose [of ERP] is network access control.) than about specifically authenticating the network. Provided that service is obtained with no surprises in the bill at the end of the month the rationale was that the peer didn't care if the key was distributed to proxies if it was necessary to continue to provide network access. Which is a reasonable rationale. But it needs to be mentioned in this document. It has a unique threat model that is not discussed anywhere. - The aforementioned rationale begs
RE: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
Hi Glen, On Mon, February 4, 2008 1:09 am, Glen Zorn wrote: [snip] Doesn't sound particularly readable to me; in any case, I don't think that it really matters (for the purposes you describe, however unlikely they may be) what the key name looks like. What matters is how easy it is to find the key, which depends upon the structure of the database in which it resides. Bingo! And by putting every key for every hierarchy for every user for every domain for every usage through SHA-256 the structure of the database is flat. I'm not particularly wed to using the EAP session ID as an index. Your suggestion of Username is perfectly fine. But the current idea of using SHA-256 is wrong. Dan. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
Hi Glen, On Sun, February 3, 2008 12:28 am, Glen Zorn wrote: Dan Harkins scribbled on Saturday, February 02, 2008 8:46 AM: Hello again, Pardon my repetition but I have come up with a very valid reason why naming keys using HMAC-SHA-256 is a bad idea. If one wants to administratively remove all keys in a particular key hierarchy (which seems like an entirely reasonable request) It doesn't seem particularly reasonable to me. The one reason I can think of for this is to disable access for a particular user in some domain; to do that it doesn't seem necessary to explicitly remove all the keys in the hierarchy, just the root key (after disconnecting the user). Disconnecting the user should delete the PMK, TSKs, etc., right? Yes, it should delete the other keys. And if I am the entity that holds the root key and you are an ER server that holds some derivatives like a DSUSRK and some derivatives of that like rMSKs for different authenticators in that domain then what information should I give you to identify the particular hierarchy I'm talking about? Remember you may hold other key hierarchies for other users in other domains for other usages and they all use the same name space. An incomprehensible string of random bits doesn't seem particularly helpful in accomplishing the task. one must do a linear search of all keys in all key hierarchies that a particular server maintains! all identifying key information for all key hierarchies to the same name space. It precludes using something like a hash table for fast lookup of all related keys. If keys were named by concatenating the EAP Session-ID with a string that identified the particular key in the key hierarchy rooted at the MK derived in that EAP Session-ID then the EAP Session-ID could be used as an index into a hash table and all keys for that particular key hierarchy could be looked up very efficiently. I won't argue that indexing the keystore by Session-ID is a bad idea (though Username might be better), but I can't see how that depends upon the actual key name. Glen, the issue is that not only is every key in the hierarchy mapped to the same name space, every key for every user's hierarchy for every domain for every usage is all mapped to the same name space! Yea, mapping by Username might be better. Oone reason is that you could develop a rational searching strategy to identify keys if you indexed with something like Username. That is a great suggestion and a useful alternative to what is in the draft now. I would support such a change. Can you tell me one use for a key name that is an incomprehensible string of random bits? Delete all keys associated with 0x58d610a8ff4128c9 uhm, ok If not then don't you agree the current key naming scheme is completely useless? Dan. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
[HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
Hello, I believe this is a well organized and complete document. On numerous occasions while reviewing it I made a mental question regarding something only to have the question answered in a subsequent paragraph. I do have several comments though: 1. this protocol can be used in the presence of AAA proxies. Due to the nature of AAA proxies a peer or authenticator may not even know whether they are part of the communication chain. Therefore, from the view of a security threat their presence must be assumed by the peer and authenticator. The Domain referred to in section 2 (part of the EMSK key hierarchy draft) specifically allows for proxies as part of the distributed system of computers that define the Domain. This brings up many significant issues that are not addressed in this draft. - It cannot be claimed that a key is being bound to its context when the context cannot even be scoped. (Section 6) - The domino effect is not prevented because compromise of a proxy will compromise keying material on (other) authenticators. - A pairwise key is being given by one of the entities that share it, e.g. the server, to a 3rd entity, e.g. a proxy, without the consent of the other peer that shares the key, e.g. the peer. This brings up security considerations that are not discussed. - During discussions at a HOKEY meeting and on the list the rationale that justified proxies was that the peer is more concerned about receiving network access (which is confirmed in the ERP document when it says, The primary purpose [of ERP] is network access control.) than about specifically authenticating the network. Provided that service is obtained with no surprises in the bill at the end of the month the rationale was that the peer didn't care if the key was distributed to proxies if it was necessary to continue to provide network access. Which is a reasonable rationale. But it needs to be mentioned in this document. It has a unique threat model that is not discussed anywhere. - The aforementioned rationale begs the question of why have Domain Specific Keys. If the peer doesn't care whether proxies have a key, potentially for a different domain, then it doesn't care about key separation between domains. This is significant added complexity for no benefit. - RFC4962 REQUIRES things-- bind key to its context, prevent the domino effect-- that ERP cannot support. ERP is a AAA key management protocol though and falls under the scope of RFC4962. There needs to be justification for why ERP is not meeting the mandatory requirements of RFC4962. I think all of these issues need addressing before advancement of this Internet-Draft. 2. Inter-Domain ERP It is this reviewers recollection that consensus was reached in HOKEY to require a peer to reauthenticate back to the home AAA server every time it attached to a POP in different domain. Therefore, I wonder why a Domain-Specific key, the DSRK, and all it's progeny-- DS-rIK, DS-rRK, DSUSRK, etc.-- continue to be used by this protocol. A HOKEY-KEY, a USRK, should be derived from the EMSK and that is the key given, through proxies if need be, to the ER server in the visited domain. If the peer goes to a different domain then it does a full reauthentication resulting in a _new_ USRK, that has no relation to the previous USRK, being given to the ER server in the new domain. Again, it was my understanding that the group already reached consensus on this matter. 3. HMAC-SHA256 as a key naming technique SHA-256 is a computationally intensive operation; HMAC-SHA256 doubly so. There should, therefore, be some justification to use such a strong cryptographic mixing function if all one wants to do is uniquely name a key. EAP methods export a Session-ID. An rIK can be named by the concatenation of Session-ID and rIK. Similarly for the rMSK, rRK and the other keys being generated in ERP. This has the added benefit of allowing for key management to quickly identify keys based on common queries-- all the keys for a specific Session-ID, or all rIKs held by a particular entity. By using a strong cryptographic mixing function all specificity of the key names has been lost across every single key hierarchy that a HOKEY server may end up managing. This is a really bad idea and it should be changed before this Internet-Draft is advanced. 4. Section 5.3.2 EAP-Initiate/Re-Auth Packet This packet has the following field: +-+-+-+-+-+-+-+-+ |R|B|L| Reserved| +-+-+-+-+-+-+-+-+ And R is, itself, reserved. This makes no sense. Please 1 this field. regards, Dan. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
Hello again, Pardon my repetition but I have come up with a very valid reason why naming keys using HMAC-SHA-256 is a bad idea. If one wants to administratively remove all keys in a particular key hierarchy (which seems like an entirely reasonable request) one must do a linear search of all keys in all key hierarchies that a particular server maintains! This is because HMAC-SHA-256 has mapped all identifying key information for all key hierarchies to the same name space. It precludes using something like a hash table for fast lookup of all related keys. If keys were named by concatenating the EAP Session-ID with a string that identified the particular key in the key hierarchy rooted at the MK derived in that EAP Session-ID then the EAP Session-ID could be used as an index into a hash table and all keys for that particular key hierarchy could be looked up very efficiently. regards, Dan. On Fri, February 1, 2008 5:16 pm, Dan Harkins wrote: Hello, I believe this is a well organized and complete document. On numerous occasions while reviewing it I made a mental question regarding something only to have the question answered in a subsequent paragraph. I do have several comments though: 1. this protocol can be used in the presence of AAA proxies. Due to the nature of AAA proxies a peer or authenticator may not even know whether they are part of the communication chain. Therefore, from the view of a security threat their presence must be assumed by the peer and authenticator. The Domain referred to in section 2 (part of the EMSK key hierarchy draft) specifically allows for proxies as part of the distributed system of computers that define the Domain. This brings up many significant issues that are not addressed in this draft. - It cannot be claimed that a key is being bound to its context when the context cannot even be scoped. (Section 6) - The domino effect is not prevented because compromise of a proxy will compromise keying material on (other) authenticators. - A pairwise key is being given by one of the entities that share it, e.g. the server, to a 3rd entity, e.g. a proxy, without the consent of the other peer that shares the key, e.g. the peer. This brings up security considerations that are not discussed. - During discussions at a HOKEY meeting and on the list the rationale that justified proxies was that the peer is more concerned about receiving network access (which is confirmed in the ERP document when it says, The primary purpose [of ERP] is network access control.) than about specifically authenticating the network. Provided that service is obtained with no surprises in the bill at the end of the month the rationale was that the peer didn't care if the key was distributed to proxies if it was necessary to continue to provide network access. Which is a reasonable rationale. But it needs to be mentioned in this document. It has a unique threat model that is not discussed anywhere. - The aforementioned rationale begs the question of why have Domain Specific Keys. If the peer doesn't care whether proxies have a key, potentially for a different domain, then it doesn't care about key separation between domains. This is significant added complexity for no benefit. - RFC4962 REQUIRES things-- bind key to its context, prevent the domino effect-- that ERP cannot support. ERP is a AAA key management protocol though and falls under the scope of RFC4962. There needs to be justification for why ERP is not meeting the mandatory requirements of RFC4962. I think all of these issues need addressing before advancement of this Internet-Draft. 2. Inter-Domain ERP It is this reviewers recollection that consensus was reached in HOKEY to require a peer to reauthenticate back to the home AAA server every time it attached to a POP in different domain. Therefore, I wonder why a Domain-Specific key, the DSRK, and all it's progeny-- DS-rIK, DS-rRK, DSUSRK, etc.-- continue to be used by this protocol. A HOKEY-KEY, a USRK, should be derived from the EMSK and that is the key given, through proxies if need be, to the ER server in the visited domain. If the peer goes to a different domain then it does a full reauthentication resulting in a _new_ USRK, that has no relation to the previous USRK, being given to the ER server in the new domain. Again, it was my understanding that the group already reached consensus on this matter. 3. HMAC-SHA256 as a key naming technique SHA-256 is a computationally intensive operation; HMAC-SHA256 doubly so. There should, therefore, be some justification to use such a strong cryptographic mixing function if all one wants to do is uniquely name a key. EAP methods
Re: Travel Considerations
which could have unpleasant consequences. Prudence would suggest that we take steps to mitigate these consequences. To argue about what these steps should be is reasonable, but to totally ignore the situation is not. Hope this helps. As I said before, I'll shut up about this now, at least on this list. Regards Marshall On Oct 13, 2007, at 12:03 AM, Dan Harkins wrote: Hi James, I think you're missing the point. I'm not advocating being wasteful because everyone else is. I'm saying that this effort is futile and will not result in _any_ win for the planet. Your analogy to driving an SUV is incorrect because not driving the SUV (or driving an electric car instead) results in less emissions. A trivial amount but every little bit helps. Flying 1000 people to Frankfurt instead of Prague does not result in any less emissions. Encouraging other organizations to follow our lead-- having 1 people scattered over the course of a year fly to a hub instead of through the hub to a spoke-- won't either. The demand is still there to fly to places like Prague and San Diego and airlines typically fly at less than 100% capacity, sometimes significantly so. If you think there is an individual responsibility to change what you can then please don't waste your effort on something that won't have any effect! Do something that will make a difference. I for one would rather fly to (spoke) Prague than (hub) Frankfurt; to (spoke) San Diego than to (hub) Chicago; and anywhere (spoke) on God's green earth (yes, it's still green in spite of the IETF World Tour) than (hub) London. Dan. On Fri, October 12, 2007 12:17 pm, James M. Polk wrote: Unfortunately, using this logic -- I can buy a tank and get 2 gallons-to-the-mile mileage because the rest of the planet (or at least America) is still buying SUVs that get horrible mileage too, since there will be nearly an unmeasurable difference to global warming if I drive my tank or not... so why not drive it anyway. There is an individual responsibility to change what we each can change to help. As an organization, we can have a greater positive affect if we reduce demand for such spoke flights by only flying to hub sites of major airlines -- if we're going to continue to meet in person. If other organizations see ours as an example, and do the same, then the positive affect is greater on us doing the right thing... Doing the right thing in mass has to start somewhere -- why does it have to start somewhere else here? It's Friday... At 01:30 PM 10/12/2007, Dan Harkins wrote: You're assuming that if 1000 people decide not to fly to Prague some weekend that the number of planes burning jet fuel to fly there will be different. I don't think so. Maybe you can start a Boycott Prague The Spoke City campaign which, if wildly successful, will reduce demand to fly there by some discernable amount and thereby reduce the number of planes flying there and the amount of jet fuel they would've burned. Well, as long as the planes that aren't flying to Prague aren't used to fly to Heathrow or Frankfurt or some other hub city. Also doubtful. I do not intend on making ietf-discuss into a forum for discussing the pluses and minuses resulting from a degree centigrade temperature change but let me just say that the planet wins is a somewhat dubious statement. Dan. On Fri, October 12, 2007 7:32 am, Eric Burger wrote: Here is an interesting optimization problem: it turns out the most polluting part of a conference is people taking jets to fly to the conference. Minimize that and the planet wins. Favors hub cities over spokes, like San Diego or Prague, where you can't get there from here, no matter where here is. See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -BEGIN PGP SIGNATURE- iD8DBQFHEDp5bjEdbHIsm0MRAslgAKDSi+UeR/OnCD1QiXbjIwbHB6RV/ACgqPve GXSX3XJqDkWibCQ1NeuDivA= =TqSH -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman
Re: Travel Considerations
You're assuming that if 1000 people decide not to fly to Prague some weekend that the number of planes burning jet fuel to fly there will be different. I don't think so. Maybe you can start a Boycott Prague The Spoke City campaign which, if wildly successful, will reduce demand to fly there by some discernable amount and thereby reduce the number of planes flying there and the amount of jet fuel they would've burned. Well, as long as the planes that aren't flying to Prague aren't used to fly to Heathrow or Frankfurt or some other hub city. Also doubtful. I do not intend on making ietf-discuss into a forum for discussing the pluses and minuses resulting from a degree centigrade temperature change but let me just say that the planet wins is a somewhat dubious statement. Dan. On Fri, October 12, 2007 7:32 am, Eric Burger wrote: Here is an interesting optimization problem: it turns out the most polluting part of a conference is people taking jets to fly to the conference. Minimize that and the planet wins. Favors hub cities over spokes, like San Diego or Prague, where you can't get there from here, no matter where here is. See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Travel Considerations
Hi James, I think you're missing the point. I'm not advocating being wasteful because everyone else is. I'm saying that this effort is futile and will not result in _any_ win for the planet. Your analogy to driving an SUV is incorrect because not driving the SUV (or driving an electric car instead) results in less emissions. A trivial amount but every little bit helps. Flying 1000 people to Frankfurt instead of Prague does not result in any less emissions. Encouraging other organizations to follow our lead-- having 1 people scattered over the course of a year fly to a hub instead of through the hub to a spoke-- won't either. The demand is still there to fly to places like Prague and San Diego and airlines typically fly at less than 100% capacity, sometimes significantly so. If you think there is an individual responsibility to change what you can then please don't waste your effort on something that won't have any effect! Do something that will make a difference. I for one would rather fly to (spoke) Prague than (hub) Frankfurt; to (spoke) San Diego than to (hub) Chicago; and anywhere (spoke) on God's green earth (yes, it's still green in spite of the IETF World Tour) than (hub) London. Dan. On Fri, October 12, 2007 12:17 pm, James M. Polk wrote: Unfortunately, using this logic -- I can buy a tank and get 2 gallons-to-the-mile mileage because the rest of the planet (or at least America) is still buying SUVs that get horrible mileage too, since there will be nearly an unmeasurable difference to global warming if I drive my tank or not... so why not drive it anyway. There is an individual responsibility to change what we each can change to help. As an organization, we can have a greater positive affect if we reduce demand for such spoke flights by only flying to hub sites of major airlines -- if we're going to continue to meet in person. If other organizations see ours as an example, and do the same, then the positive affect is greater on us doing the right thing... Doing the right thing in mass has to start somewhere -- why does it have to start somewhere else here? It's Friday... At 01:30 PM 10/12/2007, Dan Harkins wrote: You're assuming that if 1000 people decide not to fly to Prague some weekend that the number of planes burning jet fuel to fly there will be different. I don't think so. Maybe you can start a Boycott Prague The Spoke City campaign which, if wildly successful, will reduce demand to fly there by some discernable amount and thereby reduce the number of planes flying there and the amount of jet fuel they would've burned. Well, as long as the planes that aren't flying to Prague aren't used to fly to Heathrow or Frankfurt or some other hub city. Also doubtful. I do not intend on making ietf-discuss into a forum for discussing the pluses and minuses resulting from a degree centigrade temperature change but let me just say that the planet wins is a somewhat dubious statement. Dan. On Fri, October 12, 2007 7:32 am, Eric Burger wrote: Here is an interesting optimization problem: it turns out the most polluting part of a conference is people taking jets to fly to the conference. Minimize that and the planet wins. Favors hub cities over spokes, like San Diego or Prague, where you can't get there from here, no matter where here is. See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
On Mon, April 9, 2007 3:38 pm, [EMAIL PROTECTED] wrote: [snip] I'd define the EAP channel binding problem as follows. There are two sets of identities that the peer and authenticator use: one at the EAP layer and one at a lower layer. There is an additional identity that the authenticator may use to authenticate to the AAA server. The channel binding problem is to make sure that the EAP server authorizes the authenticator's use of the lower layer identity to the peer and the peer's use of a given lower layer identity. I don't agree. The channel binding problem is to make sure the EAP server and the peer agree to whom the key is being disclosed. They have to agree on a common identity that is relevant at the EAP layer. You're right that the authenticator can have 3 identities-- a lower layer identity like a MAC address, a NAS ID, and some identity that was used to create a security association with the AS. The AS doesn't know and doesn't care what the lower layer identity of the authenticator is. Likewise the peer doesn't know and doesn't care what identity the authenticator used to establish a security association with the AS (most likely an IP address). But they are both speaking EAP and there is an identity of the authenticator that they can both agree on and that is relevant at that layer-- the NAS ID. EAP channel binding is a protected exchange, between the peer and AS, of this identity (the NAS ID not a lower layer identity) and the identity passed in the protected exchange is verified with the identity established in some out-of-band fashion (for instance, at provisioning time of the NAS). If they are equal then all systems are go, if they are not then houston we have a problem. Dan. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt
Hi Sam, On Wed, April 4, 2007 6:16 pm, Sam Hartman wrote: 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. I just don't see that in draft-housley-aaa-key-mgmt-09.txt which says: Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role. A party has access to a particular key if it has access to all of the secret information needed to derive it. The role of the particular party is an authenticator and this key is for that purpose. There's nothing there about a purpose involving specific entities (peer foo and authenticator bar). I snipped the 2nd paragraph in that section because it talks about session keys, and: 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. They are not keys used for bulk traffic protection. At least not in my mind. There is something the aforementioned draft refers to as a secure association protocol used to derive keys used for bulk traffic protection-- like 802.11's 4 way handshake. The 2nd paragraph that I snipped above deals with such a secure association protocol and the identities identified in that protocol are low-layer identities-- a BSSID or a MAC address-- used to send protected packets/frames between the peer and authenticator. I guess you could use the key being distributed directly as a bulk traffic protection key but then return handoffs-- peer goes from A to B and back to A-- would require additional trips to the AAA server which is something we want to avoid. 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? Provided there are no channel binding issues and the all parties are authenticated and the authenticated identity is authorized to hold the distributed key I guess there isn't anything wrong. The reason I'm bringing this up, though, is because AAA is now being used as a key distribution protocol-- 802.11r and HOKEY-- and these issues are not being addressed in that use of AAA. In discussions with people it is apparent they think the channel binding mention in the aforementioned draft deals with EAP. They think authentication of all parties just means establishing some security association (using a RADIUS shared secret for instance, or an IPsec SA) and the identity that was authenticated during its creation is irrelevant and not used during the distribution of a key. Any new security issues that they might create by using AAA as a key distribution protocol are ignored and compliance to the Housley Criteria is claimed. 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. I will step away from that question. I did not intend on introducing any new issues when I brought it up. Although I honestly don't see how you can solve the issue of binding a common authenticator identity between the peer and AAA server (the two entities that share the secret that is being disclosed to the authenticator) without involving the peer. Dan. ___ 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: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt
Sam, I guess the question is, what text in this I-D would prevent a new key distribution protocol based on AAA in which the authentication server sent a copy of the peer's keys willy-nilly to every authenticator it had a security association with? Another question: has the peer no say in to whom its secrets are disclosed? If you think it does then what in the I-D addresses that concern and if you don't think it does then why? As I have stated (starting with my 16 Feb 07 comments) I think this is an important I-D and we need an RFC on this subject. I just don't think it goes far enough in proscribing bad behavior and mandating good behavior. Again, the 802.11 Task Group r is a prime example of why this I-D does not go far enough. I think this I-D has to discuss the use of AAA as a key distribution protocol and it does not do that right now. At the SAAG meeting you said (something to the effect of) everyone understands the 'channel binding' issue. I don't necessarily agree with you (see 802.11r) but the problem is that when AAA is used as a key distribution protocol that issue explodes in another dimension. And people think that if it's OK to ignore that issue in the traditional EAP case where an authentication server gives single key to single authenticator through whom the peer is speaking then it must be OK to ignore it when distributing keys to a multiplicity of authenticators that the peer is not, and may never be, speaking to. Dan. On Fri, March 30, 2007 10:52 am, Sam Hartman wrote: Hi. I had a few discussions in Prague and think that we're all basically on the same page about what the document should say. I'm going to describe that consensus here. I'd like to ask Russ to confirm that the document reflects the consensus and if so to ask me to remove my discuss and approve the document. Unless I've really gotten something wrong here, I think we're done deciding what we are trying to say and are only left with deciding if we've managed to say it. When two parties communicate in these protocols they must authenticate each other. Typically EAP is used to authenticate the peer and the EAP server. Typically AAA protocols authenticate the authenticator and the AAA server. Typically secure association protocols run between the peer and authenticator. It's common for the EAP layer identities to be different from the lower layer identities. There are two types of lower layer identities: those that are used for authorization and those that are not. AN example of an identity not used for authorization would be a network that had a concept like a MAC address that is not used for access control. The MAC address is used to look up keys, but all people granted access to the network have the same authorizations. In this case it's not important to make sure that the peer is claiming a MAC address that is appropriate for the EAP layer identity of the peer. However in a network where the MAC address is used to make authorization decisions, someone needs to make sure that the peer's EAP identity is authorized to claim the MAC address that it claims. Typically the AAA server fills this role. However it would be OK to architect a design where the authenticator filled that role--I don't think you'd use RADIUS or Diameter in such a design though. The authenticator probably has a lower layer identity too. The AAA server needs to authorize this identity to the peer. Typically this would happen by the AAA server looking at what authenticator the peer claims it is connecting to, looking at the higher layer identity that the authenticator is using to communicate to the AAA server and confirming that the higher layer identity is authorized to claim the lower layer identity to peers. It's OK to have things like WLAN switches that are authenticators including a large number of physical devices. They can have one higher layer identifier and a lot of lower layer identifiers. They could potentially also have one lower layer identifier. Unlike the peer identity, we always assume that the lower layer authenticator identity needs to be authorized. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Dan Harkins] comments on draft-houseley-aaa-key-mgmt-07.txt
Lakshminath, Actually we're discussing my suggested additions to an individual submission that is in IESG evaluation stage. Since I do not believe they will be accepted at this point in time I don't see a point in elaborating on them here. We're intersecting on this issue for one reason and one reason only: HOKEY. If you want to a full description of the problem then read (and comment on) the Problem Statement and Requirments on a 3-Party Key Distribution Protocol for Handover Keying. Please do so on the HOKEY list so we are sure to include all the people who might care but are not on this list. thanks, Dan. On Thu, March 8, 2007 12:41 am, Lakshminath Dondeti wrote: Dan Harkins wrote: Hi Lakshminath, That's not entirely correct. As I recently stated to your colleage if a 3 party key distribution scheme finishes and all 3 parties think it finished successfully but they do not agree on all state then the scheme is flawed. Could you elaborate on what part is missing from my description please? What is in the state that the parties need to agree on? I see the path you're trying to go down-- add a server nonce, assume everything is now fine-- and I'm not going to follow you down there. In this round, I am trying to get a full description of the problem before jumping into solutions, but now that you mention this what in your view is wrong with this approach? What necessary properties are lost? Perhaps exploring this might help us agree on the problem. This is not the forum for this discussion. This is the IETF Discussion list after all and we are discussing an individual submission that is in the IESG evaluation stage. To my knowledge, this is the appropriate open forum. Let's take this to the HOKEY list if you really want to continue. Better yet we can discuss it over a Budvar in Prague. I am ok with an offline discussion in Prague, but I am not sure whether we have that much time. regards, Lakshminath Dan. On Wed, March 7, 2007 10:51 pm, Lakshminath Dondeti wrote: Dan Harkins wrote: Sam, 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. Dan, I snipped all the rest of the email so I can get a clarification from you on this particular paragraph. The problem you describe here is that the authenticator gets a key based on the claimed identity of the authenticator. If the peer and the server do not have a way to verify the identity of the authenticator it is a problem because the key that the server sends to the authenticator is the same as long as the claimed identity of the authenticator is the same. Do I understand correctly? thanks, Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Dan Harkins] comments on draft-houseley-aaa-key-mgmt-07.txt
Hi Sam, Thanks for the update. My original comment never made it to the ietf list because I wasn't a member at the time of posting. I was informed that if the moderator approved my posting it would be sent to the list, unfortunately it wasn't. :-( In the new Peer and authenticator authorization section the last paragraph has no keywords signifying a requirement. That seems strange to me considering the message the paragraph is trying to convey seems important. ...key management protocols need to demonstrate... seems like it should be ...key management protocols MUST demonstrate... The final sentence says ...channel binding is required... and that should be ...channel binding MUST be performed... I bring this up because I have seen people attempt to maneuver in such weasel room in an attempt to not do The Right Thing. Also, my comment on the Authenticate all parties section regarding authenticator impersonation was because the only mention of identities is in the context of generating session keys. My concern is around key distribution from a AAA server to an authenticator. I asked for the following text to be added: When a security association is used to distribute keying material the security association SHOULD be bound to a unique identity that can be commonly known by all the parties-- including the peer. If the security association cannot be based on such an identity then it MUST be statically configured to be an attribute of the security association. And that unique identity was then to be used as follows in a new section: When another party requires access to keying material the identity of that party MUST be authenticated prior to distribution of the keying material. The distributor MUST ensure that the keying material is not disclosed to the wrong party. This can be accomplished, for example, by verifying the identity of the party to whom the keying material is being disclosed with the identity bound to the security association under which it will be sent. When keying material is disclosed the other party on whose behalf it is being disclosed MUST confirm disclosure. For example, a peer MUST acknowledge disclosure of keying material from a AAA server to an authenticator and the identity of the authenticator MUST be confirmed by the peer and AAA server. I think my first two points are serious objections but will accept the fact that other people don't. Also, I reiterate my suggestion for text regarding identities because the post never made it to the list. If the authors considered my suggestion but did not accept it then that's all I could ask for. So I would still like to see some changes but understand if no one else views these as serious objections. thanks, Dan. On Wed, March 7, 2007 8:05 am, Sam Hartman wrote: Hi, folks. The following last call comment was received and based on discussion the draft was updated. This comment never seems to have made it to the ietf list though. The following text was added to address the comment. Please confirm that this text addresses the comment and that from the following text it is clear that these requirements prohibit authenticator impersonination: Peer and authenticator authorization Peer and authenticator authorization MUST be performed. These entities MUST demonstrate possession of the appropriate keying material, without disclosing it. Authorization is REQUIRED whenever a peer associates with a new authenticator. The authorization checking prevents an elevation of privilege attack, and it ensures that an unauthorized authenticator is detected. Authorizations SHOULD be synchronized between the peer, NAS, and backend authentication server. Once the AAA key management protocol exchanges are complete, all of these parties should hold a common view of the authorizations associated the other parties. In addition to authenticating all parties, key management protocols need to demonstrate that the parties are authorized to possess keying material. Note that proof of possession of keying material does not necessarily prove authorization to hold that keying material. For example, within an IEEE 802.11i, the 4-way handshake demonstrates that both the peer and authenticator possess the same EAP keying material. However, by itself, this possession proof does not demonstrate that the authenticator was authorized by the backend authentication server to possess that keying material. As noted in RFC 3579 in section 4.3.7, where AAA proxies are present, it is possible for one authenticator to impersonate another, unless each link in the AAA chain implements checks against impersonation. Even with these checks in place, an
Re: [Dan Harkins] comments on draft-houseley-aaa-key-mgmt-07.txt
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.
RE: [Dan Harkins] comments on draft-houseley-aaa-key-mgmt-07.txt
If you have a 3 party key distribution scheme and at the end of it the 3 parties do not share ALL THE SAME STATE yet believe the protocol has successfully completed then your key distribution scheme is flawed. Dan. On Wed, March 7, 2007 8:32 pm, Narayanan, Vidya wrote: 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. None of this is feasible when the key distributed to BAR (impersonating as FOO) is different from the key distributed to FOO (appearing as FOO). In other words, a peer connects to BAR and thinks it is connected to FOO. The server also thinks the peer is connected to FOO; a key (say, K1) is derived (with freshness) and given to FOO aka BAR. But, at this point, the real FOO DOES NOT have K1. When the peer tries to attach to the real FOO, it may attempt to use K1, but, will fail. If another key is requested for/by the real FOO, all the server has to ensure is that K1 is *never* given (in fact, K1 should never have been cached and MUST be forgotten after delivery); a *different* key (say, K2) must again be derived (with freshness, again) and given. In other words, no two key retrievals from the server must result in the same key being distributed, even if the entity requesting the key is *seemingly* the same. This only means that every transported key MUST have an element of freshness (say, at least a server nonce) that must be communicated with end-to-end protection between the server and peer. Ensuring correctness of identities while allowing the same key to be retrievable upon multiple fetches is only *one* way to achieve the security properties you are trying to achieve. In fact, *never* allowing the same key to be retrievable multiple times even by the same entity will consistently achieve these security properties, irrespective of the correctness of identities. Vidya ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Dan Harkins] comments on draft-houseley-aaa-key-mgmt-07.txt
Hi Lakshminath, That's not entirely correct. As I recently stated to your colleage if a 3 party key distribution scheme finishes and all 3 parties think it finished successfully but they do not agree on all state then the scheme is flawed. I see the path you're trying to go down-- add a server nonce, assume everything is now fine-- and I'm not going to follow you down there. This is not the forum for this discussion. Let's take this to the HOKEY list if you really want to continue. Better yet we can discuss it over a Budvar in Prague. Dan. On Wed, March 7, 2007 10:51 pm, Lakshminath Dondeti wrote: Dan Harkins wrote: Sam, 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. Dan, I snipped all the rest of the email so I can get a clarification from you on this particular paragraph. The problem you describe here is that the authenticator gets a key based on the claimed identity of the authenticator. If the peer and the server do not have a way to verify the identity of the authenticator it is a problem because the key that the server sends to the authenticator is the same as long as the claimed identity of the authenticator is the same. Do I understand correctly? thanks, Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: comments on draft-houseley-aaa-key-mgmt-07.txt
Hi Vidya, On Sat, February 17, 2007 11:43 pm, Narayanan, Vidya wrote: Yes, the problem of an authenticator providing different identities to the peer and the server is the typical channel binding problem and can be detected by simply doing a protected exchange of the identity between the peer and server. When such a discrepancy is detected, then, keys won't be handed out or if the identity is part of the key derivation, then, it will result in a key mismatch anyway. Hence, there is no problem there. No, there is a problem even if the identity is part of the key derivation. The reason is that this is a _symmetric_ key that is used by the client to gain network access. If it is possible for some entity to lie about its identity to obtain one of these keys, then that key can be used to impersonate the client to the authenticator whose identity was lied about and/or attack a connection the client makes to the authenticator whose identity was lied about. Any security properties you're trying to assign to this key have been thrown out the window. Dan. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
comments on draft-houseley-aaa-key-mgmt-07.txt
Hi, I understand this draft is in IESG evaluation and would like to register some comments. I apologize for the tardiness of this email. This draft is well-written and much needed but I feel it does not completely address the issue of using AAA for key distribution. Let me summarize the problematic scenario in mind, why I think the draft does not address this, and suggested additions to the draft to address my concern. PROBLEM It is desired to use AAA to distribute keys for network access and what is basically a 2 party model is applied to a 3 party protocol. A client authenticates through an authenticator to a AAA server. Upon successful completion of the 2 party authentication protocol between the client and AAA server a key derived from a shared secret is delivered to the authenticator. (Known channel binding issues here). Then, a new key hierarchy, built off another shared secret, is derived and keys from it are sent, using AAA, to other authenticators to faccilitate fast handoff. These keys typically have an identity of the authenticator mixed into the key derivation function. The explaination given by proponents of this type of scheme on why this is secure is that the authenticators all have a security association with the AAA server, the distributed keying material is sent under the protection of that security association, and the AAA server is trusted. This, again, takes a 2 party model and attempts to apply it to what is essentially a 3 party problem. The concern is that the security associations are most likely based on some identity that is not known to the client and therefore is not bound into the key, for example an IP address. The authenticator's identity mixed into the key is a NAS Identifier and the security association it has with the AAA server is based on its IP address. This allows an authenticator to lie about its identity to the AAA server, through it's secure and trusted link to the AAA server, and obtain a key intended for another authenticator. Since this key is symmetric it can be used to impersonate the client to the entity to whom it should've been delivered. If a key distribution protocol cannot guarantee that a key will not be sent to the wrong entity then it is flawed. Also, the client is not involved in the distribution of this secret that it shares. It just notices that some new entity has the key and must just assume that possession of the key implies authorization to hold the key. WHY IS THIS NOT ADDRESSED IN THE DRAFT Two groups, IEEE 802.11 Task Group r and the HOKEY working group, are discussing using such a 2 party model in a 3 party key distribution scheme. They are coming up with schemes that suffer from the problem described above and justify them by saying that the authenticators share a security association with the server and that the key being distributed has the identity of the new authenticator mixed into it. People in both these groups advocating this type of flawed scheme are well aware of the Housley Criteria and this draft. In fact, they point to Authenticate all parties and Bind key to its context as specific requirements they meet. (In the case of HOKEY the problem is more compound as they wish to distribute keys from a home domain to visited domains and a server in verizon.net could request a key for the sprint.net domain). If this draft explicitly discussed this type of flawed scheme I presume these groups would not persist in advancing them, but persist they do. So I would like to see some explicit guidance in this draft to direct people away from them. Some guidance on how to ensure that this type of subtle flaw is not perpetuated in future systems would be most helpful. SUGGESTED ADDTIONS TO THE DRAFT In Limit Key Scope it says, parties MUST NOT have access to keying material that is not needed to perform their role. In the problem above the role of the entity lying about its identity is an authenticator and it is obtaining keying material necessary to perform the role of an authenticator, it's just that it has obtained a key for a different authenticator. I would like to see an additional requirement stating Key distribution protocols MUST ensure that keying material is not given to the wrong party. In Authenticate all parties it specifically mentions different identities being used in the AAA protocol. This is in the context of establishment of session keys and the only problem it notes with different identities is one of difficulty with authorization decisions. I suggest the following paragraph be added to Authenticate all parties: When a security association is used to distribute keying material the security association SHOULD be bound to a unique identity that can be commonly known by all the parties-- including the peer. If the security association cannot be based on such an identity then it MUST be statically configured to be an attribute of the security
