[NGO] RE: FW: 10/18 agenda item - NETCONF WG Rechartering

[[e-mail]]

Dear Dan and all,

Following is a tentative, Comments are welcome..

"It should be possible to transport the Netconf protocol using several
different protocols. Netconf relies on the transport protocol for the
mutual authentication. During the authentication stage, the identity check
of the two communicating endpoints MUST be performed by the transport
protocol before any configuration or state data is sent to or received
from each other."

Regarding the document "Netconf over TLS", I will insert the following
text to meet above requirements:

Within TLS, the server authentication is usually by default using a X.509
certificate. During the TLS negotiation, the client MUST carefully examine
the certificate presented by the server to determine if it meets their
expectations. Particularly, the client MUST check its understanding of the
server hostname against the server's identity as presented in the server
Certificate message, in order to prevent man-in-the-middle attacks.
Matching is performed according to these rules in section 5 of RFC4642.
According to RFC3546, a TLS client MAY include an extension of type
"server_name" in the (extended) client hello to tell a server the name of
the server it is contacting.

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.

Best regards,
Badra

>
> Badra,
>
> At this point we need to provide text in the charter to make the security
> AD confident that the requirements for dealing with this issue are clear
> for the Working Group. It is exactly the fact that ISMS and SYSLOG did not
> do too good a job on this respect that seems to worry Sam Hartman. Can you
> make a suggestion on this respect?
>
> Dan
>
>
>
>
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Friday, October 19, 2007 5:13 PM
>> To: Romascanu, Dan (Dan)
>> Cc: Mohamad Badra; �
>> Subject: Re: FW: 10/18 agenda item - NETCONF WG Rechartering
>>
>> Dear Dan and all,
>>
>> I think it is not easy to provide a generic solution. Since
>> TLS left that to the application itself, I wish we have a
>> common text for all network managment protocols* to identify
>> the clients when TLS is used.
>>
>> For the moment, what about remplacing the section 3.2 of
>> NETCONF over TLS with the following text? Please advice...
>>
>>    If a server authenticates a client using certificate, the
>> server MUST
>>    validate the certificate and check the client identity. The general
>>    algorithm described in section 3.1 can be used for the client
>>    certificate validation. The user 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.
>>
>> Best regards,
>> Badra
>>
>> * draft-ietf-syslog-transport-tls-10,
>> draft-marinov-isms-tlstm-00.txt and isms are not clear
>> regarding the client identification.
>>
>>
>> > Badra and all,
>> >
>> > Sam Hartman who is one of the Security Area Directors expressed
>> > concern that the NETCONF over TLS charter proposal does not set the
>> > requirements for user authentication. As these issues proved to be
>> > problematic in syslog and isms, we need more clear requirements in
>> > order to have the NETCONF charter approved including this
>> item. Please propose.
>> >
>> > Dan
>> >
>> >
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Sam Hartman [mailto:[e-mail]]
>> > Sent: Thursday, October 18, 2007 5:31 PM
>> > To: Romascanu, Dan (Dan)
>> > Cc: Internet Engineering Steering Group
>> > Subject: Re: 10/18 agenda item - NETCONF WG Rechartering
>> >
>> >
>> >
>> > Hi.  I am concerned that the TLS charter item is not
>> specific enough
>> > to lead anywhere clear.  In particular, what are the
>> requirements for
>> > user authentication?
>> >
>>
>



_______________________________________________
NGO mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ngo