| Chair | Jeffrey Hutzelman | |
|---|---|---|
| Scribe | Leif Johansson |
slides 5-10 of the first presentation in the proceedings
There was a summary of ongoing work, related work outside the WG, and proposed new work items.
second presentation in the proceedings
Tom Yu gave a presentation on the goals and open issues for the kerberos-extensions document (aka RFC1510ter).
Tom Yu: One possible problem is user-to-user authentication. As part of user-to-user authentication, the client obtains a ticket-granting ticket from an application service. How is the client to know whether the service supports new messages or only RFC1510?
Sam Hartman: The interesting question is, how is the application service to know what the client supports, in order to give the client the right ticket?
Tom Yu: Yes. The problem is that the protocol doesn't specify a way for a user-to-user client to request a TGT from an application service. So, the application protocol needs to become aware of this. This is unfortunate, because it conflicts with our goal that applications not see any change in behavior. But since we don't have anything in the Kerberos protocol for how a user-to-user client requests the TGT of the application service, I don't know a better way to solve it.
Larry Zhu: Are you aware that there was an internet-draft for user-to-user that defines a message to allow a client to request a TGT from an application server? It is currently implemented in all flavors of Windows; it was added by Mike Swift and John Brezak.
Tom Yu: Was that ever published?
Larry Zhu: It was published as an internet-draft.
Sam Hartman: One of these years, this working group should deal with standardizing a user-to-user mechanism, because it's kind of embarrassing that we don't have one. But that draft only dealt with the problem for GSS.
Tom Yu: I think every time we've tried to do a Kerberos user-to-user mechanism in GSS-API, there have been security issues raised in terms of which principals you're going to authenticate against. I'd have to dig through really old discussions to review the issues.
The problem is that when 1510 was specified, there was no provision for a user-to-user client to communicate with a u2u app service to obtain the app service's TGT. so people writing app protocols had to construct their own messages. So, we can't revise the protocol transparently to deal with capability negotiation there.
Martin Rex (via jabber): Microsoft Kerberos SSP can use U2U authentication (by requesting the SESSION_KEY SSPI attribute). With Windows 2003 at Domain functional level "Windows 2003" the U2U authentication is acutally enforced by Microsoft Kerberos SSP for non-service targets and for service-targets that never had an explicit service-principal name assigned
Larry Zhu: That's what I pointed out earlier; we do have a GSS-API user-to-user mechanism and we have an internet-draft for that.
Sam Hartman: We've never standardized one; we should do that.
Larry Zhu: Maybe we should put that in the charter.
Tom Yu: The DC uses authorization information in the DC to determine what principals can be used for user-to-user services?
Larry Zhu: Yes; if you have an SPN, we assume you have a strong password. If you have weak keys, like users, we don't issue a service ticket to that user, so we invoke user-to-user instead.
Tom Yu: RFC1510 has ASN.1 GeneralString, which allowed more things than expected, with not the encoding people expected. So people put all sorts of things in there. We have no way to identify what goes in there. We need to figure out who's responsible for what mappings from legacy strings to UTF-8.
An interesting question is whether we care about legacy characters which we cannot map to Unicode. It would be much easier for us if we decide we don't care.
Jeffrey Altman: If you are an org that has lots of DOS systems out there and you're using OEM code pages, you might have line-drawing characters in your password. Do we care about being able to represent those, since there are no corresponding character codes in Unicode. Even if we care, there's not much we can do about it, other than those organizations that care assigning private-use characaters.
Sam Hartman: I thought we closed the character reportoire issues a while ago. The chair agrees.
Tom Yu: This is a problem for preauth, because you need a way to signal which encoding is in use. non-preauth is easy, because the client just tries everything it knows. It's slow, but workable. Unfortunately, we have nothing in ETYPE-INFO2 that helps with this.
Sam Hartman: Let's make sure we're not trying to create interop we don't care about.
Tom Yu: OK. You're a user who, using an old client, set a password with legacy characters. Now you're using a new client. And the KDC doesn't necessarily know which mapping to use.
Sam Hartman: If it's a preexisting key, the KDC just doesn't know. So the interoperability we want is that we never want someone to have to try to be an old client in order to get their password to work. So if this is encrypted-timestamp, the client has to choose a password encoding. Oh.
The client has a password that was typed in, and has to choose which mapping to use.
Jeffrey Altman: I think we addressed this. Organizations that have old clients with legacy passwords could configure the default legacy locale.
Tom Yu: But the KDC only has a key, not a password.
Nicolas Williams (via jabber): Force users with such passwords to change them.
Sam Hartman: I dislike that approach because it encourages people to use old clients.
Tom Yu: Making it harder for people to migrate to extensions is not something we want to do.
Jeffrey Altman: The question is what charset was used when the key was stored. The KDC doesn't know. It can guess; the guess is configurable by an administrator.
Sam Hartman: The KDC needs to communicate the guess to the client?
Tom Yu: I believe that needs to happen.
Sam Hartman: I'd love to find a solution that doesn't have that problem.
Tom Yu: Me too, but I don't think such a solution exists.
Jeffrey Altman: Users have the problem now; if they have a password where one system encodes in UTF-8 and the other in ISO Latin-2, the keys don't match.
Sam Hartman: The KDC doesn't need to know the charset; the KDC needs to know old vs new. And that's all it should tell you. The interoperability requirement is that old clients that used to work continue to do so. All I need to know is which charset to apply; a bit that tells me old or new.
Tom Yu: A new preauth hint.
Sam Hartman: You could do a flag, or an extension, or data that gets sent along with pa-enc-timestamp in the response.
Tom Yu: The client does optimistic timestamp.
Sam Hartman: Those clients are screwed.
Tom Yu: Does any implementation do that?
Sam Hartman: Ours.
Tom Yu: Does anyone deploy it?
Sam Hartman: Yes. In the preauth-failed error, you return information on old vs new.
Tom Yu: You think we should revise the specs for the preauth mechanisms?
Sam Hartman: It sould be preauth-mechanism-independent and somehow integrated into the preauth framework. So, I guess my question is, can we get comments on the proposal that in the case where the KDC wants the client to use the key first, it will communicate to the client information on old vs new. Do people believe that's a reasonable solution to this issue?
Tom Yu: Do we have a hole in ETYPE-INFO2 for this?
Nicolas Williams (via jabber):
ETYPE-INFO2 doesnʼt have a typed hole
no extensibility marker
ETYPE-INFO2-ENTRY ::= SEQUENCE { etype [0] Int32, salt [1]
KerberosString OPTIONAL, s2kparams [2] OCTET STRING OPTIONAL }
Tom Yu: I guess we have an ETYPE-INFO3 then.
Sam Hartman: I don't object to ETYPE-INFO3, but I don't understand why extensions can't extend ETYPE-INFO2.
Jeffrey Hutzelman: It's not extensible.
Tom Yu: We might be able to, but I'm not sure it comes late enough that our capability negotiation will work for it.
Sam Hartman: You only see it in an new AS-REP or ERROR.
Jeffrey Hutzelman: I think making PA-DATA mean something different depending on whether it appears in a new vs old message is fragile and sets a poor precedent.
Sam Hartman: We already decided that aspects of PKINIT string handling would have to be different. We expected that we'd have to update the PKINIT spec for extensions, but not define new structures.
Jeffrey Hutzelman: What strings in PKINIT are not controlled by another source?
Sam Hartman: Some of the principal names and things are copied in the PKINIT messages. I'd agree that having the structure of a PA type change would be bad.
Jeffrey Hutzelman: I think even having the semantics change seems fragile.
Tom Yu: The is essentially a rehash of the argument over why defined new tag numbers and new PDU's for lots of things. If you want to open that box again.
Jeffrey Hutzelman: No; the cases we've decided, are decided.
Nicolas Williams (via jabber): one bit: presence absence of a trivial PA-DATA
Jeffrey Hutzelman: We've dealt with this before, in the form of PA-AFS3-SALT. It's not clear to me you can't just try more than one. Oh, but with preauth, it's a problem.
Sam Hartman: I think the details of how to send this bit can be worked out on the mailing list; meeting time is better spend on other issues.
Tom Yu: Is there ever a reason for an extensions-capable implementation to want to communicate a legacy non-ASCII string?
Sam Hartman: I think this has been discussed in the past; we've all been assuming the answer is "no". If you ever need to send both, it really sucks. Fortunately, I think we've just dealt with the cases where you'd need to send both. Let's consider this a last call for people to look hard at this and figure out if there are places where you need to send both.
Tom Yu: The cases I can think of are things like a 1510 ticket inside an extensions KDC-REP, or an extensions EncTicketPart inside a 1510 ticket.
Nicolas Williams (via jabber):
transited field
it isnʼt true
it has issues
if you transit an RFC4120 realm
you canʼt then transit an extensions realm
with non-ASCII realm name
Sam Hartman: So, the TGS is just a service. I believe the behaviour is implementation-defined if the KDC is trying to issue a service whose name has non-ASCII characters to an old client, or if you have an old service whose name is like that. For example, if you happen to be a just-send-utf-8 implementation, does it just all work out? I think the answer is yes.
Tom Yu: If you're transiting a 4120 realm, the TGT necessarily has to be a 4120 ticket, right?
Nicolas Williams (via jabber):
weʼve discussed this before
the issue is that the transited field is an OCTET STRING
because it encodes the names of realms transited in a compressed scheme
Sam Hartman: Yeah, and in 4120 tickets, it will always be just-send-whatever, and you hope you agree on charsets, and in extensions tickets, it's UTF-8. My KDC needs to know what charset it's going to use when it generates a 4120 ticket. A valid policy is "error"; the MS policy will probably be "utf-8". The MIT policy will be crying a lot; effectively you'll need a config option. You'll have to get an error if you can't represent a realm name that comes in in a ticket that's going out. Or a dummy realm or something.
For domain realms, we could specify ACE encoding.
Tom Yu: I thought we had text saying not to do ACE encoding.
Sam Hartman: Yes, but for transited-realms in 4120 tickets, we can do that.
Tom Yu: So once you've started doing cross-realm using 4120, you cannot upgrade.
Sam Hartman: Why not?
Tom Yu: You can't then use an extensions ticket during that transit.
Jeffrey Hutzelman: The transited field is part of the EncTicketPart. So, an extensions KDC receiving a 4120 ticket for a foreign-realm user should be able to issue a ticket for a local service with an extensions EncTicketPart with an extensions transited-realms.
Sam Hartman: Can I use a 4120 ticket in a new TGS-REQ? If no, then you're wrong.
Jeffrey Hutzelman: It doesn't matter. What's going on here, whether or not you're going to update, you must give the client a 4120 ticket.
Sam Hartman: Can I send a new EncTicketPart in response to an old request?
Tom Yu: I think that's safe.
Jeffrey Hutzelman: The client shouldn't be allowed to affect that, just like the enctype it's encrypted in.
Sam Hartman: Can I use a new EncTicketPart in a 4120 ticket.
Tom Yu: We decided that was OK.
Sam Hartman: So the complicated case is you get a 1510 ticket and a 1510 EncTicketPart. I want to convert the transited-realm field to extensions, and a few hops earlier, there was an extended realm name. Do we want to specify how to encode an extended realm name in a 1510 ticket so you can get back later.
Sam Hartman: I have a 4120 universe between two extensions islands with funny realm names. When I go from 4120 back to extensions, do I want to recover the realm name?
Tom Yu: When you went from extensions to 4120, what happened to the funny realm name?
Sam Hartman: That's what we have to decide. For domain-style realm names, the obvious answer is ACE encoding. We could repoen the question of ACE-encoded realm names, but I don't want to open that worm of cans.
Nicolas Williams (via jabber):
yes, you do want to specify behaviour
what about services that want to make decisions based
on the transited path?
will they understand ACE encoding?
I do think that ACE encoding in transited field is fine in normalization
Sam Hartman: New services won't see the ace encoding. Well, the one service that has to know about it is the KDC. The point of specifying the behavior is that we can undo it when going from 4120 to extensions.
Tom Yu: This should be a lossless transformation
Sam Hartman: Not quite; if you have two realms whose names differ only in that one as ACE-encoded and one is not, they will be the same after this transformation. I think that's OK.
Tom Yu: Isn't that the problem that IDN has?
Jeffrey Hutzelman: Yes; IDN picks a prefix that they assume doesn't exist in real life, and uses that to indicate ACE encoding. We'd do the same thing, and have the same problem, which is if you have a domain that has that prefix, it would be indistinguishable from the domain whose name it represents as an encoding.
Sam Hartman: Note that it would be indistinguishable at a fundamental level in the DNS, too.
Jeffrey Hutzelman: And they decided that was OK for DNS, and given that, it's probably OK for Kerberos, too.
Tom Yu: How is this documented?
Sam Hartman: The behavior needs to be documented in how to produce a 4120 ticket. The spoofing issue needs to be documented in security considerations.
Sam Hartman: New issue for the tracker: what to do about transited-realm encoding when crossing a 4120 island. Answer: when entering an 4120 island, for transited-realm only, specify ACE encoding. When leaving a 4120 island, turn ACE into unicode. Leave representation of the realm name at the borders unspecified, like any other 4120 principal with non-ASCII characters.
POLL: Support for Sam's proposal:
Tom Yu: We had some discussions before, but never got anywhere.
Jeffrey Hutzelman: In has capacity as the person who operates the registries now, Tom should come up with a set of proposed policies and post them to the mailing list.
Shawn Emery: Integers or OID's ?
Tom Yu: That's closed [chair agrees]; it's a choice.
Shawn Emery: Are there guidelines?
Tom Yu: I get to write them.
third presentation in the proceedings
Sam Hartman: To give an incentive, I want you to agree on a charter before you submit your next agenda request.
Jeffrey Hutzelman How many people have read the charter email? [many] Good.
POLL: people who are currently editors of documents in this
working group:
Shawn Emery, Ken Raeburn, Tom Yu, Nicolas Williams, Larry Zhu,
Sam Hartman, Love Hörnquist-Åstrand
POLL: people who are currently noteditors of documents in this working group, but are willing to be editors of potential new documents (include people who have brought proposed work). 2-3, but chair thinks several more are not in the room.
Jeffrey Hutzelman I don't think there is much proposed work on the list that doesn't already have an editor.
Sam Hartman: Your editors are overloaded.
Jeffrey Hutzelman Yes, but all of the new stuff comes with new people. So we're getting away from the problem of all documents coming from Nico and Larry.
POLL: people who are willing to review documents: 12 or more
Jeffrey Hutzelman presented a proposal for an updated charter, then opened the floor to comments and things people would like to see added or removed. Little response.
Jeffrey Hutzelman One possibility is that I sit down with Russ and Sam, and produce something the three of us like, and then get the IESG to approve it. I'd rather have buy-in from the working group; it's more likely that the IESG will approve it.
Matt Crawford Can I assume passwordless initial authentication is subsumed under the preauth stuff?
Jeffrey Hutzelman Yes, probably. It would not make sense to me to pick up all of the proposals in the preauth space, because they overlap or make each other unnecessary. But we want to work on a subset that does what we want.
Matt Crawford The draft was old, from 5 years ago, but was recently revised.
Jeffrey Hutzelman No further discussion. Jeff will refine his proposal based on discussion and comments, sit down with Sam and Russ to put together a revised proposal, and continue on the mailing list. I'd like to have something for Sam and Russ to take to the IESG by sometime in January.
Larry had prepared presentations on PKU2U, Kerberos for Web Services, and the preauth framework, in case there was time. These presetnations were not given due to the shortage of time, but are included in the proceedings.