IETF 85 - kitten Working Group Minutes ====================================== Location: Atlanta, GA – (Hilton Atlanta) Room: 209 Time: Tuesday, 6 November 2012, 09:00 - 11:30 Local Time Co-Chairs: Sam Hartman Shawn Emery Josh Howlett Secretary: Simon Josefsson Security Area Director: Stephen Farrell Scribes: Ben Kaduk Tom Yu Simon Josefsson Jabber Log: http://www.ietf.org/jabber/logs/kitten/2012-11-06.html Audio Recording: http://www.ietf.org/audio/ietf85/ietf85-209-20121106-0900-am1.mp3 MeetEcho Recording: http://ietf85.conf.meetecho.com/index.php/Recorded_Sessions Action Items ============ Chairs: Send updated work items and charter text to the WG list for consensus review/consensus. Leif: Review 07 of the gssapi-extensions-iana draft. Leif: Get with Resnik to resolve DISCUSS issue with kdc-model draft. Tom Yu: Post CAMMAC KDC mac - service ticket issue to the list. Chairs (Josh): PROTO write-up for the pkinit-alg Hannes: Update the draft with example token types and fixes to the IMAP/SMTP examples. Conference Session ================== The kitten and Kerberos WG shared the same session with the anticipation that that the Kerberos WG will be folded into the kitten WG in the near future. Active Working Group Items draft-ietf-kitten-gssapi-extensions-iana ---------------------------------------- Per programming language registry update in 07 made by Alexey. Looking for reviewers. Leif has volunteered. Alexey thinks the draft is fairly stable. draft-ietf-kitten-gssapi-naming-exts ------------------------------------ Now RFC 6680! draft-ietf-kitten-sasl-openid ----------------------------- Now RFC 6616! draft-ietf-kitten-sasl-saml --------------------------- Now RFC 6595! draft-ietf-kitten-sasl-saml-ec ------------------------------ Scott Cantor gave a presentation on updates to the SASL SAML-EC draft and brought up issues with expert review, naming and keying issues. Scott Cantor: 04 uploaded, needing review and implementation. The OASIS drafts which this is based on, are stable and ready for standardization. NCSA has prototype using SSH. Ran into an issue we thought needed to be patched in SSH code, already covered by moonshot, but tried to make things work by requiring session keying. Cantor: Naming Lots of federated mechanisms. None of the names are guaranteed to have anything to do with each other. Can be tricky to map out what needs to be known. Try to avoid specifying new name types specific to this mech avoid use of XML in the actual initiator/acceptor names need to express token name to acceptor, so pickle the nameid element data into a string (GSS_C_NT_USER_NAME?) separate fields with a bang and glom them together. Rest of naming refers to naming extenstions and eap draft, need to update references. Cantor: Session keys Define some XML local to the draft to store local internal information allows carrying session key information to both sides by the IdP intention is to have IdP generate a key and send to both parties. Cantor: IdP generated key Reuse 3961 enctypes. Draft right now generates protocol key and passes as base64 inside assertion and that can be encrypted; soap header back to the client EAP draft has a lot of extra machinery to get protocol key in 4121 sense; do we really need all that much complexity? <\Presentation> Hartman: Wants Jim, Sam or a kerberos folk to review. Hannes can review. "Find someone who understands 3961 pretty well". Shawn Emery: Guidance would be to not overspecify this -- some applications like ssh have mappings for naming. Cantor: Clarifies up to application for how to map from federated name information to local name. Needs to get standardized somewhere, somehow. Hartman: Do you have a standard way of mapping from service to standard name? Cantor: Yes. Hartman: GSS-EAP side has not standardized any user maping at all (in the spec) Hartman/Cantor: Could go there. Cantor: Can't tell apps to do something the spec doesn't tell them how to do Hartman: How much of that is a platrform thing? Cantor: Willing to do some work in the ietf on it. Some needs to be pluggable in the applications. Nothing cantor did is intended to subvert/preclude such mechanisms. No assumptions built-in, is all. One common issue: can you assume the name you type in is the name you give to your IdP at auth time (no). Paul Leach: It's fine to say that mapping to local identity is local, but if the input is not specified it makes mapping it tricky. Cantor: The input is specified, but in federated case that will be very deployment specific Hartman: Paul, an application you're familiar with is to use the pac and get a local mapping. There's a history of extra inputs. Cantor: not a history of multiple applications actually doing so. Not unique to this draft. Emery: May come up in recharter discussions. draft-ietf-kitten-sasl-oauth ---------------------------- WGLC expired on 10/7/12. Issues were brought up on the list: Some comments on list about target name and entity id, require updates Alexey has imap/smtp examples comments. Hannes: I've read through Alexey's comments; they are good and will get these incorporated. Alexey provided some review comments after WGLC; some language/terminology left to sort out. One issue still to raise is registration of different tokens. Three tokens/features specified in document, but maybe not very clearly. There are two oauth types supported in document, with some differences between them. Also channel binding characteristics; IANA considerations section (7.1) registers three SASL profiles, oauth-bearer, oath 1.08, oauth 1.08+ (channel binding). Results from on-list discussions. The document is fuzzy on what those exactly mean. "authorization using bearer tokens" is that from oauth token itself, which matters for client/server implementation. oauth 1.08 tokens -- one is based on shared secret/mac signature, and also rsa tokens are possible. But, the RSA mechanism has not been completely specified and is not fully usable. More clarification needed? Emery: Status of RSA draft for OAuth? Hannes: Only bearer token is published; we're working on additional security stuff, but can't say what it will look like. There's nothing to reference at this time for OAuth 2.0. For 1.0, don't think it's deployed (RSA). Justin Richer: The status is that there are deployments of 1.0 rsa but they are very limited and insular. There are some cases in enterprise world, but when people think 1.0, thinking of hmac-sig tokens. There exist plaintext sig/bearer token, but no one uses that either. "oauth 1.0 means hmac-sig". When people hear "bearer", people think 2.0. In the SASL doc, would make sense to point out explicitly "token as defined in "X" for clarity. Most people will assume right thing, though. Hannes: That's what I was suggesting. I don't think we can write useful things about RSA with 1.0. Richer: We can, but no one will care. Hannes: How to get keys? Hartman: I agree with Justin's comment, and should do it based on specific sections of the document. An issue to be aware of, in gs2 mech bridge, go from library to do generic sasl implementation either directly on top of SASL stuff or on top of gssapi, ask enough questions to figure out if it has channel bindings. Need to know by querying static attributes whether can pass channel-binding into gss_init_sec_context, and there will be confusion or insecurity if a mech claims to support CB and then doesn't check them (sometimes). So, I strongly recommend that you define mech such that you can tell whether it supports CB (separate profile), and such that generic GS2 bridge can work with mech based on mech attribues we've defined. Hannes: Agrees to update the draft with example token types and fixes to the IMAP/SMTP examples. draft-ietf-krb-wg-kdc-model --------------------------- DISCUSS brought up by Pete Resnik. Leif and Peter are trying to coordinate; the list has been informed. We need a proposal before can do anything. Stephen Farrell: who is going to write text? Leif: don't know answer. Peter did not like use of 4121 language (he called it "insane" ); the working group has covered extensively Farrell: they will sort it out, probably. It's possible they will need editorial help. Hartman: Volunteers? Need experience with conformance levels in some formal context, either 2119 or the equivalent in some other organization. Farrell: People are being poked. What could happen, and would be on list, is if requires lot of work, and none to do work. Leif: I'm not going to throw up hands in disgust and give up. Emery: Pending hallway discussion draft-ietf-krb-wg-pkinit-alg-agility ------------------------------------ Needs to be sent to IESG (passed WGLC) and Josh will shepherd. Tom had found an IANA conflict, which was discussed during the Kerberos IANA status. draft-ietf-krb-wg-kerberos-referrals ------------------------------------ Approved; in RFC editor queue. draft-sakane-dhc-dhcpv6-kdc-option ---------------------------------- In AUTH48. draft-ietf-krb-wg-camellia-cts ------------------------------ Approved; in RFC editor queue. Kerberos IANA ------------- Tom Yu had brought up a conflict with error code 82 and proposals to resolve this: update the pkinit-alg draft, erratum for 6111, or overload the error code. In regards to the registry draft there were questions on whether to document message types, tags, and ASN.1. Will take the questions to the list Tom Yu: It seems that two different drafts that had some of the same people involved produced a confilict for code 82. pkinit algorithm agility has it already in use in MIT, possibly also in heimdal/windows. An other use is in RFC 6911. Our implementation does not seem to use that code in that fashion Ben Kaduk: Did you see Simo's mail Yu: I did, but it did not have enough info to say much. Emery: Sam proposed that we special-case the conflict? You seem to think that might not be viable in all cases, so maybe we should have that discussion. Yu: part of issue is that well-known-names RFC says that that error can be used in a whole number of different places where the recipient doesn't recognize the name. Conceivably that could happen in anon pkinit, or in some other name situation while using pkinit. We should figure out if we care. Emery: Sam, want to counter? Hartman: I don't feel very strongly. Emery: Do we need a consensus call? Hartman: Let's see if there's discussion, then make a hum. Yu: One possibility is to reassign the alg agility code. Means changing implemetations... Jim Shaad: libraries or clients? Yu: Libraries. Emery: Consensus calls? Yu: Our options are to overload and have it be ambiguous, reassign the not-yet-published code, or publish an erratum to 6111 and change implementation code. I Haven't done a thorough study of how big a change that would be. Emery: Show of hands. Hartmans: Not an erratum! I disagree with changing protocol constants there. No objection to doing it as a new RFC. Yu: Can other implementors in room comment on how difficult it is to change pkinit alg agility ipmlementations? [no] Paul Leach: Clarification question; how widely are implementations deployed? Yu: MIT's release 1.9 came out in 2010. It is worth noting that it is unlikely for this error code to be transmitted until we decide to adopt a hash algo for pkinit that isn't sha256. Hartman: But then you will get it from old kdcs with new clients? won't you have to [upgrade kdcs] Yu: We all know old code never dies... Hartman: clients are going to be stuck seeing this error, no matter what we do here. On the other hand, both errors are, "you tried to do something I don't support; go away". If we're trying to fallback, we might fallback on wrong axis, which could actualy be a significant issue. Probably just have to try falling back on no axes no matter what, since the code is already out there. Yu: Has anyone shipped code that uses the unknown well-known name error code? [crickets] [jabber channeling ghudson] Greg Hudson reports over jabber that if the update to change the number is released as a patch release, it might not be unreasonable to assume that the old code will be upgraded by the time the error starts getting produced. Yu: It's time to talk about the issues Greg [not Tom Petch??] brought up Hartman: Document message types. Tom: ASN.1 Hartman: Tags Yu: Does that change mind about options? [crickets] Yu: About message types and/or application tag numbers, do people think that's a useful thing to include in the iana registry? Will they be updated sufficiently rarely that we can not bother registering? A similar question applies to transit encodings. Farrell: There are some ASN.1 structures. Are they in a module somewhere? If we create a registry will we have those numbers in two places? Hartman: We do have asn1 modules. Yu: The oids in question are mostly for the whole module, not specific elements. Hartman: I believe that if we were to register a new tag, we would expect a complete update of krb5 module. If we say don't document the numbers in iana, our response should be that when we change this, we will do complete rerelease of affected module, so there will always be a single place to go to to look for registered modules Jim Shaad: For asn1 modules I'm less worried, but my gut feeling is that I'd rather see registered with iana than not; it's an easy central location to find. Hartman: If it ever gets inconsistent... Yu: A philosophical question is whether iana is supposed to be a one-stop-shop to get everything you need in a protocol, or if it exists to avoid conflicts. Hartman: This issue doesn't matter much, I think. Does anyone feel strongly? I think it's reasonable to say tom [petch] does, actually no. He did not like our answer, but that could mean we did a bad job explaining. Farrell: Maybe also talk to IANA? Harmtan: Show of hands [for including these in the iana registry]? Chairs declare apathy. unless consensus appears to do something in particular on-list, we'll instruct the editor to do something reasonable. Yu: Where "something reasaonble" might include "toss a coin." Hartman: Or not register and explain why (update whole module). "this room does not care about this issue" Lucy Lynch: A clarifying question. If we say we will always update module, will that be done in bounded time? Harmtan: It would require standards action to do anything vaguely near this space; we could change our policy, but at that time, we could change the spec to add a registry. We expect to never do this. Emery: Any more comments on IANA? Hartman: It needs review, especially of the registration procedures Tom has in there. I will do that ... sometime. Emery: Volunteers? Hartman: Chairs will twist arms. Emery: Some IANA folks are not here. Suite B Profile for Kerberos 5 ------------------------------ Kelly Burgin had presented Suite B profile use for Kerberos 5. He is looking for feed-back on his draft and direction on whether to adopt the draft as a WG item. Kelley Burgin: These slides are from a talk prepared for last week that didn't happen due to weather; some stuff in here is not necessary for today. We want a suite b profile because the government is going to commercial products and needs standards for how vendors can build equipment for the government to use. The standard "government solution is a 4/5 year route, which is too long; we need to buy things off-the-shelf to get current technologies. Suite b provides layers for us to meet the specs. [existing stuff] needed to write down new enctype Notes: no mode specified, no sha1 (sha2 everywhere), CRL checking required. People don't like CRL checking, as it's a lot of work. There's a preference for gcm when makes sense, but for us there's no guarantee of new key being present when needed for rollover; after a big discussion we decided to go with cbc. Originally that was with pkcs5 padding? But it might not work with implementations; go to cbc with ciphertext stealing as other enctypes to use.. \slide overview what suite b means for kerberos require pkinit -- no password-based keys \slide refs specifics of enctype draft that are different than the two we've looked at (3962, camellia) are that the KDF is updated to use sha2; we mac ciphertext and not plaintext, and use explicit IV (not implicit) for same reasons as TLS did so. Hartman: What are you asking us to do? Take on 1 or more drafts as work item? Burgin: No, don't need to make WG item; fine to be as usual suite B rfcs as informational Hartman: Even new enctype as informational? Burgin: Yes. Hartman: Don't need adoption, just review. Burgin: Yes. Emery: volunteers? Burgin: I got a few comments on the enctype draft; the suite b draft has been out for a couple years with no comments. Hartman: To be honest, you're probably not going to get lots of comments. You would have gotten people running to the mic now if you'd done something strange in that draft. You did not intend to do something innovative in a suite b profile; just trying to reuse stuff that people have confidence in. Burgin: It would be great to get "yeah, you reused a bunch of existing techs" Emery: please state on list if you've reviewed and have no comments. Provide comments whether negative or positive. Hartman: You should probably also send mail to Ken Raeburn (sort of the enctype registry master) and let him know that you're trying to get an enctype draft published; review soon would be great. There will come a time when you need his review and it might as well be soon. Yu: Why sha-384 truncated to 192 rather than sha-256 truncated? Burgin: There might have been a reason for that. Yu: Or is it that the reviewers who look at the nist requirements will look at sha-384 and think 192 bits regardless of underlying level of security. Burgin: Right, we want 192 bits Yu: That's not necessary for hmac. Burgin: Possibly. We want the overall security stated as 192, without bound. Even if could get away with something less, we would like to say there's a system-wide level of security of 192 bits. Yu: That's fine; I would suggest to make a note about this in future revision. I also assume you're not concerned about cipherblock collisions? Burgin: No. Emery: Other comments? Charter Discussion ------------------ New work items were discussed for the merged WGs. Interest was gauged for each of these potential work items, while polling for individuals that would be major contributors and reviewers of subsequent drafts. Emery: Looking for new work items as well as existing items. Hartman: One thing, a high-level question, are we trying to finish existing work and shut down, or are we trying to go forward and do some new stuff? We have a chair team for the WG that's excited to put in more energy than we have seen in either WG in the past year, and move things forward. That only works if we have lots of reviewers and editors to pull work foward. There are some existing items that need to get done, but the question is are we going to do more than that, or spin down. Question is: How excited are you about sitting here each IETF and getting stuff done. We'll go through stuff and find out about that, seeing potential for work done on a list of items. Emery: Existing items: sasl-oauth sasl-saml-ec gssapi-extensions-iana kdc-model pkinit-alg-agility kerberos-referrals sakane-dhc-dhcpv6-kdc-option camellia-cts kerberos-iana-registries Hartman: Question for Stephen Farrell. Does the new charter need to include items in the RFC editor queue but not yet published? Farrell: You can distinguish between charter body text and milestones, put it in milestones and that's fine. Hartman: Even ones already approved by stephen? Farrell: No. Emery: New work items. GSS-API related, from Tom Yu's wishlist draft. Farrell: What I would love to see is work items where it's really going to happen. Hartman: That's what we're going to try to figure out. Something that's been floating around for a while. Asking now, who's going to come forward and do one of these. Farrell: This is a slightly different style than Kerberos, and maybe kitten had in their charter before; we had some items that we will do, some that we might do. I hope that the new charter will be a list of ones that we will actually do. Emery: Take a poll for each of these, interest in authors/reviewers; engage interest during the session. Try to gague which items would generate most energy. New interfaces for cred management: good idea: six Hartman: Who thinks is bad idea?: [none] Emery: Willing to review: five Hartman: My understanding is that we know people are implementing it; I'm skeptical whether people wiling to edit document and write it up. I know it will be implemented and used, but don't know that we have the energy to standardize it. Emery: Who will edit/major contribute: Simon Josefsson plus Jim Shaad. Hartman: simo+mit already have some proposals for parts of this that are pretty cool and have received review in their dev community. Emery: going through, we'll ask who has general interest, would review, would be a major contributor. Negotiable replay cache avoidance: Good idea: one hand Bad idea (to work on): one contribute as editor: 1/2 reviewers: none Hartman: This one isn't making the list from just the room... Emery: We will take it to the list. Is Nico around? Hartman: This one isn't sounding very good. That could change on-list Define interfaces for better error message reporting: good idea: four bad idea: one Hartman: My concern is that I would like more specific proposal; it could turn into boiling the ocean a little bit. major contributor: two reviewers: one Option for exporting partially-established contexts, &c.: good idea: three Leif: Wasn't this motivated by attempts to do gss for negotiate, handshake? Hartman: It's still needed for gss-rest, etc. Leif: still a use case? Hartman: It's effectively dead in the ietf, but the moonshot code does roundtrip negotiations not quite using your protocol. We couldn't get what it does standardized in the IETF. Emery: bad idea: none contribute in major way: one reviewers: none Farrell: There is an issue that a lot of the major contributors who have been raising their hand so far are the same people. Are we taking notes on individuals? There's a question of capacity, what's the milestone distance to actually do all of these? Hartman: We need to decide priorities amongst the things with same reviewers. Emery: Kerberos-related things. Prepare, review, and advance updates/extensions to RFC 4121 Hartman: does anyone think this needs ongoing unnamed maintenance, or do we need specific charter items? I would be happy if we dropped this, if we have text in the body of the charter saying "bring that work here, but update the charter when you do so." I'm not aware of specific work not already enumerated here. Farrell: Makes sense. Emery: Premature? Hartman: Body text but not action items. Farrell: A question on the charter text -- do we say that this is where krb/gss work should be done, no one else, or...? Hartman: It's spotty; we don't want to require all gssapi mechs to come here. we do want to own 4121 and that will kind of need to come to the list for consensus, but that will be patchwork. GSS-API is designed to have less-coordinated extensibility. Farrell: E.g., TLS wants more ownership of some bits, less of others. Hartman: We need to decide that. This item is saying 'we want to own 4121'. Emery: Move that up in the charter and submit to the list. Standards-track spec for krb5 non-ascii names: Hartman: Only one specific proposal in this area in last four years. Text is in krb-wg current charger. Made call for adoption, and we received inadequate support to adopt a draft that we discussed during the last round of chartering, was already written, and fulfilled part of this goal. If this text is to remain in the charter, why do we think we'll do better this time? Emery: good idea: 1.5->2 bad idea: none contribute in major way: none reviewers: one Hartman: Starting to sound a lot like 'no'. Stephen, you get to explain to ADs. We will put to the list, but this is kind of the result I expected Emery: Standards-track update krb5 to extend unencrypted portion of ticket: Hartman: have draft for; editor got busy; fairly easy to do if people will put in the effort. Don't know of anyone said urgently need to implement. One of the pk-cross solutions depends on this. Lots of times I've found a use for it, but over the last ten years they haven't been important enough to go and fund it. There's a draft for kerberos that was blocked by this, but never got to the top of a priority list. Fairly low-effort, we know why we want it, ... Emery: good idea: one bad idea: none contribute in "major" way: one reviewers: one Hartman: I think we would need a little more support to do this, but we'll take to the list. Emery: Might be a good one to start off with if you're new to the WG. Hartman: Would be a good way to get involved. Emery: Standards-track+informational spec for new authz data types (like krbwg-general-pac): Hartman: Do we want to have an ongoing task to standardize authz data that needs standardizing. My thinking is 'yes'. hands in favor: five against: none Hartman: In terms of specific proposals, we would need to get enough support to add it to a milestone, stephen's approval and people to do work, but. Question of CAMMAC. I understand there was a recent update, but there's really been inadequate progress over last year to move forward. Revisiting CAMMAC as a charter item, will we push to completion? Does it not have necessary energy? Interesed in cammac: good idea: four bad idea: none sig contribute: three reviewers: one Hartman: Need to rope in more reviewers, but would be good to see this move forward. Emery: Standards protocol for hotz-kx509 including digital signatures: Hartman: We have had this document around for some time; we've gotten notes that "we're delayed but still interested". Jim Shaad: What is this work? Hartman: Have ticket, want cert. Can be enrollment or short-lived certs. good idea: 4.5 bad idea: none contribute major: none reviewers: 4 Emery: New crypto for kerberos using 3961 framework: Hartman: Do we want to own crypto work in IETF? Do we want to support non-standards track crypto work in the IETF going through us? Do we want to own IETF-stream krb crypto?: in favor: six against: none Have a way to do informational algorithmss (or send to independent stream) in favor (of doing info): Farrell: the process that krb was using for that is maybe something that needs explaining. The distinction between standards and informational was particular to krb-wg, was it not? Hartman: Yeah, sorry. Krb has enctypes, and if the WG has consensus to do it, we can do an informational registry; the IANA registry requires either standards action or expert review, effectively. There are fairly strict criteria for what it means to be a standards-track enctype, but we are also allowed to do informational RFCs. For example, Camellia. Do we want to spend our time on that; we could easily send things through the intependent-submission stream, or Stephen could sponsor them. There's a question of do we want that sort of stuff coming through here. Might not want to, as it's frustrating to figure out which algorithms we do want and which we don't; lots of algorithms want RFCs everywhere and it can take up lots of the group time. On the other hand, people can decide that it's valuable. Support informational crypto in charter?: in favor: six against: none Kaduk: We can support this in the charter but still tell people to go away. Hartman: But have to have the talk to tell them to go away. Farrell: Essentially you're inviting them in. Hartman: Hasn't been an issue for krb in last 15 years, modulo camellia Emery: Anyone change their mind? [no] Emery: Specs (standard+info) for preauth frameworks for krb, on ongoing basis: Hartmans: Types, or frameworks? Should be types... Emery: Yes, types: favor: four against: none [rest of questions n/a until there are types for consideration] Emery: new work items? (not listed here) Hartman: One thing to consider in this space is the GSSAPI preauth that got apathetic response when presented here, but was already implemented. Authors haven't gotten that far, but we should check with them on-list. Emery: We will bring that to the list as well. Farrell: I'm all for having predictability about who will put in work on what; there will be lots of these that people are interested in, but allowing editors to prioritize sounds like a good start. Encourage people to say if they're willing to do stuff, the propose it. Simon Jofesson: Interested in/doing 2FA/OTP work. Hartman: Anyone familiar enough to have an opinion other than me? [no] We'll take it to the list. Emery: Anyone else, new work items? [no] Kerberos Authorization Data Container Authenticated by Multiple MACs -------------------------------------------------------------------- Tom Yu had brought questions on whether we should provide two MACs in the container, one keyed in the TGS key and application's long-term key. For the KDC mac, would it still be useful if we did not include the entire service ticket? Will take the questions to the list. Tom Yu: We want an authorization data container, meant to replace the AD-KDC issued container. CAMMAC is wrapper with two macs, one is for the KDC with the TGS key, and the other is with the app's long-term key. We may want authorization data that app needs to verify that KDC issued, and the KDC needs to verify that the app hasn't tampered with it. In the course of revising, I put some text in security considerations that if the KDC needs to verify the contents, it needs to have something tied to the ticket that the CAMMAC is associated with, as the service can shuffle around previously-existing authorization data mac'd by the KDC. Is that text in security considerations sufficient? Are there some minimum considerations that should be inculded? In the S4U2Proxy case, it would be important to include essentially all of the ticket contents (or a hash) duplicated in the CAMMAC. Do we need more clarification? Emery: People need more information. Have you posted to list? Yu: I was hoping people had read the draft. [show of hands] Four people have read the draft. Emery: We need more reviewers of latest draft. Yu: Another way to rephrase is, "can anybody imagine a use of the KDC mac of the CAMMAC that would be useful if there were not substantially all of the ticket content contained in it?" Paul Leach: I'll take a stab; in the MS implementaion, the PAC is signed in the kdc's key, but always sent to a particular server; the server could muck around with what it's got. If it sends another principal's pac back, it has that principal and could do anything as that principal anyway. It ought to be tied to the principal, but may not matter? Yu: Yeah, it should be done, but may not matter. Hartman: It seems like it's really easy to tie it to the ticket; I can think of lots of different ways. Games involving the session key (or its hash), or a session ID; Nico put forward several proposals. I don't think that the security considerations note is sufficient. Yu: You would recommend a required element in the cammac to tie to the ticket? Hartman: Not quite; it must tie to the ticket, but one could play games with mac keys (i.e., not necessarily a separate element in the CAMMAC). I believe it is relatively easy to do; if that's not true, I would reevaluate. One previous objection is that we want to move around PADs and CAMMACs independent of tickets; I don't buy that. We would force people to move around tickets; that would not cause me to change my mind. Yu: Anything from jabber or IRC? [no] Yu: Simo? [dropped off] Open Mic -------- None. ============ Session Over