Subject: Re: [Netconf] handling invalid XML tag name

From: Wes Hardaker <[email-masked]>
Date: Mon, 08 Dec 2008 08:15:32 -0800

>>>>> On Sat, 29 Nov 2008 07:25:46 -0800, Andy Bierman <[email-masked]> said:

AB> We have attributes in the <rpc> element so we
AB> need a CLR that says "]]>]]>" is not allowed
AB> to appear anywhere inside a NETCONF PDU.

It'd be a nasty security bug if the EOM marker could be inserted as
valid text inside XML.  If indeed the XML directorate was wrong at the
time that advice was given, you definitely need that CLR.  Otherwise you
risk the possibility of non-privileged users providing the system with
text that includes that marker followed by a complete edit-config
command and another proper marker.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 08 Dec 2008 08:15:32 -0800

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Dec 2008 17:22:09 +0100

> command and another proper marker.

I do not think we can ban "]]>]]>" from ever appearing in NETCONF
messages, especially if we talk about user provided data.

So we need to fix the protocol specifications and the relevant
security considerations by making it clear that implementors must not
fall into the trap of treating "]]>]]>" inside of messages as an EOM
marker. This implies that the EOM marker looses most of its value
since I need to parse the message to find its end but at the end this
is better than pretending "]]>]]>" never appears in valid NETCONF
messages.

/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, 8 Dec 2008 17:22:09 +0100

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Dec 2008 08:53:21 -0800

> command and another proper marker.

yep.

This would be a non-compatible change.
It requires a new RFC and 4741 changed to Historic.
Recall that the reason we put this in 4741 was
that it was deemed to be unreasonable to parse XML
to do the framing.  All it takes is 1 bad element
and framing is lost.  Requiring an agent to parse
through all processing instructions, comments, etc.
and 'guess' where the 'good' XML starts again is too
difficult.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Dec 2008 08:53:21 -0800

yep.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Dec 2008 09:07:51 -0800

> command and another proper marker.

Actually it depends on the implementation, if this is even a
problem or not.  Since the framing is done on the SSH byte stream,
none of the per-NETCONF-PDU security checks have likely been started yet.
In my code, embedding PDUs in an attribute might result in
bad-msg1, good-msg2, bad-msg3.  The 'good-msg2' would have to
go through all of the security checks it would have faced
if it was the entire message.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Dec 2008 09:07:51 -0800

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Dec 2008 19:09:59 +0100 (CET)

> messages, especially if we talk about user provided data.

We talk about attributes (and comments).  The sequence is not allowed
in text data in elements.

Maybe we can say that implementations must quote it and send

  <foo x="]]&gt;]]&gt;"/>

instead of

  <foo x="]]>]]>"/>

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Dec 2008 19:09:59 +0100 (CET)

<foo x="]]&gt;]]&gt;"/>

instead of

  <foo x="]]>]]>"/>

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Dec 2008 19:28:37 +0100

> It requires a new RFC and 4741 changed to Historic.

The framing sequence ]]>]]> is a property of NETCONF over SSH and so
RFC 4742 is concerned, not RFC 4741.

> and 'guess' where the 'good' XML starts again is too

I believe when RFC 4742 was designed, people thought they can get away
with an non-event-driven XML parser, but it now appears that the EOM
sequence is not as good as we believed back then.

And yes, not well-formed XML kills you and the only sensible reaction
is IMHO to close the session. And this not different with other
encodings; if you send multiple BER encoded PDUs over a stream based
connection (e.g. SNMP over TCP or SSH), you face the same problem when
you hit a parsing error. Since XML is so much easier than BER, hitting
non well-formed XML documents should be rare in practice. ;-)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Dec 2008 19:28:37 +0100

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Dec 2008 19:38:25 +0100

> if it was the entire message.

It can imagine a situation where a NETCONF client is trusted and has
credentials installed on the server to do certaiFrom [email-masked]  Mon Dec  8 10:38:40 2008
Date: Mon, 8 Dec 2008 19:38:25 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Andy Bierman <[email-masked]>
Mail-Followup-To: Andy Bierman <[email-masked]>,
	Wes Hardaker <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] handling invalid XML tag name
Reply-To: [email-masked]
Sender: [email-masked]

> if it was the entire message.

It can imagine a situation where a NETCONF client is trusted and has
credentials installed on the server to do n useful things. If
now someone manages to send carefully crafted input to this client
resulting in bad-msg1, good-msg2, bad-msg3, then the good-msg2 might
be executed with rights it should not receive. Sure, you can argue
that the server is not to blame since the client did allow something
to slip through it should not have allowed. But then there is also
some evidence from the Web that this sort of stuff causes security
problems and the question is whether we want to be proactive or
whether we are willing to wait for a CERT advisory.

/js

certain useful things. If
now someone manages to send carefully crafted input to this client
resulting in bad-msg1, good-msg2, bad-msg3, then the good-msg2 might
be executed with rights it should not receive. Sure, you can argue
that the server is not to blame since the client did allow something
to slip through it should not have allowed. But then there is also
some evidence from the Web that this sort of stuff causes security
problems and the question is whether we want to be proactive or
whether we are willing to wait for a CERT advisory.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Dec 2008 10:42:37 -0800

> Maybe we can say that implementations must quote it and send

I was going to point this out.
The '>' char cannot appear at all within a text() node.
It has to be written as a character entity.

I don't think this is a big deal.  Should we
worry about comment nodes?

The client implementation that generated the EOM sequence
inside an attribute value is broken, right?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Dec 2008 10:42:37 -0800

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Dec 2008 10:48:26 -0800

Juergen Schoenwaelder wrote:
> credentials installed on the server to do certain useful things. If

There is certainly a Trojan horse vulnerability on the client side.
If the access control (oh, that again!) is really loose on the
agent, then an application may be hijacked to invoke RPCs
that the agent will allow.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Dec 2008 10:48:26 -0800

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 08 Dec 2008 20:21:54 +0100

> I was going to point this out.

For example xmllint indeed replaces ']]>' with ']]&gt;' in attribute
values.

> It has to be written as a character entity.

Not true. XML 1.0 spec: The right angle bracket (>) may be represented
using the string "&gt;", and MUST, for compatibility, be escaped using
either "&gt;" or a character reference when it appears in the string
"]]>" in content, when that string is not marking the end of a CDATA
section.

Left angle bracket '<' must not appear as literal.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 08 Dec 2008 20:21:54 +0100

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Tue, 09 Dec 2008 09:21:25 +0100

