One document matched: draft-schaad-eps-trust-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "bibxml/reference.RFC.2119.xml" >
<!ENTITY getPolicyRequest SYSTEM "ForDraft/getPolicyRequest">
<!ENTITY getPolicyResponse SYSTEM "ForDraft/getPolicyResponse">
<!ENTITY sendMessageRequest SYSTEM "ForDraft/sendMessageRequest">
<!ENTITY sendMessageResponse SYSTEM "ForDraft/sendMessageResponse">
<!ENTITY readMessageRequest SYSTEM "ForDraft/readMessageRequest">
<!ENTITY readMessageResponse SYSTEM "ForDraft/readMessageResponse">
<!ENTITY SOAP11 SYSTEM "bibxml4\reference.w3c.note-soap-20000508.xml">
<!ENTITY SOAP12 SYSTEM "bibxml4\reference.w3c.rec-soap12-part1-20070427.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xlst' ?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc comments="yes"?>
<rfc category="std" docName="draft-schaad-eps-trust-01" ipr="trust200902">
<front>
<title abbrev="EPS TRUST">Email Policy Service Trust Processing</title>
<author fullname="Jim Schaad" initials="J." surname="Schaad">
<organization>Soaring Hawk Consulting</organization>
<address>
<email>ietf@augustcellars.com</email>
</address>
</author>
<date/>
<abstract>
<t>Write Me</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="XML Nomenclature and Name Spaces">
<t>The following name spaces are used in this document:</t>
<texttable>
<ttcol>Prefix</ttcol><ttcol> Namespace</ttcol><ttcol> Specification(s)</ttcol>
<c>eps</c><c>http://ietf.org/2011/plasma/</c><c>This Specification</c>
<c>S11</c><c>http://schemas.xmlsoap.org/soap/envelope/</c><c><xref target="SOAP11"/></c>
<c>S12</c><c> http://www.w3.org/2003/05/soap-envelope</c><c><xref target="SOAP12"/></c>
<c>wst</c><c> http://docs.oasis-open.org/ws-sx/ws-trust/200512</c><c><xref target="WS-TRUST"/></c>
<c>wsu</c><c> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd</c><c> [WS-Security]</c>
<c>wsse</c><c> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd</c><c> [WS-Security]</c>
<c>wsse11</c><c> http://docs.oasis-open.org/wss/oasis-wss-wsecurity-secext-1.1.xsd</c><c> [WS-Security]</c>
<c>ds</c><c> http://www.w3.org/2000/09/xmldsig#</c><c> [XML-Signature]</c>
<c>xenc</c><c> http://www.w3.org/2001/04/xmlenc#</c><c> [XML-Encrypt]</c>
<c>wsp</c><c> http://schemas.xmlsoap.org/ws/2004/09/policy</c><c> [WS-Policy]</c>
<c>wsa</c><c> http://www.w3.org/2005/08/addressing</c><c> [WS-Addressing]</c>
<c>xs</c><c> http://www.w3.org/2001/XMLSchema</c><c> [XML-Schema1][XML-Schema2]</c>
</texttable>
</section>
<section title="Requirements Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Components">
<section title="WS-Trust 1.3">
<t>We use WS-Trust as the basis for the protocol presented in this document. WS-Trust is a secure messaging protocol used for security token exchange to enable the issuance and dissemination of credentials within different trust domains. WS-Trust 1.3 is specified by OASIS in <xref target="WS-TRUST"/>. WS-Trust is built on SOAP (see <xref target="SOAP12"/>) to provide a messaging structure.</t>
<t>Implementers of this protocol MUST implement the HTTP binding.</t>
<t>Implementers of this protocol MUST implement SOAP 1.2. Support for SOAP 1.1 <xref target="SOAP11"/> is OPTIONAL.</t>
</section>
</section>
<section title="Model" anchor="model">
<t>To be supplied from the problem statement document.</t>
<figure align="center" title="Message Access Control Actors" anchor="fig1"><artwork><![CDATA[
(1)(3) +----------+
+----------->|Sending |<------------+
| |Agent | |
(2) v +----------+ v
+----------+ ^ +---------+
|Email | | |Mail |
|Policy |<----------+ |Transfer |
|Service | |Agent |
+----------+ +---------+
() ^ +----------+ ^
| |Receiving | |
+----------->|Agent |<------------+
()() +----------+
]]></artwork></figure>
<t>List the boxes above and give some info about them.
<list style="hanging">
<t hangText="Email Policy Service"> is the gateway controller for accessing a message. Although it is represented as a single box in the diagram, there is no reason for it to be in practice. Each of the three protocols could be talking to different instances of a common system. This would allow for a server to operated by Company A, but be placed in Company B's network thus reducing the traffic sent between the two networks.</t>
<t hangText="Mail Transfer Agent"> is the entity or set of entities that is used to move the message from the sender to the receiver. Although this document describes the process in terms of mail, any method can be used to transfer the message.</t>
<t hangText="Receiving Agent"> is the entity that consumes the message.</t>
<t hangText="Sending Agent"> is the entity that originates the message.</t>
</list>
</t>
<section title="Sender Processing">
<t>We layout the general steps that need to be taken by the sender of an EPS message. The numbers in the steps below refer to the numbers in the upper half of <xref target="fig1"/>. A more detailed description of the processing is found in <xref target="getPolicy"/> for obtaining the security policies that can be applied to a messages and <xref target="sendMessage"/> for sending a message. </t>
<t>
<list style="numbers">
<t>The Sending Agent sends a message to one or more Email Policy Services in order to obtain the set of policies that it can apply to a message along with a security token to be used in proving the authorization. Details of the message send can be found in <xref target="getPolicy-Request"/>.</t>
<t>The Email Policy Service examines the set of policies that it understands and checks to see if the requester is authorized to send messages with the policy.</t>
<t>The Email Policy Service returns the set of policies and an security token to the Sending Agent. Details of the message sent can be found in <xref target="getPolicy-Response"/>.</t>
<t>The Sending Agent selects the Email Policy(s) to be applied to the message, along with the set of recipients for the message.</t>
<t>The Sending Agent relays the selected information to the Email Policy Service along with the security token. Details of this message can be found in <xref target="sendMessage-Request"/>.</t>
<t>The Email Policy Service creates the recipient info attribute as defined in <xref target="EPS-ASN"/>.</t>
<t>The Email Policy Service returns the created attribute to the Sending Agent. Details of this message can be found in <xref target="sendMessage-Response"/>.</t>
<t>The Sending Agent composes the CMS EnvelopedData content type placing the returned attribute into a KEKRecipientInfo structure and then send the message to the Mail Transport Agent.</t>
</list>
</t>
</section>
<section title="Recieving Agent Processing">
<t>We layout the general steps that need to be taken by the sender of an EPS message. The numbers in the steps below refer to the numbers in the lower half of <xref target="fig1"/>. A more detailed description of the processing is found in <xref target="readMessage"/>.</t>
<t>
<list style="numbers">
<t>The Receiving Agent obtains the message from the Mail Transport Agent.</t>
<t>The Receiving Agent starts to decode the message and in that process locates an EvelopedData content type which has a KEKRecipientInfo structure with a XXXX attribute.</t>
<t>The Receiving Agent processes the SignedData content of the XXXX attribute to determine that communicating with it falls within accepted policy.</t>
<t>The Receiving Agent transmits the content of the XXXX attribute to the referenced Email Policy Service. The details of this message can be found in <xref target="readMessage-Request"/>.</t>
<t>The Email Policy Service decrypts the content of the message and applies the policy to the credentials provided by the Receiving Agent.</t>
<t>If the policy passes, the Email Policy Service returns the appropriate key or RecipientInfo structure to the Receiving Agent. Details of this message can be found in <xref target="readMessage-Response"/>.</t>
<t>The Receiving Agent proceeds to decrypt the message and perform normal processing.</t>
</list>
</t>
</section>
</section>
<section title="Initial Token and Policy Acquisition" anchor="getPolicy">
<t>The first step in the process is for the sending agent to acquire the set of policies that it is permitted to use in labeling a message. This is done by a request and response. For this purpose we define two new uri values to be used in the wst:RequestType field:
<list style="hanging">
<t hangText="urn:ietf:params:ns:eps-xml:RequestSendToken"> is used to identify a request to receive a set of security policies that can be used along with a security token to identify the sending agent when sending a message.</t>
</list>
</t>
<t>It is assumed that the Email Policy Server will do an exhaustive set of tests to check which security policies are usable by the sending agent in order to label messages. As this is going to be a computationally intensive operation, the process is expected to be done infrequently compared to sending messages. The data and security token returned is therefore expected to be good for a period of time. In situations where changes to privileges change and it is important that the system correctly enforce them, then a subsequence check on just the label presented at the time the mail message is sent.</t>
<section title="Request Policy Information" anchor="getPolicy-Request">
<t>Send a wst:RequestSecurityToken message to the Email Policy Service. The request will contain at least the following elements:
<list>
<t>A wst:RequestType containing a urn:ietf:params:ns:eps-xml:#RequestSendToken URI MUST be included.</t>
</list>
</t>
<t>An example of a message requesting the set of policy information is:
&getPolicyRequest;
In this example the identity information of the requester is implicit from the transport protocol used.</t>
</section>
<section title="Request Policy Information Response" anchor="getPolicy-Response">
<t>Receive a wst:RequestSecurityTokenResponse message with the following elements:
<list>
<t>A wst:RequestedSecruityToken element containing the security token MUST be included. The format of the security token is not specified and is implementation specific, it is not expected that . Examples of items that could be used as security tokens are SAML statements, encrypted record numbers in a server database. </t>
<t>A eps:PolicySet containing the set of policies that the server has been ascertained are acceptable for the querier to use in labeling email messages MUST be included.</t>
<t>A wst:Lifetime giving the life time of the token SHOULD be included. It is not expected that this should be determinable from the token itself and thus must be independently provided. There is no guarantee that the token will be good during the lifetime as it make get revoked due to changes in credentials, however the client is permitted to act as if it where. The token provided may be used for duration. If this element is absent, it should be assumed that the token is either a one time token or of limited duration.</t>
</list>
</t>
<t>An example of a message returning the set of policy information is:
&getPolicyResponse;
In this example, the Email Policy Service is returning three different policies that can be used along with a security token and a key to be used with the token when sending a message.
</t>
</section>
</section>
<section title="Sending A Message" anchor="sendMessage">
<t>When the sending agent is ready to build the list of recipient info structures, it builds a request message containing the label, the key encryption key and other information required for decryption to send to the Email Policy Service. It will then get back a response containing a CMS SignedData object to be included in a KEKRecipientInfo object.</t>
<t>To identify this operation we have defined a new uri urn:ietf:params:ns:eps-xml:RequestSendToken.</t>
<section title="Send Message Request" anchor="sendMessage-Request">
<t>The process we are looking at is:
Send a wst:RequestSecurityToken to the Email Policy Service. The request MUST contain at least the following elements:
<list>
<t>A wst:RequestType containing a urn:ietf:params:ns:eps-xml:RequestSendToken URI.</t>
<t>Put in the previously assigned tokens as if you were doing a token renewal.</t>
<t>An eps:SendMessage as defined in this document.</t>
</list>
</t>
<t>An example of a message returning the set of policy information is:
&sendMessageRequest;
</t>
</section>
<section title="Send Message Response" anchor="sendMessage-Response">
<t>Receive a wst:RequestSecurityTokenResponse from the Email Policy Service. The response MUST contain at least the following elements:
<list>
<t>An eps:SendMessageResponse as defined in this document.</t>
</list>
</t>
<t>An example of a message returning the set of policy information is:
&sendMessageResponse;
</t>
</section>
</section>
<section title="Decoding A Message" anchor="readMessage">
<t>When the receiving agent is ready to decrypt the message, it identifies that there is a KEKRecipientInfo object which contains a key attribute identified by id-keyatt-eps-token. It validates that communicating with the Email Policy Service is within local policy and then sends a request to the service to obtain the encryption key for the message.</t>
<t>To identify this operation we have defined a new uri urn:ietf:params:ns:eps-xml:RequestReadToken.</t>
<t>In some cases the recipient of a message is not authorized to use the same set of labels for sending a message. For this purpose a token can be returned in the message along with the key so that recipient of the can reply to the message using the same set of security labels.</t>
<section title="Requesting Message Key" anchor="readMessage-Request">
<t>Send a wst:RequestSecurityToken message to the EMail Policy Server. The request MUST contain at least the following elements:
<list>
<t>A wst:RequestType containing a urn:ietf:params:ns:eps-xml:RequestReadToken URI.</t>
<t>A eps:ReadMessageRequest defined in this document.</t>
</list>
</t>
<t>An example of a message returning the set of policy information is:
&readMessageRequest;
</t>
</section>
<section title="Requesting Message Key Response" anchor="readMessage-Response">
<t>Receive a wst:RequestSecurityTokenResponse message from the Email Policy Server. The response contains the following elements:
<list>
<t>An eps:ReadMessageResponse.</t>
</list>
</t>
<t>An example of a message returning the set of policy information is:
&readMessageResponse;
</t>
</section>
</section>
<section title="Security Considerations">
<t>To be supplied after we have a better idea of what the document looks like.</t>
</section>
<section title="IANA Considerations">
<t>We should have at least one name space to be registered.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
<reference anchor="EPS-ASN">
<front>
<title>Email Policy Service ASN.1 Processing</title>
<author initials="J." surname='Schaad' fullname='Jim Schaad'/>
<date month='Jan' year='2011'/>
</front>
<seriesInfo name='Work In Pgoress' value='draft-eps-smime-00'/>
</reference>
&SOAP11;
&SOAP12;
<reference anchor="WS-TRUST" target="http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html">
<front>
<title>WS-Trust 1.3</title>
<author initials="K" surname="Lawrence"/>
<author initials="C" surname="Kaler"/>
<author initials="A" surname="Nadalin"/>
<author initials="M" surname="Goodner"/>
<author initials="M" surname="Gudgin"/>
<author initials="A" surname="Barbir"/>
<author initials="H" surname="Granqvist"/>
<date month="March" day='19' year='2007'/>
</front>
<seriesInfo name="OASIS Standard" value="ws-trust-200512"/>
<format type='HTML' target='http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html'/>
</reference>
</references>
<section title="XML Schema">
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 02:59:00 |