Page 4 of 4

Re: ADCS Drafting (Official Discussion Here)

Posted: 14 Feb 2010, 04:52
by cologic
Currently the GPA/PAS command pair effectively requires plaintext hubside password storage. This is problematic because it forces a choice between encrypting passwords locally and encrypting passwords in transmission. Sans ADC, this is a perhaps necessary tradeoff. With ADCS, one can do both, because one can send a password 'in the clear' in the encrypted channel and then check that against a password stored locally in an arbitrary hashed format and combine both advantages.

I propose that ADCS include an alternate login procedure that obviates this mutual exclusivity by having a client send (only if ADCS is active) the password without modification.

Re: ADCS Drafting (Official Discussion Here)

Posted: 07 Mar 2010, 16:14
by Quicksilver
As this seems not to go on... and as we already discussed GPA/PAS as it is vs the benefit /downsides in the hub. So far my recommendation for what should become "ADCS":

Purpose: yaddah yaddah some security against ouside eavesdroppers..


How to achieve: (In one line: TLS+Allow clients to use KEYP+ all searches done passive except between SUDP supporting clients)

All TCP connections -> use TLS 1.0

Hubs should be aware of the enhacement protocols available for ADCS (which are all work in progress):

i.e. KEYPRINT (optional) : hublists should provide access to their hublist.xml over HTTPS -> (keyprint could be put into clients to verify hublist)
hublists could provide KEYPRINT of hubs to clients -> verification gap closed.
Hubs should forward Keyprints of clients in their INFs. ADCS hub should not ommit KP flag from clients! ADCS hubs should check KP flags! -> conjecture: clients have to provide their (self singed) certificates even if on clientside of TLS. If a client provides a bad KP flag it should get a STA message with severity "Fatal".

client client connections should be closed if a user provides a CID/TOKEN that does not match to the Keyprint of the connection. (if incoming connection). Outgoing connections must be closed as soon as wrong KEYPRINT is detected on handshake.

SUDP(optional): A hub supporting ADCS must ommit UDP4/UDP6 in SU flag and U4/U6 flags in all INFs sent to a client.
Except the receiver and the sender of the INF both specify support for SUDP. ( -> without SUDP searches should be done passive)



might have forgotten some things... please comment

Re: ADCS Drafting (Official Discussion Here)

Posted: 09 Mar 2010, 20:21
by Quicksilver
minimal change

user TLS 1.0 becomes use TLS 1.0 or later (clients/hubs need to support TLS1.0 though can use later version if present on both sides)

Re: ADCS Drafting (Official Discussion Here)

Posted: 04 Sep 2010, 10:38
by Quicksilver
Clarification

"... should be closed if a user provides a CID/TOKEN that does not match ..."

CID/TOKEN refers to the information received in Client/Client protocol to indentify the other party in case of an incoming connection.
In an outgoing connection you know the other beforehand and therefore don't need this to find out which KP matches the connection.

Re: ADCS Drafting (Official Discussion Here)

Posted: 20 Sep 2010, 14:08
by darkKlor
Assuming I've got it right that the client KeyPrint is the SHA256 hash of the client's TLS certificate, then is a CID/PID even necessary? Or rather, should the CID actually be the KeyPrint when a client or hub is in ADCS mode, and the PID removed completely?

The goal of the PID was to have a unique ID for each client, and it was withheld from other clients to prevent spoofing. The CID is a hash of the PID, so although others can see it, it is very difficult to reverse engineer.

The client's TLS certificate combined with KEYP, as QS suggests, should provide this protection, I think? So rather than add an extra INF field KP, why not just use the CID field and make the hub process ADCS connections differently? If the KeyPrint is bad, then it's just the same old Invalid CID error.

Also, for a hub where users can register, can the hub issue a certificate to the user upon registration, with the hub acting as CA? This would let the hub trust all registered users more highly. Protection of the client certificate store is a potential threat though. If used in conjunction with the above, then the CID becomes a per-hub ID (when registered) so you would lose the ability to track a user across hubs via CID, and you could identify individual file shares by CID, to allow different shares across hubs. Hub owners would be less able to issue retribution for users sharing in other hubs, because the only identifier left would be the IP, and the obvious argument would be that they're behind a router.

Re: ADCS Drafting (Official Discussion Here)

