Subject: [sidr] Key learning procedures in BGPsec?

From: Eric Osterweil <[email-masked]>
Date: Tue, 17 Jan 2012 18:36:39 -0500

Hey everyone,

I was walking through the thought exercise of figuring out how BGPsec might be planning to do its crypto key learning (which I see as a two pronged problem that I outline below), and I couldn't seem to find any clear text on this matter in the current drafts.  I think I'm up to date on most of the drafts, but perhaps not?  Can someone point me to the the treatises that clarify:
1 - How are routers in BGPsec going to learn and onboard the crypto certs (ROAs/AOAs/xOAs?) needed to verify the routing updates that they receive from peers?  These certs are clearly going to need to be maintained and updated somewhere in each router's extended memory hierarchy, right?  Without these, updates from other ASes can not be verified...
- and -
2 - How do we envision the process of an AS getting its own private key information installed on all of its routers?*  Without _these_, updates cannot be signed...

*Note: I think this is a subtle, but very critical issue.  If we consider (for example) that multinational ASes have routers all over the world, and that these routers need to be upgraded/replaced/etc sometimes, and that the ASes' private keys are essentially critical secrets (which also will change periodically), then how do we envision addressing the _ongoing_ issue of getting private keys onto routers in faraway places?  For instance, we wouldn't press a private key onto a CD, give it to a FedEx delivery person, and then let it work its way through customs in a foreign country that may (or may not) host entities with a vested interest in acquiring or intercepting such a critical enabling secret, right?  For that matter, what do people think about the issue that a private key could simply be covertly extracted from an AS' routers that are deployed in far off lands?  Wouldn't this kind of compromise be a terrifying security threat to most ISPs?  afaict, this threat directly elevates the importance the vulnerability period that comes between compromise, detection, revocation/reissuing, and the lag that occurs until other routers throughout the routing system learn of the changes to certs.   fwiw, I don't think we can punt on this and claim it is anything other than a first order architectural issue, because of the online nature of BGPsec's signing process.

That said, I'm really hoping that I've just missed/misread some text that addresses these issues.  If that's the case, please forgive the rambling noise, and tia for the pointers... :-}

Eric

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 18 Jan 2012 01:20:06 +0000

About #1:

ROAs are used for origin validation.  (*) The bgpsec router needs only the prefix-AS binding in the ROA, not the crypto part, and only for the origin validation, not the signature attribute validation.  The rpki-rtr protocol is one way to communicate that binding.  

The bgpsec signature attribute validation does need the public keys that are used to validate the signatures.  (And the binding to an AS - see previous message.)  But it is the nature of the public part of a public/private key pair that security concerns are lower for communicating that part of the pair and exposure is no concern.

--Sandy

(*)(Years ago Geoff corrected me about calling ROAs "certs" and I've remembered the lesson. They're just signed objects, not certs.)

________________________________________
From: [email-masked] [[email-masked]] on behalf of Eric Osterweil [[email-masked]]
Sent: Tuesday, January 17, 2012 6:36 PM
To: [email-masked] list
Subject: [sidr] Key learning procedures in BGPsec?

Hey everyone,

*Note: I think this is a subtle, but very critical issue.  If we consider (for example) that multinational ASes have routers all over the world, and that these routers need to be upgraded/replaced/etc sometimes, and that the ASes' private keys are essentially critical secrets (which also will change periodically), then how do we envision addressing the _ongoing_ issue of getting private keys onto routers in faraway places?  For instance, we wouldn't press a private key onto a CD, give it to a FedEx delivery person, and then let it work its way through customs in a foreign country that may (or may not) host entities with a vested interest in acquiring or intercepting such a critical enabling secret, right?  For that matter, what do people think about the issue that a private key could simply be covertly extracted from an AS' routers that are deployed in far off lands?  Wouldn't this kind of compromise be a terrifying security threat to most ISPs?  afaict, this threat directly
 elevates the importance the vulnerability period that comes between compromise, detection, revocation/reissuing, and the lag that occurs until other routers throughout the routing system learn of the changes to certs.   fwiw, I don't think we can punt on this and claim it is anything other than a first order architectural issue, because of the online nature of BGPsec's signing process.

Eric

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

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 18 Jan 2012 10:11:50 +0100

Hi,

> 2 - How do we envision the process of an AS getting its own private key information installed on all of its routers?*  Without _these_, updates cannot be signed...

I don't know for a fact, but I expect that the router key pair is created on the router itself. The private key never leaves it, but the public key can be exported so that it can be put on a (EE?) certificate signed by the holder of the AS.

I have to admit though that I am not fully up to speed with all the bgpsec documents, it's somewhere on my todo list, but my main focus here has been on publication and validation related matters, not so much bgp and router..

Tim

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 18 Jan 2012 08:42:38 -0500

>For that matter, what do people think about the issue that a private key 
>could simply be covertly extracted from an AS' routers that are deployed 
>in far off lands?  Wouldn't this kind of compromise be a terrifying security 
>threat to most ISPs?  

Eric,

We (BGPSEC document authors) had considered this problem.
It is mitigated by having 'Key per Router' as discussed in:
http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01#section-4.5

4.5.   Key Per Router (Rouge Router Problem)

4.5.1.  Decision

   Within each AS, each individual BGPSEC router can have a unique pair
   of private and public keys.

4.5.2.  Discussion

   If a router is compromised, its key pair can be revoked
   independently, without disrupting the other routers in the AS.  Each
   per-router key-pair will be represented in an end-entity certificate
   issued under the CA cert of the AS.  The Subject Key Identifier (SKI)
   in the signature points to the router certificate (and thus the
   unique public key) of the router that affixed its signature, so that
   a validating router can reliably identify the public key to use for
   signature verification.

Sriram

P.S. In case you had not seen the cited document
(draft-sriram-bgpsec-design-choices) before,
it is a design rationale discussion document and is a companion to
draft-lepinski-bgpsec-protocol-00.txt (our initial individual draft submission).

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 18 Jan 2012 10:12:15 -0500

Hey Sandy,

> ROAs are used for origin validation.  (*) The bgpsec router needs only the prefix-AS binding in the ROA, not the crypto part, and only for the origin validation, not the signature attribute validat…

I think I recall from another recent thread that there was some contention over whether a router should just take it on faith that the bindings are legit or if it needs to verify them.  Since I don't recall that thread coming to consensus, rather than recreate that here, I'm happy to leave this to the other thread if people think that makes sense.

> The bgpsec signature attribute validation does need the public keys that are used to validate the signatures.  (And the binding to an AS - see previous message.)  But it is the nature of the public…

