draft-ietf-hip-rfc6253-bis-05.txt   draft-ietf-hip-rfc6253-bis-06.txt 
Host Identity Protocol Heer Host Identity Protocol Heer
Internet-Draft Albstadt-Sigmaringen University Internet-Draft Albstadt-Sigmaringen University
Obsoletes: 6253 (if approved) Varjonen Obsoletes: 6253 (if approved) Varjonen
Updates: 7401 (if approved) University of Helsinki Updates: 7401 (if approved) University of Helsinki
Intended status: Standards Track November 3, 2015 Intended status: Standards Track December 9, 2015
Expires: May 6, 2016 Expires: June 11, 2016
Host Identity Protocol Certificates Host Identity Protocol Certificates
draft-ietf-hip-rfc6253-bis-05 draft-ietf-hip-rfc6253-bis-06
Abstract Abstract
The Certificate (CERT) parameter is a container for digital The Certificate (CERT) parameter is a container for digital
certificates. It is used for carrying these certificates in Host certificates. It is used for carrying these certificates in Host
Identity Protocol (HIP) control packets. This document specifies the Identity Protocol (HIP) control packets. This document specifies the
certificate parameter and the error signaling in case of a failed certificate parameter and the error signaling in case of a failed
verification. Additionally, this document specifies the verification. Additionally, this document specifies the
representations of Host Identity Tags in X.509 version 3 (v3). representations of Host Identity Tags in X.509 version 3 (v3).
The concrete use cases of certificates, including how certificates The concrete use cases of certificates, including how certificates
are obtained, requested, and which actions are taken upon successful are obtained, requested, and which actions are taken upon successful
or failed verification, are specific to the scenario in which the or failed verification, are specific to the scenario in which the
certificates are used. Hence, the definition of these scenario- certificates are used. Hence, the definition of these scenario-
specific aspects is left to the documents that use the CERT specific aspects is left to the documents that use the CERT
parameter. parameter.
This document extends RFC7401 and obsoletes RFC6253. This document updates RFC7401 and obsoletes RFC6253.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 6, 2016. This Internet-Draft will expire on June 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 28 skipping to change at page 2, line 28
Digital certificates bind pieces of information to a public key by Digital certificates bind pieces of information to a public key by
means of a digital signature, and thus, enable the holder of a means of a digital signature, and thus, enable the holder of a
private key to generate cryptographically verifiable statements. The private key to generate cryptographically verifiable statements. The
Host Identity Protocol (HIP) [RFC7401] defines a new cryptographic Host Identity Protocol (HIP) [RFC7401] defines a new cryptographic
namespace based on asymmetric cryptography. The identity of each namespace based on asymmetric cryptography. The identity of each
host is derived from a public key, allowing hosts to digitally sign host is derived from a public key, allowing hosts to digitally sign
data and issue certificates with their private key. This document data and issue certificates with their private key. This document
specifies the CERT parameter, which is used to transmit digital specifies the CERT parameter, which is used to transmit digital
certificates in HIP. It fills the placeholder specified in certificates in HIP. It fills the placeholder specified in
Section 5.2 of [RFC7401], and thus, extends [RFC7401]. Section 5.2 of [RFC7401], and thus, updates [RFC7401].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
2. CERT Parameter 2. CERT Parameter
skipping to change at page 3, line 13 skipping to change at page 3, line 13
SIGNATURE field and is a non-critical parameter. SIGNATURE field and is a non-critical parameter.
The CERT parameter can be used in all HIP packets. However, using it The CERT parameter can be used in all HIP packets. However, using it
in the first Initiator (I1) packet is NOT RECOMMENDED because it can in the first Initiator (I1) packet is NOT RECOMMENDED because it can
increase the processing times of I1s, which can be problematic when increase the processing times of I1s, which can be problematic when
processing storms of I1s. Each HIP control packet MAY contain processing storms of I1s. Each HIP control packet MAY contain
multiple CERT parameters. These parameters MAY be related or multiple CERT parameters. These parameters MAY be related or
unrelated. Related certificates are managed in Cert groups. A Cert unrelated. Related certificates are managed in Cert groups. A Cert
group specifies a group of related CERT parameters that SHOULD be group specifies a group of related CERT parameters that SHOULD be
interpreted in a certain order (e.g., for expressing certificate interpreted in a certain order (e.g., for expressing certificate
chains). For grouping CERT parameters, the Cert group and the Cert chains). Ungrouped certificates exhibit a unique Cert group field
count field MUST be set. Ungrouped certificates exhibit a unique and set the Cert count to 1. CERT parameters with the same Cert
Cert group field and set the Cert count to 1. CERT parameters with group number in the group field indicate a logical grouping. The
the same Cert group number in the group field indicate a logical Cert count field indicates the number of CERT parameters in the
grouping. The Cert count field indicates the number of CERT group.
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 HIP control packets. This is indicated by a in multiple sequential HIP control packets. This is indicated by a
higher Cert count than the amount of CERT parameters with matching higher Cert count than the amount of CERT parameters with matching
Cert group fields in a HIP control packet. The CERT parameters MUST Cert group fields in a HIP control packet. The CERT parameters MUST
be placed in ascending order, within a HIP control packet, according be placed in ascending order, within a HIP control packet, according
to their Cert group field. Cert groups MAY only span multiple to their Cert group field. Cert groups MAY only span multiple
packets if the Cert group does not fit the packet. A HIP packet MUST packets if the Cert group does not fit the packet. A HIP packet MUST
NOT contain more than one incomplete Cert group that continues in the NOT contain more than one incomplete Cert group that continues in the
next HIP control packet. next HIP control packet.
skipping to change at page 3, line 46 skipping to change at page 3, line 45
0 1 2 3 0 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert group | Cert count | Cert ID | Cert type | | Cert group | Cert count | Cert ID | Cert type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate / | Certificate /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding | / | Padding (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 768 Type 768
Length Length in octets, excluding Type, Length, and Padding Length Length in octets, excluding Type, Length, and Padding
Cert group Group ID grouping multiple related CERT parameters Cert group Group ID grouping multiple related CERT parameters
Cert count Total count of certificates that are sent, possibly Cert count Total count of certificates that are sent, possibly
in several consecutive HIP control packets. in several consecutive HIP control packets.
Cert ID The sequence number for this certificate Cert ID The sequence number for this certificate
Cert Type Indicates the type of the certificate Cert Type Indicates the type of the certificate
Padding Any Padding, if necessary, to make the TLV a multiple Padding Any Padding, if necessary, to make the TLV a multiple
of 8 bytes. of 8 bytes.
The certificates MUST use the algorithms defined in [RFC7401] as the The certificates MUST use the algorithms defined in [RFC7401] as the
signature and hash algorithms. signature and hash algorithms.
The following certificate types are defined: The following certificate types are defined:
skipping to change at page 6, line 30 skipping to change at page 6, line 33
------------------------------------ ----- ------------------------------------ -----
CREDENTIALS_REQUIRED 48 CREDENTIALS_REQUIRED 48
The Responder is unwilling to set up an association, The Responder is unwilling to set up an association,
as the Initiator did not send the needed credentials. as the Initiator did not send the needed credentials.
INVALID_CERTIFICATE 50 INVALID_CERTIFICATE 50
Sent in response to a failed verification of a certificate. Sent in response to a failed verification of a certificate.
Notification Data MAY contain n groups of 2 octets (n calculated Notification Data MAY contain n (n calculated from the
from the NOTIFICATION parameter length), in order Cert group and NOTIFICATION parameter length) groups of Cert group and
Cert ID of the CERT parameter that caused the failure. Cert ID octets (in this order) of the CERT parameter that
caused the failure.
6. IANA Considerations 6. IANA Considerations
As this document replaces [RFC6253], references to [RFC6253] in IANA As this document obsoletes [RFC6253], references to [RFC6253] in IANA
registries have to be replaced by references to this document. This registries have to be replaced by references to this document. This
document changes Certificate type registry in Section 2. document changes Certificate type registry in Section 2.
7. Security Considerations 7. Security Considerations
Certificate grouping allows the certificates to be sent in multiple Certificate grouping allows the certificates to be sent in multiple
consecutive packets. This might allow similar attacks, as IP-layer consecutive packets. This might allow similar attacks, as IP-layer
fragmentation allows, for example, the sending of fragments in the fragmentation allows, for example, the sending of fragments in the
wrong order and skipping some fragments to delay or stall packet wrong order and skipping some fragments to delay or stall packet
processing by the victim in order to use resources (e.g., CPU or processing by the victim in order to use resources (e.g., CPU or
memory). Hence, hosts SHOULD implement mechanisms to discard memory). Hence, hosts SHOULD implement mechanisms to discard
certificate groups with outstanding certificates if state space is certificate groups with outstanding certificates if state space is
scarce. scarce.
Although, CERT parameter is allowed in the first Initiator (I1)
packet it is NOT RECOMMENDED because it can increase the processing
times of I1s, which can be problematic when processing storms of I1s.
Furthermore, Initiator has to take into consideration that the
Responder can drop the CERT parameter in I1 without processing the
parameter.
Checking of the URL and LDAP entries might allow denial-of-service Checking of the URL and LDAP entries might allow denial-of-service
(DoS) attacks, where the target host may be subjected to bogus work. (DoS) attacks, where the target host may be subjected to bogus work.
Security considerations for X.509 v3 in [RFC5280]. Security considerations for X.509 v3 are discussed in [RFC5280].
8. Acknowledgements 8. Acknowledgements
The authors would like to thank A. Keranen, D. Mattes, M. Komu and T. The authors would like to thank A. Keranen, D. Mattes, M. Komu and T.
Henderson for the fruitful conversations on the subject. D. Mattes Henderson for the fruitful conversations on the subject. D. Mattes
most notably contributed the non-HIP aware use case in Section 3. most notably contributed the non-HIP aware use case in Section 3.
9. References 9. References
9.1. Normative References 9.1. Normative References
skipping to change at page 9, line 39 skipping to change at page 10, line 7
o Updates to contact details. o Updates to contact details.
o Correct updates and obsoletes headers. o Correct updates and obsoletes headers.
o Removed the pre5378 disclaimer. o Removed the pre5378 disclaimer.
o Updated references. o Updated references.
o Removed the SPKI references from the document. o Removed the SPKI references from the document.
Changes from version 05 to 06:
o Addressed the Int-Dir review comments from Korhonen.
Authors' Addresses Authors' Addresses
Tobias Heer Tobias Heer
Albstadt-Sigmaringen University Albstadt-Sigmaringen University
Poststr. 6 Poststr. 6
72458 Albstadt 72458 Albstadt
Germany Germany
Email: heer@hs-albsig.de Email: heer@hs-albsig.de
Samu Varjonen Samu Varjonen
University of Helsinki University of Helsinki
Gustaf Haellstroemin katu 2b Gustaf Haellstroemin katu 2b
Helsinki Helsinki
Finland Finland
Email: samu.varjonen@helsinki.fi Email: samu.varjonen@helsinki.fi
 End of changes. 15 change blocks. 
19 lines changed or deleted 31 lines changed or added

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