Posted: 22 Sep 2010, 04:44
by cologic
darkKlor wrote:Assuming I've got it right that the client KeyPrint is the SHA256 hash of the client's TLS certificate, then is a CID/PID even necessary? Or rather, should the CID actually be the KeyPrint when a client or hub is in ADCS mode, and the PID removed completely?
Main issue I see is that it makes mixed ADC/ADCS hubs harder because it bleeds over somewhat into non-ADCS ADC implementations which are exposed via C-C connections to ADCS implementations. I don't have a strong opinion about how problematic or not this would be, however.
darkKlor wrote:Also, for a hub where users can register, can the hub issue a certificate to the user upon registration, with the hub acting as CA? This would let the hub trust all registered users more highly. Protection of the client certificate store is a potential threat though. If used in conjunction with the above, then the CID becomes a per-hub ID (when registered) so you would lose the ability to track a user across hubs via CID, and you could identify individual file shares by CID, to allow different shares across hubs. Hub owners would be less able to issue retribution for users sharing in other hubs, because the only identifier left would be the IP, and the obvious argument would be that they're behind a router.
Assuming a shared, single CID across multiple hubs represents a functionally identical user has shown itself an ADC design failure. Per FleetCommand's and others' observations regarding PM routing, CTM routing (when one is on hubs with different requirements), etc the 'solutions' have ended up being to try to engineer per-hub user specificity back. Thus, losing the ability to track a user across hubs I regard as advantageous insofar as it represents a more useful set of assumptions about the interchangeability of hubs.

However, my qualms with that underlying approach aside and operating within an essentially ADC frame, how would you propose that two clients connect introduce each other within a C-C connection? Currently they start by sharing CIDs. Choosing which CID to present to the other client presents a bootstrapping problem akin to operating in a NMDC-like pre-ADC environment not completely solvable either deterministically, per this blog post or heuristically, per this blog post. Thus I don't see how a single client, barring using multiple listening ports, can present more than a single CID to the world for any reason, including to implement your hub-as-CA-with-CID-replaced-by-keyprint suggestion.

Re: ADCS Drafting (Official Discussion Here)

Posted: 26 Sep 2010, 18:34
by Quicksilver
I have had 3 ideas about that

1. one port per hub
2. strictly timing connectiongs / determining IPs if possible before allowing connections (if IP unknown don't send out CTMs for multiple users with unknown IPs)
3. mixed solution of 1+2 ..


1. is simple but not every nice..
2. is highly complicated, bugprone and will not work with multiple users with same IP
3. combines most disadvantages but can solve the multiple users with same IP problem..


so yes cologic is 100% right! multiple CIDs are a problem.. and the 3 above are just nothing practical..

Re: ADCS Drafting (Official Discussion Here)

Posted: 23 Nov 2010, 23:33
by Pretorian
Having read this thread a few times, I've concluded that "ADCS" will never be finalized since people will either continue discuss about the same thing, or someone else will come in and start a new discussion about something else.

The discussion, as far as I've observed, is now;
a) How should the login-sequence look in 'secure ADC'?
b) How does CID/PID fit in the picture of 'secure ADC'?
c) Who should generate/validate certificates?

Looking at the current state of the discussion regarding a), I don't think anyone will ever come up with a satisfactory specification (or implementation) in the near future. I propose that a) should be a different protocol extension than 'ADCS'.

I think the difficulty of deciding how b) can be adequately answered lies in that, I think, it is technically not specific to 'secure ADC'. Hell, people aren't sure whether one or multiple CIDs should be generated, without resorting to the hub-specific ports that cologic mentioned.

As an extension of b), I think an additional item ("d)"), should be added to what is "unclear" about 'secure ADC'; whether the client should generate one or multiple certificates, but this is essentially the same problem (and solution) as b).

As to who generates and/or validates the certificates, I have no idea. The problems are that 1) it would cost too much to buy a "real" certificate that we can use as root certificate, 2) we (someone) could create a root certificate that can later be used and 3) it is a nightmare trying to maintain something any certificate-validation-or-generation service.

Given that we now have KEYP and SUDP, I think we simply, at the moment, need to specify general certificate management; which I think we have in the current specification of ADCS. Further, that any other additional proposals regarding 'secure ADC' should be separate extensions.

Re: ADCS Drafting (Official Discussion Here)

Posted: 24 Nov 2010, 00:16
by Pretorian
jvk suggested something that I can agree with; 'ADCS' is simply "encrypted ADC connections". Whether they are secure or not, should not be in 'ADCS'.

Re: ADCS Drafting (Official Discussion Here)

Posted: 29 Nov 2010, 20:24
by Pretorian
"Symmetrical Encryption in ADC", "ADCS", have now been pushed to ADC-Ext 1.0.6.