I think we may not be speaking to the same point.  If a router gets a private key installed on it (presumably one that has been vetted to sign for an AS/prefix binding), then how do we get that key installed securely?  If the router gets born with a key, how does an AS manage the lifetime of that key?  That is, how do you envision it gets rolled over to a new key, and how does that key get vetted and installed? Again, I may just be missing the relevant part of some draft, but I was not able to find this procedure concisely documented.

> (*)(Years ago Geoff corrected me about calling ROAs "certs" and I've remembered the lesson. They're just signed objects, not certs.)

Point well taken, thanks. :)

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 18 Jan 2012 10:14:28 -0500

> I don't know for a fact, but I expect that the router key pair is created on the router itself. The private key never leaves it, but the public key can be exported so that it can be put on a (EE?)…

I think this is one of the things that I was afraid of (though I may still be in the weeds).  If (on one extreme) every router in an AS creates its own pub/priv key pair, then an AS w/ ~10^3 routers will need to publish ~10^3 keys, and consuming/verifying routers will need to have ~10^3 public keys in their extended memory hierarchies to verify any possible prefix/signature combination.  It sounds like we may need routers to manage key sets on the order of the number of _routers_ in the global routing system rather than the number of ASes in order to be able to verify all of crypto sigs that may be encountered on updates...

> I have to admit though that I am not fully up to speed with all the bgpsec documents, it's somewhere on my todo list, but my main focus here has been on publication and validation related matters,…

Understood.  I have not ruled out the possibility that my confusion stems from not being current enough with one of the drafts that happens to address this... Though, I wonder if that is also a point worth making.  Maybe there are just too many drafts, and that needs to be addressed? ;)

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 18 Jan 2012 10:26:47 -0500

Hey Sriram,

>   a validating router can reliably identify the public key to use for

Indeed, I knew about this (and even remember a NANOG discussion about it in Denver, I think).  I mentioned one of my concerns surrounding this in an email, just moments ago: 
1 - I think this could lead to quite a lot of state that consuming routers need, in order to verify any possible updates received from an AS.  In the previous email, I gave a more detailed response.
- but also -
2 - If there is such a compromise, how is it addressed?  In order to get a new key in there, does someone need to send a whole new router to replace the old one?  Do we envision putting sensitive private key info on some kind of electronic media and sending it via FedEx, etc?
3 - If new key material is to be shipped in to the same location that the last one was compromised in (in a new router, on a CD, or whatever) aren't we just putting the new key signing materials in the same not-so-secure-environment, and should we give some thought to how easy it might be to extract this information from a router?

> draft-lepinski-bgpsec-protocol-00.txt (our initial individual draft submission).

