draft-ietf-httpauth-hoba-06.txt   draft-ietf-httpauth-hoba-07.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 8, 2015 VPN Consortium Expires: June 12, 2015 VPN Consortium
M. Thomas M. Thomas
Phresheez Phresheez
December 5, 2014 December 9, 2014
HTTP Origin-Bound Authentication (HOBA) HTTP Origin-Bound Authentication (HOBA)
draft-ietf-httpauth-hoba-06 draft-ietf-httpauth-hoba-07
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 8, 2015. This Internet-Draft will expire on June 12, 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 16 skipping to change at page 2, line 16
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . 10
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.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 12 6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 13
6.2. Associating Additional Keys to an Exiting Account . . . . 14 6.2. Associating Additional Keys to an Exiting Account . . . . 14
6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 14 6.2.1. Moving private keys . . . . . . . . . . . . . . . . . 15
6.2.2. Human memorable one time password (don't do this one) 14 6.2.2. Human memorable one time password (don't do this one) 15
6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 15 6.2.3. Out of band URL . . . . . . . . . . . . . . . . . . . 15
6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 15 6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 16
7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 16 7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8.1. Privacy considerations . . . . . . . . . . . . . . . . . 16 8.1. Privacy considerations . . . . . . . . . . . . . . . . . 17
8.2. localStorage Security for Javascript . . . . . . . . . . 17 8.2. localStorage Security for Javascript . . . . . . . . . . 17
8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 18 8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 18 9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 18
9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 18 9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 19
9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 19 9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 19
9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 19 9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 19
9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 19 9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 20
9.6. Hobareg HTTP Header . . . . . . . . . . . . . . . . . . . 20 9.6. Hobareg HTTP Header . . . . . . . . . . . . . . . . . . . 20
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Problems with Passwords . . . . . . . . . . . . . . 22 Appendix A. Problems with Passwords . . . . . . . . . . . . . . 23
Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 50 skipping to change at page 5, line 50
the CPK and the challenge string; and signs that blob with the the CPK and the challenge string; and signs that blob with the
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. defined.
HOBA-TBS = nonce alg origin [ realm ] kid challenge HOBA-TBS = len ":" nonce
len ":" alg
len ":" origin
len ":" [ realm ]
len ":" kid
len ":" challenge
len = 1*DIGIT
nonce = 1*base64urlchars nonce = 1*base64urlchars
alg = 1*2DIGIT alg = 1*2DIGIT
origin = scheme "://" authority ":" port origin = scheme "://" authority ":" port
realm = unreserved realm = unreserved
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
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
following field, expressed as a decimal number in ASCII [RFC0020].
Lengths are separated from field values by a colon character. So
if a nonce with the value "ABCD" were used then that would be
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].) UAs MUST be able to use at
least 32 bits of randomness in generating a nonce. UAs SHOULD be least 32 bits of randomness in generating a nonce. UAs SHOULD be
able to use 64 or more bits of randomness for nonces. 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 an
ASCII character as defined in Section 9.3. RSA-SHA256 MUST be ASCII character 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
skipping to change at page 6, line 41 skipping to change at page 7, line 7
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 [RFC7235]. If no realm is specified for this defined in [RFC7235]. If no realm is specified for this
authentication then this is absent. (A missing field here is no authentication then this is absent, but is preceeded by a length
problem since both sides know when it needs to be there.) of zero ("0:"). Recall both sides know when this needs to be
there independent of the encoding via a zero length.
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 21, line 12 skipping to change at page 21, line 34
current (-04) version of HOBA and is available from https://hoba.ie/ current (-04) version of HOBA and is available from https://hoba.ie/
which site 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: Amos Jeffries, Benjamin Kaduk, preparation of this specification: Amos Jeffries, Benjamin Kaduk,
Matt Lepinski, Ilari Liusvaara, James Manger, Alexey Melnikov, Yoav Watson Ladd, Matt Lepinski, Ilari Liusvaara, James Manger, Alexey
Nir, Mark Nottingham, Julian Reschke, Michael Richardson, Yaron Melnikov, Yoav Nir, Mark Nottingham, Julian Reschke, Michael
Sheffer, and Michael Sweet. All errors and stupidities are of course Richardson, Yaron Sheffer, and Michael Sweet. All errors and
the editors' fault. 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,
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.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
skipping to change at page 23, line 26 skipping to change at page 23, line 50
Note that passwords that are not human-memorable are still subject to Note that passwords that are not human-memorable are still subject to
database attack, though are of course unlikely to be re-used across database attack, though are of course unlikely to be re-used across
many systems. Similarly, database attacks of some form or other will many systems. Similarly, database attacks of some form or other will
work against any password based authentication scheme, regardless of work against any password based authentication scheme, regardless of
the crytographic protocol used. So for example, zero-knowledge or the crytographic protocol used. So for example, zero-knowledge or
PAKE schemes, though making use of elegant cryptographic protocols, PAKE schemes, though making use of elegant cryptographic protocols,
remain as vulnerable to what is clearly the most common exploit seen remain as vulnerable to what is clearly the most common exploit seen
when it comes to passwords. HOBA is however not vulnerable to when it comes to passwords. HOBA is however not vulnerable to
database theft. database theft.
The repeated length fields in the HOBA-TBS structure are present in
order to ensure that there is no possibility that the catenation of
different input values can cause confusion that might lead to an
attack, either against HOBA as specified here, or else an attack
against some other protocol that re-used this to-be-signed structure.
Appendix B. Example Appendix B. Example
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://example.com:443 Carriage-returns have been added
and need to be removed to validate the example. and need to be removed to validate the example.
Public Key:
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3TpLg0kglmnZIXNQZ6g6 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviE8fMrGIPZN9up94M28
Aj6b9PAhHD1TojOiuJZAY8KblNu-0WbiUSwTzl1EPBCa4Og3SNR0-8omb09iDSTV 6o38B99fsz5cUqYHXXJlnHIi6gGKjqLgn3P7n4snUSQswLExrkhSr0TPhRDuPH_t
nKGEYcAHxP2wvvqOFrb6f8GWFHxHw4MiODlnSTvHARx6wiogY4w7WIs57ETZfiJY fXLKLBbh17ofB7t7shnPKxmyZ69hCLbe7pB1HvaBzTxPC2KOqskDiDBOQ6-JLHQ8
MYyo6swHXO4DofteTasjuQwZ_5L4sbCR_aZx7Nsv4O4hNhCreoCfh0QD6pQQ-krW egXB14W-641RQt0CsC5nXzo92kPCdV4NZ45MW0ws3twCIUDCH0nibIG9SorrBbCl
0Ny8mGEecnAG0reXRgBvCmDq2I15jV8yqXuNYqEORO-vur2-JztH8pQUoSTfTkMv DPHQZS5Dk5pgS7P5hrAr634Zn4bzXhUnm7cON2x4rv83oqB3lRqjF4T9exEMyZBS
h0EyVfWzq9KtykKWXyv625CGVkxR3MMAfitxKgtZit0hw9_VCXtfhvwZcfnhmhxG L26m5KbK860uSOKywI0xp4ymnHMc6Led5qfEMnJC9PEI90tIMcgdHrmdHC_vpldG
ZQIDAQAB DQIDAQAB
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
Key Identifier: kzd-WBLsWtHQV6wiZgNd6t5rjR-1X267UetbAfkWHbw Origin: https://example.com:443
Challenge: z4TUcgVzBXZAHPkQdolngviExx5k+pbhC3sHnBP0JUs= Key Identifier: vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w
Nonce: LV_WTVyHFfE Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=
Tbsorigin: https://hoba-local.ie:443 Nonce: Pm3yUW-sW5Q
The resulting signature is: Signature:
qiMi54cNiP_bv7cVus7JuwEmkDXk_yyNjXx0QGUCQNtXrSjoWP7E2sdjIT_iZajb VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0i
zb9lO2fYCUcD8M-MQBttKziG7n9HUaRGZzWIY-028tIvL-eLa8t6tEJtqrnqtR84 4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miUz
O2oPtn6CYL5my9_VdbE4krmV545ZzOitHPp18745BU4q_POiaidULwEj75lPkX57 q04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrKP
2ehWXyk3Gaz_TiduN7gMhulrg9d4Uu5eQWfMmxWFQ0kgg8e2Y8YEFicitkdQBDqX tG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr9
PwkwdYAA7HcCAI-iEEEWxNccJYaGjrWEs_00CKhjtRjCDnTNgPzmF4nqM6UT_ww9 6ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9kI
XO593LaL3LnykmMn11ddiw S13qQA43m4IMExkbApqrSg
The final HTTP header field sent with a request is then: Authorization Header:
Authorization: HOBA result="kzd-WBLsWtHQV6wiZgNd6t5rjR-1X267Uetb Authorization: HOBA result="vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-
AfkWHbw.z4TUcgVzBXZAHPkQdolngviExx5k+pbhC3sHnBP0JUs=.LV_WTVyHFfE k_L6t3w.pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=.Pm3yUW-sW5Q
.qiMi54cNiP_bv7cVus7JuwEmkDXk_yyNjXx0QGUCQNtXrSjoWP7E2sdjIT_iZaj .VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0
bzb9lO2fYCUcD8M-MQBttKziG7n9HUaRGZzWIY-028tIvL-eLa8t6tEJtqrnqtR8 i4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miU
4O2oPtn6CYL5my9_VdbE4krmV545ZzOitHPp18745BU4q_POiaidULwEj75lPkX5 zq04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrK
72ehWXyk3Gaz_TiduN7gMhulrg9d4Uu5eQWfMmxWFQ0kgg8e2Y8YEFicitkdQBDq PtG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr
XPwkwdYAA7HcCAI-iEEEWxNccJYaGjrWEs_00CKhjtRjCDnTNgPzmF4nqM6UT_ww 96ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9k
9XO593LaL3LnykmMn11ddiw" IS13qQA43m4IMExkbApqrSg"
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. 30 change blocks. 
54 lines changed or deleted 78 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/