tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8120

Experimental
Pages: 53
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: HTTPAUTH

Mutual Authentication Protocol for HTTP

Part 1 of 3, p. 1 to 15
None       Next Section

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                           Y. Oiwa
Request for Comments: 8120                                   H. Watanabe
Category: Experimental                                         H. Takagi
ISSN: 2070-1721                                               ITRI, AIST
                                                                K. Maeda
                                                  Individual Contributor
                                                              T. Hayashi
                                                                 Lepidum
                                                                 Y. Ioku
                                                  Individual Contributor
                                                              April 2017


                Mutual Authentication Protocol for HTTP

Abstract

   This document specifies an authentication scheme for the Hypertext
   Transfer Protocol (HTTP) that is referred to as either the Mutual
   authentication scheme or the Mutual authentication protocol.  This
   scheme provides true mutual authentication between an HTTP client and
   an HTTP server using password-based authentication.  Unlike the Basic
   and Digest authentication schemes, the Mutual authentication scheme
   specified in this document assures the user that the server truly
   knows the user's encrypted password.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  It represents the consensus of the IETF
   community.  It has received public review and has been approved for
   publication by the Internet Engineering Steering Group (IESG).  Not
   all documents approved by the IESG are a candidate for any level of
   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 obtained at
   http://www.rfc-editor.org/info/rfc8120.

