Re: [sidr] comments needed (Re: I-D Action: draft-ietf-sidr-rtr-keying-14.txt)

[Sean Turner]

Apologies for taking so long to get back to these.  I’ve gone ahead and posted 
-15; -14 was about to expire.  I suspect that there will be a -16 to address 
changes that result from resolving #3-5 and #9.

spt

> On Nov 14, 2017, at 21:07, Sandra Murphy  wrote:
> 
> Well.
> 
> The mail archive does not seem to show attachments.  For me. I see do see 
> attachments on other messages.
> 
> It would be nice to know if anyone has seen attachments on my messages in the 
> last few weeks.
> 
> At any rate, for the mail archive, the comments are copied below the 
> signature.
> 
> —Sandy
> 
> 
> Points that might get lost in the long detailed list that follows:
> 
> 1.  RFC4271 (and RFC6286) and RFC8209 use the term “BGP Identifier”.  The 
> main text says RouterID and the Appendix B says “serial number”.  I believe 
> both are talking about what RFC8209 calls the “BGP Identifier”.  Most of the 
> tech sites say router ID or router-id or routerid or RID or some such.  But I 
> think consistency with the referenced text would be good.

#Sean: Changed throughout the draft to BGP Identifier and added a reference to 
4271.

> 2.  I was initially confused by the text in various places that talks about 
> the operator adding the AS and RouterID (sic) and sends to the CA.  I thought 
> that meant the operator adds those to the CSR, which would be hard since the 
> CSR is signed.  This occurs a couple of places.  I suggest a sentence early 
> on that says the router certificate includes the AS and router identifier but 
> the CSR does not include such fields, so the operator must include the AS and 
> routerID when it sends the CSR to the CA.

#Sean: The setup section explains that the Operator either needs to configure 
the AS and to configure/extract the BGP Identifier.  These values are included 
in the cert req; I guess the way I said they are added was confusing?  I guess 
in s5.1/s5.2 as opposed to saying the operator adds it should just say:

   The PKCS#10 includes the chosen AS number and
   BGP Identifier that the RPKI CA will certify.

> 3.  “corresponds” - there are several places that say the certificate must be 
> validated to prove that the public key corresponds with the private key.  The 
> main body does not say how that correspondence is validated.  The appendix 
> suggests that the operator could validate the signature on the CSR with the 
> returned router cert in order to validate the key.  (a) When the operator 
> generated the public/private key pair, why not just do a comparison to the 
> generated public key, presuming it was retained?  (b) When the operator 
> passed the CSR generated by the router to the CA, why not validate the public 
> key before sending it to the CA?  The public key in the returned router 
> certificate could subsequently be validated by a comparison, presuming the 
> public key was retained.  (c) When the router is supposed to validate the 
> public key of the router cert it receives, and the operator generated the 
> public/private key pair, it does not have a copy of the CSR to validate the 
> correspondence.  Took me a bit to realize the router could sign just any old 
> bit of bytes and then validate the signature with the received router cert.  
> Right?

#Keyur: Ack on A and B. Sean and Randy Can u validate if that makes sense? On C 
we should call this results in incorrect signing of “old bit of bytes”. 
Assuming there is a key rollover period this should be okay as old keys could 
be active? 

#Randy: yes, if the router has both the private and alleged pubic keys, it 
could sign a nonce and then verify it.  but if you worry that the operertor is 
lying to the router, she would be smart enough to give the router a 
public/private pair which matches but is not the same as she negotited with the 
CA.  the router would have to make some sort of check with the CA, i.e. the 
router would need the CA's public key or up-chain.

#Sean: So corresponds means that the public key in the certificate and private 
key are actually a key pair, i.e., the public key can be used to validate a 
signature generated with the private.  In this draft we only do the check on 
the returned certificate because the CA does the check on the certificate 
submitted for certification; that bit is called POP or proof-of-possession.   
Now you can do this by verifying any old signed bag-o-bits or the PKCS#10 and 
if the RPKI package you used to generate the key pair supports it special 
functions that do the verification.  The check in s6 is done when the operator 
does it to check that the CA didn’t screw up and send it the wrong cert; the 
check in s7 covers both the router and operator generated cases because in the 
former the router needs to the check because it made the request and in the 
later the operator may have screwed up and sent the router the wrong cert.  The 
check is repeated in s8 and AppA because we’ll those sections are variations on 
a theme.  So, I was 

Re: [sidr] comments needed (Re: I-D Action: draft-ietf-sidr-rtr-keying-14.txt)

