Re: [secdir] secdir review of draft-ietf-lmap-information-model-17

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Mar 09, 2017 at 05:06:00PM +0100, Leif Johansson wrote:
> 
> Reviewer: Leif Johansson
> Review result: Has issues
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> Review:
> 
> Section 3.8 begins "A Channel defines a bi-directional communication
> channel". First of all it is probably a good idea avoid using the
> term you're defining in the definition.

I can s/channel/mechanism/ to avoid the usage of channel while
defining Channel (not sure it adds clarity though).
 
> Also in the text a Channel is described as a URL with the cert or CA
> of the endpoint but in the channel object definition there is only a
> reference to the credentials which I understood to be the client authn
> credential and not the server identity.
> 
> This leads me to a larger issue (which may be answered in another LMAP
> document for all I know): what is the authentication model for LMAP?
> Specifically, does LMAP assume the standard Web PKI for channel end-
> points? If not, then you probably need to specify how to validate the
> server cert which may lead you to want to represent a private CA (say)
> in the channel object. In any case the authentication model should be
> referenced from the Security Considerations section and clearly match
> the information model for channels.

This being an information model, we aim at staying away from being too
specific. The information model is mapped today to a YANG data model
(IETF) and a data model for TR-69 (BBF). The YANG data model may be
accessed today via NETCONF or RESTCONF. There may be other protocols
in the future.  RESTCONF runs over HTTP/TLS, NETCONF runs by default
over SSH (which supportes a number of authentication mechanisms),
NETCONF may also run over TLS. In other words, the concrete details
how authentication is done is specific to the protocols used to access
instantiations of specific data models. This is why we talk about
rather opaque credentials in the definition of ma-channel-obj and
section 2 "Notation" says:

   credentials An opaque type representing credentials needed by a
               cryptographic mechanism to secure communication.  Data
	       models must expand this opaque type as needed and
               required by the security protocols utilized.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>