wdiff rfc8464.original rfc8464.txt


Network Working Group
Internet Engineering Task Force (IETF)                        R. Atarius

Intended status: Informational
Expires: December 12,
Request for Comments: 8464                                September 2018
Category: Informational
ISSN: 2070-1721

A Uniform Resource Name URN Namespace for the Device Identity and the Mobile Equipment Identity (MEID)
                   draft-atarius-dispatch-meid-urn-18

Abstract

   This document defines a Uniform Resource Name (URN) namespace for the
   Third Generation Partnership Project 2 (3GPP2) and a Namespace
   Specific String (NSS) for the Mobile Equipment Identity (MEID).  The
   structure of an MEID is 15 hexadecimal digits long and is defined in
   the Third Generation Partnership Project 2 (3GPP2) (see [S.R0048-A]) 3GPP2 to uniquely identify each individual mobile equipment
   (e.g., a handset or mobile phone).  The 3GPP2 has a requirement to be
   able to use an MEID as a URN.  This document fulfills that
   requirement.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents valid
   approved by the IESG are candidates for a maximum any level of six months Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 12, 2018.
   https://www.rfc-editor.org/info/rfc8464.

Copyright Notice

   Copyright (c) 2018 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Namespace Registration Template . . . . . . . . . . . . . . .   4
     3.1.  Namespace ID  . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Version . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Date  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.4.  Registrant  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.5.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.6.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.7.  Assignment  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.8.  Security IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and Privacy  . . . . . . . . . . . . . . . . . .   5
     3.9.  Interoperability  . . . . . . . . . . . . . . . . . . restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . .   5
     3.10. Resolution . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology .   6
     3.11. Documentation . . . . . . . . . . . . . . . . . . . . . .   6
     3.12. Additional Information: . .   3
   3.  Namespace Registration Template . . . . . . . . . . . . . . .   6   4
   4.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  MEID Parameters . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  MEID Format . . . . . . . . . . . . . . . . . . . . . . .   7   6
       4.2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .   7   6
       4.2.2.  Manufacturer Code . . . . . . . . . . . . . . . . . .   7   6
       4.2.3.  Serial Number . . . . . . . . . . . . . . . . . . . .   7
       4.2.4.  Check Digit . . . . . . . . . . . . . . . . . . . . .   7
       4.2.5.  Hexadecimal Encoding  . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8   7
   6.  Security and Privacy Considerations . . . . . . . . . . . . .   8
   7.  Acknowledgements  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   8.
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . .  10
   Acknowledgements  . . . . . . .   9
     8.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11  10

