Subject: [CGA-EXT] about draft-krishnan-cgaext-send-cert-eku-03.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 14 Mar 2009 15:38:40 +0100

Hi,

good work
I think this is in good shape, but i am really far from being an expert 
on this (as my question below reflect)
I have some comments and questions.

2.  Introduction

   Secure Neighbor Discovery [RFC3971] Utilizes X.509v3 certificates for
   performing router authorization.  It uses the X.509 extension for IP
   addresses to verify whether the router is authorized to advertise the
   mentioned IP addresses.

s/addresses/prefixes

   The SEND specification does not describe the set of extensions that
   need to be supported

This is strictly true, right? I mean section 6.3.1.  Router 
Authorization Certificate Profile of the send spec does define the cert 
profile.

4.1.  Extended Key Usage Values

  The inclusion of the router authorization value indicates that the
   certificate has been issued for allowing the router to advertise
   prefix(es) that are mentioned using the X.509 extensions for IP
   addresses and AS identifiers [RFC3779]

I understnad that this means that the router is auhtorized to advertise 
the prefix included in the RADV ND message, right?
I think this shoudl be described more explicitly, I mean, the main 
contribution of the draft is to define these EKU, so it should if very 
precisely, right? would these apply to DHCP prefix delegation for instance?

   The inclusion of the owner authorization value indicates that the
   certificate has been issued for allowing the node to use the
   address(es) or prefix(es) that are mentioned using the X.509
   extensions for IP addresses and AS identifiers [RFC3779]

i am not sure what do you mean about this
Are you aiming for the case we use SEND with non cga addresses? If so, 
it should be more clearly stated. In particualr, i fail to understnad 
why a host could announce more that one address i.e. why prefixes are 
acceptbale. Maybe describing thesecould help

then the draft reads:

   Inclusion of multiple values indicates that the certified public key
   is appropriate for use by a node performing more than one of these
   functions.

     send-kp OBJECT IDENTIFIER ::=
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) TBA1 }

     id-kp-sendRouter OBJECT IDENTIFIER ::= { send-kp 1 }

     id-kp-sendProxy OBJECT IDENTIFIER ::= { send-kp 2 }

     id-kp-sendOwner OBJECT IDENTIFIER ::= { send-kp 3 }

I don't understnad what do you mean by the data strcuture you include 
here... could you clarify? (is it just an example? if, so, please tag it 
as one)

then...

   Certificate-using applications MAY require the extended key usage
   extension to be present in a certificate, and they MAY require a
   particular KeyPurposeId value to be present (such as id-kp-sendRouter
   or id-kp-sendProxy)

where are these keypurposeid are defined?
maybe additng a reference would be useful

then it reads

5.  Backward Compatibility

   The disadvantages of this model are related to the fact that the SEND
   specification was developed before the standardization of the RPKI.
   Hence, SEND is not completely compliant with the RPKI specifications
   since it defines its own IP prefix validation routine and it is not
   suitable for the use with CRLs, while the RPKI suports only CRLs.
   This means that SEND implementations supporting this profile will not
   be able to interoperate with legacy SEND implementations.

I don't fully understnad the implications of this
I mean, what needs to be changed in a current send implementation to be 
compatible with this new format?
I mean, the optimal would be that current send implementations accept 
RPKI certs but skip the new extensions and that new send implementations 
are able to read the new extensions defined by this document. is this 
not possible?

I am missing the part where you actually defines the EKU values for the 
3 usages you have defined... wouldn't this be in the IANA cosiderations 
part of the draft? If not, shouldn't this be somehwere else? I mean, i 
understnad you are assigning 3 values of a registry for that usage? Or 
does this work in a different way?

Regards, marcelo

---

From: "Ana Kukec" <[email-masked]>
Date: Sat, 14 Mar 2009 20:04:05 +0100

Hi Marcelo,

Tnx for the comments, please see my comments below..

marcelo bagnulo braun wrote:
> Authorization Certificate Profile of the send spec does define the 
> cert profile.
>

The send spec describes just the X.509 IP address extension in the 
section 6.3.1 RAC profile, and indirectly the Subject name and the 
subjectAltName extension in the section 6.4.3 TA option.

