Hi Carl,
General Sorry it took longer than I was hoping for but I finally got the 09 draft out. I want to thank you and Peter for your feedback because it has help the document in my humble opinion.:) I have done a little more surgery in this version to try and put the focus more on email with assess control rather than just access control as you suggested. I think it is now clear we are looking to deliver an alternative for ESS not an alternative for S/MIME as a whole. Jims document get more into the Recipient Info section so I did not want to steal his thunder on that part. I have pruned out some of the non-essential content to get the size down as you also suggested. I have added your suggested security and privacy concerns to the security considerations. I hope I have accurately captured the concerns there. See inline below Trevor -----Original Message----- From: plasma [mailto:[email protected]] On Behalf Of Carl Wallace Sent: Thursday, November 21, 2013 2:21 PM To: [email protected] Subject: [plasma] draft-freeman-plasma-requirements-08 After IETF 88 I read this document for this first time. Below are some comments. General - The document is too long. The use cases seem unnecessary to support the primary (?) motivation - i.e., ESS security labels don't work as desired. - Should state early in the document whether or not use of S/MIME (i.e., CMS) is a requirement or if the aim is to do something different (first bullet in 5.2 asserts backwards compatibility but is pretty far into the document and section 5.2 is a bit fuzzy). - For a document that asserts an email focus up front, there is too much focus on SAML/XACML concepts. An email focus for the document might be to reference a new recipient info type that points to a key server (and maybe a signed attribute for instructions to key server too). While the document sets the table with ESS labels as the objection, it seems like the real objection is premature release of CEKs relative to access control decisions (which doesn't necessarily have anything to do with labels). With a different orientation, most of the work would then be in the definition of the key server interface (including formats, like a RecipientInfo lockbox) and key server operations, where the SAML/XACML material would probably fit more naturally. Comments - The vocabulary section seems misplaced on a first read through. It would benefit from some text in the introductory section that alludes to the proposed architecture, or at least describes some of the SAML/XACML concepts that appear in the vocabulary section. [tf] I have clarified this vocabulary list supplements rfc3198 which is a normative reference and remove duplication with 3198 - In section 2.1, bullet 7 applies more to S/MIME than ESS security [tf] removed labels. - The last paragraph in section 2.2 would benefit from some connection to S/MIME, i.e., describe how a S/MIME sender benefits from delegating authentication of a recipient to a SAML attribute provider who uses username/password for authentication. [tf] added some clarifying text on why use of other forms of credentials is a benefit. - Why is section 2.3 necessary? [tf] removed - I would break section 2 into two parts: one part would provide background on things like SAML. The other would catalog problems with current mechanisms. Sections 2.1 and 2.5 would fall in the latter part. It's not altogether clear why the other sections are necessary in a document generating requirements for improved email access control mechanisms. [tf] I have split out the access control model discussion to a separate section to the ESS discussion. - Requirements should be organized around functions, perhaps: sender generation/release of email and keys, intermediary receipt/storage/release of email and keys, recipient acquisition of email and key, attribute generation/aggregation/storage/release, access control policy definition/storage/evaluation/versioning/expiry. [tf] I want to discuss this more with Jim before I change the requirements layout. - The last paragraph in section 3.2.1 is not clear. Why would Bob's use of the same username/password attest to his identity in an email he sends in response to a message from the bank? Is this suggesting he authenticates to some key server interface to obtain a new signature key and that attests to his identity? [tf] Bob has a way to authenticate to his identity provider which is independent of the use context. If he uses password, otp, rubber chicken etc., he always uses the same mechanism regardless of if its email, web access etc. - Section 3.3 seems like a bit of a stretch as a requirement given Dave could simply copy and paste mail into a new thread. [tf] The concern is to get the information from Charlie to Dave with some level of assurance. Charlie has to trust Dave to treat the information appropriately. This should be possible without the transaction needing to be pre-ordained by some central admin in Charlie's organization. One common problem with SAML implementations is the dependency establishing federation before any interaction is possible between the identity provider and relying party. - Section 3.4.1 refers to a curious concept: "finding all instances of the data". How would any access control mechanism account apply policies to data already released? This section notes that Frank labels an email with Project X and Company Foo's IP labels. How would a recipient know which label applied to which portions of the email? This section concludes with the idea that Grace can no longer access Program X mail. It should probably more simply state that she can no longer retrieve CEKs for Program X mail from the server. She may well have access to Program X mail through a local copy. Generally this section is confusing and seems likely to render email threads very difficult to manage as multiple labels are applied that all parties may not be able to access. How would labels be removed if one were to forward a message or reply to a message while including only the part associated with one of the labels? [tf] The mechanism in the plasma service document describes how to do that. It allows for consistent policy enforcement regardless of how many times a message is bifurcated and which domain it is delivered to. I have clarified the text for Grace as you suggested. - In 3.4.2, where is Grace's signature generated, i.e., by Grace or by the server? Item (f) is difficult to parse. Some explanation as to how one can be required by policy to confirm compliance with policy without knowing the specifics of the policy would be helpful. This section asserts a requirement to support exchange of forms that does not seem to appear elsewhere in the document. These sections appear to address web-based access to a workflow more than secure email. [tf] The policy compliance signature comes from the PDEP. Grace can sign as well if the policy wants and she has a suitable credential, but it's the PDEP who attests the policy compliance i.e. it's a e-notary in this case. - Section 3.5 describes (more or less) how anyone with same attributes as Grace can access email sent to Grace. Is there a requirement for Frank to be able to send email to Grace such that only Grace can access it? What prevents Brian from obtaining the key even if Grace is not away and did not forward the message? [tf] its really setting the stage for whatever the policy requires. A policy can enforce named recipients only or anybody with the right attributes or whatever it wants. It could change its mind depending on the domain of the recipient. - Section 3.6 (like several other sections) asserts a requirement for recipient's to be able to confirm the email is from a specific sender. If server-applied signatures are used, how does this work? If user-applied signatures are used doesn't this violate one of the primary aims of the work, i.e., to support users who do not possess an S/MIME credential? [tf] The PDEP signature would assert who it is singing on behalf of. - How do you permit the mail server from leaking attributes to a sender via failure notices? For example, Alice sends various test messages to Bob under different policies to determine which attributes are associated with him. [tf] The PIP manages that process in conjunction with the subject. It has policy for what attributes it will release to which PDEPS where its B2B. For Consumers, it would likely need consent from the subject. - In section 3.8, should inbound inspection also search for leakage to unauthorized parties? [tf] Isn't that more a function for outbound? Given the base model is attribute based there is also a challenge as often the full set of subject attributes are not know to the inspection service. It can typicaly do some high level checks e.g. domain based rather than user based. - Is there a requirement to enable a sender to be able to express a specific version of a policy be used at enforcement time (vs some later version)? [tf] this gets into the whole policy versioning discussion. I don't think it's a sender choice thing. I do think the PAP could make that choice but it has latitude to do so via the URI. The URI binds to s asset of ruleks which are managed over time. The PAP can choose to update the rules at the URL location or start generating new URIs if it wants to distinguish a new set of policies. - Is there a requirement for communications partners to be able to contribute attributes to others? For example, Alice may associate some attribute with Frank to allow him to participate in some exchange. [tf] potentially yes but the issue is how to discover those attributes. The PDEP may have a relationship with Alice's PIP so can discover attributes about Frank that Alice want to publish. Certainly that may be cases where Frank can go to multiple PIP to gather attributes. An example of this in action I came across was in healthcare relating to control substance prescriptions. For a controlled substance prescription, the doctor needs an attribute to say they are a licensed doctor in the state they are practicing in as well as at attribute asserting they are authorized to issue controlled substances. One attribute comes from an authority in the state, the other form the DEA. - Section 5.2 seems to reference the "basic policy" concept in conflicting ways, i.e., as backwards compatible with current S/MIME practices and to accomodate users with no certificate. [tf] basic policies are simple, authentication only policies. Therefore if the sender discovers an encryption certificate for a recipient, it can use the existing S/MIME mechanism without conflict to the policy. If the sender selects a basic policy, the client could do the normal S/MIME certificate discovery process and only invoke the new mechanism if it fails to find a certificate for some recipients therby eliminating the need to remove recipients where no certificate can be found. The client cannot use the existing S/MIME mechanism with an advanced policy. Maybe we should can them authentication only polices and authorization polices? Some additional security considerations: - Use of an authentication mechanism that can be reset via control of an email account is problematic in support of an email access control tool. - Granting access to different portions of an email message is similarly weak as ESS labels given there is no cryptographic separation between different groups of users accessing a single message. - Is there any need to provide an indication that a key has already been released to Bob or someone purporting to be Bob in the past? For example, in section 3.2.1. - Need to discuss migration from one algorithm to another in the event an algorithm is deemed no longer suitable. What's the lifetime of documents/keys held by a plasma server? Some additional privacy considerations - Moving the decryption capability to servers enables "pervasive monitoring" in ways that end-to-end encryption does not. Some discussion of the trade off is warranted (including perhaps how it is not a significant change due to escrow of encryption keys in current practice). - Downloading keys allows for automated read receipt generation. Is this desirable? Miscellaneous - Given the references to SAML, XACML, etc., should KEYPROV be cited as a key format spec to use? Nits - In section 2, change "without certificates" to "without valid certificates". - In section 2.1, bullet 6, s/enforce/enforced. - In section 2.2, s/replying party/relying party. (multiple occurrences) - In section 2.2, s/a mean/a means. - In section 2.2, s/by to a subjects/to a subject's. (the sentence containing this change is pretty difficult to parse in general) - In section 2.2.1, s/subject's themselves/subjects themselves. - In section 3.1, should this reference Alice's ISP or her email service provider? - In section 3.2.1, s/recipients identity/recipient's identity - In section 3.4.1, s/confidentiality its own/confidentiality of its own - In section 3.4.2, s/Franks/Frank's - In section 3.6 bullet (4), delete " : , then encrypts the message." _______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
_______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