[Page 2] 
Copyright Notice

   Copyright (c) 2017 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
   (http://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 ....................................................3
      1.1. Terminology ................................................5
      1.2. Document Structure and Related Documents ...................6
   2. Protocol Overview ...............................................6
      2.1. Messages ...................................................7
      2.2. Typical Flows of the Protocol ..............................8
      2.3. Alternative Flows .........................................10
   3. Message Syntax .................................................12
      3.1. Non-ASCII Extended Header Parameters ......................12
      3.2. Values ....................................................13
           3.2.1. Tokens .............................................13
           3.2.2. Strings ............................................14
           3.2.3. Numbers ............................................14
   4. Messages .......................................................15
      4.1. 401-INIT and 401-STALE ....................................16
      4.2. req-KEX-C1 ................................................19
      4.3. 401-KEX-S1 ................................................19
      4.4. req-VFY-C .................................................20
      4.5. 200-VFY-S .................................................21
   5. Authentication Realms ..........................................21
      5.1. Resolving Ambiguities .....................................23
   6. Session Management .............................................24
   7. Host Validation Methods ........................................26
      7.1. Applicability Notes .......................................27
      7.2. Notes on "tls-unique" .....................................28
   8. Authentication Extensions ......................................28
   9. String Preparation .............................................29
   10. Decision Procedure for Clients ................................29
      10.1. General Principles and Requirements ......................29
      10.2. State Machine for the Client (Informative) ...............31

Top      ToC       Page 3 
   11. Decision Procedure for Servers ................................36
   12. Authentication Algorithms .....................................39
      12.1. Support Functions and Notations ..........................39
      12.2. Default Functions for Algorithms .........................41
   13. Application Channel Binding ...................................42
   14. Application for Proxy Authentication ..........................42
   15. Methods to Extend This Protocol ...............................43
   16. IANA Considerations ...........................................44
      16.1. Addition to HTTP Authentication Schemes Registry .........44
      16.2. Registry for Authentication Algorithms ...................44
      16.3. Registry for Validation Methods ..........................45
   17. Security Considerations .......................................46
      17.1. Security Properties ......................................46
      17.2. Secrecy of Credentials ...................................46
      17.3. Denial-of-Service Attacks on Servers .....................47
           17.3.1. Online Active Password Attacks ....................47
      17.4. Communicating the Status of Mutual Authentication
            with Users ...............................................48
      17.5. Implementation Considerations ............................48
      17.6. Usage Considerations .....................................49
   18. References ....................................................49
      18.1. Normative References .....................................49
      18.2. Informative References ...................................51
   Authors' Addresses ................................................53

1.  Introduction

   This document specifies an authentication scheme for the Hypertext
   Transfer Protocol (HTTP) that is referred to as either the Mutual
   authentication scheme or the Mutual authentication protocol.  This
   scheme provides true mutual authentication between an HTTP client and
   an HTTP server using just a simple password as a credential.

   Password-stealing attacks are one of the most critical threats for
   Web systems.  Plain-text password authentication techniques (Basic
   authentication and Web-form-based authentication) have been widely
   used for a long time.  When these techniques are used with plain HTTP
   protocols, it is trivially easy for attackers to sniff the password
   credentials on the wire.

   The Digest authentication scheme [RFC7616] uses SHA-256 and
   SHA-512/256 (formerly SHA-1 and MD5) hash algorithms to hide the raw
   user password from network sniffers.  However, if the number of
   possible candidate users' passwords is not enough, newer and more
   powerful computers can compute possible hash values for billions of
   password candidates and compare these with the sniffed values to find
   out the correct password.  This kind of attack is called an offline
   password dictionary attack; the search capacity of these newer

Top      ToC       Page 4 
   computers reduces the effectiveness of users' memorable passwords,
   thereby threatening the effectiveness of such hash-based password
   protections.

   Transport Layer Security (TLS) [RFC5246] provides strong
   cryptographic protection against the network-based sniffing of
   passwords and other communication contents.  If TLS is correctly used
   by both server operators and client users, passwords and other
   credentials will not be available to any outside attackers.  However,
   there is a pitfall related to TLS deployment on Web systems: if the
   users are fraudulently routed to a "wrong Website" via some kind of
   social engineering attack (e.g., phishing) and tricked into
   performing authentication on that site, the credentials will be sent
   to the attacker's server and trivially leaked.  Attacks such as
   phishing have become a serious threat.  In current Web system
   deployments, TLS certificates will be issued to almost any users of
   the Internet (including malicious attackers).  Although those
   certificates include several levels of the "validation results" (such
   as corporate names) of the issued entities, the task of "checking"
   those validation results is left to the users of Web browsers, still
   leaving open the possibility of such social engineering attacks.

   Another way to avoid such threats is to avoid password-based
   authentication and use some kinds of pre-deployed strong secret keys
   (on either the client side or the server side) for authentications.
   Several federated authentication frameworks, as well as HTTP
   Origin-Bound Authentication (HOBA) [RFC7486], are proposed and
   deployed on real Web systems to satisfy those needs.  However, a type
   of authentication based on "human-memorable secrets" (i.e.,
   passwords) is still required in several scenarios, such as
   initialization, key deployment to new clients, or recovery of secret
   accounts with lost cryptographic keys.

   The Mutual authentication protocol, as proposed in this document, is
   a strong cryptographic solution for password authentications.  It
   mainly provides the following two key features:

   o  No password information at all is exchanged in the communications.
      When the server and the user fail to authenticate with each other,
      the protocol will not reveal even the tiniest bit of information
      about the user's password.  This prevents any kind of offline
      password dictionary attacks, even with the existence of phishing
      attacks.

   o  To successfully authenticate, the server, as well as client users,
      must own the valid registered credentials (authentication secret).
      This means that a phishing attacker cannot trick users into
      thinking that it is an "authentic" server.  (It should be

Top      ToC       Page 5 
      pointed out that this is not true for Basic and Digest
      authentication; for example, servers using Basic authentication
      can answer "YES" to any clients without actually checking
      authentication at all.)  Client users can ascertain whether or not
      the communicating peer is truly "the server" that registered their
      account beforehand.  In other words, it provides "true" mutual
      authentication between servers and clients.

   Given the information above, the proposed protocol can serve as a
   strong alternative to the Basic, Digest, and Web-form-based
   authentication schemes and also as a strong companion to the
   non-password-based authentication frameworks.

   The proposed protocol will serve in the same way as does existing
   Basic or Digest authentication: it meets the requirements for new
   authentication schemes for HTTP, as described in Section 5.1.2 of
   [RFC7235].  Additionally, to communicate authentication results more
   reliably between the server and the client user, it suggests that Web
   browsers have some "secure" way of displaying the authentication
   results.  Having such a user interface in future browsers will
   greatly reduce the risk of impersonation by various kinds of social
   engineering attacks, in a manner similar to that of the
   "green padlock" for Extended Validation TLS certificates.

   Technically, the authentication scheme proposed in this document is a
   general framework for using password-based authenticated key exchange
   (PAKE) and similar stronger cryptographic primitives with HTTP.  The
   two key features shown above correspond to the nature of PAKE.

1.1.  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].

   This document distinguishes the terms "client" and "user" in the
   following way: a "client" is an entity that understands and
   implements HTTP and the specified authentication protocol -- usually
   computer software; a "user" is typically a human being who wants to
   access data resources using a "client".

   The term "natural numbers" refers to the non-negative integers
   (including zero) throughout this document.

