Re: NETCONF over TLS

[Tomoyuki Iijima <tomoyuki.iijima.fg@hitachi.com>]

Hi,

I agree with the following Andy's comment.

Andy Bierman wrote:

> > IMO, this should be handled with a different top-level element
> > than <rpc>, outside the scope of the NETCONF protocol.
> > That way, no special RPC code is needed at all.
> > Only sessions that have been properly authenticated, and <hello>
> > messages are okay, should be allowed to use <rpc> methods.

NETCONF and TLS are completely separeted mechanism. TLS were
standardized to carry any application/transport protocol. Since
SOAP/BEEP have been chosen as transport protocol of NETCONF, we don't
need to care about TLS over which SOAP/BEEP would run. Additionaly,
TLS's authentication mechanism is described fully in the RFC 2246. So,
NETCONF does not need to care about authentication. It is unnecessary to
publish NETCONF/TLS-like document.

In the following draft, I wrote my view about security in the case of
NETCONF/SOAP.
http://www.ietf.org/internet-drafts/draft-iijima-netconf-soap-implementation-02.txt

4.  Security Consideration

   Security should be considered from 2 angles.  One is transport-level
   security, and the other is message-level security.  Transport-level
   security such as encryption of entire message is left to SSL/TLS.
   However, the message-level security such as partial encryption of
   message or signature should be achieved by other technologies.  To
   fulfill that need, WS-security has been stipulated.

-- 

Eliot Lear wrote:
> David B Harrington wrote:
>> If BEEP is just TLS + SASL + framing, why can't we just use TLS + SASL
>> + framing? Where is the value-add for using BEEP instead of using the
>> independent components? How does BEEP make it easier for an operator
>> to operate their network than if they simply used TLS + SASL + a
>> standardized framing approach?
>>   
> 
> I think these are good and fair questions.  First, I didn't say that
> BEEP is *only* that.  BEEP has a couple of what I would call frills,
> like the ability eliminate directionality to ease "call home".  That's
> going to valuable to operators who need to manage hundreds of thousands
> of devices.  Again, think along the lines of DOCSIS.  A management model
> where the manager connects to hundreds of thousands of devices is just a
> non-starter.  In addition, the framing allows interspersing of different
> (presumably related) applications.  This would simplify operator
> access-lists, not to mention AAA operations (one versus N).  SSH offers
> this sort of functionality, as you correctly pointed out elsewhere
> yesterday.
> 
> But beyond that, I'd tend to agree with your sentiment.  If you wanted
> to do what I would call a "BEEP light" that does TLS + user login, then
> I implement SASL first, and then a very simple framing protocol that
> NETCONF sits above, particularly one that doesn't require funky tags in
> the data, making parsing a pain.
> 
> And so before you start NETCONF you add some gook along the lines of:
> 
> C: start-netconf
> 
> S: 354-authenticate first
> S: 354-SASL/PLAIN
> S: 354-SASL/OTP
> (...)
> S: 354 SASL/GSS-API
> C: SASL PLAIN username=foo password=bar
> S: 250 OK
> C: start-netconf
> S: 350 228 greeting follows
> <greeting>
> ...
> C: 278
> <greeting>
> ...
> 
> (where 228 and 278 are byte counts)
> 
> What this gets you is integrated authentication and out of the byte
> counting
> business.  You might even be able to steel the byte count code from
> either SMTP
> CHUNKING or IMAP (although IMAP is a bit weird).
> 

-- 
Tomoyuki Iijima
Hitachi, Ltd., Central Research Laboratory
1-280, Higashi-koigakubo Kokubunji-shi,
Tokyo 185-8601, Japan
Tel:+81-42-323-1111 ext.3579
Fax:+81-42-327-7868
E-mail:tomoyuki.iijima.fg@hitachi.com


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>