Re: NETCONF over TLS
Tomoyuki Iijima <tomoyuki.iijima.fg@hitachi.com> Thu, 21 June 2007 00:06 UTC
Return-path: <owner-netconf@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ACD-00022z-P3 for netconf-archive@lists.ietf.org; Wed, 20 Jun 2007 20:06:45 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ACD-00006F-Ag for netconf-archive@lists.ietf.org; Wed, 20 Jun 2007 20:06:45 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from <owner-netconf@ops.ietf.org>) id 1I1A4W-0009zg-TT for netconf-data@psg.com; Wed, 20 Jun 2007 23:58:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.1.8
Received: from [133.145.228.42] (helo=mail7.hitachi.co.jp) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from <tomoyuki.iijima.fg@hitachi.com>) id 1I1A4L-0009yf-Cl for netconf@ops.ietf.org; Wed, 20 Jun 2007 23:58:43 +0000
Received: from mlsv16.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id B924737ACE for <netconf@ops.ietf.org>; Thu, 21 Jun 2007 08:58:36 +0900 (JST)
Received: from mfilter-s5.hitachi.co.jp by mlsv16.hitachi.co.jp (8.13.1/8.13.1) id l5KNwaeu029681; Thu, 21 Jun 2007 08:58:36 +0900
Received: from vshuts1.hitachi.co.jp (unverified) by mfilter-s5.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with SMTP id <T8059e9ebb10ac906b555c@mfilter-s5.hitachi.co.jp> for <netconf@ops.ietf.org>; Thu, 21 Jun 2007 08:58:36 +0900
Received: from gmml28.itg.hitachi.co.jp ([158.213.165.131]) by vshuts1.hitachi.co.jp with SMTP id M2007062108583521356 for <netconf@ops.ietf.org>; Thu, 21 Jun 2007 08:58:35 +0900
Received: from [127.0.0.1] by gmml28.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id l5KNwal876720; Thu, 21 Jun 2007 08:58:36 +0900
Message-ID: <4679BEF9.6080904@hitachi.com>
Date: Thu, 21 Jun 2007 08:57:45 +0900
From: Tomoyuki Iijima <tomoyuki.iijima.fg@hitachi.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Subject: Re: NETCONF over TLS
References: Your message of "Tue, 19 Jun 2007 13:50:46 +0200." <4677C316.3080707@cisco.com> <200706191441.l5JEfwjw065141@idle.juniper.net> <05dd01c7b285$33665f10$0600a8c0@china.huawei.com> <4677F796.6070507@cisco.com> <05e501c7b28d$18f4d5a0$0600a8c0@china.huawei.com> <4678D6D7.8020400@cisco.com>
In-Reply-To: <4678D6D7.8020400@cisco.com>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
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/>
- NETCONF over TLS badra
- NETCONF over TLS Andy Bierman
- Re: NETCONF over TLS Phil Shafer
- Re: NETCONF over TLS Juergen Schoenwaelder
- Re: NETCONF over TLS badra
- Re: Re: NETCONF over TLS Phil Shafer
- Re: NETCONF over TLS Andy Bierman
- RE: NETCONF over TLS Romascanu, Dan (Dan)
- Re: NETCONF over TLS Eliot Lear
- Re: NETCONF over TLS Martin Bjorklund
- Re: NETCONF over TLS Juergen Schoenwaelder
- Re: NETCONF over TLS Eliot Lear
- Re: �NETCONF�over�TLS badra
- Re: NETCONF over TLS badra
- Re: NETCONF over TLS Eliot Lear
- RE: ??NETCONF?over?TLS Ma Yuzhi
- Re: NETCONF over TLS Mohamad Badra
- Re: NETCONF over TLS Simon Leinen
- Re: NETCONF over TLS Mohamad Badra
- Re: NETCONF over TLS Martin Bjorklund
- Re: NETCONF over TLS Eliot Lear
- Re: NETCONF over TLS Phil Shafer
- Re: NETCONF over TLS Mohamad Badra
- Re: NETCONF over TLS Mohamad Badra
- Re: NETCONF over TLS Eliot Lear
- Re: NETCONF over TLS Andy Bierman
- Re: NETCONF over TLS Phil Shafer
- Re: NETCONF over TLS Andy Bierman
- Re: NETCONF over TLS Phil Shafer
- Re: NETCONF over TLS Andy Bierman
- Re: NETCONF over TLS Andy Bierman
- Re: NETCONF over TLS badra
- RE: NETCONF over TLS David B Harrington
- Re: NETCONF over TLS Andy Bierman
- Re: NETCONF over TLS Balazs Lengyel
- Re: NETCONF over TLS Balazs Lengyel
- RE: NETCONF over TLS Romascanu, Dan (Dan)
- Re: NETCONF over TLS Mohamad Badra
- Re: NETCONF over TLS Mohamad Badra
- Re: NETCONF over TLS Eliot Lear
- Re: NETCONF over TLS Phil Shafer
- Call for volunteer authors (was Re: NETCONF over … Andy Bierman
- Re: NETCONF over TLS tom.petch
- Re: NETCONF over TLS Simon Leinen
- RE: NETCONF over TLS David B Harrington
- Re: NETCONF over TLS Eliot Lear
- RE: NETCONF over TLS David B Harrington
- Re: NETCONF over TLS Andy Bierman
- Re: NETCONF over TLS Eliot Lear
- Re: NETCONF over TLS Tomoyuki Iijima