> I mean, what needs to be changed in a current send implementation to 
> be compatible with this new format?
> RPKI certs but skip the new extensions and that new send 
> implementations are able to read the new extensions defined by this 
> document. is this not possible?

The incompliances between the RPKI and SEND are related to the X.509 
extensions profile and their validation. Regarding the acception of the 
RPKI certificate profile into SeND, there are two problematic 
extensions, the EKU extension (as we already discussed) and the 
subjectAltName extension. The send spec requires the usage of the 
subjectAltName extension in order to match its contents with the Trust 
Anchor option of the FQDN type (as described in the section 6.4.5 of the 
send spec). But, since the RPKI is about the authorization and not about 
the authentication, the subject names in RPKI are not intended to be 
descriptive, and thus the RPKI certificate profile, i.e. 
draft-ietf-sidr-res-certs-16 does not use/describe the subjectAltName 
extension at all.

Regarding the validation routines, the rfc3779 extension validation 
routine conflicts with the one described in the send spec. But together 
with the RPKI certificate profile we can accept the rfc3779 extension 
validation routine.

Contrary to the X.509 extensions and the validation routines, the 
revocation is not a conflicting thing, it is just that the SeND lacks 
the text describing how to incorporate the RPKI revocation into SeND. 
With carefully chosen validity intervals for the RPKI certificates on 
the lower tiers, i.e. at the SEND level,  the CRL is not expected to 
grow to large sizes, and it can fit well into the SEND messages.

Regarding the section 4.1. EKU extension, we will describe it more in 
details, in collaboration with the sidr wg.

Ana

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 14 Mar 2009 20:31:51 +0100

Ana Kukec escribió:
> extensions profile and their validation. Regarding the acception of 
> the RPKI certificate profile into SeND, there are two problematic 
> extensions, the EKU extension (as we already discussed)

right, but my question is what happens when a current send node receives 
a cert with the EKU? does it fails, or does it just skipe the option 
takes the cert as valid?

> and the subjectAltName extension. The send spec requires the usage of 
> the subjectAltName extension in order to match its contents with the 
> Trust Anchor option of the FQDN type (as described in the section 
> 6.4.5 of the send spec). But, since the RPKI is about the 
> authorization and not about the authentication, the subject names in 
> RPKI are not intended to be descriptive, and thus the RPKI certificate 
> profile, i.e. draft-ietf-sidr-res-certs-16 does not use/describe the 
> subjectAltName extension at all.
So, this seems to psoe two problems:
- first, that a current send node will not accept as valid a cert 
without the subjectAltname, right? While this is not optimal, we may be 
able to live with that
- second, how does a send node uses the subjectAltName? i mean does the 
send node needs this information to validate the anchor point? If so, 
how do we deal with this?
> routine conflicts with the one described in the send spec. But 
> together with the RPKI certificate profile we can accept the rfc3779 
> extension validation routine.

not sure waht do you mean here... can we still use the send validation 
routing? Or we need to change the send nodes to do the new validation 
routine?
> grow to large sizes, and it can fit well into the SEND messages.
right, but do we need to specify the revocation routines as well?

I would like to understnad if we need to update rfc3971 to support this, 
i understnad we do. I am not sure i fully understnad what are the 
updates that are needed to rfc3971... could you elaborate on this?

regards, marcelo

---

From: Ana Kukec <[email-masked]>
Date: Sat, 14 Mar 2009 21:38:42 +0100

marcelo bagnulo braun wrote:
> right, but my question is what happens when a current send node 
> receives a cert with the EKU? does it fails, or does it just skipe the 
> option takes the cert as valid?

The draft says that the EKU extension is a critical extension, i.e. if 
the receiving node does not recognize the extension, it must reject the 
certificate.

> without the subjectAltname, right? While this is not optimal, we may 
> be able to live with that
> - second, how does a send node uses the subjectAltName? i mean does 
> the send node needs this information to validate the anchor point? If 
> so, how do we deal with this?

The TA option either helps the receivers to decide which advertisements 
are useful for them or denotes the TAs that the client is willing to 
accept (in the solicitation message). If the TA is represented as a 
FQDN, the FQDN must be equal to the subjectAltName in the TA's certificate.

On the other hand, we can survive with using just the Subject name field 
and the DER Encoded X.501 Name Trust Anchor option..

> routing? Or we need to change the send nodes to do the new validation 

