One document matched: draft-kivinen-ipsecme-oob-pubkey-11.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3447 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3447.xml'>
<!ENTITY rfc4025 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4025.xml'>
<!ENTITY rfc4055 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4055.xml'>
<!ENTITY rfc4754 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4754.xml'>
<!ENTITY rfc5246 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY rfc5280 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml'>
<!ENTITY rfc5480 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml'>
<!ENTITY rfc5996 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5996.xml'>
<!ENTITY rfc6394 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6394.xml'>
<!ENTITY rfc7250 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml'>
<!ENTITY rfc7296 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml'>
<!ENTITY rfc7427 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7427.xml'>
]>
<rfc category='std' ipr='trust200902'
updates="7296"
docName='draft-kivinen-ipsecme-oob-pubkey-11.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>INSIDE Secure</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></organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country/>
</postal>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<date month='August' year='2015' />
<area>Security</area>
<abstract>
<t>The Internet Key Exchange Version 2 (IKEv2) protocol currently
only supports raw RSA keys. In constrained 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='RFC7296'/> and Transport Layer
Security (TLS) <xref target='RFC5246'/> but it relies on
extensions in those protocols to be specified.</t>
<t>In <xref target='RFC5996'/> IKEv2 had 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 key types are, however, not supported. In <xref
target='RFC7296'/> this feature was removed, and this document
adds support for raw public keys back to IKEv2 in a more generic
way.</t>
<t>The TLS Out-of-Band Public Key Validation specification (<xref
target='RFC7250'/>) 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 to 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 base IKEv2 include support for RSA and DSA signatures, but
the Signature Authentication in IKEv2 <xref target='RFC7427'/>
extended IKEv2 so that signature methods over any types of keys
can be used. Implementations using raw public keys SHOULD use the
Digital Signature method described in the RFC7427.</t>
<t>When using raw public keys, the authenticated identity is not
usually the identity from the ID payload, but instead the public
key itself is used as identity for the other end. This means that
ID payload contents might not be useful for authentication
purposes. It might still be used for policy decisions, for
example to simplify the policy lookup etc.</t>
</section>
<section anchor="terminology" 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'/>.</t>
</section>
<section title='Certificate Encoding Payload' anchor='cert-encoding'>
<t>Section 3.6 of RFC 7296 defines the Certificate payload
format as shown in <xref target="payload"/>.</t>
<figure anchor="payload" title="Certificate Payload Format." ><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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>To support raw public keys, the field values are as
follows:</t>
<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.</t>
</list></t>
<t>In order to provide a simple and standard way to indicate the
key type when the encoding type is 'Raw Public Key', the
SubjectPublicKeyInfo structure of the PKIX certificate is used.
This is a a very simple encoding, as most of the ASN.1 part can be
included literally, and recognized by block comparison. See <xref
target='RFC7250'/> Appendix A for a detailed breakdown. In
addition, <xref target='examples'/> has several examples.</t>
<t>In addition to the Certificate payload, the Cert Encoding for
Raw Public Key can be used in the Certificate Request payload. In
that case the Certification Authority field MUST be empty if the
"Raw Public Key" certificate encoding is used.</t>
<t>For RSA keys, the implementations MUST follow the public key
processing rules of section 1.2 of the Additional Algorithms and
Identifiers for RSA Cryptography for PKIX (<xref
target="RFC4055"/>) even when the SubjectPublicKeyInfo is not part
of a certificate, but rather sent as a Certificate Data field.
This means that RSASSA-PSS and RSASSA-PSS-params inside the
SubjectPublicKeyInfo structure MUST be sent when applicable.</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 way to achieve this goal
is to use a configuration mechanism for provisioning raw public
keys into the IKEv2 software. "Smart object" deployments are
likely to use such preconfigured public keys.</t>
<t>Another approach is to rely on secure DNS to associate public
keys with domain names using the IPSECKEY DNS RRtype <xref
target='RFC4025'/>. More information can be found in DNS-Based
Authentication of Named Entities (DANE) <xref
target='RFC6394'/>.</t>
<t>This document does not change the security assumptions made by
the IKEv2 specification since "Raw RSA Key" support was already
available in IKEv2. This document only generalizes 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 reproduces some parts of the similar TLS document
(<xref target='RFC7250'/>).</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc5280;
&rfc7296;
&rfc7427;
</references>
<references title='Informative References'>
&rfc3447;
&rfc4025;
&rfc4055;
&rfc4754;
&rfc5246;
&rfc5480;
&rfc5996;
&rfc6394;
&rfc7250;
<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>
<section title='Examples' anchor='examples'>
<t>This appendix provides examples of the actual payloads sent on
the wire.</t>
<section title='ECDSA Example'>
<t>This first example uses the 256-bit ECDSA private/public key
pair defined in section 8.1 of the IKEv2 ECDSA document <xref
target='RFC4754'/>.</t>
<t>The public key is as follows:</t>
<t><list style='symbols'>
<t>Algorithm : id-ecPublicKey (1.2.840.10045.2.1)</t>
<t>Fixed curve: secp256r1 (1.2.840.10045.3.1.7)</t>
<t>Public key x coordinate :
cb28e099 9b9c7715 fd0a80d8 e47a7707
9716cbbf 917dd72e 97566ea1 c066957c
</t>
<t>Public key y coordinate :
2b57c023 5fb74897 68d058ff 4911c20f
dbe71e36 99d91339 afbb903e e17255dc
</t>
</list></t>
<t>The SubjectPublicKeyInfo ASN.1 object is as follows:
<figure><artwork><![CDATA[
0000 : SEQUENCE
0002 : SEQUENCE
0004 : OBJECT IDENTIFIER id-ecPublicKey (1.2.840.10045.2.1)
000d : OBJECT IDENTIFIER secp256r1 (1.2.840.10045.3.1.7)
0017 : BIT STRING (66 bytes)
00000000: 0004 cb28 e099 9b9c 7715 fd0a 80d8 e47a
00000010: 7707 9716 cbbf 917d d72e 9756 6ea1 c066
00000020: 957c 2b57 c023 5fb7 4897 68d0 58ff 4911
00000030: c20f dbe7 1e36 99d9 1339 afbb 903e e172
00000040: 55dc
]]></artwork></figure>
</t>
<t>The first byte (00) of the bit string indicates that there is
no "number of unused bits", and the second byte (04) indicates
uncompressed form (<xref target='RFC5480'/>). Those two octets are
followed by the values of X and Y.</t>
<t>The final encoded SubjectPublicKeyInfo object is as follows:
<figure><artwork><![CDATA[
00000000: 3059 3013 0607 2a86 48ce 3d02 0106 082a
00000010: 8648 ce3d 0301 0703 4200 04cb 28e0 999b
00000020: 9c77 15fd 0a80 d8e4 7a77 0797 16cb bf91
00000030: 7dd7 2e97 566e a1c0 6695 7c2b 57c0 235f
00000040: b748 9768 d058 ff49 11c2 0fdb e71e 3699
00000050: d913 39af bb90 3ee1 7255 dc
]]></artwork></figure>
</t>
<t>This will result in the final IKEv2 Certificate Payload:
<figure><artwork><![CDATA[
00000000: NN00 0060 XX30 5930 1306 072a 8648 ce3d
00000010: 0201 0608 2a86 48ce 3d03 0107 0342 0004
00000020: cb28 e099 9b9c 7715 fd0a 80d8 e47a 7707
00000030: 9716 cbbf 917d d72e 9756 6ea1 c066 957c
00000040: 2b57 c023 5fb7 4897 68d0 58ff 4911 c20f
00000050: dbe7 1e36 99d9 1339 afbb 903e e172 55dc
]]></artwork></figure>
</t>
<t>Where NN is the next payload type (i.e. the type of the
payload that immediately follows this Certificate payload).</t>
<t>Note to the RFC editor / IANA, replace the XX above with the
newly allocated Raw Public Key number (in hex notation), and
remove this note.</t>
</section>
<section title='RSA Example'>
<t>This second example uses a random 1024-bit RSA key. </t>
<t>The public key is as follows:</t>
<t><list style='symbols'>
<t>Algorithm : rsaEncryption (1.2.840.113549.1.1.1)</t>
<t>Modulus n (1024 bits, decimal):
1323562071162740912417075551025599045700
3972512968992059076067098474693867078469
7654066339302927451756327389839253751712
9485277759962777278073526290329821841100
9721044682579432931952695408402169276996
5181887843758615443536914372816830537901
8976615344413864477626646564638249672329
04996914356093900776754835411</t>
<t>Modulus n (1024 bits, hexadecimal):
bc7b4347 49c7b386 00bfa84b 44f88187 9a2dda08 d1f0145a
f5806c2a ed6a6172 ff0dc3d4 cd601638 e8ca348e bdca5742
31cadc97 12e209b1 fddba58a 8c62b369 038a3d1e aa727c1f
39ae49ed 6ebc30f8 d9b52e23 385a4019 15858c59 be72f343
fb1eb87b 16ffc5ab 0f8f8fe9 f7cb3e66 3d8fe9f9 ecfa1230
66f36835 8ceaefd3</t>
<t>Exponent e (17 bits, decimal): 65537</t>
<t>Exponent e (17 bits, hexadecimal): 10001</t>
</list></t>
<t>The SubjectPublicKeyInfo ASN.1 object is as follows:
<figure><artwork><![CDATA[
0000 : SEQUENCE
0003 : SEQUENCE
0005 : OBJECT IDENTIFIER rsaEncryption (1.2.840.113549.1.1.1)
0016 : NULL
0018 : BIT STRING (141 bytes)
00000000: 0030 8189 0281 8100 bc7b 4347 49c7 b386
00000010: 00bf a84b 44f8 8187 9a2d da08 d1f0 145a
00000020: f580 6c2a ed6a 6172 ff0d c3d4 cd60 1638
00000030: e8ca 348e bdca 5742 31ca dc97 12e2 09b1
00000040: fddb a58a 8c62 b369 038a 3d1e aa72 7c1f
00000050: 39ae 49ed 6ebc 30f8 d9b5 2e23 385a 4019
00000060: 1585 8c59 be72 f343 fb1e b87b 16ff c5ab
00000070: 0f8f 8fe9 f7cb 3e66 3d8f e9f9 ecfa 1230
00000080: 66f3 6835 8cea efd3 0203 0100 01
]]></artwork></figure>
</t>
<t>The first byte (00) of the bit string indicates that there is
no "number of unused bits". Inside that bit string there is an
ASN.1 sequence having 2 integers. The second byte (30) indicates
that this is beginning of the sequence, and the next byte (81)
indicates the length does not fit in 7 bits, but requires one
byte, so the length is in the next byte (89). Then starts the
first integer with tag (02) and length (81 81). After that we
have the modulus (prefixed with 0 so it will not be a negative
number). After the modulus there follows the tag (02) and length
(03) of the exponent, and the last 3 bytes are the exponent.</t>
<t>The final encoded SubjectPublicKeyInfo object is as follows:
<figure><artwork><![CDATA[
00000000: 3081 9f30 0d06 092a 8648 86f7 0d01 0101
00000010: 0500 0381 8d00 3081 8902 8181 00bc 7b43
00000020: 4749 c7b3 8600 bfa8 4b44 f881 879a 2dda
00000030: 08d1 f014 5af5 806c 2aed 6a61 72ff 0dc3
00000040: d4cd 6016 38e8 ca34 8ebd ca57 4231 cadc
00000050: 9712 e209 b1fd dba5 8a8c 62b3 6903 8a3d
00000060: 1eaa 727c 1f39 ae49 ed6e bc30 f8d9 b52e
00000070: 2338 5a40 1915 858c 59be 72f3 43fb 1eb8
00000080: 7b16 ffc5 ab0f 8f8f e9f7 cb3e 663d 8fe9
00000090: f9ec fa12 3066 f368 358c eaef d302 0301
000000a0: 0001
]]></artwork></figure>
</t>
<t>This will result in the final IKEv2 Certificate Payload:
<figure><artwork><![CDATA[
00000000: NN00 00a7 XX30 819f 300d 0609 2a86 4886
00000010: f70d 0101 0105 0003 818d 0030 8189 0281
00000020: 8100 bc7b 4347 49c7 b386 00bf a84b 44f8
00000030: 8187 9a2d da08 d1f0 145a f580 6c2a ed6a
00000040: 6172 ff0d c3d4 cd60 1638 e8ca 348e bdca
00000050: 5742 31ca dc97 12e2 09b1 fddb a58a 8c62
00000060: b369 038a 3d1e aa72 7c1f 39ae 49ed 6ebc
00000070: 30f8 d9b5 2e23 385a 4019 1585 8c59 be72
00000080: f343 fb1e b87b 16ff c5ab 0f8f 8fe9 f7cb
00000090: 3e66 3d8f e9f9 ecfa 1230 66f3 6835 8cea
000000a0: efd3 0203 0100 01
]]></artwork></figure>
</t>
<t>Where NN is the next payload type (i.e. the type of the
payload that immediately follows this Certificate payload).</t>
<t>Note to the RFC editor / IANA, replace the XX above with the
newly allocated Raw Public Key number, and remove this note.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:56:21 |