TGFkaXNsYXYgTGhvdGthIHdyb3RlOgo+IEFuZHkgQmllcm1hbiBww63FoWUgdiBQbyAwOC4gMTIuIDIwMDggdiAxMDo0MiAtMDgwMDoKPiAKPj4+IE1heWJlIHdlIGNhbiBzYXkgdGhhdCBpbXBsZW1lbnRhdGlvbnMgbXVzdCBxdW90ZSBpdCBhbmQgc2VuZAo+Pj4KPj4+ICAgPGZvbyB4PSJdXSZndDtdXSZndDsiLz4KPj4+Cj4+PiBpbnN0ZWFkIG9mCj4+Pgo+Pj4gICA8Zm9vIHg9Il1dPl1dPiIvPgo+Pj4KPj4gSSB3YXMgZ29pbmcgdG8gcG9pbnQgdGhpcyBvdXQuCj4gCj4gRm9yIGV4YW1wbGUgeG1sbGludCBpbmRlZWQgcmVwbGFjZXMgJ11dPicgd2l0aCAnXV0mZ3Q7JyBpbiBhdHRyaWJ1dGUKPiB2YWx1ZXMuCj4gCj4+IFRoZSAnPicgY2hhciBjYW5ub3QgYXBwZWFyIGF0IGFsbCB3aXRoaW4gYSB0ZXh0KCkgbm9kZS4KPj4gSXQgaGFzIHRvIGJlIHdyaXR0ZW4gYXMgYSBjaGFyYWN0ZXIgZW50aXR5Lgo+IAo+IE5vdCB0cnVlLiBYTUwgMS4wIHNwZWM6IFRoZSByaWdodCBhbmdsZSBicmFja2V0ICg+KSBtYXkgYmUgcmVwcmVzZW50ZWQKPiB1c2luZyB0aGUgc3RyaW5nICImZ3Q7IiwgYW5kIE1VU1QsIGZvciBjb21wYXRpYmlsaXR5LCBiZSBlc2NhcGVkIHVzaW5nCj4gZWl0aGVyICImZ3Q7IiBvciBhIGNoYXJhY3RlciByZWZlcmVuY2Ugd2hlbiBpdCBhcHBlYXJzIGluIHRoZSBzdHJpbmcKPiAiXV0+IiBpbiBjb250ZW50LCFrom [email-masked]  Tue Dec  9 00:24:24 2008Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from [127.0.0.1] (localhost [127.0.0.1])	by core3.amsl.com (Postfix) with ESMTP id 9A79B28C114;	Tue,  9 Dec 2008 00:24:24 -0800 (PST)X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1])	by core3.amsl.com (Postfix) with ESMTP id E0CBC28C114	for <[email-masked]>; Tue,  9 Dec 2008 00:24:23 -0800 (PST)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: 0.49X-Spam-Level: X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[AWL=0.004,	BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95]Received: from mail.ietf.org ([64.170.98.32])	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id 4FE0RCY4nabG for <[email-masked]>;	Tue,  9 Dec 2008 00:24:23 -0800 (PST)Received: from ormo.s3group.com.pl (ormo.s3group.com.pl [212.160.116.194])	by core3.amsl.com (Postfix) with ESMTP id CE45628C10C	for <[email-masked]>; Tue,  9 Dec 2008 00:24:22 -0800 (PST)Received: from exwro.wroclaw.ad.s3group.com (exwro.wroclaw.s3group.com	[192.168.88.33])	by ormo.s3group.com.pl  with ESMTP id mB98NVtQ030151;	Tue, 9 Dec 2008 09:23:33 +0100Received: from [0.0.0.0] ([192.168.88.91]) by exwro.wroclaw.ad.s3group.com	with Microsoft SMTPSVC(6.0.3790.1830); 	Tue, 9 Dec 2008 09:23:30 +0100Message-ID: <[email-masked]>Date: Tue, 09 Dec 2008 09:21:25 +0100From: Tomasz Mikolajczyk <[email-masked]>User-Agent: Thunderbird 2.0.0.18 (X11/20081112)MIME-Version: 1.0To: Ladislav Lhotka <[email-masked]>References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<1228764114.6318.27.camel@missotis>In-Reply-To: <1228764114.6318.27.camel@missotis>X-OriginalArrivalTime: 09 Dec 2008 08:23:30.0952 (UTC)	FILETIME=[6B487080:01C959D7]X-Scanner: InterScan AntiVirus for SendmailX-Filter-Version: 1.11,S3-1.6 (ormo.s3group.com.pl)X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0	(ormo.s3group.com.pl [212.160.116.194]);	Tue, 09 Dec 2008 09:23:35 +0100 (CET)Cc: [email-masked]: Re: [Netconf] handling invalid XML tag nameX-BeenThere: [email-masked]: 2.1.9Precedence: listList-Id: Network Configuration WG mailing list <netconf.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>,	<mailto:[email-masked]?subject=unsubscribe>List-Archive: <https://www.ietf.org/mailman/private/netconf>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>,	<mailto:[email-masked]?subject=subscribe>Content-Type: text/plain; charset="utf-8"Content-Transfer-Encoding: base64Sender: [email-masked]: [email-masked]+IEFuZHkgQmllcm1hbiBww63FoWUgdiBQbyAwOC4gMTIuIDIwMDggdiAxMDo0MiAtMDgwMDoKPiAKPj4+IE1heWJlIHdlIGNhbiBzYXkgdGhhdCBpbXBsZW1lbnRhdGlvbnMgbXVzdCBxdW90ZSBpdCBhbmQgc2VuZAo+Pj4KPj4+ICAgPGZvbyB4PSJdXSZndDtdXSZndDsiLz4KPj4+Cj4+PiBpbnN0ZWFkIG9mCj4+Pgo+Pj4gICA8Zm9vIHg9Il1dPl1dPiIvPgo+Pj4KPj4gSSB3YXMgZ29pbmcgdG8gcG9pbnQgdGhpcyBvdXQuCj4gCj4gRm9yIGV4YW1wbGUgeG1sbGludCBpbmRlZWQgcmVwbGFjZXMgJ11dPicgd2l0aCAnXV0mZ3Q7JyBpbiBhdHRyaWJ1dGUKPiB2YWx1ZXMuCj4gCj4+IFRoZSAnPicgY2hhciBjYW5ub3QgYXBwZWFyIGF0IGFsbCB3aXRoaW4gYSB0ZXh0KCkgbm9kZS4KPj4gSXQgaGFzIHRvIGJlIHdyaXR0ZW4gYXMgYSBjaGFyYWN0ZXIgZW50aXR5Lgo+IAo+IE5vdCB0cnVlLiBYTUwgMS4wIHNwZWM6IFRoZSByaWdodCBhbmdsZSBicmFja2V0ICg+KSBtYXkgYmUgcmVwcmVzZW50ZWQKPiB1c2luZyB0aGUgc3RyaW5nICImZ3Q7IiwgYW5kIE1VU1QsIGZvciBjb21wYXRpYmlsaXR5LCBiZSBlc2NhcGVkIHVzaW5nCj4gZWl0aGVyICImZ3Q7IiBvciBhIGNoYXJhY3RlciByZWZlcmVuY2Ugd2hlbiBpdCBhcHBlYXJzIGluIHRoZSBzdHJpbmcKPiAiXV0+IiBpbiBjb250B3aGVuIHRoYXQgc3RyaW5nIGlzIG5vdCBtYXJraW5nIHRoZSBlbmQgb2YgYSBDREFUQQo+IHNlY3Rpb24uCgpTbyBpZiBzb21lb25lIG5lZWQgIl1dPl1dPiIgbWFya3MgaW4gYW4gYXR0cmlidXRlLCBwYXNzaW5nIHRoZW0gYXMgIl1dJmd0O11dJmd0OyIgb3IgIl1dJiM2MjtdXSYjNjI7IiBpcyBmdWxseSBzdWZmaWNpZW50LgoKVG9tYXN6Cgo+IExlZnQgYW5nbGUgYnJhY2tldCAnPCcgbXVzdCBub3QgYXBwZWFyIGFzIGxpdGVyYWwuCj4gCj4gTGFkYQo+IAo+PiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYSBiaWcgZGVhbC4gIFNob3VsZCB3ZQo+PiB3b3JyeSBhYm91dCBjb21tZW50IG5vZGVzPwo+Pgo+PiBUaGUgY2xpZW50IGltcGxlbWVudGF0aW9uIHRoYXQgZ2VuZXJhdGVkIHRoZSBFT00gc2VxdWVuY2UKPj4gaW5zaWRlIGFuIGF0dHJpYnV0ZSB2YWx1ZSBpcyBicm9rZW4sIHJpZ2h0Pwo+Pgo+Pj4gL21hcnRpbgo+Pgo+PiBBbmR5Cj4+CgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBhbmQgaW4gYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgaXMgZGVzaWduYXRlZCBzb2xlbHkgZm9yIHRoZSBhdHRlbnRpb24gb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgbXVzdCBub3QgdXNlLCBkaXNjbG9zZSwgY29weSwgZGlzdHJpYnV0ZSBvciByZXRhaW4gdGhpcyBlLW1haWwgb3IgYW55IHBhcnQgdGhlcmVvZi4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIGUtbWFpbCBmcm9tIHlvdXIgY29tcHV0ZXIgc3lzdGVtKHMpLgpQbGVhc2UgZGlyZWN0IGFueSBhZGRpdGlvbmFsIHF1ZXJpZXMgdG86IGNvbW11bmljYXRpb25zQHMzZ3JvdXAuY29tLgpUaGFuayBZb3UuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk5ldGNvbmYgbWFpbGluZyBsaXN0Ck5ldGNvbmZAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mCg==ZW50LCB3aGVuIHRoYXQgc3RyaW5nIGlzIG5vdCBtYXJraW5nIHRoZSBlbmQgb2YgYSBDREFUQQo+IHNlY3Rpb24uCgpTbyBpZiBzb21lb25lIG5lZWQgIl1dPl1dPiIgbWFya3MgaW4gYW4gYXR0cmlidXRlLCBwYXNzaW5nIHRoZW0gYXMgIl1dJmd0O11dJmd0OyIgb3IgIl1dJiM2MjtdXSYjNjI7IiBpcyBmdWxseSBzdWZmaWNpZW50LgoKVG9tYXN6Cgo+IExlZnQgYW5nbGUgYnJhY2tldCAnPCcgbXVzdCBub3QgYXBwZWFyIGFzIGxpdGVyYWwuCj4gCj4gTGFkYQo+IAo+PiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYSBiaWcgZGVhbC4gIFNob3VsZCB3ZQo+PiB3b3JyeSBhYm91dCBjb21tZW50IG5vZGVzPwo+Pgo+PiBUaGUgY2xpZW50IGltcGxlbWVudGF0aW9uIHRoYXQgZ2VuZXJhdGVkIHRoZSBFT00gc2VxdWVuY2UKPj4gaW5zaWRlIGFuIGF0dHJpYnV0ZSB2YWx1ZSBpcyBicm9rZW4sIHJpZ2h0Pwo+Pgo+Pj4gL21hcnRpbgo+Pgo+PiBBbmR5Cj4+CgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBhbmQgaW4gYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgaXMgZGVzaWduYXRlZCBzb2xlbHkgZm9yIHRoZSBhdHRlbnRpb24gb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgbXVzdCBub3QgdXNlLCBkaXNjbG9zZSwgY29weSwgZGlzdHJpYnV0ZSBvciByZXRhaW4gdGhpcyBlLW1haWwgb3IgYW55IHBhcnQgdGhlcmVvZi4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIGUtbWFpbCBmcm9tIHlvdXIgY29tcHV0ZXIgc3lzdGVtKHMpLgpQbGVhc2UgZGlyZWN0IGFueSBhZGRpdGlvbmFsIHF1ZXJpZXMgdG86IGNvbW11bmljYXRpb25zQHMzZ3JvdXAuY29tLgpUaGFuayBZb3UuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk5ldGNvbmYgbWFpbGluZyBsaXN0Ck5ldGNvbmZAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mCg==

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 10 Dec 2008 08:55:21 -0800

>>>>> On Mon, 8 Dec 2008 19:28:37 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> Since XML is so much easier than BER, hitting non well-formed XML
JS> documents should be rare in practice. ;-)

The general rule is: you must do the eval if you're the one acting on
the message.  IE, don't trust the client to have properly escaped ]]>]]>
for you; don't trust the other side's implementation when it comes to
security (and you're right: we see this all the time with web-browser
vulnerabilities)

non-well-formed XML documents are not necessarily going to be rare in
practice.  If we're designing netconf to be easily script-able (which was
an early goal) then we have to expect bad scripts to be written by
operators in a hurry who fail to consider where the input to the script
is coming from.

  echo "What is your name?"
  set a=$<
  echo "<create-ppp-user>$i</create-ppp-user>" | netconf-client

or worse:

  echo "<create-ppp-user>$i</create-ppp-user>" | raw-ssh-client host:netconfport

They're obviously not checking if the user had put

  ]]>]]><edit-config><somethingnasty/></edit-config>

as their user name.  The only choice from a security perspective is to
drop the connection when the first mesFrom [email-masked]  Wed Dec 10 08:55:30 2008
From: Wes Hardaker <[email-masked]>
To: Andy Bierman <[email-masked]>
Organization: Sparta
Date: Wed, 10 Dec 2008 08:55:21 -0800
Cc: [email-masked]
Subject: Re: [Netconf] handling invalid XML tag name
Sender: [email-masked]

>>>>> On Mon, 8 Dec 2008 19:28:37 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> Since XML is so much easier than BER, hitting non well-formed XML
JS> documents should be rare in practice. ;-)

The general rule is: you must do the eval if you're the one acting on
the message.  IE, don't trust the client to have properly escaped ]]>]]>
for you; don't trust the other side's implementation when it comes to
security (and you're right: we see this all the time with web-browser
vulnerabilities)

non-well-formed XML documents are not necessarily going to be rare in
practice.  If we're designing netconf to be easily script-able (which was
an early goal) then we have to expect bad scripts to be written by
operators in a hurry who fail to consider where the input to the script
is coming from.

  echo "What is your name?"
  set a=$<
  echo "<create-ppp-user>$i</create-ppp-user>" | netconf-client

or worse:

  echo "<create-ppp-user>$i</create-ppp-user>" | raw-ssh-client host:netconfport

They're obviously not checking if the user had put

  ]]>]]><edit-config><somethingnasty/></edit-config>

as their user name.  The only choice from a security perspective is to
drop the connection when the firsage (the <create-ppp-user> rpc)
fails to be fully parsed.

Back then, we took the word of the xml-directorate that ]]>]]> couldn't
exist in a legal XML document.  Turns out that may be suspect even for
legal documents and worse it doesn't matter if you can't control the
legality of what's coming in anyway.  SSH doesn't do framing and trying
to force in a framing mechanism into the data-stream was the likely
mistake.

st message (the <create-ppp-user> rpc)
fails to be fully parsed.

Back then, we took the word of the xml-directorate that ]]>]]> couldn't
exist in a legal XML document.  Turns out that may be suspect even for
legal documents and worse it doesn't matter if you can't control the
legality of what's coming in anyway.  SSH doesn't do framing and trying
to force in a framing mechanism into the data-stream was the likely
mistake.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Dec 2008 09:24:22 -0800

>   ]]>]]><edit-config><somethingnasty/></edit-config>

I don't know who 'they' are, but the NETCONF protocol is designed
a little better than that, and implementations can take advantage.
When a session starts, it must go through a state machine that
begins with the <hello> exchange.  The agent will not accept
anything but <hello> and it doesn't go well, the connection
will be dropped right away.

