8 Nov 2006, 0900 - 1130
Geoff Huston & Sandy Murphy
Henk Uijterwaal
Administrivia
Working Group Status (chairs)
Certificate Format (Geoff Huston)
Certificate Policy and Certificate Practice Statement (Steve Kent)
Route Origination Attestation (Sandy Murphy)
Discussion of route origination attestation issues.
The WG agenda items covered the progress with the charter milestones, the resource certificate profile and the initial considerations regarding routing origination attestations.
The efforts on an architecture for inter-domain routing security are falling behind. A group of authors volunteered to work on this in the coming months, so that there is now some confidence that while this milestone is going to be late, a path of progress has been identified. Work on secure origination is also now visible.
We had a report from Russ White, the RSPEC WG co-chair that the IDR requirements documents was close to completion and that they are unable to resolve the issues relating to distinct approaches with respect to path validation. We will await the RPSEC outcomes to understand the situation a little better.
WG Status Report
Sandy Murphy (Co-Chair) reviewed the WG milestones and note that the WG was slipping behind on the document on a secure inter-domain routing architecture.
ACTION:
Sue Hares and Steve Kent volunteer to work on this draft
The certificate profile specification is largely completed, and the ROA activity is starting up.
The upcoming deadlines to complete this work in the period March - June 2007 remain possible.
Certificate Discussion
Resource Certificate Profile
The draft to which this item is speaking to is from APNIC together with an inter-RIR design team.
A resource certificate is based on specific choices made from the PKIX profile (RFC3780 (not the draft 3280bis)), and RFC3779 Resource Extensions. The general constraints are that the RFC3779 extensions are critical and MUST be present. In terms of specific profile, the AIA is cast as a persistent URL, and EE certs are used as one-off signing certificates where the private key is destroyed after a single signing.
Questions / Comments:
Russ White: When should people turn the CA bit off? The draft should offer some guidance.
Steve Kent: The scope of the CRL is all certificates issued by this issuer when using this key. Under key rollover the CRLDP will also follow the new key, so that the CRL is not constant across key rollover.
Steve Kent: We should analyze the impact of this choice of one-off EE certificates. It is an elegant solution for some things, but there might be more. The example cited was the routing table, in the case where an ISP with a /x prefix allocates sub blocks to customers, where those customers become multi homed in the routing system. How many EE certs are involved in this case? Based on use-once principle, it appears that many more EE certs are needed to support sub allocations.
Geoff Huston: Does not envisaging this happening to a large extent (assuming in the response that EE certs are not 1:1 matched with routing objects in terms of constraints on advertisement of more specific prefixes)
Brian Weis: Is the one-off use nature of an EE cert mandatory or a suggested requirement?
Geoff: This is a suggested requirement.
Resource Certificate Trial progress report.
(This report was noted as being an informational item.)
Questions / Comments:
Steve Kent: With respect to your illustration of the use of signing a database object with a signature that was supported by a Resource Certificate then the semantics of the signing need to be carefully defined. The signer is a resource holder, and the result of the signing relates to the resources in the database object.
Steve Kent: Is worried about the opportunity to retrofit data in into existing data structures. Registries can have a diverse range of data, while Resource Certificates only attest to resource holdings. We don't want to create situation where seeing a signature implies trust in all the fields in the object. This unrelated information has to be checked.
George Michaelson: Yes, a Relying Party has to validate this information, and existence of signature is not of itself enough for all the fields in the registry object.
Sandy Murphy: How does AS65000 know the person really is ISPx, entitled to advertise this prefix? Shouldn't this advertising party want email signed by the prefix holder's private key? In your example the resource holder has just destroyed it?
Steve Kent: What Sandy is asking, is, if I send email to my ISP, how do they know that the info I provide, claim to be a particular subscriber of the ISP, is correct, so they bind the (valid) ROA info to the subscriber.
Geoff Huston: The Resource Certificate has limited use. This does not cover secure communication and identity attestation. For such purposes the parties may want to use some other trusted communication framework. Use an identity certificate if identity is the issue in this form of communication.
Steve Kent: The ISP can decide.
Geoff Huston: These Resource Certificates provide tools for validation in the context of use of resources, and are to be used only for this role. They should not be used for unrelated purposes.
Sandy Murphy: We need guidelines for good usage of these certificates.
Certificate Policy and Certificate Practice Statement
The goal here are informational RFCs. The draft CP and CPS documents need review and comments from the Working Group.
Questions / Comments:
Paul Wilson, Is it possible that CPS will conflict as a result of local differences?
Steve Kent: The CPS is per issuer, so there cannot be a conflict here. The template does not instruct an Issuer what it must do.
Brian Weis: This is necessary work, and an informational RFC is a good outcome here. How is a PKI-wide CP enforced?
Steve Kent: Is averse to the term "enforce". However, issuers will declare that they use the CP and hopefully do it according to the CP.
Russ Housley: This can be summarized as a CP for resources. CAs that chose to issue certs will reference this CP by the OID in the issued certificates. Issuers will also write a CPS to state how they meet the requirements in CP.
Taiji Kimura: CP and CPS are helpful are not only helpful afterwards (to see what happened), also useful to build trust infrastructure and planning.
Sandy Murphy: The key pair generation. Is this requestor generated and issuer signs, or issuer generated and signed. Is there a recommended method?
Steve Kent: Its requestor generated and issuer-signed. This does not preclude the requestor using an agent, and the issuer undertaking that agent role.
Route Origination Attestation
ROA Content
[presentation by Geoff Huston]
Questions / Comments:
Steve Kent: Is there benefit in having more than one AS in a ROA?. It could be useful for ISPs running a collection of AS.
Geoff Huston: more than one would be viable, as long as it is one ISP. The multiple-AS ROA fate shares in terms of validity across all the listed AS's.
Steve Kent: When talking about a ROA, the associated resource certificate for the prefix should be validating the ROA for exact prefix or any more specific. From a safety standpoint, should we want an exact match, and explicitly disallow more specifics to be validated from a covering prefix in a ROA? If both the listed aggregate and more specifics can match then is this risky? If you require an exact match without more specifics then isn't this less risky in terms of validating unintended leakage of more specifics?
Simon Leinen: This sounds convincing to me.
Ruediger Volk: In the world of existing allocated prefixes Steve's example may break things. Ruediger always asks for precise prefixes.
Geoff Huston: Noted that more than half the routing table are more specifics that share a common origin. Making the ROA precise would cause the number of ROAs and the number of EE certs to increase proportionately. The issue of whether a ROA allows more specifics or not requires some further consideration.
William Liebzon: In some cases you want constraints, but perhaps we should consult with operational folks as to what they want.
Ruediger Volk: Where do operators communicate routes? Would prefer specific routes for specific address blocks. If this is not expressed in the ROA, where then? If we don't do it here, we are deferring to another level.
Geoff Huston: What do you want from a ROA? Do you want to put routing policy in the ROA? This was not intended as a route policy vehicle as far as I was aware.
Larry Blunk: Allowing more specifics seems to allow lying in path, given correct origin AS.
William Liebzon: Prefers not to have policy in ROAS. Suggests that this be referred to the WG list.
Ruediger Volk: Resource Certs are for address space, while the ROA is to switch over from there to the routing system. Description doesn't imply policy here - it allows you to define more precisely what you are authorizing.
Geoff Huston: will take this to the list. This is a draft being written, so we can do anything at this early stage!
Steve Kent: Trust anchors are chosen by relying party.
Geoff Huston: A ROA doesn't come with trust anchor sets.
ROA format and content proposal
[presentation by Brian Weis]
Similar work, started from a different point of view.
Questions / Comments
Russ Housley: CMS provides a signed object with multiple signatures, which seems to be the proposal here.Issues
[presentation by Sandy Murphy]
Questions / Comments:
Ruediger Volk: Within RPSL, don't touch. For new system: just the address holder is right. Path checking is the thing, and a ROA can't do this.
Geoff Huston: It would be better not to overload ROAs with path validation. We're waiting for RPSEC to give us requirements for paths.
Sandy Murphy: The problem is in ROA, not in path.
Steve Kent: Mixed feelings, if ROA is a right to originate, then it does not need a second signature from the originating AS. It wouldn't solve all path attacks in any case.
Russ White (RPSEC co-chair): The RPSEC IDR current requirements doc is most likely what we'll end up with, and as there have been no comments recently this like the candidate document for a WG last call. This document is not specific on the level of validation required for path validity. The document is expected to be in last call before March 2007.