draft-ietf-httpauth-hoba-03.txt   draft-ietf-httpauth-hoba-04.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: October 20, 2014 VPN Consortium Expires: February 15, 2015 VPN Consortium
M. Thomas M. Thomas
Phresheez Phresheez
April 18, 2014 August 14, 2014
HTTP Origin-Bound Authentication (HOBA) HTTP Origin-Bound Authentication (HOBA)
draft-ietf-httpauth-hoba-03 draft-ietf-httpauth-hoba-04
Abstract Abstract
HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP
authentication method with credentials that are not vulnerable to authentication method with credentials that are not vulnerable to
phishing attacks, and that does not require any server-side password phishing attacks, and that does not require any server-side password
database. The design can also be used in Javascript-based database. The design can also be used in Javascript-based
authentication embedded in HTML. HOBA is an alternative to HTTP authentication embedded in HTML. HOBA is an alternative to HTTP
authentication schemes that require passwords. authentication schemes that require passwords.
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 October 20, 2014. This Internet-Draft will expire on February 15, 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 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 4 1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 5 2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 5
3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 7 3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 7
4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 8 4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 8
5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 9 5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 9
5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 9 5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 9
5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 9 5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 10
6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 10 6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 11
6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Associating Additional Keys to an Exiting Account . . . . 13 6.2. Associating Additional Keys to an Exiting Account . . . . 13
6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 13 6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 13
6.2.2. One time password . . . . . . . . . . . . . . . . . . 13 6.2.2. Human memorable one time password (don't do this one) 14
6.2.3. Out of band . . . . . . . . . . . . . . . . . . . . . 14 6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 14
6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 14
6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 14 6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 15
7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 14 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8.1. localStorage Security for Javascript . . . . . . . . . . 15 8.1. Privacy considerations . . . . . . . . . . . . . . . . . 15
8.2. Multiple Accounts on One User Agent . . . . . . . . . . . 16 8.2. localStorage Security for Javascript . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 16
9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.2. .well-known URLs . . . . . . . . . . . . . . . . . . . . 16 9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 17
9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 16 9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 17
9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 17 9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 17
9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 17 9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 18
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 9.6. HOBAREG HTTP Header . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Problems with Passwords . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Problems with Passwords . . . . . . . . . . . . . . 20
Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
[[ Commentary is in double-square brackets, like this. Fewer things
this time.]]
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 that can be used as an HTTP authentication scheme [RFC7235] and for
[I-D.ietf-httpbis-p7-auth] and for Javascript-based authentication Javascript-based authentication embedded in HTML. The main goal of
embedded in HTML. The main goal of HOBA is to offer an easy-to- HOBA is to offer an easy-to-implement authentication scheme that is
implement authentication scheme that is not based on passwords, but not based on passwords, but that can easily replace HTTP or HTML
that can easily replace HTTP or HTML forms-based password forms-based password authentication. Deployment of HOBA can reduce
authentication. Deployment of HOBA can reduce or eliminate password or eliminate password entries in databases, with potentially
entries in databases, with potentially significant security benefits. significant security benefits.
HOBA is an HTTP authentication mechanism that complies with the HOBA is an HTTP authentication mechanism that complies with the
framework for such schemes [I-D.ietf-httpbis-p7-auth]. As a framework for such schemes [RFC7235]. As a JavaScript design, HOBA
JavaScript design, HOBA demonstrates a way for clients and servers to demonstrates a way for clients and servers to interact using the same
interact using the same credentials that are used by the HTTP credentials that are used by the HTTP authentication scheme.
authentication scheme.
Current HTTP authentication methods (Basic and Digest), as well as Current HTTP authentication methods (Basic and Digest), as well as
username/password authentication using web forms, have been in use username/password authentication using web forms, have been in use
for many years, but being based on passwords, are susceptible to for many years, but being based on passwords, are susceptible to
theft of server-side databases. Instead of passwords, HOBA uses theft of server-side databases. Instead of passwords, HOBA uses
digital signatures as an authentication mechanism. HOBA also adds digital signatures as an authentication mechanism. HOBA also adds
useful features such as credential management and session logout. In useful features such as credential management and session logout. In
HOBA, the client creates a new public-private key pair for each host HOBA, the client creates a new public-private key pair for each host
("web-origin" [RFC6454]) to which it authenticates. These keys are ("web-origin" [RFC6454]) to which it authenticates. These keys are
used in HOBA for HTTP clients to authenticate themselves to servers used in HOBA for HTTP clients to authenticate themselves to servers
skipping to change at page 4, line 50 skipping to change at page 4, line 47
While cookies are bearer tokens, and thus weaker than HOBA While cookies are bearer tokens, and thus weaker than HOBA
signatures, they are currently ubiquitously used. If non-bearer signatures, they are currently ubiquitously used. If non-bearer
token session continuation schemes are developed in future in the token session continuation schemes are developed in future in the
IETF or elsewhere, then those can interface to HOBA as easily as with IETF or elsewhere, then those can interface to HOBA as easily as with
any password based authentication scheme. any password based authentication scheme.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
A client public key ("CPK") is the public key and associated A client public key ("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.
The term "account" is (loosely) used to refer to whatever data The term "account" is (loosely) used to refer to whatever data
structure(s) the server maintains that are associated with an 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 of 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. It might also involve many other non- authentication specification. It might also involve many other non-
standard pieces of data that the server accumulates as part of standard pieces of data that the server accumulates as part of
skipping to change at page 6, line 38 skipping to change at page 6, line 38
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
default for the port number, and the port number MUST be present. default for the port number, and the port number MUST be present.
o realm: is similarly just a string with the syntactic restrictions o realm: is similarly just a string with the syntactic restrictions
defined in [I-D.ietf-httpbis-p7-auth]. If no realm is specified defined in [RFC7235]. If no realm is specified for this
for this authentication then this is absent. (A missing field authentication then this is absent. (A missing field here is no
here is no problem since both sides know when it needs to be problem since both sides know when it needs to be there.)
there.)
o kid: is a key identifier - this MUST be a base64url encoded value o kid: is a key identifier - this MUST be a base64url encoded value
that is presented to the server in the HOBA client result (see that is presented to the server in the HOBA client result (see
below). below).
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 server chose to send to the client
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
skipping to change at page 7, line 17 skipping to change at page 7, line 17
The value that is sent over the network is the HOBA "client result" The value that is sent over the network is the HOBA "client result"
which we now define. which we now 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 Authorized header field value using signature and is sent in the HTTP Authorized header field value using
the value syntax defined in Figure 2. The "sig" value is the 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 = unreserved sig = unreserved
Figure 2: HOBA Client Result value Figure 2: HOBA Client Result value
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"
skipping to change at page 8, line 6 skipping to change at page 8, line 6
string made up of the base64url encoded octets that the server string made up of the base64url encoded octets that the server
wants the client to sign in its response. The challenge SHOULD be wants the client to sign in its response. The challenge SHOULD be
unique for every HTTP 401 response in order to prevent replay unique for every HTTP 401 response in order to prevent replay
attacks from passive observers. attacks from passive observers.
o An "expires" attribute MUST be included that specifies the number o An "expires" attribute MUST be included that specifies the number
of seconds from the time the HTTP response is emitted for which of seconds from the time the HTTP response is emitted for which
responses to this challenge can be accepted. responses to this challenge can be accepted.
o A "realm" attribute MAY be included to indicate the scope of o A "realm" attribute MAY be included to indicate the scope of
protection in the manner described in HTTP/1.1, Part 7 protection in the manner described in HTTP/1.1, Part 7 [RFC7235].
[I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT appear The "realm" attribute MUST NOT appear more than once.
more than once.
When the "client response" is created, the UA encodes the HOBA When the "client response" is created, the UA encodes the HOBA
client-result (a string matching the HOBA-RES production in Figure 2 client-result (a string matching the HOBA-RES production in Figure 2
as an auth-param with the name "result" and returns that in the as an auth-param with the name "result" and returns that in the
Authorization header. Authorization header.
The server MUST check the cryptographic correctness of the signature The server MUST check the cryptographic correctness of the signature
based on a public key it knows for the kid in the signatures, and if based on a public key it knows for the kid in the signatures, and if
the server cannot do that, or if the signature fails cryptographic the server cannot do that, or if the signature fails cryptographic
checks, then validation has failed. The server can use any checks, then validation has failed. The server can use any
additional mechanisms to validate the signature. If the validation additional mechanisms to validate the signature. If the validation
fails, or if the server chooses reject the signature for any reason fails, or if the server chooses reject the signature for any reason
whatsoever, the server aborts the transaction via a 403 Forbidden whatsoever, the server aborts the transaction via a 401 Unauthorized
HTTP response. [[ This maybe should be 401 Unauthorized. ]] HTTP response.
Note that a HOBA signature is good for however long the expires Note that a HOBA signature is good for however long the expires
attribute allows. This means that replay is possible within the time attribute allows. This means that replay is possible within the time
window specified by the "expires" value chosen by the server. window specified by the "expires" value chosen by the server.
Servers can attempt to detect any such replay and MAY react to such Servers can attempt to detect any such replay (via caching if they so
replays by responding with a second (or subsequent) 401-status HTTP choose) and MAY react to such replays by responding with a second (or
response containing a new challenge. [[ How could such detection be subsequent) 401-status HTTP response containing a new challenge.
done in face of cut-and-paste attacks? ]]
UAs MAY optimise their use of challenges by pre-fetching a challenge UAs MAY optimise their use of challenges by pre-fetching a challenge
value, for example after expires/2 seconds have elapsed, using the value, for example after expires/2 seconds have elapsed, using the
".well-known/hoba/getChal" scheme described later in this document. ".well-known/hoba/getChal" scheme described later in this document.
This also allows for pre-calculation of HOBA signatures, if that is This also allows for pre-calculation of HOBA signatures, if that is
required in order to produce a responsive user interface. required in order to produce a responsive user interface.
4. Introduction to the HOBA-js Mechanism 4. Introduction to the HOBA-js Mechanism
Web sites using JavaScript can also perform origin-bound Web sites using JavaScript can also perform origin-bound
skipping to change at page 11, line 19 skipping to change at page 11, line 22
is not possible, the differences are called out. is not possible, the differences are called out.
All additional services MUST be performed in TLS-protected sessions All additional services MUST be performed in TLS-protected sessions
([RFC5246]). If the current HTTP traffic is not running under TLS, a ([RFC5246]). If the current HTTP traffic is not running under TLS, a
new session is started before any of the actions described here are new session is started before any of the actions described here are
performed. performed.
HOBA-http uses a well-known URL [RFC5785] "hoba" as a base URI for HOBA-http uses a well-known URL [RFC5785] "hoba" as a base URI for
performing many tasks: "https://www.example.com/.well-known/hoba". performing many tasks: "https://www.example.com/.well-known/hoba".
These URLs are based on the name of the host that the HTTP client is These URLs are based on the name of the host that the HTTP client is
accessing. There are many use cases for these URLs to redirect to accessing.
other URLs: a site that does registration through a federated site, a
site that only does registration under HTTPS, and so on. Like any There are many use cases for these URLs to redirect to other URLs: a
HTTP client, HOBA-http clients MUST be able to handle redirection of site that does registration through a federated site, a site that
these URLs. [[ There are a bunch of security issues to consider only does registration under HTTPS, and so on. Like any HTTP client,
related to cases where a re-direct brings you off-origin. ]] HOBA-http clients have to be able to handle redirection of these
URLs. However, as that would potentially cause security issues when
a re-direct brings the client to a different web origin, servers
implementing HOBA-http SHOULD NOT re-direct to a different web origin
from below .well-known/hoba URLs. The above is considered sufficient
to allow experimentation with HOBA, but if at some point HOBA is
placed on the standards track then a full analysis of off-origin re-
directions would need to be documented.
6.1. Registration 6.1. Registration
Normally, a registration (also called "joining") is expected to Normally, a registration (also called "joining") is expected to
happen after a UA receives a WWW-Authenticate for a web-origin and happen after a UA receives a WWW-Authenticate for a web-origin and
realm (for HOBA-http) or on demand (for HOBA-js) for which it has no realm (for HOBA-http) or on demand (for HOBA-js) for which it has no
associated CPK. The process of registration for a HOBA account on a associated CPK. The process of registration for a HOBA account on a
server is relatively light-weight. The UA generates a new key pair, server is relatively light-weight. The UA generates a new key pair,
and associates it with the web-origin/realm in question. and associates it with the web-origin/realm in question.
skipping to change at page 12, line 29 skipping to change at page 12, line 37
o didtype: specifies a kind of device identifier intended to contain o didtype: specifies a kind of device identifier intended to contain
one of the values from Section 9.5, if absent then the "string" one of the values from Section 9.5, if absent then the "string"
form of device identifier MUST be used. form of device identifier MUST be used.
o did: a UTF8 string that specifies the device identifier. This can o did: a UTF8 string that specifies the device identifier. This can
be used to help a user be confident that authentication has be used to help a user be confident that authentication has
worked, e.g., following authentication some web content might say worked, e.g., following authentication some web content might say
"You last logged in from device 'did' at time T." "You last logged in from device 'did' at time T."
o curtime: the number of milliseconds since the Unix epoch, Note that replay of registration (and other HOBA) messages is quite
formatted as [[ not yet specified ]]. This is based on the possible. That however can be counteracted if challenge freshness is
expectation that the synchronization between the browser's and ensured. See Section 2 for details. Note also that with HOBA-http
server's clocks is sufficiently reliable. This is used to guard the HOBA signature does not cover the POST message body. If that is
against the replay of a legitimate registration message. The required then HOBA-JS may be a better fit for registration and other
server needs to have a replay cache covering a signature timeout account management actions.
window. This might be done using a database table that is keyed
(in the database sense of the term) using the signature bits. If
the signature is in the replay table, the server will reject it.
If the timestamp in the signature is outside the current replay
cache window then it also gets rejected.
[[ An addition of the ability for the server to reject a client with Since registration can often be a multi-step process, e.g. requiring
potential time skew and give it a nonce (as with HOBA-http) would a user to fill in contact details, the initial response to the HTTP
allow the size of the replay cache to be set to just a few minutes POST message defined above may not be the end of the registration
rather than a much longer period. Or the HOBA server could always process even though the HTTP response has a 200 OK status. This
use a nonce method. This is worthy of more discussion. ]]. creates an issue for the UA since, during the registration process
(e.g., while dealing with interstitial pages), the UA doesn't yet
know whether the CPK is good for that web origin or not.
[[ A comment raised on the list was: how does the UA know that the For this reason the server MUST add a header to the response message
registration process has completed successfully or badly? That's not when the registration has succeded to indicate the new state. The
yet handled. Also need to specify what happens if more data is header to be used is "HOBA-REG" and the value when registration has
needed. ]] succeeded is to be "regok". When registration is in-work (e.g. on an
HTTP response for an interstitial page) the server MAY add this
header with a value of "reginwork". See Section 9.6 for the relevant
IANA registration of this header field.
For interstitial pages, the client MAY include a HOBA Authorization
header. This is not considered a MUST as that might needlessly
complicate client implementations but is noted here in case a server
implementer assumes that all registration messages contain a HOBA
Authorization header.
6.2. Associating Additional Keys to an Exiting Account 6.2. Associating Additional Keys to an Exiting Account
From the user perspective, the UA having a CPK for a web origin will
often appear to be the same as having a way to sign in to an account
at that web site. Since users often have more than one UA, and since
the CPKs are, in general, UA-specific, that raises the question of
how the user can sign in to that account from different UAs. And
from the server perspective that turns into the question of how to
safely bind different CPKs to one account. In this section, we
describe some ways in which this can be done, as well as one way in
which this ought not be done.
Note that the context here is usually that the user has succeeded in
registering with one or more UAs (for the purposes of this section we
call this "the first UA" below) and can use HOBA with those, and the
user is now adding another UA. The newest UA might or might not have
a CPK for the site in question. Since it is in fact trivial, we
assume that the site is able to put in place some appropriate
quicker, easier registration for a CPK for the newest UA. The issue
then becomes one of binding the CPK from the newest UA with those of
other UAs bound to the account.
6.2.1. Moving private keys 6.2.1. Moving private keys
It is common for a user to have multiple UAs, and to want all those It is common for a user to have multiple UAs, and to want all those
UAs to be able to authenticate to a single account. One method to UAs to be able to authenticate to a single account. One method to
allow a user who has an existing account to be able to authenticate allow a user who has an existing account to be able to authenticate
on a second device is to securely transport the private and public on a second device is to securely transport the private and public
keys and the origin information from the first device to the second. keys and the origin information from the first device to the second.
If this approach is taken, then there is no impact on the HOBA-http If this approach is taken, then there is no impact on the HOBA-http
or HOBA-js so this is a pure UA implementation issue and not or HOBA-js so this is a pure UA implementation issue and not
discussed further. discussed further.
6.2.2. One time password 6.2.2. Human memorable one time password (don't do this one)
To enroll a new UA using an existing UA, the user requests a one-time
password that will be entered in the new UA. On HOBA-http, this is
done with the URL ".well-known/hoba/associate-start" using a POST
message [[ more detail is clearly needed here ]]. The server
displays a one-time password that expires in a short amount of time
(such as 30 minutes) on the currently enrolled UA. The new UA
generates a new CPK and sends it to the server. In HOBA-http, this
is done with a POST to ".well-known/hoba/associate-finish" [[ more
detail needed here ]].
The one-time password should be easy for a user to type into the new
UA, but at the same time needs to have enough randomness to prevent
an attacker from succeeding if they try to use the password during
its short lifetime. After the server gets the password in the new
UA, it verifies the signature and verifies that the password supplied
is in a list of unexpired one-time passwords. If so, the server
knows that the authenticated user is associated with the second CPK.
The server can choose to associate the two CPKs with one account.
Whether to do so is entirely at the server's discretion however, but
the server needs make the outcome clear to the user.
Alternatively, if an already-enrolled UA is not available to the user It will be tempting for implementers to use a human-memorable one-
when they want to associate a new UA with an existing account, and time password (OTP) in order to "authenticate" binding CPKs to the
the site has an out-of-band communication mechanism such as email or same account. The workflow here would likely be something along the
SMS associated with that account, the user can request that a one- lines of some server administrative utility generating a human
time password be sent to the user out of band. The user receives the memorable OTP such as "1234" and sending that to the user out of band
one-time password and, using the new UA, tells it to the server. On for the user to enter at two web pages each authenticated via the
HOBA-http, this is done with the URL ".well-known/hoba/associate- relevant CPK. While this seems obvious enough and could even be
from-oob" using a POST message [[ more detail is clearly needed here secure enough in some limited cases, we consider that this is too
]]. risky to use in the Internet and so servers SHOULD NOT provide such a
mechanism. The reason this is so dangerous is that it would be
trivial for an automated client to guess such tokens and "steal" the
binding intended for some other user. At any scale, there would
always be some in-process bindings so that even with only a trickle
of guesses (and hence not being detectable via message volume) an
attacker would have a high probability of succeeding in registering a
binding with the attacker's CPK.
[[ Note: the hoba.ie implementation doesn't do this - I omitted a This method of binding CPKs together is therefore NOT RECOMMENDED.
human memorable OTP for now. The reason is I think the probability
that spammers would try those is too high. So maybe we should delete
this entirely? ]]
6.2.3. Out of band 6.2.3. Out of band URL
There are various other ways in which a server can provide ways to One easy binding method is to simply provide a web page where, using
allow a new UA to be registered to the same account. For example, the first UA, the user can generate a URL (containing some
simply providing a web page where, using the first UA, the user can "unguessable" cryptographically generated value) that the user then
generate a URL (containing some cryptographic value) that the user later de-references on the newest UA. The user could e-mail that URL
then later de-references on the second UA would suffice. The user to herself for example, of the web server accessed at the first UA
could have e-mail that URL to herself for example, of the web server could automatically do that.
accessed at the first UA could automatically do that.
[[ Need to think about how much detail to put in here. Its all Such a URL SHOULD contain at least the equivalent of 128 bits of
fairly obvious, but we probably should talk about the security randomness.
considerations. The hoba.ie site btw has a few of these methods
implemented. ]]
6.3. Logging Out 6.3. Logging Out
The user can tell the server it wishes to log out. With HOBA-http, The user can tell the server it wishes to log out. With HOBA-http,
this is done by going to the URL ".well-known/hoba/logout". The UA this is done by sending any HOBA-authenticated HTTP message to the
SHOULD also delete session cookies associated with the session so URL ".well-known/hoba/logout" on the site in question. The UA SHOULD
that the user's state is no longer "logged in." also delete session cookies associated with the session so that the
user's state is no longer "logged in."
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. [[ Need to determine if this is needed or even a good idea. 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 include a fresh (base64url encoded) HOBA the response response MUST include a fresh (base64url encoded) HOBA
challenge for this origin in the body of the response. challenge for this origin in the body of the response.
skipping to change at page 15, line 8 skipping to change at page 15, line 25
lengths of at least 2048 bits SHOULD be used. lengths of at least 2048 bits SHOULD be used.
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
different accounts belonging to the user from the network with different accounts belonging to the user from the network with
possible bad consequences, especially if one of the private keys was possible bad consequences, especially if one of the private keys was
compromised somehow. compromised somehow.
Binding my CPK with someone else's account would be fun and Binding my CPK with someone else's account would be fun and
profitable so SHOULD be appropriately hard. In particular the string profitable so SHOULD be appropriately hard. In particular URLs or
generated by the server MUST be hard to guess, for whatever level of other values generated by the server as part of any CPK binding
difficulty is chosen by the server. The server SHOULD NOT allow a process MUST be hard to guess, for whatever level of difficulty is
random guess to reveal whether or not an account exists. chosen by the server. The server SHOULD NOT allow a random guess to
reveal whether or not an account exists.
[[ The potential impact on privacy of HOBA needs to be addressed. If 8.1. Privacy considerations
a site can use a 401 and a CPK to track users without permission that
would be not-so-nice so some guidance on how a UA could indicate to a
user that HOBA stuff is going on might be needed. Any authentication
mechanism allows tracking within account. ]]
[[ Lots more TBD, be nice to your private keys etc. etc. ]] HOBA does impact to some extent on privacy and could be considered to
represent a super-cookie to the server, or to any entity on the path
from UA to HTTP server that can see the HOBA signature. This is
because we need to send a key identifier as part of the signature and
that will not vary for a given key. For this reason, and others, it
is strongly RECOMMENDED to only use HOBA over server-authenticated
TLS and to migrate web sites using HOBA to only use "https" URLs.
8.1. localStorage Security for Javascript UAs SHOULD provide users a way to manage their CPKs. Ideally, there
would be a way for a user to maintain their HOBA details for a site
while at the same time deleting other site information such as
cookies or non-HOBA HTML5 LocalStorage. However, as this is likely
to be complex and appropriate user interfaces counter intutitive, we
exepect that UAs that implement HOBA will likely treat HOBA
information as just some more site data, that would disappear should
the user choose to "forget" that site.
8.2. localStorage Security for Javascript
Our use of localStorage will undoubtedly be a cause for concern. Our use of localStorage will undoubtedly be a cause for concern.
localStorage uses the same-origin model which says that the scheme, localStorage uses the same-origin model which says that the scheme,
domain and port define a localStorage instance. Beyond that, any domain and port define a localStorage instance. Beyond that, any
code executing will have access to private keying material. Of code executing will have access to private keying material. Of
particular concern are XSS attacks which could conceivably take the particular concern are XSS attacks which could conceivably take the
keying material and use it to create UAs under the control of an keying material and use it to create UAs under the control of an
attacker. But XSS attacks are in reality across the board attacker. But XSS attacks are in reality across the board
devastating since they can and do steal credit card information, devastating since they can and do steal credit card information,
passwords, perform illicit acts, etc, etc. It's not clear that we passwords, perform illicit acts, etc, etc. It's not clear that we
introduce unique threats from which clear text passwords don't introduce unique threats from which clear text passwords don't
skipping to change at page 16, line 11 skipping to change at page 16, line 40
that was breached, it's all of the sites a user used the same that was breached, it's all of the sites a user used the same
password on too. That is, the collateral damage is severe because password on too. That is, the collateral damage is severe because
password reuse is common. Storing a password in localStorage would password reuse is common. Storing a password in localStorage would
also have a similar multiplier effect for an attacker, though perhaps also have a similar multiplier effect for an attacker, though perhaps
on a smaller scale than a server-side compromise: one successful on a smaller scale than a server-side compromise: one successful
crack gains the attacker potential access to hundreds if not crack gains the attacker potential access to hundreds if not
thousands of sites the user visits. HOBA does not suffer from that thousands of sites the user visits. HOBA does not suffer from that
attack multiplier since each asymmetric key pair is unique per site/ attack multiplier since each asymmetric key pair is unique per site/
UA/user. UA/user.
8.2. Multiple Accounts on One User Agent 8.3. Multiple Accounts on One User Agent
A shared UA with multiple accounts is possible if the account A shared UA with multiple accounts is possible if the account
identifier is stored along with the asymmetric key pair binding them identifier is stored along with the asymmetric key pair binding them
to one another. Multiple entries can be kept, one for each account, to one another. Multiple entries can be kept, one for each account,
and selected by the current user. This, of course, is fraught with and selected by the current user. This, of course, is fraught with
the possibility for abuse, since a server is potentially enrolling the possibility for abuse, since a server is potentially enrolling
the device for a long period and the user may not want to have to be the device for a long period and the user may not want to have to be
responsible for the credential for that long. To alleviate this responsible for the credential for that long. To alleviate this
problem, the user can request that the credential be erased from the problem, the user can request that the credential be erased from the
browser. Similarly, during the enrollment phase, a user could browser. Similarly, during the enrollment phase, a user could
request that the key pair only be kept for a certain amount of time, request that the key pair only be kept for a certain amount of time,
or that it not be stored beyond the current browser session. or that it not be stored beyond the current browser session.
9. IANA Considerations 9. IANA Considerations
IANA is requested to make registrations and create new registries as
described below.
9.1. HOBA Authentication Scheme 9.1. HOBA Authentication Scheme
Please register a new scheme in the HTTP Authentication Scheme
Registry registry as follows:
Authentication Scheme Name: HOBA Authentication Scheme Name: HOBA
Pointer to specification text: [[ this document ]] Pointer to specification text: [[ this document ]]
Notes (optional): The HOBA scheme can be used with either HTTP Notes (optional): The HOBA scheme can be used with either HTTP
servers or proxies. [[ Still need to figure out what it means to do servers or proxies. When used in response to a 407 Proxy
this through proxies. ]] Authentication Required indication, the appropriate proxy
authentication header fields are used instead, as with any other HTTP
authentication scheme.
9.2. .well-known URLs 9.2. .well-known URI
We probably want a new registry for the labels beneath .well-known/ Please register a new .well-known URI in the Well-Known URIs registry
hoba so that other folks can add additional features in a controlled as described below.
way, e.g. for CPK/account revocation or whatever.
URI suffix: hoba
Change controller: IETF
Specification document(s): [[ this document ]]
Related information: N/A.
9.3. Algorithm Names 9.3. Algorithm Names
Please create a new HOBA signature algorithms registry as follows,
with the specification required rule for updates.
TBD, hopefully re-use and existing registry TBD, hopefully re-use and existing registry
"0" means RSA-SHA256 "0" means RSA-SHA256
"1" means RSA-SHA1 "1" means RSA-SHA1
[[ Will most likely add an elliptic curve signature mechanism. ]]
9.4. Key Identifier Types 9.4. Key Identifier Types
Please create a new HOBA Key Identifier Types registry as follows,
with the specification required rule for updates.
"0" means a hashed public key, as done in DANE. [RFC6698] "0" means a hashed public key, as done in DANE. [RFC6698]
"1" means a URI, such as a mailto: or acct: URI, but anything "1" means a URI, such as a mailto: or acct: URI, but anything
conforming to [RFC3986] is ok.i conforming to [RFC3986] is ok.i
"2" means an unformatted string, at the user's/UA's whim "2" means an unformatted string, at the user's/UA's whim
9.5. Device Identifier Types 9.5. Device Identifier Types
Please create a new HOBA Device Identifier Types registry as follows,
with the specification required rule for updates.
"0" means an unformatted nickname, at the user's/UA's whim "0" means an unformatted nickname, at the user's/UA's whim
9.6. HOBAREG HTTP Header
Please register a new identifier in the Permanent Message Header
Field Names registry as described below.
Header field name: HOBAREG
Applicable protocol: HTTP (RFC 7230)
Status: Experimental
Author/Change controller: IETF
Specification document(s): [[ this document ]]
Related information: N/A.
10. Implementation Status 10. Implementation Status
[[ Note to RFC editor - please delete this section before [[ Note to RFC editor - please delete this section before
publication. ]] publication. ]]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982]. Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
skipping to change at page 17, line 44 skipping to change at page 19, line 29
exist. exist.
According to [RFC6982] "this will allow reviewers and working groups According to [RFC6982] "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, by considering the running code as evidence of valuable running code, by considering the running code as evidence of valuable
experimentation and feedback that has made the implemented protocols experimentation and feedback that has made the implemented protocols
more mature. It is up to the individual working groups to use this more mature. It is up to the individual working groups to use this
information as they see fit". information as they see fit".
At the time of writing there are two known implementations. One done At the time of writing there are two known implementations. One done
by Stephen Farrell of HOBA-HTTP and a HOBA-JS variant implements the by Stephen Farrell of HOBA-http and a HOBA-JS variant implements the
-01 version of HOBA and is available from https://hoba.ie/ which site current (-04) version of HOBA and is available from https://hoba.ie/
also includes a demonstration of HOBA. which site also includes a demonstration of HOBA.
There is another implementation by Michael Thomas of an HOBA-JS There is another implementation by Michael Thomas of an HOBA-JS
variant. variant.
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: Julian Reschke, James Manger, preparation of this specification: Julian Reschke, James Manger,
Michael Sweet, Ilari Liusvaara, [[ and many more to be added ]]. All Michael Sweet, Ilari Liusvaara, [[ and any more to be added ]]. All
errors and stupidities are of course the editors' fault. errors and stupidities are of course the editors' fault.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
skipping to change at page 18, line 39 skipping to change at page 20, line 24
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December
2011. 2011.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. Protocol: TLSA", RFC 6698, August 2012.
12.2. Informative References 12.2. Informative References
[I-D.ietf-httpbis-p7-auth]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-22
(work in progress), February 2013.
[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.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[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, July Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
2013. 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.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, June 2014.
[bonneau] Bonneau, , "The science of guessing: analyzing an
anonymized corpus of 70 million passwords.", Security and
Privacy (SP), 2012 IEEE Symposium on. IEEE, 2012. , 2012.
Appendix A. Problems with Passwords Appendix A. Problems with Passwords
By far the most common mechanism for web authentication is passwords By far the most common mechanism for web authentication is passwords
that can be remembered by the user, called "memorizable passwords". that can be remembered by the user, called "human-memorable
There is plenty of good research on how users typically use passwords". There is plenty of good research on how users typically
memorizable passwords ([[ handful of citations goes here ]]), but use human-memorable passwords (e.g. see [bonneau]), but some of the
some of the highlights are that users typically try hard to reuse highlights are that users typically try hard to reuse passwords on as
passwords on as many web sites as possible, and that web sites often many web sites as possible, and that web sites often use either email
use either email addresses or users' names as the identifier that addresses or users' names as the identifier that goes with these
goes with these passwords. passwords.
If an attacker gets access to the database of memorizable passwords, If an attacker gets access to the database of memorizable passwords,
that attacker can impersonate any of the users. Even if the breach that attacker can impersonate any of the users. Even if the breach
is discovered, the attacker can still impersonate users until every is discovered, the attacker can still impersonate users until every
password is changed. Even if all the passwords are changed or at password is changed. Even if all the passwords are changed or at
least made unusable, the attacker now possesses a list of likely least made unusable, the attacker now possesses a list of likely
username/password pairs that might exist on other sites. username/password pairs that might exist on other sites.
Using memorizable passwords on unencrypted channels also poses risks Using memorizable passwords on unencrypted channels also poses risks
to the users. If a web site uses either the HTTP Plain to the users. If a web site uses either the HTTP Plain
authentication method, or an HTML form that does no cryptographic authentication method, or an HTML form that does no cryptographic
protection of the password in transit, a passive attacker can see the protection of the password in transit, a passive attacker can see the
password and immediately impersonate the user. If a hash-based password and immediately impersonate the user. If a hash-based
authentication scheme such as HTTP Digest authentication is used, a authentication scheme such as HTTP Digest authentication is used, a
passive attacker still has a high chance of being able to determine passive attacker still has a high chance of being able to determine
the password using a dictionary of known passwords. the password using a dictionary of known passwords.
[[ Say a bit about non-memorizable passwords. Still subject to Note that passwords that are not human-memorable are still subject to
database attack, although that doesn't give the attacker knowledge database attack, though are of course unlikely to be re-used across
for other systems. Safe if digest authentication is used, but that's many systems. Similarly, database attacks of some form or other will
rare. ]] work against any password based authentication scheme, regardless of
the crytographic protocol used. So for example, zero-knowledge or
Appendix B. Examples PAKE schemes, though making use of elegant cryptographic protocols,
remain as vulnerable to what is clearly the most common exploit seen
when it comes to passwords. HOBA is however not vulnerable to
database theft.
[[ Will add more later and probably use example.org. Note these Appendix B. Example
still use the -01 version of the "origin" abnf production. ]]
The following values show an example of HOBA-HTTP authentication to The following values show an example of HOBA-http authentication to
the origin https://hoba-local.ie. Carriage-returns have been added the origin https://hoba-local.ie. Carriage-returns have been added
and need to be removed to validate the example. and need to be removed to validate the example.
-----BEGIN PRIVATE KEY----- -----BEGIN PUBLIC KEY-----
MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDNF6tZUbsM7ZrO MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3TpLg0kglmnZIXNQZ6g6
5Lyzvn15lJAfOz7j7xdc3hmeSOfh/DCiJWwE5qqffrOvOvXYN+qUTlsXPeBYdrz/ Aj6b9PAhHD1TojOiuJZAY8KblNu-0WbiUSwTzl1EPBCa4Og3SNR0-8omb09iDSTV
my0YYC02u2QFhDbFRvpM/EuMzZUWTQzkKyU7nSjtPqlLZJJ/Rh6PnjTgImoIMn92 nKGEYcAHxP2wvvqOFrb6f8GWFHxHw4MiODlnSTvHARx6wiogY4w7WIs57ETZfiJY
JZgJZgl/vzd29K5Z94JzdJ4Z5bNmQ/gCpjlv0Wvi+GpJ3lDo1csDEyxATxyTUx1J MYyo6swHXO4DofteTasjuQwZ_5L4sbCR_aZx7Nsv4O4hNhCreoCfh0QD6pQQ-krW
K73+/RPoNgUF9nrXN6kqeH7RkERRz+PFhfGM6r3tU5povJxOP0bzVl6R4kptWLn2 0Ny8mGEecnAG0reXRgBvCmDq2I15jV8yqXuNYqEORO-vur2-JztH8pQUoSTfTkMv
GqDb5LS9iwzsk6YHWQcLOIAMVZ9ITPN2PSuQX0ym81B9qB1V6fTfo2r0Yo1Djn6C h0EyVfWzq9KtykKWXyv625CGVkxR3MMAfitxKgtZit0hw9_VCXtfhvwZcfnhmhxG
YRX62p4dAgMBAAECggEBAJiyWLcFrPhxJ2OG1iAVYaJVxAAcwjQ+XOydyAEbUtnk ZQIDAQAB
Q+lVZ1k2zC43zVxXz5aN+y80L4ncXd4/eXPteuO9J6yqVEvvJkA3GkCbTzykC64w -----END PUBLIC KEY-----
67otjWkXF9ObZbxmQtRTxokzRzbhKIS15ER4tPu6ZrQgEBGXFwCQ0SVY3CV36dvm Key Identifier: kzd-WBLsWtHQV6wiZgNd6t5rjR-1X267UetbAfkWHbw
xU2Y90wf98BGQF5VO47S9h8N/VtBn1ttI/6BhQHGsM+TbRR0b6oT9Mp/kqh5jZ2P
dH/l7Q6aj6zeFYljvI6HUpjc0mVOSKPAO0qYLZNYC0sqXxW9vCtEODziFZwrO2tL
jm14/H8+AZvtR6ZvbzP8h3G95PNdG4Z1eGZv5pOoJoECgYEA8omsyssjVgLIon60
Q6h3EjOi8I+mfvXYXcAZhv/1MnojFZgMLmuZ13Lgi3dIHYFNYGFRi8g9iYU/Ljtf
G3B9o6PQsvL0yym85TZzF/yn+kbinHR2yQUiA1Ck1rnrFx8dla/BjAplPxumyh/z
HyNFplVbOeRQS4K5F72wScuB9DECgYEA2Hnq1OSLetl4lrGAEHDoiIKw++ACQ/Tn
w5O+xAxOXr9iOmczwpHls+zFSQHty4za8C/tBLxg6HCHKZSO4lh+p5SR21UNgwfr
X6xBZ4xoH9zHTFdD2yrHdxAoItdT5oMTAUNHxDS8kcSY1+YcjRs2T4kcONIxeBlp
O++dxK9I6a0CgYEAp52WGSCCbzLFTeea1RdcEuw0s2PTgPKOcVwNSEskPZpDHO1T
ndEnJMpzfG8XG6z8uJsJLD1aqeu4Wk8Vz3TSn4Da/pEBtFZIAXC74dvuivzqJ44l
eY9ejkPxZ6RdYEFUxNoOPKYCiralchLahq5tuCJNRZkQFN9m441og9dtHEECgYEA
qnvRqlpXUqfEZYFi5w/UwfWTJrozbouInylTOpiqe8njtTUjuV8ndPzKHoYrXXwP
zMshsfIdq9E7UU7S/IVPMfE6sW6ZVpE9GDrTw5X7RuSb/I5ZPVjCgA00XsQQKmEd
7YesFGSoAXDAIn/yClrc+eR0WneHSBtTGkXKjWSyWn0CgYAlHdG3wj/sOL+JI7p8
fgSoRpkrbjfrczqSCDVFbT84sUz3dXObZecrI3v0XUZySakIDha5ZbxXNST/bfea
kReKsoeFY9J7os0hbfGwxiCQwD3wN9tS2yJbJYl1mCFc45YfylkXBzB0S2V/i6rv
vCWW1nijRb+WhpUF8HyKW64bxA==
-----END PRIVATE KEY-----
Key Identifier: Zhh5vD5ovE0NqTDOufSUFRu5dzZMe-KOrMX2cN3vqWw
Challenge: zzrYL7BaOQtlzOsl4fMY+EYcG4eT2h+JXi+jEGzozQ0= Challenge: z4TUcgVzBXZAHPkQdolngviExx5k+pbhC3sHnBP0JUs=
Nonce: xXSFdZ-7ahM Nonce: LV_WTVyHFfE
Tbsorigin: httpshoba-local.ie443 Tbsorigin: https://hoba-local.ie:443
The resulting signature is: The resulting signature is:
r1ZXAWPXpzkd9iyI9TvwNYb0LT6Nth4WRYL4ciLZD6Wvvsni8AYLduUEPdo5ezfo qiMi54cNiP_bv7cVus7JuwEmkDXk_yyNjXx0QGUCQNtXrSjoWP7E2sdjIT_iZajb
K__W_Hi4nyHmtRzPpAW9YSGhsyYOd7GSZH7Kd6ncCPVBQuHQdHI5n6OJslitD7hK zb9lO2fYCUcD8M-MQBttKziG7n9HUaRGZzWIY-028tIvL-eLa8t6tEJtqrnqtR84
t4bCtP3zGxkg_W71KGU2RXcQDfcTNmFcs2ice8RrrvNh1lzRViHO-scV0VNBk19J O2oPtn6CYL5my9_VdbE4krmV545ZzOitHPp18745BU4q_POiaidULwEj75lPkX57
LTUyaisiNKq-sNK14_RIG6AeivAGxLlXnN_RzttNe5d0XrXJ1nRUSFmeN6ZfVHE7 2ehWXyk3Gaz_TiduN7gMhulrg9d4Uu5eQWfMmxWFQ0kgg8e2Y8YEFicitkdQBDqX
qf6lORqaMeyqsDoJe1MIyISn6sCGzMZmplizNw_eg2QJIJX3Txat9mTfT5UZYyUq PwkwdYAA7HcCAI-iEEEWxNccJYaGjrWEs_00CKhjtRjCDnTNgPzmF4nqM6UT_ww9
8meaqRXMhoQWHGLweFTNYw XO593LaL3LnykmMn11ddiw
The final HTTP header field sent with a request is then: The final HTTP header field sent with a request is then:
Authorization: result="Zhh5vD5ovE0NqTDOufSUFRu5dzZMe-KOrMX2cN3vq Authorization: HOBA result="kzd-WBLsWtHQV6wiZgNd6t5rjR-1X267Uetb
Ww.zzrYL7BaOQtlzOsl4fMY+EYcG4eT2h+JXi+jEGzozQ0=.xXSFdZ-7ahM.r1ZX AfkWHbw.z4TUcgVzBXZAHPkQdolngviExx5k+pbhC3sHnBP0JUs=.LV_WTVyHFfE
AWPXpzkd9iyI9TvwNYb0LT6Nth4WRYL4ciLZD6Wvvsni8AYLduUEPdo5ezfoK__W .qiMi54cNiP_bv7cVus7JuwEmkDXk_yyNjXx0QGUCQNtXrSjoWP7E2sdjIT_iZaj
_Hi4nyHmtRzPpAW9YSGhsyYOd7GSZH7Kd6ncCPVBQuHQdHI5n6OJslitD7hKt4bC bzb9lO2fYCUcD8M-MQBttKziG7n9HUaRGZzWIY-028tIvL-eLa8t6tEJtqrnqtR8
tP3zGxkg_W71KGU2RXcQDfcTNmFcs2ice8RrrvNh1lzRViHO-scV0VNBk19JLTUy 4O2oPtn6CYL5my9_VdbE4krmV545ZzOitHPp18745BU4q_POiaidULwEj75lPkX5
aisiNKq-sNK14_RIG6AeivAGxLlXnN_RzttNe5d0XrXJ1nRUSFmeN6ZfVHE7qf6l 72ehWXyk3Gaz_TiduN7gMhulrg9d4Uu5eQWfMmxWFQ0kgg8e2Y8YEFicitkdQBDq
ORqaMeyqsDoJe1MIyISn6sCGzMZmplizNw_eg2QJIJX3Txat9mTfT5UZYyUq8mea XPwkwdYAA7HcCAI-iEEEWxNccJYaGjrWEs_00CKhjtRjCDnTNgPzmF4nqM6UT_ww
qRXMhoQWHGLweFTNYw" 9XO593LaL3LnykmMn11ddiw"
Authors' Addresses Authors' Addresses
Stephen Farrell Stephen Farrell
Trinity College Dublin Trinity College Dublin
Dublin 2 Dublin 2
Ireland Ireland
Phone: +353-1-896-2354 Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie Email: stephen.farrell@cs.tcd.ie
 End of changes. 61 change blocks. 
231 lines changed or deleted 273 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/