Before the <hello>, everything is handled by the 'master' SSH agent
(openssh), which would not do anything except barf if it got
an <edit-config> embedded in the username.  Only the 'netconf'
subsystem has access to the config databases.  Avoiding the
netconf subsystem with raw SSH will not help.

After the session is established, each EOM seen at the SSH channel
layer input stream will cause a message to be sent to the dispatcher,
which will go through all the security checks that are
supported by the agent.  I do not see how the EOM marker can cause
an agent to invoke an RPC as if it were a different one.  It can
certainly disrupt the session, but that's just garbage-in, garbage-out.

> drop the connection when the first message (the <create-ppp-user> rpc)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Dec 2008 09:24:22 -0800

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Dec 2008 23:07:25 +0100

On Wed, Dec 10, 2008 at 09:24:22AM -0800, Andy Bierman wrote:

> an agent to invoke an RPC as if it were a different one.

We seem to agree that the EOM marker may be used to ship an "unwanted"
RPC call through a naive client imFrom [email-masked]  Wed Dec 10 14:07:41 2008
Date: Wed, 10 Dec 2008 23:07:25 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Andy Bierman <[email-masked]>
Mail-Followup-To: Andy Bierman <[email-masked]>,
	Wes Hardaker <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] handling invalid XML tag name
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Dec 10, 2008 at 09:24:22AM -0800, Andy Bierman wrote:

> an agent to invoke an RPC as if it were a different one.

We seem to agree that the EOM marker may be used to ship an "unwanted"
RPC call through a naive cliplementation. If this is paired with
a loose access control configuration where the server trusts a certain
client, the problem is real.

You seem to take the position that (a) there should not be access
control rules that allow more access than absolutely necessary and (b)
there should not be clients that pass user input unfiltered to a
NETCONF server. While I agree with (a) and (b) in theory, there
happens to be evidence that in real world installations often violate
(a) and (b).  [And I like to add that there is no common way to do (a)
yet - so it is unclear how strict access control actually can be.]

I believe the usefulness of the EOM marker needs to be revisited now
that we have some implementation experience. If the WG after having
implementation experience reaches the some conclusion that the
benefits are worth to keep the EOM marker, then I think there needs to
be security considerations text discussing the implications of having
clients not controlling EOM markers contained in the messages they
generate and it might spell out implementation guidelines to protect
against misuse via creative EOM markers.

/js

ent implementation. If this is paired with
a loose access control configuration where the server trusts a certain
client, the problem is real.

You seem to take the position that (a) there should not be access
control rules that allow more access than absolutely necessary and (b)
there should not be clients that pass user input unfiltered to a
NETCONF server. While I agree with (a) and (b) in theory, there
happens to be evidence that in real world installations often violate
(a) and (b).  [And I like to add that there is no common way to do (a)
yet - so it is unclear how strict access control actually can be.]

I believe the usefulness of the EOM marker needs to be revisited now
that we have some implementation experience. If the WG after having
implementation experience reaches the some conclusion that the
benefits are worth to keep the EOM marker, then I think there needs to
be security considerations text discussing the implications of having
clients not controlling EOM markers contained in the messages they
generate and it might spell out implementation guidelines to protect
against misuse via creative EOM markers.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Dec 2008 14:59:49 -0800

Juergen Schoenwaelder wrote:
> RPC call through a naive client implementation. If this is paired with

I think all aspects of NETCONF 1.0 interoperability and security
should be open to discussion for NETCONF 1.1.  I pushed for an
access control model several times but the NETCONF community
is happy with proprietary ACMs for now, so other work is being
done instead.

I guess it would be prudent for an agent to drop the session
if it gets any bad XML at all.  Not very Postel-like though.
It should be configurable on the agent (operation-failed or
drop-session).

Why doesn't NETCONF have standard configurable security, like SNMP?
I thought SNMP was the 'read-only' protocol.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Dec 2008 14:59:49 -0800

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 10 Dec 2008 16:06:02 -0800

>>>>> On Wed, 10 Dec 2008 09:24:22 -0800, Andy Bierman <[email-masked]> said:

AB> I don't know who 'they' are, but the NETCONF protocol is designed
AB> a little better than that, and implementations can take advantage.

Andy,

Sorry for my brevity.  I sliced a finger open the other day and didn't
want to type a full-length message out because my typing speed is a bit
reduced.  I thought you'd pick up on what I was trying to get across
(Juergen did I'm pretty sure at least) but I failed.

netconf is designed to be scripted such that messages need not
necessarily be passed through a netconf-aware application.  IE, openssh
(which you referenced) may be an end-tool through which a script passes
data to a netconf server without requiring a specialized program like
"snmpset" and similar tools exist for SNMP.  I've already seen real code
written that does not invoke a "smart" netconf client but constructs
hopefully-valid XML on the fly from the "script" to pass to a server.

My example didn't include <hello> and capability exchanges, you're
right.  It was a terse example.  It also didn't include namespaces and
other necessary "stuff".

Picture a ISP's operators having quickly hacked together a web-sign-up
sheet for offering a new account to their system.  They fail to
implement decent security checks against the "preferred" user name or
email address (sorry, but this is actually more common than you'd like).
The take the entered data from the user and later use it to populate a
netconf message sent to a netconf agent on the router for adding a new
account name that should be granted access through the PPP modem pool.

So, if a bad-dude enters a user-name in the web form that includes
]]>]]> followed by a syntactically valid edit-config and the operator's
script sends it to the router as part of the update then currently the
user's edit-config gets executed.  Because the SSH transport uses the
]]>]]> as a valid framing marker and allows the transport to take the
first part of the message stream (the invalid update to the users table
that gets truncated by the ]]>]]>), toss it aside as invalid and then
keep trying to execute further data (the trailing <edit-config> inserted
by the bad-dude).

Now, I know "the operator gets what he deserves" for writing such a bad
script.  But as we know, performing all the right "checks" rarely gets
done perfectly.  Simply put, I don't by the assumption that 100% of all
netconf clients are always going to properly check their input for
]]>]]> markers and properly escape them.  Maybe they do get what they
deserve.  Maybe we should require smarter operators.  But one of the
early goals of netconf was to make things easier so they didn't have to
understand as much of the nitty-gritty protocol details like BER and
other nasty encoding rules.

AB> After the session is established, each EOM seen at the SSH channel
AB> layer input stream will cause a message to be sent to the dispatcher,
AB> which will go through all the security checks that are
AB> supported by the agent.

Yep.  And malicious users may be able to insert EOM markers in the
middle of their form-data to add additional commands to the stream.
This is exactly what sql injection attacks do and they work because not
everyone carefully checks input like they should.  Yes, the operators
writing the code get what they deserve for sql injection attacks too.
But wouldn't it be better if the operators didn't have to worry about
it?

Unfortunately, it's too late and I don't know what could be done other
than to say if you are parsing a stream and get bad data you should drop
the connection rather than discard the message and keep reading from
the stream.  That's the only path forward that makes the most sense.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 10 Dec 2008 16:06:02 -0800

Andy,

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Dec 2008 07:02:19 -0800

> (Juergen did I'm pretty sure at least) but I failed.

So the solution is to drop the session if any bad XML is received?
The dumb script inserting user data without checking it cannot 'undo'
the <rpc> already seen by the agent, so truncating it will
prevent the 'bad PDU' from being executed.  OK, but...

Why can't the attacker just figure out exactly where the
data is getting inserted and figure out how to close
off the XML properly?  Then issue the bad PDU,
aFrom [email-masked]  Thu Dec 11 07:02:32 2008
Date: Thu, 11 Dec 2008 07:02:19 -0800
From: Andy Bierman <[email-masked]>
To: Wes Hardaker <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] handling invalid XML tag name
Sender: [email-masked]

> (Juergen did I'm pretty sure at least) but I failed.

So the solution is to drop the session if any bad XML is received?
The dumb script inserting user data without checking it cannot 'undo'
the <rpc> already seen by the agent, so truncating it will
prevent the 'bad PDU' from being executed.  OK, but...

Why can't the attacker just figure out exactly where the
data is getting inserted and figure out how to close
off the XML properly?  Then issue the bad PDU,
and whend when the truncated end of the real PDU is detected,
it is already too late (or insert a <close-session>
after the <edit-config> to keep the operator a little
more in the dark.)

It doesn't seem like the SSH EOM marker is relevant to this attack.

It seems like only a real (properly configured) ACM is going to help.

Andy

n the truncated end of the real PDU is detected,
it is already too late (or insert a <close-session>
after the <edit-config> to keep the operator a little
more in the dark.)

It doesn't seem like the SSH EOM marker is relevant to this attack.

It seems like only a real (properly configured) ACM is going to help.

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 11 Dec 2008 16:40:56 -0800

>>>>> On Thu, 11 Dec 2008 07:02:19 -0800, Andy Bierman <[email-masked]> said:

AB> Why can't the attacker just figure out exactly where the
AB> data is getting inserted and figure out how to close
AB> off the XML properly?

That's possible too, but a lot harder.  It requires knowledge of the
entire XML stream sent to the agent before the insertion point.  It's
doable, but takes a *lot* more effort as opposed to almost none for
inserting an EOM and hoping it's not checked.

Ask yourself how you would figure out how to close an existing session
properly.  Your choices are guessing a lot at all the open tags in
use (possibly including unknown name space prefixes) or sniffing the
wire (which fortunately we've made pretty hard).  Can it be done?  Yes.
Easily?  No.  It'll take many attempts to likely get it right.  An EOM
marker, on the other hand, looks like it'll succeed the first time.

AB> It seems like only a real (properly configured) ACM is going to
AB> help.

An ACM will only help if the web-based application is very limited in
what ACM rights it has.  We know this is smarFrom [email-masked]  Thu Dec 11 16:41:04 2008
From: Wes Hardaker <[email-masked]>
To: Andy Bierman <[email-masked]>
Organization: Sparta
Date: Thu, 11 Dec 2008 16:40:56 -0800
Cc: [email-masked]
Subject: Re: [Netconf] handling invalid XML tag name
Sender: [email-masked]

>>>>> On Thu, 11 Dec 2008 07:02:19 -0800, Andy Bierman <[email-masked]> said:

AB> Why can't the attacker just figure out exactly where the
AB> data is getting inserted and figure out how to close
AB> off the XML properly?

That's possible too, but a lot harder.  It requires knowledge of the
entire XML stream sent to the agent before the insertion point.  It's
doable, but takes a *lot* more effort as opposed to almost none for
inserting an EOM and hoping it's not checked.

Ask yourself how you would figure out how to close an existing session
properly.  Your choices are guessing a lot at all the open tags in
use (possibly including unknown name space prefixes) or sniffing the
wire (which fortunately we've made pretty hard).  Can it be done?  Yes.
Easily?  No.  It'll take many attempts to likely get it right.  An EOM
marker, on the other hand, looks like it'll succeed the first time.

AB> It seems like only a real (properly configured) ACM is going to
AB> help.

An ACM will only help if the web-based application is very limited in
what ACM rights it has.  We know this it.  However we know from
experience that not enough people put decent ACM systems in place too
(financial institutions and large companies do a better job than
mom-and-pop ISPs).

s smart.  However we know from
experience that not enough people put decent ACM systems in place too
(financial institutions and large companies do a better job than
mom-and-pop ISPs).

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Dec 2008 17:09:14 -0800

> marker, on the other hand, looks like it'll succeed the first time.

The only top-level element of interest is <rpc>,
so no need to guess that.  The injected PDU is going to
have to be in an attribute in that start tag.
It is easy to finish off the <rpc> start tag,
then put in whatever PDU you want.  It is also
easy to begin another <rpc> start tag when your done,
so the next attribute (after the bad one) will
simply continue the RPC message stream.

You do not need to guess at anything, but it is a bit more work.

> what ACM rights it has.  We know this is smart.  However we know from

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Dec 2008 17:09:14 -0800

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Dec 2008 08:35:57 +0100

> have to be in an attribute in that start tag.

Why?

/js

NetcFrom [email-masked]  Thu Dec 11 23:36:13 2008
Date: Fri, 12 Dec 2008 08:35:57 +0100

> have to be in an attribute in that start tag.

Why?

/js

Netconf mailing [email-masked]

t
[email-masked]

---

From: Jan Lindblad <[email-masked]>
Date: Fri, 12 Dec 2008 10:47:39 +0100

>> have to be in an attribute in that start tag.

The hard lesson learned by the "SQL injection" crisis is that a client  
that doesn't properly and completely check it's input, effectively  
transfers any trust/authority it may have to whoever is capable of  
providing such input. This is a fact of life, and has very little to  
do with start tags or ]]>]]> EOM markers.

