[Dcplusplus-commit] SF.net SVN: adc:[30] trunk/ADC-EXT.txt

[<ul...@us...>]

Revision: 30
          http://adc.svn.sourceforge.net/adc/?rev=30&view=rev
Author:   ullner
Date:     2010-09-26 17:43:50 +0000 (Sun, 26 Sep 2010)

Log Message:
-----------
Starting 1.0.6;
Added KEYP extension; note that the URI is slightly changed from the 'original' KEYP wiki entry; some wording changed to be more simple to grasp. 
Note that ADCS is not added at this point in time, just yet. ADCS is not needed at this point particularly, since the KEYP spec only relies on a) the URI (which is simply the same as the standard URI with an 's' appended) and b) the general use of "certificates".

Modified Paths:
--------------
    trunk/ADC-EXT.txt

Modified: trunk/ADC-EXT.txt
===================================================================
--- trunk/ADC-EXT.txt	2010-09-16 19:11:35 UTC (rev 29)
+++ trunk/ADC-EXT.txt	2010-09-26 17:43:50 UTC (rev 30)
@@ -1,6 +1,6 @@
 = ADC Extensions
 Fredrik Ullner <ul...@gm...>
-1.0.5, September 2010
+1.0.6, September 2010
 
 == Abstract
 These are the official extensions to ADC. This document is based on the
@@ -42,6 +42,9 @@
 * Added hidden in enumeration of CT field in INF.
 * Added error code Invalid feature in STA.
 
+=== Version 1.0.6 UNRELEASED
+* Added KEYP extension for providing certificate substitution protection in ADCS.
+
 == Extensions
 
 === TIGR - Tiger tree hash support
@@ -491,4 +494,64 @@
 |48 |Invalid feature. Flag "FC" is the FOURCC of the invalid feature(s). If multiple features are invalid, use comma between the features (i.e. FCQWER,ASDF,ZXCV).
 |=====
 
+=== KEYP - Certificate substitution protection in ADCS (Secure ADC)
+This extension adds a simple, but secure way to protect against man-in-the-middle attacks against ADC when wrapped with TLS (1.0 or later). It does not require setting up a CA or signing keys, but possible if desired.
+
+The extension introduce a keyprint parameter to the ADCS URI. The keyprint parameter is a hash of either the certificate signing the server certificate (in a CA-style key-signing configuration) or, simply, the server certificate itself (in a self-signed configuration). 
+
+The extension also require that clients should publish their own certificates' keyprint in the KP field in the INF. Assuming one trusts the hub enough not to maliciously change the keyprints en route (a reasonable assumption given the hub's existing position of trust), and given that the connection to the hub has been similarly authenticated (either as above or via a directly downloaded trusted certificate), client-client connections are also protected against attempted man-in-the-middle attacks - without messing around having to get everyone's certificates signed in advance.
+
+The keyprint parameter consist of a hash name, followed by a forward slash ('/'), followed by the Base32-encoded cyrptographic hash of either the certificate directly (which is appropriate in the case of a self-signed certificate), or a certificate providing the base of a valid signature chain (which may be more appropriate a CA-signed certificate). 
+
+The hash used shall be SHA256. Other extensions may add other hashes, given sufficient security contemplation.
+
+INF field;
+[options="autowidth"]
+|=====
+|KP |The client's own certificate keyprint.
+|=====
+
+==== Keyprint replacement behaviour
+If a client receives a KP field in an FINF broadcast via a hub to it is connected using ADCS and a trusted key as above (or otherwise), it should be regarded as the valid and correct keyprint for that client's IP/port/hub combination, replacing any earlier keyprint for that IP/port/hub combination. 
+
+==== Keyprint verification
+When initiating a TLS handshake with a remote host where the keyprint is known, the client can verify that a man-in-the-middle attack is not occurring by checking if the hash given in the keyprint matches exactly: 
+
+* a root certificate presented in a valid signature chain which covers the certificate presented during the handshake by the remote host; or 
+* the entire certificate presented during the handshake by the remote host. 
+
+Suppose the client is aware of a remote host's keyprint and is in the process of connecting to that host. A certificate substitution attack is in place if the hub presents itself with a certificate that does not match and where the certificate is not the root of the valid signature chain covering the certificate.
+If the client detect such an attack, the client MUST abort the connection with a user-visible, non-modal error stating, for example, "Crypto error: Detected attempted man-in-the-middle attack, aborting". (This error quite possibly represents a real attempted attack that has been foiled; we may try auto-reconnecting but we should NEVER ignore it, or it will succeed. We may wish to avoid stating the keyprint of the certificate that was actually received.) 
+
+Optionally, when receiving a TLS handshake, if the client know what the remote host's keyprint ought to be, the client could also verify this. However, note that only the initiating side needs to check this for the man-in-the-middle protection to be valid; specifically the hub doesn't need to remember, or even understand, clients' keyprints. 
+
+==== Security Considerations 
+===== General 
+The certificates, including the name fields, are sent in the clear during the initial handshake. Therefore it is recommended to avoid identifying marks in the certificates CommonName fields (for example) that would clearly single them out as being TLS keys used by ADCS:, and the CID field most definitely should not appear. Quite possibly no name fields should appear, or they should be blank. 
+
+===== Client-Hub 
+The keyprint in the ADCS URI prevents a clandestine man-in-the-middle (certificate substitution) attack on the TLS session with the hub, if and only if the kp parameter hasn't been modified by an attacker. 
+
+Suggested countermeasures against this include the following;
+
+* Even if otherwise unprotected, an attacker would likely only have a maximum of one opportunity to make the substitution (by changing the kp parameter when the URL is first sent to the user); if it's changed later, it will be detected. ("Casual first-use" security, as often used in SSH.) 
+
+* Checking the fingerprint or transferring the hub URL out-of-band (for example by telephone, or in person) could reveal or thwart man-in-the-middle attacks; something's wrong if you don't have the same URL as the hub operator gives out. (PGP-style "sneakernet" security.) 
+
+* We would be protected if the URL were in a file signed by some secure means by a party we have already decided we trust not to change the URLs maliciously. Encryption would not be necessary, only a signature to ensure no untrusted party has modified the KP fields. (A signed hublist, possibly.) 
+
+Finally, we would be protected were the hublist/URL retrieved from an https: site signed by a CA we trust not to issue signatures for any domain to someone who doesn't own that domain, and the owner of that domain trusted not to modify the KP fields. (SSL-style security.) 
+
+===== Client-Client
+We are, in particular, trusting the hub not to maliciously modify the KP fields sent by the clients through their INF broadcasts. However;
+
+* The hub would gain nothing from swapping the keyprints of its users, as it would not gain anything from mounting a man-in-the-middle attack on its own users that it does not already have the ability to do, as it's the hub; and 
+* If the client do not trust the hub enough not to maliciously modify the data, why is the client choosing to connect to the hub and transmit the client's IP address through the hub? 
+* It could be detected by cross-checking with other clients/hubs, as connecting through a malicious hub would clearly show to have a different keyprint to any other hub; therefore any hub doing this would obviously be quickly removed from hublists. 
+
+==== Example
+====
+adcs://example.com:1234/kp?SHA256/G3PJC4F4MQ5KOXGE2MPYJW5EW63IC6M7RN7OS663JLLWN2M5I6FQ
+====
+
 // vim: set syntax=asciidoc:


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.