Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8120

Mutual Authentication Protocol for HTTP

Pages: 53
Experimental
Part 1 of 3 – Pages 1 to 15
None   None   Next

Top   ToC   RFC8120 - 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.
Top   ToC   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   RFC8120 - 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   RFC8120 - 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   RFC8120 - 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   RFC8120 - 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   RFC8120 - 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   RFC8120 - 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   RFC8120 - 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   RFC8120 - 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   RFC8120 - 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   RFC8120 - 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   RFC8120 - 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   RFC8120 - 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   RFC8120 - 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