Just as a simple example, consider an application that prompts for a  
name and inserts it in its XML stream:

"""
<edit-config>
    <users>
        <user>
            <name>%s</name>
            <privileges>almost-nothing</privileges>
        </user>
    </users>
<edit-config>
"""

And someone responds with:
"cool-hacker</name><privileges>top-secret</privileges></ 
user><user><name>someone-else"

The good news is that it's very easy to fix this. Simply by removing  
(or XML escaping) all > characters in the user input (plus quotes if  
it inserts text in attributes), the application is safe.

> inserting an EOM and hoping it's not checked.

This appeals to the security-by-obscurity principle. It was (mostly)  
abandoned ca 1973.

/Jan Lindblad
--
Jan Lindblad, [email-masked], +46 702855728
Tail-f Systems, Professional Services, www.tail-f.com

---

From: Jan Lindblad <[email-masked]>
Date: Fri, 12 Dec 2008 10:47:39 +0100

"""
<edit-config>
    <users>
        <user>
            <name>%s</name>

/Jan Lindblad

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Dec 2008 06:50:05 -0800

>> have to be in an attribute in that start tag.

There is the 'official' attribute hole in <rpc>, making it more likely.
But an implementation could be filling leafs blindly too, so this
could show up anywhere in the PDU.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Dec 2008 06:50:05 -0800

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Dec 2008 07:30:44 -0800

Jan Lindblad wrote:
> providing such input. This is a fact of life, and has very little to do 
> with start tags or ]]>]]> EOM markers.
> 
> "cool-hacker</name><privileges>top-secret</privileges></user><user><name>someone-else"
> 
> The good news is that it's very easy to fix this. Simply by removing (or 
> XML escaping) all > characters in the user input (plus quotes if it 
> inserts text in attributes), the application is safe.
> 

great example...

Isn't part of the responsibility on the manager?

In your example, almost no ACM or agent mechanism is really going
to help.  If the user correctly establishes a session,
and has write access to the /users/user node, then injecting
an extra entry is going to be accepted.

(The super-fine VACM mode "let user X set leaf Y to value Z" is
way too hard to really be useful.)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Dec 2008 07:30:44 -0800

great example...

Andy

---

From: Jan Lindblad <[email-masked]>
Date: Fri, 12 Dec 2008 23:31:14 +0100

>> The hard lesson learned by the "SQL injection" crisis is that a  
>> client that doesn't properly and completely check it's input,  
>> effectively transfers any trust/authority it may have to whoever is  
>> capable of providing such input. This is a fact of life, and has  
>> very little to do with start tags or ]]>]]> EOM markers.
>> Just as a simple example, consider an application that prompts for  
>> a name and inserts it in its XML stream:
>> """
>> <edit-config>
>>   <users>
>>       <user>
>>           <name>%s</name>
>> The good news is that it's very easy to fix this. Simply by  
>> removing (or XML escaping) all > characters in the user input (plus  
>> quotes if it inserts text in attributes), the application is safe.
>> This appeals to the security-by-obscurity principle. It was  
>> (mostly) abandoned ca 1973.
>
> great example...
>

I don't think so. The server will not be able to tell whether the  
above request is a legitimate creation of two users or a result of a  
naïve client being tricked.

Look at a decade's worth of experience in the SQL injection defense.  
It's all happening on the client side. There are basically two defense  
mechanisms:
- All user provided data is sent out-of-band, or
- All user provided data is cleaned from "control characters" or  
control characters are escaped.

Doing something out-of-band on an SSH session seems complicated, but  
with XML, cleaning is easy. Basically removing (or escaping) any  
occurrences of > (in CDATA) and quotes (in attributes) will make it  
impossible for a malicious user to modify the XML document structure.

> way too hard to really be useful.)

And even if ACM rules like this could be expressed, it wouldn't help  
when the client really has the authority to create users with top- 
secret privileges. The server could not distinguish between a sane and  
tricked client.

/Jan Lindblad

---

From: Jan Lindblad <[email-masked]>
Date: Fri, 12 Dec 2008 23:31:14 +0100

/Jan Lindblad

---

From: Andy Bierman <[email-masked]>
Date: Sat, 13 Dec 2008 09:01:52 -0800

