draft-ietf-hip-cert-00.txt   draft-ietf-hip-cert-01.txt 
Host Identity Protocol Heer Host Identity Protocol Heer
Internet-Draft Distributed Systems Group, RWTH Internet-Draft Distributed Systems Group, RWTH
Intended status: Informational Aachen University Intended status: Informational Aachen University
Expires: April 24, 2009 Varjonen Expires: January 2, 2010 Varjonen
Helsinki Institute for Information Helsinki Institute for Information
Technology Technology
October 21, 2008 July 1, 2009
HIP Certificates HIP Certificates
draft-ietf-hip-cert-00 draft-ietf-hip-cert-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may not be modified,
have been or will be disclosed, and any of which he or she becomes and derivative works of it may not be created, except to format it
aware will be disclosed, in accordance with Section 6 of BCP 79. for publication as an RFC or to translate it into languages other
This document may not be modified, and derivative works of it may not than English.
be created, except to publish it as an RFC and to translate it into
languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2009. This Internet-Draft will expire on January 2, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document specifies a certificate parameter called CERT for the This document specifies a certificate parameter called CERT for the
Host Identity Protocol (HIP). The CERT parameter is a container for Host Identity Protocol (HIP). The CERT parameter is a container for
Simple Public Key Infrastructure (SPKI) and X.509.v3 certificates. Simple Public Key Infrastructure (SPKI) and X.509.v3 certificates.
It is used for carrying these certificates in HIP control messages. It is used for carrying these certificates in HIP control messages.
Additionally, this document specifies the representations of Host Additionally, this document specifies the representations of Host
Identity Tags in SPKI and X.509.v3 certificates. Identity Tags in SPKI and X.509.v3 certificates.
skipping to change at page 2, line 35 skipping to change at page 2, line 44
The CERT parameter is a container for a certain types of digital The CERT parameter is a container for a certain types of digital
certificates. It may either carry SPKI certificates or X.509.v3 certificates. It may either carry SPKI certificates or X.509.v3
certificates. It does not specify any certificate semantics. certificates. It does not specify any certificate semantics.
However, it defines some organizational parameters that help HIP However, it defines some organizational parameters that help HIP
hosts to transmit semantically grouped parameters in a more hosts to transmit semantically grouped parameters in a more
systematic way. systematic way.
The CERT parameter may be covered by the HIP SIGNATURE field and is a The CERT parameter may be covered by the HIP SIGNATURE field and is a
non-critical parameter. non-critical parameter.
Each HIP packet may contain multiple CERT parameters. If these Each HIP packet may contain multiple CERT parameters. These
parameters must be handled in certain sequence, the Cert group and parameters may be related or unrelated. Related certificates are
the Cert count field must be set. Ungrouped certificates exhibit a managed in Cert groups. A cert group specifies a group of related
unique Cert group field and set the Cert count to 1. CERT parameters cert parameters that should be interpreted in a certain order (e.g.
with the same Cert group number in the group field indicate a logical for expressing certificate chains). For grouping Cert parameters,
grouping. The Cert count field indicates the number of grouped CERT the Cert group and the Cert count field must be set. Ungrouped
parameters. certificates exhibit a unique Cert group field and set the Cert count
to 1. CERT parameters with the same Cert group number in the group
field indicate a logical grouping. The Cert count field indicates
the number of CERT parameters in the group.
CERT parameters that belong to the same CERT group may be contained CERT parameters that belong to the same CERT group may be contained
in multiple sequential packets. This is indicated by a higher Cert in multiple sequential packets. This is indicated by a higher Cert
count than the amount of CERT parameters with matching Cert group count than the amount of CERT parameters with matching Cert group
fields in a packet. Within a HIP packet, CERT parameters must be fields in a packet. Within a HIP packet, CERT parameters must be
placed in ascending order according to their Cert group field. Cert placed in ascending order according to their Cert group field. Cert
groups may only span multiple packets if the Cert group does not fit groups may only span multiple packets if the Cert group does not fit
the packet. Only one Cert group may span two subsequent packets. the packet. Only one Cert group may span two subsequent packets.
The Cert ID acts as a sequence number to identify the certificates in The Cert ID acts as a sequence number to identify the certificates in
skipping to change at page 4, line 27 skipping to change at page 4, line 27
format for X.509.v3 is Distinguished Encoding Rules format as defined format for X.509.v3 is Distinguished Encoding Rules format as defined
in [X.690]. in [X.690].
Hash and URL encodings (3 and 4) are used as defined in [RFC4306]. Hash and URL encodings (3 and 4) are used as defined in [RFC4306].
Using hash and URL encodings results in smaller HIP control packets, Using hash and URL encodings results in smaller HIP control packets,
but requires the receiver to resolve the URL or check local cache but requires the receiver to resolve the URL or check local cache
against the hash. against the hash.
It is not recommended to use hash and URL encodings when HIP-aware It is not recommended to use hash and URL encodings when HIP-aware
middleboxes are present on the communication path between peers middleboxes are present on the communication path between peers
because fetching remote certificates requires the middlebox to buffer because fetching remote certificates require the middlebox to buffer
the packets and to request remote data. This makes these devices the packets and to request remote data. This makes these devices
prone to denial of service (DoS) attacks. Moreover, middleboxes and prone to denial of service (DoS) attacks. Moreover, middleboxes and
responders that request remote certificates can be used as deflectors responders that request remote certificates can be used as deflectors
for distributed denial of service attacks. for distributed denial of service attacks.
3. SPKI Cert Object and Host Identities 3. SPKI Cert Object and Host Identities
When using SPKI certificates to transmit information related to HIP When using SPKI certificates to transmit information related to HIP
hosts, HITs need to be enclosed within the certificates. In the hosts, HITs need to be enclosed within the certificates. In the
following we define the representation of those identifiers for SPKI following we define the representation of those identifiers for SPKI
skipping to change at page 5, line 13 skipping to change at page 5, line 13
Appendix A shows a full example SPKI certificate with HIP content. Appendix A shows a full example SPKI certificate with HIP content.
4. X.509.v3 Certificate Object and Host Identities 4. X.509.v3 Certificate Object and Host Identities
When using X.509.v3 certificates to transmit information related to When using X.509.v3 certificates to transmit information related to
HIP hosts, HITs need to be enclosed within the certificates. HITs HIP hosts, HITs need to be enclosed within the certificates. HITs
are represented as issuer and subject alternative name X.509.v3 are represented as issuer and subject alternative name X.509.v3
extensions as defined in [RFC2459]. Because the Distinguished Name extensions as defined in [RFC2459]. Because the Distinguished Name
(DN) in X.509.v3 certificate cannot be empty HITs are also placed (DN) in X.509.v3 certificate cannot be empty HITs are also placed
into the Common Name (CN) in a colon delimited presentation format. into the Common Name (CN) in a colon delimited presentation format.
Placing CN is not necessary if DN contains any other information. It
is RECOMMENDED to use FQDN/NAI from the hosts HOST_ID parameter in DN
if one exists.
As an example the HIT of a host is expressed as follows: As an example the HIT of a host is expressed as follows:
Format: Format:
Issuer: CN=hit-of-host Issuer: CN=hit-of-host
Subject: CN=hit-of-host Subject: CN=hit-of-host
X509v3 extensions: X509v3 extensions:
X509v3 Issuer Alternative Name: X509v3 Issuer Alternative Name:
IP Address:HIT-OF-HOST IP Address:HIT-OF-HOST
skipping to change at page 9, line 5 skipping to change at page 9, line 46
Signature Algorithm: sha1WithRSAEncryption Signature Algorithm: sha1WithRSAEncryption
19:32:0b:72:a8:6c:f9:65:20:5b:1d:9a:e1:c7:39:97:c7:8a: 19:32:0b:72:a8:6c:f9:65:20:5b:1d:9a:e1:c7:39:97:c7:8a:
4d:d1:01:f9:7d:0b:0d:6f:61:a2:e3:2c:62:30:28:f6:36:db: 4d:d1:01:f9:7d:0b:0d:6f:61:a2:e3:2c:62:30:28:f6:36:db:
62:bc:7f:d1:9b:6d:cc:da:e3:9b:90:e7:53:9e:55:28:51:7e: 62:bc:7f:d1:9b:6d:cc:da:e3:9b:90:e7:53:9e:55:28:51:7e:
39:de:23:24:f5:a9:97:7a:ba:ce:54:3e:cf:8b:68:04:f6:be: 39:de:23:24:f5:a9:97:7a:ba:ce:54:3e:cf:8b:68:04:f6:be:
78:94:9f:d3:20:62:96:14:84:51:af:c7:ba:30:ae:b1:d6:7e: 78:94:9f:d3:20:62:96:14:84:51:af:c7:ba:30:ae:b1:d6:7e:
7f:32:42:9c:f6:f5:76:27:0a:28:58:8b:b5:85:e7:e9:5a:ff: 7f:32:42:9c:f6:f5:76:27:0a:28:58:8b:b5:85:e7:e9:5a:ff:
aa:4c:57:55:95:09:33:ac:0b:8c:fd:05:4a:5e:60:e7:7f:d7: aa:4c:57:55:95:09:33:ac:0b:8c:fd:05:4a:5e:60:e7:7f:d7:
42:f0 42:f0
Appendix C. Change log
Changes from version 00 to 01:
o Revised text about DN usage.
o Revised text about Cert group usage.
Authors' Addresses Authors' Addresses
Tobias Heer Tobias Heer
Distributed Systems Group, RWTH Aachen University Distributed Systems Group, RWTH Aachen University
Ahornstrasse 55 Ahornstrasse 55
Aachen Aachen
Germany Germany
Phone: +49 241 80 214 36 Phone: +49 241 80 214 36
Email: heer@cs.rwth-aachem.de Email: heer@cs.rwth-aachen.de
URI: http://ds.cs.rwth-aachen.de/members/heer URI: http://ds.cs.rwth-aachen.de/members/heer
Samu Varjonen Samu Varjonen
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Metsnneidonkuja 4 Metsnneidonkuja 4
Helsinki Helsinki
Finland Finland
Fax: +35896949768 Fax: +35896949768
Email: samu.varjonen@hiit.fi Email: samu.varjonen@hiit.fi
URI: http://www.hiit.fi URI: http://www.hiit.fi
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 11 change blocks. 
20 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/