| Chair | Jeffrey Hutzelman | |
|---|---|---|
| Scribe | Michael Richardson |
slides 3-10 of the second presentation in the proceedings
Eric Rescorla: How much outside-of-lab deployment is there of this mechanism?
Andy Adamson: There is none.
Charlie Kaufman: It sounds like a lot of this is going to be done in the short run no matter what IETF does. What do you need from IETF? Why are you here?
Andy Adamson: We tried to implement SPKM-3, because it is mandatory in NFSv4, and found a lot of issues with interoperability. So, we looked at what it would take to turn RFC2847 into something that people could actually implement and interoperate. We looked at GSI, but it's not standards track, and SPKM seemed to be the only choice. We discussed this on NFSv4, produced a document which we think will work. We have an immediate need and will probably do some form of SPKM-3, but that doesn't have to be the way the IETF goes. That's what we're here to talk about.
Nicolas Williams: I thought "low infrastructure" in LIPKEY meant no PKI for users - they use usernames and passwords - but that there would still be full PKI for authenticating servers.
Andy Adamson: We're not stopping use of CRL's, etc. Some do, some don't; we just don't require it. We're targeting an existing deployment. Even though LIPKEY didn't talk about user certs, that doens't mean it can't be done.
Nicolas Williams: Sure, some places can have policy that makes CRL's, etc. unnecessary, but for a standards track mechanism, we need to have support for those. I understand you're using the phrase "low infrastructure" to describe Globus, but I don't think you're using it in the same way as RFC2847.
Sam Hartman: I think this is a rathole. RFC2847 uses "low-infrastructure" to mean users don't need certs, and they clearly support that. So, for all the possible definitions, they care. chair agrees; end this line of questioning
slides 15-24 of the second presentation in the proceedings
Sam Hartman (sponsoring AD): One of the reasons I asked the authors to propose this BOF is because in the individual submission process, we weren't able to come up with a complete list of issues. One successful outcome of this BOF would be to come up with a procedure (WG? group of volunteers?) such that we had high confidence that we could come up with a complete list of issues that need to be fixed in SPKM-3 before it can move forward. Another successful outcome would be to decide on how to get another approach to solving the stated problem.
Jeffrey Hutzelman (chair): Sam's point is important - we're not here today to walk through the issues, but to decide how to move forward in the IETF.
Stefan Santesson: In the list of signature algorithms, you included MD5 signatures; is there any reason to do that?
Olga Kornievskaia: No, we'd like not to have that; reviewing algorithms is one of the open issues.
Eric Rescorla: How much flexibility do you have to bring this spec up to modern standards, not just replacing algorithms, but the whole flavor of the protocol.
Olga Kornievskaia: The protocol is based on a standard X.509 3-way auth; it's not ancient or insecure; the protocol is not in question.
Sam Hartman: We have several options to maintain backward compatibility. GSS-API mechanisms are identified by OID's. NFS is implemented on top of RPCSEC-GSS, and clients and servers negotiate a set of mechanisms. So, we can create a new mechanism OID, which lets us change anything we want; however, if we do that, then the new mech cannot interop with the old. The other thing we can do is change algorithms within the mechanism without changing the OID, but we can only do that if we insure that old and new implementations of the mechanism will be able to interoperate (provided they have a common set of algorithms).
Basically, we have a wide variety of options, and we do have a way to change anything we want, and allow implementors to support both the old and new mechanisms. One of the open questions is whether we have a way to deploy that.
unknown: Hummingbird and Linux have no problem with an OID change.
Olga Kornievskaia: If there's anything you think is wrong with the protocol, we'd be happy to hear about it.
Eric Rescorla: You have heard about it; you have an extensive review from me.
Jeffrey Hutzelman (chair): If there are problems, and some people think there are, we can handle that if and when we move forward with this spec; we're not going to spend time in this meeting on it. I do suggest you find Eric after the meeting and talk to him about the issues he has found.
third presentation in the proceedings
Eric Rescorla: Is your draft somewhere we can read?
Larry Zhu: I will send it to the mailing list.
fourth presentation in the proceedings
Andy Adamson: There is no spec for this?
Nicolas Williams: Correct
Sam Hartman: On the mailing list, Martin Rex pointed out an alignment we'd have to do between TLS and the GSS-API. TLS allows a handshake at any point, while the GSS-API does not. We'd have to coordinate with the TLS working group to deal with that issue.
Nicolas Williams: The GSS-API doesn't support rekeying, and it's not just a matter of extending the API; the application protocols would also have to be extended. So, the answer to Martin's issue is if there's a pressing reason to do additional handshakes, then the GSS-API context must apply(?). If we can avoid additional handshakes, great. But note if there's any real pressing need to do this (for example, key lifetime exhausted), you have the problem with all GSS-API mechanisms, not just GSS-TLS.
Pasi Eronen: To me, this looks like the gss equiv of eap-tls; is that correct?
was there an answer?
fifth presentation in the proceedings
Eric Rescorla: I want to make sure I understand. You do an https fetch to establish a shared key, and then use that to bootstrap the mechanisms we already have?
Mike Eisler: yes
Eric Rescorla: The current mechanisms are already prepared to eat a shared symmetric key?
Mike Eisler: yes
Sam Hartman: I don't know of any gss mechs that are prepared to eat a shared symmteric key, unless it comes in the form of a kerberos ticket. You could have this https thing return something that happens to be an RFC4120 'Ticket', and then RFC4121 would consume that.
Charlie Kaufman: One of the things that makes security people cringe is that one of the target uses for this is to use a username and password. If someone were to do that, would they send it over the initial TLS connection, or would it be sent over the later RPC connection?
Mike Eisler: I'd establish a secured channel over TLS and get the shared key to SSiLKey. Once you do that, LIPKEY could do the username and password.
Sam Hartman: Point of information - LIPKEY is only specified over SPKM-3; to use it for this, you'd have to separate it out. That would probably be trivial.
Mike Eisler: Yes; you'd just have to establish an OID that binds LIPKEY to SSiLKey.
Olga Kornievskaia: What you're proposing is, first you're going to do a TLS connection, which requires at least two round trips, plus at least another one for password authentication. For filesystem access, I think this is going to kill performance.
Mike Eisler: People are using TLS today with passwords; they seem to be OK with it.
Mike Eisler: I'm very pragmatic; if SPKM is ready to go, I'm more than happy to go with it. But since we're entertaining alternatives, I thought I'd throw this in.
Michael Richardson: To follow up... Let's say it's five round trips. That's once per hour? Maybe once per day? I don't see the issue.
Olga Kornievskaia: Hopefully it's more often than once per day; TLS connections are typically only active for 10 minutes or so.
Chair: this is a rathole; end this line of questioning
Due to the shortage of time, the presentations and discussion on the naming issues were dropped, to allow time for discussion about how to move forward. The presentations remain in the proceedings; they are the sixth (final) presentation, and slides 30-36 of the second.
Andy Adamson: Given the current situation with SPKM-3 mandated by NFSv4, I'd like to see continued review of the SPKM draft, even if it doesn't turn out to be the solution, because we have this "in the meantime" problem. I'm open to a different solution on the standards track, but would appreciate help with closing issues on SPKM.
Charlie Kaufman: It seems like forming a working group without making a decision is an invitation for a working group that will rathole. There are small communities behind each of these; if we can't make the decision here, it doesn't seem like it'll happen there either. It almost seems like it would be worth forming multiple working groups to pursue different directions, if people were enthusiastic about that.
Sam Hartman: Do you believe we can make a decision here?
Charlie Kaufman: I don't know
Nicolas Williams: (via jabber)
***nico believes no WG is needed for any of the TLS-based solutions
nico: which doesnʼt mean that I think that a WG is needed for the
CITI/Hummingbird approach either
***nico doesnʼt believe a WG is needed at all
***nico seconds charlie
Jeffrey Hutzelman: if we proceed down multiple paths, it's not clear to me that it's impossible to do that in one working group. They'd share some parts of the solution, for example, naming. So a possible outcome is a working group chartered to work on more than one solution.
Sam Hartman: It's a possible outcome, but I'd like to understand why we're doing it. We normally try to only have one standards-track solution in a space; if we're going to have multiple solutions, I want to know why. There is no reason people can't develop the non-standards-track solutions and submit as independent submissions to the RFC-Edtior.
Eric Rescorla: I think it's a mistake to charter a working group with the assumption that you're going to select the protocol later. These protocols are all very different. Some would require a working group, and others wouldn't.
If we pick one, which one?
Notes of this part of the discussion were sketchy, and there was a short interruption in the audio stream, so some comments were lost.
Charlie Kaufman: The impression I've gotten is, SPKM sort of exists today, and needs some work and flaws fixed, and if that happened, the old one could be deprected. It seems like that work could go forward without a working group, though it would be better reviewed in one.
The others seem like they are new GSS-API mechanisms aimed at solving the same problem, and face a bigger hurdle with respect to whether the world needs new GSS-API mechanisms to solve this kind of problem.
Sam Hartman: We've had many years of experience with SPKM. Can we deprecate it even if we don't update it? Discussion in the kitten working group led to the claim that there are not interoperable SPKM mechanisms with respect to naming. At least in NFSv4, we don't currently have deployment of SPKM.
If you use something like TLS or Kerberos, then if you are able to deprecate SPKM, you reduce the total number of public key mechanisms in the world, the total number of things you have to update when there's a problem with an algorithm or whatever. On the other hand, if you need to keep SPKM around, it may be better to update it. There's a question of whether to reuse old GSS technology or to reuse technology more widely adopted in the IETF.
Charlie Kaufman: I agree; that's the dilemma we face.
Nicolas Williams: It's not clear that SPKM really exists as a deployed mechanism, so to me, it's like starting with a blank slate.
Andy Adamson: SPKM 1 and 2 are used by entrust. SPKM 3 has no production deployment, but it does exist. The changes we're talking about are minimal compared to starting over and writing a new mechanism. As for updating algorithms, we use existing crypto routines in the Linux kernel, OpenSSL, etc., so adding an algorithm is not a problem. Also, the naming problem exists everywhere.
Sam Hartman: An interesting question is how much effort would be involved in getting to standards track for each of these proposals?
Eric Rescorla: I agree that in general adding new algorithms to systems is not that hard. But it's not true that this will be as adjustable as TLS. For example, how will you add elliptic curve, or increase DH key sizes in a way that doesn't involve multiple round trips?
Nicolas Williams: (via jabber)
nico: !itʼs easier to have fewer core protocols
Mike Eisler: I think with Larry's proposal [PKUTU], the naming problem is solved, because Kerberos solves it.
Sam Hartman: The Kerberos WG has solved the naming problem for PKINIT if you're willing to generate Kerberos-specific certs; otherwise it's a matter of local policy
Nicolas Williams: (via jabber)
nico: !extending TLS to support better naming, channel bindings,
benefits non-GSS apps as well
Olga Kornievskaia: Kerberos does not solve the naming problem for the PKI approach. It solves its own naming problem.
Sam Hartman: I fully agree. Kerberos doesn't solve the naming problem. Even with larry's approach and pkinit SAN's, what to do about gss_export_name is still completely unspecified.
Andy Adamson: Once you update TLS, at least in my implementation, SPKM-3 is updated too
(?)Jeffrey Hutzelman: It's not good enough for the code/library/whatever to have an implementation of the new algorithm; you have to update your protocol to specify how and when to use it, and you have to do that for every protocol. If you have a protocol built on TLS, then when it's done for TLS, it's done; if not, then you have to do it separately.
Eric Rescorla: It's easy to add new algorithms when they fit in the same slot. When you want a new algorithm with even slightly different interfaces, it takes a major amount of surgery. For example, randomized hashes.
Nicolas Williams: (via jabber)
nico: !Olga: PKIX doesnʼt have just DN
Sam Hartman: No one has proposed ruling anything out. Andy has proposed that we go forward with SPKM-3.
Andy Adamson: Yes, I propose we use SPKM-3. I also understand there are issues that I don't necessarily understand. But I also know we have code that we're going to be using. It's like to get it tightened up, at least as an interim.
Nicolas Williams: (via jabber)
nico: then I propose going forward with the GSS-TLS proposal
Jeffrey Hutzelman (chair): I'd like to hear proposals to go forward with something or rule something out, other than the authors proposing their own.
Michael Richardson: I think he [Andy] articulated the problem. Did we agree that was a problem we should solve? [yes] Was that the complete set of requirements?
Jeffrey Hutzelman: Of course there are lots of requirements; whatever we do has to have strong algorithms, not cause catastrophic congestion, etc.
Michael Richardson: Some of those talk about username and password. It seems to me that if that is the criteria, then questions like whether the username and password has to be available in the clear on the server might reduce the number of choices.
Sam Hartman: I'm not aware of any process requirements that would rule out any of the solutions presented today.
Jeffrey Hutzelman: Did any of them not propose dealing with username/password with LIPKEY?
Sam Hartman: Yes, PKU2U.
Michael Richardson: It doesn't really sound to me like people are talking about the same question.
Jeffrey Hutzelman: I think they were. For example, in the discussion about MD5... The AD's haven't said this today, but I think it is nearly impossible that any proposal will be allowed to go forward if the strongest hash algorithm is MD5. The earlier discussion was about how each proposal affected how hard it would be to update algorithms.
Jeffrey Hutzelman (chair): We are short on time; if we're not going to decide how to move forward, we have to at least decide how to decide.
Mike Eisler: Speaking as a nfs implementor, the tls concerns me because of new code that has to be brought into the kernel.
Sam Hartman: Even with the variant with 4121 per-message tokens? Do we have consensus to drop the gss-tls variant with dtls records? [yes]
Eric Rescorla: The problem with DTLS is that it doesn't live in the kernel?
Sam Hartman: The issue is that doing per-message tokens with DTLS would require bringing code into the kernel that's not there now, and that would be an obstacle for NFSv4 deployment. But Nico has a version that uses RFC 4121 token formats, and is very similar to EAP-TLS, using TLS's PRF to key RFC 4121.
Nicolas Williams: (via jabber)
nico: !jhutz: would you like a second BoF, perhaps?
nico: !so, using RFC4121 for per-msg tokens can apply to ALL proposals
nico: !the SPKM-3 proposal, the SSiLKeY proposal, the GSS-TLS proposal
nico: !PKU2U oalready re-uses rfc4121
nico: !finally
nico: !my proposal isnʼt the GSS-DTLS proposal, itʼs the GSS-TLS
proposal, with a variant using DTLS
Sam Hartman: Would people be willing to set up a design team to choose a solution? Do people in this room believe that a design team would be useful enough for the default to be that if no one screams loudly enough at the result, that we have a consensus? It would be an AD-sponsored design team, consisting of some neutral parties and some involved with some of the proposals. Would that be a reasonable approach?
Eric Rescorla: Do people really think that will converge?
Sam Hartman: I'm not sure. For example, do the various proponents think they could work with each other?
Andy Adamson: Yes; we're open to other approaches. I want the problem solved.
POLL: Will forming a design team produce useful output?
Sam Hartman: If the design team produces output, would taking that as a starting point be a reasonable approach? That is, does the design team have a presumption of consensus, at least within this room?
Russ Housley: Similar things have been tried before. You should have the design team, and then another BOF. You won't be able to confirm you have consensus without a second BOF.
Sam Hartman: I don't want to commit to a second BOF unless I have to. If everyone is happy on the list and stuff moves forward, then maybe we don't need a second BOF. But I agree a second BOF would happen if needed.
POLL: If the design team produces output, would taking that as a starting point be a reasonable approach?
Volunteers to be on the design team:
Andy Adamson, Olga Kornievskaia, Michael Richardson,
Charlie Kaufman, Mike Eisler, Nicolas Williams, Larry Zhu
unknown: Larry, do you think Microsoft will implement PKU2U no matter what is decided here?
Larry Zhu: If the GSS-TLS mechanism can provide all of the functionality of PKU2U, then we could use that. We just need a GSS-API mechanism to be able to provide server auth using public keys.
unknown: How soon do you need that?
Larry Zhu: I can't comment on that.
unknown: Are you saying that the only proposals you'll accept are PKU2U and GSS-TLS?
Larry Zhu: Correct. I strongly object to creating a new set of core protocols.
(?)Jeffrey Hutzelman: Do you have an existing SPKM?
Larry Zhu: Not that I'm aware of
Sam Hartman: So, you're strongly objecting to SPKM?
Larry Zhu: Yes
Jeffrey Hutzelman (chair): We are out of time.
Sam Hartman: Anyone objecting to the design team approach, or has a better approach to moving forward, please speak up. [no response]
Polls indicated there was sufficient interest in this work and enough people willing to work on it; however, it was not clear whether formation of a working group was actually necessary to proceed.
The sense of the room seemed to be that leaving the choice of solution up to the proposed WG would be counter-productive, and that any WG formed should be constrained to a particular solution. This led to a discussion about the relative merits of the solutions proposed. The conclusion was that selection of a particlar proposal was not possible in the short time remaining in the BOF session.
As a next step, Sam will form an AD-sponsored design team to evaluate the proposals and select one. This group will include one of the authors of of each of the four proposals, and possibly a small number of others. A poll of the room indicated that the output of such a design team would likely be acceptable to the group.