Subject: [Sidrops] adopt draft-ymbk-sidrops-rpki-has-no-identity please

From: Randy Bush <[email-masked]>
Date: Thu, 18 Mar 2021 11:15:29 -0700

i would request wg adoption of draft-ymbk-sidrops-rpki-has-no-identity.
a number of people are already wanting to tweak/tune/fix; and another
draft is already referencing it.

thanks

randy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 23 Mar 2021 16:19:01 +0100 (CET)

> draft is already referencing it.

When someone asks me to put a string into a webserver file or into my DNS 
zone file to "prove" I have administration access, they don't want to 
identify me, they just want me to prove I already have access to the 
resource at the "business end" of it.

RSC is the same thing, I prove I can create ROAs and/or RSCs, I already 
have critical access to the resources somehow, and that's fine for 
attesting to for instance a LOA being correct for this resource.

So yes, you're correct, it doesn't prove identity, but that's not what 
it's used for either.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Tue, 23 Mar 2021 19:19:44 -0700

> When someone asks me to put a string into a webserver file or into my
> DNS zone file to "prove" I have administration access, they don't want
> to identify me, they just want me to prove I already have access to
> the resource at the "business end" of it.

usually because dns is the purpose of the exercise

> RSC is the same thing, I prove I can create ROAs and/or RSCs

as sra would say, you can demonstrate that the same unknown attacker
can create objects.

randy

---

From: George Michaelson <[email-masked]>
Date: Wed, 24 Mar 2021 12:22:28 +1000

> as sra would say, you can demonstrate that the same unknown attacker

The attacker has access to private keys behind the specific INR. We
have bigger problems than the one here, Surely?

(or, can you show me the attack vector, which does not imply loss of
privacy over a public-private keypair?)

---

From: Randy Bush <[email-masked]>
Date: Tue, 23 Mar 2021 19:25:31 -0700

> have bigger problems than the one here, Surely?

indeed.  some are proposing to grant them access to someone's bank
account because they can sign some roa

> privacy over a public-private keypair?)

we have been over this multiple times, george.  read the draft

randy

---

From: George Michaelson <[email-masked]>
Date: Wed, 24 Mar 2021 12:39:22 +1000

> account because they can sign some roa

I think what you are asked to sign over should be crafted either along
with, or by the person who is going to have to act on it. If you need
the statement to be conditional on proof of control of some INR, you
would want a cryptographic test of the proof of control of the INR.

"Randy say's he's your agent in this transaction. I need to see an INR
signed assertion you want Randy, identified by this information <here>
to be the one who says what is to be done wth this INR"

If you, the signer didn't check what the <here> was and what the INR
was, and who was saying this, You're being gamed all the way along the
path. This had to be in a trustable channel surely?

Remember this starts in BYO. You're deep inside AWS provisioning with
a bPKI keypair anchored in AWS, doing JSON/Post stuff, when you're
asked to assert an RSC or RTA signed blob back inside that protocol so
they can have high confidence. To be the MITM, you've owned the entire
supply chain bootstrapping into AWS.

> we have been over this multiple times, george.  read the draft

It's helpful to be explicit. The MITM risk flows two possible ways.
There is the signer, the person who makes the RTA/RSC, and there is
the recipient. A MITM can be attacking either or both.

The case you appear to be arguing, is the attack on the bank: the bank
is led to believe the MITM is authorised to do things, because they
show the signer countersigned a token, which they passed over to be
signed, claiming some spurious reasoning why the signer should sign.

I am wondering how this differs from a MITM asking a signer to make a
specific ROA, and presenting it forward as proof to some entity (the
bank in this case) -And the only part I can see which differs is the
public nature of how ROA are currently made: that it appears on a
Manifest, and is in a repository. But I don't understand how that
mitigates the attack.

Unless I've missed something, you can do this MITM attack with ROAs,
if you take a ROA as proof of agency over resources right now: Which,
is what BYO does for some people.

This reduces to the statement "its only applicable to BGP" but doesn't
actually remove the MITM risk: a MITM can make people believe you want
an outcome by mediating the dialogue leading to the making of the
outcome.  Are there no attacks on the integrity of routing, which
leverage the "wrong" ROA being asserted? At a guess, the primary ones
go to the INR holder, So, its the "other" party in the MITM attack.
That's the difference.

Otherwise, its an attack on the integrity of the supply chain bPKI, or
it is completely absent, its an insecure supply chain transaction.  I
don't see that RSC or RTA increased risks, of choosing to do a
provisioning exchange relevant to INR over an insecure path.

cheers

-G

---

From: Randy Bush <[email-masked]>
Date: Tue, 23 Mar 2021 19:47:54 -0700

dear jck,

you want me to dispense funds from ggm's account, prove you are ggm.
that you can sign 100,000 rpki objects with some rpki credentials does
not go 2mm toward demonstrating you are ggm.

randy

---

From: George Michaelson <[email-masked]>
Date: Wed, 24 Mar 2021 13:32:27 +1000

No disagree. But, its also a non-sequiteur.

Your statement showed no conditionality on INR.

Why was INR signing brought into play? Who even suggested INR signing
was relevant to the transaction in question? Where is the interest in
the recipient of the signing, in what INR are in play?

It only makes sense to request the disbursement of funds conditional
on some INR signing, if there is some INR purpose involved. If there
was INR conditionality, then the direction of force would lie with the
person requesting evidence of an association with Randy, and the
INR-holder.

The mechanism is not to prove Randys name. The mechanism is to define
the INR, of interest to the transaction the receiver needs INR-proof
in.

-G

---

From: Randy Bush <[email-masked]>
Date: Tue, 23 Mar 2021 20:36:56 -0700

from the sec cons

    When a document is signed with the private key associated with a
    RPKI certificate, the signer is speaking for the INRs, the IP
    address space and Autonomous System (AS) numbers, in the
    certificate.  This is not an identity; this is an authorization.

randy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 24 Mar 2021 07:19:33 +0100 (CET)

>    certificate.  This is not an identity; this is an authorization.

Agreed.

Are you opposing the use of RPKI for signing LOAs, because I don't see the 
document affecting the use of RPKI for RSC for signing LOAs.

The document says it doesn't prove identity. Correct. We all seem to agree 
on that. Now what?

---

From: Ben Maddison <[email-masked]>
Date: Wed, 24 Mar 2021 09:15:10 +0200

> The document says it doesn't prove identity. Correct. We all seem to agree
Yup, I certainly agree with that.

I also agree that the LOA use-case for RTA/RSC is fundamentally no
different from the semantics of 6811.

However, "strongly defined" objects (ROAs, GBRs, ASPAs, etc) ship with
well specified semantics, which can be (are) sanity checked by the
originating WG during standardisation.

The difference, for me, and why I think that a document spelling out
what is and is not a suitable use of the RPKI is a good idea, is that
RTA/RSC-style objects give issuers free reign to invent new semantics on
the fly, including ones with bogus trust semantics (like Randy's EFT
authorization).

People will always be able to trip over their own feet using tools like
these, but spelling out what is and is not a good idea seems to be a
useful community service.

I don't think that the document currently does a particularly good job of
articulating this distinction. But I do think that it should be adopted
so that the shortcomings can be fixed by the WG.

Cheers,

Ben

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 24 Mar 2021 09:11:38 +0100 (CET)

> so that the shortcomings can be fixed by the WG.

I agree with above.

---

From: Randy Bush <[email-masked]>
Date: Wed, 24 Mar 2021 11:12:04 -0700

>>    certificate.  This is not an identity; this is an authorization.

cool

> Are you opposing the use of RPKI for signing LOAs, because I don't see
> the document affecting the use of RPKI for RSC for signing LOAs.

all depends on what is being Authorized by by the loA, doesn't it?

i certainly seems reasonable to use an inr for 1.2.3.0/24 to sign loa
for maria to originate that prefix.

