Subject: [Netconf] netconf username and 4742bis

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jul 2010 11:49:49 +0200

Hi,

the monitoring draft triggered some discussion that the secure
transports must provide an authenticated NETCONF username. Such a
username is exported in the monitoring module and also used in an
access control proposal. Since different transports support different
authentication schemes, it should be the responsibility of the
transport documents to spell out how a username is derived for the
authentication mechanisms supported. The upcoming 4741bis has been
updated to make that clear. The relevant paragraph:

   The 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.  The algorithm used to derive the username is
   transport protocol specific and in addition specific to the
   authentication mechanism used by the transport protocol.  NETCONF
   transport protocols therefore MUST explain how a NETCONF username is
   derived from the authentication mechanisms supported by the transport
   protocol.

This has implications to 4742bis since it should spell out how the
NETCONF username is provided when SSH is being used. (And the text on
authentication requirements in the access control ID probably should
be reviewed and where approriate incorporated into 4742bis.)

/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: "Bert (IETF) Wijnen" <[email-masked]>
Date: Tue, 06 Jul 2010 12:14:51 +0200

Thanks Juergen.

Margaret, can you please take this into account when doing the new rev 
(RSN I hope)!

Bert

---

From: Phil Shafer <[email-masked]>
Date: Tue, 6 Jul 2010 10:41:50 -0400

>be reviewed and where approriate incorporated into 4742bis.)

Be aware that many low-end devices (and more than a few high-end
ones) do not have the concept of "user" at all, with just a single
password prompt at login time.  I'll admit complete ignorance about
how ssh is implemented on those devices, given that the ones I have
at hand don't support ssh.

Ok, google says:

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t2/feature/guide/ftrevssh.html

    Router> enable 
    Router# configure terminal 
    Router(config)# username user password xxxxx
    Router(config)# aaa authentication login LOCALUSERS local
    Router(config)# line 47
    Router (config-line)# no exec 
    Router (config-line)# login authentication LOCALUSERS
    Router (config-line)# transport input ssh 
    Router (config-line)# exit 
    Router (config)# exit 

    Client Commands
    Router# ssh -l user:47 10.1.2.3

I've never seen this ":47" suffix before, so it looks odd, but I
guess it's needed to tell the ssh server which "line" to use.

In any case, it looks like there is in fact a user name configured,
instead of the non-user-oriented telnet access.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jul 2010 17:30:19 +0200

> at hand don't support ssh.

The SSH protocols requires to ship a username, whatever the device
does with it I do not know. I know that some of our equipment (and it
is not CISCO gear) does not remember a user name - so if you change
privilege level and you go through RADIUS, the box simply asks again
for your user name (since it obviously forgot how you came into the
box via SSH in the first place). Frankly, this is somewhat annoying
but I am able to live with it.

Anyway, for SSH it should be pretty straight forward to explain how a
username is derived. Everything else is pretty much implementation
detail except that access control will at the end have to know which
access control policies to apply (so some idea who got authenticated
is better preserved somewhere).

/js

---

From: Mark Scott <[email-masked]>
Date: Tue, 6 Jul 2010 11:35:41 -0400

Juergen,

Is the intention to state that the NETCONF username will be protocol and authentication method specific and the key requirement is that a value be provided in all cases?

  OR

Is the plan to establish some rules around the username derivation to enable the NACM work?  The 'whose permissions are known to the server' seems to imply some consistency in derivation.  For example, will consistent NETCONF usernames be generated across protocols?  Across sessions? What about authentication schemes such as host-based SSH where there is no username would we want to standardize on user of hostname/IP/other?

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: July-06-10 5:50 AM
To: [email-masked]
Subject: [Netconf] netconf username and 4742bis

Hi,

/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: Tue, 6 Jul 2010 20:23:40 +0200

On Tue, Jul 06, 2010 at 05:35:41PM +0200, Mark Scott wrote:
 
> Is the intention to state that the NETCONF username will be protocol
> and authentication method specific and the key requirement is that a
> value be provided in all cases?
> 
>   OR
> 
> Is the plan to establish some rules around the username derivation
> to enable the NACM work?  The 'whose permissions are known to the
> server' seems to imply some consistency in derivation.  For example,
> will consistent NETCONF usernames be generated across protocols?
> Across sessions? What about authentication schemes such as
> host-based SSH where there is no username would we want to
> standardize on user of hostname/IP/other?

Well, this username first appeared in the monitoring MIB (which you
are a co-author of) and I asked the mailing list whether it is
understood what we are going to get into. Now we are in it (and
frankly for access control to work, we have to go through this).

You ask several questions.

Q1: Is the NETCONF username protocol and authentication method
    specific?

A1: I consider the NETCONF username equivalent to the notion of SNMP's
    snmpSecurityName, which is qualified by the security model and in
    some cases of ISMS in addition by the transport model so that a
    TLS user joe can be distinguished from an SSH user joe if this is
    desirable.

Q2: Is the NETCONF username value provided in all cases?

A2: It better is if we want access control to be meaningful.

Q3: For example, will consistent NETCONF usernames be generated across
    protocols?

A3: I assume you mean transport protocols. In ISMS, we ended up
    supporting both via a transport model prefix that can be added.

Q4: What about authentication schemes such as host-based SSH where
    there is no username would we want to standardize on user of
    hostname/IP/other?

A4: That needs to be worked out. And given my ISMS experience, the
    real fun starts when we hit X.509 certificates.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 Jul 2010 21:48:00 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> username is derived.

Maybe, but note that even in SSH the user name can depend on the
authentication method.  In
http://www.ietf.org/mail-archive/web/netconf/current/msg05993.html I wrote:

  It turns out that the 'user name' field can be empty, and the real
  user name derived from other authentication messages, see section
  3.1 and 3.2 of RFC 4462.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jul 2010 22:05:28 +0200

>   user name derived from other authentication messages, see section

I guess this is still simple compared to the fun you can have with
X.509 certificates. Section 3.2 of RFC 4462 actually says:

   The user name may be an empty string if it can be deduced from the
   results of the GSS-API authentication. 

My reading is that even if there is no user name in the
SSH_MSG_USERAUTH_REQUEST, the GSS-API has to provide a user name and
hence there is always something like a user name involved in the
authentication exchange.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 06 Jul 2010 15:48:24 -0700

>>>>> On Tue, 6 Jul 2010 20:23:40 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> Q4: What about authentication schemes such as host-based SSH where
JS> there is no username would we want to standardize on user of
JS> hostname/IP/other?

JS> A4: That needs to be worked out. And given my ISMS experience, the
JS> real fun starts when we hit X.509 certificates.

It's certainly interesting that RFC5539 specifies no way to come up with
a username to even pass to an access control system.  I suspect that'll
need a -bis before it can be used with whatever resulting access control
document this WG produces.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Mark Scott <[email-masked]>
Date: Thu, 8 Jul 2010 16:12:45 -0400

Wes,

Agree and think a -bis may be warranted for any Netconf transport RFC where the access control expects standardized authentication, session mgmt or other data and/or behaviour.

Imo, priority should be given to standardize SSH since it is the mandatory Netconf transport protocol.  We should at minimum have recommendations for the others though.

>From an earlier offline discussion held in the context of the monitoring draft the (rough) assessment for each Netconf transport RFC which may be useful for this discussion:

	1.  rfc4743/SOAP: Map the Netconf identity to the http transport identity which was used to initiate the session?  (since sec 3.4 states the netconf session must be maintained, including authentication).  Is there a common derivation for all options specified in 4.1?

	2.  rfc4742/SSH: "SSH_MSG_USERAUTH_REQUEST" independent of authentication method used
 
	3.  rfc5539/tls:  the only must for client identity seems to be certificates (sec 2.1).  The contents of these vary considerably so suggest we use the "Subject Name" from X.509.

	4.  rfc4744/beep:  I don't know much about BEEP but the SASL authentication identity looks appropriate.  I don't know if we need to account for proxies here.

Note that the monitoring draft ultimately did not include this information and we did not reach consensus on the completeness or accuracy of the information above.

Any updates/recommendations anyone can provide would be useful.

cheers,
Mark

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 13 Jul 2010 08:06:13 -0400

Hi Juergen,

Bert passed on your e-mail below, and I am not sure what changes you  
are proposing for the SSH draft.

When using SSH, the username is (implicitly or explicitly) supplied  
when the SSH client is invoked.  The user name isn't derived using any  
algorithm, it is supplied by the client.

Should I just say that?  Or are you looking for some additional  
explanation?

Margaret

On Jul 6, 2010, at 6:14 AM, Bert (IETF) Wijnen wrote:

> Thanks Juergen.
>
> Margaret, can you please take this into account when doing the new  
> rev (RSN I hope)!
>
> Bert
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Jul 2010 00:14:13 +0200

> Should I just say that?  Or are you looking for some additional  

You may want to read about the different authentication methods SSH
supports, see also some comments recently made on the mailing list.

Note that we are talking about the SSH _server_ - so it matters how
a user identity is communicated and authenticated to the server.

/js

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 26 Jul 2010 14:24:02 +0200

We discussed the NETCONF user name issue at the NETCONF meeting in  
Maastricht, and there was agreement within the room that the draft  
should state that the method to obtain the user name from the SSH  
server is implementation-dependent.  The working group chairs will be  
confirming this agreement on the mailing list.

In the meantime, I have just submitted a new draft that contains the  
following changes:

(1) Inserts a new paragraph between the first and second paragraphs of  
section 3:

    How the NETCONF Server extracts the SSH user name from the SSH layer
    is implementation-dependent.

