[GitHub] [trafficcontrol] alficles commented on a diff in pull request #6622: Added Client Certificate Auth blueprint.

[GitBox <gi...@apache.org>]

alficles commented on code in PR #6622:
URL: https://github.com/apache/trafficcontrol/pull/6622#discussion_r932710469


##########
blueprints/client-certificate-auth.md:
##########
@@ -0,0 +1,240 @@
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+<Paste>"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Client Certificate Authentication
+
+## Problem Description
+
+Passwords currently serve as a powerful, but inflexible, way for clients to
+authenticate with Traffic Ops. However, an account can only have one password
+at a time, which means that service accounts tend to have a single shared
+password. This is undesirable from a security perspective.
+
+Client certificates are a flexible tool that allows operators to assign
+independent credentials to users of a service account. These credentials can
+have varying expirations and be issued in accordance with the operator's
+security policy.
+
+## Proposed Change
+
+When Traffic Portal or Traffic Ops receives a request, in addition to accepting
+a valid token, it will accept a valid TLS certificate chain. Traffic Ops will
+have a list of root certificates that it accepts.
+
+Issuance and management of these certificates will occur outside of Traffic
+Control and is the responsibility of the operator.
+
+### Traffic Portal Impact
+
+Traffic Portal will pull user information from requests before they are
+proxied. Connections between TP and TO will be signed with a client certificate
+to protect the connection.
+
+When TP proxies a connection to TO, it validates the TLS certificate against
+it's list of authorized roots. Iff it is valid, it includes the Subject of the
+certificate verbatim in a request header named `Client-Cert-Subject`.
+Otherwise, it strips any header named `Client-Cert-Subject` from the request.
+
+Whether the certificate is valid or not, it removes any existing
+`Client-Cert-Public-Key` header and adds a `Client-Cert-Public-Key` with the
+base64-encoded public key of the client certificate.
+
+TP will also add a Forwarded header.
+
+TP will have a list of valid roots and a client certificate with private key in
+it's configuration. The client certificate should have an empty value in the
+UID Relative Distinguished Name to indicate that it is considered a trusted
+proxy. TP will use this client certificate for all requests to Traffic Ops.
+
+An invalid certificate should be processed as if it were not present, except
+for the fact that its public key will be copied into the
+`Client-Cert-Public-Key` header.
+
+#### Certificate Expiration Notification
+
+When an authorized root is within 30 days of expiration, Traffic Portal should
+put a banner up for every administrative user on login indicating how long
+remains until expiration.
+
+### Traffic Ops Impact
+
+Traffic Ops will need to accept certificates as proof of identity as well in
+addition to tokens.
+
+A certificate provides proof of identity for a given user iff:
+  - the user id matches the value of the Relative Distinguished Name with the
+    attribute UID in the Subject of the certificate and it chains through valid
+    intermediates to an authorized root; or
+  - the value of the UID RDN in the Subject of the certificate is empty, it
+    chains through valid intermediates to an authorized root, and the user id
+    matches the value of the single UID RDN of the `Client-Cert-Subject` header.
+
+A certificate may not contain multiple UID RDNs. If it does, it is invalid.
+
+In all log messages that contain a user's identity, the CN of the Subject of
+the certificate and the IP address of connection should be logged as well. If
+the user id is matched in the `Client-Cert-Subject` on account of an empty UID
+in the Subject of the certificate, the CN of the Client-Cert-Subject and the IP
+address from the Forwarded header should be logged as well.
+
+An invalid certificate should be processed as though it were not present. So a

Review Comment:
   Any valid credential is valid. That is part of what I mean when I say "processed as though it were not present". If the credential is invalid, you act like it was never presented and do whatever you would have done if it weren't there.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@trafficcontrol.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org