Subject: [Netconf] Questions about draft-ietf-netconf-tls-04.txt

From: Alan Luchuk <[email-masked]>
Date: Mon, 6 Oct 2008 14:39:49 -0400 (EDT)

Hello,

Regarding NETCONF over TLS, I have two questions.  If these questions 
have been answered already, would someone kindly point me to relevant 
information?

RFC 4742 (NETCONF over SSH, Section 3.1) specifies a "framing sequence"
to be inserted after each NETCONF message.  Why is this framing sequence
not needed or specified for NETCONF over TLS?  It would seem that in either
case, the transport layer (SSH or SSL) is simply a "data pipe", and that 
if a framing sequence is needed for SSH, it would also be needed for TLS.  
Making the framing sequence mandatory over SSH but not over TLS requires 
two slightly different software implementations.

Second, when implementing a NETCONF server over TLS, how is a user identity 
derived for the purposes of data view access control?  Although not specif-
ically mentioned in RFC 4742, I believe such a user identity can be obtained 
from the process environment of the NETCONF server SSH subystem (on open
systems, at least), based upon the username specified during the launch of 
the SSH client.

Thanks in advance for any/all information!

Regards,
--Alan

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Oct 2008 21:40:54 +0200

> two slightly different software implementations.

See the last paragraph in section 2.1 for an answer.
 
> systems, at least), based upon the username specified during the launch of 

NETCONF does not (yet?) have access control and hence the question can
probably be postponed (I think all NETCONF transports are silent how a
name for the authenticated client is derived for authorization
purposes - although for some transports the answer might be pretty
obvious).

Using the local user identity does not make much sense to me; you want
something that is linked to the authenticated identity of the NETCONF
client, e.g. a name derived from a certificate. ISMS is facing similar
questions, although SNMP over TLS/DTLS is not an ISMS work item so far
(but there are IDs about these transports).

/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/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Oct 2008 21:40:54 +0200

/js