Yeah, I did see this.  I guess I was hoping that there was some kind of discussion text, intuition, or an explanation of the intricacies that are inherent to this proposition (re: the comments I made above and in the last few emails).  THanks for the pointer though.  I'll re-read this draft's diffs (as I see it's been updated since Taipei), thanks! :)

Eric

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Jan 2012 14:26:23 -0500

At 10:12 AM -0500 1/18/12, Eric Osterweil wrote:
>>  ROAs are used for origin validation.  (*) The bgpsec router needs 
>>only the prefix-AS binding in the ROA, not the crypto part, and 
>>only for the origin validation, not the signature attribute 
>>validation.  The rpki-rtr protocol is one way to communicate that 
>>binding. 
>
>I think I recall from another recent thread that there was some 
>contention over whether a router should just take it on faith that 
>the bindings are legit or if it needs to verify them.  Since I don't 
>recall that thread coming to consensus, rather than recreate that 
>here, I'm happy to leave this to the other thread if people think 
>that makes sense.

I don't recall that as a point of contention. The model for use of RTR is that
the set of routers that subscribe to a server in this protocol all trust the
server. If the server is managed by the operator of the AS in which 
the routers'operate, this is equivalent to the routers trusting the 
network management node for the AS.

>  > The bgpsec signature attribute validation does need the public 
>keys that are used to validate the signatures.  (And the binding to 
>an AS - see previous message.)  But it is the nature of the public 
>part of a public/private key pair that security concerns are lower 
>for communicating that part of the pair and exposure is no concern.
>
>I think we may not be speaking to the same point.  If a router gets 
>a private key installed on it (presumably one that has been vetted 
>to sign for an AS/prefix binding), then how do we get that key 
>installed securely?  If the router gets born with a key, how does an 
>AS manage the lifetime of that key?  That is, how do you envision it 
>gets rolled over to a new key, and how does that key get vetted and 
>installed? Again, I may just be missing the relevant part of some 
>draft, but I was not able to find this procedure concisely 
>documented.

PKIX has defined (CMC and CMP) protocols for cert requests that can 
be used if the router generates its own key pair. We are in the 
process of defining a new one that is simpler that than the two cited 
above. So there are multiple options here. If one chooses to generate 
a key and insert it into a router, then different protocols would be 
employed. (CMC is being enhanced to support this mode of operation, 
see draft-ietf-pkix-cmc-serverkeygeneration.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Jan 2012 14:41:52 -0500

At 6:36 PM -0500 1/17/12, Eric Osterweil wrote:
>...
>2 - How do we envision the process of an AS getting its own private 
>key information installed on all of its routers?*  Without _these_, 
>updates cannot be signed...

BGPSEC allows for a per-AS key pair or a per-router key pair.or anything
in between. Thus, if an AS has routers in locations that the AS 
operator considers physically insecure, it can choose to have those 
routers be individually keyed, while having a shared key pair for 
other routers.

Yes, this design may require routers to have access to a fairly large 
number of PUBLIC keys for routers/ASes.

Steve

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 19 Jan 2012 15:07:56 -0500

On Jan 18, 2012, at 2:41 PM, Stephen Kent wrote:

> in between. Thus, if an AS has routers in locations that the AS operator considers physically insecure, it can choose to have those routers be individually keyed, while having a shared key pair for other routers.
> 
> Yes, this design may require routers to have access to a fairly large number of PUBLIC keys for routers/ASes.

Where "fairly large" could approximate a number that is on the order of the number of all BGPsec routers in the global routing system, right (~millions)?  I would imaging that keeping a coherent cache of these keys at every ISP would be a major concern, no?  That's potentially a huge challenge when you include churn, revocation, etc, right?

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 19 Jan 2012 15:07:52 -0500

Hey Steve,

On Jan 18, 2012, at 2:26 PM, Stephen Kent wrote:

> server. If the server is managed by the operator of the AS in which the routers'operate, this is equivalent to the routers trusting the network management node for the AS.

Like I said, this is not something I (personally) feel the need to rehash here.  If those on the other thread ("[sidr] I-D Action: draft-ietf-sidr-rpki-rtr-23.txt") were content w/ its resolution, so be it.  But, iirc, there seemed to be some... lingering disagreement, no?

> PKIX has defined (CMC and CMP) protocols for cert requests that can be used if the router generates its own key pair. We are in the process of defining a new one that is simpler that than the two cited above. So there are multiple options here. If one chooses to generate a key and insert it into a router, then different protocols would be employed. (CMC is being enhanced to support this mode of operation, see draft-ietf-pkix-cmc-serverkeygeneration.

I just took a read through that draft, thanks for the pointer! :)

OOC, were you all imagining that the CMC authentication for these BGPsec routers would use a shared secret or a pre-installed certified key o each remote router?  Also, do you happen to know which nation states require key escrow these days?

Thanks!

Eric

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2012 17:18:26 -0500

At 3:07 PM -0500 1/19/12, Eric Osterweil wrote:
>...
>
>Where "fairly large" could approximate a number that is on the order 
>of the number of all BGPsec routers in the global routing system, 
>right (~millions)?  I would imaging that keeping a coherent cache of 
>these keys at every ISP would be a major concern, no?  That's 
>potentially a huge challenge when you include churn, revocation, 
>etc, right?

It's not clear how many different router certs we will see, but I 
agree that it may be substantial. it will likely be a mix of per-As 
and per-router certs, spread over all of the participating ASes.

Even if there are many fewer certs, inconsistent caches would pose a 
problem. Unless we're discussing an emergency rekey for a cert, the 
smart procedure is to post a new cert well before the old one 
expires, allowing RPs to retrieve the new one in plenty of time.

There is not yet an operational guidance doc for router cert management, but
I anticipate this sort of guidance will appear there.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2012 16:45:08 -0500

At 3:07 PM -0500 1/19/12, Eric Osterweil wrote:
>...
>
>Like I said, this is not something I (personally) feel the need to 
>rehash here.  If those on the other thread ("[sidr] I-D Action: 
>draft-ietf-sidr-rpki-rtr-23.txt") were content w/ its resolution, so 
>be it.  But, iirc, there seemed to be some... lingering 
>disagreement, no?

I think there was confusion re this topic, and that the RYR protocol 
doc could be improved by adding text in the security considerations 
section to clarify the trust model envisioned by the authors.

>I just took a read through that draft, thanks for the pointer! :)

you're welcome.

>OOC, were you all imagining that the CMC authentication for these 
>BGPsec routers would use a shared secret or a pre-installed 
>certified key o each remote router?  Also, do you happen to know 
>which nation states require key escrow these days?

This is a local matter, so each ISP can decide what approach they 
wish to adopt. I personally prefer installing the cert for the CA.

When key escrow has been required, it has usually been mandated for 
keys used for encryption, not for integrity or authentication. Since 
we're discussing integrity & authentication here, it is not clear 
that there are any applicable key escrow regulations.  Also, the IETF 
general policy has been to ignore any nation-specific crypto 
regulations when  developing standards.

Steve

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 19 Jan 2012 22:25:22 +0000

About your "all BGPSEC routers in the global routing system" - keep in mind that the ebgp routers are the ones that need a private key, not all the routers in an AS.

While we have a lot of info on churn in routing updates, I am not certain how to predict how much church there will be in the keys assigned to routers.

To those who operate networks:
can you mention an order of magnitude of the number of e-bgp routers you have?
can you mention how often you re-key your routers, for whatever secure communication you ordinarily  use with the routers?  (I presume without proof that operators typically secure the communications to their routers and must already be doing key management.) 

--Sandy

________________________________________
From: [email-masked] [[email-masked]] on behalf of Eric Osterweil [[email-masked]]
Sent: Thursday, January 19, 2012 3:07 PM
To: Stephen Kent
Cc: [email-masked] list
Subject: Re: [sidr] Key learning procedures in BGPsec?

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 19 Jan 2012 22:38:51 -0500

> At 3:07 PM -0500 1/19/12, Eric Osterweil wrote:

<snip>

> This is a local matter, so each ISP can decide what approach they wish to adopt. I personally prefer installing the cert for the CA.

Yeah, I see.  I agree that it should be a local policy decision, but then how does this avoid my initial concern about relying on crypto material that has been dispatched through customs (or some other suspect medium), where key material could be intercepted and extracted?  Also, is it safe to assume that you would need the CA(s) to restrict access to just your own routers (so that unknown routers/certs cannot issue KGReqs that result in KGReses)?

> 
> When key escrow has been required, it has usually been mandated for keys used for encryption, not for integrity or authentication. Since we're discussing integrity & authentication here, it is not clear that there are any applicable key escrow regulations.  

Sorry if I'm confused, but in the diagrams in 1.2.1 and 1.2.2, don't the curly braces denote encrypted material?  I thought the responses in the key exchanges where necessarily encrypted in this protocol?  Otherwise, the new private key is sent in the clear.  I fully accept the possibility that I'm confused here, but if the material is encrypted and needs to be decrypted, would the corresponding keys be subject to escrow policies?

I'm sure someone is about to remind me that this is not a PKIX list, but I just want to make sure that I understand how we are proposing to use this protocol. :)

> Also, the IETF general policy has been to ignore any nation-specific crypto regulations when  developing standards.

I see, I guess I had thought we should be worried about the eventual operational issues that might arise.  I didn't know this was taboo, but shouldn't we find a way to address these concerns in order to help ensure the design's operational relevance when it's finished?  I'm just bringing this up in the sprit of making this design more relevant, not because I think there should be some official linkage to escrow policies or anything.

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 19 Jan 2012 22:39:32 -0500

On Jan 19, 2012, at 5:18 PM, Stephen Kent wrote:

> It's not clear how many different router certs we will see, but I agree that it may be substantial. it will likely be a mix of per-As and per-router certs, spread over all of the participating ASes.
> 
> Even if there are many fewer certs, inconsistent caches would pose a problem. Unless we're discussing an emergency rekey for a cert, the smart procedure is to post a new cert well before the old one expires, allowing RPs to retrieve the new one in plenty of time.

Yeah, I agree with your comment about getting keys out ahead of time.  However, with a corpus of keys that could well order in the millions, I would worry that the inherent churn and resource requirements are going to be well more than we are (or at least I was) expecting.

> I anticipate this sort of guidance will appear there.

Will it include some discussion about scaling?  I think this key-per-router idea could turn out to be Pandora's box.  While having a key or two per AS or per prefix may allow us to use elements of today's routing system to give us some idea about how churn and dynamics _may_ look, I'm kind of worried now that we haven't properly evaluated how enormous the resource dependencies will be with per-router-keys.  Are there any specific plans to write this up anywhere?

Eric

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Jan 2012 15:28:37 -0500

At 10:38 PM -0500 1/19/12, Eric Osterweil wrote:
>Yeah, I see.  I agree that it should be a local policy decision, but 
>then how does this avoid my initial concern about relying on crypto 
>material that has been dispatched through customs (or some other 
>suspect medium), where key material could be intercepted and 
>extracted?

The focus of BGPSEC is improving inter-AS routing security. The 
operator of any AS may not do a great job of securing the keys 
associated with some or all of its routers. Other ASes will not, in 
general, be able to evaluate the operational security of an AS. 
BGPSEC tries to limit the extent to which an AS  can lie about routes 
that it propagates. Local (within an AS) security errors or poor 
practices do not undermine this security feature.

>Also, is it safe to assume that you would need the CA(s) to restrict 
>access to just your own routers (so that unknown routers/certs 
>cannot issue KGReqs that result in KGReses)?

A CA issuing certs to routers in an AS must have a way to verify that 
a cert request is form a legitimate source. There are various ways 
this can be done and, ultimately, this too is a local matter.

>  > When key escrow has been required, it has usually been mandated 
>for keys used for encryption, not for integrity or authentication. 
>Since we're discussing integrity & authentication here, it is not 
>clear that there are any applicable key escrow regulations.
>
>Sorry if I'm confused, but in the diagrams in 1.2.1 and 1.2.2, don't 
>the curly braces denote encrypted material?  I thought the responses 
>in the key exchanges where necessarily encrypted in this protocol? 
>Otherwise, the new private key is sent in the clear.  I fully accept 
>the possibility that I'm confused here, but if the material is 
>encrypted and needs to be decrypted, would the corresponding keys be 
>subject to escrow policies?

Typically no, because the use of the key being issued is for signing.

>  > Also, the IETF general policy has been to ignore any 
>nation-specific crypto regulations when  developing standards.
>
>I see, I guess I had thought we should be worried about the eventual 
>operational issues that might arise.  I didn't know this was taboo, 
>but shouldn't we find a way to address these concerns in order to 
>help ensure the design's operational relevance when it's finished? 
>I'm just bringing this up in the sprit of making this design more 
>relevant, not because I think there should be some official linkage 
>to escrow policies or anything.

In general it is appropriate to worry about operational issues. But, 
I'd suggest that key escrow is not within scope, based on previous 
IETF experience in related areas.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Jan 2012 15:31:03 -0500

At 10:39 PM -0500 1/19/12, Eric Osterweil wrote:
>...
>  >
>>  Even if there are many fewer certs, inconsistent caches would pose 
>>a problem. Unless we're discussing an emergency rekey for a cert, 
>>the smart procedure is to post a new cert well before the old one 
>Yeah, I agree with your comment about getting keys out ahead of 
>time.  However, with a corpus of keys that could well order in the 
>millions, I would worry that the inherent churn and resource 
>requirements are going to be well more than we are (or at least I 
>was) expecting.

speak for yourself :-).

>Will it include some discussion about scaling?  I think this 
>key-per-router idea could turn out to be Pandora's box.  While 
>having a key or two per AS or per prefix may allow us to use 
>elements of today's routing system to give us some idea about how 
>churn and dynamics _may_ look, I'm kind of worried now that we 
>haven't properly evaluated how enormous the resource dependencies 
>will be with per-router-keys.  Are there any specific plans to write 
>this up anywhere?

I anticipate that an operational considerations doc will be written.

Steve

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 24 Jan 2012 13:43:54 -0500

On Jan 23, 2012, at 3:28 PM, Stephen Kent wrote:

>> Yeah, I see.  I agree that it should be a local policy decision, but then how does this avoid my initial concern about relying on crypto material that has been dispatched through customs (or some other suspect medium), where key material could be intercepted and extracted?
> 
> The focus of BGPSEC is improving inter-AS routing security. The operator of any AS may not do a great job of securing the keys associated with some or all of its routers. Other ASes will not, in general, be able to evaluate the operational security of an AS. BGPSEC tries to limit the extent to which an AS  can lie about routes that it propagates. Local (within an AS) security errors or poor practices do not undermine this security feature.

This seems almost like a self-contradictory statement.  How is the system improving AS security if keys can only be deployed over a potentially compromised medium, and there is no provision for CAs, signers, RPs, etc. to express partial trust?  With BGPSEC, we are already assuming some degree of trust imparted by signatures, but your comment above suggests that there should be some further understanding that "other ASes" cannot evaluate the trustworthiness of what they are consuming...  If this is the case, I would worry that we are worse off with this false sense of security...

To put it differently, I think this highlights a misalignment between the design of BGPSEC and what operators are going to have to deal with.  We're not giving any choice to operators that will essentially have to risk compromise, or not play in this system at all...

> 
>> Also, is it safe to assume that you would need the CA(s) to restrict access to just your own routers (so that unknown routers/certs cannot issue KGReqs that result in KGReses)?
> 
> A CA issuing certs to routers in an AS must have a way to verify that a cert request is form a legitimate source. There are various ways this can be done and, ultimately, this too is a local matter.

Actually, I think this is a "turtles all the way down" issue.  I cannot see any silver bullet here that solves this (which is what I'm trying to highlight).  We can't bootstrap trust in a BGPSEC router's key w/o some external handshake, but we can't bootstrap that handshake without some external cert, but we can't bootstrap that without... etc.  Deploying a remote signer with sensitive information (private keys, shared secrets, etc.) seems to be a serious problem...

> Typically no, because the use of the key being issued is for signing.

But the diagrams show encryption.  Are the KGRes private keys to be sent in the clear then?

> In general it is appropriate to worry about operational issues. But, I'd suggest that key escrow is not within scope, based on previous IETF experience in related areas.

OK, I suppose my parting thought on this escrow issue, then, is that having to negotiate key escrow is an issue that operators will be required to face with this system, and I am worried that our working group's secure design might be a non-starter for some unless we try to address this issue it in the design.  I really feel like we need to fix this to keep our design relevant.

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 24 Jan 2012 13:44:32 -0500

>> Yeah, I agree with your comment about getting keys out ahead of time.  However, with a corpus of keys that could well order in the millions, I would worry that the inherent churn and resource requ…

Good one...

> I anticipate that an operational considerations doc will be written.

Great, I'd like to request that some form of complexity analysis be included (even just back of the envelope kinds of explanations).

Thanks,

Eric

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jan 2012 10:57:35 -0500

At 1:43 PM -0500 1/24/12, Eric Osterweil wrote:
>>BGPSEC tries to limit the extent to which an AS  can lie about 
>>routes that it propagates. Local (within an AS) security errors or 
>>poor practices do not undermine this security feature.
>
>This seems almost like a self-contradictory statement.

I guess I should be happy that you included "almost" :-).

>   How is the system improving AS security if keys can only be 
>deployed over a potentially compromised medium, and there is no 
>provision for CAs, signers, RPs, etc. to express partial trust?

Trust is subjective, not transitive, and a poor choice for a metric. 
Each AS operates in whatever way it chooses. This is already true 
with regard to local routing policy, quality of network management, 
subscriber service, etc. This same notion extends to the security of 
its BGPSEC operation.

Having an AS assert how well it secures it's BGPSEC router keys is a 
self-evaluative declaration. It is not very meaningful re the 
security guarantees that BGPSEC offers. Each AS operator is a CA, but 
it's not as though relying parties can choose a different CA to 
attest to the authorization of these routers to represent the AS. The 
operator is authoritative for this info.

One way to think of this is, if you are willing to do business with 
an AS operator, irrespective of its use of BGPSEC, you should be at 
least as happy when the operator deploys BGPSEC. Deploying BGPSEC 
will not make the operator "better" relative to other aspects of its 
operation; hopefully it also will not make the operator worse.

>   With BGPSEC, we are already assuming some degree of trust imparted 
>by signatures, but your comment above suggests that there should be 
>some further understanding that "other ASes" cannot evaluate the 
>trustworthiness of what they are consuming...  If this is the case, 
>I would worry that we are worse off with this false sense of 
>security...

I don't belive we are creating a false sense of security, but there 
may be confusion about the security model for BGPSEC.

A major goal of BGPSEC is to limit the extent to which 
errors/misbehavior by an AS operator, or a successful attack against 
an AS operator, can adversely affect other ASes (re routing). The 
RPKI limits the (verifiable) assertions that an AS operator can make 
about the AS that its routers represent, and the prefixes it can 
originate. The BGPSEC per-AS-hop sigs limit the assertions the AS can 
make re what routes have been advertised to it. These guarantees 
still apply whether the operator does a good or poor job of router 
key management.

>To put it differently, I think this highlights a misalignment 
>between the design of BGPSEC and what operators are going to have to 
>deal with.  We're not giving any choice to operators that will 
>essentially have to risk compromise, or not play in this system at 
>all...

I disagree with your characterization of the situation. One 
anticipates that an operator will prefer signed routes to unsigned 
routes, although that is still a local choice. You seem to be 
suggesting that if an operator were to publish the equivalent of a 
CPS re its router cert secruity management, then other operators 
could use this info to decide how much to trust signed updates. While 
I agree that one could imagine this sort of trust model, it becomes 
very complex very quickly. Experience suggests that users are not 
good at managing such complex trust models. Also, since the data is 
self-reported, it's not clear how one ought to weight it. So, we have 
adopted a much simpler trust model.

>...
>  > A CA issuing certs to routers in an AS must have a way to verify 
>that a cert request is form a legitimate source. There are various 
>ways this can be done and, ultimately, this too is a local matter.
>
>Actually, I think this is a "turtles all the way down" issue.  I 
>cannot see any silver bullet here that solves this (which is what 
>I'm trying to highlight).  We can't bootstrap trust in a BGPSEC 
>router's key w/o some external handshake, but we can't bootstrap 
>that handshake without some external cert, but we can't bootstrap 
>that without... etc.  Deploying a remote signer with sensitive 
>information (private keys, shared secrets, etc.) seems to be a 
>serious problem...

I'm puzzled by your comments above. CAs have used various methods to 
provision certs to users and to devices for years. Each Cisco VoIP 
phone has a vendor-installed cert and private key, and this has been 
true for years. One might image a similar feature for BGPSEC-enabled 
routers. This cert could be used to bootstrap issuance of a BGPSEC 
cert. The EST draft explicitly incorporates this notion. This is an 
elegant approach to cert issuance, but it's not the only option. So, 
as in many other PKI-based systems, the specific means by which a CA 
provisions certs will remain a local matter.

If a router is in a location that the operator considers risky, it 
might choose to use a per-router cert for that device, while sharing 
a cert/key for other routers. That is a per-operator choice.

>But the diagrams show encryption.  Are the KGRes private keys to be 

The issue is not whether encryption is used at any point in a key 
provisioning process. The issue, typically, has been what is the 
purpose of the key that might be subject to an escrow policy. But, in 
any case, I think key escrow is a red herring.

>...
>  > In general it is appropriate to worry about operational issues. 
>But, I'd suggest that key escrow is not within scope, based on 
>previous IETF experience in related areas.
>
>OK, I suppose my parting thought on this escrow issue, then, is that 
>having to negotiate key escrow is an issue that operators will be 
>required to face with this system, and I am worried that our working 
>group's secure design might be a non-starter for some unless we try 
>to address this issue it in the design.  I really feel like we need 
>to fix this to keep our design relevant.

I see nothing to fix.

Let's consider an AS operating in Elbonia. Let's assume that the 
Elbonian government imposes key escrow on router keys used with 
BGPSEC. This implies that signed updates from an AS operating in 
Elbonia  might really be bogus, generated by the Elbonia secret 
police (the notorious ESP). How is this different from the ESP taking 
over the AS, coercing the operators of the AS to emit bogus updates? 
Since BGPSEC is employed, the AS cannot emit verifiable routes that 
have not been sent to them. Thay cannot originate verifiable bogus 
routes for prefixes not allocated to them. The secruity guarantees 
provided by BGPSEC are designed to limit the damage that occurs if an 
AS makes errors, behaves badly, or is compromised.  Attacks based on 
key escrow are just one form of compromise.

Steve

---

From: Brian Dickson <[email-masked]>
Date: Mon, 30 Jan 2012 13:07:31 -0500

On Mon, Jan 30, 2012 at 10:57 AM, Stephen Kent <[email-masked]> wrote:
>>>  The focus of BGPSEC is improving inter-AS routing security. The operator
>>> of any AS may not do a great job of securing the keys associated with some
>>> or all of its routers. Other ASes will not, in general, be able to evaluate
>>> the operational security of an AS. BGPSEC tries to limit the extent to which
>>> an AS  can lie about routes that it propagates. Local (within an AS)
>>> security errors or poor practices do not undermine this security feature.
> A major goal of BGPSEC is to limit the extent to which errors/misbehavior by
> an AS operator, or a successful attack against an AS operator, can adversely
> affect other ASes (re routing). The RPKI limits the (verifiable) assertions
> that an AS operator can make about the AS that its routers represent, and
> the prefixes it can originate.

> The BGPSEC per-AS-hop sigs limit the
> assertions the AS can make re what routes have been advertised to it.

This is a stated goal, but how this achieved or achievable relates
greatly to key management.
See below for why I think there are issues with the current protocol
design vs key management.

> These
> guarantees still apply whether the operator does a good or poor job of
> router key management.

I disagree with this assertion.

Let's consider off-axis risks.

Originator O, Relying party R, Weak-operator W, and Bad Actor B.

If poor key management on W makes it possible for the private keys of
a single router in W's network to be learned by B, then all bets are
off for anything advertised via W.

Here's why:

Presume all the good stuff you want about O, and the RPKI system.
Route X, originated by O, is fully validated and legitimate.

Topologically, let's say the following BGPSEC sessions and links exist:

O--?--W--?--R--?--B--?

(All the "?" mean there could be intermediate parties, but none are
required for this example to still be applicable.)

In order to spoof announcements, B need two things: The private key of
a single router (such as the key for a W router), and the data that
would be signed by that router (for X).

However, since anyone receiving route X which was sent from O via W
_must_ contain that data, it is trivial for B to generate false routes
for O.

The process would be:
B sets up a router F ( which claims to be the W router for which the
key was compromised).
The (W_fake) router F is configured with ASN == W.
B sets up a BGPSEC session between F and B, and signs the results.

Voila, BGPSEC signed routes received by R, that appear to be:

O--?--W--B--?--R

and this BGPSEC-signed path is fully origin-validatable and fully
BGPSEC path-validatable.

An error by W, allows B to "pwn" O, without O or R doing anything wrong at all.

There is no (trivial) way for R (or O) to detect or prevent this kind of attack.

This shows why one or more of the following things needs to be changed
in the BGPSEC design:
(1) key management requirements (not part of the design)
(2) availability of unencrypted signature-input data to off-axis parties
(3) ability for a single signature to subvert the validation process
(4) absolute trust model for signature chains (all/nothing)
(5) ???

Brian

---

From: "Murphy, Sandra" <[email-masked]>
Date: Mon, 30 Jan 2012 19:32:28 +0000

Speaking as a regular ol' wg member:

>off for anything advertised via W.

Actually, you can stop with "all bets are off".

Any use of cryptography relies on the protection of the keying material.  The
assurance is not that a particular person/entity can do something, but that the
holder of the keying material can do something.

So like sharing your password to your bank account means that someone else
can appear as you to the bank, sharing your keys lets someone/something else
act as if they were you.  That is why key compromise is a serious issue.

This is common to anything that uses cryptography.  It is not specific to this
particular application.  Exposing the keys in DNSSEC, exposing the keys in https,
exposing the ssh keys, exposing passwords, etc., will all affect the assurance 
provided by the cryptography.

I do not see any requirements here that would make that any different than any other
use of cryptography in any other environment, so I do not see any need for
the protocols here to provide solutions.  Pointers to operational guidance 
elsewhere, where it exists, perhaps.

--Sandy, speaking as regular ol' member

________________________________________
From: [email-masked] [[email-masked]] on behalf of Brian Dickson [[email-masked]]
Sent: Monday, January 30, 2012 1:07 PM
To: Stephen Kent
Cc: [email-masked] list
Subject: Re: [sidr] Key learning procedures in BGPsec?

Here's why:

O--?--W--?--R--?--B--?

The process would be:

O--?--W--B--?--R

Brian

---

From: Brian Dickson <[email-masked]>
Date: Mon, 30 Jan 2012 14:57:25 -0500

> holder of the keying material can do something.

Correct.

My point was, and is, that _this_ particular design, as has been
proposed to the WG,
is what is placing the requirement for private key material, and the
consequent need
to protect said material.

Without going into details of alternative designs, it is enough to
point out, IMHO, the distinctions:

signatures - requires signer to possess private key,
recipient(s)/validators need public key
encryption - requires sender to have the public key(s), and the
recipient(s) need their respective private keys.

There are other kinds of encryption as well, which involve shared
keys, or in case of DH, random session keys with neither party
having/needing the other's key material.

What I'm saying is, I don't believe enough attention has been paid to
the private key on the router requirement, or its implications.

The designers of the protocol really need to justify their choice. It
is not enough to wave hands at this and say, "operational docs will
cover this".

> act as if they were you.  That is why key compromise is a serious issue.

This is an apples vs oranges thing. There is an end-to-end encrypted
session (SSL), and there is no requirement for private key
distribution.

The bank has its SSL private key, which is neither distributed, nor
exposed operationally. Then there's all the L8/L9 stuff related to
record keeping etc. (SOX etc.)

The primary issue is the creation and exposure of private keys.
If the protocol requires FIPS-140 (to whatever level/degree) to ensure
it does not introduce weakness or risk, that is something that needs
to be addressed.
Or, it may be a non-starter if that is a requirement, but the WG needs
to make an informed decision.

This isn't the kind of stuff to be taken lightly - it strongly impacts
deployment and operation, and cost of deployment (and/or risks).

> provided by the cryptography.

DNSSEC uses effectively out-of-band management for securely
distributing public keys (which is what DS uses).
DNSSEC supports centralized signature models with HSM  use being very scalable.

SSH also uses distribution of public keys and supports encrypted
storage of private keys (presumably in physically secure local
storage).

This would be the first major deployment of private keying material in
geographically diverse locations, that I'm aware of, for the protocol
to function as described.

> elsewhere, where it exists, perhaps.

I'd say it goes beyond operational guidance, and to the heart of the
protocol design.

It is not beyond fixing, but IMHO, desperately requires fixing. At
least if it stands a chance of being deployed in the real world.

Brian (speaking ONLY for myself).

---

From: "Murphy, Sandra" <[email-masked]>
Date: Mon, 30 Jan 2012 20:27:34 +0000

Speaking as regular ol' member:

>to protect said material.

I reiterate my point: any  use of cryptography will require that you are careful with
the keying material.

Do you have any designs in mind that will NOT use cryptography?

________________________________________
From: Brian Dickson [[email-masked]]
Sent: Monday, January 30, 2012 2:57 PM
To: Murphy, Sandra
Cc: Stephen Kent; [email-masked] list
Subject: Re: [sidr] Key learning procedures in BGPsec?

Correct.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jan 2012 16:37:38 -0500

>off for anything advertised via W.

To put this into perspective you need to say how the secruity problem 
created by poor key management by W for this router is substantively 
different from B successfully attacking W's network management system 
or compromising the router in question to achieve the same goal.

>would be signed by that router (for X).

You're example is a bit underspecified, so I'll try to fill in the blanks.

	- B's goal is to send a route to R, for address space 
legitimately originated by O, which will attract traffic to B rather 
than to W, right?

	- B needs to acquire an update for the target (O), that 
passed through W, otherwise the forward sig on the BGPSEC update will 
fail, making the attack fail.

	- in your example, B will get the BGPSEC update for O, from 
R, after it has passed through W, which satisfies the criteria above.

>B sets up a BGPSEC session between F and B, and signs the results.

In many cases, ASes have external info about neighbors to which they 
are directly connected, e.g., they executed a contract, paid for a 
link, etc. So, if B tries to claim it's W, based only on having a key 
from one of W's routers, that often may not work. (It might work if B 
and R are peers at an IXP and the VLAN at the IXP is not too strong.)

I would expect the attack to be:

	- upon receiopt of the signed update, B strips the sigs 
applied by W, and by any ASes between W and R, and any ASes between R 
and B.

	- using the compromised router key from W, B generates an update
that shows O-?-W-B. it signs the update using its (B's) key, and 
sends it to R, possibly via an intermediate AS ("?"). this way B does 
not have to pretend to be W. It only asserts that it (B) has a link 
to W, and that it has the same path to O as W had, plus itself.

If there are one or more ASes between W and R, legitimately, then the 
bogus route is shorter and probably preferable. So, the presence of 
one or more "?" ASes between W and R is critical, contrary to your 
assertion. If W is directly connected to R, the bogus route is longer 
and may not be preferred.

You go on to observe that W's poor key management practices allow B 
to cause O's traffic to be routed through it, even though O and R did 
nothing wrong. That's true. But it also would be true if B 
compromised a router or network management computer in W and caused 
the AS/router to forward traffic destined for O (from R) to B. Or, W 
may be evil and takes $ from B to send it a copy of traffic from R to 
O. All of these are ways that the targeted traffic ca be misrouted, 
due to some bad behavior by W. This is an inherent limitation, in 
your example; R is dependent on W's secruity, realtive to traffic 
beign sent to O, because W is between O and R.

I don't agree with any of your proposed changes for the design.

#1 calls for a level of micromanagement that is not common in IETF standards

#2 is not relevant; my detailed attack example did not need to 
acquire the updates by wiretapping "off axis."

#3 suggests multiple sigs per something (AS?, router?) are more 
secure than a single sig. Absent a lot of unspecified context 
details, this assertion is not valid.

#4, viewed in the context of Eric's message, seems to suggest that if 
every AS were required to publish self-assertions about key 
management, then this info would be used as a "trust" value inputs to 
local routing policy by other ASes. Really?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jan 2012 16:52:13 -0500

>having/needing the other's key material.

not true. DH key agreement requires that each party receive the public
key of the other, in order to compute a shared secret.

Steve

---

From: Brian Dickson <[email-masked]>
Date: Mon, 30 Jan 2012 17:57:00 -0500

> key of the other, in order to compute a shared secret.

In DH, each side generates a random (per-session) private key, and
computes _a_ public key (which is exchanged), off of that private key
.

Here's the thing - the "public key" in DH is not pre-published, nor is
it re-used. It is a one-use, fire-and-forget object, as are the
private key and shared key.

This is different from a published (public) key material a la PKI. PKI
keys are longer-lived and multiple-use.

In DH, neither party has the other's key _before_ they start their DH
exchange. That was my point.

Sorry for not making that more obvious.

Brian

---

From: Richard Barnes <[email-masked]>
Date: Tue, 31 Jan 2012 00:04:44 +0100

> exchange. That was my point.

<hat type="pedantic"/>

I do not think that word (DH) means what you think it means
Diffie-Hellman is an algorithm on groups that have hard discrete log problems.  It has nothing to do with key management.
<http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange>

I think what you mean to say is DH with *ephemeral* keys.  That is not a necessary property.  You can have even DH keys in certificates.
<http://tools.ietf.org/html/rfc2631>

---

From: Brian Dickson <[email-masked]>
Date: Mon, 30 Jan 2012 18:57:22 -0500

> Do you have any designs in mind that will NOT use cryptography?

There are two things to consider here.

(1) If I can come up with an example design that does not rely on
private keys being kept (let alone exposed) on routers, would that be
sufficient to justify exploring more options than just my example? I'm
fine with someone else coming up with something better than this, and
am not married to the particulars of this. However, it can be
considered an "existence proof".

(2) Do you accept that an example of such a design is intended to
prompt the merits of looking for better designs, rather than the
example being fodder for dissection/discussion/bashing? I mean for
this to be an "okay, fine, clearly there are alternatives, and we
should discuss the high-level pros/cons of on-router crypto and key
management".

Having said that, here's a simple example (with "simple" being in the
eye of the beholder, obviously).

Each AS maintains a (for lack of a better term) "database" of its BGP
neighbors, and known prefixes.

Each AS also maintains a single, global "nonce", which it may
periodically change.

>From these sets of data and the single nonce, each AS publishes a set
of SHA-256 hashes (or other SHA hash, as appropriate), over (prefix +
neighbor_ASN + nonce) tuples.

How/where this gets published doesn't matter, but for example could be
in a per-ASN DNSSEC zone.

Each router, upon receiving a BGPSEC update, adds to the BGPSEC
hash-stack, the calculated SHA hash (of prefix + neighbor_ASN +
nonce).

Each RP looks up each received _hash_ in the corresponding publication
location, to determine the validity of that prefix's ASN_X-ASN_Y path
element. The RP does _not_ calculate the hash - it is already there.

Publishing the hashes in DNSSEC zones scales reasonably well:

- The hash values only need to be generated or updated when policy
changes (add/remove ASN neighbors) or the nonce gets changed. Thus,
caching works well.
- Large nonces ensure no collisions occur, and the zone is not
enumerable/searchable. A 1024-bit nonce (just a random number, needn't
be prime!) makes it completely impractical to try finding matches.
- The relationships between ASNs, in addition to being evident in the
AS_PATH (and/or AS4_PATH) are also represented _indirectly_ via the
published information.
- You have to already know the hash to confirm/deny the relationship,
and then only for specific prefixes.
- The relationships can be validated, but are not themselves exposed.
Only the SHA hash is ever used for the validation itself.
- Having a nonce is of little or no value, other than for being able
to determine specific ASN neighbor relationships.

Validation is yes/no based on looking up the literal value from the
BGPSEC field (which happens to be an SHA hash), but the RP does not
actually calculate anything, only looks up the value.

The router sending the update (which includes the hash) doesn't care
about who sent it the prefix - the hash remains the same _regardless_
of from whom it was received.

The router sending the update is an RP, and only adds the hash if the
validation succeeds (for every hash in the hash stack). Caching
pre-validated hashes further optimizes update processing.

The bottom line on this scheme is, bad actor B can only attempt to
spoof routes, where there are entries chained towards B of actual
neighbor relationships, and where the originator of the prefix matches
the RPKI. In other words, the worst that can be done is to leak "real"
routes. There are other suggestions for addressing route leaks, which
when combined with this, locks BGP down quite nicely.

NB:
- This requires no deployed-on-router crypto of any sort.
- There is a need for DNSSEC (and large zones at that), but that is
centralized and cached.
- Memory on commodity servers is cheap enough to not care, and the
stateful nature of this scales even better
- Depending on response time requirements, SSDs may handle zone
size/cache size issues.
- Other than occasionally rolling DNSSEC keys and nonces, there is no
need for "beaconing" in this model.
- DNSSEC signature expiry can trigger cache refresh, without requiring
re-signing or route invalidation.

Brian, speaking only for himself.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 30 Jan 2012 19:35:34 -0500

(The dangers of hitting send before double-checking)

> neighbor_ASN + nonce) tuples.