U2ltb24gTGVpbmVuIHdyb3RlOgo+IEphbiBMaW5kYmxhZCB3cml0ZXM6Cj4+IFtxdW90aW5nIEFuZHldCj4+PiBbcXVvdGluZyBKYW5dCj4+Pj4gQW5kIHNvbWVvbmUgcmVzcG9uZHMgd2l0aDoKPj4+PiAiY29vbC1oYWNrZXI8L25hbWU+PHByaXZpbGVnZXM+dG9wLXNlY3JldDwvcHJpdmlsZWdlcz48Lwo+IHVzZXI+IDx1c2VyPjxuYW1lPnNvbWVvbmUtZWxzZSIKPj4+PiBUaGUgZ29vZCBuZXdzIGlzIHRoYXQgaXQncyB2ZXJ5IGVhc3kgdG8gZml4IHRoaXMuIFsuLi5dCj4gCj4+PiBncmVhdCBleGFtcGxlLi4uCj4+Pgo+Pj4gSXNuJ3QgcGFydCBvZiB0aGUgcmVzcG9uc2liaWxpdHkgb24gdGhlIG1hbmFnZXI/Cj4gCj4+IEkgZG9uJ3QgdGhpbmsgc28uIFRoZSBzZXJ2ZXIgd2lsbCBub3QgYmUgYWJsZSB0byB0ZWxsIHdoZXRoZXIgdGhlCj4+IGFib3ZlIHJlcXVlc3QgaXMgYSBsZWdpdGltYXRlIGNyZWF0aW9uIG9mIHR3byB1c2VycyBvciBhIHJlc3VsdCBvZiBhCj4+IG5hw692ZSBjbGllbnQgYmVpbmcgdHJpY2tlZC4KPiAKPiBJIHRoaW5rIHRoYXQgdGhlICJtYW5hZ2VyIiBBbmR5IGlzIHRhbGtpbmcgYWJvdFrom [email-masked]  Sat Dec 13 09:02:04 2008Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from [127.0.0.1] (localhost [127.0.0.1])	by core3.amsl.com (Postfix) with ESMTP id C13EB3A6866;	Sat, 13 Dec 2008 09:02:04 -0800 (PST)X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1])	by core3.amsl.com (Postfix) with ESMTP id ACBB23A6866	for <[email-masked]>; Sat, 13 Dec 2008 09:02:03 -0800 (PST)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -2.222X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.043, 	BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]Received: from mail.ietf.org ([64.170.98.32])	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id XvUXUjaQ2C+E for <[email-masked]>;	Sat, 13 Dec 2008 09:02:02 -0800 (PST)Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com	[69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id D6DFE3A684F	for <[email-masked]>; Sat, 13 Dec 2008 09:02:02 -0800 (PST)Received: (qmail 71196 invoked from network); 13 Dec 2008 17:01:56 -0000Received: from unknown (HELO ?127.0.0.1?) ([email-masked] with plain)	by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 13 Dec 2008 17:01:54 -0000X-YMail-OSG: MYlQBa0VM1kKD6nvIJ.S4o4L_4BtoEMatbEwOKun7WPJ4cob2Kq10SVkPyomdlIkNbI7pvev9t86qXLv6h38xuSpwR61skccNGtuAHj6MWk8pSQVtuNI2dtzmQ5YQnI8pTW0isFfGSPNUHRiNJV6RTyFX-Yahoo-Newman-Property: ymail-3Message-ID: <[email-masked]>Date: Sat, 13 Dec 2008 09:01:52 -0800From: Andy Bierman <[email-masked]>User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)MIME-Version: 1.0To: Simon Leinen <[email-masked]>References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>In-Reply-To: <[email-masked]>Cc: [email-masked]: [Netconf] security-tagging (was: Re: handling invalid XML tag name)X-BeenThere: [email-masked]: 2.1.9Precedence: listList-Id: Network Configuration WG mailing list <netconf.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>,	<mailto:[email-masked]?subject=unsubscribe>List-Archive: <https://www.ietf.org/mailman/private/netconf>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>,	<mailto:[email-masked]?subject=subscribe>Content-Transfer-Encoding: base64Content-Type: text/plain; charset="utf-8"; Format="flowed"Sender: [email-masked]: [email-masked]+IEphbiBMaW5kYmxhZCB3cml0ZXM6Cj4+IFtxdW90aW5nIEFuZHldCj4+PiBbcXVvdGluZyBKYW5dCj4+Pj4gQW5kIHNvbWVvbmUgcmVzcG9uZHMgd2l0aDoKPj4+PiAiY29vbC1oYWNrZXI8L25hbWU+PHByaXZpbGVnZXM+dG9wLXNlY3JldDwvcHJpdmlsZWdlcz48Lwo+IHVzZXI+IDx1c2VyPjxuYW1lPnNvbWVvbmUtZWxzZSIKPj4+PiBUaGUgZ29vZCBuZXdzIGlzIHRoYXQgaXQncyB2ZXJ5IGVhc3kgdG8gZml4IHRoaXMuIFsuLi5dCj4gCj4+PiBncmVhdCBleGFtcGxlLi4uCj4+Pgo+Pj4gSXNuJ3QgcGFydCBvZiB0aGUgcmVzcG9uc2liaWxpdHkgb24gdGhlIG1hbmFnZXI/Cj4gCj4+IEkgZG9uJ3QgdGhpbmsgc28uIFRoZSBzZXJ2ZXIgd2lsbCBub3QgYmUgYWJsZSB0byB0ZWxsIHdoZXRoZXIgdGhlCj4+IGFib3ZlIHJlcXVlc3QgaXMgYSBsZWdpdGltYXRlIGNyZWF0aW9uIG9mIHR3byB1c2VycyBvciBhIHJlc3VsdCBvZiBhCj4+IG5hw692ZSBjbGllbnQgYmVpbmcgdHJpY2tlZC4KPiAKPiBJIHRoaW5rIHRoYXQgdGhlICJtYW5hZ2VyIiBBbmR5IGlzIHRhbGtpbmcXQgaXMgdGhlIHBpZWNlIG9mCj4gc29mdHdhcmUgZ2VuZXJhdGluZyBORVRDT05GIHJlcXVlc3RzIGZyb20gdXNlciBpbnB1dCwgdGhlIHNhbWUgdGhpbmcKPiB0aGF0IHlvdSBjYWxsIHRoZSAiY2xpZW50IiAKPiAKPiBTbyB0aGUgdHdvIG9mIHlvdSBzZWVtIHRvIGJlIGluIHZpb2xlbnQgYWdyZWVtZW50Lgo+IAo+IEZvciB0aGUgcmVjb3JkLCBJIGFncmVlIHRoYXQgdGhpcyBwcm9ibGVtIG11c3QgYmUgc29sdmVkIGJ5IGVkdWNhdGluZwo+IHByb2dyYW1tZXJzIG9uIHRoZSBORVRDT05GIGNsaWVudCAobWFuYWdlcikgc2lkZSB0byBzYW5pdGl6ZSB1c2VyCj4gaW5wdXQsIGFuZCB0byBwcm92aWRlIHRoZW0gd2l0aCB0aGUgYXBwcm9wcmlhdGUgdG9vbHMgLSB2aXouIG1vZGVybgo+IGRldmVsb3BtZW50IHRvb2xraXRzIHN1Y2ggYXMgUmFpbHMgbWFraW5nIGl0IGluY3JlYXNpbmdseSBkaWZmaWN1bHQgdG8KPiB3cml0ZSBwcm9ncmFtcyB2dWxuZXJhYmxlIHRvIFNRTCBpbmplY3Rpb24gYW5kIHNpbWlsYXIgYXR0YWNrcy4KPiAKPiBXZSBzaG91bGRuJ3QgdHJ5IHRvIHNvbHZlIHRoaXMgYnkgbWFraW5nIHRoZSBwcm90b2NvbCBtb3JlIGNvbXBsZXgsIG9yCj4gYnkgZGVwZW5kaW5nIG9uIGEgZmluZS1ncmFpbmVkIGF1dGhvcml6YXRpb24gc2NoZW1lIG5vYm9keSB3aWxsIHVzZQo+IChBbmR5IGFscmVhZHkgbWVudGlvbmVkIHRoZSBTTk1QIFZBQ00pLgoKSXMgdGhlcmUgYW55dGhpbmcgdGhhdCBjYW4gYmUgZG9uZSBpbiBZQU5HPwoKSSBoYXZlIGJlZW4gdGhpbmtpbmcgb2YgYWRkaW5nICdzZWN1cml0eS10YWdnaW5nJyB0byBteSB0b29sc2V0LgpJIGFtIG5vdCBzdXJlIGhvdyBvcGVyYXRvcnMgbGlrZSB0byBjbGFzc2lmeSB0aGlzIHNvcnQgb2YgcmlzaywKc28gSSBqdXN0IGhhdmUgaGlnaGVyIG51bWJlcnMgYXJlIG1vcmUgb2YgYSB0aHJlYXQ6CgpFLmcuLCBmb3IgdGhlIGN1cnJlbnQgZXhhbXBsZToKCiAgICBjb250YWluZXIgdXNlcnMgewogICAgICAgbmN4OnNlY3VyaXR5LWxldmVsIDI7CgogICAgICAgbGlzdCB1c2VyIHsKICAgICAgICAgIGtleSBuYW1lOwoKICAgICAgICAgIGxlYWYgbmFtZSB7CiAgICAgICAgICAgICB0eXBlIHN0cmluZzsKICAgICAgICAgIH0KCiAgICAgICAgICBlbnVtZXJhdGlvbiBwcml2aWxlZ2VzIHsKICAgICAgICAgICAgIG5jeDpzZWN1cml0eS1sZXZlbCAgMzsKICAgICAgICAgICAgIGVudW0gYWxtb3N0LW5vdGhpbmc7CiAgICAgICAgICAgICBlbnVtIGEtbGl0dGxlLW1vcmUgewogICAgICAgICAgICAgICAgbmN4OnNlY3VyaXR5LWxldmVsIDQ7CiAgICAgICAgICAgICB9CiAgICAgICAgICAgICBlbnVtIGEtd2hvbGUtbG90IHsKICAgICAgICAgICAgICAgIG5jeDpzZWN1cml0eS1sZXZlbCA1OwogICAgICAgICAgICAgfQogICAgICAgICAgfQogICAgICAgfQogICAgfQoKClRoZSBpZGVhIGlzIHRvIG1vdmUgYXMgbXVjaCB3b3JrIGZyb20gdGhlIGh1bWFuIHRvIHRoZSBhdXRvbWF0ZWQgdG9vbHMsCmJ5IGFubm90YXRpbmcgdGhlIFlBTkcgZmlsZSB3aXRoIHRoZXNlIHNvcnQgb2YgZXh0ZW5zaW9ucy4KSW4gdGhpcyBleGFtcGxlLCBBQ00gY291bGQgYmUgYXV0b21hdGljYWxseSBjb25maWd1cmVkIG9uIHRoZQphZ2VudC4gIFVzZXIgd2FybmluZ3MgYW5kIGV2ZW4gc29tZSBzZWN1cml0eSBjb3VsZCBiZSBlbmZvcmNlZApvbiB0aGUgY2xpZW50LgoKVGhlIEFDTSBjb25maWd1cmF0aW9uIGNvdWxkIGJlIGFzIHNpbXBsZSBhcyAibGV0IHVzZXIgWApoYXZlIHNlY3VyaXR5LWxldmVsIDMgYWNjZXNzIi4KCk5vdyB0aGUgcHJvYmxlbSBzaGlmdHMgdG8gdGhlIGRhdGEgbW9kZWwgZGVzaWduZXJzIHRvIHRhZwpjb3JyZWN0bHksIGJ1dCB0aGV5IGFyZSB0aGUgb25lcyB3aG8gbW9zdCB1bmRlcnN0YW5kIHRoZQpzZWN1cml0eSByaXNrcy4gIFNvbWUgb3BlcmF0b3JzIHdpbGwgd2FudCB0byBvdmVycmlkZQp0aGUgZGVmYXVsdCBzZXR0aW5ncywgYnV0IHRoYXQgaXMgdGhlIGV4Y2VwdGlvbi4gIFRoZSBtYWpvcml0eQpkbyBub3Qgd2FudCB0byBmdXNzIHdpdGggZmluZSBncmFudWxhcml0eSBWQUNNIGNvbmZpZ3VyYXRpb24uCgpZQU5HIGlzIHZlcnkgcmljaCBpbiBzZW1hbnRpY3MsIGJ1dCBmcm9tIGEgc2VjdXJpdHkgUE9WCml0IHRyZWF0cyB0aGUga25vYiB0byBjaGFuZ2UgdGhlIGljb24gY29sb3IgdGhlIHNhbWUgYXMKdGhlIGtub2IgdG8gZGVsZXRlIGFsbCBQVkNzIGluIE5vcnRoZXJuIENhbGlmb3JuaWEuCgoKCkFuZHkKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk5ldGNvbmYgbWFpbGluZyBsaXN0Ck5ldGNvbmZAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mCg==gYWJvdXQgaXMgdGhlIHBpZWNlIG9mCj4gc29mdHdhcmUgZ2VuZXJhdGluZyBORVRDT05GIHJlcXVlc3RzIGZyb20gdXNlciBpbnB1dCwgdGhlIHNhbWUgdGhpbmcKPiB0aGF0IHlvdSBjYWxsIHRoZSAiY2xpZW50IiAKPiAKPiBTbyB0aGUgdHdvIG9mIHlvdSBzZWVtIHRvIGJlIGluIHZpb2xlbnQgYWdyZWVtZW50Lgo+IAo+IEZvciB0aGUgcmVjb3JkLCBJIGFncmVlIHRoYXQgdGhpcyBwcm9ibGVtIG11c3QgYmUgc29sdmVkIGJ5IGVkdWNhdGluZwo+IHByb2dyYW1tZXJzIG9uIHRoZSBORVRDT05GIGNsaWVudCAobWFuYWdlcikgc2lkZSB0byBzYW5pdGl6ZSB1c2VyCj4gaW5wdXQsIGFuZCB0byBwcm92aWRlIHRoZW0gd2l0aCB0aGUgYXBwcm9wcmlhdGUgdG9vbHMgLSB2aXouIG1vZGVybgo+IGRldmVsb3BtZW50IHRvb2xraXRzIHN1Y2ggYXMgUmFpbHMgbWFraW5nIGl0IGluY3JlYXNpbmdseSBkaWZmaWN1bHQgdG8KPiB3cml0ZSBwcm9ncmFtcyB2dWxuZXJhYmxlIHRvIFNRTCBpbmplY3Rpb24gYW5kIHNpbWlsYXIgYXR0YWNrcy4KPiAKPiBXZSBzaG91bGRuJ3QgdHJ5IHRvIHNvbHZlIHRoaXMgYnkgbWFraW5nIHRoZSBwcm90b2NvbCBtb3JlIGNvbXBsZXgsIG9yCj4gYnkgZGVwZW5kaW5nIG9uIGEgZmluZS1ncmFpbmVkIGF1dGhvcml6YXRpb24gc2NoZW1lIG5vYm9keSB3aWxsIHVzZQo+IChBbmR5IGFscmVhZHkgbWVudGlvbmVkIHRoZSBTTk1QIFZBQ00pLgoKSXMgdGhlcmUgYW55dGhpbmcgdGhhdCBjYW4gYmUgZG9uZSBpbiBZQU5HPwoKSSBoYXZlIGJlZW4gdGhpbmtpbmcgb2YgYWRkaW5nICdzZWN1cml0eS10YWdnaW5nJyB0byBteSB0b29sc2V0LgpJIGFtIG5vdCBzdXJlIGhvdyBvcGVyYXRvcnMgbGlrZSB0byBjbGFzc2lmeSB0aGlzIHNvcnQgb2YgcmlzaywKc28gSSBqdXN0IGhhdmUgaGlnaGVyIG51bWJlcnMgYXJlIG1vcmUgb2YgYSB0aHJlYXQ6CgpFLmcuLCBmb3IgdGhlIGN1cnJlbnQgZXhhbXBsZToKCiAgICBjb250YWluZXIgdXNlcnMgewogICAgICAgbmN4OnNlY3VyaXR5LWxldmVsIDI7CgogICAgICAgbGlzdCB1c2VyIHsKICAgICAgICAgIGtleSBuYW1lOwoKICAgICAgICAgIGxlYWYgbmFtZSB7CiAgICAgICAgICAgICB0eXBlIHN0cmluZzsKICAgICAgICAgIH0KCiAgICAgICAgICBlbnVtZXJhdGlvbiBwcml2aWxlZ2VzIHsKICAgICAgICAgICAgIG5jeDpzZWN1cml0eS1sZXZlbCAgMzsKICAgICAgICAgICAgIGVudW0gYWxtb3N0LW5vdGhpbmc7CiAgICAgICAgICAgICBlbnVtIGEtbGl0dGxlLW1vcmUgewogICAgICAgICAgICAgICAgbmN4OnNlY3VyaXR5LWxldmVsIDQ7CiAgICAgICAgICAgICB9CiAgICAgICAgICAgICBlbnVtIGEtd2hvbGUtbG90IHsKICAgICAgICAgICAgICAgIG5jeDpzZWN1cml0eS1sZXZlbCA1OwogICAgICAgICAgICAgfQogICAgICAgICAgfQogICAgICAgfQogICAgfQoKClRoZSBpZGVhIGlzIHRvIG1vdmUgYXMgbXVjaCB3b3JrIGZyb20gdGhlIGh1bWFuIHRvIHRoZSBhdXRvbWF0ZWQgdG9vbHMsCmJ5IGFubm90YXRpbmcgdGhlIFlBTkcgZmlsZSB3aXRoIHRoZXNlIHNvcnQgb2YgZXh0ZW5zaW9ucy4KSW4gdGhpcyBleGFtcGxlLCBBQ00gY291bGQgYmUgYXV0b21hdGljYWxseSBjb25maWd1cmVkIG9uIHRoZQphZ2VudC4gIFVzZXIgd2FybmluZ3MgYW5kIGV2ZW4gc29tZSBzZWN1cml0eSBjb3VsZCBiZSBlbmZvcmNlZApvbiB0aGUgY2xpZW50LgoKVGhlIEFDTSBjb25maWd1cmF0aW9uIGNvdWxkIGJlIGFzIHNpbXBsZSBhcyAibGV0IHVzZXIgWApoYXZlIHNlY3VyaXR5LWxldmVsIDMgYWNjZXNzIi4KCk5vdyB0aGUgcHJvYmxlbSBzaGlmdHMgdG8gdGhlIGRhdGEgbW9kZWwgZGVzaWduZXJzIHRvIHRhZwpjb3JyZWN0bHksIGJ1dCB0aGV5IGFyZSB0aGUgb25lcyB3aG8gbW9zdCB1bmRlcnN0YW5kIHRoZQpzZWN1cml0eSByaXNrcy4gIFNvbWUgb3BlcmF0b3JzIHdpbGwgd2FudCB0byBvdmVycmlkZQp0aGUgZGVmYXVsdCBzZXR0aW5ncywgYnV0IHRoYXQgaXMgdGhlIGV4Y2VwdGlvbi4gIFRoZSBtYWpvcml0eQpkbyBub3Qgd2FudCB0byBmdXNzIHdpdGggZmluZSBncmFudWxhcml0eSBWQUNNIGNvbmZpZ3VyYXRpb24uCgpZQU5HIGlzIHZlcnkgcmljaCBpbiBzZW1hbnRpY3MsIGJ1dCBmcm9tIGEgc2VjdXJpdHkgUE9WCml0IHRyZWF0cyB0aGUga25vYiB0byBjaGFuZ2UgdGhlIGljb24gY29sb3IgdGhlIHNhbWUgYXMKdGhlIGtub2IgdG8gZGVsZXRlIGFsbCBQVkNzIGluIE5vcnRoZXJuIENhbGlmb3JuaWEuCgoKCkFuZHkKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk5ldGNvbmYgbWFpbGluZyBsaXN0Ck5ldGNvbmZAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mCg==

---

From: "James Balestriere (jbalestr)" <[email-masked]>
Date: Tue, 16 Dec 2008 07:50:01 +0800

So where did we get to with the ]]>]]>  
Are we still looking to deprecate its usage ?

James.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Leinen
Sent: Sunday, December 14, 2008 12:45 AM
To: Jan Lindblad
Cc: [email-masked]
Subject: Re: [Netconf] handling invalid XML tag name

Jan Lindblad writes:
>[quoting Andy]
>>[quoting Jan]
user> <user><name>someone-else"
>>> The good news is that it's very easy to fix this. [...]

> naïve client being tricked.

I think that the "manager" Andy is talking about is the piece of software generating NETCONF requests from user input, the same thing that you call the "client" 

So the two of you seem to be in violent agreement.

For the record, I agree that this problem must be solved by educating programmers on the NETCONF client (manager) side to sanitize user input, and to provide them with the appropriate tools - viz. modern development toolkits such as Rails making it increasingly difficult to write programs vulnerable to SQL injection and similar attacks.

We shouldn't try to solve this by making the protocol more complex, or by depending on a fine-grained authorization scheme nobody will use (Andy already mentioned the SNMP VACM).
--
Simon.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "James Balestriere (jbalestr)" <[email-masked]>
Date: Tue, 16 Dec 2008 07:50:01 +0800

James.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 15 Dec 2008 17:06:29 -0800

> Are we still looking to deprecate its usage ?

Why are we doing that?
I am opposed to changing the SSH transport.
I do not see any reason to do so.
A note to developers in the 4741-bis about
using caution, generating proper character entities, etc.
should be sufficient.

Andy

> Subject: Re: [Netconf] handling invalid XML tag naFrom [email-masked]  Mon Dec 15 17:06:41 2008
Date: Mon, 15 Dec 2008 17:06:29 -0800
From: Andy Bierman <[email-masked]>
To: "James Balestriere (jbalestr)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] handling invalid XML tag name
Sender: [email-masked]

> Are we still looking to deprecate its usage ?

Why are we doing that?
I am opposed to changing the SSH transport.
I do not see any reason to do so.
A note to developers in the 4741-bis about
using caution, generating proper character entities, etc.
should be sufficient.

Andy

> =me

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 19 Dec 2008 14:53:07 +0100

