Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

[Toerless Eckert <[e-mail]>]

On Thu, Feb 15, 2018 at 05:32:30PM +0000, Max Pritikin (pritikin) wrote:
> Certificates are a data format for encoding public keys and associated certifications (e.g. the CA signature) etc. I think this could reasonably be called data needed to establish a cryptographic security association. 

Ok, great. Then i would just love to see a definition stating keying material
in the context of BRSKI includes public, private keys, certificates and vouchers.

> > IMHO, I need certificates to establish (authenticate) the cryptographic security
> > association when i am using certificates.  Likewise would a voucher
> > be keying material because it is required for authentication.
> 
> If we???re stretching like this then sure. A voucher is a certification of a public key (the new owner) along with additional data used to interpret the certification. If you keep going down that path you???re gonna end up claiming we should have simply had an X509 extension instead of a voucher format. There are reasons we didn???t go that way but I could see a world where that happened (thankfully not our reality though). 

I am happy with vouchers being clearly distinguished from certificates. I just
want well defined names such as what "keying material" is. Any term we
can not clearly define (or point to clear definitions) should be avoided in the document. 
rfc4949 is IMHO not clearly defined for "keying material".

> > brski keying entities = pledge + registrar + CA ( + MASA ?)
> >  Possible non-crypto speaker confusion: Is MASA part of keying entities ?
> >  If keying material is just the public key pairs, then probably not ?
> 
> Why not? Its all part of the key infrastructure in that these are the entities (and associated protocols!) needed to manage all the key material. 

Again: I have no strong opinions. But yes, if certificates and vouchers where not
keying material we would need yet another work that includes them.

> There is something different about ???authentication key material??? and ???certification key material??? but is it necessary for us to get into those pedantic areas? Are you proposing an update to RFC4949? Where are we going with this? 

For the readers of BRSKI i would like to minimize the need to refer
to confusing external documents, especially wrt. terminology.
I am declaring myself the the expert to represent the non-native
security speaking reader.

For IESG security review we need to make sure that the way we're using and
probably extending the existing terminology is acceptable. You're the
better judge for that, and if not, you'll hear from Eric.

> >  But would BRSKI without a following EST part even be "keying entities??? ????
> 
> BRSKI and EST are protocols not ???entities???. But yes, BRSKI is a part of the key infrastructure. It is the protocol for ???bootstrapping [the] remote [portion of the] secure key infrastructure???. 

Sorry, yes..

> > brski keying protocols = BRSKI+ EST (pledge/registrar), EST (registrar/MASA), BRSKI-EST (registrar/MASA)
> > 
> > brski keying infrastructure = brski keying entities + brski keying protocols
> > 
> > Or whatever else is correct in the context of BRSKI. Better to just enumerate whats
> > meant like i suggested above instead of trying generic definitions because those
> > can fail on non-native crypto speakers like my above confusion with rfc4949.
> > 
> > Also it wold be good if there was a clear understanding if BRSKI claims to expand
> > the scope of any of these terms. Eg: If MASA or vouchers are now considered to
> > be part of any prior existing terms such as keying material or keying infra. I
> > guess that "keying protocols" are definitely expanded by BRSKI???
> 
> Based on the above I think its fair to say that:
> 
> Voucher???s expand on the defined key material data types. 
> BRSKI protocol and MASA entity expand on the defined types of key infrastructure elements. 

Great. So please put into the terminology section those simple explanations
of the terms used/required by BRSKI.

Cheers
    Toerless