... whose DNS _data_ would consist of the neighbor's ASN and prefix,
to complete the validation.

It would also be the case that doing this for just ASN path data,
without the prefix (as either hash
input, or as part of the DNS data) would be equally valid, and a heck
of a lot smaller and more efficient.

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 31 Jan 2012 08:05:58 +0000

Brian

(delurk) As a recovering cryptographer I can think of nits to pick but it's
certainly possible to build a robust system using hash chains and hash
trees rather than conventional signatures.

Declaration of interest: I started this field of study 15 years ago with a
paper on the Guy Fawkes protocol. This was then taken up by Adrian Perrig
and others and turned into systems (TESLA etc) for authenticating digital
streams using hash chains. If you want to authenticate a large number of
messages from Alice to Bob that all arrive in order then hash chains are
great.

Here's how it might work. You have a conventional mechanism for initial key
setup between routers (maybe a route reflector doing public-key crypto,
maybe DNSSEC). Then each router sets up a hash chain with each peer and
uses hashes to authenticate routine updates.

Steve Kent will point out that routers do in effect have key material, in
the sense of not-yet-published hash preimages, and this is almost
equivalent to using symmetric keys for MACs (not quite, as you can get some
nonrepudiation from hash chains). But having local symmetric keys (or
short-lived signature keys) managed by per-AS route reflectors, perhaps
with HSMs for the bigger players, is in any case a good strategy to get
resilience in the face of occasional compromise.

