thanks Henk for your notes!
Geoff
Secure Inter-Domain Routing WG (sidr)
IETF 67, San Diego
WEDNESDAY, November 8, 2006
0900-1130 Morning Session I
====================================================
CHAIR(s): Geoff Huston <gih at apnic.net>
Sandra Murphy <sandy at tislabs.com>
AGENDA:
1) Administrivia 5 minutes
- Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html
- Scribe: Henk Uijterwal
- Blue Sheets
- Agenda Bashing
2) WG Status Report 10 minutes
Chairs
3) Certificate Discussion (Geoff Huston) 30 minutes
A Profile for X.509 PKIX Resource Certificates
draft-ietf-sidr-res-certs-02.txt
Available at:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-02.txt
This will discuss the latest version of the resource certificate
draft and report on the status of a trial implementation of resource
certificates.
4) Certificate Policy and Certificate Practice Statement (Steve Kent)
30 minutes
Template for an Internet Registry's Certification Practice Statement
(CPS) for the Internet IP Address and AS Number (PKI)
draft-ietf-sidr-cps-irs-00.txt
Available at:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-00.txt
Certificate Policy (CP) for the Internet IP Address and AS Number (PKI)
draft-ietf-sidr-cp-00.txt
Available at:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-00.txt
This will discuss both a certificate policy for a PKI used for
resource certificates and a template for a Certification Practice
Statement (CPS) for an Internet Registry.
5) Route Origination Attestation (Sandy Murphy) 30 minutes
Discussion of route origination attestation issues.
SUMMARY:
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.
NOTES:
2. 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:
Sure 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.
3. Certificate Discussion
a. 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 Wise: Is the one-off use nature of an EE cert mandatory or a
suggested requirement?
Geoff: This is a suggested requirement.
b. 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.
4. 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 Weiss: 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.
Taijii: 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.
5. Route Origination attestation
a. ROA Content
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.
b. ROA format and content proposal
Similar work, started from a different point of view.
No Questions / Comments
c. Issues
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.
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