> - max
> 
> > 
> > Cheers
> >    Toerless
> > 
> >> 
> >> - max
> >> 
> >>> 
> >>>> c) (terminology) MASA definition: "A third-party Manufacturer...". Why "third-party" ?
> >>>> who are the first two parties ? If this is only slang and we can't explain who the
> >>>> first two parties are, delete "third-party" ?
> >>> 
> >>> Fixed...  The first party is the Pledge and manufacturer.
> >>> The second party is the Domain Owner.
> >>> The third party is the entity running the MASA, which may not be the manufacturer.
> >>> 
> >>>> d) "Domain Registrar" vs. "Join Registrar", JRC. Especially because the text mostly
> >>>> uses "Domain Registrar" and very seldom "Join Registar".
> >>> 
> >>> Yes, because we agreed that the term across WGs would be JRC, and we say
> >>> in the terminology that we shorten it to Registrar.  We say "Domain
> >>> Registrar" because we want to link it to the PKI concept of a Registration
> >>> Authority (RA).
> >>> 
> >>>> JRC is used in exactly three places in the draft. I also can not find on www.google.com
> >>>> or wikipedia any example of "The term JRC is used in common with other bootstrap
> >>>> mechanisms" as the Terminology claims. Either provide a non-anima reference for the
> >>>> use of that term or eliminate it in the document.
> >>> 
> >>> We agreed to use common terms.
> >>> It was a thread on ANIMA and 6tisch a year ago.
> >>> I can't get mailarchive to find it for me...
> >>> Ah, I see because "JRC" was never used contracted in that thread.
> >>>   https://mailarchive.ietf.org/arch/msg/anima/iotBM0-kxsIB66t8hBo4XUtZLag
> >>> 
> >>> As long as they Informative references.
> >>> https://tools.ietf.org/html/draft-ietf-6tisch-architecture-13#section-6.1
> >>> https://tools.ietf.org/html/draft-ietf-6tisch-terminology-09
> >>>       (yes, expired, but not forgotten, just not a priority)
> >>> 
> >>>> e) Voucher
> >>>> - misses ":" after term.
> >>>> - please change "statement" to "artifact" so the terminology aligns with both voucher
> >>>> draft and voucher-request text which also uses artifact. See also section 2.2
> >>>> where you use "cryptographically protected" instead of "signed" and figure out
> >>>> which term you want to use in all cases (hint: signed).
> >>> 
> >>> I've changed it to:
> >>> <t>A voucher is a cryptographically protected artifact (a digital signature) to the Pledge
> >>> 
> >>> I feel that we need to say it's cryptographically signed at least once.
> >>> 
> >>>> f) IMPORTANT: Please add/define the term "ANI"
> >>> 
> >>>> ANI - "Autonomic Network Infrastructure". Systems that support both BRSKI and
> >>>> Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-plane]). ANI
> >>>> systems (pledges, proxies, registrar) have specific requirements detailled in
> >>>> the document.
> >>> 
> >>>           <t hangText="ANI:">The Autonomic Network Infrastructure as
> >>>           defined by <xref target="I-D.ietf-anima-autonomic-control-plane"
> >>>           />.  This document details specific requirements for pledges,
> >>>           proxies and registrars when they are part of an ANI.</t>
> >>> 
> >>> Does this work for you?
> >>> 
> >>>> Without this term we can not nail down the explicit requirements against
> >>>> ANI Pledges, Proxies, Registrars that we need from the document (and distinguish
> >>>> from requirements against any non-ANI adaptation of BRSKI). I added according
> >>>> comments into other parts of the doc.
> >>> 
> >>>> g) Please replace "MASA server" with "MASA service" everywhere.
> >>> 
> >>> I prefer to just say "MASA" actually.
> >>> Are you okay with that?
> >>> 
> >>> Let me wrap up here for the moment so you can see the edits and
> >>> I'll reply to the rest as Max and I digest it.  It's a lot of comments.
> >>> I'd like to push an -11 (if only to fix email for M. Behringer).
> >>> 
> >>>   https://github.com/anima-wg/anima-bootstrap/pull/42
> >>>   https://github.com/anima-wg/anima-bootstrap/pull/42/commits/cb7af66344ad709aaf70287a40fa13a67bbf601c
> >>> 
> >>> 
> >>> --
> >>> Michael Richardson <[e-mail]>, Sandelman Software Works
> >>> -= IPv6 IoT consulting =-
> >>> 
> >>> 
> >>> 
> >>> _______________________________________________
> >>> Anima mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/anima
> >> 
> >> _______________________________________________
> >> Anima mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/anima
> > 
> > -- 
> > ---
> > [e-mail]
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[e-mail]