One document matched: draft-kivinen-ipsecme-oob-pubkey-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc3447 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3447.xml'>
    <!ENTITY rfc5280 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml'>
    <!ENTITY rfc5996 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml'>
    <!ENTITY rfc6394 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6394.xml'>
    <!ENTITY wou12 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-oob-pubkey.xml'>
]>

<rfc category='info' ipr='trust200902'
     docName='draft-kivinen-ipsecme-oob-pubkey-00.txt'>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc compact='yes' ?>
<?rfc strict='yes' ?>

<front>
  <title>More Raw Public Keys for IKEv2 </title>
        
  <author initials='T.' surname='Kivinen' fullname='Tero Kivinen'>
    <organization>AuthenTec</organization>
    <address>
      <postal>
        <street>Eerikinkatu 28</street>
        <code>FI-00180</code>
        <city>HELSINKI</city>
        <country>FI</country>
      </postal>
      <email>kivinen@iki.fi</email>
    </address>
  </author>
  <author fullname="Paul Wouters" initials="P." surname="Wouters">
    <organization>Red Hat</organization>
    <address>
      <postal>
	<street/>
	<city/>
	<region/>
	<code/>
	<country/>
      </postal>
      <email>pwouters@redhat.com</email>
    </address>
  </author>
        <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
            <organization>Nokia Siemens Networks</organization>
            <address>
                <postal>
                    <street>Linnoitustie 6</street>
                    <city>Espoo</city>
                    <code>02600</code>
                    <country>Finland</country>
                </postal>
                <phone>+358 (50) 4871445</phone>
                <email>Hannes.Tschofenig@gmx.net</email>
                <uri>http://www.tschofenig.priv.at</uri>
            </address>
        </author>
  <date month='March' year='2012' />
  <area>Security</area>
  <workgroup>IP Security Maintenance and Extensions
    (ipsecme)</workgroup>
  <abstract>
    <t>The Internet Key Exchange Version 2 (IKEv2) protocol currently
    only supports raw RSA keys. In some environments it is useful to
    make use of other types of public keys, such as those based on
    Elliptic Curve Cryptography. This documents adds support for other
    types of raw public keys to IKEv2.</t>
  </abstract>
</front>

