From dwallach@cs.rice.edu Wed Mar 28 11:28:58 2001 Date: Tue, 27 Mar 2001 22:21:21 -0600 (CST) From: Dan Wallach Reply-To: Usenix Security 2001 Chair To: aglo@umich.edu Subject: UsenixSec2001: paper L41 has been accepted Congratulations! Your paper (L41) has been accepted for publication in the 2001 Usenix Security Symposium. ID: L41 Title: Kerberized Credential Translation: A Solution to Web Access Control Authors: Olga Kornievskaia, CITI, Peter Honeyman, CITI, Bill Doster, CITI, Kevin Coffman, CITI Primary Contact: Olga Kornievskaia Contact E-mail: aglo@umich.edu THE FINAL CAMERA-READY DEADLINE IS MAY 2, 2001. Instructions for preparing your paper are (or will shortly be) here: http://www.usenix.org/events/sec01/instrux/ Thanks, Dan ========== Review #1 Please answer the following questions: 1: Is the work of interest to a reasonable portion of the USENIX attendees? If not, please try and suggest an alternate forum for the work. Yes, it should be. On the negative side, this is yet another authorization proxy. As long as there are legacy systems that people don't want to rewrite, there will be proxies. This makes a proxy of more interest to the security community than a purist would like, but it also makes proxies so common to be of less interest, after a while. On the positive side, the creation of a CA, using Kerberos authentication and authorization, to yield short-lived certificates that carry the same authorization (and therefore don't need any more authentication during issuance than Kerberos provides) is a good example that should be provided to the community at large. 2: Does the abstract of the work briefly and clearly state its goals and conclusions? Yes. 3: Are the references sufficient? The related work section is missing references to SDSI 2.0 and the access controlled web browsing work of Dwaine Clarke for his MIT Master's Thesis. References to that work and the underlying SDSI 2.0 documents could be added. 4: Is the English use and presentation of this work acceptable? The English is just a little rough. There are typos that appear sometimes to be careless typing and at others to be from a faulty grasp of grammar. 5: What are the weakest and/or least understandable parts of the work with respect to its presentation? There is no special weakness to point out. 6: Is the work technically correct? It appears to be. 7: What are the weakest technical parts of the work? There is no security analysis. Generally, a proxy is a security hole in a system design. One needs to trust the proxy not to misbehave when end-to-end authorization would not require such trust. Of course, end-to-end authorization requires that all parties use the same authorization and authentication mechanism. In this case, they cannot, as a basic premise of the work. However, in any capability system, one process hands a capability on to an intermediate process in order to get it to act on behalf of the first process. To the extent that a normal Kerberized system acts like a capability system, one could compare the security of such a normal system (using Kerberos throughout) to the hybrid systme described here). === The paper says they assume the existence of a workable PKI. It is not clear what they mean by PKI. If one takes the US Federal Gov't PKI as an example, it's not clear that they either want or could use such a massive PKI. The KCA that grants the public key certificates used in this mechanism does not seem to require any other PKI, so this statement (on p.5) is not backed up and may not be true. An existing Kerberos system does not merely authenticate users but also authorizes them (e.g., to access AFS accounts). Such authorization needs to remain local and can not be delegated to some worldwide or even national PKI. In addition, local Kerberos registration probably includes careful physical-world, in-person authentication of the person being registered (e.g., through a student ID). It is not likely that any larger scale PKI would do an equivalent job. The paper should probably have considered these points and discussed them. A security analysis needs to consider not just a protocol but the registration of keyholders. 8: Do the goals of this work need to be altered, and if so, how? No. 9: If you believe that this work should not be accepted, what changes would be sufficient for you to change your opinion? No changes. Please include anything else that you think might be helpful to the author here: ========== Review #2 Please answer the following questions: 1: Is the work of interest to a reasonable portion of the USENIX attendees? If not, please try and suggest an alternate forum for the work. Yes. 2: Does the abstract of the work briefly and clearly state its goals and conclusions? Yes. 3: Are the references sufficient? The related work section is missing references to SDSI 2.0 and the access controlled web browsing work of Dwaine Clarke for his MIT Master's Thesis. References to that work and the underlying SDSI 2.0 documents could be added. 4: Is the English use and presentation of this work acceptable? The English is just a little rough. There are typos that appear sometimes to be careless typing and at others to be from a faulty grasp of grammar. 5: What are the weakest and/or least understandable parts of the work with respect to its presentation? There is no special weakness to point out. 6: Is the work technically correct? It appears to be. 7: What are the weakest technical parts of the work? There is no security analysis. Generally, a proxy is a security hole in a system design. One needs to trust the proxy not to misbehave when end-to-end authorization would not require such trust. Of course, end-to-end authorization requires that all parties use the same authorization and authentication mechanism. In this case, they cannot, as a basic premise of the work. However, in any capability system, one process hands a capability on to an intermediate process in order to get it to act on behalf of the first process. To the extent that a normal Kerberized system acts like a capability system, one could compare the security of such a normal system (using Kerberos throughout) to the hybrid systme described here). === The paper says they assume the existence of a workable PKI. It is not clear what they mean by PKI. If one takes the US Federal Gov't PKI as an example, it's not clear that they either want or could use such a massive PKI. The KCA that grants the public key certificates used in this mechanism does not seem to require any other PKI, so this statement (on p.5) is not backed up and may not be true. An existing Kerberos system does not merely authenticate users but also authorizes them (e.g., to access AFS accounts). Such authorization needs to remain local and can not be delegated to some worldwide or even national PKI. In addition, local Kerberos registration probably includes careful physical-world, in-person authentication of the person being registered (e.g., through a student ID). It is not likely that any larger scale PKI would do an equivalent job. The paper should probably have considered these points and discussed them. A security analysis needs to consider not just a protocol but the registration of keyholders. 8: Do the goals of this work need to be altered, and if so, how? No. 9: If you believe that this work should not be accepted, what changes would be sufficient for you to change your opinion? No changes. Please include anything else that you think might be helpful to the author here: ========== Review #3 Please answer the following questions: 1: Is the work of interest to a reasonable portion of the USENIX attendees? If not, please try and suggest an alternate forum for the work. Yes. 2: Does the abstract of the work briefly and clearly state its goals and conclusions? Yes. 3: Are the references sufficient? Yes. 4: Is the English use and presentation of this work acceptable? Some typos/grammer, "a digest of the all the handshake message prior to" (two errors), "In the second step, The " (capitalisation), "apriori", "save certifiates in user's", "Opensmall SSL library". 5: What are the weakest and/or least understandable parts of the work with respect to its presentation? Section 4.1 mentions that there's no way to clear the Windows cert cache, how is this problem resolved? Or does the cert store just keep accumulating KCA-issued certs forever? Section 5 mentions "Linux 6.2", whose Linux 6.2? 6: Is the work technically correct? SSL doesn't use HMAC but a type of proto-HMAC, it'd be best to delete the mention of HMAC next to SSL in section 3.2 since the preceding text already describes it as a keyed digest which is accurate (TLS uses HMAC). When using these certs in browsers, you also need to add the KCA cert to the browser's cert store in order for certs issued by it to be trusted by the browser. 7: What are the weakest technical parts of the work? The scheme depends on SSLv3 timestamps in the SSL hello message, what happens when this is used with Windows machines with effectively random clocks? What about client implementations which get the endianness of the timestamp wrong? What about clients which don't include a timestamp at all but just use random data? (Yes, these things do exist - since the timestamp is never explicitly used in SSL, there's no error indication if you get it wrong, so implementations have appeared which put any old rubbish in that field). 8: Do the goals of this work need to be altered, and if so, how? - 9: If you believe that this work should not be accepted, what changes would be sufficient for you to change your opinion? - Please include anything else that you think might be helpful to the author here: ========== Review #4 Cool topic, the integration of Kerberos and SSL, and I liked the attention to practical details. The presentation somewhat undermined the paper, though - key parts of the design were not completely clear, in particular, the exact role played by the SSL transcript and what elements in the transcript were required, and the lengthy bulleted list in 3.3, which would work better as explicit pseudo code. Other comments and typos - * in fig 1, item 4, there's an extraneous ] * in 2.1, it would help to hyphenate "ticket granting ticket", readers unfamiliar with Kerberos may otherwise trip over it * capitalize "the server uses the public key" in the caption of fig 2 * in fig 2, explain the role of the timestamp * explain in 2.2 why you'd want to renegotiate the security context * explain more thoroughly in 2.3 the danger of "requesting a ticket for a rogue server" It's not clear if this means "requesting a ticket in order to access a rogue server" or "requesting a ticket on behalf of a rogue server". For whichever of these, what bad things can happen if you do it? * in 3.1, how often does Alice have to generate public/private key pairs, and how expensive is this? * in fig 4, what exactly is "[Key material]"? The caption discusses a *negotiated* SSL session key, yet there doesn't appear to be a negotiation of it, just a presentation via "[Key material]". * in 3.2, "the all the handshake message prior to this one" has (1) a typo at the beginning, (2) isn't clear what "prior to this one" means * "force the Web server to request renegotiation" how do you force it? * in 3.2, the Web server winds up caching Kerberos credentials, after earlier the paper made a good argument that we don't want to trust the Web server with Kerberos authentication keys. There should be more discussion here on the risks of the credential caching. In particular, does this mean that if I compromise a Web server, all I have to do to exploit its users is add a bit of extra code to my trojan that waits around for user credentials to show up and then uses them to further my attack? * I didn't understand the comment in 4.1 about storing certificates in the ticket cache having the advantage that they're wiped when the user logs out. That's not anything fundamental about how ticket caches are managed, it's just how some users choose to manage their cache. Surely they could likewise choose to wipe the certificates on logout if they resided somewhere else. * the paper needs proofreading, there are articles like "the" and "a" missing in several places * typo in 4.2, "Opensmall SSL library" * in 5, the assessment should split out the load into client and server components * in 5, how much of the total delay is *additional* to what would be incurred anyway if we weren't using the cross-authentication mechanism? * explain what s_client does * what's the difference in the 3rd paragraph of 5 between "termination of the browser application" and "termination of the browser software" if any? * in 6, "discuss open questions" isn't really done. * typo in 6, "an SSL-enabled Telnet" needs "such as" before it. * [3] has a garbled date. * [4] needs an URL and a date. * [16] has a mangled tilde. ========== Review #5 Please answer the following questions: 1: Is the work of interest to a reasonable portion of the USENIX attendees? If not, please try and suggest an alternate forum for the work. Yes. 2: Does the abstract of the work briefly and clearly state its goals and conclusions? Yes. 3: Are the references sufficient? Ok. 4: Is the English use and presentation of this work acceptable? Yes. 5: What are the weakest and/or least understandable parts of the work with respect to its presentation? P. 5, last paragraph: what name goes in the short term certificate? 6: Is the work technically correct? Appears to be except more analysis of the SSL transcript to KCT protocol is needed. 7: What are the weakest technical parts of the work? Delegation without permission from the initiator. How would you extend the mechanism to show the user intended to allow the web server to act on its behalf without modifying the client? Also, how would restrictions on the web server's actions be implemented? Section 3: dependency on PKI on the client would be fine for some scenarios but not good for others. 8: Do the goals of this work need to be altered, and if so, how? Since clients will be modified anyway (Netscape), and IE can be modified with a browser plugin, I would remove the requirement of not modifying the browser. 9: If you believe that this work should not be accepted, what changes would be sufficient for you to change your opinion? Please include anything else that you think might be helpful to the author here: