Subject: [Netconf] NETCONF over TLS: username

From: Badra <[email-masked]>
Date: Fri, 14 Oct 2011 20:26:45 +0200

Dear all,

Alan Luchuk and I had prepared the following text to map a certificate to a
NETCONF username.

Moreover, if needed, we will add text on PSK authentication (see last
section)

Please don't hesitate to send your comments

Best regards
Badra

1) Generating NETCONF Usernames From NETCONF Client Certificates

The NETCONF protocol [RFC6241] requires the transport protocol is

responsible for authentication of the server to the client and

authentication of the client to the server.  TLS does this by

exchanging and verifying the certficates presented by the peer.

Additionally, the NETCONF protocol [RFC6241] requires the

transport protocol's authentication process MUST result in an

authenticated client identity whose permissions are known to the

server.  The authenticated identity of a client is commonly

referred to as the NETCONF username.  Thus, an algorithm for

mapping certificates to NETCONF usernames is required.

The algorithm for mapping certificates to NETCONF usernames is

patterned after the algorithm for mapping certificates to

tmSecurityNames specified in Transport Layer Security (TLS)

Transport Model for the Simple Network Management Protocol (SNMP)

[RFC6353].  RFC6353 specifies that an SNMP agent must implement

several algorithms for mapping a certificate to a tmSecurityName,

and lets the agent deployer choose and configure the algorithm

most suitable for the deployer's environment.

The NETCONF server may map a certificate to a NETCONF username

using any of the following algorithms:

-  Map a certificate directly to a NETCONF username;

-  Extract the subjectAltName's rfc822Name from the certificate

  and map this to a NETCONF username;

-  Extract the subjectAltName's dnsName from the certificate

  and map this to a NETCONF username;

-  Extract the subjectAltName's iPAddress from the certificate

  and map this to a NETCONF username;

-  Extract the subjectAltName's rfc822Name, dnsName, and iPAddress

  fields, and map the first matching subjectAltName value.

The NETCONF server should implement all of these algorithms, and

allow the deployer to choose and configure the algorithm used.

How a NETCONF server is configured is implementation dependent.

Although remote configuration might be useful, it is out-of-scope

for this document.

Conceptually, the configuration must include a means of identifying

the certificate presented and the mapping algorithm.  Additionally,

when a certificate is mapped directly to a NETCONF username, the

NETCONF username must be configurable.

2) Identifying a Certificate

A client certificate has an identity: the certificate.  The TLS and

corresponding X.509 protocols provide an identity.  The identity

shows that "this client certificate has shown that it, indeed, is on

the other side of the connection".  With a complete certificate,

the certificate receiver can be certain that for someone or something

on the other side to use that certificate successfully, it has the

associated private key.

The problem with using the entire certificates as the identity is

that it is difficult to use by people and software being configured.

It is generally accepted that a fingerprint of a certificate is not

likely to come up with a collision against a fingerprint of another

(different) certificate.  Thus, assuming a good hash algorithm, using

fingerprints is a safe way to compare two certificates.

How a NETCONF server identifies a certificate is implementation-dependent.

It is suggested that the NETCONF server username configuration use

certificate fingerprints as "likely unique index" into a mapping table.

3) Generating the NETCONF username from the subjectAltName's rfc822Name

Maps a subjectAltName's rfc822Name to a NETCONF username.  The local part

of the rfc822Name is passed unaltered but the host-part of the name must

be passed in lowercase.  This mapping results in a 1:1 correspondence

between equivalent subjectAltName rfc822Name values and NETCONF username

values except that the host-part of the name MUST be passed in lowercase.

Example rfc822Name Field:  [email-masked]

is mapped to NETCONF username: [email-masked]."

4) Generating the NETCONF username from the subjectAltName's dnsName