<middle>
  <section title='Introduction'>
    <t>Secure DNS allows public keys to be associated with domain
    names for usage with security protocols like Internet Key Exchange
    Version 2 (IKEv2) <xref target='RFC5996'/> and Transport Layer
    Security (TLS) but it relies on extensions in those protocols to
    be specified.</t>

    <t>IKEv2 already offers support for PKCS #1 encoded RSA keys,
    i.e., a DER- encoded RSAPublicKey structure (see <xref
    target='RSA'/> and <xref target='RFC3447'/>). Other raw public
    keys types are, however, not supported.</t>

    <t>The TLS Out-of-Band Public Key Validation specification (<xref
    target='I-D.ietf-tls-oob-pubkey'/>) adds generic support for raw
    public keys to TLS by re-using the SubjectPublicKeyInfo format
    from the X.509 Public Key Infrastructure Certificate profile <xref
    target='RFC5280'/>.</t>
    
    <t>This document is similar than the TLS Out-of-Band Public Key
    Validation specification, and applies the concept to IKEv2 to
    support all public key formats defined by PKIX. This approach also
    allows future public key extensions to be supported without the
    need to introduce further enhancements to IKEv2.</t>

    <t>To support new types of public keys in IKEv2 the following
    changes are needed:</t>
    
    <t><list style='symbols'>
      
      <t>A new Certificate Encoding format needs to be defined for
      carrying the SubjectPublicKeyInfo structure. <xref
      target='cert-encoding'/> specifies this new encoding format.</t>
      
      <t>A new Certificate Encoding type needs to be allocated from
      the IANA registry. <xref target='iana'/> contains this request
      to IANA.</t>
    </list>
    </t>
    
    <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 title='Certificate Encoding Payload' anchor='cert-encoding'>

    <t>Section 3.6 of RFC 5996 defines the Certificate payload format
    as shown in Figure 1.</t>
    
    <figure><artwork><![CDATA[
                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding |                                               |
+-+-+-+-+-+-+-+-+                                               |
~                       Certificate Data                        ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: Certificate Payload Format
]]></artwork></figure>

    <t><list style='symbols'>
      
      <t>Certificate Encoding (1 octet) - This field indicates the
      type of certificate or certificate-related information
      contained in the Certificate Data field.
      
      <figure><artwork><![CDATA[
   Certificate Encoding                 Value
   ----------------------------------------------------
   Raw Public Key                       TBD
]]></artwork></figure></t>

      <t>Certificate Data (variable length) - Actual encoding of the
      certificate data. The type of certificate is indicated by the
      Certificate Encoding field.</t>
	
    </list></t>

    <t>When the certificate encoding type 'Raw Public Key' is used
    then the Certificate Data only contains the SubjectPublicKeyInfo
    part of the PKIX certificate.</t>
    
    <t>In the case of the Certificate Request payload the
    Certification Authority field MUST be empty if the "Raw Public
    Key" certificate encoding is used.</t>
    
  </section>

  <section title='Old Raw RSA Key Certificate Type'>

    <t>After this there are two ways of sending Raw RSA public keys in
    the IKEv2: The already existing mechanisms, and the new format
    defined here. The IKEv2 protocol already supports a method to
    indicate which certificate encoding formats are supported, i.e. a
    peer can send one or multiple Certificate Request payload with the
    certificate encoding types it supports. From this list the
    recipient can see which formats are supported and select one which
    is used to send Certificate back.</t>

    <t>If the peer has raw non-RSA public key, it has no other option
    than to use the new format. If it has raw RSA public key, it can
    either use the old format or the new format, and it SHOULD
    indicate support for both by sending both certificate encoding
    types inside Certificate Request payloads.</t>

    <t>If a peer receives both old and new certificate endocing
    formats in the Certificate Request payloads, it is RECOMMENDED for
    new implementations to prefer this new format defined in this
    document, so the old Raw RSA public key format could possibly be
    phased out in the future.</t>

    <t>To better support minimal implementations, it would be best to
    limit the code complexity of those versions, and in such
    implementations it might be better to implement only the new
    format as it supports all types of raw public keys.</t>

  </section>

  <section title='Security Considerations'>

    <t>An IKEv2 deployment using raw public keys needs to utilize an
    out-of-band public key validation procedure to be confident in the
    authenticity of the keys being used. One such mechanism is to use
    a configuration mechanism for provisioning raw public keys into
    the IKEv2 software. A suitable deployment is likely to be found
    with smart objects. Yet another approach is to rely on secure DNS
    to associate public keys to be associated with domain names. More
    information can be found in DNS-Based Authentication of Named
    Entitites (DANE) <xref target='RFC6394'/>.</t>

    <t>This document does not change the assumptions made by the IKEv2
    specifications since "Raw RSA Key" support is already available in
    IKEv2. This document only generalizes the raw public key support.</t>

  </section>
  
  <section title='IANA Considerations' anchor='iana'>

    <t>This document allocates a new value from the IKEv2 Certificate
    Encodings registry:</t>

    <figure><artwork><![CDATA[
TBD      Raw Public Key
]]></artwork></figure>
    
  </section>

  <section title='Acknowledgements'>

    <t>This document copies parts from the similar TLS document (<xref
    target='I-D.ietf-tls-oob-pubkey'/>).</t>

  </section>
</middle>
<back>

  <references title="Normative References">
    &rfc2119;
    &rfc5280;
    &rfc5996;
  </references>

  <references title='Informative References'>
    &rfc3447;
    &rfc6394;
    &wou12;

    <reference anchor='RSA'>
      <front>
        <title>A Method for Obtaining Digital
        Signatures and Public-Key Cryptosystems</title>
        <author surname='R. Rivest'><organization/></author>
        <author surname='A. Shamir'><organization/></author>
        <author surname='L. Adleman'><organization/></author>
        <date month='February' year='1978'/>
      </front>
      <format type='TXT' 
              target='Communications of the ACM, v. 21, n. 2'/>
    </reference>

  </references>

</back>

</rfc>