BTLS: Blockchain-based Transport Layer Security

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

BTLS: Blockchain-based Transport Layer Security

Post by renne »

Hi,

I want to suggest a relatively simple-to-implement authentication mechanism based on Namecoin:

1. User registers a username in \u-namespace
2. Namecoin generates a self-signed X.509 client-certificate matching the username in \u-namespace (Username = Common Name) and runs an update to add the fingerprint to the \u-namespace
3. User adds self-signed X.509 client-certificate to his application (e.g. browser)
4. Service operators install an authentication module on their servers (e.g. Apache) which queries the Namecoin blockchain for the username <-> fingperprint tupel and uses the fingerprint to validate the client certificate.

That way there is no need to have Namecoin running on client machines all the time for authentication and we can use existing client-side infrastructure (e.g browsers) without any change.

As Proof-of-Concept I suggest an Apache authentication module.

What do you think?

Does anyone have experience with creating Apache-Auth-modules?

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: BTLS: Blockchain-based Transport Layer Security

Post by domob »

I think this should be done using the "signer" field of id/. (Not u/!) While "signer" is currently only defined for using Namecoin addresses as "public keys", it was always meant to be extended as necessary. So it would not be a problem to add, for instance, GPG or TLS fingerprints as possible values. As you correctly point out, this would make it possible for the client to not run namecoind.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by renne »

Sorry, "id/" it is, of course. ;)

This wouldn't authenticate domains but it would be a simple approach to show the potential of blockchain-validated globally unique names. Server admins are a relatively small group with professional knowledge which would simplify the rollout of such an authentication system. If it has proven hard- and software vendors of client-systems will follow to implement blockchain-validation of domains by adding blockchain-support to their client systems.

ToDo:

Namecoin-QT: Add button per name in "Manage Names"-table to create self-signed X.509 certificate.
Apache: Develop authentication module.

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by renne »

I've added a Namecoin issue. ;)

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by renne »

I'd like to add a new application to Identity-namespace in Wiki:
  • Application
    • x.509
    Description
    • Fingerprint of self-signed X.509 client-certificate
    Rules
    • value = hash(X.509 client-certificate)
      • Hash algorithm = Hash algorithm of certificate signature algorithm (e.g sha256WithRSAEncryption -> sha256)
        Certificate
        • IETF RFC 5280-compliant client-certificate
          IETF RFC 7292-compliant file format (PKCS12 v1.1)
          Minimum key size: 4096-bit RSA
          Minimum signature algorithm strength: sha256
          Certificate expiration time < ID expiration time (36.000 blocks)
          Subject: O=Internet Community, OU=Namecoin, CN=<Namecoin ID>
          Issuer: O=Internet Community, OU=Namecoin, CN=Namecoin
    Examples
    • {
      "x.509": "ae7392fc64776e14fc2f768ce5fafbc6136665a8b29511e30a48eea4028e127d"
      }
I suggest a new application instead of the "signer"-application to have a multi-purpose X.509-application. This will allow to use the X.509 certificate for any kind of purpose (e.g. TLS client-/server-certificates, S/MIME, ...)

Please comment! ;)

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: BTLS: Blockchain-based Transport Layer Security

Post by domob »

As mentioned already above (with no answer so far), I suggest to consider using the "signer" field. Note that in my opinion, a X.509 client certificate can fulfill two distinct "roles":

1) To authenticate a user to a server. This is comparable to NameID, and - as I understand it -, what you propose here. For this application, I think that "signer" should be extended instead of adding a new field. That's precisely the purpose of "signer".

2) As a general purpose key-pair, for instance in the context of S/MIME (comparable to a GPG key). In this case, I think that a separate field makes sense, just like we have one for GPG keys.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by renne »

My goal is a general purpose key pair. TLS user authentication is just the beginning to show the benefits of blockchains. ;)

We can also use it for email encryption (S/MIME), code signing, instant messaging, VoIP, ...

In "d/"-namespace we can use the x.509-application with two changes:
* "Subject: O=Internet Community, OU=Namecoin, CN=<Namecoin ID>" -> "Subject: O=Internet Community, OU=Namecoin, CN=<dotbit-domain>".
* Subdomains can be added to server certificates as alternate names.

But we should post-pone server certificates as we have to change code in all client applications. ;)

  • Application
    • x.509
    Description
    • Fingerprint of self-signed X.509 client-certificate
    Rules
    • value = hash(X.509 client-certificate)
      • Hash algorithm = Hash algorithm of certificate signature algorithm (e.g sha256WithRSAEncryption -> sha256)
        Certificate
        • IETF RFC 5280-compliant client-certificate
          IETF RFC 7292-compliant file format (PKCS12 v1.1)
          Minimum key size: 4096-bit RSA
          Minimum signature algorithm strength: sha256
          Certificate expiration time < ID expiration time (36.000 blocks)
          Subject: O=Internet Community, OU=Namecoin, CN=<Namecoin ID|.bit-domain>
          Issuer: O=Internet Community, OU=Namecoin, CN=Namecoin
          Subdomains in "d/"-namespace as X.509 alternate names
    Examples
    • {
      "x.509": "ae7392fc64776e14fc2f768ce5fafbc6136665a8b29511e30a48eea4028e127d"
      }

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: BTLS: Blockchain-based Transport Layer Security

Post by domob »

I see. In this case, I think that adding the "x.509" field makes totally sense. I'm no expert in these matters, so I can't really comment on the proposed rules - as far as I can tell, they look fine. I also agree that this (including the certificate rules, hash method and all that as you describe it) should be defined as a general-purpose spec (like "import") and not confined to a particular namespace. Different namespace definitions could then reference these rules. For instance, in the context of TLS server certificates (for "d/") or S/MIME / messaging keys (for "id/").

Similarly, if a user wants to explicitly declare that this certificate shall be able to authenticate her as "id/some-name" to servers, the "signer" field can reference a certificate. But I really think that - whenever we are talking about logging into a server - "signer" should be used.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by renne »

domob wrote:I also agree that this (including the certificate rules, hash method and all that as you describe it) should be defined as a general-purpose spec (like "import") and not confined to a particular namespace. Different namespace definitions could then reference these rules. For instance, in the context of TLS server certificates (for "d/") or S/MIME / messaging keys (for "id/").
Agreed!. ;)
domob wrote:Similarly, if a user wants to explicitly declare that this certificate shall be able to authenticate her as "id/some-name" to servers, the "signer" field can reference a certificate. But I really think that - whenever we are talking about logging into a server - "signer" should be used.
In my opinion this is an unnecessary redundancy. As blockchains are decentralized we should drop the idea of the hierarchical client/server paradigm and consider each user/client/server as an equal node. We only need the client/server language to explain it to the IT-dinosaurs! ;)

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by renne »

renne wrote:In my opinion this is an unnecessary redundancy. As blockchains are decentralized we should drop the idea of the hierarchical client/server paradigm and consider each user/client/server as an equal node. We only need the client/server language to explain it to the IT-dinosaurs! ;)
@domob: What do you think?

Post Reply