Subject: [Sidr] draft on minutes of the SIDR WG meeting

From: Geoff Huston <[email-masked]>
Date: Fri, 10 Nov 2006 01:50:03 +1100

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-masked]
https://www1.ietf.org/mailman/listinfo/sidr

---

From: [email-masked] (Sandy Murphy)
Date: Thu, 9 Nov 2006 10:13:41 -0500 (EST)

>Brian Wise

Brian Weis

>    Similar work, started from a different point of view.

Russ Housley did note that CMS provided exactly the signed object with
multiple signatures structure shown in the ASN.1 encoding.

--Sandy

---

From: [email-masked] (Sandy Murphy)
Date: Thu, 9 Nov 2006 11:25:41 -0500 (EST)

>    Similar work, started from a different point of view.

One more (this could have been an off-mike exchange, if so, sorry)

   Sandy Murphy: why a list of signatures?

   Brian Weis/Geoff Huston: with mulitiple trust anchors, it is possible
      that you might have multiple resource certificates for the same
      prefixes.  You would need to sign the ROA with all those certificates
      so that it would validate no matter what trust anchor "relying
      parties" might use.

--Sandy

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Nov 2006 11:59:49 -0500

>       so that it would validate no matter what trust anchor "relying

This is not the way that a PKI would be expected to work, in general. 
A signer of data cannot in general know what TAs RPs may select, so 
it is not incumbent on a signer to try to provide multiple signatures 
to accommodate this uncertainty. In our context, a signer selects a 
cert that embodies the necessary authorization and uses the 
corresponding private key. It is up to an RP to construct a path to 
one of his TAs to verify the signature.

Steve

---

From: [email-masked] (Sandy Murphy)
Date: Thu, 9 Nov 2006 14:58:27 -0500 (EST)

>to accommodate this uncertainty.

(This isn't a matter for the minutes, since it wasn't mentioned in
the meeting.   So I changed the subject.)

So you are saying that there is no need for the list of signatures
in the ROA that Brian Weiss was showing?

Suppose there were a small handful of commonly used trust anchors
Would you then say that a list of signatures made sense?
(Obviously, if there were a wild plethora of trust anchors in use,
trying to list all needed ones would be infeasible.
And we don't know which will be the case.)

Having a list of single signature ROAs works as well as a single ROA
with a list of signatures, I believe.  So this is not a functional
difference, more an engineering decision.

--Sandy

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Nov 2006 16:14:30 -0500

>in the ROA that Brian Weiss was showing?

not for the reasons cited in your message.

>Would you then say that a list of signatures made sense?

well, if the list is "commonly used" then you could pick any one, right :-)?

>And we don't know which will be the case.)

right.

>difference, more an engineering decision.

I still think this is the wrong model. The original rationale for 
multiple signatures for a ROA was NOT to accommodate multiple TAs, 
but rather to accommodate a ROA that contained prefixes acquired from 
multiple sources, and thus no EE cert could be created that merged 
these prefixes (due to RFC 3779 constraints).

Thus there may still be a good basis for supporting multiple 
signatures for a ROA, if we want to allow a ROA to contain prefixes. 
However, if we become comfortable with the notion that one should 
just create multiple ROAs in these circumstances, we can live with a 
single signature ROA syntax. This also would obviate a security issue 
Geoff raised, i.e., stripping a signature from a ROA.

Steve

---

From: [email-masked] (Sandy Murphy)
Date: Thu, 9 Nov 2006 18:09:19 -0500 (EST)

>well, if the list is "commonly used" then you could pick any one, right :-)?

I meant suppose there were a set of TAs that covered the TAs that were
commonly used.  Not that common use was to use the entire set.

>these prefixes (due to RFC 3779 constraints).

That is a different answer than was given in the meeting, but it is
an answer I had half expected.

The question then becomes whether we have to relate each signature to
the prefixes it covers, or whether we are OK with a validation rule
that as long as the stated prefixes are completely covered by the
union of the prefixes associated with the signatures, the ROA is valid.

--Sandy