DESCRIPTION  "Maps a subjectAltName's dNSName to a

                 NETCONF username after first converting it to all

                 lowercase (RFC 5280 does not specify converting to

                 lowercase so this involves an extra step).  This

                 mapping results in a 1:1 correspondence between

                 subjectAltName dNSName values and the NETCONF username

                 values."

The subjectAltName's dNSName is mapped to a NETCONF usernames after

first converting it to all lowercase (RFC 5280 does not specify these

conversions, so this involves an extra step).  This mapping results in

a 1:1 correspondence between subjectAltName dNSName values and the

NETCONF username values.

REFERENCE RFC 5280 - Internet X.509 Public Key Infrastructure

                     Certificate and Certificate Revocation

                     List (CRL) Profile.

5) Generating the NETCONF username from the subjectAltName's ipAddress

The subjectAltName's iPAddress is mapped to a NETCONF username by

transforming the binary encoded address as follows:

a)  for IPv4, the value is converted into a decimal-dotted quad address

   with dots replaced by underscore characters (e.g., '192.0.2.1')

b)  for IPv6 addresses, the value is converted into a 32-character all

   lowercase hexadecimal string without any colon separators.

This mapping results in a 1:1 correspondence between subjectAltName

iPAddress values and the NETCONF username values.

6) Generating the NETCONF username from any of the subjectAltName's

  rfc822Name, dNSName, or iPAddress

Any of the subjectAltName fields rfc822Name, dNSName, or iPAddress are

mapped to the NETCONF username using the corresponding mapping algorithms

described above.

The NETCONF server should allow the deployer to configure the order in

which these subjectAltName fields are examined.  For example, the

NETCONF server should allow the deployer to configure that the

subjectAltName fields be examined in any of following orders:

o  1) rfc822Name,  2) dNSName,     3) iPAddress

o  1) rfc822Name,  2) iPAddress,   3) dNSName

o  1) dNSName,     2) iPAddress,   3) rfc822Name

o  1) dNSName,     2) rfc822Name,  3) iPAddress

o  1) iPAddress,   2) iPAddress,   3) rfc822Name

o  1) iPAddress,   2) rfc822Name,  3) iPAddress

When the certificate's ssubjectAltName fields are examined in the

deployer-specified order, the first matching subjectAltName value

found MUST be used when deriving the NETCONF username.  The mapping

algorithm specified in the previous sections MUST be used to derive

the NETCONF username.

This mapping results in a 1:1 correspondence between subjectAltName

values and NETCONF username values.  The three sub-mapping algorithms

produced by this combined algorithm cannot produce conflicting results

between themselves.

7) Selecting NETCONF Server Certificates From NETCONF Usernames

When a NETCONF server must send a notification, the NETCONF server

acts in a client role.  When acting in a client role, the NETCONF

server must also have a mechanism for transforming a NETCONF Username

into a TLS certificate.

The NETCONF server should map a NETCONF username directly to a

certificate.  The NETCONF server should allow the deployer to

configure the mapping.  How this is configured in a NETCONF server

implementation dependent.  Although remote configuration might be

useful, it is out-of-scope for this document.

8) Generating the NETCONF username from any of the PSK Identity

RFC 4279 describes pre-shared key cipher suites for TLS to support

authentication based on pre-shared keys (PSKs).

During the TLS Handshake, the client indicates which key to use by

including a "PSK identity" in the TLS ClientKeyExchange message

[RFC4279].

The PSK identity MUST be first converted to a character string, and

then encoded to octets using UTF-8 [UTF8]. For instance, RFC4279

specifies encoding for three PSK identity types:

 o  IPv4 addresses are sent as dotted-decimal strings (e.g.,

"192.0.2.1"), not as 32-bit integers in network byte order.

 o  Domain names are sent in their usual text form [DNS] (e.g.,

"www.example.com" or "embedded\.dot.example.net"), not in DNS

protocol format.

 o  X.500 Distinguished Names are sent in their string representation

[LDAPDN], not as BER-encoded ASN.1.