Top      ToC       Page 6 
   This document treats both the input (domain) and the output
   (codomain) of hash functions as octet strings.  When a natural number
   output for a hash function is required, it will be written as
   INT(H(s)).

1.2.  Document Structure and Related Documents

   The entire document is organized as follows:

   o  Section 2 presents an overview of the protocol design.

   o  Sections 3 through 11 define a general framework of the Mutual
      authentication protocol.  This framework is independent of
      specific cryptographic primitives.

   o  Section 12 describes properties needed for cryptographic
      algorithms used with this protocol framework and defines a few
      functions that will be shared among such cryptographic algorithms.

   o  Sections 13 through 15 contain general normative and informative
      information about the protocol.

   o  Sections 16 and 17 describe IANA considerations and security
      considerations, respectively.

   In addition, we will refer to the following two companion documents,
   as they are related to this specification:

   o  [RFC8121] defines cryptographic primitives that can be used with
      this protocol framework.

   o  [RFC8053] defines small but useful extensions to the current HTTP
      authentication framework so that it can support application-level
      semantics of existing Web systems.

2.  Protocol Overview

   The protocol, as a whole, is designed as a natural extension to HTTP
   [RFC7230] and uses the framework defined in [RFC7235].  Internally,
   the server and the client will first perform a cryptographic key
   exchange, using the secret password as a "tweak" to the exchange.
   The key exchange will only succeed when the secrets used by both
   peers are correctly related (i.e., generated from the same password).
   Then, both peers will verify the authentication results by confirming
   the sharing of the exchanged key.  This section provides a brief
   outline of the protocol and the exchanged messages.

Top      ToC       Page 7 
2.1.  Messages

   The authentication protocol uses six kinds of messages to perform
   mutual authentication.  These messages have specific names within
   this specification.

   o  Authentication request messages: used by the servers to request
      that clients start mutual authentication.

      *  401-INIT message: a general message to start the authentication
         protocol.  It is also used as a message indicating an
         authentication failure.

      *  401-STALE message: a message indicating that the client has to
         start a new key exchange.

   o  Authenticated key exchange messages: used by both peers to perform
      authentication and the sharing of a cryptographic secret.

      *  req-KEX-C1 message: a message sent from the client.

      *  401-KEX-S1 message: an intermediate response to a req-KEX-C1
         message from the server.

   o  Authentication verification messages: used by both peers to verify
      the authentication results.

      *  req-VFY-C message: a message used by the client to request that
         the server authenticate and authorize the client.

      *  200-VFY-S message: a response used by the server to indicate
         that client authentication succeeded.  It also contains
         information necessary for the client to check the authenticity
         of the server.

   In addition to the above six kinds of messages, a request or response
   without any HTTP headers related to this specification will be
   hereafter called a "normal request" or "normal response",
   respectively.

Top      ToC       Page 8 
2.2.  Typical Flows of the Protocol

   In typical cases, client access to a resource protected by the
   Mutual authentication scheme will use the following protocol
   sequence:

          Client                                 Server
            |                                      |
            |  ---- (1) normal request --------->  |
        GET / HTTP/1.1                             |
            |                                      |
            |  <---------------- (2) 401-INIT ---  |
            |            401 Unauthorized          |
            |            WWW-Authenticate: Mutual realm="a realm"
            |                                      |
   [user,   |                                      |
    pass]-->|                                      |
            |  ---- (3) req-KEX-C1 ------------->  |
        GET / HTTP/1.1                             |
        Authorization: Mutual user="john",         |--> [user DB]
                       kc1="...", ...              |<-- [user info]
            |                                      |
            |  <-------------- (4) 401-KEX-S1 ---  |
            |           401 Unauthorized           |
            |           WWW-Authenticate: Mutual sid=..., ks1="...", ...
            |                                      |
        [compute] (5) compute session secret   [compute]
            |                                      |
            |                                      |
            |  ---- (6) req-VFY-C -------------->  |
        GET / HTTP/1.1                             |--> [verify (6)]
        Authorization: Mutual sid=...,             |<-- OK
                       vkc="...", ...              |
            |                                      |
            |  <--------------- (7) 200-VFY-S ---  |
   [verify  |           200 OK                     |
     (7)]<--|           Authentication-Info: Mutual vks="..."
            |                                      |
            v                                      v

     Figure 1: Typical Communication Flow for First Access to Resource

   o  As is typical in general HTTP protocol designs, a client will at
      first request a resource without any authentication attempt (1).
      If the requested resource is protected by the Mutual
      authentication protocol, the server will respond with a message
      requesting authentication (401-INIT) (2).

