Page 2 of 4

Re: ADCS Drafting (Official Discussion Here)

Posted: 20 Aug 2009, 01:51
by darkKlor
With client-client comms, it would be nice if you could look at the certificate that the other client sends you, and see that it has been issued by the hub you're connected to.

I think defining the level of verification in the specification is important because then you can say that a compliant implementation meets a certain quality bar in terms of the protections it offers e.g. the client you connect to is guaranteed to be a member of the current hub (not an imposter), and the communication will be secure. Such verification steps are easy enough to unit test, there just needs to be a specification laid out.

Re: ADCS Drafting (Official Discussion Here)

Posted: 23 Sep 2009, 16:07
by darkKlor
to keep life simple (i.e. ignore certificates):
Diffie-Hellman + KEYP extension = win!??

there's probably plenty of Diffie-Hellamn code around that is GPL'd too, which may let us get rid of OpenSSL....

Re: ADCS Drafting (Official Discussion Here)

Posted: 28 Sep 2009, 13:03
by darkKlor
Attached is a draft of an ADCS proposal. Comments are welcome!

Re: ADCS Drafting (Official Discussion Here)

Posted: 29 Sep 2009, 00:07
by cologic
darkKlor wrote:Attached is a draft of an ADCS proposal. Comments are welcome!
Cosmetic comments:
1) Probably best to link to some actual TLS standard from the IETF rather than Wikipedia. There's TLS1.0, 1.1, and 1.2 available.
2) Potential stylistic issues exist. I'm going to ignore them for now, though, pending the next thing.

Less cosmetic:
3) Skeptical about the 'upgrade existing network' functionality. Complexity is hostile in any crypto-based protocol (how does one specify a preference for an encrypted hub? how long can it remain unencrypted? if someone wants to connect to an ADCS hub precisely so that they deal with encrypted users, they're hurt by the basically deceptive presence of lots of nonencrypting users. these aren't unsolvable, just pointless complexity) and there's not an installed base of nonencrypted ADCS hubs to speak of. Seems better to strongly encourage hubs to start life as ADCS rather than invent a legacy problem that can be completely avoided.

When I have more time to read through the supporting documents more thoroughly (SRP is new to me) I may have further comments.

Re: ADCS Drafting (Official Discussion Here)

Posted: 29 Sep 2009, 00:47
by darkKlor
how does one specify a preference for an encrypted hub? how long can it remain unencrypted?
The appendix hints at when it begins with upward negotiation, 'after feature negotiation' i.e. after SUP, before SID.
there's not an installed base of nonencrypted ADCS hubs to speak of
Don't know where you got that from... there IS an installed base of ADC hubs. I thought I made it fairly clear that upward negotiation is only for existing ADC hubs, so that the address and URL scheme of the hub need not change (the table on page 2). New hubs should use the ADCS prefix AND initiate TLS as soon as the socket connection is establish (i.e. before SUP).
If someone wants to connect to an ADCS hub precisely so that they deal with encrypted users, they're hurt by the basically deceptive presence of lots of nonencrypting users
Second last paragraph in the Appendix, "If a hub enables clients to establish a secure session, it should force all clients to establish a secure session, at threat of sessionā€termination. This is because if both secure and insecure sessions are allowed, information which one client sends securely becomes insecure when sent to an insecure client."

I've started writing the section for client-to-client connections, but at the moment it relies on the existance of client-to-hub encryption to simplify authentication. Establishing a secure session between two clients on an insecure hub is a little more challenging in terms of knowing who you're really connecting to (I mean, without both needing to have CA/hub-signed certificates, which poses infrastructure issues).

Re: ADCS Drafting (Official Discussion Here)

Posted: 29 Sep 2009, 23:05
by Dj_Offset
darkKlor wrote:Attached is a draft of an ADCS proposal. Comments are welcome!
I have quite a few. First of all thanks for taking your time to write a draft, that being said - there are so many issues I disagree strongly on in this current spec, and that are plainly omitted from the spec. But, since I haven't written a spec myself, I'd rather comment on what is written here.

Rationale
The hub registration method is weak i.e. password-based registration involves the transmission of passwords to the server in plain-text.
The current ADC spec does not address this issue at all, so it is therefore inaccurate to claim that the registration method is weak.
The hub authentication method is weak i.e. the hub cannot verify that a connection has not been hijacked in the establishment phase, or initiated by a client impersonating the registered user.
This reflects directly back to point #2 of the bullet list which addresses MITM attacks. Yes, as a concequence of a MITM a transparent proxy can for instance hijack a session after authentication. The authentication is not to blame for that though, and it does not indicate that it is weak - rather the opposite - it is strong since an attacker must do an active injection attack instead of a simple replay attack.

Connection Approach

