Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

[Magnus Westerlund <[e-mail]>]

Hi Ben and Brian,

On Fri, 2020-06-05 at 11:00 -0700, Benjamin Kaduk wrote:
> Hi Magnus, Brian,
> 
> Sorry for the slow response here -- I've been trying to meet a deadline at
> work and email responses have suffered.
> 
> I think Brian's discussion and explanations in this thread are generally
> spot-on.  I'll make a few notes inline but they don't really touch on the
> core substance of things.
> 
> I do wonder, though (Magnus), why you are under the impression that (as
> stated in the start of the thread) " for normal Web PKI if a browser opens
> a connection for alice.foo.com and gets a cert that says foo.com and has a
> AltSubjectName: alice.foo.com it will be fine. However, if I put in
> alice.bar.com which is not a subdomain of the primary name in the cert it
> will reject the altSubjectName."  My understanding matches Brian's that all
> SANs and the CN are treated independently (and in particular, that if SANs
> exist, they are generally preferred over CN).

Yes, I guess I made an error in though here. So maybe the better question is
what type of runtime validation that is done related to domain names on the
certificate and its chain, any at all? Or is all this checking happening by the
enitity signing the certificate in the certificate chain? 


What appear clear is that we really should keep the basic checking required for
any TLS usage in TCPCLv4 document seperated from what would be required for any
type of PKI for the DTN or IPN namespaces. 

I think the immediate question here boils down to what are the aspect around
this that we need to note in the TCPCLv4 document? I do note that some of it is
inlide below. 


