Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)
RFC 3572
| Document | Type |
RFC
- Informational
(July 2003)
Updated by RFC 8064
Was
draft-ogura-ipv6-mapos
(int)
|
|
|---|---|---|---|
| Authors | Toshiaki Yoshida , Tsuyoshi Ogura , Mitsuru Maruyama | ||
| Last updated | 2015-10-14 | ||
| RFC stream | Independent Submission | ||
| Formats | |||
| IESG | Responsible AD | Dr. Thomas Narten | |
| Send notices to | (None) |
RFC 3572
Network Working Group J. Schaad
Request for Comments: 4211 Soaring Hawk Consulting
Obsoletes: 2511 September 2005
Category: Standards Track
Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the Certificate Request Message Format (CRMF)
syntax and semantics. This syntax is used to convey a request for a
certificate to a Certification Authority (CA), possibly via a
Registration Authority (RA), for the purposes of X.509 certificate
production. The request will typically include a public key and the
associated registration information. This document does not define a
certificate request protocol.
Schaad Standards Track [Page 1]
RFC 4211 Internet X.509 CRMF September 2005
Table Of Contents
1. Introduction and Terminology ....................................3
2. Overview ........................................................3
2.1. Changes since RFC 2511 .....................................4
3. CertReqMessage Syntax ...........................................4
4. Proof-of-Possession (POP) .......................................5
4.1. Signature Key POP ..........................................7
4.2. Key Encipherment Keys ......................................9
4.2.1. Private Key Info Content Type ......................11
4.2.2. Private Key Structures .............................12
4.2.3. Challenge-Response Guidelines ......................13
4.3. Key Agreement Keys ........................................14
4.4. Use of Password-Based MAC .................................14
5. CertRequest syntax .............................................16
6. Controls Syntax ................................................18
6.1. Registration Token Control ................................18
6.2. Authenticator Control .....................................19
6.3. Publication Information Control ...........................19
6.4. Archive Options Control ...................................21
6.5. OldCert ID Control ........................................23
6.6. Protocol Encryption Key Control ...........................23
7. RegInfo Controls ...............................................23
7.1. utf8Pairs .................................................23
7.2. certReq ...................................................24
8. Object Identifiers .............................................24
9. Security Considerations ........................................25
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
11. Acknowledgements ..............................................28
Appendix A. Use of RegInfo for Name-Value Pairs ..................29
A.1. Defined Names ............................................29
A.2. IssuerName, SubjectName, and Validity Value Encoding .....29
Appendix B. ASN.1 Structures and OIDs ............................32
Appendix C. Why do Proof-of-Possession (POP) .....................38
Schaad Standards Track [Page 2]
RFC 4211 Internet X.509 CRMF September 2005
1. Introduction and Terminology
This document describes the Certificate Request Message Format
(CRMF). A Certificate Request Message object is used within a
protocol to convey a request for a certificate to a Certification
Authority (CA), possibly via a Registration Authority (RA), for the
purposes of X.509 certificate production. The request will typically
include a public key and the associated registration information.
The certificate request object defined in this document is not a
stand-alone protocol. The information defined in this document is
designed to be used by an externally defined Certificate Request
Protocol (CRP). The referencing protocol is expected to define what
algorithms are used, and what registration information and control
structures are defined. Many of the requirements in this document
refer to the referencing Certificate Request Protocol (CRP).
Certificate requests may be submitted by an RA requesting a
certificate on behalf of a Subject, by a CA requesting a cross-
certificate from another CA, or directly by an End Entity (EE).
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document (in uppercase, as shown) are to be interpreted as
described in RFC 2119 [RFC2119].
2. Overview
Construction of a certification request involves the following steps:
a) A CertRequest object is constructed. This object may include the
public key, all or a portion of the Subject name, other requested
certificate fields, and additional control information related to
the registration process. Depending on the CRP, this information
can be specified by the Subject and potentially modified by an
RA, or specified by the RA based on knowledge of the Subject or
documentation presented by the Subject.
b) If required, a proof-of-possession (of the private key
corresponding to the public key for which a certificate is being
requested) value is calculated.
c) Additional registration information can be combined with the
proof-of-possession value and the CertRequest structure to form a
CertReqMessage. Additional registration information can be added
by both the Subject and an RA.
Schaad Standards Track [Page 3]
RFC 4211 Internet X.509 CRMF September 2005
d) The CertReqMessage is securely communicated to a CA. Specific
means of secure transport are to be specified by each CRP that
refers to this document.
2.1. Changes since RFC 2511
1. Addition of an introduction section.
2. Addition of the concept of a CRP and language relating to CRPs.
3. In section 6.2, changed regToken to authenticator.
4. Add information describing the contents of the EncryptedValue
structure.
5. Changed name and contents of OID {id-regInfo 1}.
6. Added text detailing what goes into the fields of the different
structures defined in the document.
7. Replaced Appendix A with a reference to [RFC2875]. The only
difference is that the old text specified to use subject alt name
instead of subject name if subject name was empty. This is not
possible for a CA certificate issued using PKIX. It would
however be useful to update RFC 2875 to have this fallback
position.
7. Insert Appendix C describing why POP is necessary and what some
of the different POP attacks are.
8. pop field in the CertReqMsg structure has been renamed to popo to
avoid confusion between POP and pop.
9. The use of the EncryptedValue structure has been deprecated in
favor of the EnvelopedData structure.
10. Add details on how private keys are to be structured when
encrypted.
11. Allow for POP on key agreement algorithms other than DH.
3. CertReqMessage Syntax
A certificate request message is composed of the certificate request,
an optional proof-of-possession field, and an optional registration
information field.
Schaad Standards Track [Page 4]
RFC 4211 Internet X.509 CRMF September 2005
MSB LSB
+-+-+-+-+-+-+-+-+
| | | |
|1|D(6) - D(1)|1|
| | | |
+-+-+-+-+-+-+-+-+
^ ^
| |
| EA bit (always 1)
1 (multicast)
Figure 2. Address mapping in multicasting (MAPOS version 1).
MAPOS 16:
The address field of the MAPOS 16 frame header contains the 16-bit-
wide destination HDLC address [2]. The LSB of the first octet must
always be 0 to indicate the continuation of this field, and the LSB
of the second octet must always be 1 to indicate the end of this
field. The MSB of the first octet is used to indicate whether the
frame is a unicast or a multicast frame.
In the case of an IPv6 multicast, the MSB of the first octet is 1 to
indicate that the frame is multicast. As described above, the LSB of
the first octet is 0 and the LSB of the second octet is 1. The other
13 bits of the address field must contain the lowest-order 13 bits of
the IPv6 multicast address. Figure 3 shows the address field of the
MAPOS 16 frame header in the case of an IPv6 multicast, where D(1)
through D(13) represent the lowest-order 13 bits of the IPv6
multicast address. Exceptions arise when these 13 bits are either
all zeros or all ones. In these cases, the address field should be
0xFEFD (hexadecimal).
MSB LSB
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
|1|D(13)-D(8) |0| D(7)-D(1) |1|
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^
| | |
| | +-- EA bit (always 1)
| +-- EA bit (always 0)
1 (multicast)
Figure 3. Address mapping in multicasting (MAPOS 16).
Ogura, et. al. Informational [Page 5]
RFC 3572 IPv6 over MAPOS July 2003
3. Interface Identifier
This section specifies the method of forming the interface identifier
[7].
A node that has one or more MAPOS interfaces must create one or more
EUI-64 [8] based interface identifiers. Here, it should be noted
that deriving interface identifiers from HDLC addresses of MAPOS
interfaces is undesirable for the following reasons.
1. When a node is connected to a frame switch, an HDLC address is
assigned to the interface of the node from the frame switch via
NSP [6]. (In the remainder of this document, the term "MAPOS
address" is used to refer to the address.) The value of the MAPOS
address assigned to the interface depends on the combination of
the switch number of the frame switch and the port number of the
frame switch to which the interface is connected. The switch
number is required to be unique only within a MAPOS multi-switch
environment [6]; that is, there can be frame switches that have
the same switch number in different MAPOS multi-switch environment
separated by IP routers. Therefore, the uniqueness of a MAPOS
address is guaranteed only within a MAPOS multi-switch
environment.
Furthermore, if an implementation ensures that the link between
the interface of the node and the port of the frame switch is
hot-swappable, the port number of the frame switch or the frame
switch connected to the interface of the node can be changed, so
the MAPOS address assigned to the interface can also be changed
without performing a system re-start of the node.
In short, the global uniqueness of a MAPOS address is not
guaranteed, and a MAPOS address is not a built-in address but can
be changed without performing a system re-start. Thus, if an
interface identifier were derived from a MAPOS address, it could
also be changed without a system re-start. This would not follow
the recommendation in [7].
2. In the case of a point-to-point connection between two nodes, the
same MAPOS address is assigned to each interface. Specifically,
in the case of MAPOS version 1, the assigned address is 0x03 [6],
and in the case of MAPOS 16, the assigned address is 0x0003 [2].
It is not easy to achieve link-locality of the interface
identifier in a strict manner using the same Link-layer address.
For the above reasons, nodes with MAPOS interfaces must not derive
their interface identifiers from their MAPOS addresses.
Ogura, et. al. Informational [Page 6]
RFC 3572 IPv6 over MAPOS July 2003
The following are methods of forming an interface identifier in
the order of preference. These are almost the same as the methods
described in [9] except that a MAPOS address must not be used as a
source of uniqueness when an IEEE global identifier is
unavailable.
1) If an IEEE global identifier (EUI-48 or EUI-64) is available
anywhere on the node, it should be used to construct the interface
identifier due to its uniqueness. When extracting an IEEE global
identifier from another device on the node, care should be taken
to ensure that the extracted identifier is presented in canonical
ordering [10].
The only transformation from an EUI-64 identifier is to invert the
"u" bit (universal/local bit in IEEE EUI-64 terminology). For
example, for a globally unique EUI-64 identifier as shown in
Figure 4:
MSB LSB
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
Figure 4. Globally unique EUI-64 identifier.
where "c" are the bits of the assigned company_id, "0" is the
value of the universal/local bit to indicate global scope, "g" is
the group/individual bit, and "e" are the bits of the extension
identifier, the IPv6 interface identifier would be as shown in
Figure 5. The only change is inverting the value of the
universal/local bit.
MSB LSB
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
Figure 5. IPv6 interface identifier derived from a globally unique
EUI-64 identifier.
In the case of an EUI-48 identifier, it is first converted to the
EUI-64 format by inserting two octets, with hexadecimal values of
0xFF and 0xFE, in the middle of the 48-bit MAC (between the
company_id and extension-identifier portions of the EUI-48 value).
Ogura, et. al. Informational [Page 7]
RFC 3572 IPv6 over MAPOS July 2003
For example, for a globally unique 48-bit EUI-48 identifier as
shown in Figure 6:
MSB LSB
|0 1|1 3|3 4|
|0 5|6 1|2 7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+
Figure 6. Globally unique EUI-48 identifier.
where "c" are the bits of the assigned company_id, "0" is the
value of the universal/local bit to indicate global scope, "g" is
the group/individual bit, and "e" are the bits of the extension
identifier, the IPv6 interface identifier would be as shown in
Figure 7.
MSB LSB
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee|
+----------------+----------------+----------------+----------------+
Figure 7. IPv6 interface identifier derived from a globally unique
EUI-48 identifier.
2) If an IEEE global identifier is not available, a different source
of uniqueness should be used. Suggested sources of uniqueness
include machine serial numbers, etc. MAPOS addresses must not be
used.
In this case, the "u" bit of the interface identifier must be set
to 0.
3) If a good source of uniqueness cannot be found, it is recommended
that a random number be generated. In this case the "u" bit of
the interface identifier must be set to 0.
4. Duplicate Address Detection
Immediately after the system start-up, the MAPOS address has not yet
been assigned to a MAPOS interface. The assignment is not completed
until the adjacent frame switch, or adjacent node in the case of a
point-to-point connection between two nodes, has delivered the MAPOS
address to the interface via NSP [6]. Until then, no data
transmission can be performed on the interface. Thus, a node must
Ogura, et. al. Informational [Page 8]
RFC 3572 IPv6 over MAPOS July 2003
conduct duplicate address detection [11] on all unicast addresses of
MAPOS interfaces after the MAPOS address assignment has been
completed by NSP.
5. Source/Target Link-layer Address Option
As specified in [5], the Source/Target Link-layer Address option is
one of the options included in Neighbor Discovery messages. In [5],
the length of the Source/Target Link-layer Address option field is
specified in units of 8 octets. However, in the case of MAPOS, the
length of the address field is 2 octets (MAPOS 16) or 1 octet (MAPOS
version 1)[1][2]. Thus, if the exact form of the address field is
embedded in the Link-layer Address field of the Source/Target Link-
layer Address option field, the total length of the option field is 4
octets (MAPOS 16) or 3 octets (MAPOS version 1), both of which are
shorter than 8 octets.
For the above reason, in the case of MAPOS, the Link-layer Address
field of the Source/Target Link-layer Address option must be extended
with zeros in order to extend the length of the option field to 8
octets, and the Length field must be set to 1 as shown below.
MAPOS version 1:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | All 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All 0 | Address | All 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type: 1 for Source link-layer address.
2 for Target link-layer address.
Length: 1 (in units of 8 octets).
Address: MAPOS version 1 8-bit address.
Figure 8. Format of the Source/Target Link-layer Address option
field (MAPOS version 1).
Ogura, et. al. Informational [Page 9]
RFC 3572 IPv6 over MAPOS July 2003
MAPOS 16:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | All 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-layer Address | All 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type: 1 for Source link-layer address.
2 for Target link-layer address.
Length: 1 (in units of 8 octets).
Link-layer Address: MAPOS 16 16-bit address.
Figure 9. Format of the Source/Target Link-layer Address option
field (MAPOS 16).
6. Security Considerations
In MAPOS, a link-layer address (MAPOS address) is assigned to a
network interface by a frame switch via NSP; unlike other link-layer
protocols such as Ethernet that use a built-in address on a network
interface. Security considerations derived from this are described
in 6.1 and 6.2. Because there is no link-layer security in MAPOS,
the same security considerations as those of other link-layer
protocols would be applied to other points.
6.1. Issues concerning Link-layer Addresses
6.1.1. Protection against fraudulent reception of traffic
In MAPOS, a MAPOS address is assigned by a frame switch, and it
consists of the switch number and the port number of the switch to
which the network interface is connected. (In the case of a point-
to-point connection between two nodes, a fixed address is assigned to
their network interfaces.) This brings the following advantages.
1. The value of the MAPOS address of a MAPOS network interface
indicates the location of the interface in the MAPOS network. In
other words, the value itself of the destination address of a
MAPOS frame defines the actual location of the network interface
to which the frame should be finally delivered. Therefore, as
long as MAPOS addresses of network interfaces of nodes that have
Ogura, et. al. Informational [Page 10]
RFC 3572 IPv6 over MAPOS July 2003
been connected to the network through proper administrative
process are held and frames are delivered only to those addresses,
other nodes cannot receive frames unless their network interfaces
are connected to the same ports of frame switches as those to
which network interfaces of properly administered nodes are
connected. This makes fraudulent reception of traffic difficult.
2. In the case where MAPOS addresses are not administered as
mentioned above, it is possible that a malicious node could hijack
traffic by spoofing its IPv6 address in a response to an IPv6
Neighbor Discovery. Even in this case, the node must advertise
the true MAPOS address of its network interface in the response so
that it can receive successive frames. This makes it easy to
pinpoint the location of the host.
6.1.2. Protection against improper traffic
A MAPOS frame does not have a field for including its sender's
address. Therefore, in the case where a node sends one-way improper
traffic maliciously or accidentally, there is no way to obtain the
sender's MAPOS address from the traffic and this leads to difficulty
in identifying the node (because source IP addresses might be
forged).
An effective way to alleviate the difficulty is to moderate the size
of MAPOS multi-switch environment [6]. A common approach is to
separate it using IP routers. This makes it easy to identify the
node sending improper traffic within the multi-switch environment.
To secure the environment against improper traffic from outside it,
boundary IP routers need to block it using packet filtering based on
IP layer information.
6.2. Uniqueness of Interface Identifiers
Global uniqueness of a MAPOS address is not guaranteed, and a MAPOS
address is not a built-in address but can be changed without
performing a system re-start if an implementation ensures that the
link between the network interface of the node and the port of the
frame switch is hot-swappable. Thus, an interface identifier must
not be derived from a MAPOS address in order to ensure that the
interface identifier is not changed without a system re-start.
As a consequence, in IP Version 6 over MAPOS, the existence of
network interfaces other than MAPOS that have IEEE global identifier
based addresses has great importance in creating interface
identifiers. However, it may be common for there to be no such
interfaces on a node, so a different source of uniqueness must be
used. Therefore, sufficient care should be taken to prevent
Ogura, et. al. Informational [Page 11]
RFC 3572 IPv6 over MAPOS July 2003
duplication of interface identifiers. At present, there is no
protection against duplication through accident or forgery.
7. References
[1] Murakami, K. and M. Maruyama, "MAPOS - Multiple Access protocol
over SONET/SDH Version 1", RFC 2171, June 1997.
[2] Murakami, K. and M. Maruyama, "MAPOS 16 - Multiple Access
Protocol over SONET/SDH with 16 Bit Addressing", RFC 2175, June
1997.
[3] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994.
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[6] Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -
Node Switch Protocol", RFC 2173, June 1997.
[7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[8] IEEE, "Guidelines of 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/db/oui/tutorials/EUI64.html, March
1997.
[9] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998.
[10] Narten, T. and C. Burton, "A Caution On The Canonical Ordering
Of Link-Layer Addresses", RFC 2469, December 1998.
[11] Thompson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Ogura, et. al. Informational [Page 12]
RFC 3572 IPv6 over MAPOS July 2003
8. Authors' Addresses
Tsuyoshi Ogura
NTT Network Innovation Laboratories
3-9-11, Midori-cho
Musashino-shi
Tokyo 180-8585, Japan
EMail: ogura@core.ecl.net
Mitsuru Maruyama
NTT Network Innovation Laboratories
3-9-11, Midori-cho
Musashino-shi
Tokyo 180-8585, Japan
EMail: mitsuru@core.ecl.net
Toshiaki Yoshida
Werk Mikro Systems
250-1, Mikajiri
Kumagaya
Saitama 360-0843, Japan
EMail: yoshida@peta.arch.ecl.net
Ogura, et. al. Informational [Page 13]
RFC 3572 IPv6 over MAPOS July 2003
9. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ogura, et. al. Informational [Page 14]