Subject: [Sidr] Rsync

From: "Michele (Mike) Hjorleifsson" <[email-masked]>
Date: Fri, 14 Mar 2008 14:29:10 -0400

If the consensus is to go forward with rsync, may i suggest we start  
with rsync over ssh so that the information being transferred is  
somewhat protected
the accepting sites can setup key and host based authentication to add  
a layer of security as well.

-----------------------------------------
Mike Hjorleifsson
US Technical Sales Manager
AEP Networks, Inc
347 Elizabeth Avenue
Somerset, NJ 08773
Ph: 732-652-5257
Em: [email-masked]
 Apple ACTC  	||    	Microsoft MCP/MCT/MPS
Citrix CCA/CCI  	|| 	Novell Linux Engineer
FTOCC Certified VOIP Technician

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

---

From: Robert Kisteleki <[email-masked]>
Date: Mon, 17 Mar 2008 12:09:21 +0100

Hi,

I wonder what the benefit would be? (I can't parse "somewhat protected")

We need no encryption on the channel, as all the published information is 
public. The objects themselves (manifests, certs, CRLs, ROAs, ...) are 
signed so you can catch tampering. Finally, the existence of manifest 
provides source authentication. So there does not seem to be any advantages 
for this.

OTOH, you *would* have to incorporate a completely separate PKI in order to 
authenticate hosts (potentially thousands of them).

Robert

---

From: "Tony Li" <[email-masked]>
Date: Mon, 17 Mar 2008 10:38:44 -0700

One benefit would be a secure, automatic exchanges without cleartext
authentication.
 
Tony

|I wonder what the benefit would be? (I can't parse "somewhat 
|protected")
|
|We need no encryption on the channel, as all the published 
|information is 
|public. The objects themselves (manifests, certs, CRLs, ROAs, ...) are 
|signed so you can catch tampering. Finally, the existence of manifest 
|provides source authentication. So there does not seem to be 
|any advantages 
|for this.
|
|OTOH, you *would* have to incorporate a completely separate 
|PKI in order to 
|authenticate hosts (potentially thousands of them).

---

From: "Michele (Mike) Hjorleifsson" <[email-masked]>
Date: Mon, 17 Mar 2008 14:50:36 -0400

You could also limit which hosts can rsync

Michele (Mike) Hjorleifsson

---

From: Robert Loomans <[email-masked]>
Date: Tue, 18 Mar 2008 09:55:39 +1000

> One benefit would be a secure, automatic exchanges without cleartext

There is no authentication for the repositories. They are publicly, 
anonymously available.

Every party who wants to check one of your assertions (ROA, etc) needs 
to be able to retrieve the appropriate certificates, CRLs, etc.

Rob

-- 
Robert Loomans                                  Email: [email-masked]
Senior Software Engineer, APNIC                 Phone:   +61 7 3858 3100
http://www.apnic.net                              Fax:   +61 7 3858 3199
_______________________________________________
Sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Robert Loomans <[email-masked]>
Date: Tue, 18 Mar 2008 09:57:54 +1000

> You could also limit which hosts can rsync

That would be defeating the intent. The objects in the repositories are 
intended for public consumption. There is no way to predict who will 
want access and from which hosts they will run their tools.

Rob

---

From: "Michele (Mike) Hjorleifsson" <[email-masked]>
Date: Mon, 17 Mar 2008 20:27:30 -0400

Ok let me be a lil more clear, i wasnt referring to public access to  
the repo's i was talking about access to update the underlying  
information
is the intent to allow the public to edit the data in these  
repositories, my concern would be that if unprotected (or writable)  
the repository could
become compromised and the unsuspecting download a copy of corrupt data.

On Mar 17, 2008, at 7:55 PM, Robert Loomans wrote:

> Every party who wants to check one of your assertions (ROA, etc)  
> needs to be able to retrieve the appropriate certificates, CRLs, etc.
>
> Rob
>
> --

---

From: Robert Loomans <[email-masked]>
Date: Tue, 18 Mar 2008 10:54:27 +1000

Michele (Mike) Hjorleifsson wrote:
> Ok let me be a lil more clear, i wasnt referring to public access to the 
> repo's i was talking about access to update the underlying information
> repositories, my concern would be that if unprotected (or writable) the 
> repository could

Ah... Updates to the repositories are an internal implementation 
decision between the CA, and the repository. None of the current drafts 
describe updating repositories. They only describe fetching from them.

Rob

---

From: Geoff Huston <[email-masked]>
Date: Tue, 18 Mar 2008 13:59:32 +1100

> describe updating repositories. They only describe fetching from them.

Actually draft-huston-sidr-repos-structure attempted to do precisely that

Section 2 of that document may be a but implicit, but it defines as instance of a publication repository as containing all the signed products of a CA or the signed products of an EE. What is implicit is that neither a CA nor an EE would allow third parties to write to their publication repository. Also note that as these are all signed, foreign objects are detectable by relying parties.

    Geoff

---

From: Robert Loomans <[email-masked]>
Date: Tue, 18 Mar 2008 13:18:22 +1000

>> decision between the CA, and the repository. None of the current 
>> drafts describe updating repositories. They only describe fetching 
>> from them.
> 
> Section 2 of that document may be a but implicit, but it defines as 
> instance of a publication repository as containing all the signed 
> products of a CA or the signed products of an EE. What is implicit is 
> that neither a CA nor an EE would allow third parties to write to their 
> publication repository. Also note that as these are all signed, foreign 
> objects are detectable by relying parties.

Ok, what I said was poorly worded. I'll rephrase: None of the current 
drafts specify the mechanisms or protocols used to modify the contents 
of the repositories.

Rob

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Mar 2008 11:34:42 -0400

At 9:55 AM +1000 3/18/08, Robert Loomans wrote:
>Content-Type: multipart/signed; 
>protocol="application/x-pkcs7-signature"; micalg=sha1; 
>boundary="------------ms040001000803000508020806"
>
>Tony Li wrote:

Rob,

It has been suggested that access to repositories might be 
TLS-protected, even though the data is intended to be widely 
available.  The motivation is that requiring a TLS credential (issued 
under the RPKI) could be used to reject DoS attacks by complete 
outsiders.  Of course, one has to pay close attention to the 
implementation details to ensure that use of TLS does not itself 
become a vector for a DoS attack.

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 18 Mar 2008 13:25:15 -0400 (Eastern Daylight Time)

> At 9:55 AM +1000 3/18/08, Robert Loomans wrote:
<snip>
> outsiders.

Can you say more about the TLS credential issued under the RPKI?

First - so the credential would point in some way to the resource held as 
the source of the access?

Second - are you suggesting that a repository would not be open to those 
who were not resource holders?  (Like: academics looking for allocation 
patterns for research purposees would be just as denied as the trolls 
looking for allocation patters for commercial purposes?)

Third - do commercial entities running global repositories as a service 
have a way to get such a TLS credential?

What is it that I am missing?

--Sandy

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Mar 2008 16:29:05 -0400

At 1:25 PM -0400 3/18/08, Sandra Murphy wrote:
>First - so the credential would point in some way to the resource 
>held as the source of the access?

it would, implicitly, as do all RPKI certs, but the only check needed 
here is that it is a valid cert under the RPKI.

>Second - are you suggesting that a repository would not be open to 
>those who were not resource holders?  (Like: academics looking for 
>allocation patterns for research purposees would be just as denied 
>as the trolls looking for allocation patters for commercial 
>purposes?)

the primary function of a repository is to provide certs, CRLs, ROAs, 
etc. to ISPs. access to anyone else is a secondary issue.

>Third - do commercial entities running global repositories as a 
>service have a way to get such a TLS credential?

we have not discussed the need for such third parties to operate repositories.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Wed, 19 Mar 2008 09:00:18 +1100

>> under the RPKI) could be used to reject DoS attacks by complete

Perhaps the clarifying question is: are you talking about read access or write access?

The comments I've seen that support the notion of no need for TLS support appear to refer to read access, where anyone can be a relying party and the combination of manifests and digital signatures on retrieved objects is sufficient to ensure that the relying party can determine the completeness and validity of the retrieved information.

The comments I've seen in favour of TLS appear to refer to write access where a CA or EE has outsouced the publication repository management function to a third party and there may be some need for a secured channel of write access as a means of DOS protection.

The drafts on this topic (draft-huston-sidr-repos-struct-01.txt, and draft-ietf-sidr-res-certs-09.txt) refer only to read access.

---

From: "Michele (Mike) Hjorleifsson" <[email-masked]>
Date: Tue, 18 Mar 2008 22:09:07 -0400

I believe the conversation was centered around write access, to ensure  
an unauthorized individual couldnt corrupt the repository

On Mar 18, 2008, at 18:00 , Geoff Huston wrote:

> The comments I've seen that support the notion of no need for TLS  
> support appear to refer to read access, where anyone can be a  
> relying party and the combination of manifests and digital  
> signatures on retrieved objects is sufficient to ensure that the  
> relying party can determine the completeness and validity of the  
> retrieved information.
>
> The comments I've seen in favour of TLS appear to refer to write  
> access where a CA or EE has outsouced the publication repository  
> management function to a third party and there may be some need for  
> a secured channel of write access as a means of DOS protection.
>
> The drafts on this topic (draft-huston-sidr-repos-struct-01.txt, and  
> draft-ietf-sidr-res-certs-09.txt) refer only to read access.
>
>
>

---

From: Robert Loomans <[email-masked]>
Date: Wed, 19 Mar 2008 12:51:15 +1000

> an unauthorized individual couldnt corrupt the repository

"the repository" is, I think, the crux of the issue here: there isn't 
just one repository.

The current architecture is that each player in this system will be 
publishing to their own repository or to a repository hosted by someone 
on their behalf.

Each of the RIRs will have a repository, each of their members that run 
their own certifying infrastructure will have their own repository, etc.

The burden of synchronising from all the repositories in existence is 
expected to be mitigated somewhat by various parties, including APNIC, 
running aggregated caches.

At present, there is no draft/spec/whatever standardising how provide a 
hosted repository to 3rd parties. So the issue of write access to "the 
repository" reduces to write access to your own repository... which is a 
very similar to discussing write access to your website: the details 
will vary depending on whether you host it yourself or use a hosting 
service, but you would hope that suitable access control would be in 
place :)

Cheers,
     Rob

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Mar 2008 13:14:19 -0400

>Perhaps the clarifying question is: are you talking about read 

With regard to DoS concerns, I was talking about read access.

>relying party can determine the completeness and validity of the 

I agree that write access poses greater access control concerns in 
general, but we should care about DoS in the context of read access. 
Since I was the one who made the comments, I guess I didn't make them 
clearly enough :-).

>a secured channel of write access as a means of DOS protection.

Yes. There are lots of options here, and it is not clear if we need 
to have one standard way to do this, or just say that suitable access 
controls need to be employed, and give examples of reasonable ways to 
achieve such.

>draft-ietf-sidr-res-certs-09.txt) refer only to read access.

right.

Steve