1.  Introduction

   A single mode 3GPP mobile

   Mobile equipment which uses that is either a) single-mode 3GPP using only 3GPP
   technology to transmit and receive voice or data, data or a dual mode b) dual-mode
   3GPP/3GPP2
   mobile equipment which uses using either 3GPP or 3GPP2 technology to transmit and
   receive voice or data has an International Mobile station Equipment
   Identity (IMEI) to identify the mobile equipment. it.  A URN Namespace namespace and an NSS for the
   IMEI are defined in [RFC7254].  For cases where the mobile equipment
   uses IMEI as an identity for
   dual mode dual-mode 3GPP/3GPP2 access access, the IMEI urn
   URN as defined in [RFC7254] can be used to identify the mobile
   equipment.

   However, single mode single-mode 3GPP2 mobile equipment which that supports only 3GPP2
   access technology to transmit and receive voice or data has a
   hexadecimal MEID.  Since there are fundamental differences between
   MEID and IMEI, i.e. IMEI (i.e., in encoding, format format, and the ownership, ownership),
   [RFC7254] cannot be employed to represent the hexadecimal MEID.

   This document specifies a URN namespace for 3GPP2 and an NSS for the
   MEID as per the namespace registration requirement in [RFC8141].  The
   structure of an MEID is 15 hexadecimal encoded digits long and is defined by
   3GPP2 (see [S.R0048-A]) to uniquely identify each individual piece of
   mobile equipment (e.g., a handset or mobile phone).  The 3GPP2 has a
   requirement to be able to use an MEID as a URN.  This document
   fulfills that requirement.  The Namespace Identifier (NID) '3gpp2' is
   for identities used in 3GPP2 networks.  The MEID is managed by the
   3GPP2, so this NID is managed by the 3GPP2.  This specification
   defines only NSSs constructed from MEIDs under the '3gpp2' NID.
   These NSSs start with "meid:" in order to identify them as such.  Additional  In
   the future, the 3GPP2 may specify other types of NSS NSSs under the
   '3gpp2' NID may be
   specified in the future by the 3GPP2 via additional specifications. NID.

   The MEID is 15 hexadecimal digits long and long, includes a manufacturer code
   of 8 hexadecimal digits digits, and includes the serial number of 6
   hexadecimal digits plus a hexadecimal digit as a check digit.

   The manufacturer code identifies the mobile equipment manufacturer.
   A manufacturer can be assigned more than one manufacturer code.  The
   serial number uniquely identifies each piece of mobile equipment
   within the manufacturer code.  The check digit is used as assurance
   of integrity in error-prone operations, e.g. e.g., when used with certain
   types of readers during inventory management inventory-management operations.  The check
   digit is not transmitted.  Therefore  Therefore, the first 14 of the 15 dexadecimal
   hexadecimal digits are used for defining the MEID as a URN.

   The information here is meant to be a concise guide for those wishing
   to use the hexadecimal MEID as a URN.  Nothing in this document
   should be construed to override [S.R0048-A] that [S.R0048-A], which defines the MEID.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Namespace Registration Template

   A completed namespace registration follows.

3.1.

   Namespace ID Identifier:  '3gpp2' requested

3.2.  Version

   Version:  1

3.3.  Date

   Date:  2018-06-10

3.4.  Registrant

   Registrant:
      Standards Organization: Third Generation Partnership Project 2
      (3GPP2)

      Contact:

      John Derr, MEID Global Hexadecimal Administrator,
      JDerr@tiaonline.org

      Gary Pellegrino, TIA TR-45 EUMAG Chair, gary@commflowresources.com
      c/o Telecommunications Industry Association
      1320 N.  Courthouse Rd., Suite 200
      Arlington, Virginia 22201 USA

3.5.  Purpose 22201, United States of America

   Purpose:  The '3gpp2' namespace is used to identify mobile equipment which
      that uses technologies defined by the Third Generation Partnership
      Project 2 ((3GPP2); initially initially, such equipment is identified by a
      URN that embeds a Mobile Equipment Identity (MEID) that is 15
      hexadecimal digits long and unique to each individual piece of
      mobile equipment (e.g., a handset or mobile phone).

3.6.  Syntax

   Syntax:  The identifier is expressed in American Standard Code for
      Information Interchange (ASCII) characters and has a hierarchical
      expression using the Augmented Backus-Naur Form (ABNF) defined in
      [RFC5234], as follows:

      pp2-urn              = "urn:" pp2-NID ":" pp2-NSS
      pp2-NID              = "3gpp2"
      pp2-NSS              = meid-specifier / future-pp2-specifier
      meid-specifier       = "meid:" meidval
      future-pp2-specifier = future-specifier *[ ":" 1*( pchar / "/" ] )]
      future-specifier     = 1*pp2-char
      pp2-char             = ALPHA / DIGIT / "-" / "." / "_" /
                             pct-encoded

      where 'pchar' and 'pct-encoded' are defined in [RFC3986].  An NSS
      for the MEID is defined under the '3gpp2' NID.  The representation
      of the MEID is a specific number of hexadecimal digits, as
      described in [S.R0048-A].  The formal definition of a URN with
      'meid' NSS contains one meidval with the formal definition
      according to the following ABNF [RFC5234]:

      meidval           = Manufacturer-Code "-" Serial-Number
      Manufacturer-Code = 8HEX
      Serial-Number     = 6HEX
      HEX               = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