Top      ToC       Page 9 
   o  The client processes the body of the message and waits for the
      user to input the username and password.  If the username and
      password are available, the client will send a message with the
      authenticated key exchange (req-KEX-C1) to start the
      authentication (3).

   o  If the server has received a req-KEX-C1 message, the server
      looks up the user's authentication information within its user
      database.  Then, the server creates a new session identifier (sid)
      that will be used to identify sets of the messages that follow it
      and responds with a message containing a server-side authenticated
      key exchange value (401-KEX-S1) (4).

   o  At this point (5), both peers calculate a shared "session secret"
      using the exchanged values in the key exchange messages.  Only
      when both the server and the client have used secret credentials
      generated from the same password will the session secret values
      match.  This session secret will be used for access authentication
      of every individual request/response pair after this point.

   o  The client will send a request with a client-side authentication
      verification value (req-VFY-C) (6), calculated from the
      client-generated session secret.  The server will check the
      validity of the verification value using its own version of the
      session secret.

   o  If the authentication verification value from the client was
      correct, then the client definitely owns the credential based on
      the expected password (i.e., the client authentication succeeded).
      The server will respond with a successful message (200-VFY-S) (7).
      Unlike the usual one-way authentication (e.g., HTTP Basic
      authentication or POP APOP authentication [RFC1939]), this message
      also contains a server-side authentication verification value.

      When the client's verification value is incorrect (e.g., because
      the user-supplied password was incorrect), the server will respond
      with a 401-INIT message (the same message as the message used
      in (2)) instead.

   o  The client MUST first check the validity of the server-side
      authentication verification value contained in the message (7).
      If the value was equal to the expected value, server
      authentication succeeded.

Top      ToC       Page 10 
      If it is not the expected value or the message does not contain
      the authentication verification value, then the mutual
      authentication has been broken for some unexpected reason.  The
      client MUST NOT process any body or header values contained in the
      HTTP response in this case.  (Note: This case should not happen
      between a correctly implemented server and client without any
      active attacks; such a scenario could be caused by either a
      man-in-the-middle attack or incorrect implementation.)

2.3.  Alternative Flows

   As shown above, the typical flow for a first authentication request
   requires three request-response pairs.  To reduce protocol overhead,
   the protocol enables several shortcut flows that require fewer
   messages.

   o  Case A: If the client knows that the resource is likely to require
      authentication, the client MAY omit the first unauthenticated
      request (1) and immediately send a key exchange (req-KEX-C1)
      message.  This will reduce the number of round trips by one.

   o  Case B: If both the client and the server previously shared a
      session secret associated with a valid sid, the client MAY
      directly send a req-VFY-C message using the existing sid and
      corresponding session secret.  This will further reduce the number
      of round trips by one.

      The server MAY have thrown out the corresponding session from the
      session table.  If so, the server will respond with a 401-STALE
      message, indicating that a new key exchange is required.  The
      client SHOULD try again to construct a req-KEX-C1 message in
      this case.

Top      ToC       Page 11 
   Figure 2 depicts the shortcut flows described above.  When using
   appropriate settings and implementations, most of the requests to
   resources are expected to meet both criteria; thus, only one
   round trip of request/response will be required.

     Case A: Omit first request
             (2 round trips)

        Client            Server
        |                      |
        | --- req-KEX-C1 ----> |
        |                      |
        | <---- 401-KEX-S1 --- |
        |                      |
        | ---- req-VFY-C ----> |
        |                      |
        | <----- 200-VFY-S --- |
        |                      |

     Case B: Reuse session secret (re-authentication)

         (B-1) key available        (B-2) key expired
               (1 round trip)             (3 round trips)

        Client            Server   Client              Server
        |                      |   |                        |
        | ---- req-VFY-C ----> |   | --- req-VFY-C -------> |
        |                      |   |                        |
        | <----- 200-VFY-S --- |   | <------- 401-STALE --- |
        |                      |   |                        |
                                   | --- req-KEX-C1 ------> |
                                   |                        |
                                   | <------ 401-KEX-S1 --- |
                                   |                        |
                                   | --- req-VFY-C -------> |
                                   |                        |
                                   | <------- 200-VFY-S --- |
                                   |                        |

               Figure 2: Several Alternative Protocol Flows

   For more details, see Sections 10 and 11.