"Separate port" and "Upgrade negotiation" is nice, but you totally miss the obvious 3rd option. Simply redirect to an adcs:// address.
There is no technical need for having a "separate port" to run TLS on - as such I don't see a point in overspecifying this point as it boils down to
implementation details.
That being said, "Upgrade negotiation" is very much vulnerable to downgrade attacks by a proxy simply eliminating "ADCS" as a viable feature.
I agree with cologic here, either you do ADCS or you don't.
Paranoid users need to use the "adcs://" prefix to signal to the client that an encrypted connection is to be expected here, nothing less is acceptable.

Situational Considerations
mutial authentication provides a higher level of assurance as to the identity of the parties.
Yes, that can be true.
Server authentication - only server is authenticated via certificate.
And a server can authenticate a user based on a shared secret - a password comes to mind.
Isn't that still mutual authentication?
...but also allow a hub owner to generate a self-signed certificate
Yes, I am all for self-signed certificates. But how are they verified?

Verification of Self-Signed Server Certificates

A-ha! :)
When a hub address is given to a user, it is appended with a cryptographic hash of the server's public key
KeyPrint as described here does not solve any issue itself, it now generates a couple of new issues:
  • First of all: Can you trust the link you got?
  • If the link you got contains a keyprint using an unsupported hash?
  • If the link you got contains an invalid keyprint - what are the potential recovery strategies?
  • If the link you got does not contain a keyprint - is it invalid, considered insecure, not secure, or dangerous?
As far as I can see, only the first issue is discussed in the Keyprint spec.

I think we can solve this problem better and simpler by aligning closer to the SSH model of the first "leap of faith" when connecting,
and then storing the public key for future sessions.
But keep in mind, we need to know what assets we are trying to protect by doing such an excersise.

Mutual authentication

This section made me jump!
the hub generates a certificate and sends it to the user via a new ADC protocol message (e.g. CRT, for certificate)
WTF - Basic crypto NO NO!
You don't own your own certificate any more. A more secure way to do it is for the client to generate a public key and a private key,
the public key (or "certificate") is transmitted to the hub (no transfer security needed), the hub signs the certificate and transmits
back the signature of the public key (no transfer security needed here either).

A new issues now is signing denial of service, since signing is a moderately heavy operation.


That's it for now.

Re: ADCS Drafting (Official Discussion Here)

Posted: 30 Sep 2009, 07:48
by darkKlor
With the hub signing the certificate, I'm suggesting that the hub acts as a Certificate Authority. A secure TLS session should already be established to register the user, but only server authentication will be in use. The delivery of the certificate should therefore be secure, as long as you as the hub owner trust the user you're sending it to. This approach means your certificate store on the client would contain per-hub certificates, but it enables the hub to verify that it was the CA within the TLS model.

I'm sending this from my phone and safari isn't rendering the page too well, so I'll have to answer your other concerns later when I can re-read them :P

Re: ADCS Drafting (Official Discussion Here)

Posted: 30 Sep 2009, 10:18
by Dj_Offset
darkKlor wrote:With the hub signing the certificate, I'm suggesting that the hub acts as a Certificate Authority.
I strongly disagree with this model. I don't see the need for clients to have certificates signed by the hub - we can do better with other less obtrusive changes. Such as:

* All clients have a certificate, the CID becomes a hash of the certificate (or the public key - haven't made up my mind on that).
* Upon hub login the hub will check that the CID matches the hash of the clients certificate to verify the user's certificate.
* The hub MAY use a password to register a user in case the certificate is unknown
* The hub MAY store the user's certificate in order to allow password-less logins in the future.
* For C-C connections the clients can verify each others identity by hashing each others public key/certificate and check if the CID is present on the hub or not ("identity" only goes as far as determining if another user belongs in a trusted hub).

The added bonus of this is that I just solved the useless PID issue. :)

Re: ADCS Drafting (Official Discussion Here)

Posted: 03 Oct 2009, 14:09
by darkKlor
A certificate exists for authentication and should only be used in cases where the user is registered on the hub.

I will quote the part of the TLS v1.2 standard (http://tools.ietf.org/html/rfc5246#appendix-F.1.1):
TLS supports three authentication modes: authentication of both
parties, server authentication with an unauthenticated client, and
total anonymity. Whenever the server is authenticated, the channel
is secure against man-in-the-middle attacks, but completely anonymous
sessions are inherently vulnerable to such attacks. Anonymous
servers cannot authenticate clients. If the server is authenticated,
its certificate message must provide a valid certificate chain
leading to an acceptable certificate authority. Similarly,
authenticated clients must supply an acceptable certificate to the
server. Each party is responsible for verifying that the other's
certificate is valid and has not expired or been revoked.
If we are to use TLS, I think we should be as close to the manner in which it was intended to work as is possible.

Also, looking at a section which refers to the Client Certificate message (http://tools.ietf.org/html/rfc5246#section-7.4.6):
This is the first message the client can send after receiving a
ServerHelloDone message. This message is only sent if the server
requests a certificate. If no suitable certificate is available,
the client MUST send a certificate message containing no
certificates. That is, the certificate_list structure has a
length of zero. If the client does not send any certificates, the
server MAY at its discretion either continue the handshake without
client authentication, or respond with a fatal handshake_failure
alert. Also, if some aspect of the certificate chain was
unacceptable (e.g., it was not signed by a known, trusted CA), the
server MAY at its discretion either continue the handshake
(considering the client unauthenticated) or send a fatal alert.
Note the last sentence in particular gives two options to a server when a client sends a certificate with no known CA:
1) continue the handshake, considering the client unauthenticated, or
2) send a fatal alert.