3.7.  Assignment

   Assignment:  The Manufacturer Code manufacturer code and Serial Number serial number portions of the
      MEID are permanently stored in the mobile equipment equipment, so they
      remain persistent as long as the mobile equipment exists.  The
      process for Manufacturer
   Code manufacturer code and Serial Number serial number assignment is
      documented in [SC.R4002-0] and the Manufacturer Code manufacturer code and Serial Number serial
      number values once assigned are not
   re-assigned reassigned to other pieces of
      mobile equipments. equipment.

      Identifiers in the '3gpp2' namespace are defined and assigned by
      the 3GPP2 or an agency appointed by 3GPP2 after ensuring that the
      URNs to be assigned are unique.  Procedures are in place to ensure
      that each MEID is uniquely assigned by the mobile equipment
      manufacturer so that it is guaranteed to uniquely identify that
      particular piece of mobile equipment.

3.8.

   Security and Privacy Privacy:  See Section 8 6 of RFC XXXX.

3.9.  Interoperability 8464.

   Interoperability:  Although both the 3GPP2 Mobile Equipment Identity
      (MEID) and the 3GPP International Mobile station Equipment
      Identity (IMEI) are used to
   identity identify mobile equipment, they are
      separate identifiers and are not to be confused.
      Internet implementations will not generally possess MEID
      identifiers.  The identifiers generated by such implementations
      will typically be URNs within namespaces other than '3gpp2', and
      may, depending on context, even be non-URN URIs.  Implementations
      are advised to be ready to process URIs other than '3gpp2' namespaced
      namespace URNs, so as to aid in interoperability.

3.10.  Resolution

   Resolution:  No resolution is envisioned.

3.11.  Documentation

   Documentation:  Documentation can be found in the following
      specifications:

   o  A Uniform Resource Name

      *  "A URN Namespace for the Device Identity and the Mobile Equipment
         Identity (MEID)" [RFC XXXX].

   o  3G [RFC8464].

      *  "3G Mobile Equipment Identifier (MEID) - Stage 1" [S.R0048-A].

   o  GHA

      *  "GHA (Global Hexadecimal Administrator) Assignment Guidelines
         and Procedures for Mobile Equipment Identifier (MEID) and Short
         Form Expanded UIM Identifier (SF_EUIMID) (SF_EUIMID)" [SC.R4002-0].

3.12.

   Additional Information:  Because the syntax of a 3GPP2 Mobile
      Equipment Identity (MEID) differs from that of a 3GPP
      International Mobile station Equipment Identity (IMEI), reuse of
      the URN specified in RFC 7254 is not possible.

   Revision Information:  N/A

4.  Specification

4.1.  MEID Parameters

   Any future change to the format of the 'meid' NSS requires the use of
   the procedure for URN NSS changes (currently through the publication
   of a future Informational RFCs RFC approved by IETF consensus).

   [draft-atarius-dispatch-meid-urn-as-instanceid]

   [RFC8465] specifies how the MEID URN can be used as an instance Instance ID as
   specified in [RFC5626].  Any change to the instance ID, Instance ID will require
   an update to
   [draft-atarius-dispatch-meid-urn-as-instanceid]. [RFC8465].  An example of 3GPP2 MEID URN is:

   urn:3gpp2:meid:A04B0D56-02A7E3

4.2.  MEID Format

4.2.1.  Overview

   The MEID format is 15 hexadecimal digits encoded in 8 octets as
   defined in [S.R0048-A].  The first eight 8 hexadecimal digits constitute
   the manufacturer code, code; the next six 6 hexadecimal digits the serial
   number within the manufacturer code.  The last hexadecimal digit is a
   check digit.  For more details on the hexadecimal encoding
   c.f. encoding, see
   Section 4.2.5.

4.2.2.  Manufacturer Code

   The manufacturer code is an a value of 8 hexadecimal digit value. digits.  The
   manufacturer code identifies the mobile equipment manufacturer.  The
   manufacturer code is chosen from a range of values allocated to the
   mobile equipment manufacturer in order to uniquely identify the
   mobile equipment.