So it might well be worth trying to explore the design options in more
detail. The authentication mechanisms had better be cheap and resilient if
we want this thing deployed

Ross Anderson
www.ross-anderson.com

---

From: Richard Barnes <[email-masked]>
Date: Tue, 31 Jan 2012 10:36:49 +0100

"As simple as possible, and no simpler"

Your proposal is basically BGPSEC with MACs instead of digital signatures.  That doesn't work because another AS on the Internet can, e.g., poison a route by appending hashes computed with another AS's nonce.

The critical security feature of this system is that resource holders can only make statements about themselves.  In order for that to be the case, you really do need asymmetric cryptography: digital signatures vs. MACs/hashes.  Otherwise, in order for the world to be able to validate MACs, the MAC key needs to be published (the "nonce" in your example), which means that other entities can then generate valid MACs -- making statements about entities other than themselves.

--Richard

---

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 31 Jan 2012 15:06:19 +0000

Speaking as regular ol' member

On  Tuesday, January 31, 2012, Ross.Anderson said:

>If you want to authenticate a large number of messages from Alice to Bob that

>all arrive in order then hash chains are great.

That is not what we are looking for in the sidr work.

Authenticating the stream of messages between two adjacent routers is not

the sidr focus.  Furthermore, there are solutions in hand (TCP AO, IPSEC,

pt-pt physical protections, etc.).

