blog: some fixes in authenticationHEADmaster

1 files changed, 39 insertions, 33 deletions

diff --git a/content/en/blog/20241110-auth.md b/content/en/blog/20241110-auth.md
index da4cac5..5dd427d 100644
--- a/content/en/blog/20241110-auth.md
+++ b/content/en/blog/20241110-auth.md
@@ -15,9 +15,9 @@ Mariah Carey signals it almost Christmas, so it sounds like as good a
 time for a blog post. Been a long time since my last one.
 
 My plan for this year for Ouroboros was to clean up the flow allocator
-code, then add implement authentication and clean up and fix packet
-loss handling (EFCP) and congestion avoidance, and then leave the
-elephant - the naming system - for later.
+code, then add authentication and clean up and fix packet loss
+handling (EFCP), fix congestion avoidance, and then leave the big
+missing part - the naming system - for later.
 
 As they say, plans never survive contact with the enemy. At least I
 got the clean-up of the flow allocator code done.
@@ -41,36 +41,37 @@ But here I am, at least 5 months later, and I don't have this
 implemented.
 
 There was one thing I absolutely wanted to avoid: having to configure
-the certificates for each application. The library could of course add
-some configuration/command line options to each linked application
-(e.g. --certificate), but even that is not to my liking: I know this
-is roughly how it is with OpenSSL certificates today, but it's a drag,
-and the O7s code was very emphatically hinting that it could be
-done.
+the certificates as part of the application. The library could of
+course add some configuration/command line options to each linked
+application (e.g. --certificate <cert.pem>), but that is also not to
+my liking. I know this is roughly how it is with OpenSSL certificates
+today, but it's a drag, and the O7s code was very emphatically hinting
+that it could be done without.
 
 But how? One way was to map programs to certificates in the IRM
 configuration, and when an application starts, the IRMd will pass it
 the certificate. As an example, the configuration has an entry
-/usr/bin/apache -> apache.crt and when /usr/bin/apache starts, it
-would get that certificate loaded). Meh, that would kind of have
-worked, but it left another problem open: what if I wanted the same
+/usr/bin/apache -> /etc/ouroboros/apache.crt and when /usr/bin/apache
+starts, it would get that certificate loaded). That would kind of have
+worked, but it left another problem: what if I wanted the same
 application to start twice, but with different certificates? In other
 words, I'd need to map the certificate to a process, not to a program.
 That kept my mind busy for a while, as there seemingly was no obvious
 solution to this. I say seemingly, because the solution is as obvious
-as it is simple. But it's far off the current state of affairs.
+as it is simple. But it's far from the current state of affairs.
 
 So, how could I get a process to load a certificate at runtime, but
-configure it in a central location before the process is running?
-That seems like aa catch 22. Mapping the program, instantiating the
-program, then set a new mapping, starting another process, that would
-be an error-prone mess riddled with race conditions.
-
-The answer is simple don't map the process, map the service name. O7s
-already has the primitives to map programs and processes to names. And
-this method is actually not that far off the current Internet. X509
-certficates are usually tied to Domain Names. One part of the puzzle
-solved, and I can still use standard X509 certificates.
+configure it in a central location, and before the process is running?
+That seems like a catch-22. First mapping the program, instantiating
+the program, then configure a new mapping, starting another process
+would be an error-prone mess riddled with race conditions.
+
+The answer was simple: don't map the process, map the service
+name. O7s already has the primitives to map programs and processes to
+service names. And this method is actually not that far off the
+current Internet approach. X509 certficates are usually tied to Domain
+Names. One part of the puzzle solved using this indirection, and I can
+still use standard X509 certificates, nice.
 
 So, why don't I have this yet? Glad you asked.
 
@@ -78,15 +79,17 @@ Mapping certificates to names and as such indirectly tying them to
 processes allows for a significantly different approach for
 authentication. Why would we trust the peer with sending us his
 certificate? We can get it from the name system, before establishing
-any communications with the peer. So, instead of allocating a flow,
-and then authenticating and deriving symmetric keys for end-to-end
-in-flight encryption - as is done with TLS - we can do something a lot
-more secure: encrypt absolutely everything - including the initial
-(flow allocation) handshake.
+any communications with the peer. Translated to the current Internet:
+DNS could return the public key together with the IP address. So,
+instead of first allocating a flow, and then authenticating and
+deriving symmetric keys for end-to-end in-flight encryption - as is
+done with TLS - we can do something a lot more secure: get the public
+key of the peer from the naming system and use it to encrypt the
+initial (flow allocation) handshake.
 
 But this has another impact on my implementation plan: I need the
-naming system, as the public certificate needs to be there for this to
-work.
+naming system, as the public certificate needs to be retrieved from it
+for this to work.
 
 The naming system is a component that has not been written yet. It is
 a distributed application/database and it needs IPC with the IRMd.
@@ -101,9 +104,12 @@ want to build the new component (name system) using that approach, and
 ripping it out of the current implementation is going to be messy.
 
 Starting over would allow using a more "modern" language than C. I've
-been looking at rust and golang, but from my initial survey, they
-don't seem like a good fit due to the lack of shared memory/robust
-mutex support. If C is the only viable language for this thing,
+been looking at rust, but from my initial survey, rust don't seem like
+a good fit due to the lack of shared memory/robust mutex
+support. Golang inherits mutexes from C pthreads, but I'm not that
+fond of switching to golang over C (and it might not work that
+transparently with other OS like BSD or OS X if I rely on the pthreads
+and shared memory). If C is the only viable language for this thing,
 ripping the guts out of the current implementation might be the best
 option after all.