4.2.3.  Serial Number

   The serial number is a value of 6 hexadecimal digit value. digits.  The serial
   number identifies equipment within the manufacturer code.

4.2.4.  Check Digit

   This is a single hexadecimal digit (bits 1-4 of octet 8) 8), and it is
   used as assurance of integrity in error-prone operations, e.g. e.g., when
   used with certain types of readers during inventory management
   operations.  The check digit is not transmitted by the mobile
   equipment and are is not used in the MEID URN.

4.2.5.  Hexadecimal Encoding

   The MEID format is 15 hexadecimal digits encoded in 8 octets as
   defined in [S.R0048-A].  The following figure is an abstract
   representation of a hexadecimal encoded hexadecimal-encoded MEID stored in memory (the
   actual storage format in memory is implementation specific).  In this
   figure, the most significant digit of the Manufacturer Code manufacturer code is
   encoded in the bits 1-4 of octet 1.  Bits 5-8 of octet 8 are zero-
   padded, zero-padded,
   since the bits 1-4 are only needed to encode the Check Digit. check digit.  The most
   significant digit of the Serial Number serial number is encoded in the bits 1-4 of
   octet 5.  When MEID is included in a cellular signaling message, the Check Digit
   check digit is omitted and the first 7 Octets in the following figure
   are only transmitted, [X.S0008-A].

       14 13 12 11 10  9  8  7  6  5  4  3  2  1  0  Hexadecimal
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+    Digits
      |                       |                 |  |
      |                       |                 |  |
      |   Manufacturer Code   |  Serial Number  |CD|
      |                       |                 |  |
      |                       |                 |  |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         1     2     3     4     5     6     7     8  Octets

5.  IANA Considerations

   In accordance with BCP 66 [RFC8141], IANA is asked to register has registered the Formal
   URN namespace '3gpp2' in the "Uniform Resource Name (URN) Namespaces"
   registry, using the registration template presented in Section 3 of this document. 3.

6.  Security and Privacy Considerations

   An MEID is usually printed outside of the box, box in which a mobile
   device ships
   in. ships.  The MEID may also be printed under the battery on a
   mobile
   device, however device; however, very few devices have removable batteries
   today.  One can retrieve the MEID via either settings or by dialing
   *#06#.  Anyone with brief physical access to the mobile device or its
   box can
   therefore easily obtain the MEID.  Therefore  Therefore, MEIDs MUST NOT be used as
   security capabilities (identifiers whose mere possession grants
   access).  Unfortunately  Unfortunately, there are currently examples of some
   applications which that are using the MEID for authorization.  Also  Also, some
   service providers' customer service departments have been known to
   use knowledge of the MEID as "proof" that the caller is the
   legitimate owner of the mobile device.  Both of these are
   inappropriate uses of the MEID.

   Since the MEID is permanently assigned to the mobile equipment and is
   not modified when the ownership of the mobile equipment changes, changes (even
   upon a complete software reload of the mobile equipment), the MEID
   URN MUST NOT be used as a user identifier or user address by an
   application.  Using the MEID to identify a user or as a user address
   could result in communications destined for a previous owner of a
   device being received by the new device owner or could allow the new
   device owner to access information or services owned by the previous
   device owner.

   Additionally, since the MEID identifies the mobile equipment, it
   potentially could be used to identify and track users for the
   purposes of surveillance and call data mining if sent in the clear.

   Since the MEID is personally identifiable information, uses of the
   MEID URN with IETF protocols require a specification and IETF expert
   review [RFC5226] [RFC8126] in order to ensure that the privacy concerns are
   appropriately addressed.  Protocols carrying the MEID URN SHOULD SHOULD, at
   a
   minimum minimum, use strongly hop-by-hop encrypted channels channels, and that it is
   RECOMMENDED that end-to-end encryption is be used.