Another comment on using a single certificate for all hubs a user connects to (this applies to CIDs just the same): it is an information disclosure vulnerability, because you can reasonably expect that a public key only exists once. If you see a user on two hubs, with two different nicknames and IP's (e.g. they connect to one hub via a proxy, but not the other hub), but they have a common public key (or CID), then you know them to be the same user.

If, for registered users, the hub issues the user with a hub-signed certificate, specifically for that hub, and (borrowing from DJ_Offset's suggestions) the registered user's CID is a hash of that certificate (not the public key, because anyone can get that, potentially), then the hub knows who the user is, and their registered CID on that hub will not match their CID on another hub (registered or otherwise).

Re: ADCS Drafting (Official Discussion Here)

Posted: 03 Oct 2009, 14:42
by darkKlor
Rationale
Dj_Offset wrote:
darkKlor wrote:The hub registration method is weak i.e. password-based registration involves the transmission of passwords to the server in plain-text.
The current ADC spec does not address this issue at all, so it is therefore inaccurate to claim that the registration method is weak.
I know you love defending the ADC spec itself :P However, lets call it a community issue that there is no registration method built into the protocol so passwords are sent in plain-text via hub-commands. Non-existant can still mean weak, it's just extra-weak :P


Connection Approach
Dj_Offset wrote: "Separate port" and "Upgrade negotiation" is nice, but you totally miss the obvious 3rd option. Simply redirect to an adcs:// address.
There is no technical need for having a "separate port" to run TLS on - as such I don't see a point in overspecifying this point as it boils down to implementation details.
No technical point having a separate port is quite true, but you shouldn't allow users to connect to a hub with ADCS activated if they do not support ADCS (i.e. in non-encrypted mode). Thus, it is effectively a requirement to have separate ports.

Also, If you want to see hubs move to ADCS (final, not draft) then you need to decide whether you're going to tell everybody (i.e. all ADC users) that old clients are unacceptable and they must move to a new client, or cater for the laggards and have a mechanism to provide information on why a connection is being refused (e.g. via the upgrade method). DCDev (Private) is in no rush to become an ADC hub, and there's still the odd client connecting which is NMDC-only... so obviously it the hub is backwards-compatible. Will moving a hub to ADCS offer backward compatibility to older clients on that hub?
Dj_Offset wrote:That being said, "Upgrade negotiation" is very much vulnerable to downgrade attacks by a proxy simply eliminating "ADCS" as a viable feature.
Well at least the hub can gracefully send a refused connection message, and even a list of possible ways to diagnose the connection or places to ask for support. I do not support allowing ADCS and non-ADCS users to mix in an ADCS-enabled hub, and the feature negotiation (and any rejection messages) would occur prior to the user list being sent to the connecting user, so it is not a risk to the security of the hub if a user is denied ADCS as a feature by a proxy.


Situational Considerations
Dj_Offset wrote: And a server can authenticate a user based on a shared secret - a password comes to mind.
Isn't that still mutual authentication?
Yes, see the TLS-PSK stuff :)

Verification of Self-Signed Server Certificates
Dj_Offset wrote:KeyPrint as described here does not solve any issue itself, it now generates a couple of new issues:
  • First of all: Can you trust the link you got?
  • If the link you got contains a keyprint using an unsupported hash?
  • If the link you got contains an invalid keyprint - what are the potential recovery strategies?
  • If the link you got does not contain a keyprint - is it invalid, considered insecure, not secure, or dangerous?
As far as I can see, only the first issue is discussed in the Keyprint spec.
An unsupported hash is a particularly valid concern, since one of the nice things about TLS is it uses a 'suite' of ciphers to try and get around such a problem... I'd suggest the client would inform the user that the certificate cannot be verified because the hash is unsupported, and allow them to decide whether or not to continue; whereas, if the hash is supported and the certificate cannot be verified, it would not give the option of continuing anyway. If the hash was supported but the KeyPrint was not a valid hash e.g. 11 characters where it should be 12; then, the client would inform the user the hash was invalid, but give them the option of continuing.