SGVsbG8sCldlIGhhZCBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IGJ1dCBsb25nIHN0YW5kaW5nIHByb2JsZW0gdGhhdCBjb3VsZCBiZSBzb2x2ZWQgd2l0aCBzZWN1cml0eSB0YWdnaW5nLgoKU29tZSBvcGVyYXRvcnMgd2FudCBldmVyeSBtYW5hZ2VtZW50IG9wZXJhdGlvbiBsb2dnZWQsIGZ1bGx5LiBIb3dldmVyIHdlIGFsc28gaGF2ZSBhbm90aGVyIApyZXF1aXJlbWVudDogc2VjdXJpdHkgZGF0YSwgZS5nLiBwYXNzd29yZHMsIG11c3Qgbm90IGJlIGxvFrom [email-masked]  Fri Dec 19 05:53:25 2008Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from [127.0.0.1] (localhost [127.0.0.1])	by core3.amsl.com (Postfix) with ESMTP id C2BE63A6A24;	Fri, 19 Dec 2008 05:53:25 -0800 (PST)X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1])	by core3.amsl.com (Postfix) with ESMTP id 8C9EA3A6A24	for <[email-masked]>; Fri, 19 Dec 2008 05:53:24 -0800 (PST)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -6.212X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.037, 	BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]Received: from mail.ietf.org ([64.170.98.32])	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id FHP2x1Xz3H-G for <[email-masked]>;	Fri, 19 Dec 2008 05:53:23 -0800 (PST)Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62])	by core3.amsl.com (Postfix) with ESMTP id 54C843A6842	for <[email-masked]>; Fri, 19 Dec 2008 05:53:23 -0800 (PST)Received: from mailgw4.ericsson.se (unknown [127.0.0.1])	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id	875E3221A4; Fri, 19 Dec 2008 14:53:14 +0100 (CET)X-AuditID: c1b4fb3e-adf84bb00000537b-90-494ba74a4e07Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125])	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id	5CA5620304; Fri, 19 Dec 2008 14:53:14 +0100 (CET)Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 	Fri, 19 Dec 2008 14:53:08 +0100Received: from [159.107.197.224] ([159.107.197.224]) by	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 	Fri, 19 Dec 2008 14:53:08 +0100Message-ID: <[email-masked]>Date: Fri, 19 Dec 2008 14:53:07 +0100From: Balazs Lengyel <[email-masked]>User-Agent: Thunderbird 2.0.0.4 (X11/20070604)MIME-Version: 1.0To: Andy Bierman <[email-masked]>References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>In-Reply-To: <[email-masked]>X-OriginalArrivalTime: 19 Dec 2008 13:53:08.0305 (UTC)	FILETIME=[1FA28410:01C961E1]X-Brightmail-Tracker: AAAAAA==Cc: [email-masked]: Re: [Netconf] security-taggingX-BeenThere: [email-masked]: 2.1.9Precedence: listList-Id: Network Configuration WG mailing list <netconf.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>,	<mailto:[email-masked]?subject=unsubscribe>List-Archive: <https://www.ietf.org/mailman/private/netconf>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>,	<mailto:[email-masked]?subject=subscribe>Content-Transfer-Encoding: base64Content-Type: text/plain; charset="utf-8"; Format="flowed"Sender: [email-masked]: [email-masked]IHN0YW5kaW5nIHByb2JsZW0gdGhhdCBjb3VsZCBiZSBzb2x2ZWQgd2l0aCBzZWN1cml0eSB0YWdnaW5nLgoKU29tZSBvcGVyYXRvcnMgd2FudCBldmVyeSBtYW5hZ2VtZW50IG9wZXJhdGlvbiBsb2dnZWQsIGZ1bGx5LiBIb3dldmVyIHdlIGFsc28gaGF2ZSBhbm90aGVyIApyZXF1aXJlbWVudDogc2VjdXJpdHkgZGF0YSwgZS5nLiBwYXNzd29yZHMsIG11c3Qgbm90IGZ2dlZC4gSXQgaXMgb2Z0ZW4gbm90IHRyaXZpYWwgdG8gCmZpZ3VyZSBvdXQgd2hhdCBkYXRhIGlzIHNlbnNpdGl2ZSwgd2hhdCBtdXN0IGJlIHNraXBwZWQgYXQgbG9nZ2luZy4gSWYgc3VjaCBkYXRhIGNvdWxkIGJlIAp0YWdnZWQsIHRoZW4gd2UgY291bGQganVzdCBzYXk6IGlmIGl0IGlzIG92ZXIgc2VjdXJpdHkgbGV2ZWwgNCwgZG9uJ3QgbG9nIGl0LgoKQmFsYXpzCgpBbmR5IEJpZXJtYW4gd3JvdGU6Cj4gU2ltb24gTGVpbmVuIHdyb3RlOgo+PiBKYW4gTGluZGJsYWQgd3JpdGVzOgo+Pj4gW3F1b3RpbmcgQW5keV0KPj4+PiBbcXVvdGluZyBKYW5dCj4+Pj4+IEFuZCBzb21lb25lIHJlc3BvbmRzIHdpdGg6Cj4+Pj4+ICJjb29sLWhhY2tlcjwvbmFtZT48cHJpdmlsZWdlcz50b3Atc2VjcmV0PC9wcml2aWxlZ2VzPjwvCj4+IHVzZXI+IDx1c2VyPjxuYW1lPnNvbWVvbmUtZWxzZSIKPj4+Pj4gVGhlIGdvb2QgbmV3cyBpcyB0aGF0IGl0J3MgdmVyeSBlYXN5IHRvIGZpeCB0aGlzLiBbLi4uXQo+Pgo+Pj4+IGdyZWF0IGV4YW1wbGUuLi4KPj4+Pgo+Pj4+IElzbid0IHBhcnQgb2YgdGhlIHJlc3BvbnNpYmlsaXR5IG9uIHRoZSBtYW5hZ2VyPwo+Pgo+Pj4gSSBkb24ndCB0aGluayBzby4gVGhlIHNlcnZlciB3aWxsIG5vdCBiZSBhYmxlIHRvIHRlbGwgd2hldGhlciB0aGUKPj4+IGFib3ZlIHJlcXVlc3QgaXMgYSBsZWdpdGltYXRlIGNyZWF0aW9uIG9mIHR3byB1c2VycyBvciBhIHJlc3VsdCBvZiBhCj4+PiBuYcOvdmUgY2xpZW50IGJlaW5nIHRyaWNrZWQuCj4+Cj4+IEkgdGhpbmsgdGhhdCB0aGUgIm1hbmFnZXIiIEFuZHkgaXMgdGFsa2luZyBhYm91dCBpcyB0aGUgcGllY2Ugb2YKPj4gc29mdHdhcmUgZ2VuZXJhdGluZyBORVRDT05GIHJlcXVlc3RzIGZyb20gdXNlciBpbnB1dCwgdGhlIHNhbWUgdGhpbmcKPj4gdGhhdCB5b3UgY2FsbCB0aGUgImNsaWVudCIKPj4gU28gdGhlIHR3byBvZiB5b3Ugc2VlbSB0byBiZSBpbiB2aW9sZW50IGFncmVlbWVudC4KPj4KPj4gRm9yIHRoZSByZWNvcmQsIEkgYWdyZWUgdGhhdCB0aGlzIHByb2JsZW0gbXVzdCBiZSBzb2x2ZWQgYnkgZWR1Y2F0aW5nCj4+IHByb2dyYW1tZXJzIG9uIHRoZSBORVRDT05GIGNsaWVudCAobWFuYWdlcikgc2lkZSB0byBzYW5pdGl6ZSB1c2VyCj4+IGlucHV0LCBhbmQgdG8gcHJvdmlkZSB0aGVtIHdpdGggdGhlIGFwcHJvcHJpYXRlIHRvb2xzIC0gdml6LiBtb2Rlcm4KPj4gZGV2ZWxvcG1lbnQgdG9vbGtpdHMgc3VjaCBhcyBSYWlscyBtYWtpbmcgaXQgaW5jcmVhc2luZ2x5IGRpZmZpY3VsdCB0bwo+PiB3cml0ZSBwcm9ncmFtcyB2dWxuZXJhYmxlIHRvIFNRTCBpbmplY3Rpb24gYW5kIHNpbWlsYXIgYXR0YWNrcy4KPj4KPj4gV2Ugc2hvdWxkbid0IHRyeSB0byBzb2x2ZSB0aGlzIGJ5IG1ha2luZyB0aGUgcHJvdG9jb2wgbW9yZSBjb21wbGV4LCBvcgo+PiBieSBkZXBlbmRpbmcgb24gYSBmaW5lLWdyYWluZWQgYXV0aG9yaXphdGlvbiBzY2hlbWUgbm9ib2R5IHdpbGwgdXNlCj4+IChBbmR5IGFscmVhZHkgbWVudGlvbmVkIHRoZSBTTk1QIFZBQ00pLgo+IAo+IElzIHRoZXJlIGFueXRoaW5nIHRoYXQgY2FuIGJlIGRvbmUgaW4gWUFORz8KPiAKPiBJIGhhdmUgYmVlbiB0aGlua2luZyBvZiBhZGRpbmcgJ3NlY3VyaXR5LXRhZ2dpbmcnIHRvIG15IHRvb2xzZXQuCj4gSSBhbSBub3Qgc3VyZSBob3cgb3BlcmF0b3JzIGxpa2UgdG8gY2xhc3NpZnkgdGhpcyBzb3J0IG9mIHJpc2ssCj4gc28gSSBqdXN0IGhhdmUgaGlnaGVyIG51bWJlcnMgYXJlIG1vcmUgb2YgYSB0aHJlYXQ6Cj4gCj4gRS5nLiwgZm9yIHRoZSBjdXJyZW50IGV4YW1wbGU6Cj4gCj4gICAgY29udGFpbmVyIHVzZXJzIHsKPiAgICAgICBuY3g6c2VjdXJpdHktbGV2ZWwgMjsKPiAKPiAgICAgICBsaXN0IHVzZXIgewo+ICAgICAgICAgIGtleSBuYW1lOwo+IAo+ICAgICAgICAgIGxlYWYgbmFtZSB7Cj4gICAgICAgICAgICAgdHlwZSBzdHJpbmc7Cj4gICAgICAgICAgfQo+IAo+ICAgICAgICAgIGVudW1lcmF0aW9uIHByaXZpbGVnZXMgewo+ICAgICAgICAgICAgIG5jeDpzZWN1cml0eS1sZXZlbCAgMzsKPiAgICAgICAgICAgICBlbnVtIGFsbW9zdC1ub3RoaW5nOwo+ICAgICAgICAgICAgIGVudW0gYS1saXR0bGUtbW9yZSB7Cj4gICAgICAgICAgICAgICAgbmN4OnNlY3VyaXR5LWxldmVsIDQ7Cj4gICAgICAgICAgICAgfQo+ICAgICAgICAgICAgIGVudW0gYS13aG9sZS1sb3Qgewo+ICAgICAgICAgICAgICAgIG5jeDpzZWN1cml0eS1sZXZlbCA1Owo+ICAgICAgICAgICAgIH0KPiAgICAgICAgICB9Cj4gICAgICAgfQo+ICAgIH0KPiAKPiAKPiBUaGUgaWRlYSBpcyB0byBtb3ZlIGFzIG11Y2ggd29yayBmcm9tIHRoZSBodW1hbiB0byB0aGUgYXV0b21hdGVkIHRvb2xzLAo+IGJ5IGFubm90YXRpbmcgdGhlIFlBTkcgZmlsZSB3aXRoIHRoZXNlIHNvcnQgb2YgZXh0ZW5zaW9ucy4KPiBJbiB0aGlzIGV4YW1wbGUsIEFDTSBjb3VsZCBiZSBhdXRvbWF0aWNhbGx5IGNvbmZpZ3VyZWQgb24gdGhlCj4gYWdlbnQuICBVc2VyIHdhcm5pbmdzIGFuZCBldmVuIHNvbWUgc2VjdXJpdHkgY291bGQgYmUgZW5mb3JjZWQKPiBvbiB0aGUgY2xpZW50Lgo+IAo+IFRoZSBBQ00gY29uZmlndXJhdGlvbiBjb3VsZCBiZSBhcyBzaW1wbGUgYXMgImxldCB1c2VyIFgKPiBoYXZlIHNlY3VyaXR5LWxldmVsIDMgYWNjZXNzIi4KPiAKPiBOb3cgdGhlIHByb2JsZW0gc2hpZnRzIHRvIHRoZSBkYXRhIG1vZGVsIGRlc2lnbmVycyB0byB0YWcKPiBjb3JyZWN0bHksIGJ1dCB0aGV5IGFyZSB0aGUgb25lcyB3aG8gbW9zdCB1bmRlcnN0YW5kIHRoZQo+IHNlY3VyaXR5IHJpc2tzLiAgU29tZSBvcGVyYXRvcnMgd2lsbCB3YW50IHRvIG92ZXJyaWRlCj4gdGhlIGRlZmF1bHQgc2V0dGluZ3MsIGJ1dCB0aGF0IGlzIHRoZSBleGNlcHRpb24uICBUaGUgbWFqb3JpdHkKPiBkbyBub3Qgd2FudCB0byBmdXNzIHdpdGggZmluZSBncmFudWxhcml0eSBWQUNNIGNvbmZpZ3VyYXRpb24uCj4gCj4gWUFORyBpcyB2ZXJ5IHJpY2ggaW4gc2VtYW50aWNzLCBJlIGxvZ2dlZC4gSXQgaXMgb2Z0ZW4gbm90IHRyaXZpYWwgdG8gCmZpZ3VyZSBvdXQgd2hhdCBkYXRhIGlzIHNlbnNpdGl2ZSwgd2hhdCBtdXN0IGJlIHNraXBwZWQgYXQgbG9nZ2luZy4gSWYgc3VjaCBkYXRhIGNvdWxkIGJlIAp0YWdnZWQsIHRoZW4gd2UgY291bGQganVzdCBzYXk6IGlmIGl0IGlzIG92ZXIgc2VjdXJpdHkgbGV2ZWwgNCwgZG9uJ3QgbG9nIGl0LgoKQmFsYXpzCgpBbmR5IEJpZXJtYW4gd3JvdGU6Cj4gU2ltb24gTGVpbmVuIHdyb3RlOgo+PiBKYW4gTGluZGJsYWQgd3JpdGVzOgo+Pj4gW3F1b3RpbmcgQW5keV0KPj4+PiBbcXVvdGluZyBKYW5dCj4+Pj4+IEFuZCBzb21lb25lIHJlc3BvbmRzIHdpdGg6Cj4+Pj4+ICJjb29sLWhhY2tlcjwvbmFtZT48cHJpdmlsZWdlcz50b3Atc2VjcmV0PC9wcml2aWxlZ2VzPjwvCj4+IHVzZXI+IDx1c2VyPjxuYW1lPnNvbWVvbmUtZWxzZSIKPj4+Pj4gVGhlIGdvb2QgbmV3cyBpcyB0aGF0IGl0J3MgdmVyeSBlYXN5IHRvIGZpeCB0aGlzLiBbLi4uXQo+Pgo+Pj4+IGdyZWF0IGV4YW1wbGUuLi4KPj4+Pgo+Pj4+IElzbid0IHBhcnQgb2YgdGhlIHJlc3BvbnNpYmlsaXR5IG9uIHRoZSBtYW5hZ2VyPwo+Pgo+Pj4gSSBkb24ndCB0aGluayBzby4gVGhlIHNlcnZlciB3aWxsIG5vdCBiZSBhYmxlIHRvIHRlbGwgd2hldGhlciB0aGUKPj4+IGFib3ZlIHJlcXVlc3QgaXMgYSBsZWdpdGltYXRlIGNyZWF0aW9uIG9mIHR3byB1c2VycyBvciBhIHJlc3VsdCBvZiBhCj4+PiBuYcOvdmUgY2xpZW50IGJlaW5nIHRyaWNrZWQuCj4+Cj4+IEkgdGhpbmsgdGhhdCB0aGUgIm1hbmFnZXIiIEFuZHkgaXMgdGFsa2luZyBhYm91dCBpcyB0aGUgcGllY2Ugb2YKPj4gc29mdHdhcmUgZ2VuZXJhdGluZyBORVRDT05GIHJlcXVlc3RzIGZyb20gdXNlciBpbnB1dCwgdGhlIHNhbWUgdGhpbmcKPj4gdGhhdCB5b3UgY2FsbCB0aGUgImNsaWVudCIKPj4gU28gdGhlIHR3byBvZiB5b3Ugc2VlbSB0byBiZSBpbiB2aW9sZW50IGFncmVlbWVudC4KPj4KPj4gRm9yIHRoZSByZWNvcmQsIEkgYWdyZWUgdGhhdCB0aGlzIHByb2JsZW0gbXVzdCBiZSBzb2x2ZWQgYnkgZWR1Y2F0aW5nCj4+IHByb2dyYW1tZXJzIG9uIHRoZSBORVRDT05GIGNsaWVudCAobWFuYWdlcikgc2lkZSB0byBzYW5pdGl6ZSB1c2VyCj4+IGlucHV0LCBhbmQgdG8gcHJvdmlkZSB0aGVtIHdpdGggdGhlIGFwcHJvcHJpYXRlIHRvb2xzIC0gdml6LiBtb2Rlcm4KPj4gZGV2ZWxvcG1lbnQgdG9vbGtpdHMgc3VjaCBhcyBSYWlscyBtYWtpbmcgaXQgaW5jcmVhc2luZ2x5IGRpZmZpY3VsdCB0bwo+PiB3cml0ZSBwcm9ncmFtcyB2dWxuZXJhYmxlIHRvIFNRTCBpbmplY3Rpb24gYW5kIHNpbWlsYXIgYXR0YWNrcy4KPj4KPj4gV2Ugc2hvdWxkbid0IHRyeSB0byBzb2x2ZSB0aGlzIGJ5IG1ha2luZyB0aGUgcHJvdG9jb2wgbW9yZSBjb21wbGV4LCBvcgo+PiBieSBkZXBlbmRpbmcgb24gYSBmaW5lLWdyYWluZWQgYXV0aG9yaXphdGlvbiBzY2hlbWUgbm9ib2R5IHdpbGwgdXNlCj4+IChBbmR5IGFscmVhZHkgbWVudGlvbmVkIHRoZSBTTk1QIFZBQ00pLgo+IAo+IElzIHRoZXJlIGFueXRoaW5nIHRoYXQgY2FuIGJlIGRvbmUgaW4gWUFORz8KPiAKPiBJIGhhdmUgYmVlbiB0aGlua2luZyBvZiBhZGRpbmcgJ3NlY3VyaXR5LXRhZ2dpbmcnIHRvIG15IHRvb2xzZXQuCj4gSSBhbSBub3Qgc3VyZSBob3cgb3BlcmF0b3JzIGxpa2UgdG8gY2xhc3NpZnkgdGhpcyBzb3J0IG9mIHJpc2ssCj4gc28gSSBqdXN0IGhhdmUgaGlnaGVyIG51bWJlcnMgYXJlIG1vcmUgb2YgYSB0aHJlYXQ6Cj4gCj4gRS5nLiwgZm9yIHRoZSBjdXJyZW50IGV4YW1wbGU6Cj4gCj4gICAgY29udGFpbmVyIHVzZXJzIHsKPiAgICAgICBuY3g6c2VjdXJpdHktbGV2ZWwgMjsKPiAKPiAgICAgICBsaXN0IHVzZXIgewo+ICAgICAgICAgIGtleSBuYW1lOwo+IAo+ICAgICAgICAgIGxlYWYgbmFtZSB7Cj4gICAgICAgICAgICAgdHlwZSBzdHJpbmc7Cj4gICAgICAgICAgfQo+IAo+ICAgICAgICAgIGVudW1lcmF0aW9uIHByaXZpbGVnZXMgewo+ICAgICAgICAgICAgIG5jeDpzZWN1cml0eS1sZXZlbCAgMzsKPiAgICAgICAgICAgICBlbnVtIGFsbW9zdC1ub3RoaW5nOwo+ICAgICAgICAgICAgIGVudW0gYS1saXR0bGUtbW9yZSB7Cj4gICAgICAgICAgICAgICAgbmN4OnNlY3VyaXR5LWxldmVsIDQ7Cj4gICAgICAgICAgICAgfQo+ICAgICAgICAgICAgIGVudW0gYS13aG9sZS1sb3Qgewo+ICAgICAgICAgICAgICAgIG5jeDpzZWN1cml0eS1sZXZlbCA1Owo+ICAgICAgICAgICAgIH0KPiAgICAgICAgICB9Cj4gICAgICAgfQo+ICAgIH0KPiAKPiAKPiBUaGUgaWRlYSBpcyB0byBtb3ZlIGFzIG11Y2ggd29yayBmcm9tIHRoZSBodW1hbiB0byB0aGUgYXV0b21hdGVkIHRvb2xzLAo+IGJ5IGFubm90YXRpbmcgdGhlIFlBTkcgZmlsZSB3aXRoIHRoZXNlIHNvcnQgb2YgZXh0ZW5zaW9ucy4KPiBJbiB0aGlzIGV4YW1wbGUsIEFDTSBjb3VsZCBiZSBhdXRvbWF0aWNhbGx5IGNvbmZpZ3VyZWQgb24gdGhlCj4gYWdlbnQuICBVc2VyIHdhcm5pbmdzIGFuZCBldmVuIHNvbWUgc2VjdXJpdHkgY291bGQgYmUgZW5mb3JjZWQKPiBvbiB0aGUgY2xpZW50Lgo+IAo+IFRoZSBBQ00gY29uZmlndXJhdGlvbiBjb3VsZCBiZSBhcyBzaW1wbGUgYXMgImxldCB1c2VyIFgKPiBoYXZlIHNlY3VyaXR5LWxldmVsIDMgYWNjZXNzIi4KPiAKPiBOb3cgdGhlIHByb2JsZW0gc2hpZnRzIHRvIHRoZSBkYXRhIG1vZGVsIGRlc2lnbmVycyB0byB0YWcKPiBjb3JyZWN0bHksIGJ1dCB0aGV5IGFyZSB0aGUgb25lcyB3aG8gbW9zdCB1bmRlcnN0YW5kIHRoZQo+IHNlY3VyaXR5IHJpc2tzLiAgU29tZSBvcGVyYXRvcnMgd2lsbCB3YW50IHRvIG92ZXJyaWRlCj4gdGhlIGRlZmF1bHQgc2V0dGluZ3MsIGJ1dCB0aGF0IGlzIHRoZSBleGNlcHRpb24uICBUaGUgbWFqb3JpdHkKPiBkbyBub3Qgd2FudCB0byBmdXNzIHdpdGggZmluZSBncmFudWxhcml0eSBWQUNNIGNvbmZpZ3VyYXRpb24uCj4gCj4gWUFORyBpcyB2ZXJ5IHJpY2ggaW4gc2VtYW50aidXQgZnJvbSBhIHNlY3VyaXR5IFBPVgo+IGl0IHRyZWF0cyB0aGUga25vYiB0byBjaGFuZ2UgdGhlIGljb24gY29sb3IgdGhlIHNhbWUgYXMKPiB0aGUga25vYiB0byBkZWxldGUgYWxsIFBWQ3MgaW4gTm9ydGhlcm4gQ2FsaWZvcm5pYS4KPiAKPiAKPiAKPiBBbmR5Cj4gCj4gCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBOZXRjb25mIG1haWxpbmcgbGlzdAo+IE5ldGNvbmZAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYKCi0tIApCYWxhenMgTGVuZ3llbCAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuClRTUCBTeXN0ZW0gTWFuYWdlcgpFQ046IDgzMSA3MzIwICAgICAgICAgICAgICAgICAgICAgICAgRmF4OiArMzYgMSA0Mzc3NzkyClRlbDogKzM2LTEtNDM3LTczMjAgICAgIGVtYWlsOiBCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTmV0Y29uZiBtYWlsaW5nIGxpc3QKTmV0Y29uZkBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYKWNzLCBidXQgZnJvbSBhIHNlY3VyaXR5IFBPVgo+IGl0IHRyZWF0cyB0aGUga25vYiB0byBjaGFuZ2UgdGhlIGljb24gY29sb3IgdGhlIHNhbWUgYXMKPiB0aGUga25vYiB0byBkZWxldGUgYWxsIFBWQ3MgaW4gTm9ydGhlcm4gQ2FsaWZvcm5pYS4KPiAKPiAKPiAKPiBBbmR5Cj4gCj4gCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBOZXRjb25mIG1haWxpbmcgbGlzdAo+IE5ldGNvbmZAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYKCi0tIApCYWxhenMgTGVuZ3llbCAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuClRTUCBTeXN0ZW0gTWFuYWdlcgpFQ046IDgzMSA3MzIwICAgICAgICAgICAgICAgICAgICAgICAgRmF4OiArMzYgMSA0Mzc3NzkyClRlbDogKzM2LTEtNDM3LTczMjAgICAgIGVtYWlsOiBCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTmV0Y29uZiBtYWlsaW5nIGxpc3QKTmV0Y29uZkBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYK

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Dec 2008 14:57:06 +0100

