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

From: Leif Johansson <[email-masked]>
Date: Thu, 9 Mar 2017 17:06:00 +0100

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.

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.

	Cheers Leif

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 12 Mar 2017 12:52:00 +0100

> 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).
 
> 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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Leif Johansson <[email-masked]>
Date: Mon, 13 Mar 2017 08:46:05 +0100

>                required by the security protocols utilized.

The level of abstraction is beside the point. If you want your model
to reflect authentication for client then you need a credential in the
model (which you have).

If in addition, you need to control how you validate the server cert
then you need something in the model that represents that. Given your
model that could be a credential too. It depends on what you want to
do but it doesn't depend on the level of abstraction of your model.

	Cheers Leif