it does not seem reasonable to use an inr for 1.2.3.0/24 to sign loa for
maria to withdraw funds from bill's bait and sushi's bank account.

> The document says it doesn't prove identity. Correct. We all seem to
> agree on that.

that is not clear to me.  among other things, ggm's walls of text
confuse me.  but i am easily confused.

randy

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 24 Mar 2021 19:02:34 +0000

Statements about origination and Bill's bank account are obvious.
Here is another statement:

Any route to 1.2.3.0/24 must be routed through Elbonia.
I.e., if the route does not include an Elbonian ASN in the
AS_PATH, then you must reject it.

Before you reject such a route, you want to be sure that
the statement is signed by the owner of 1.2.3.0/24.
Thus signing it with the RPKI cert ensures that.
OTOH, signing it with Bills personal cert doesn't.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <[email-masked]> On Behalf Of Randy Bush
Sent: Wednesday, March 24, 2021 11:12 AM
To: Mikael Abrahamsson <[email-masked]>
Cc: SIDR Operations WG <[email-masked]>; George Michaelson <[email-masked]>
Subject: Re: [Sidrops] adopt draft-ymbk-sidrops-rpki-has-no-identity please

cool

randy

_______________________________________________
Sidrops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidrops

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 24 Mar 2021 20:04:11 +0100 (CET)

> maria to withdraw funds from bill's bait and sushi's bank account.

I agree. So what about LOA for a fiber cross connect for peering with an 
ASN?

LOAs for originating a prefix, that sounds like a ROA is sufficient...

---

From: Randy Bush <[email-masked]>
Date: Wed, 24 Mar 2021 12:21:34 -0700

>> it does not seem reasonable to use an inr for 1.2.3.0/24 to sign loa
>> for maria to withdraw funds from bill's bait and sushi's bank
>> account.
> I agree. So what about LOA for a fiber cross connect for peering with
> an ASN?

to convince the colo that you have the authority to request a fiber run,
i imagine they would need to have a valid authority chain from whoever
signed the contract for the colo to the requestor.  i do not see how
the rpki would provice this.

for convincing your peer that your AS wishes to peer with their AS, i
can see an authorization by the rpki cert which contains the 3779 for
your asn,

> LOAs for originating a prefix, that sounds like a ROA is sufficient...

depends on what you are authorizing.  if it is not an AS, then a roa
would not be helpful.

randy

---

From: George Michaelson <[email-masked]>
Date: Thu, 25 Mar 2021 09:16:01 +1000

You posed a MITM attack. You instantiated it as a bank account fraud.
I tried to decompose your koan to identify the parties, and I draw the
conclusion that the risk of fraud exists irrespective of the nature of
the signed object, can be trivially instantiated from abuse of things
signed, and demands the receiver and sender be naive respecting MITM
risk, and draw false conclusions from the provable INR part of the
signing.

It is likely a ROA only harms the creator if abused. There is a risk
an RTA or RSC signed statement harms the receiver or some third party.
If the transaction is like BYOip, and the receiver defines the form of
data to be signed and some suitable nonce or hash to be over-signed, I
think its starting to look safer.

I believe we all agree the RPKI does not prove identity. I would say
that use of RTA and RSC, is to bridge signed provable assertions about
INR, to some other space. What that space is, and how it is proved,
lies between the receiver and the sender (of that bridged, signed
assertion). If the assertion is badly drawn up, and the receiver draws
unjustified conclusions, especially from the proofs over the INR into
some other domain, They're SOL.

Ideally defining new signed object types would be easy. I don't think
it is, the initial proposing is fine, its closure to a registry in
process which takes forever. RTA and RSC also help bootstrap ideas
which probably emerge as specific ASN1 defined objects with structure
fit for purpose. There is an argument to be made that the hard test of
what should be in the ASN1 and what it means is the necessary cost to
avoiding risk like the MITM threat.

cheers

-G

---

From: Randy Bush <[email-masked]>
Date: Wed, 24 Mar 2021 17:32:02 -0700

> You posed a MITM attack.