On Fri, Dec 19, 2008 at 02:53:07PM +0100, Balazs Lengyel wrote:

> Some operators want every management operation logged, fully. However we 
> also have another requirement: security data, e.g. passwords, must not be 
> logged. It is often not trivial to figure out what data is sensitive, 
> what must be skipped at logging. If such data could be tagged, then we 
> could just say: if it is over security level 4, don't log it.

It is not trivial because the sensitFrom [email-masked]  Fri Dec 19 05:57:25 2008
Date: Fri, 19 Dec 2008 14:57:06 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Balazs Lengyel <[email-masked]>
Mail-Followup-To: Balazs Lengyel <[email-masked]>,
	Andy Bierman <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] security-tagging
Reply-To: [email-masked]
Sender: [email-masked]

On Fri, Dec 19, 2008 at 02:53:07PM +0100, Balazs Lengyel wrote:

> Some operators want every management operation logged, fully. However we 
> also have another requirement: security data, e.g. passwords, must not be 
> logged. It is often not trivial to figure out what data is sensitive, 
> what must be skipped at logging. If such data could be tagged, then we 
> could just say: if it is over security level 4, don't log it.

It is not trivial because the ivity of data to some extend
depends on the deployment and I expect that it will be very difficult
to reach agreement whether something has security level 3 or 4. It
might take WGs an additional year to fight^Hfigure this out. (And when
they are done, it goes to the security directorate. ;-)

/js

sensitivity of data to some extend
depends on the deployment and I expect that it will be very difficult
to reach agreement whether something has security level 3 or 4. It
might take WGs an additional year to fight^Hfigure this out. (And when
they are done, it goes to the security directorate. ;-)

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 19 Dec 2008 15:18:42 +0100

Juergen Schoenwaelder wrote:
> It is not trivial because the sensitivity of data to some extend
But internally in my or other companies, where agreement is easier, it would be a nice 
solution, and much better than what we have today i.e. nothing.
Balazs
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 19 Dec 2008 15:18:42 +0100