Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
-Original Message- From: Ace On Behalf Of Henk Birkholz Sent: Wednesday, March 4, 2020 2:33 PM To: Jim Schaad ; r...@ietf.org; ace@ietf.org; c...@ietf.org Subject: Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? Hi Jim, I'll take a stake into my heart for the group then :) Please note that I claim that there is no evidence that I am a vampire nor that I am the provenance of option 1.). [JLS] Please note I was planning on staking the idea not the person, I was just going to de-credential you. However that does raise the question should I bring salt and a sewing kit (mummies) or a gun with a silver bullet (werewolves)? I tried to phrase the output of the last virtual interim as neutral as possible and I think your reply is to be categorized as: Option 1.) is "out of the question" as a reply from a COSE WG chair. [JLS] That would be the COSE author and ACE and CBOR WG chair. I am not a COSE WG chair. However, I guess I hit all three asks. Viele Grüße, Henk On 04.03.20 22:42, Jim Schaad wrote: > Henk, > > Well you have definitely written a message designed to get a response from me. > > -Original Message- > From: Ace On Behalf Of Henk Birkholz > Sent: Wednesday, March 4, 2020 10:41 AM > To: r...@ietf.org; ace@ietf.org; c...@ietf.org > Subject: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to > be a CWT? > > Hi RATS enthusiasts, > hi ACE, > hi CBOR, > > in the RATS WG we had a lot of discussions about the nature of an Entity > Attestation Token (EAT): > > > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ > > > https://github.com/ietf-rats-wg/eat/ > > A bit of (hopefully useful) context: an EAT is one way to convey > believable evidence from an Attester (a role residing on a device-like > entity) to a Verifier (another role defined by RATS - the appraiser of > evidence). All that is done to provide a Relying Party with "simple enough" > attestation results generated by the Verifier to enable Relying Parties (in > general, the remote peer) to make an informed decision about whether to put > trust in the trustworthiness of that Attester or not. In summary, an Attester > could be compromised in some way and RATS tries to inhibit that Attester to > lie about that. > > There are a lot of benefits if an EAT (representing evidence) is a CWT: > > * we avoid conflicting CWT claim index/label definitions in the IANA > registry, while being able to use the CWT world of claims (existing, > cnf soon, and such), > * at first glance it seems simpler to use existing code that can > process CWT, and > * EAT can simply inherit the well defined COSE signing conventions. > > Alas, there is also a very specific drawback: > > * sometimes RATS might not want to sign a token (maybe that does > render it not a token anymore, but rather a ticket. But that is just a > rather minor detail for now) > > Why do RATS sometimes not require a signature around their CWT Claims Sets? > Because the surrounding secure channel between two entities with well > established authenticity and trustworthiness can be good enough to convey > useful CWT Claims Sets without a signature (emphasis on: in RATS). > > Now - there are multiple options discussed in the RATS WG how to deal with > this: > > 1.) go to COSE and ask for a "null signature", > > [JLS] For suggesting this, you should have all of you security credentials > revoked. The idea of deliberately introducing a way to take the security > value of COSE signatures to zero is something that should be staked like a > vampire and not allowed to continue. I strongly believe that this is a fatal > flaw in the current JOSE security suite and have several times deliberated > writing a document to remove the "null signature" from JOSE. While it is bad > to have signatures which are no longer adequately secure, having one with > zero security is just brain dead. > > 2.) go to ACE and ask for an "unsigned token" option, or > > [JLS] I don't have a problem with this, I am not sure that I see any reason > for it however. See below. > > 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are > not signed). > [JLS] I don't see any difference between this and option #2 > > [JLS] > 4.) Just write your CWT code in a sensible manner. > > My CWT code base does not make any assumptions about the number or > order of COSE security wrapping layers on a token. It thus looks like > > while (true) { > if input has a COSE_Encrypt tag { decrypt it; set input to the content; > save the encryption information if needed e.g. shared key authentication; > continue; } > if input has a COSE_MAC tag { validate it; set input to the content; > save the MAC information if needed e.g. shared key authentication; continue;} > if input has a COSE_Signature tag { validate it; set input to the > content; save the signer information; continue } > if
Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
Oh. Yes. Sorry. Tired and therefore still claiming #notavampire On 04.03.20 23:46, Carsten Bormann wrote: On 2020-03-04, at 23:33, Henk Birkholz wrote: Option 1.) is "out of the question" as a reply from a COSE WG chair. Option 1.) is "out of the question" as a reply from the author of the COSE specification. (And at least one other WG member agrees.) FTFY… Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
On 2020-03-04, at 23:33, Henk Birkholz wrote: > > Option 1.) is "out of the question" as a reply from a COSE WG chair. Option 1.) is "out of the question" as a reply from the author of the COSE specification. (And at least one other WG member agrees.) FTFY… Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
Hi Jim, I'll take a stake into my heart for the group then :) Please note that I claim that there is no evidence that I am a vampire nor that I am the provenance of option 1.). I tried to phrase the output of the last virtual interim as neutral as possible and I think your reply is to be categorized as: Option 1.) is "out of the question" as a reply from a COSE WG chair. Viele Grüße, Henk On 04.03.20 22:42, Jim Schaad wrote: Henk, Well you have definitely written a message designed to get a response from me. -Original Message- From: Ace On Behalf Of Henk Birkholz Sent: Wednesday, March 4, 2020 10:41 AM To: r...@ietf.org; ace@ietf.org; c...@ietf.org Subject: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? Hi RATS enthusiasts, hi ACE, hi CBOR, in the RATS WG we had a lot of discussions about the nature of an Entity Attestation Token (EAT): > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ > https://github.com/ietf-rats-wg/eat/ A bit of (hopefully useful) context: an EAT is one way to convey believable evidence from an Attester (a role residing on a device-like entity) to a Verifier (another role defined by RATS - the appraiser of evidence). All that is done to provide a Relying Party with "simple enough" attestation results generated by the Verifier to enable Relying Parties (in general, the remote peer) to make an informed decision about whether to put trust in the trustworthiness of that Attester or not. In summary, an Attester could be compromised in some way and RATS tries to inhibit that Attester to lie about that. There are a lot of benefits if an EAT (representing evidence) is a CWT: * we avoid conflicting CWT claim index/label definitions in the IANA registry, while being able to use the CWT world of claims (existing, cnf soon, and such), * at first glance it seems simpler to use existing code that can process CWT, and * EAT can simply inherit the well defined COSE signing conventions. Alas, there is also a very specific drawback: * sometimes RATS might not want to sign a token (maybe that does render it not a token anymore, but rather a ticket. But that is just a rather minor detail for now) Why do RATS sometimes not require a signature around their CWT Claims Sets? Because the surrounding secure channel between two entities with well established authenticity and trustworthiness can be good enough to convey useful CWT Claims Sets without a signature (emphasis on: in RATS). Now - there are multiple options discussed in the RATS WG how to deal with this: 1.) go to COSE and ask for a "null signature", [JLS] For suggesting this, you should have all of you security credentials revoked. The idea of deliberately introducing a way to take the security value of COSE signatures to zero is something that should be staked like a vampire and not allowed to continue. I strongly believe that this is a fatal flaw in the current JOSE security suite and have several times deliberated writing a document to remove the "null signature" from JOSE. While it is bad to have signatures which are no longer adequately secure, having one with zero security is just brain dead. 2.) go to ACE and ask for an "unsigned token" option, or [JLS] I don't have a problem with this, I am not sure that I see any reason for it however. See below. 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are not signed). [JLS] I don't see any difference between this and option #2 [JLS] 4.) Just write your CWT code in a sensible manner. My CWT code base does not make any assumptions about the number or order of COSE security wrapping layers on a token. It thus looks like while (true) { if input has a COSE_Encrypt tag { decrypt it; set input to the content; save the encryption information if needed e.g. shared key authentication; continue; } if input has a COSE_MAC tag { validate it; set input to the content; save the MAC information if needed e.g. shared key authentication; continue;} if input has a COSE_Signature tag { validate it; set input to the content; save the signer information; continue } if input is a map - return input as the set of claims; throw an exception because it is not the correct format. } This does not require a tag for a naked set of claims and would allow that set of claims to be pass in the same place as a CWT can be passed. What you are suggesting would require extra code to exist someplace that is going to check for an additional tag. It is also going to lead to people thinking that this new tag should be legal to place inside of a CWT. After all it makes more sense to always include it than to just sometimes include it. This would be more of an issue if an array rather than a map was being used to carry the claims as there would be a chance to not know what type of security wrapper exists. [JLS END] At the last RATS virtual interim there was no certa
Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
Henk, Well you have definitely written a message designed to get a response from me. -Original Message- From: Ace On Behalf Of Henk Birkholz Sent: Wednesday, March 4, 2020 10:41 AM To: r...@ietf.org; ace@ietf.org; c...@ietf.org Subject: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? Hi RATS enthusiasts, hi ACE, hi CBOR, in the RATS WG we had a lot of discussions about the nature of an Entity Attestation Token (EAT): > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ > https://github.com/ietf-rats-wg/eat/ A bit of (hopefully useful) context: an EAT is one way to convey believable evidence from an Attester (a role residing on a device-like entity) to a Verifier (another role defined by RATS - the appraiser of evidence). All that is done to provide a Relying Party with "simple enough" attestation results generated by the Verifier to enable Relying Parties (in general, the remote peer) to make an informed decision about whether to put trust in the trustworthiness of that Attester or not. In summary, an Attester could be compromised in some way and RATS tries to inhibit that Attester to lie about that. There are a lot of benefits if an EAT (representing evidence) is a CWT: * we avoid conflicting CWT claim index/label definitions in the IANA registry, while being able to use the CWT world of claims (existing, cnf soon, and such), * at first glance it seems simpler to use existing code that can process CWT, and * EAT can simply inherit the well defined COSE signing conventions. Alas, there is also a very specific drawback: * sometimes RATS might not want to sign a token (maybe that does render it not a token anymore, but rather a ticket. But that is just a rather minor detail for now) Why do RATS sometimes not require a signature around their CWT Claims Sets? Because the surrounding secure channel between two entities with well established authenticity and trustworthiness can be good enough to convey useful CWT Claims Sets without a signature (emphasis on: in RATS). Now - there are multiple options discussed in the RATS WG how to deal with this: 1.) go to COSE and ask for a "null signature", [JLS] For suggesting this, you should have all of you security credentials revoked. The idea of deliberately introducing a way to take the security value of COSE signatures to zero is something that should be staked like a vampire and not allowed to continue. I strongly believe that this is a fatal flaw in the current JOSE security suite and have several times deliberated writing a document to remove the "null signature" from JOSE. While it is bad to have signatures which are no longer adequately secure, having one with zero security is just brain dead. 2.) go to ACE and ask for an "unsigned token" option, or [JLS] I don't have a problem with this, I am not sure that I see any reason for it however. See below. 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are not signed). [JLS] I don't see any difference between this and option #2 [JLS] 4.) Just write your CWT code in a sensible manner. My CWT code base does not make any assumptions about the number or order of COSE security wrapping layers on a token. It thus looks like while (true) { if input has a COSE_Encrypt tag { decrypt it; set input to the content; save the encryption information if needed e.g. shared key authentication; continue; } if input has a COSE_MAC tag { validate it; set input to the content; save the MAC information if needed e.g. shared key authentication; continue;} if input has a COSE_Signature tag { validate it; set input to the content; save the signer information; continue } if input is a map - return input as the set of claims; throw an exception because it is not the correct format. } This does not require a tag for a naked set of claims and would allow that set of claims to be pass in the same place as a CWT can be passed. What you are suggesting would require extra code to exist someplace that is going to check for an additional tag. It is also going to lead to people thinking that this new tag should be legal to place inside of a CWT. After all it makes more sense to always include it than to just sometimes include it. This would be more of an issue if an array rather than a map was being used to carry the claims as there would be a chance to not know what type of security wrapper exists. [JLS END] At the last RATS virtual interim there was no certainty how to approach this. So this is a call out. COSE, ACE, and CBOR, how would you approach this "unsigned CWT Claims Set" requirement? If one of the three options highlighted above is out of the question, please say so (and please elaborate on the why for the sake of helping the RATS WG understand why that is not a good idea). If one of the three options looks like a low hanging fruit & viable, please say so (and... you know the dr
Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
On 2020-03-04, at 19:40, Henk Birkholz wrote: > > 1.) go to COSE and ask for a "null signature", https://en.wikipedia.org/wiki/Just_Say_No > 2.) go to ACE and ask for an "unsigned token" option, or > 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are > not signed). I believe this is pretty much the same option. I think ACE would come up with a CBOR tag as the obvious technical solution, and CBOR would suggest exactly that to ACE as the group responsible for CWT (and thus CWT Claims Sets). Apparently the only technical problem we have is that we don’t have a defined way to mark a naked CWT Claims Set (NCCS) as such; EATs would then be either NCCS or CWTs. CBOR tags are cheap and solve this problem. Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?
Hi RATS enthusiasts, hi ACE, hi CBOR, in the RATS WG we had a lot of discussions about the nature of an Entity Attestation Token (EAT): > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ > https://github.com/ietf-rats-wg/eat/ A bit of (hopefully useful) context: an EAT is one way to convey believable evidence from an Attester (a role residing on a device-like entity) to a Verifier (another role defined by RATS - the appraiser of evidence). All that is done to provide a Relying Party with "simple enough" attestation results generated by the Verifier to enable Relying Parties (in general, the remote peer) to make an informed decision about whether to put trust in the trustworthiness of that Attester or not. In summary, an Attester could be compromised in some way and RATS tries to inhibit that Attester to lie about that. There are a lot of benefits if an EAT (representing evidence) is a CWT: * we avoid conflicting CWT claim index/label definitions in the IANA registry, while being able to use the CWT world of claims (existing, cnf soon, and such), * at first glance it seems simpler to use existing code that can process CWT, and * EAT can simply inherit the well defined COSE signing conventions. Alas, there is also a very specific drawback: * sometimes RATS might not want to sign a token (maybe that does render it not a token anymore, but rather a ticket. But that is just a rather minor detail for now) Why do RATS sometimes not require a signature around their CWT Claims Sets? Because the surrounding secure channel between two entities with well established authenticity and trustworthiness can be good enough to convey useful CWT Claims Sets without a signature (emphasis on: in RATS). Now - there are multiple options discussed in the RATS WG how to deal with this: 1.) go to COSE and ask for a "null signature", 2.) go to ACE and ask for an "unsigned token" option, or 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are not signed). At the last RATS virtual interim there was no certainty how to approach this. So this is a call out. COSE, ACE, and CBOR, how would you approach this "unsigned CWT Claims Set" requirement? If one of the three options highlighted above is out of the question, please say so (and please elaborate on the why for the sake of helping the RATS WG understand why that is not a good idea). If one of the three options looks like a low hanging fruit & viable, please say so (and... you know the drill). I hope that this email contains all the information required to help the RATS WG in this call out to other WGs. If it does not, please say so :) Last but not least, if there are other relevant WGs or experts that could lend opinions or alternatives, let us know. Viele Grüße, Henk ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace