Subject: [Netconf] Updating NETCONF over TLS document (RFC5539)

From: Badra <[email-masked]>
Date: Tue, 24 May 2011 15:47:14 +0200

Dear all,

NETCONF over TLS document (RFC5539) update needs to support and fulfill
(additional to the introduction of the Chunked Framing) the requirements
on the username handling defined in 4741bis.

For the Chunked Framing, I will bring the same way being proposed by
NETCONF over SSH document. Since the only authentication mechanism being
defined by RFC5539 is based on certificates, so I would propose the
following (it borrows text from rfc5216):

In NETCONF over TLS, the username is determined from the subject or
subjectAltName fields in the manager's certificates. For details, see
Section 4.1.2.6 of [RFC5280].

Where the subjectAltName field is present in the certificate, the username
MUST be set to the contents of the subjectAltName. If subject naming
information is present only in the subjectAltName extension of certificate,
then the subject field MUST be an empty sequence and the subjectAltName
extension MUST be critical.

Where the username represents a host, a subjectAltName of type dnsName
SHOULD be present in the manager certificate.  Where the username represents

a user and not a resource, a subjectAltName of type rfc822Name SHOULD be
used.
If a dnsName or rfc822Name are not available, other field types (for
example,
a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be
used.

Where it is non-empty, the subject name field MUST contain an X.500
distinguished name (DN).  If subject naming information is present only in
the subject name field of the manager's certificate and the username
represents a host or device, the subject name field SHOULD contain a
CommonName (CN) RDN or serialNumber RDN.  If subject naming information is
present only in the subject name field of the manager's certificate, then
the subject name field SHOULD contain a CN RDN or serialNumber RDN.

It is possible for more than one subjectAltName field to be present in the
manager's certificate in addition to an empty or non-empty subject
distinguished name.  Implementations of this document SHOULD export all the
subjectAltName fields and the non-empty subject distinguished name field.
All of the exported fields are considered valid.

The username provided by the implementation of this document will be made
available to the NETCONF message layer as the NETCONF username without
modification.  If the username does not comply to the NETCONF requirements
on usernames [I-D.ietf-netconf-4741bis] , i.e., the username is not
representable in XML, the TLS session MUST be dropped.  Any transformations
applied to the authenticated identity of the TLS client made by the TLS
server (e.g., via authentication services or mappings to system accounts)
are outside the scope of this document.

Comments?

Best regards
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 May 2011 16:23:01 +0200

> extension MUST be critical.

What does "MUST be critical" mean?

[...]
 
> All of the exported fields are considered valid.

Export to whom? If there are multiple subjectAltNames, how do you
choose the username?

/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: Badra <[email-masked]>
Date: Tue, 24 May 2011 17:40:48 +0200

Hi,

> What does "MUST be critical" mean?

The following text explains the meaning of "critical":
(extracted from http://wiki.cacert.org/VhostTaskForce).

When an implementation processing a certificate does not recognize an
extension,
if the criticality flag is FALSE, it may ignore that extension. If the
criticality flag is
TRUE, unrecognized extensions shall cause the structure to be
considered invalid,
i.e. in a certificate, an unrecognized critical extension would cause
validation of a
signature using that certificate to fail. When a certificate-using
implementation
recognizes and is able to process an extension, then the certificate-using
implementation shall process the extension regardless of the value of
the criticality
flag.

> Export to whom? If there are multiple subjectAltNames, how do you

Export to the NETCONF message layer

If multiple subjectAltNames are presented, all of them are exported to
the NETCONF message layer. A match in any one of the exported
subjectAltNames is considered acceptable

Best regards,
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 May 2011 17:44:02 +0200

> implementation shall process the extension regardless of the value of

Is this the normative reference for this??
 
> subjectAltNames is considered acceptable

I do not think RFC4741bis provides that service to the transport.

/js

---

From: Badra <[email-masked]>
Date: Tue, 24 May 2011 17:55:22 +0200

> Is this the normative reference for this??

NO, you have section 4.2 of RFC5280
... Each extension in a
   certificate is designated as either critical or non-critical.  A
   certificate-using system MUST reject the certificate if it encounters
   a critical extension it does not recognize or a critical extension
   that contains information that it cannot process.  A non-critical
   extension MAY be ignored if it is not recognized, but MUST be
   processed if it is recognized.

> > >> distinguished name.  Implementations of this document SHOULD export
> all
> > >> the

Would it workif we export them one by one till a match is there?
Have you any other proposal for exporting multiple subjectAltNames?
If not, we shall be restricted to a singlesubjectAltName

Best regards
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 May 2011 18:01:30 +0200

>    processed if it is recognized.

A pointer to that at the right place would be bhighly appreciated.
 
> If not, we shall be restricted to a singlesubjectAltName

There currently is no such loop iterating over a set of usernames. So
either RFC 4741bis needs to provide this functionality by allowing
transports to supply (ordered?) sets of usernames or the TLS transport
has to figure out how to select the one and only username.

/js

---

From: Badra <[email-masked]>
Date: Tue, 24 May 2011 18:09:13 +0200

> A pointer to that at the right place would be bhighly appreciated.

OK

> has to figure out how to select the one and only username.

IMO, it would be better to specify it by RFC 4741bis. Like that, all
transports could
rely on a common way of looping over a set of usernames

Best regards
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 May 2011 19:21:55 +0200

On Tue, May 24, 2011 at 06:09:13PM +0200, Badra wrote:

> transports could rely on a common way of looping over a set of
> usernames

It might be important to note that RFC4741bis is in the RFC editor
queue - so procedurally, such a change to NETCONF is not likely going
to happen any time soon. But that said, the usage of the username is
really in the access control part of NETCONF, which is a WG I-D. But
then this document also does not provide many details, but it says
also:

   Once session establishment is completed, and a user identity has been
   authenticated, the NETCONF transport layer reports the username and a
   possibly empty set of group names associated with the user to the
   NETCONF server.  [...]

RFC4741bis does not talk about group names as far as I can tell...

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 24 May 2011 10:24:38 -0700

Placing X.500 into the client's certificate is interesting, but raises the following questions:

1. Since devices are unlikely to know how to map any field other than CN=<username>, should
   the draft explicit state that the other fields (C, O, OU, etc.) will be ignored?

2. Should the draft say that the CN should be a uid (i.e. kwatsen) instead of a full name
   (i.e. Kent Watsen)?

3. How would the TLS server authenticate the TLS client's certificate?  Will the certificate
   be signed by a CA the TLS server is previously configured to trust?

4. If the TLS client's certificate can be signed by a CA, would it make sense to define a 
   field to encode a group assignment?  For instance, the Netconf server may not know who
   "kwatsen" is, but it sees that a CA the NetConf server trusts has stated that "kwatsen"
   is a member of the "admin" group...

PS: I find the NetConf Manager/Agent terminology in 5539 confusing - would it be easier to 
    always spell out TLS Client/Server and NetConf client/server?

Thanks,
Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Badra
Sent: Tuesday, May 24, 2011 9:47 AM
To: [email-masked]
Subject: [Netconf] Updating NETCONF over TLS document (RFC5539)

Dear all,

Comments?

Best regards
Badra
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Phil Shafer <[email-masked]>
Date: Tue, 24 May 2011 13:11:15 -0400

Kent Watsen writes:
>PS: I find the NetConf Manager/Agent terminology in 5539 confusing - would it be easier 
>to always spell out TLS Client/Server and NetConf client/server?

Amen.  We avoid the terms "manager" and "agent" in all the other
NETCONF-related specs.  I'm surprised to see them here.

Thanks,
 Phil

---

From: Badra <[email-masked]>
Date: Tue, 24 May 2011 23:20:48 +0200

Hi Kent,

> 2. Should the draft say that the CN should be a uid (i.e. kwatsen) instead
 It should do, What about adding after the

" Where it is non-empty, the subject name field MUST contain an X.500
.......... contain a CN RDN or serialNumber RDN.

Implementations of this specification MUST be prepared to ignore
the following standard attribute types in issuer and subject names:

      * country,
      * organization,
      * organizational unit,
      * distinguished name qualifier,
      * state or province name,
      * serial number.
The common name SHOULD be a uid (e.g., "kwatsen"), insteqd of full name
(e.g. "Kent Wasten").

3. How would the TLS server authenticate the TLS client's certificate?  Will
> the certificate
This is beyond TLS, isn't? It is based on PKI as you described.

>   is a member of the "admin" group...

We can include user-specific privilege and access control information in a
user's certificate. I don't have access to the X500 specs to extract the
exactly name of the field containing such information. Have you the firld
name? Thanks

>    always spell out TLS Client/Server and NetConf client/server?
OK, will replace them

Best regards
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 May 2011 02:11:55 +0200

> The common name SHOULD be a uid (e.g., "kwatsen"), insteqd of full name

What is the definition of a uid? In UNIX, a uid is a number... And why
does this matter at all? If I choose to call someone "Ken Watsen" then
this should be just fine, no? What is going to break in NETCONF if Ken
is called "Ken Watsen"?

> This is beyond TLS, isn't? It is based on PKI as you described.

I do not think this is beyond TLS. I assume a server needs to verify the
presented certificate - are you saying that is not the case?? RFC 5539
says:

   The server MUST verify the identity of the client with certificate-
   based authentication according to local policy to ensure that the
   incoming client request is legitimate before any configuration or
   state data is sent to or received from the client.

So what does this text mean in implementation terms? Since a server
does not have a human in the loop to take decisions, how does a server
"verify the identity of the client with certificate-based
authentication according to local policy" if there is not some form or
a PKI? I think it is important to be explicit what this text means -
and in particular it should _not_ be sufficient to accept certificates
just because they contain certain values in some convenient places.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 24 May 2011 20:23:24 -0700

It doesn't have to be "uid" in a UNIX sense, but I think that the common name MUST map to a user account the device can map to an ACL.

Exactly.   The only way this RFC makes sense is if the device can validate the presumed user's identity.  As it is written now, any malicious agent could log into a device.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 25 May 2011 09:38:10 -0700

[I sent this response originally from my phone, which didn't quote Juergon's comments correctly - which is fixed below]

---

From: Badra <[email-masked]>
Date: Wed, 25 May 2011 19:26:57 +0200

On Wed, May 25, 2011 at 6:38 PM, Kent Watsen <[email-masked]> wrote:

> [I sent this response originally from my phone, which didn't quote
> Juergon's comments correctly - which is fixed below]
>
>
>
> It doesn't have to be "uid" in a UNIX sense, but I think that the common
> name MUST map to a user account the device can map to an ACL.
>
>
>
> Exactly.   The only way this RFC makes sense is if the device can validate
> the presumed user's identity.  As it is written now, any malicious agent
> could log into a device.
>

The server should verify the certificate as described in the document and by
rfc5246. Access control based on information exported from the certificate
are out of scope of TLS. This is what I wanted to say.

I don't know how I have to change the text since I didn't get the point of
the malicious agent. Please don't hesitate to propose some text to resolve
the issue
Best regards
Badra

---

From: Kent Watsen <[email-masked]>
Date: Wed, 25 May 2011 13:00:14 -0700

> Please don't hesitate to propose some text to resolve the issue

How about this?

OLD:

   3.2. Client Identity

NEW:

   3.2. Client Identity

      The server MUST verify the identity of the client with using a
      Client Certificate (RFC 5246, section 7.4.6).  The client's
      certificate MUST encode the NETCONF username as follows:

      If the client's certificate type is X.509 (RFC 5280), the NETCONF
      username MUST be obtained from either the "CN" (Common Name)
      "emailAddress", or "rfc822Name" fields.  If the CN field is set,
      then the NETCONF username is the value of CN field.  If either 
      the emailAddress or rfc822Name fields are set, then the NETCONF
      username is the "local-part" field (RFC 822).  If more than one
      of these fields are set, the NETCONF username from each must be
      the same.

      If the client's certificate type is OpenPGP (RFC 6091), the
      NETCONF username is extracted from "User ID" field that has been
      flagged as being the "Primary User ID" field (RFC 4880).  The
      NETCONF username is the "local-part" of the "addr-spec" field
      (RFC 5322).

      The username provided by the implementation of this document
      will be made available to the NETCONF message layer as the NETCONF
      username without modification.  If the username does not comply
      to the NETCONF requirements on usernames [I-D.ietf-netconf-4741bis],
      i.e., the username is not representable in XML, the TLS session
      MUST be dropped.  Any transformations applied to the authenticated
      identity of the TLS client made by the TLS server (e.g., via 
      authentication services or mappings to system accounts) are 
      outside the scope of this document.

      The client's certificate SHOULD be signed by a certificate 
      authority having a valid chain of trust to a certificate
      authority the server trusts.

What do you think?

Thanks,
Kent

---

From: Badra <[email-masked]>
Date: Thu, 26 May 2011 00:28:50 +0200

Dear Kent

Thanks for the text, I have no objection to adopt it
Just a small comment on the following:

     If more than one
     of these fields are set, the NETCONF username from each must be
     the same.
Does this mean that we have to carefully set all of those fields to the same
value (username) during the certificate generation?

Isn't required to keep your early point on the CN;

"The common name SHOULD be a uid (e.g., "kwatsen"), instead of full name
(e.g. "Kent Wasten")."

Best regards
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 May 2011 02:10:22 +0200

>       of these fields are set, the NETCONF username from each must be

It seems the way things are done in RFC 5953 is slightly different.
For example, you propose to treat foo@here and foo@there to be the
same NETCONF username foo. RFC 5953 seems to preserve the difference.
RFC 5953 also has strong words the usage of CN is deprecated and I
guess this is likely more reflecting current policy thinking than
actual usage (but then don't ask me about these things ;-).

>       NETCONF username is the "local-part" of the "addr-spec" field

Puh, RFC 5953 does ignore RFC 6091 certs... Out of curiosity, any
information how much implementation support there is for OpenPGP
certs?

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 25 May 2011 17:15:15 -0700

>Does this mean that we have to carefully set all of those fields to the
>same value (username) during the certificate generation?
>
> "The common name SHOULD be a uid (e.g., "kwatsen"), instead of full name (e.g. "Kent Wasten")."

I was trying to provide some flexibility - I don't know which of those 3 fields people will want to use.    Do you think it's too restrictive to require them to be the same?  Maybe some folks would want to set Common Name to "Kent Watsen" while having rfc822Name "[email-masked]"...  Perhaps we should replace the text to read:  "If more than one of these fields are set, the NETCONF server should attempt to use them in the following order: CN, rfc822Name, emailAddress."?  

Also, we should ensure that some fields are marked "critical".  For instance:

   subjectAltName=critical,rfc822Name:[email-masked]

BTW, I completely forgot to write anything about the CA setting a value for what group the user can be mapped to.  Maybe we could use the "otherName" field, using an IANA-assigned OID under the "ietf-tree" (http://www.oid-info.com/get/1.3.6.1.8.1)?  For instance:

   subjectAltName=critical,rfc822Name:[email-masked],otherName:group;UTF8:my-group

What do you think?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 May 2011 06:42:52 +0200

On Wed, May 25, 2011 at 05:15:15PM -0700, Kent Watsen wrote:
 
> Perhaps we should replace the text to read: "If more than one of
> these fields are set, the NETCONF server should attempt to use them
> in the following order: CN, rfc822Name, emailAddress."?

As said before, this is what we ended up with in RFC 5953:

        [...] However, the usage
        of the CommonName field is deprecated and thus this usage is
        NOT RECOMMENDED. 

> BTW, I completely forgot to write anything about the CA setting a
> value for what group the user can be mapped to.  Maybe we could use
> the "otherName" field, using an IANA-assigned OID under the
> "ietf-tree" (http://www.oid-info.com/get/1.3.6.1.8.1)?  For
> instance:

There is no requirement to provide a group. NACM has the concept of a
group (=role) and the situation where this is provided to NACM is in
principle RADIUS (Management-Policy-Id defined in RFC 5607).

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 26 May 2011 00:45:31 -0700

[top-posting since my phone didn't quote well last time]

Regarding using the entire rfc822Name field (foo@here vs foo@there), this would mean that all usernames would have to have the '@' character, per the addr-spec format defined in RFC 822.  But only using the local-part doesn't restrict use of the '@' character, since it's allowed when in a quoted string (e.g. "foo@bar"@domain).  There is a convention for email address to be "username@domain"  (e.g. local-part == username), since the @domain part is used primarily for Internet routing (virtual hosting aside).     Was this discussed with RFC 5953?  Is this why RFC 5953 supports mappings for ipAddress and dnsName?  Should we support these other mappings as well?

Regarding OpenPGP certificates, I've never seen it used, but the TLS RFC allows it, so it seemed prudent to have a mapping for it. 

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Thu, 26 May 2011 01:08:56 -0700

Good point about Common Name being deprecated.  Since emailAddress is also deprecated, maybe we just say the NETCONF username MUST come from rfc822Name?

Even if we only allow the username to come from rfc822Name, x.509 allows for multiple rfc822Names - any thoughts on how more than one should be handled?

Dropping the group information sounds right, since the SSH transport doesn't provide an equivalent. 

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 May 2011 10:38:35 +0200

> Regarding using the entire rfc822Name field (foo@here vs foo@there), this would mean that all usernames would have to have the '@' character, per the addr-spec format defined in RFC 822.  But only…

I think RFC 5953 took the approach of making it configurable what is
picked from a cert and then mapped into the SNMP equivalent of the
NETCONF username.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 26 May 2011 11:03:59 +0200 (CEST)

> Dropping the group information sounds right, since the SSH transport doesn't

I think it would be a feature for this transport to provide group
mapping.  It means you don't have to configure additional user ->
group maps.  NACM supports getting groups from the transport, so it
fits nicely into the architecture.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 May 2011 11:14:58 +0200

> fits nicely into the architecture.

With RADIUS, I thought the idea was that the identity of an SSH client
can be mapped at authentication time into the current group (role) the
identity has. This makes sense if roles change more frequently than
the identity of a client (and its associated credentials).

If we have the group (role) hard coded into a certificate, then we
require to issue new certs whenever a group (role) of an identity
changes. If the assumption is correct that roles change more
frequently than identities (and their credentials), then coding the
group into the cert seems probably wrong.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 26 May 2011 11:21:19 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> > > Dropping the group information sounds right, since the SSH
> > > transport doesn't 
> > > provide an equivalent.
> > 

We wouldn't _require_ the group info in the cert, but if it is there,
it can be used.  You could still use RADIUS or the NACM config mapping
if you want to.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 May 2011 11:30:35 +0200

> it can be used.  You could still use RADIUS or the NACM config mapping

But why would someone use this? What is the problem to be solved? Is
creating certificates easier than configuring a NETCONF server? ;-)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 26 May 2011 12:01:12 +0200 (CEST)

> creating certificates easier than configuring a NETCONF server? ;-)

I thought Kent had a use case, and I thought that the reasoning that
it shouldn't be here b/c SSH doesn't have it was not convincing.  If
we don't see a use case, it should of course not be included.  (But
you should probably not ask me, since I don't really see the use case
with client certificates in the first place.  I don't think this TLS
transport provides any benefits over the SSH transport.)

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 26 May 2011 05:43:24 -0700

The use case is much like with RADIUS, mapping an unknown user to a known group, but without the need to deploy a RADIUS server.  If a company is using PKI, presumably they could set up infrastructure to quickly generate/revoke client certs when roles change.  

That said, Martin is right about this transport not having anything on SSH, especially given that SSH now supports client/server certs (RFC 6187).  Actually, this transport is arguably worse than SSH given the lack of userauth and no multiplexing solution like SSH channels (BEEP doesn't count).

It seems that how to use x.509 client certs to encode identity could be it's own RFC that this RFC would then reference.  An RFC like that might be useful for HTTPS, POPS, IMAPS, etc. 

Thanks,
Kent

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 26 May 2011 07:36:33 -0700

>>>>> On Thu, 26 May 2011 10:38:35 +0200, Juergen Schoenwaelder <[email-masked]> said:

>> There is a convention for email address to be "username@domain"
>> (e.g. local-part == username), since the @domain part is used
>> primarily for Internet routing (virtual hosting aside).  Was this
>> discussed with RFC 5953?  Is this why RFC 5953 supports mappings for
>> ipAddress and dnsName?  Should we support these other mappings as
>> well?

JS> I think RFC 5953 took the approach of making it configurable what is
JS> picked from a cert and then mapped into the SNMP equivalent of the
JS> NETCONF username.

The 5953 certificate mapping was done to allow for flexibility so
operators could do what they wanted using certificates they already had
available to them without needing to create new ones.  In many cases, it
was expected that it wasn't necessarily a human even making the
connection, hence an IP address based certificate might do a better job
identifying what exactly was making the connection.

The proposals in this thread seem to be taking the opposite approach:
limit what the certificate can look like restricting it so that it must
be created specifically to meet the needs of netconf and thus it's
likely operators will need a "netconf" certificate that is very
different than the rest of the certificates they might already have
available to them.  It also appears that "there will be only one CA" as
well, based on the discussion texts so far.  I haven't chimed in much
because I'm having a hard time trying to figure out what the real end
goals are: restrictive vs permissive, one CA vs multiple, reuse vs "only
for netconf", etc.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 May 2011 20:18:24 +0200

On Thu, May 26, 2011 at 05:43:24AM -0700, Kent Watsen wrote:

> The use case is much like with RADIUS, mapping an unknown user to a
> known group, but without the need to deploy a RADIUS server.  If a
> company is using PKI, presumably they could set up infrastructure to
> quickly generate/revoke client certs when roles change.

And that is simpler than simply changing the ACL configuration?

> That said, Martin is right about this transport not having anything
> on SSH, especially given that SSH now supports client/server certs
> (RFC 6187).  Actually, this transport is arguably worse than SSH
> given the lack of userauth and no multiplexing solution like SSH
> channels (BEEP doesn't count).

True, if you have SSH, which you must have since NETCONF requires it
as mandatory to implement transport. That said, there likely will be a
class of devices that have TLS but no SSH and where adding SSH support
just for NETCONF is a significant cost factor - or a reason to not use
NETCONF. The question is whether we care about this or not.

Whatever we do, I think we should either make the TLS transport usable
or take the decision to move this off the standards-track instead of
doing half-baked updates that won't work in practice. Perhaps time to
check how many implementations and deployments we have for the non-SSH
transports?

> It seems that how to use x.509 client certs to encode identity could
> be it's own RFC that this RFC would then reference.  An RFC like
> that might be useful for HTTPS, POPS, IMAPS, etc.

Who uses client certs with HTTPS, POPS, IMAPS? What would be more
seriously needed is an addition to TLS that provides us with different
user auth mechanisms within TLS...

/js

---

From: Badra <[email-masked]>
Date: Thu, 26 May 2011 20:50:17 +0200

> actual usage (but then don't ask me about these things ;-).

Since there is no loop iterating over a set of usernames, so how exporting
the first subjectAltName field? Like that we avoid restrictions on reusing
certificates (but need to restrict the NETCONF usernqmes to this field
content)

Best regards
Badra

---

From: Kent Watsen <[email-masked]>
Date: Fri, 27 May 2011 16:09:38 -0700

> And that is simpler than simply changing the ACL configuration?

For one device, no, but maybe for a network of devices.  Of course,
to your point, if they have a network of devices, it's more likely
they'll have a RADIUS server.

> NETCONF. The question is whether we care about this or not.

Good point.  *If* there were such a class of devices, it would matter 
to a NETCONF-oriented NMS (like ours!) - as managing the device through 
NETCONF/TLS would be easier than adapting whatever native interface 
it presents.

> check how many implementations and deployments we have for the non-SSH

Agreed

> Who uses client certs with HTTPS, POPS, IMAPS? 

A quick search reveals more than I suspected.  Both Firefox and Mozilla
support "personal certificates" and both Apache and DoveCot can be 
configured to authenticate client certificates.  A number of institutions
(labs, schools, etc.) run CAs to issue personal certificates.  Some issue
client certificates for as little as 7 days.  This page 
(http://itc.virginia.edu/netbadge) shows how a university uses personal
certificates to grant access to "website, service, or application" - 
apparently they're using Pubcookie (http://www.pubcookie.org/).  Should
the TLS transport require a call out to an identity server to produce 
a NetConf username from the certificate?

> What would be more

Your suggestion to add the user auth mechanisms to TLS itself is along 
the lines of what I meant by saying that the effort (if any) should be 
factored into another standard - as having a NetConf-specific solution
wouldn't be ideal...