draft-ietf-hip-rfc5203-bis-03.txt   draft-ietf-hip-rfc5203-bis-04.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft Luminate Wireless, Inc. Internet-Draft Luminate Wireless, Inc.
Obsoletes: 5203 (if approved) L. Eggert Obsoletes: 5203 (if approved) L. Eggert
Intended status: Standards Track NetApp Intended status: Standards Track NetApp
Expires: June 14, 2014 December 11, 2013 Expires: July 19, 2014 January 15, 2014
Host Identity Protocol (HIP) Registration Extension Host Identity Protocol (HIP) Registration Extension
draft-ietf-hip-rfc5203-bis-03 draft-ietf-hip-rfc5203-bis-04
Abstract Abstract
This document specifies a registration mechanism for the Host This document specifies a registration mechanism for the Host
Identity Protocol (HIP) that allows hosts to register with services, Identity Protocol (HIP) that allows hosts to register with services,
such as HIP rendezvous servers or middleboxes. This document such as HIP rendezvous servers or middleboxes. This document
obsoletes RFC5203. obsoletes RFC5203.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 June 14, 2014. This Internet-Draft will expire on July 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. HIP Registration Extension Overview . . . . . . . . . . . . . 3 3. HIP Registration Extension Overview . . . . . . . . . . . . . 3
3.1. Registrar Announcing Its Ability . . . . . . . . . . . . 4 3.1. Registrar Announcing Its Ability . . . . . . . . . . . . 4
3.2. Requester Requesting Registration . . . . . . . . . . . . 4 3.2. Requester Requesting Registration . . . . . . . . . . . . 4
3.3. Registrar Granting or Refusing Service(s) Registration . 4 3.3. Registrar Granting or Refusing Service(s) Registration . 4
4. Parameter Formats and Processing . . . . . . . . . . . . . . 6 4. Parameter Formats and Processing . . . . . . . . . . . . . . 6
4.1. Encoding Registration Lifetimes with Exponents . . . . . 6 4.1. Encoding Registration Lifetimes with Exponents . . . . . 6
4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. REG_INFO . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. REG_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 7 4.4. REG_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 8
4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. REG_FAILED . . . . . . . . . . . . . . . . . . . . . . . 9
5. Establishing and Maintaining Registrations . . . . . . . . . 9 5. Establishing and Maintaining Registrations . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 12 Appendix A. Changes from RFC 5203 . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document specifies an extension to the Host Identity Protocol This document specifies an extension to the Host Identity Protocol
(HIP) [I-D.ietf-hip-rfc5201-bis]. The extension provides a generic (HIP) [I-D.ietf-hip-rfc5201-bis]. The extension provides a generic
means for a host to register with a service. The service may, for means for a host to register with a service. The service may, for
example, be a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis] or a example, be a HIP rendezvous server [I-D.ietf-hip-rfc5204-bis] or a
middlebox [RFC3234]. middlebox [RFC3234].
This document makes no further assumptions about the exact type of This document makes no further assumptions about the exact type of
skipping to change at page 4, line 35 skipping to change at page 4, line 35
packets that need to be exchanged with the registrar. A registrar packets that need to be exchanged with the registrar. A registrar
MAY end a HIP association that does not carry a REG_REQUEST by MAY end a HIP association that does not carry a REG_REQUEST by
including a NOTIFY with the type REG_REQUIRED in the R2. In this including a NOTIFY with the type REG_REQUIRED in the R2. In this
case, no HIP association is created between the hosts. The case, no HIP association is created between the hosts. The
REG_REQUIRED notification error type is 51. REG_REQUIRED notification error type is 51.
3.3. Registrar Granting or Refusing Service(s) Registration 3.3. Registrar Granting or Refusing Service(s) Registration
Once registration has been requested, the registrar is able to Once registration has been requested, the registrar is able to
authenticate the requester based on the host identity included in I2. authenticate the requester based on the host identity included in I2.
It then verifies that the host identity is authorized to register
with the requested service(s), based on local policies. The details
of this authorization procedure depend on the type of requested
service(s) and on the local policies of the registrar, and are
therefore not further specified in this document.
After authorization, the registrar includes a REG_RESPONSE parameter If the registrar knows the Host Identities (HIs) of all the hosts
in its response, which contains the service type(s) for which it has that are allowed to use the relaying service, it SHOULD reject
authorized registration, and zero or more REG_FAILED parameters registrations from unknown hosts. However, since it may be
containing the service type(s) for which it has not authorized unfeasible to pre-configure the relay with all the HIs, the relay
registration or registration has failed for other reasons. This SHOULD also support HIP certificates [I-D.ietf-hip-rfc6253-bis] to
response can be either an R2 or an UPDATE message, respectively, allow for certificate based authentication.
When a requester wants to register with a registrar, it SHOULD check
if it has a suitable certificate for authenticating with the
registrar. How the suitability is determined and how the
certificates are obtained is out of scope for this document. If the
requester has one or more suitable certificates, the host SHOULD
include them (or just the most suitable one) in a CERT parameter to
the HIP packet along with the REG_REQUEST parameter. If the
requester does not have any suitable certificates, it SHOULD send the
registration request without the CERT parameter to test whether the
registrar accepts the request based on the host's identity.
When a registrar receives a HIP packet with a REG_REQUEST parameter,
and it requires authentication for at least one of the Registration
Types listed in the REG_REQUEST parameter, it MUST first check
whether the HI of the requester is in the allowed list for all the
Registration Types in the REG_REQUEST parameter. If the requester is
in the allowed list (or the registrar does not require any
authentication), the registrar MUST proceed with the registration.
If the requester was not in the allowed list and the registrar
requires the requester to authenticate, the registrar MUST check
whether the packet also contains a CERT parameter. If the packet
does not contain a CERT parameter, the registrar MUST reject the
registrations requiring authentication with Failure Type 0
(Registration requires additional credentials). If the certificate
is valid and accepted (issued for the requester and signed by a
trusted issuer), the registrar MUST proceed with the registration.
If the certificate in the parameter is not accepted, the registrar
MUST reject the corresponding registrations with Failure Type [IANA
TBD] (Invalid certificate).
After successful authorization, the registrar includes a REG_RESPONSE
parameter in its response, which contains the service type(s) for
which it has authorized registration, and zero or more REG_FAILED
parameters containing the service type(s) for which it has not
authorized registration or registration has failed for other reasons.
This response can be either an R2 or an UPDATE message, respectively,
depending on whether the registration was requested during the base depending on whether the registration was requested during the base
exchange, or using an existing association. In particular, exchange, or using an existing association. In particular,
REG_FAILED with a failure type of zero indicates the service(s) REG_FAILED with a failure type of zero indicates the service(s)
type(s) that require further credentials for registration. type(s) that require further credentials for registration.
If the registrar requires further authorization and the requester has If the registrar requires further authorization and the requester has
additional credentials available, the requester SHOULD try to additional credentials available, the requester SHOULD try to
register again with the service after the HIP association has been register again with the service after the HIP association has been
established. The precise means of establishing and verifying established.
credentials are beyond the scope of this document and are expected to
be defined in other documents.
Successful processing of a REG_RESPONSE parameter creates Successful processing of a REG_RESPONSE parameter creates
registration state at the requester. In a similar manner, successful registration state at the requester. In a similar manner, successful
processing of a REG_REQUEST parameter creates registration state at processing of a REG_REQUEST parameter creates registration state at
the registrar and possibly at the service. Both the requester and the registrar and possibly at the service. Both the requester and
registrar can cancel a registration before it expires, if the registrar can cancel a registration before it expires, if the
services afforded by a registration are no longer needed by the services afforded by a registration are no longer needed by the
requester, or cannot be provided any longer by the registrar (for requester, or cannot be provided any longer by the registrar (for
instance, because its configuration has changed). instance, because its configuration has changed).
skipping to change at page 9, line 27 skipping to change at page 9, line 41
Length Length in octets, excluding Type, Length, and Padding. Length Length in octets, excluding Type, Length, and Padding.
Failure Type Reason for failure. Failure Type Reason for failure.
Reg Type The registration types that failed with the specified Reg Type The registration types that failed with the specified
reason. reason.
Failure Type Reason Failure Type Reason
------------ -------------------------------------------- ------------ --------------------------------------------
0 Registration requires additional credentials 0 Registration requires additional credentials
1 Registration type unavailable 1 Registration type unavailable
3 Insufficient resources 3 Insufficient resources
[TBD-IANA] Invalid certificate
3-200 Unassigned 3-200 Unassigned
201-255 Reserved by IANA for private use 201-255 Reserved by IANA for private use
Other documents will define specific values for registration types. Other documents will define specific values for registration types.
See Section 7 for more information. See Section 7 for more information.
A failure type of zero means a registrar requires additional A failure type of zero means a registrar requires additional
credentials to authorize a requester to register with the credentials to authorize a requester to register with the
registration types listed in the parameter. A failure type of one registration types listed in the parameter. A failure type of one
means that the requested service type is unavailable at the means that the requested service type is unavailable at the
skipping to change at page 12, line 12 skipping to change at page 12, line 27
Teemu Koponen co-authored an earlier, experimental version of this Teemu Koponen co-authored an earlier, experimental version of this
specification [RFC5203]. specification [RFC5203].
9. Acknowledgments 9. Acknowledgments
The following people (in alphabetical order) have provided thoughtful The following people (in alphabetical order) have provided thoughtful
and helpful discussions and/or suggestions that have helped to and helpful discussions and/or suggestions that have helped to
improve this document: Jeffrey Ahrenholz, Miriam Esteban, Ari improve this document: Jeffrey Ahrenholz, Miriam Esteban, Ari
Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig. Keranen, Mika Kousa, Pekka Nikander, and Hannes Tschofenig.
Ari Keranen suggested inclusion of the text specifying requester
authorization based on certificates as a direct adaption of text
found in HIP native NAT traversal specification
[I-D.ietf-hip-native-nat-traversal].
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-hip-rfc5201-bis] [I-D.ietf-hip-rfc5201-bis]
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf- "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
hip-rfc5201-bis-14 (work in progress), October 2013. hip-rfc5201-bis-14 (work in progress), October 2013.
[I-D.ietf-hip-rfc5204-bis] [I-D.ietf-hip-rfc5204-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rfc5204-bis-02 (work Rendezvous Extension", draft-ietf-hip-rfc5204-bis-03 (work
in progress), September 2012. in progress), December 2013.
[I-D.ietf-hip-rfc6253-bis]
Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", draft-ietf-hip-rfc6253-bis-01 (work in
progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
10.2. Informative References 10.2. Informative References
[I-D.ietf-hip-native-nat-traversal]
Keranen, A. and J. Melen, "Native NAT Traversal Mode for
the Host Identity Protocol", draft-ietf-hip-native-nat-
traversal-06 (work in progress), December 2013.
[I-D.ietf-hip-rfc4423-bis] [I-D.ietf-hip-rfc4423-bis]
Moskowitz, R. and M. Komu, "Host Identity Protocol Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", draft-ietf-hip-rfc4423-bis-06 (work in Architecture", draft-ietf-hip-rfc4423-bis-07 (work in
progress), November 2013. progress), December 2013.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002. Issues", RFC 3234, February 2002.
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity
Protocol (HIP) Registration Extension", RFC 5203, April Protocol (HIP) Registration Extension", RFC 5203, April
2008. 2008.
Appendix A. Changes from RFC 5203 Appendix A. Changes from RFC 5203
o Updated references to revised HIP specifications. o Updated references to revised HIP specifications.
o Added a new registration failure type for use in case of o Added a new registration failure type for use in case of
insufficient resources available at the HIP registrar. insufficient resources available at the HIP registrar.
o Added requester authorization based on certificates, and new
registration failure type for invalid certificate.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
Luminate Wireless, Inc. Luminate Wireless, Inc.
Cupertino, CA Cupertino, CA
USA USA
EMail: julien.ietf@gmail.com EMail: julien.ietf@gmail.com
Lars Eggert Lars Eggert
 End of changes. 16 change blocks. 
30 lines changed or deleted 80 lines changed or added

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