[Sandra Murphy]

The Secretariat has responded to my ticket about the attachment problem noted 
below.

> On Dec 7, 2017, at 5:17 PM, x via RT  wrote:
> 
> Hi Sandy,
> 
> It turns out the archive did not have support for the "text/rtf" mimetype. 
> This
> has now been added and the attachment appears in the messages you referenced
> below.


So .rtf attachments, if anyone were so wise as to try one, should now show up 
in the archive.

—Sandy

> On Nov 14, 2017, at 9:07 PM, Sandra Murphy  wrote:
> 
> Well.
> 
> The mail archive does not seem to show attachments.  For me. I see do see 
> attachments on other messages.
> 
> It would be nice to know if anyone has seen attachments on my messages in the 
> last few weeks.
> 
> At any rate, for the mail archive, the comments are copied below the 
> signature.
> 
> —Sandy
> 
> 
> Points that might get lost in the long detailed list that follows:
> 
> 1.  RFC4271 (and RFC6286) and RFC8209 use the term “BGP Identifier”.  The 
> main text says RouterID and the Appendix B says “serial number”.  I believe 
> both are talking about what RFC8209 calls the “BGP Identifier”.  Most of the 
> tech sites say router ID or router-id or routerid or RID or some such.  But I 
> think consistency with the referenced text would be good.
> 
> 2.  I was initially confused by the text in various places that talks about 
> the operator adding the AS and RouterID (sic) and sends to the CA.  I thought 
> that meant the operator adds those to the CSR, which would be hard since the 
> CSR is signed.  This occurs a couple of places.  I suggest a sentence early 
> on that says the router certificate includes the AS and router identifier but 
> the CSR does not include such fields, so the operator must include the AS and 
> routerID when it sends the CSR to the CA.
> 
> 3.  “corresponds” - there are several places that say the certificate must be 
> validated to prove that the public key corresponds with the private key.  The 
> main body does not say how that correspondence is validated.  The appendix 
> suggests that the operator could validate the signature on the CSR with the 
> returned router cert in order to validate the key.  (a) When the operator 
> generated the public/private key pair, why not just do a comparison to the 
> generated public key, presuming it was retained?  (b) When the operator 
> passed the CSR generated by the router to the CA, why not validate the public 
> key before sending it to the CA?  The public key in the returned router 
> certificate could subsequently be validated by a comparison, presuming the 
> public key was retained.  (c) When the router is supposed to validate the 
> public key of the router cert it receives, and the operator generated the 
> public/private key pair, it does not have a copy of the CSR to validate the 
> correspondence.  Took me a bit to realize the router could sign just any old 
> bit of bytes and then validate the signature with the received router cert.  
> Right?
> 
> 4.  “corresponds” again - there’s no mention of a router verifying that the 
> router cert it receives has an AS that is configured on the router.  There 
> are lots of other checks and double checks - why not this one?  And if the 
> router has multiple ASs and multiple CSRs have been generated (either by the 
> router or by the operator), then the router uses the received router 
> certificate to associate the AS with the public/private key pair, so it knows 
> which private key to use over which session.  Right?
> 
> 5.  Section 8 on “Advanced Deployment Scenarios” talks about routers that 
> already have pre-installed keys (with mentions of types of crypto that are 
> not known to me, and I did not dig up the refs, so I might be missing 
> something here).  The first paragraph talks about “pre-installed key 
> material”.  I could understand why these pre-installed keys might be useful 
> in authenticating the router directly to the CA.  The “burdens” 1 and 2 also 
> talk abut “key material”.  It did not look to me like the “key material” in 1 
> and 2 are talking about these “pre-installed” keys.  But I admit to being 
> very confused by the way the term is used.
> 
> 6.  Section 5.2.1 is titled ”Using PKCS#8 to Transfer Public Key”.  The text 
> talks about using PKCS #8 in RFC5958, which allows for including both the 
> public and private key.  But the text of that section is talking about using 
> PKCS #8 to transmit the private key to the router.  I presume the title 
> should be Using PKCS#8 to Transfer Private Key
> 
> 7.  There is an early assumption that all the communication between the 
> operator and the router is over a protected channel.  Section 5.2.1 suggests 
> using a CMS SignedData to transmit the PKCS#8.  RFC5958 suggests several 
> different “CMS protecting content types” for the PKCS#8 - EncryptedData, 
> EnvelopedData, etc.  I presume that the encrypted versions are not used here 
> because the protected 