The algorithm for mapping PSK identities to NETCONF usernames is

trivial. It consists of extracting the PSK identity from the received

ClientKeyExchange message and maps this to a NETCONF username.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 14 Oct 2011 12:24:29 -0700

Hi -

A few comments...

> From: "Badra" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, October 14, 2011 11:26 AM
> Subject: [Netconf] NETCONF over TLS: username
...
> The NETCONF protocol [RFC6241] requires the transport protocol is

s/is/to be/
 
> Additionally, the NETCONF protocol [RFC6241] requires the

s/requires/requires that/
 
> mapping certificates to NETCONF usernames is required.

s/required/needed/
 
> [RFC6353].  RFC6353 specifies that an SNMP agent must implement

s/agent/engine/

> and lets the agent deployer choose and configure the algorithm

s/agent/SNMP engine/

>   fields, and map the first matching subjectAltName value.

Just what is meant by "map" here?

> allow the deployer to choose and configure the algorithm used.

Is this a RFC 2119 SHOULD?  If it is, I think from an interoperability
perspective it would really need to be a MUST.

Is it permitted for the server to employ multiple algorithms, using one
or more fall-back algorithms if the first one tried fails?
 
> Although remote configuration might be useful, it is out-of-scope

This is too ironic for words.
 
> NETCONF username must be configurable.

I'm afraid I'm unable to make sense of this last sentence.  Do you mean
that the *mapping* needs to be configurable?

> that it is difficult to use by people and software being configured.

s/it is/they are/ 
s/to use by people/for people to use/
s/and software being configured//

> certificate fingerprints as "likely unique index" into a mapping table.

This seems like an internal implementation detail that would be
inappropriate in a specification. 

> values except that the host-part of the name MUST be passed in lowercase.

Any interaction with IDNs?
 
>    with dots replaced by underscore characters (e.g., '192.0.2.1')

Uh, the example doesn't match the description here.   Did you mean
"192_0_2_1"?

> algorithm specified in the previous sections MUST be used to derive

Does the deployer have the option of prohibiting a particular mapping /
field from being used?

> useful, it is out-of-scope for this document.

:-) 

> ClientKeyExchange message and maps this to a NETCONF username.
...

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Oct 2011 22:46:13 +0200

> [LDAPDN], not as BER-encoded ASN.1.

This text seems to be copied from RFC 4279. I think we should instead
simply refer to section 5.1. of RFC 4279 for the encoding of the PSK
identity. Having MUSTs spelled out in multiple places causes document
update pain.

/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/>

---

From: "t.petch" <[email-masked]>
Date: Thu, 20 Oct 2011 14:58:29 +0200

It does seem to me that we are trying to fit some square pegs into a round hole
(just as we did with isms).

Meanwhile, sidr has a need to issue all routers (that originate paths) with
certificates and is specifying just that, expecting all RIR, LIR, ISP - most, if
not all, significant networks - to become Certificate Authorities and to issue
suitable End-Entity certificates to routers and others.  These certificates will
be suitable for routers, with fields to identify them and their properties.

Do I see a faint parallel with netconf (or snmp or any operational protocol)?
This protocol, like others,  is primarily for use with an administrative domain,
not world-wide, so a certificate, be it for client or for server, needs to
uniquely identify the end point within the domain, so an employee number,
perhaps employee name, a box name or box serial number, coupled with the
identifier of the administrative domain, perhaps implicit in the Certificate
Authority, provides a suitable identifer.  (Well, if not, blame the Certificate
Authority, they chose it:-).  All we need is a profile to specify that.

It seems to me we have the tools to solve the problem but just are not using
them.

The profile for router certificates is in
               A Profile for BGPSEC Router Certificates,
        Certificate Revocation Lists, and Certification Requests
                draft-turner-sidr-bgpsec-pki-profiles-02
which sidr just failed to adopt as a WG document, but that was purely a
procedural error; the chair has her whip out:-)

Tom Petch