The sidr work is creating protections for the path - the AS_PATH attribute

that is modified by each AS in the path of propagation of the BGP update.

A sends an update to B, who adds itsself to the AS_PATH and sends to C,

who adds itself and send the update to D, who....

The protections ensure that a recipient can look at an AS_PATH that shows

A, B, C, D, ... and know that the update did in fact pass through those systems.

And "in order" becomes a more complex idea as well.

-Sandy, speaking as regular ol' member

________________________________
From: [email-masked] [[email-masked]]
Sent: Tuesday, January 31, 2012 3:05 AM
To: [email-masked] list
Cc: Murphy, Sandra; Brian Dickson
Subject: Re: [sidr] Key learning procedures in BGPsec?

Brian

(delurk) As a recovering cryptographer I can think of nits to pick but it's certainly possible to build a robust system using hash chains and hash trees rather than conventional signatures.

Declaration of interest: I started this field of study 15 years ago with a paper on the Guy Fawkes protocol. This was then taken up by Adrian Perrig and others and turned into systems (TESLA etc) for authenticating digital streams using hash chains. If you want to authenticate a large number of messages from Alice to Bob that all arrive in order then hash chains are great.

Here's how it might work. You have a conventional mechanism for initial key setup between routers (maybe a route reflector doing public-key crypto, maybe DNSSEC). Then each router sets up a hash chain with each peer and uses hashes to authenticate routine updates.

Steve Kent will point out that routers do in effect have key material, in the sense of not-yet-published hash preimages, and this is almost equivalent to using symmetric keys for MACs (not quite, as you can get some nonrepudiation from hash chains). But having local symmetric keys (or short-lived signature keys) managed by per-AS route reflectors, perhaps with HSMs for the bigger players, is in any case a good strategy to get resilience in the face of occasional compromise.

So it might well be worth trying to explore the design options in more detail. The authentication mechanisms had better be cheap and resilient if we want this thing deployed

Ross Anderson
www.ross-anderson.com<http://www.ross-anderson.com>