(2) Makes the final changes to the operation/command wording, as  
agreed with Martin Bjorklund and confirmed on the list.

If the first change is successfully confirmed on the list, I believe  
this draft will be ready for submission to the IESG.  Please let me  
know if you see any errors or omissions.

Thanks.
Margaret

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 27 Jul 2010 11:25:54 -0700

Hi -

> From: "Margaret Wasserman" <[email-masked]>
> To: "Juergen Schoenwaelder" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, July 26, 2010 5:24 AM
...
>     is implementation-dependent.

I hope that this cannot be understood as meaning that the *value* extracted
could also be implementation-dependent.

Randy

---

From: Steve Maxwell <[email-masked]>
Date: Tue, 27 Jul 2010 23:53:01 -0700

I believe the discussion at the IETF working group was that the *way* or mechansim to obtain the user name was implementation-dependent, but not the contents..

Steve,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Presuhn
Sent: Tuesday, July 27, 2010 11:26 AM
To: [email-masked]
Subject: Re: [Netconf] netconf username and 4742bis

Hi -

...

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Jul 2010 10:21:56 +0200

On Wed, Jul 28, 2010 at 08:53:01AM +0200, Steve Maxwell wrote:

> I believe the discussion at the IETF working group was that the
> *way* or mechansim to obtain the user name was
> implementation-dependent, but not the contents..

I think there is general agreement that the 'how' is implementation
dependent. I do not know why this is even mentioned or discussed.

The discussion as far as I recall it was about the 'what' and the
sense of the room was that this is implementation dependent as
well. The point was made that mappings done by an SSH server of the
user identity authenticated by the SSH protocol to the operating
system's notion of an account name is what people / operators do
expect since this is consistent with what they get when they start an
interactive SSH session. If an SSH server maps the SSH user identity
'bob' to the account identity 'domain/bob', then the username used by
NETCONF should be 'domain/bob' and not 'bob'.

This of course means that user to group mappings in an access control
model won't be portable across devices but the room felt this was less
a problem than having differences between the username seem by NETCONF
and interactive sessions.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Jul 2010 01:34:52 -0700

> I believe the discussion at the IETF working group was that the *way* or mechansim to obtain the user name was implementation-dependent, but not the contents..

no -- the content will be different.
Margaret's example of Windows inserting the default domain
into the name string is 1 such case.

E.g., user 'joe' in the SSH request may turn into 'mydomain/joe'
by the time he NETCONF server sees it.

If radius is used, the server may have no idea what username
was usually used in the SSH setup.

Simply declaring a server MUST know this is problematic.
I doubt any implementation will go to the trouble of
violating the SSH layering to determine this field.
Certainly a server subsystem executable using openssh will not be able
to do this.

The 'transformation' (if any) will be consistent within a single server.
That's the best we can do.  Applications will have to deal with it.
The only impact will be NACM 'group' configuration.

Andy

> Steve,
> 
> -----Original Message----- From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Presuhn Sent: Tuesday, July 27, 2010 11:26 AM To: [email-masked] Subject: Re:
> [Netconf] netconf username and 4742bis
> 
> Hi -
> 
>> From: "Margaret Wasserman" <[email-masked]> To: "Juergen Schoenwaelder" <[email-masked]> Cc: <[email-masked]> Sent: Monday, July 26, 2010 5:24 AM Subject: Re:
>> [Netconf] netconf username and 4742bis
> ...
>> (1) Inserts a new paragraph between the first and second paragraphs of section 3:
>> 
>> How the NETCONF Server extracts the SSH user name from the SSH layer is implementation-dependent.
> 
> I hope that this cannot be understood as meaning that the *value* extracted could also be implementation-dependent.
> 
> Randy
> 
> _______________________________________________ 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: Steve Maxwell <[email-masked]>
Date: Fri, 30 Jul 2010 01:14:55 -0700

Thanks for the clarification... :-)

Steve,

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, July 28, 2010 1:35 AM
To: Steve Maxwell
Cc: Randy Presuhn; [email-masked]
Subject: Re: [Netconf] netconf username and 4742bis

Andy

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 30 Jul 2010 10:34:28 +0200

I suggest you/we all look at and check the latest revision of the draft
which was posted last monday and for which we issues a WGLC
on Tuesday.

If things are still unclear, pls let us know asap.

Bert

---

From: Steve Maxwell <[email-masked]>
Date: Fri, 30 Jul 2010 01:36:31 -0700

Great suggestion..thanks!

Steve,

-----Original Message-----
From: Bert (IETF) Wijnen [mailto:[email-masked]] 
Sent: Friday, July 30, 2010 1:34 AM
To: Steve Maxwell
Cc: Andy Bierman; [email-masked]
Subject: Re: [Netconf] netconf username and 4742bis

Bert