One document matched: draft-zorn-dime-n2n-sec-lite-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY rfc2119 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
	<!ENTITY rfc3748 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
	<!ENTITY rfc3588 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
	<!ENTITY rfc4072 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml'>
	<!ENTITY rfc5226 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
	<!ENTITY rfc2989 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2989.xml'>
	<!ENTITY rfc5216 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5216.xml'>
	<!ENTITY rfc5295 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml'>
	<!ENTITY rfc5296 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml'>
	<!ENTITY rfc5247 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml'>
	<!ENTITY rfc4398 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4398.xml'>
	<!ENTITY I-D.ietf-smime-cms-rsa-kem PUBLIC "" 		
		"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-smime-cms-rsa-kem.xml">
]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" docName="draft-zorn-dime-n2n-sec-lite-00" ipr="noDerivativesTrust200902">
	<front>
		<title abbrev="Node-to-Node Security in Diameter">A Lightweight Approach to Node-to-Node Security in Diameter</title>

		<author fullname="Glen Zorn" initials="G" surname="Zorn">
			<organization>Network Zen</organization>
			<address>
				<postal>
					<street>227/358 Thanon Sanphawut</street>
					<city>Bang Na</city>
					<region>Bangkok</region>
					<code>10260</code>
					<country>Thailand</country>
				</postal>
				<phone>+66 (0) 87-040-4617</phone>
				<email>gwz@net-zen.net</email>
			</address>
		</author>

		<author fullname="Qin Wu" initials="Q." surname="Wu">
			<organization abbrev="Huawei">Huawei Technologies Co., Ltd.</organization>
			<address>
				<postal>
					<street>101 Software Avenue, Yuhua District</street>
					<city>Nanjing</city>
					<region>Jiangsu</region>
					<code>21001</code>
					<country>China</country>
				</postal>
				<phone>+86-25-84565892</phone>
				<email>sunseawq@huawei.com</email>
			</address>
		</author>
	
		<date year="2010"/>

		<abstract>
			<t>
				This document describes a lightweight method for cryptographically protecting a portion of the contents of a Diameter message in transit between an arbitrary pair of Diameter nodes.
				The scheme assumes that the destination node possesses an X.509 certificate containing an RSA public key and that that certificate is retrievable by the node
				originating the message through a DNS query.
				<vspace blankLines="1"/>
				In addition to describing the operation of the protocol, this note specifies an Attribute-Value Pair (AVP) for the encapsulation of encrypted AVPs.
			</t>
		</abstract>
	</front>

	<middle>
		<section title="Introduction">
			<t>
				Historically, Authentication, Authorization and Accounting (AAA) network traffic has been secured on a hop-by-hop basis: messages between AAA entities 
				(such as Diameter clients, agents and servers) have been protected on the wire but those entities have had unfettered access to the message contents.
				This has not typically been considered to be a concern when all of the entities in question were within the same sphere of administrative control,
				but may be problematic if the messages pass through an outside system (for example, an agent residing in an intermediate domain in a roaming situation).
				This document describes a lightweight method for cryptographically protecting a portion of the contents of a Diameter message 
				while in transit between an arbitrary pair of Diameter nodes.
			</t>
		</section>

		<section title="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">RFC 2119</xref>.
			</t>
		</section>
		
		<section anchor="PO" title="Protocol Operation">
			<t>
				The following sections describe the operation of the proposed end-to-end security scheme.  
				Although key establishment and data transfer are discussed separately, both will usually take place in the same message.
			</t>
			<section anchor="CO" title="Client Operation">
				<section anchor="CKE" title="Key Establishment">
					<t>
						TBC.
					</t>
				</section>
				<section anchor="CPDT" title="Protected Data Transfer">
					<t>
						TBC.
					</t>
				</section>
			</section>
			<section anchor="SO" title="Server Operation">
				<section anchor="SKE" title="Key Establishment">
					<t>
						TBC.
					</t>
				</section>
				<section anchor="SPDT" title="Protected Data Transfer">
					<t>
						TBC.
					</t>
				</section>
			</section>
		</section>

		<section anchor="AVPD" title="Attribute-Value Pair Definitions">
			<t>
				This section defines a container AVP for the transport of encrypted AVPs in Diameter applications.
			</t>
