draft-ietf-httpauth-hoba-08.txt   draft-ietf-httpauth-hoba-09.txt 
Network Working Group S. Farrell Network Working Group S. Farrell
Internet-Draft Trinity College Dublin Internet-Draft Trinity College Dublin
Intended status: Experimental P. Hoffman Intended status: Experimental P. Hoffman
Expires: June 29, 2015 VPN Consortium Expires: July 3, 2015 VPN Consortium
M. Thomas M. Thomas
Phresheez Phresheez
December 26, 2014 December 30, 2014
HTTP Origin-Bound Authentication (HOBA) HTTP Origin-Bound Authentication (HOBA)
draft-ietf-httpauth-hoba-08 draft-ietf-httpauth-hoba-09
Abstract Abstract
HTTP Origin-Bound Authentication (HOBA) is a digital signature based HTTP Origin-Bound Authentication (HOBA) is a digital signature based
design for an HTTP authentication method. The design can also be design for an HTTP authentication method. The design can also be
used in Javascript-based authentication embedded in HTML. HOBA is an used in Javascript-based authentication embedded in HTML. HOBA is an
alternative to HTTP authentication schemes that require passwords and alternative to HTTP authentication schemes that require passwords and
therefore avoids all problems related to passwords, such as leakage therefore avoids all problems related to passwords, such as leakage
of server-side password databases. of server-side password databases.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 29, 2015. This Internet-Draft will expire on July 3, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 5 2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 5
3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 8 3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 8
4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 9 4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 9
5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 10 5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 10
5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 10 5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 10
5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 10 5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 10
6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 11 6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 11
6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 12
6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 13 6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 13
6.2. Associating Additional Keys to an Existing Account . . . 14 6.2. Associating Additional Keys to an Existing Account . . . 15
6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 15 6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 15
6.2.2. Human memorable one time password (don't do this one) 15 6.2.2. Human memorable one time password (don't do this one) 16
6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 16 6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 16
6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 16 6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 17
7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 16 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Privacy considerations . . . . . . . . . . . . . . . . . 17 8.1. Privacy considerations . . . . . . . . . . . . . . . . . 17
8.2. localStorage Security for Javascript . . . . . . . . . . 17 8.2. localStorage Security for Javascript . . . . . . . . . . 18
8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 18 8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 19
8.4. Injective Mapping for HOBA-TBS . . . . . . . . . . . . . 18 8.4. Injective Mapping for HOBA-TBS . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 19 9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 19
9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 19 9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 20
9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 20 9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 20
9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 20 9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 20
9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 20 9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 21
9.6. Hobareg HTTP Header Field . . . . . . . . . . . . . . . . 21 9.6. Hobareg HTTP Header Field . . . . . . . . . . . . . . . . 21
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Problems with Passwords . . . . . . . . . . . . . . 23 Appendix A. Problems with Passwords . . . . . . . . . . . . . . 24
Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
HTTP Origin-Bound Authentication (HOBA) is an authentication design HTTP Origin-Bound Authentication (HOBA) is an authentication design
that can be used as an HTTP authentication scheme [RFC7235] and for that can be used as an HTTP authentication scheme [RFC7235] and for
Javascript-based authentication embedded in HTML. The main goal of Javascript-based authentication embedded in HTML. The main goal of
HOBA is to offer an easy-to-implement authentication scheme that is HOBA is to offer an easy-to-implement authentication scheme that is
not based on passwords, but that can easily replace HTTP or HTML not based on passwords, but that can easily replace HTTP or HTML
forms-based password authentication. Deployment of HOBA can reduce forms-based password authentication. Deployment of HOBA can reduce
or eliminate password entries in databases, with potentially or eliminate password entries in databases, with potentially
skipping to change at page 5, line 7 skipping to change at page 5, line 7
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]. notation of [RFC5234].
Account: The term "account" is (loosely) used to refer to whatever Account: The term "account" is (loosely) used to refer to whatever
data structure(s) the server maintains that are associated with an data structure(s) the server maintains that are associated with an
identity. That will contain of at least one CPK and a web-origin; it identity. That will contain at least one CPK and a web-origin; it
will also optionally include an HTTP "realm" as defined in the HTTP will also optionally include an HTTP "realm" as defined in the HTTP
authentication specification [RFC7235]. It might also involve many authentication specification [RFC7235]. It might also involve many
other non-standard pieces of data that the server accumulates as part other non-standard pieces of data that the server accumulates as part
of account creation processes. An account may have many CPKs that of account creation processes. An account may have many CPKs that
are considered equivalent in terms of being usable for are considered equivalent in terms of being usable for
authentication, but the meaning of "equivalent" is really up to the authentication, but the meaning of "equivalent" is really up to the
server and is not defined here. server and is not defined here.
Client public key ("CPK"): A CPK is the public key and associated Client public key ("CPK"): A CPK is the public key and associated
cryptographic parameters needed for a server to validate a signature. cryptographic parameters needed for a server to validate a signature.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
private key corresponding to the CPK for that web-origin. The private key corresponding to the CPK for that web-origin. The
formatting chosen for this TBS blob is chosen so as to make server- formatting chosen for this TBS blob is chosen so as to make server-
side signature verification as simple as possible for a wide range of side signature verification as simple as possible for a wide range of
current server tooling. current server tooling.
Figure 1 specifies the ABNF for the signature input. The term Figure 1 specifies the ABNF for the signature input. The term
"unreserved" means that the field does not have a specific format "unreserved" means that the field does not have a specific format
defined and allows the characters specified in Section 2.3 of defined and allows the characters specified in Section 2.3 of
[RFC3986]. [RFC3986].
HOBA-TBS = len ":" nonce HOBA-TBS = len ":" nonce
len ":" alg len ":" alg
len ":" origin len ":" origin
len ":" [ realm ] len ":" [ realm ]
len ":" kid len ":" kid
len ":" challenge len ":" challenge
len = 1*DIGIT len = 1*DIGIT
nonce = 1*base64urlchars nonce = 1*base64urlchars
alg = 1*2DIGIT alg = 1*2DIGIT
origin = scheme "://" authority ":" port origin = scheme "://" authority ":" port
; scheme etc are from RFC 3986 ; scheme etc are from RFC 3986
realm = unreserved realm = unreserved
; realm is to be treated as in Section 2.2 of RFC 7235 ; realm is to be treated as in Section 2.2 of RFC 7235
kid = 1*base64urlchars kid = 1*base64urlchars
challenge = 1*base64urlchars challenge = 1*base64urlchars
; Characters for Base64URL encoding from Table 2 of RFC 4648 ; Characters for Base64URL encoding from Table 2 of RFC 4648
; all of which are US-ASCII (see RFC 20) ; all of which are US-ASCII (see RFC 20)
base64urlchars = %x30-39 ; Digits base64urlchars = %x30-39 ; Digits
/ %x41-5A ; Uppercase letters / %x41-5A ; Uppercase letters
/ %x61-7A ; Lowercase letters / %x61-7A ; Lowercase letters
/ "-" / "_" / "=" ; Special characters / "-" / "_" / "=" ; Special characters
Figure 1: To-be-signed data for HOBA Figure 1: To-be-signed data for HOBA
The fields above contain the following: The fields above contain the following:
o len: Each field is preceeded by the number of octets of the o len: Each field is preceeded by the number of octets of the
following field, expressed as a decimal number in ASCII [RFC0020]. following field, expressed as a decimal number in ASCII [RFC0020].
Lengths are separated from field values by a colon character. So Lengths are separated from field values by a colon character. So
if a nonce with the value "ABCD" were used then that would be if a nonce with the value "ABCD" were used then that would be
preceeded by "4:" (see the example in Appendix B for detail). preceeded by "4:" (see the example in Appendix B for detail).
o nonce: is a random value chosen by the UA and MUST be base64url o nonce: is a random value chosen by the UA and MUST be base64url
encoded before being included in the HOBA-TBS value. (base64url encoded before being included in the HOBA-TBS value. (base64url
encoding is defined in [RFC4648].) UAs MUST be able to use at encoding is defined in [RFC4648], guidelines for randomness are
least 32 bits of randomness in generating a nonce. UAs SHOULD be give in [RFC4086].) UAs MUST be able to use at least 32 bits of
able to use 64 or more bits of randomness for nonces. randomness in generating a nonce. UAs SHOULD be able to use 64 or
more bits of randomness for nonces.
o alg: specifies the signature algorithm being used encoded as an o alg: specifies the signature algorithm being used encoded as a
ASCII character as defined in Section 9.3. RSA-SHA256 MUST be single octet as defined in Section 9.3. RSA-SHA256 MUST be
supported, RSA-SHA1 MAY be supported. The IANA registered supported, RSA-SHA1 MAY be supported. The IANA registered
algorithm values are encoded as ASCII numbers; for example, the algorithm values are encoded as ASCII numbers; for example, the
encoding of RSA-SHA256 is 0x30. encoding of RSA-SHA256 is 0x30.
o origin: is the web origin expressed as the concatenation of the o origin: is the web origin expressed as the concatenation of the
scheme, authority and port from [RFC3986]. These are not base64 scheme, authority and port from [RFC3986]. These are not base64
encoded as they will be most readily available to the server in encoded as they will be most readily available to the server in
plain text. For example, if accessing the URL "https:// plain text. For example, if accessing the URL "https://
www.example.com:8080/foo" then the bytes input to the signature www.example.com:8080/foo" then the bytes input to the signature
process will be "https://www.example.com:8080". There is no process will be "https://www.example.com:8080". There is no
skipping to change at page 7, line 27 skipping to change at page 7, line 28
o challenge: MUST be a base64url encoded challenge value that the o challenge: MUST be a base64url encoded challenge value that the
server chose to send to the client. The challenge MUST be chosen server chose to send to the client. The challenge MUST be chosen
so that it is infeasible to guess, and SHOULD be indistinguishable so that it is infeasible to guess, and SHOULD be indistinguishable
from (the base64url encoding of) an at least 128-bit long random from (the base64url encoding of) an at least 128-bit long random
string. string.
The HOBA-TBS string is the input to the client's signing process, but The HOBA-TBS string is the input to the client's signing process, but
is not itself sent over the network since some fields are already is not itself sent over the network since some fields are already
inherent in the HTTP exchange. The challenge however is sent over inherent in the HTTP exchange. The challenge however is sent over
the network so as to reduce the amount of reduce the amount of state the network so as to reduce the amount of state that needs to be
that needs to be maintained by servers. (One form of stateless maintained by servers. (One form of stateless challenge might be a
challenge might be a ciphertext that the server decrypts and checks, ciphertext that the server decrypts and checks, but that is an
but that is an implementation detail.) The value that is sent over implementation detail.) The value that is sent over the network by
the network by the UA is the HOBA "client result" which we now the UA is the HOBA "client result" which we now define.
define.
The HOBA "client result" is a dot-separated string that includes the The HOBA "client result" is a dot-separated string that includes the
signature and is sent in the HTTP Authorizaion header field value signature and is sent in the HTTP Authorizaion header field value
using the value syntax defined in Figure 2. The "sig" value is the using the value syntax defined in Figure 2. The "sig" value is the
base64url encoded version of the binary output of the signing base64url encoded version of the binary output of the signing
process. The kid, challenge and nonce are as defined above and are process. The kid, challenge and nonce are as defined above and are
also base64url encoded. also base64url encoded.
HOBA-RES = kid "." challenge "." nonce "." sig HOBA-RES = kid "." challenge "." nonce "." sig
sig = 1*base64urlchars sig = 1*base64urlchars
Figure 2: HOBA Client Result value Figure 2: HOBA Client Result value
If a malformed message of any kind is received by a server, the
server MUST fail authenticaiton. If a malformed message of any kind
is received by a client, the client MUST abandon that authentication
attempt. (The client is of course free to start another
authentication attempt if it desires.)
The HOBA scheme is far from new, for example, the basic idea is The HOBA scheme is far from new, for example, the basic idea is
pretty much identical to the first two messages from "Mechanism R" on pretty much identical to the first two messages from "Mechanism R" on
page 6 of [MI93] which predates HOBA by 20 years. page 6 of [MI93] which predates HOBA by 20 years.
3. Introduction to the HOBA-http Mechanism 3. Introduction to the HOBA-http Mechanism
An HTTP server that supports HOBA authentication includes the "HOBA" An HTTP server that supports HOBA authentication includes the "HOBA"
auth-scheme value in a WWW-Authenticate header field when it wants auth-scheme value in a WWW-Authenticate header field when it wants
the client to authenticate with HOBA. Note that the HOBA auth-scheme the client to authenticate with HOBA. Note that the HOBA auth-scheme
might not be the only one that the server includes in a WWW- might not be the only one that the server includes in a WWW-
skipping to change at page 10, line 11 skipping to change at page 10, line 20
lieu of WebCrypto, JavaScript crypto libraries can be employed with lieu of WebCrypto, JavaScript crypto libraries can be employed with
the known deficiencies of their pseudo-random number generators and the known deficiencies of their pseudo-random number generators and
the general immaturity of those libraries. the general immaturity of those libraries.
5. HOBA's Authentication Process 5. HOBA's Authentication Process
This section describes how clients and servers use HOBA for This section describes how clients and servers use HOBA for
authentication. The interaction between an HTTP client and HTTP authentication. The interaction between an HTTP client and HTTP
server using HOBA happens in three phases: the CPK preparation phase, server using HOBA happens in three phases: the CPK preparation phase,
the signing phase, and the authentication phase. This section also the signing phase, and the authentication phase. This section also
covers the actions that give HOBA similar user features as today's covers the actions that give HOBA user features similar to today's
passwords have. password based schemes.
5.1. CPK Preparation Phase 5.1. CPK Preparation Phase
In the CPK preparation phase, the client determines if it already has In the CPK preparation phase, the client determines if it already has
a CPK for the web-origin with which it needs to authenticate. If the a CPK for the web-origin with which it needs to authenticate. If the
client has a CPK, the client will use it; if the client does not have client has a CPK, the client will use it; if the client does not have
a CPK, it generates one in anticipation of the server asking for one. a CPK, it generates one in anticipation of the server asking for one.
5.2. Signing Phase 5.2. Signing Phase
skipping to change at page 13, line 48 skipping to change at page 14, line 20
page) the server MAY add this header with a value of "reginwork". page) the server MAY add this header with a value of "reginwork".
See Section 9.6 for the relevant IANA registration of this header See Section 9.6 for the relevant IANA registration of this header
field. field.
For interstitial pages, the client MAY include a HOBA Authorization For interstitial pages, the client MAY include a HOBA Authorization
header. This is not considered a MUST as that might needlessly header. This is not considered a MUST as that might needlessly
complicate client implementations but is noted here in case a server complicate client implementations but is noted here in case a server
implementer assumes that all registration messages contain a HOBA implementer assumes that all registration messages contain a HOBA
Authorization header. Authorization header.
Hobareg-val = "regok" / "reginwork" Hobareg-val = "regok" / "reginwork"
Figure 3: Hobareg Header Field Definition Figure 3: Hobareg Header Field Definition
Figure 3 provides an ABNF definition for the values allowed in the Figure 3 provides an ABNF definition for the values allowed in the
Hobareg header field. Note that these (and the header field name) Hobareg header field. Note that these (and the header field name)
are case insensitive. Section 8.3.1 of [RFC7231] calls for are case insensitive. Section 8.3.1 of [RFC7231] calls for
documenting the following details for this new header field: documenting the following details for this new header field:
o Only one single value is allowed in a Hobareg header field. o Only one single value is allowed in a Hobareg header field.
Should more than one (a list) be encountered or any other ANBF- Should more than one (a list) be encountered or any other ANBF-
skipping to change at page 16, line 35 skipping to change at page 17, line 9
The server MUST NOT allow TLS session resumption for any logged out The server MUST NOT allow TLS session resumption for any logged out
session. session.
The server SHOULD also revoke or delete any cookies associated with The server SHOULD also revoke or delete any cookies associated with
the session. the session.
6.4. Getting a Fresh Challenge 6.4. Getting a Fresh Challenge
The UA can get a "fresh" challenge from the server. In HOBA-http, it The UA can get a "fresh" challenge from the server. In HOBA-http, it
sends a POST message to ".well-known/hoba/getchal". If successful, sends a POST message to ".well-known/hoba/getchal". If successful,
the response response MUST contain a fresh (base64url encoded) HOBA the response MUST contain a fresh (base64url encoded) HOBA challenge
challenge for this origin in the body of the response. Whitespace in for this origin in the body of the response. Whitespace in the
the response MUST be ignored. response MUST be ignored.
7. Mandatory-to-Implement Algorithms 7. Mandatory-to-Implement Algorithms
RSA-SHA256 MUST be supported. RSA-SHA1 MAY be used. RSA modulus RSA-SHA256 MUST be supported. RSA-SHA1 MAY be used. RSA modulus
lengths of at least 2048 bits SHOULD be used. RSA is defined in lengths of at least 2048 bits SHOULD be used. RSA is defined in
Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS].
8. Security Considerations 8. Security Considerations
If key binding was server-selected then a bad actor could bind If key binding was server-selected then a bad actor could bind
skipping to change at page 20, line 47 skipping to change at page 21, line 16
For this registry the number column should contain a small positive For this registry the number column should contain a small positive
integer. integer.
9.5. Device Identifier Types 9.5. Device Identifier Types
Please create a new HOBA Device Identifier Types registry as follows, Please create a new HOBA Device Identifier Types registry as follows,
with the specification required rule for updates. with the specification required rule for updates.
Number Meaning Number Meaning
----------- -------------------------------------------- ----------- --------------------------------------------
0 an unformatted string, at the user's/UA's whim 0 an unformatted UTF8 string, at the user's/UA's whim
For this registry the number column should contain a small positive For this registry the number column should contain a small positive
integer. integer.
9.6. Hobareg HTTP Header Field 9.6. Hobareg HTTP Header Field
Please register a new identifier in the Permanent Message Header Please register a new identifier in the Permanent Message Header
Field Names registry as described below. Field Names registry as described below.
Header field name: Hobareg Header field name: Hobareg
skipping to change at page 22, line 19 skipping to change at page 22, line 32
There is another implementation by Michael Thomas of an HOBA-JS There is another implementation by Michael Thomas of an HOBA-JS
variant. variant.
The most recent (Dec 2014) implementation is by Portugal Telecom The most recent (Dec 2014) implementation is by Portugal Telecom
and is available from https://github.com/razevedo/hoba- and is available from https://github.com/razevedo/hoba-
authentication authentication
11. Acknowledgements 11. Acknowledgements
Thanks to the following for good comments received during the Thanks to the following for good comments received during the
preparation of this specification: David Black, Amos Jeffries, preparation of this specification: David Black, Donald Eastlake, Amos
Benjamin Kaduk, Watson Ladd, Matt Lepinski, Ilari Liusvaara, James Jeffries, Benjamin Kaduk, Watson Ladd, Matt Lepinski, Ilari
Manger, Alexey Melnikov, Yoav Nir, Mark Nottingham, Julian Reschke, Liusvaara, James Manger, Alexey Melnikov, Kathleen Moriarty, Yoav
Michael Richardson, Yaron Sheffer, and Michael Sweet. All errors and Nir, Mark Nottingham, Julian Reschke, Michael Richardson, Yaron
stupidities are of course the editors' fault. Sheffer, and Michael Sweet. All errors and stupidities are of course
the editors' fault.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969. October 1969.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 23, line 34 skipping to change at page 23, line 47
[SHS] NIST, , "Secure Hash Standard (SHS), FIPS PUB 180-4", NIST [SHS] NIST, , "Secure Hash Standard (SHS), FIPS PUB 180-4", NIST
Special Publications , March 2012. Special Publications , March 2012.
12.2. Informative References 12.2. Informative References
[MI93] Mitchell, and Thomas, "Standardising Authentication [MI93] Mitchell, and Thomas, "Standardising Authentication
Protocols Based on Public-Key Techniques.", Journal of Protocols Based on Public-Key Techniques.", Journal of
Computer Security 2 (1993): 23-36. , 1993. Computer Security 2 (1993): 23-36. , 1993.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", STD 76, RFC 6376, Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
September 2011. September 2011.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, July Code: The Implementation Status Section", RFC 6982, July
2013. 2013.
skipping to change at page 25, line 13 skipping to change at page 25, line 29
L26m5KbK860uSOKywI0xp4ymnHMc6Led5qfEMnJC9PEI90tIMcgdHrmdHC_vpldG L26m5KbK860uSOKywI0xp4ymnHMc6Led5qfEMnJC9PEI90tIMcgdHrmdHC_vpldG
DQIDAQAB DQIDAQAB
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
Origin: https://example.com:443 Origin: https://example.com:443
Key Identifier: vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w Key Identifier: vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w
Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc= Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=
Signature algorithm: RSA-SHA256 ("0")
Nonce: Pm3yUW-sW5Q Nonce: Pm3yUW-sW5Q
Signature: Signature:
VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0i VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0i
4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miUz 4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miUz
q04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrKP q04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrKP
tG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr9 tG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr9
6ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9kI 6ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9kI
S13qQA43m4IMExkbApqrSg S13qQA43m4IMExkbApqrSg
 End of changes. 26 change blocks. 
56 lines changed or deleted 69 lines changed or added

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