Provide First-Come-First-Remembered security model #258
Conversation
|
I'd appreciate a pair of eyes on this before tomorrow's interim, given my original scribbling was flawed in several respects, and I'm not sure I got all the fixes right. |
|
A question to be raised today is whether this should contain a note that where one wants endpoint names from certificates ("the other proposal" from #254), they can write it up per application or make a short document of it. |
Authentication alone is never sufficient; with the First-Come-Fist-Remembered policy of <#258>, it should be easier to see how this is still authorization. See-Also: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ballot/#roman-danyliw
|
|
||
| When a registration or operation is attempted, the RD MUST determine the client's subject name or public key: | ||
|
|
||
| * If the client's credentials indicate a subject name certified by an authority the RD recognizes (which may be the system's trust anchor store), that subject name is stored. |
There was a problem hiding this comment.
which == authority?
Maybe rephrase to make this less ambiguous.
There was a problem hiding this comment.
How about "indicate a subject name that is certified by any authority which the RD recognizes" as in the latest changeset? (I'm trying to avoid saying "contains a certificate from for" here because the certificate may be pointed at, and to leave the form of the certified subject name open for the next paragraphs to provide details.)
| When a registration or operation is attempted, the RD MUST determine the client's subject name or public key: | ||
|
|
||
| * If the client's credentials indicate a subject name certified by an authority the RD recognizes (which may be the system's trust anchor store), that subject name is stored. | ||
| With COSE based credentials (like in ACE), the name is taken from the Subject (sub) claim; this step fails if no Subject claim is part of the token. |
There was a problem hiding this comment.
COSE ≠ CWT; is this about CWT?
"the token" is what (the CWT)?
There was a problem hiding this comment.
Yes, CWT (or JWT) is what I meant. This also means it's not "like in ACE" but "as common with ACE". Then, "the token" also makes sense.
| With COSE based credentials (like in ACE), the name is taken from the Subject (sub) claim; this step fails if no Subject claim is part of the token. | ||
| With X.509 certificates, the Common Name (CN) and the complete list of SubjectAltName entries are stored. | ||
| In both cases, the authority that certified the claim is stored along the subject, as the latter may only be locally unique. | ||
| * Otherwise, if the client's credentials contain a public key, that public key is stored. |
There was a problem hiding this comment.
I think we are assuming that the client is proving possession of the private key for that public key.
| With X.509 certificates, the Common Name (CN) and the complete list of SubjectAltName entries are stored. | ||
| In both cases, the authority that certified the claim is stored along the subject, as the latter may only be locally unique. | ||
| * Otherwise, if the client's credentials contain a public key, that public key is stored. | ||
| With (D)TLS, this applies both to raw public keys and to the public keys indicated in certificates that are not recognized by the RD. |
There was a problem hiding this comment.
certificates that are not recognized? How do these work?
There was a problem hiding this comment.
I didn't mean unknown types of certificates but more certificates not recognized by any of the abovementioned authorities; rephrased.
|
|
||
| As part of the registration operation, that information is stored along the registration resource. | ||
|
|
||
| The RD MUST accept all registrations that do not conflict with an already active registration resource, |
There was a problem hiding this comment.
rephrased to "The RD MUST accept all registrations whose registration resource is not already active,"
|
|
||
| Any operation on a registration resource, | ||
| including registrations that lead to an existing registration resource, | ||
| MUST be rejected by the RD unless the credentials information is identical to (or, in case of SubjectAltNames, a superset of) the stored information. |
There was a problem hiding this comment.
The whole credentials information or the stored name?
(I'm not sure that "the" credentials information is defined here, either.)
There was a problem hiding this comment.
Mh, I had the extraction steps phrased as "MUST determine ...", and considered changing that to "MUST extract" so I can refer to "the extracted information" here -- but that's not quite it: If the client originally just had a certificate without a good trust chain (so the public key was stored), and later comes with a good certificate, the key should still be enough, so it became:
"unless all the stored information is found in the new request's credentials."
|
Looking into the COSE!=CWT more deeply, I now think that they are not even mutually exclusive (TLS X.509 client certificate with SubjectAltName and a CWT posted to /token with a subj claim? TLS with CWT as certificate, and an X.509 posted to token? Reminds me of IP-over-DNS-over-HTTP-over-QUIC. Not that I'd do that...), so I'll send this through one more iteration that just takes the bag of all found (subject, authority) claims and requires them. Might make phrasing it easier, even. |
This resolves ambiguity when both CWT and X.509 are present, in that all that are found are compared. (It also simplifies CWT phrasing).
Closes: #254