Subject: FW: I-D ACTION:draft-badra-tls-netconf-04.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 11 Oct 2007 19:49:18 +0200

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 11, 2007 6:15 PM
To: [email-masked]
Subject: I-D ACTION:draft-badra-tls-netconf-04.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: NETCONF over TLS
	Author(s)	: M. Badra
	Filename	: draft-badra-tls-netconf-04.txt
	Pages		: 7
	Date		: 2007-10-11
	
The NETCONF configuration protocol provides mechanisms to install, 
   manipulate, and delete the configuration of network devices. This 
   document describes how to use TLS to secure NETCONF exchanges.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-badra-tls-netconf-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-badra-tls-netconf-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-badra-tls-netconf-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 19 Oct 2007 09:34:58 +0200

Chapter 3.2) Client Id checking must be solved. I think this is a big problem.
Balazs

Romascanu, Dan (Dan) wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> NGO mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ngo

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

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

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 22 Oct 2007 11:40:41 +0200

Dear Balazs and all,

Below a part of text I posted on the NGO mailing list, your comments are 
welcome...

If the server authenticates a client using certificate, the server MUST 
validate the certificate and check the client identity. The general 
algorithm described RFC4642 can be used for the client certificate 
validation. The client identity handled through its certificate MUST be 
verified and authenticated by the server according to local policy 
before any configuration or state data is sent to or received from the 
server.

The client identity could be considered to be the Common Name field in 
the X.509 v3 certificate or any of the fields in the AlternativeName 
extension defined in RFC3280. In this latter case, defined options 
include, among others, an Internet electronic mail address, a DNS name, 
an IP address, MAC, or a uniform resource identifier (URI) (RFC2459 
section 4.2.1.7). Multiple name forms, and multiple instances of each 
name form, may be included.

    Note: The local policy is not addressed in the document.

Best regards,
Badra

Balazs Lengyel a écrit :
>> From: [email-masked] [mailto:[email-masked]] Sent: 
>> Thursday, October 11, 2007 6:15 PM
>> the message. You can also visit 
>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your 
>> subscription settings.
>>
>> logging in, type "cd internet-drafts" and then "get 
>> draft-badra-tls-netconf-04.txt".
>>
>> http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 22 Oct 2007 11:44:54 +0200

I would encourage this discussion to happen on the ngo list, together with the rest of the discussions of the new netconf charter. We want to leave the netconf list focus on discussions about the completion of the current charter until the re-chartering of the WG is approved. 

Dan

> From: Mohamad Badra [mailto:[email-masked]] 
> Sent: Monday, October 22, 2007 11:41 AM
> To: Balazs Lengyel
> Cc: Romascanu, Dan (Dan); Netconf WG
> Subject: Re: [NGO] FW: I-D ACTION:draft-badra-tls-netconf-04.txt
> 
> Dear Balazs and all,
> 
> Below a part of text I posted on the NGO mailing list, your 
> comments are welcome...
> 
> If the server authenticates a client using certificate, the 
> server MUST validate the certificate and check the client 
> identity. The general algorithm described RFC4642 can be used 
> for the client certificate validation. The client identity 
> handled through its certificate MUST be verified and 
> authenticated by the server according to local policy before 
> any configuration or state data is sent to or received from 
> the server.
> 
> The client identity could be considered to be the Common Name 
> field in the X.509 v3 certificate or any of the fields in the 
> AlternativeName extension defined in RFC3280. In this latter 
> case, defined options include, among others, an Internet 
> electronic mail address, a DNS name, an IP address, MAC, or a 
> uniform resource identifier (URI) (RFC2459 section 4.2.1.7). 
> Multiple name forms, and multiple instances of each name 
> form, may be included.
> 
> > Chapter 3.2) Client Id checking must be solved. I think 
> this is a big 
> > problem.
> > Balazs
> > 
> >> [email-masked] with the word unsubscribe in 
> the body 
> >> of the message. You can also visit