i did not think i described a middle for a monkey to inhabit.  when the
monkey uses its CA access credentials to cause the CA to sign some
document/object, it is the primary actor trying to fool you into
believing it is a rabbit.  so is the CA your middle?

> You instantiated it as a bank account fraud.  I tried to decompose
> your koan to identify the parties, and I draw the conclusion that the
> risk of fraud exists irrespective of the nature of the signed object,
> can be trivially instantiated from abuse of things signed, and demands
> the receiver and sender be naive respecting MITM risk, and draw false
> conclusions from the provable INR part of the signing.

i have absolutely no idea what that just said

> It is likely a ROA only harms the creator if abused.

depends on the form of abuse.  i think we have discussed a few hunred
times the problem where
  X owns 1.2.0.0/16 and announces that /16 from AS1
  X allocates 1.2.3.0/24 to their customer Y which Y announces from AS2
  neither creates a roa for 1.2.3.0/24-AS2
  X creates a roa for 1.2.0.0/16-AS1
  customer's announcement of 1.2.3.0/24-AS2 is now invalid

i.e. X's roa creation harms their customer, Y

> There is a risk an RTA or RSC signed statement harms the receiver or
> some third party.

like a roa, only if they foolishly believe it applies to anything other
than the inrs whose certs were used to sign the statement/roa.

> think its starting to look safer.

i am not sure what over-signing means.  but yes, if i can convince a CA
to sign something using the key for some inr, then you can probably
trust that something to speak for that inr.  e.g. if you sign a document
with the key for AS42, you can probably trust what it says about AS42;
although not anything about the unidentified 'owner' of AS42 or her
wife.

> I believe we all agree the RPKI does not prove identity.

i said nothing about prove.  imiho, the rpki can not authenticate real
world identities at all beyond than the inrs in the 3779 glorp.  this is
not supposed to be a complex concept.

> I would say that use of RTA and RSC, is to bridge signed provable
> assertions about INR, to some other space. What that space is, and how
> it is proved, lies between the receiver and the sender (of that
> bridged, signed assertion).

and if you believe that, i have this bridge

> process which takes forever.

i have no idea what that means.  i think we have all had the fun of
defining a new object type, see RFC6488

> RTA and RSC also help bootstrap ideas which probably emerge as
> specific ASN1 defined objects with structure fit for purpose.

> There is an argument to be made that the hard test of what should be
> in the ASN1 and what it means is the necessary cost to avoiding risk
> like the MITM threat.

lost me again; but the bar is low

are you trying to say that rta and rsc are low cost hacks for avoiding
the pain of making 6488 derivative rfcs?

maybe so.  as long as we keep in mind that those hacks only authenticate
statements about the INRs whose certs were used to sign.

randy

---

From: Martin Hoffmann <[email-masked]>
Date: Thu, 25 Mar 2021 08:26:15 +0100

Randy Bush wrote:
> 
> when
> the monkey uses its CA access credentials to cause the CA to sign some
> believing it is a rabbit.

Keep in mind that these statements are not protecting the issuer but
the receiver. As such it is the receiver’s task to assess what exactly
they can reasonably deduce from the statement and if it is fit for
whatever purpose they use it for.

In other words, if you believe from a bunch of signed carrots that a
monkey is a rabbit, that’s on you.

I don’t think a standalone document stating what a signature derived
from an RPKI CA means (or, rather, as is the case in the draft, does
not mean) is necessary. Instead, discussing this in the security
consideration of the document defining the signed statement will
suffice. Again, it is on the party accepting these signed statements
to do their due diligence to protect themselves from liability.

 -- Martin

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 25 Mar 2021 10:28:58 +0100

Dear WG,

> On 25 Mar 2021, at 08:26, Martin Hoffmann <[email-masked]> wrote:
> 
> Randy Bush wrote:
>> 
>> when

Rabbits aside..

I think the crux of the concern is that:

1. Operators who have been given control over an RPKI CA for routing related assertions such as ROAs, are not necessarily trusted by their organisation to make other statements about the internet number resources that their RPKI CA is authoritative over.