> 
> [more inline]
> 
> On Tue, Jun 02, 2020 at 12:58:43PM +0000, Magnus Westerlund wrote:
> > Thanks Brian,
> > 
> >  
> > 
> > I think what you write below are quite clear. And I think has reasonable
> > security policies and a particular set of properties. However, I don't think
> > either Section 4.4 or the Security Consideration goes into these. They
> > support these but appear to have more fluid boundaries to even more
> > policies. So the question is if the specification should be more articulate
> > about these two targets and state that additional security policies with
> > associated properties can be defined later either in implementation or
> > future documents. 
> 
> I still have an action item to read the updated I-D, and will try to keep
> this topic in mind as I do so.
> 
> >  
> > 
> > Cheers
> > 
> >  
> > 
> > Magnus
> > 
> >  
> > 
> > From: Brian Sipos <[e-mail]> 
> > Sent: den 1 juni 2020 18:57
> > To: Magnus Westerlund <[e-mail]>; [e-mail];
> > [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with
> > DISCUSS and COMMENT)
> > 
> >  
> > 
> > Magnus,
> > 
> > To clarify two distinct use cases for TCPCL security:
> > 
> > 1.	On a private network, with private PKI and control of a CA:
> > In this situation I see it more as the CA's obligation to coordinate with
> > the network designer so that when a new BP Node is allocated that it gets
> > proper BP configuration, TCPCL configuration, and a TLS certificate (to
> > authenticate the Node ID URI) is produced. The validation of its identity
> > and private key occurs via side channels the same way the Node is otherwise
> > managed and configured.
> > 2.	On a more open network, where some other organization controls PKI
> > roots and signing CAs:
> > In the near term, public CAs only know how to validate DNS names and are
> > likely only willing to sign certificates with DNS name SANs. In this case
> 
> I don't think this is quite true, depending on how you define "public CAs".
> There's a very long thread (including, unfortunately, a lot of redundant
> bits where people are talking past each other) on a similar topic, what it
> means to be a "public CA", and what "public CAs" currently can and are
> (not) willing to do, in the thread at
> https://mailarchive.ietf.org/arch/msg/emu/8G6q7TnhgixgS92QWBNqL7vWd2U/
> 
> Key topics include the need for an agreed set of rules for CAs to operate
> by in order for consuming applications to put trust in the certifications
> coming out of the CAs.  That is, a sense that if the rules are followed,
> then clients will get the properties they need by trusting the CA
> signatures.  And, of course, enough people doing enforcement that CAs
> actually follow the rules properly, to keep things working right.
> 
> We're thinking about potentially having a future SAAG talk about non-web
> PKI topics (and if there's guidance we can/should give for starting such an
> ecosystem).
> 
> > the CA doesn't know or care about the Node ID and any BP Node which
> > authorizes transfers to/from a TCPCL entity with a DNS-only authentication
> > just has to have an implicit trust that an authenticated DNS name will not
> > falsely claim a Node ID. This risk is identified in Section 8.8 "Threat: BP
> > Node Impersonation" [1] and a BP Node can choose accept this risk as a
> > policy decision.
> > 
> > I think both of these situations are reasonable if BP is used to traverse an
> > open network where some of the intermediate nodes are not fully trusted.
> > Like you said, it would be possible for the configuration of a node to have
> > a specific whitelist of which public hosts are trusted to forward bundles.
> > And maybe the node policy can be nuanced as you have stated so that if a
> > node is the bundle destination it *must* have a TLS-authenticated Node ID.
> > In the end, the whole point of CL-level security is to ensure that
> > data/bundles are not being leaked in the clear on a single hop. You still
> > need to use BPSEC if the intent is to guaruantee integrity or authenticity
> > of the bundle itself.
> > 
> >  
> > 
> > Because ACME [2] provides a solid infrastructure to separate the mechanisms
> > of how to challenge and validate a claim from what to do with the validated
> > claims (i.e. issue a requested certificate), if it seems reasonable I am
> > willing to create a draft of a new ACME challenge type for validating a DTN
> > Node ID using a new BP administrative record type. This challenge type would
> > be extremely logically simple and could be done on its own, outside of an
> > ACME server, to validate ownership of a Node ID in a more "manual" way.
> > Doing this gives us something more concrete than a BCP explaining a
> > procedure.
> 
> I am wary of describing this as "outside of an ACME server": the separate
> account-provisioning step and cryptographic means to bind an intent to
> authorize a given name by a given account to the actual challenge and
> challenge-validation steps are important parts of achieving the properties
> that ACME provides.
> 
> >  
> > 
> > [1] https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-20#section-8.8
> > 
> > [2] https://tools.ietf.org/html/rfc8555#section-8
> > 
> >  
> > 
> >   _____  
> > 
> > From: Magnus Westerlund <[e-mail]
> > <mailto:[e-mail]> >
> > Sent: Monday, June 1, 2020 09:53
> > To: [e-mail] <mailto:[e-mail]>  <[e-mail]
> > <mailto:[e-mail]> >; Brian Sipos <[e-mail]
> > <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]>
> > <[e-mail] <mailto:[e-mail]> >
> > Cc: [e-mail] <mailto:[e-mail]>  <[e-mail]
> > <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]>
> > <[e-mail] <mailto:[e-mail]> >; [e-mail]
> > <mailto:[e-mail]>  <[e-mail]
> > <mailto:[e-mail]> >; [e-mail]
> > <mailto:[e-mail]>  <[e-mail]
> > <mailto:[e-mail]> >
> > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with
> > DISCUSS and COMMENT) 
> > 
> >  
> > 
> > Hi,
> > 
> > I would appreciate the SEC ADs input on this. 
> > 
> > I think you are correct that PKI structure and how to validate IPN and DTN
> > URI
> > in regards to the certificats are seperate document. 
> > 
> > So don't we have two different aspects here for TCPCLv4. One when it is used
> > as
> > CL to reach a next hop in the routing infrastructure, where the sending
> > agent
> > only need to know that it connected to the intended next hop. The other case
> > is
> > when the agent uses the CL to directly reach the peer agent with the
> > intended BP
> > layer destination Node ID. Maybe I have focused to much on the later and it
> > is
> > only the former that actually are needed here. Still BP routers do have
> > their
> > own Node ID and thus, I guess the identification dilema for Node IDs do
> > remain. 
> 
> (I think this dilemma is at the core of my uneasiness with the draft
> originally proposed for IESG Evaluation.  It's not a problem that's fully
> solvable, though, so we'll need to clearly document what we do/don't do and
> move on, as was noted later in the thread.)
> 



-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------