<!--
			<section anchor="K" title="Key AVP">
				<t>
					The Key AVP (AVP Code <AC1>) is of type Grouped <xref target="RFC3588"/>. 
					It contains the type and keying material and, optionally, an indication of the usable lifetime of
					the key, the name of the key and a Security Parameter Index (SPI) with which the key is 
					associated.
				</t>
<figure>
	<artwork><![CDATA[
Key ::= < AVP Header: AC1 >
          < Key-Type >
          { Keying-Material }
          [ Key-Lifetime ]
          [ Key-Name ]
          [ Key-SPI ]
        * [ AVP ]	
	]]></artwork>
</figure>
				<section anchor="K-T" title="Key-Type AVP">
					<t>

					</t>
				</section>
				<section anchor="K-N" title="Key-Name AVP">
					<t>
						The Key-Name AVP is of type OctetString.
						It contains an opaque key identifier.  
						Exactly how this name is generated and used depends on the key type and 
						usage in question, and is beyond the scope of this document (see <xref target="RFC5247"/> 
						and <xref target="RFC5295"/> 
						for discussions of key name generation in the context of EAP). 
					</t>
				</section>
				<section anchor="K-M" title="Keying-Material AVP">
					<t>
						The Keying-Material AVP (AVP Code <AC3>) is of type OctetString.
						The exact usage of this keying material depends upon several factors,
						including the link layer in use and the type of the key; it is beyond
						the scope of this document.					
					</t>
				</section>
				<section anchor="K-L" title="Key-Lifetime AVP">
					<t>
						The Key-Lifetime AVP (AVP Code <AC4>) is of type Integer64 <xref target="RFC3588"/>
						and represents the period of time (in seconds) for which the contents of the
						Keying-Material AVP (<xref target="K-M"/>)
						is valid.
						<list style="hanging">
							<t hangText="NOTE:">
								<vspace blankLines="0"/>
								Applications using this value SHOULD consider the beginning of
								the lifetime to be the point in time when the message containing the keying material is
								received.
							</t>
						</list>
					</t>
				</section>
				<section title="Key-SPI" anchor="K-S">
					<t>
						The Key-SPI AVP (AVP Code <AC5>) is of type Unsigned32 and contains a SPI
						value that can be used with other parameters for identifying 
						associated keying material. 
					</t>
				</section>
			</section>
-->
		</section>
		
		<section title="Security Considerations">
			<t>
				The security considerations applicable to the Diameter Base Protocol <xref target="RFC3588"/>
				are also applicable to this document.
			</t>
		</section>

		<section anchor="IANA" title="IANA Considerations">
			<t>
				TBC.
			</t>
<!--
				Upon publication of this memo as an RFC, IANA is requested to assign
				values as described in the following sections.
			</t>
			<section anchor="AC" title="AVP Codes">
				<t>
					Codes must be assigned for the following AVPs using the policy specified in RFC 3588, 
					Section 11.1.1:
					<list style="symbols">
						<t>
							Key (<AC1>, <xref target="K"/>)
						</t>
						<t>
							Key-Type (<AC2>, <xref target="K-T"/>)							
						</t>
						<t>
							Keying-Material (<AC3>, <xref target="K-M"/>)
						</t>
						<t>
							Key-Lifetime (<AC4>, <xref target="K-L"/>)
						</t>
						<t>
							Key-SPI (<AC5>, <xref target="K-S"/>)
						</t>
					</list>
				</t>
			</section>
			<section anchor="AV" title="AVP Values">
				<t>
					IANA is requested to create a new registry for values assigned to the Key-Type AVP and 
					populated with the decimal values defined in this document (<xref target="K-T"/>).
					New values may be assigned for the Key-Type AVP
					using the "Expert Review" policy <xref target="RFC5226"/>;
					once values have been assigned, they MUST NOT be deleted, replaced, modified or deprecated.
				</t>
			</section>
-->
		</section>
	</middle>
	
	<back>
		<references title="Normative References">
			&rfc2119;
			&rfc3748;
			&rfc3588;
			&rfc4072;
			&rfc5226;
			&rfc4398;
		</references>

		<references title="Informative References">
			&rfc5216;
			&rfc5295;
			&rfc5296;
			&rfc5247;
			&I-D.ietf-smime-cms-rsa-kem;
		</references>
	</back>
</rfc>