Top      ToC       Page 12 
3.  Message Syntax

   Throughout this specification, the syntax is denoted in the extended
   augmented BNF syntax as defined in [RFC7230] and [RFC5234].  The
   following elements are used in this document per [RFC5234],
   [RFC7230], and [RFC7235]: DIGIT, ALPHA, SP, auth-scheme,
   quoted-string, auth-param, header-field, token, challenge, and
   credentials.

   The Mutual authentication protocol uses three headers:
   WWW-Authenticate (usually in responses with a 401 status code),
   Authorization (in requests), and Authentication-Info (in responses
   other than a 401 status code).  These headers follow the frameworks
   described in [RFC7235] and [RFC7615].  See Section 4 for more details
   regarding these headers.

   The framework in [RFC7235] defines the syntax for the headers
   WWW-Authenticate and Authorization as the syntax elements "challenge"
   and "credentials", respectively.  The auth-scheme element contained
   in those headers MUST be set to "Mutual" when using the protocol
   specified in this document.  The syntax for "challenge" and
   "credentials" to be used with the "Mutual" auth-scheme SHALL be
   name-value pairs (#auth-param), not the "token68" parameter defined
   in [RFC7235].

   The Authentication-Info header used in this protocol SHALL follow the
   syntax defined in [RFC7615].

   In HTTP, the WWW-Authenticate header may contain two or more
   challenges.  Client implementations SHOULD be aware of, and be
   capable of correctly handling, those cases.

3.1.  Non-ASCII Extended Header Parameters

   All of the parameters contained in the above three headers, except
   for the "realm" field, MAY be extended to ISO 10646-1 values using
   the framework described in [RFC5987].  All servers and clients MUST
   be capable of receiving and sending values encoded per the syntax
   specified in [RFC5987].

   If a value to be sent contains only ASCII characters, the field MUST
   be sent using plain syntax as defined in RFC 7235.  The syntax as
   extended by RFC 5987 MUST NOT be used in this case.

   If a value (except for the "realm" header) contains one or more
   non-ASCII characters, the parameter SHOULD be sent using the syntax
   defined in Section 3.2 of [RFC5987] as "ext-parameter".  Such a
   parameter MUST have a charset value of "UTF-8", and the language

Top      ToC       Page 13 
   value MUST always be omitted (have an empty value).  The same
   parameter MUST NOT be sent more than once, regardless of the
   syntax used.

   For example, a parameter "user" with the value "Renee of France"
   SHOULD be sent as < user="Renee of France" >.  If the value is
   "Ren<e acute>e of France", it SHOULD be sent as
   < user*=UTF-8''Ren%C3%89e%20of%20France > instead.

   [RFC7235] requires that the "realm" parameter be in its plain form
   (not as an extended "realm*" parameter), so the syntax specified in
   RFC 5987 MUST NOT be used for this parameter.

3.2.  Values

   The parameter values contained in challenges or credentials MUST be
   parsed in strict conformance with HTTP semantics (especially the
   unquoting of string parameter values).  In this protocol, those
   values are further categorized into the following value types:
   tokens (bare-token and extensive-token), string, integer,
   hex-fixed-number, and base64-fixed-number.

   For clarity, it is RECOMMENDED that implementations use the canonical
   representations specified in the following subsections for sending
   values.  However, recipients MUST accept both quoted and unquoted
   representations interchangeably, as specified in HTTP.

3.2.1.  Tokens

   For sustaining both security and extensibility at the same time, this
   protocol defines a stricter sub-syntax for the "token" to be used.
   Extensive-token values SHOULD use the following syntax (after the
   parsing of HTTP values):

      bare-token           = bare-token-lead-char *bare-token-char
      bare-token-lead-char = %x30-39 / %x41-5A / %x61-7A
      bare-token-char      = %x30-39 / %x41-5A / %x61-7A / "-" / "_"
      extension-token      = "-" bare-token 1*("." bare-token)
      extensive-token      = bare-token / extension-token

                   Figure 3: BNF Syntax for Token Values

   The tokens (bare-token and extension-token) are case insensitive.
   Senders SHOULD send these in lower case, and receivers MUST accept
   both upper and lower cases.  When tokens are used as (partial) inputs
   to any hash functions or other mathematical functions, they MUST
   always be used in lower case.

Top      ToC       Page 14 
   Extensive-tokens are used in this protocol where the set of
   acceptable tokens may include non-standard extensions.  Any extension
   of this protocol MAY use either the bare-tokens allocated by IANA
   (see the procedure described in Section 16) or extension-tokens with
   the format "-<bare-token>.<domain-name>", where <domain-name> is a
   valid (sub)domain name on the Internet owned by the party who defines
   the extension.

   Bare-tokens and extensive-tokens are also used for parameter names,
   in the unquoted form.  Requirements for using the extension-token for
   the parameter names are the same as those described in the previous
   paragraph.

   The canonical format for bare-tokens and extensive-tokens is the
   unquoted representation.

3.2.2.  Strings

   All character strings MUST be encoded to octet strings using UTF-8
   encoding [RFC3629] for the Unicode character set [Unicode].  Such
   strings MUST NOT contain any leading Byte Order Marks (BOMs) (also
   known as ZERO WIDTH NO-BREAK SPACE, U+FEFF, or EF BB BF).  It is
   RECOMMENDED that both peers reject any invalid UTF-8 sequences that
   might cause decoding ambiguities (e.g., containing <"> in the second
   or subsequent bytes of the UTF-8 encoded characters).

   If strings represent a domain name or URI that contains non-ASCII
   characters, the host parts SHOULD be encoded as they (the parts) are
   used in the HTTP protocol layer (e.g., in a Host: header); per
   current standards, the A-label as defined in [RFC5890] will be used.
   Lowercase ASCII characters SHOULD be used.

   The canonical format for strings is quoted-string (as it may contain
   equals signs ("="), plus signs ("+"), and slashes ("/")), unless the
   parameter containing the string value will use extended syntax as
   defined in [RFC5987].  (Per [RFC5987], an extended parameter will
   have an unquoted encoded value.)

3.2.3.  Numbers

   The following syntax definitions provide a syntax for numeric values:

    integer             = "0" / (%x31-39 *DIGIT)     ; no leading zeros
    hex-fixed-number    = 1*(2(DIGIT / %x41-46 / %x61-66))
    base64-fixed-number = 1*( ALPHA / DIGIT / "+" / "/" ) 0*2"="

                     Figure 4: BNF Syntax for Numbers

Top      ToC       Page 15 
   The syntax definition of the integers only allows representations
   that do not contain leading zeros.

   A number represented as a hex-fixed-number MUST include an even
   number of hexadecimal digits (i.e., multiples of eight bits).  Those
   values are case insensitive and SHOULD be sent in lower case.  When
   these values are generated from any cryptographic values, they MUST
   have their "natural length"; if they are generated from a hash
   function, their lengths correspond to the hash size; if they
   represent elements of a mathematical set (or group), their lengths
   SHALL be the shortest lengths that represent all the elements in the
   set.  For example, the results of the SHA-256 hash function will be
   represented by 64 digits, and any elements in a 2048-bit prime field
   (modulo a 2048-bit integer) will be represented by 512 digits,
   regardless of how many zeros appear in front of such representations.
   Session identifiers and other non-cryptographically generated values
   are represented in any (even) length determined by the side that
   generates it first, and the same length MUST be used in all
   communications by both peers.

   The numbers represented as base64-fixed-number SHALL be generated as
   follows: first, the number is converted to a big-endian radix-256
   binary representation as an octet string.  The length of the
   representation is determined in the same way as the technique
   mentioned above.  Then, the string is encoded using base64 encoding
   (described in Section 4 of [RFC4648]) without any spaces and
   newlines.  Implementations decoding base64-fixed-number SHOULD reject
   any input data with invalid characters, excess or insufficient
   padding, or non-canonical pad bits (see Sections 3.1 through 3.5 of
   [RFC4648]).

   The canonical format for integer and hex-fixed-number is unquoted
   tokens, and the canonical format for base64-fixed-number is
   quoted-string.



(page 15 continued on part 2)

Next Section