7.  Acknowledgements

   This document draws heavily on the 3GPP2 work on Numbering,
   Addressing and Identification in [S.R0048-A] and also on the style
   and structure used in [RFC7254] and [RFC4122].

   The author thanks for the detailed comments, provided by Ramachandran
   Subramanian, Alex Gogic, Randall Gellens, and Peter Saint-Andre.

8.  References

8.1.

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              DOI 10.17487/RFC4122, July 2005,
              <https://www.rfc-editor.org/info/rfc4122>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https://www.rfc-editor.org/info/rfc5226>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5626]  Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
              "Managing Client-Initiated Connections in the Session
              Initiation Protocol (SIP)", RFC 5626,
              DOI 10.17487/RFC5626, October 2009,
              <https://www.rfc-editor.org/info/rfc5626>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
              (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
              <https://www.rfc-editor.org/info/rfc8141>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [S.R0048-A]
              3GPP2, "S.R0048-A: 3G "3G Mobile Equipment Identifier (MEID) - Stage 1,
              Version 4.0", 3GPP2 TS S.R0048-A Stage 1, Version 4.0, 3GPP2 S.R0048-A, June
              2005,
              <http://www.3gpp2.org/Public_html/Specs/ <http://www.3gpp2.org/Public_html/specs/
              S.R0048-A_v4.0_050630.pdf>.

   [SC.R4002-0]
              3GPP2, "SC.R4002-0: GHA "GHA (Global Hexadecimal Administrator) Assignment
              Guidelines and Procedures for Mobile Equipment Identifier
              (MEID) and Short Form Expanded UIM Identifier
              (SF_EUIMID), Version 12.0",
              (SF_EUIMID)", 3GPP2 TS SC.R4002-0 10.0, SC.R4002-0, Version 12.0, December 2013, <http://www.3gpp2.org/Public_html/Specs/SC.
              R4002-0_v12.0_GHA_%20Guidelines_for_MEID_December_2016.pdf
              >.
              2016, <http://www.3gpp2.org/Public_html/Specs/SC.R4002-0_v
              12.0_GHA_%20Guidelines_for_MEID_December_2016.pdf>.

   [X.S0008-A]
              3GPP2, "X.S0008-A: MAP "MAP Support for the Mobile Equipment Identity (MEID), Version 2.0",
              (MEID)", 3GPP2 TS X.S0008-A X.S0008-A, Version 2.0, March 2014,
              <http://www.3gpp2.org/Public_html/Specs/
              X.S0008-A_v2.0_20140321.PDF>.

8.2.

7.2.  Informative References

   [draft-atarius-dispatch-meid-urn-as-instanceid]
              Atarius, R., "Using the Mobile Equipment Identity (MEID)
              Uniform Resource Name (URN) as an Instance ID", Internet
              Draft draft-atarius-dispatch-meid-urn-as-instanceid, March
              2018.

   [RFC7254]  Montemurro, M., Ed., Allen, A., McDonald, D., and P.
              Gosden, P., "A Uniform Resource Name Namespace for the Global
              System for Mobile Communications Association (GSMA) and
              the International Mobile station Equipment Identity
              (IMEI)",
              Internet Draft RFC7254, RFC 7254, DOI 10.17487/RFC7254, May 2014. 2014,
              <https://www.rfc-editor.org/info/rfc7254>.

   [RFC8465]  Atarius, R., Ed., "Using the Mobile Equipment Identity
              (MEID) URN as an Instance ID", RFC 8465,
              DOI 10.17487/RFC8465, September 2018,
              <https://www.rfc-editor.org/info/rfc8465>.

Acknowledgements

   This document draws heavily on the 3GPP2 work on Numbering,
   Addressing, and Identification in [S.R0048-A] and also on the style
   and structure used in [RFC7254] and [RFC4122].

   The author thanks Ramachandran Subramanian, Alex Gogic, Randall
   Gellens, and Peter Saint-Andre for detailed comments.

Author's Address

   Roozbeh Atarius

   Email: ratarius@motorola.com