Subject: Proceeding issue 20: Francis Dupont's certificate issues

From: Pekka Nikander <[email-masked]>
Date: Wed, 15 Oct 2003 13:44:28 +0300

I believe that I have now resolved the majority of the
certificate issues, as discussed on the list on issue #20.
I still need to check that this covers all comments
on issue #08, but I'll do that later.

The new certificate text reads as follows:

-------------------------------------------------

6.5 Router Authorization Certificate Format

    The certificate chain of a router terminates in a Router
    Authorization Certificate that authorizes a specific IPv6 node to act
    as a router.  Because authorization chains are not a common practice
    in the Internet at the time this specification is being written, the
    chain MUST consist of standard Public Key Certificates (PKC, in the
    sense of [22]).  The certificates chain MUST start from the identity
    of a trusted root that is shared by the host and the router.  This
    allows the host to anchor trust for the router's public key in the
    trusted root.  Note that there MAY be multiple certificates issued by
    a single trusted root.

6.5.1 Router Authorization Certificate Profile

    Router Authorization Certificates MUST contain the X.509 extension
    for IP addresses, as defined in [13].  The parent certificates in the
    certificate chain MUST contain one or more X.509 IP address
    extensions, back up to the delegating authority (the Regional Address
    Registry or IANA) that delegated the original IP address space block.
    The certificates for intermediate delegating authorities MUST contain
    X.509 IP address extension(s) for subdelegations. The router's
    certificate is signed by the delegating authority for the prefixes
    the router is authorized to to advertize.

    The X.509 IP address extension MUST contain at least one
    addressesOrRanges element that contains an addressPrefix element with
    an IPv6 address prefix for a prefix the router or the intermediate
    entity is authorized to advertize.  If the entity is allowed to route
    any prefix, the used IPv6 address prefix is the null prefix, 0/0.
    The addressFamily element of the containing IPAddrBlocks sequence
    element MUST contain the IPv6 AFI (0002), as specified in [13] for
    IPv6 prefixes.  Instead of an addressPrefix element, the
    addressesOrRange element MAY contain an addressRange element for a
    range of prefixes, if more than one prefix is authorized.  The X.509
    IP address extension MAY contain additional IPv6 prefixes, expressed
    either as an addressPrefix or an addressRange.

    A SEND node receiving a Router Authorization Certificate MUST first
    check whether the certificate's signature was generated by the
    delegating authority.  Then the client MUST check whether all the
    addressPrefix or addressRange entries in the router's certificate are
    contained within the address ranges in the delegating authority's
    certificate, and whether the addressPrefix entries match any
    addressPrefix entries in the delegating authority's certificate.  If
    an addressPrefix or addressRange is not contained within the
    delegating authority's prefixes or ranges, the client MAY attept to
    take an intersection of the ranges/prefixes, and use that
    intersection.  If the addressPrefix in the certificate is the null
    prefix, 0/0, such an intersection SHOULD be used.  (In that case the
    intersection is the parent prefix or range.)  If the resulting
    intersection is empty, the client MUST NOT accept the certificate.

    The above check SHOULD be done for all certificates in the chain
    received through DCA messages.  If any of the checks fail, the client
    MUST NOT accept the certificate.

    Since it is possible that some PKC certificates used with SEND do not
    immediately contain the X.509 IP address extension element, an
    implementation MAY contain facilities that allow the prefix and range
    checks to be relaxed. However, any such configuration options SHOULD
    be off by default.  That is, the system SHOULD have a default
    configuration that requires rigorious prefix and range checks.

----------------------------------------------------

Comments?

Considering the minor points, I have resolved them as follows:

> Francis Dupont writes and Jari Arkko responds:
>
>>  - 6.3 Trusted Root Option (comment)
>> 
>>   => you don't support two root certificates for the same root...
>>   I propose to add a name type where one can put a hash of the
>>   certificate. For the hash itself the objectDigest seems perfect.
> 
> Sounds good. Pekka?

The text has now been clarified that a host may be configured with
several trusted root, and that there may be several certificates
issued by a trusted root.  The idea of using hashes to identify
trusted roots were not adopted.

>>   BTW I don't understand why we should not put PKIX certificates?
>>   IKEv2 does this, and it can make interoperability between implementations
>>   less problematic.
> 
> There's a pending discussion about the exact certificate types
> used.

The new text indeed uses PKC certificates, with the IP address
extension.

>>  - 6.5 Router Authorization Certificate Format (comment)
>> 
>>    MUST consist of standard Public Key Certificates (PKC, in the sense
>>    of [11]) for identity from the trusted root shared with the host to
>> 
>>  => [11] (PKIX) doesn't use this term... IMHO the right reference is [12]
>>  and the introduction text of [12] about PKC and AC should be copied!
> 
> Sounds right. Pekka?

Used RFC3281 as the reference.  Moved RFC3281 is now an informational
reference instead of normative.

>>  - same (comment)
>> 
>>    acinfo.attributes
>> 
>>       This field MUST contain a list of prefixes that the router is
>>       authorized to route
>> 
>>   => I disagree: a router is not authorized to route a prefix, it is
>>   authorized to advertise/annonce a prefix. About routing perhaps
>>   it should be useful to authorize (or not) a router to be a default
>>   router?
> 
> Right. This has been covered under issue #5.

Changed all text to read that a router/entity is authorized to
advertize a prefix, not to route it.

>>  - same (comment)
>> 
>>       If the router is authorized only to route specific prefixes, the
>>       ipAddress values consist of IPv6 addresses in standard RFC 3513
>>       [13] prefix format.
>> 
>>   => my problem is that ipAddress can't encode prefix in RFC 3513 format
>>   (i.e., ipAddress can get a mask but not <address>/<prefix_len>).
>>   Please clarify, for instance with an example. RFC 3280 one is:
>>     For example, a name
>>     constraint for "class C" subnet 10.9.8.0 is represented as the octets
>>     0A 09 08 00 FF FF FF 00, representing the CIDR notation
>>     10.9.8.0/255.255.255.0.
> 
> Ok.

This comment does not apply any more as we have changed the
certificate format.

>> PS: I can't find how to verify certified addresses, even for routers.
>> (this is not in 9.2)
> 
> Indeed this is missing!

I removed the remaining text that discussed certifying router's
addresses.

--Pekka Nikander

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------