The RPKI uses the validation described in rfc3779 (section 2.3). The 
validation described in the send spec is compliant with that one, but 
more detailed. So, we can just point out that despite using the RPKI 
profile, nodes have to take into account the send validation as well.

> right, but do we need to specify the revocation routines as well?

The RPKI uses the PKI revocation routines with pure CRLs, and if we 
accept the RPKI profile, IMO we should use and process the CRLs in SeND. 
Thus, yes, IMO we should specify messages for the CRL transportation and 
the processing routines for the receivers.

>
> I would like to understnad if we need to update rfc3971 to support 
> this, i understnad we do. I am not sure i fully understnad what are 
> the updates that are needed to rfc3971... could you elaborate on this?

Afaiu, we should update the part about the revocation, and decide what 
exactly to do with the subjectAltName extension, and update that part as 
well.

Ana

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 14 Mar 2009 21:58:17 +0100

Ana Kukec escribió:
>> receives a cert with the EKU? does it fails, or does it just skipe 
>> the option takes the cert as valid?
>
> the receiving node does not recognize the extension, it must reject 
> the certificate.
>
not really

the draft says:

   The extended key usage extension MAY, at the option of the
   certificate issuer, be either critical or non-critical.

So, if we do it as the draft says, it would be compatible with current 
implementations, right?

> The TA option either helps the receivers to decide which 
> advertisements are useful for them or denotes the TAs that the client 
> is willing to accept (in the solicitation message). If the TA is 
> represented as a FQDN, the FQDN must be equal to the subjectAltName in 
> the TA's certificate.
>
> On the other hand, we can survive with using just the Subject name 
> field and the DER Encoded X.501 Name Trust Anchor option..

but wouldn't that be a different use of the semantics of the subject name?

So, afaiu from this, the currnet implementations would not accept certs 
wihtout the TA and they would fial inthis case
We may be able to tweak it in way that we can make this work, by upating 
the send nodes
the other options is to see how posible is for RPKI cert profile to 
accept TA, is this correct?

>> not sure waht do you mean here... can we still use the send 
>> validation routing? Or we need to change the send nodes to do the new 
>> validation routine?
>
>
great

>>> revocation is not a conflicting thing, it is just that the SeND 
>>> lacks the text describing how to incorporate the RPKI revocation 
>>> into SeND. With carefully chosen validity intervals for the RPKI 
>>> certificates on the lower tiers, i.e. at the SEND level,  the CRL is 
>>> not expected to grow to large sizes, and it can fit well into the 
>>> SEND messages.
> accept the RPKI profile, IMO we should use and process the CRLs in 
> SeND. Thus, yes, IMO we should specify messages for the CRL 
> transportation and the processing routines for the receivers.
>
but if we don't do it, it would imply that we have current send support, 
right?

I mean, if we do it, it is an enhacement but we can not do it
I guess it is up to the wg to decide what to do

> exactly to do with the subjectAltName extension, and update that part 
> as well.
>
ok, someone else has an opinion on ths?

regards, marcelo

---

From: Ana Kukec <[email-masked]>
Date: Sat, 14 Mar 2009 22:25:33 +0100

marcelo bagnulo braun wrote:
>>
>> The draft says that the EKU extension is a critical extension, i.e. 
>> if the receiving node does not recognize the extension, it must 
>> reject the certificate.
>>
> not really
>
> the draft says:
>

Right, sorry. Yes, it would be, i.e. it is according to the current text 
in the draft.

>> represented as a FQDN, the FQDN must be equal to the subjectAltName 
>> in the TA's certificate.
>>

No.. what do you mean? According to the send spec the TA option can be 
either of the type DER Encoded X.501 Name (matching the certificate 
Subject name) or the FQDN (matching the subjectAltName).

> So, afaiu from this, the currnet implementations would not accept 
> certs wihtout the TA and they would fial inthis case
> We may be able to tweak it in way that we can make this work, by 
> upating the send nodes

Yes, we can specify the usage of the TA option only of the type X.501 
DN. The other option is to include the subjectAltName in the RPKI 
certificate profile, which is not likely to happen (see the section 3.5. 
in the draft-ietf-sidr-res-certs-16).

> but if we don't do it, it would imply that we have current send 
> support, right?
>

Yes.

Ana