Re: [sidr] comments needed (Re: I-D Action: draft-ietf-sidr-rtr-keying-14.txt)

[Sandra Murphy]

Sorry, the reply did not pick up the original attachment.

Attached here.

Let me know if there are problems reading the comments.

—Sandy

{\rtf1\ansi\ansicpg1252\cocoartf1404\cocoasubrtf470
{\fonttbl\f0\fmodern\fcharset0 Courier;\f1\fnil\fcharset0 Menlo-Regular;}
{\colortbl;\red255\green255\blue255;\red0\green0\blue233;\red66\green1\blue120;}
\margl1440\margr1440\vieww16220\viewh17060\viewkind0
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0

\f0\fs24 \cf0 Points that might get lost in the long detailed list that follows:\
\
1.  RFC4271 (and RFC6286) and RFC8209 use the term \'93BGP Identifier\'94.  The main text says RouterID and the Appendix B says \'93serial number\'94.  I believe both are talking about what RFC8209 calls the \'93BGP Identifier\'94.  Most of the tech sites say router ID or router-id or routerid or RID or some such.  But I think consistency with the referenced text would be good.\
\
2.  I was initially confused by the text in various places that talks about the operator adding the AS and RouterID (sic) and sends to the CA.  I thought that meant the operator adds those to the CSR, which would be hard since the CSR is signed.  This occurs a couple of places.  I suggest a sentence early on that says the router certificate includes the AS and router identifier but the CSR does not include such fields, so the operator must include the AS and routerID when it sends the CSR to the CA.\
\
3.  \'93corresponds\'94 - there are several places that say the certificate must be validated to prove that the public key corresponds with the private key.  The main body does not say how that correspondence is validated.  The appendix suggests that the operator could validate the signature on the CSR with the returned router cert in order to validate the key.  (a) When the operator generated the public/private key pair, why not just do a comparison to the generated public key, presuming it was retained?  (b) When the operator passed the CSR generated by the router to the CA, why not validate the public key before sending it to the CA?  The public key in the returned router certificate could subsequently be validated by a comparison, presuming the public key was retained.  (c) When the router is supposed to validate the public key of the router cert it receives, and the operator generated the public/private key pair, it does not have a copy of the CSR to validate the correspondence.  Took me a bit to realize the router could sign just any old bit of bytes and then validate the signature with the received router cert.  Right?\
\
4.  \'93corresponds\'94 again - there\'92s no mention of a router verifying that the router cert it receives has an AS that is configured on the router.  There are lots of other checks and double checks - why not this one?  And if the router has multiple ASs and multiple CSRs have been generated (either by the router or by the operator), then the router uses the received router certificate to associate the AS with the public/private key pair, so it knows which private key to use over which session.  Right?\
\
5.  Section 8 on \'93\expnd0\expndtw0\kerning0
Advanced Deployment Scenarios\'94\kerning1\expnd0\expndtw0  talks about routers that already have pre-installed keys (with mentions of types of crypto that are not known to me, and I did not dig up the refs, so I might be missing something here).  The first paragraph talks about \'93pre-installed key material\'94.  I could understand why these pre-installed keys might be useful in authenticating the router directly to the CA.  The \'93burdens\'94 1 and 2 also talk abut \'93key material\'94.  It did not look to me like the \'93key material\'94 in 1 and 2 are talking about these \'93pre-installed\'94 keys.  But I admit to being very confused by the way the term is used.\
\
6.  Section 5.2.1 is titled \'94\expnd0\expndtw0\kerning0
Using PKCS#8 to Transfer Public Key\kerning1\expnd0\expndtw0 \'94.  The text talks about using PKCS #8 in RFC5958, which allows for including both the public and private key.  But the text of that section is talking about using PKCS #8 to transmit the private key to the router.  I presume the title should be \expnd0\expndtw0\kerning0
Using PKCS#8 to Transfer Private Key\kerning1\expnd0\expndtw0 \
\
7.  There is an early assumption that all the communication between the operator and the router is over a protected channel.  Section 5.2.1 suggests using a CMS SignedData to transmit the PKCS#8.  RFC5958 suggests several different \'93CMS protecting content types\'94 for the PKCS#8 - EncryptedData, EnvelopedData, etc.  I presume that the encrypted versions are not used here because the protected channel ensures confidentiality.  So (a) Appendix A talks about the key strength to be used for the different crypto algorithms (encryption, key exchange, \'85).  That\'92s a big hint that the channel should provide the related security protections.