Archive for December, 2007

First Consortium Board Meeting

Sunday, December 16th, 2007 by hartmans

Last Tuesday, December 11, the MIT Kerberos Consortium had its first board meeting. Paul Armstrong gave detailed notes of the meeting. In a few cases, particularly dealing with parties not present at the meeting, Paul dropped some qualifiers and claimed that things were definitely true when I only stated that I suspected they were true. Such is life with raw notes.

The board did succeed in its goal of providing us priorities for our work. I think the board will work well together and will work well with the rest of the consortium staff.

I was expecting our priorities to focus mostly on technical projects. However the board surprised me; much of the work is on documentation, process and on promoting Kerberos. I actually think this is going to be good for the community and the technology but it was not quite what I expected going into the meeting. The board definitely seems to understand the value of standardization activity and working together with multiple vendors.

Some projects we’ll start now; some projects we will explore and report back to the board on in March.

Ietf 70 in Vancouver

Wednesday, December 12th, 2007 by hartmans

Last week, I attended IETF 70 in Vancouver. I had hoped to blog during the week, but the schedule was sufficiently intense that I did not find the time. However, I think that there are a few points that are worth summarizing.

At the TLS session, the topic of using EAP authentication in TLS was discussed. The IDEA is that EAP can be used within a TLS session for authentication either instead of or in addition to certificates. This would allow one-time passwords, SIM or other authentication methods to be used in TLS. In principle this could be very useful. There’s one significant problem: EAP has a fairly strict applicability statement which says that EAP should only be used for network access. There are a lot of reasons you might want this limitation. It’s useful to be able to distinguish EAP from GSS-API and SASL. When should one framework be used and when should another framework be used? Also, EAP is a three-party authentication protocol. The EAP peer authenticates to an EAP server typically by using a passthrough
such as an 802.11 access point. However, EAP does not typically verify the identity of the passthrough authenticator. If EAP is only used for network access, this is a manageable risk; Russ Housley argued at the IETF 70 HOKEY session that for service provider uses of EAP, this may not even be a problem. However as the applicability expands, the identity of the party actually taking advantage of the authentication becomes more critical. You don’t want to give someone access to your mail when you thought you were accessing some wireless network. I think that this effort has enough support it is more desirable to figure out how to do it right than to try and stop it. So, the big question is what is necessary to expand the EAP applicability safely.

There was a BOF on web authentication. There seems to be general interest in doing the work although the problem is difficult. I hope to get Nico, Leif and the folks from Mozilla together.

The SASL working group is focusing on a new password mechanism designed to provide authentication and channel binding. We ran into two challenges. The first is that channel binding data may sometimes require confidentiality. Our existing approach for channel binding in SASL does not guarantee that the channel binding provides confidentiality. It also turns out that it is more complex than I had hoped to provide channel binding in a mechanism that is both a GSS-API mechanism and a SASL mechanism. For a GSS-API mechanism you want channel bindings to be included as part of the authentication exchange. However SASL does not take advantage of this but instead uses a wrap token. Ideally you would not need both facilities. I’ll discuss this issue on the list, but I’m not sure there is a good way around this.

HOKEY focused on the role of AAA proxies and EAP. RFC 3962 describes how we want key management for network access to work. Ideally keys would be shared by at most three parties. However real-world networks tend to involve AAA proxies between providers that also know the keys. There is a significant debate ongoing about to what extent we need to provide a solution to work around this problem. There is no ongoing work to meet this requirement. The good news is that the difference in consensus seems to be a lot less than I had originally expected.

I will speak to the Kerberos activities at IETF in a later entry.