2. Statements about resources could also be made by operators of parent CAs.

And indeed the RPKI is not about identity.

On process:
I believe this is understood by the authors of both the RSC and RTA specs, and I agree with Martin that in as far that it is not clear this should be addressed in the Security Considerations of those documents. If the working group prefers to have a separate document that talks about this, so that the Security Considerations sections can refer to this - as Job has done in the RSC -02 draft, then that is also fine with me. I believe that the objective is to have clarity - so whatever works.

On content:
Indeed it should be clear to receivers of RSC/RTA statements that the assertions could be made by anyone with administrative control over an RPKI CA with the listed resources. They should apply their own due diligence to ensure that signatures are not only valid, but also relevant in their context.

So, in some cases RSC/RTA could be entirely irrelevant, or not authoritative - e.g. a network operator with control over an RPKI CA may not be authoritative to say that an IP prefix can be sold. But, going with the "Bring your own IP" example I expect no such issues: for one it's very much routing related, and secondly I believe that there was a proposal that a cloud provider would use RSC in a way similar to two factor: they would (1) require that a ROA exists, without caring *who* created it - and acknowledging that it could even be a mistakenly created ROA, and then (2) require that a known client confirms the assertion by means of a separate signature over a challenge (eg UUID) for those resources, sent to them over a trusted channel.

The RSC and RTA specs are generalized specifications, so therefore their security considerations can only be generalized as well. An alternative could be to have explicit specifications for each use case, then each specification can clearly define their own considerations and applicability. However, I think that there is value in keeping the generalized RSC/RTA specifications as templates. Much like how RFC 6488 is a "Signed Object Template for the Resource Public Key Infrastructure (RPKI)".

Tim

---

From: Randy Bush <[email-masked]>
Date: Thu, 25 Mar 2021 05:22:16 -0700

> I believe this is understood by the authors of both the RSC and RTA
> specs

ggm has succeeded in convincing me otherwise on multiple occasiona.
but the audience for the draft is not the authors of rta or rsc;
but rather the user.  though it would certainly help if the authors
of those drafts made clear their limitations of authority.

> Indeed it should be clear to receivers of RSC/RTA statements that the
> assertions could be made by anyone with administrative control over
> an RPKI CA with the listed resources.

it's a bit more than that.  it could be a rabbit (sorry, i am dealing
with a real rabbit).  the recipient has zero knowledge who or what has
that administrative control over some inrs; and needs clear notice
that, if mary hands them a document signed by a cert for some inr, they
have zero assurance that mary is even in control of that inr.

there is a missing link.  for some application there may be some link
that authorizes the document/transaction.  but the authorization comes
from that link, and not some glorp signed by some inr.

> They should apply their own due diligence to ensure that signatures
> are not only valid, but also relevant in their context.

can there be a context other than a statement about the signing inr
itself?  please lay out a detailed example.

> going with the "Bring your own IP" example I expect no such issues:
> for one it's very much routing related, and secondly I believe that
> there was a proposal that a cloud provider would use RSC in a way
> similar to two factor: they would (1) require that a ROA exists,
> without caring *who* created it - and acknowledging that it could even
> be a mistakenly created ROA, and then (2) require that a known client
> confirms the assertion by means of a separate signature over a
> challenge (eg UUID) for those resources, sent to them over a trusted
> channel.

then the roa/rpki is noise and the trusted channel is the only real
authority here.

> The RSC and RTA specs are generalized specifications, so therefore
> their security considerations can only be generalized as well.

the ~identity draft is not actually meant to be specific to rta and
rsc.  they just made clear the need for general clarification of the
limits of rpki authority.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 25 Mar 2021 06:03:23 -0700

> limits of rpki authority.

to be more clear, well at least try.  rpki-has-no-identity is not
meant as an attack on rta and rsc.

i appreciate those two drafts.  for example, we cited them in
draft-ietf-opsawg-finding-geofeeds.  but see that draft as an
example of appropriate narrow use the authority of an rpki based
signature

randy