Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Thu, 03 Mar 2011 14:25:42 +0100

Responses/comments to your DISCUSS points by Juergen.

Pls respond/comment with cc: to WG mailing list, so we all
get a clear understanding of your (remaining) concerns and so
we can try to get to convergence.

Bert Wijnen
Document SHepherd
>  ----------------------------------------------------------------------
>  DISCUSS:
>  ----------------------------------------------------------------------
>
>  1) should there be constraints on the basic format of username? if it is expected to be specified by an operator in config files 
> or databases, should it be human-readable? ascii? utf-8?

NETCONF content by default is UTF8.

>  2) should the format be predictable, so the operator can determine what the NC username will be, given a knowledge of the 
> corresponding identifier in the secure transport protocol?

NETCONF uses what the secure transport natively delivers. Since there
are not size or character set constraints in NETCONF, this just works
fine and follows the model that works on a large number of deployed
CLIs.

>  3) commit MUST revert at 600 secs, but timeout is configurable., what if somebody sets it to 700 seconds? MUST it still revert at 
> 600? Can a low timeout cause a denial of service?

600 secs is the default if a timeout is not specified:

    A confirmed commit operation MUST be reverted if a confirming commit
    is not issued within 600 seconds (10 minutes).  The confirming commit
    is a commit operation without the<confirmed>  parameter.  The timeout
    period can be adjusted with the<confirm-timeout>  parameter.

If this text is not clear enough, we can change this to:

    A confirmed commit operation MUST be reverted if a confirming
    commit is not issued within the timeout period (by default 600
    seconds = 10 minutes).  The confirming commit is a commit operation
    without the<confirmed>  parameter.  The timeout period can be
    adjusted with the<confirm-timeout>  parameter.

Setting the timeout to 0 secs likely causes an almost immediate
rollback. Is this a denial of service risk? Well, if an attacker
manages to commit configs, then he likely can do more interesting harm
that this attempt to eat some rollback CPU cycles.

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

On 3/2/11 12:05 AM, David Harrington wrote:
> David Harrington has entered the following ballot position for
> draft-ietf-netconf-4741bis-09: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> 1) should there be constraints on the basic format of username? if it is expected to be specified by an operator in config files or databases, should it be human-readable? ascii? utf-8?
>
> 2) should the format be predictable, so the operator can determine what the NC username will be, given a knowledge of the corresponding identifier in the secure transport protocol?
>
> 3) commit MUST revert at 600 secs, but timeout is configurable., what if somebody sets it to 700 seconds? MUST it still revert at 600? Can a low timeout cause a denial of service?
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 1) copyright in yang module needs updating.
>
> 2) appendix F doesn't mention dropping the local file requirement for URLs,
>
> 3) terminology should probably define username, not user. It is doubtful username is commonly referred, since it did not exist in 1.0.
>
> 4) I found the use of RFC2119 laniguage rather inconsistent. Some uses of "can" probbaly should have been MAY. Some uses of "are" probbaly should have been MUST, to ensure interoperability.
>
> 5) I support Lars' Discuss. There is no requirement to use a transport protocol that provides congestion control. If a transport is used that does not already provide congestion control, then the NC transport should provide congestion control. It is RECOMMENDED to use an existing transprt standard that provides congestion control.
>
>
>
>

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 04 Mar 2011 09:41:40 +0100

More answers/comments from Juergen below.

Can I ask mister Harrington to participate in the discussion on the
NETCONF WG mailing list? That is the only way to get to convergence
in a reasonable amount of time. Dave, you ARE a particpant in the WG,
and I hope you can pay attention there till we reach agreement on this
DISCUSS. I hate to have to keep forarding yoru emails to the WG and
then forward any WG technical responses back to you.
That is not productive, and things may get lost in that path.

Thanks,
Bert Wijnen
Document shepherd

-------- Original Message --------
Subject: 	Re: [Netconf] FW: David Harrington's Discuss on draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT)
Date: 	Thu, 3 Mar 2011 18:07:23 +0100
From: 	Juergen Schoenwaelder <[email-masked]>
Reply-To: 	Juergen Schoenwaelder <[email-masked]>
To: 	Ersue, Mehmet (NSN - DE/Munich) <[email-masked]>
CC: 	Netconf <[email-masked]>

On Thu, Mar 03, 2011 at 05:08:01PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote:

>  Any comments? Pls also check the mail below from
>  David Harrington.

[... stuff removed I figured out is not helpful to send ...]

NETCONF is the wrong place to constraint user name. For SSH, this is
a no-brainer anyway.

/js

PS: We dealt with the uniquess questions explaining that this is an
     ACM issue and note that it is even mentioned in the Security
     Considerations section:

    [...] Second, it could be desirable to authorize based on
    mechanisms available in the secure transport layer (SSH, BEEP, etc).

PS: RFC 4252 says:

       byte      SSH_MSG_USERAUTH_REQUEST
       string    user name in ISO-10646 UTF-8 encoding [RFC3629]

     RFC 4251 says:

    string

       Arbitrary length binary string.  Strings are allowed to contain
       arbitrary binary data, including null characters and 8-bit
       characters.  They are stored as a uint32 containing its length
       (number of bytes that follow) and zero (= empty string) or more
       bytes that are the value of the string.  Terminating null
       characters are not used.

______________________

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Mar 2011 08:49:38 +0100

On Wed, Mar 09, 2011 at 01:26:32AM -0500, David Harrington wrote:

> --- The DISCUSS for 4741bis ---
> 
> I have concerns about whether the ***netconf username*** being
> provided by the netconf transport layer to its upper layers is clearly
> defined enough. It is unclear what the format is, what the character
> set is, and whether the authentication service (e.g., SSH) is included
> in what the netconf transport layer provides. 
> 
> and the concern is whether what is provided by the netconf transport
> layer will meet the assumptions of operators.
> What if, I as an implementer chose to provide a netconf username of
> the following form?
> "dbh<cr>
> ssh<cr>
> ssh-password algorithm<cr>
> <<]]>>
> <cr>
> <cr>
> <tab><tab><lf>
> SSH user name = [email-masked]<cr>
> "
> 
> would this be legal? according to 4741bis and 4742bis, it would appear
> to be legal, because anything is acceptable ...
> would it be useable by operators to, for example, specify an access
> control policy?
> or map it to existing native access controls?
> would it be useable by operators to configure an access control policy
> using netconf? or a CLI?

The vast majority of deployed CLIs tells me that apparently this works
in real life.

> I fear it would not be.
> But I think this would be perfectly legal according to the netconf
> standard.
> that's my concern.

There are usually operating system specific constraints on what you
can use as a user name. I fear that we are discussing a purely
academic problem here.

> So maybe 4741bis simply needs to say that since 4741bis defines no
> constraints, anything is acceptable in a netconf username, so 4741bis
> implementations MUST gracefully accept whatever is provided by the
> transport layer as a netconf username.

Since there is going to be access control for NETCONF, I guess we
implicitely do expect that the username is a UTF8 string. In fact,
draft-ietf-netconf-access-control-02.txt defines this:

     typedef nacm-user-name-type {
       type string {
         length "1..max";
       }
       description
         "General Purpose User Name string.";
     }

Would your concern be addressed if we state this in text in 4741bis?

> --- The DISCUSS for 4741bis ---
> 
> I have a concern that the netconf transport layer might not return the
> nature of the authentication mechanism. This might be important to
> other parts of the system, such as an access control system.
> If the transport layer does not provide this, is it acceptable for an
> access control system to violate "netconf layering" to go get that
> information? will that information be available when an AC system is
> determining permissions?
> If so, it is unclear whether the Message layer is actually
> transport-independent, as claimed in section 1.2.
> and whether upper layers are transport-independent.
> The layering diagrams don't really show where an access control system
> would fit in the architecture.
> My concern is whether upper layers have the information necessary to
> identify the authenticated entity.
>    o  user: The authenticated identity of the client.  The
> authenticated
>       identity of a client is commonly referred to as the NETCONF
>       username.
> 
> section 2.2 says:
>    The authentication process MUST result in an authenticated client
>    identity whose permissions are known to the server. 
> This text does not identify what types of permissions must be known to
> the server.
> Is this the native access control system that defines the permissions?
> what types of permissions are you referring to? permission to
> establish an SSH subsystem? open a netconf session? perform
> edit-config operations? modify certain portions of the datastore? 
> If "dbh" can be returned from two different transports, but represent
> two different client identities, how can the server know the
> associated permissions?
> "whose permissions are known to the server" is really ambiguous.
> I think the text is unclear about compliance requirements of the MUST.
> 
> Those are my concerns, and I don't see them addressed in the ML
> discussions.

NETCONF access control is work in progress. As mentioned before,
4741bis says in the security considerations:

   [...] It is further
   expected that the identity of each end of a NETCONF session will be
   available to the other in order to determine authorization for any
   given request.  One could also easily envision additional
   information, such as transport and encryption methods, being made
   available for purposes of authorization.

Are you saying we have to keep the revision of 4741 (which does not do
authorization either) on hold until the access control work has been
completed??

/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: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Mar 2011 09:01:16 +0100 (CET)

Hi,

Juergen Schoenwaelder <[email-masked]> wrote:
> implicitely do expect that the username is a UTF8 string.

But do we care in what format the transport delivers it to NETCONF?
I don't care if the transport delivers a UTF-16 encoded unicode
string to the netconf server.

However, we (implicitly) expect it to be a subset of unicode, namely
the subset that can be encoded in XML (which incidentally is the
allowed values for the 'string' YANG data type).

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Mar 2011 09:10:18 +0100

> allowed values for the 'string' YANG data type).

We are talking about how things work conceptually. You implementation
might accept whatever format and do translation wherever you want as
long as the end result is going to be representable as a UTF8 string.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Mar 2011 09:28:25 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> We are talking about how things work conceptually.

It doesn't make much sense to say that the string is conceptually
encoded in UTF-8.

I suggest we add a sentence:

   The username is a string of characters that match the "Char"
   production from section 2.2 of [1].

OLD:

   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.

NEW:

   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 username is a string of characters that
   match the "Char" production from section 2.2 of [1].  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.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Mar 2011 11:48:59 +0100

>    mechanisms supported by the transport protocol.

Fine for, especially if David tells us that this change addresses his
concern.

/js

---

From: "David Harrington" <[email-masked]>
Date: Wed, 9 Mar 2011 01:26:32 -0500

Hi Bert and others,

Wow, "mister harrington"????
Actually, I am not a participant in the WG. 
I haven't actually read any emails in this WG since last July.
I also don't think I've been present in a netconf meeting since at
least last July. 
I am subscribed to the ML, but I don't read it. If you think I should
unsubscribe, let me know and I will.

I have discussions about DISCUSSes re: many WG documents, but I do not
subscribe to all mailing lists, and seldom do those discussions happen
on the WG mailing lists. 
The discussions are held in emails addressed to the DISCUSS holder,
and the iesg list, usually by the document authors and/or shepherd,
and the secretariat is working to capture those DISCUSS discussions to
be archived.
and as far as I can tell, that is standard IESG procedure for
discussing DISCUSSes.
It is NOT standard IESG procedure to require ADs to subscribe and hold
discussions on WG mailing lists.
Just so you know.

But since you asked nicely, I'll respond here.

--- The DISCUSS for 4742bis ---

4741bis states 
" NETCONF transport protocols therefore MUST explain how a NETCONF
username is
   derived from the authentication mechanisms supported by the
transport
   protocol."

My concern was not how the "SSH user name" is obtained. It is fine to
me that that is implementation-dependent, since different netconf
transport implementations might choose different SSH implementations
to work with, and might choose different authentication methods, which
will result in different things being returned by the SSH
implementation.
But there is no explanation of how the ***netconf username*** is
derived from the ***SSH user name***.
As I see it from the text, the intention is that the netconf username
has a 1:1 mapping from the SSH user name.
Actually, I think that assumption may be incorrect, as we learned in
ISMS. 
IIRC, SSH is rather ambiguous about whether "user name" MUST contain a
value (e.g., when using GSSAPI)
I think your intent is that ***netconf username will contain whatever
the SSH implementation provides to the netconf transport
implementation***.
I am fine with that intention. But that explanation is not documented
in 4742bis.

--- The DISCUSS for 4741bis ---

I think it might be simpler to document the presumed constraints on
character set, control characters, etc.
But that is a WG choice. 
But whether the choice is to constrain the netconf username, or NOT
constrain it in any way, the choice should be documented so the
standard is clear and unambiguous about compliance requirements.

--- The DISCUSS for 4741bis ---

section 2.2 says:

dbh

> -----Original Message-----
> From: Bert (IETF) Wijnen [mailto:[email-masked]] 
> Sent: Friday, March 04, 2011 3:42 AM
> To: David Harrington
> Cc: The IESG; [email-masked]; 
> [email-masked]; netconf
> Subject: Re: David Harrington's Discuss on 
> draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)
> 
> Subject: 	Re: [Netconf] FW: David Harrington's Discuss on 
> draft-ietf-netconf-rfc4742bis-07: (withDISCUSS and COMMENT)
> > Please refer to 
> http://www.ietf.org/iesg/statement/discuss-criteria.html
> >
> > 1) should there be constraints on the basic format of 
> username? if it is expected to be specified by an operator in 
> config files or databases, should it be human-readable? ascii?
utf-8?
> >
> > 2) should the format be predictable, so the operator can 
> determine what the NC username will be, given a knowledge of 
> the corresponding identifier in the secure transport protocol?
> >
> > 3) commit MUST revert at 600 secs, but timeout is 
> configurable., what if somebody sets it to 700 seconds? MUST 
> it still revert at 600? Can a low timeout cause a denial of service?
> >
> >
> > 
>
> > 3) terminology should probably define username, not user. 
> It is doubtful username is commonly referred, since it did 
> not exist in 1.0.
> >
> > 4) I found the use of RFC2119 laniguage rather 
> inconsistent. Some uses of "can" probbaly should have been 
> MAY. Some uses of "are" probbaly should have been MUST, to 
> ensure interoperability.
> >
> > 5) I support Lars' Discuss. There is no requirement to use 
> a transport protocol that provides congestion control. If a 
> transport is used that does not already provide congestion 
> control, then the NC transport should provide congestion 
> control. It is RECOMMENDED to use an existing transprt 
> standard that provides congestion control.
> >
> >
> >
> >
> 
>

---

From: Phil Shafer <[email-masked]>
Date: Wed, 9 Mar 2011 08:34:33 -0500

>   production from section 2.2 of [1].

What is [1]?  Are you limiting the character set?  Are you saying
that this string must be encodable in utf-8?  Are there strings
that cannot be encoded in utf-8?  Does this sentence add any useful
information for the implementor?

>Fine for, especially if David tells us that this change addresses his

I'm baffled as to how this addresses his concern, which was that
our use of the term "implementation-dependent" is "woefully
inadequate".  Describing or restricting the encoding does not seem
to be related.

Nit: In 4742bis, the sentence "How the NETCONF Server extracts the
SSH user name from the SSH layer is implementation-dependent."
should not use a hyphen.  (I guess that's "MUST NOT use" ;^)

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Mar 2011 15:14:25 +0100 (CET)

Phil Shafer <[email-masked]> wrote:
> What is [1]?

[1] is the XML spec, so section 2.2 is
http://www.w3.org/TR/REC-xml/#charsets.

The sentence simply says that the username must not contain characters
that cannot be encoded in XML.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Wed, 9 Mar 2011 10:02:15 -0500

>that cannot be encoded in XML.

So we are making control characters illegal in user names?  I'm
not saying this is common, but I don't really want to take the
"well no one would _ever_ do that" attitude that prevented XML
from encoding control characters.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Mar 2011 17:02:34 +0100 (CET)

> from encoding control characters.

We have to play along with the rules invented by XML.  YANG does the
same thing.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 9 Mar 2011 08:08:09 -0800

Hi,

I think the restriction to limit user names to XML is OK.
We have a practical need to return user names for data in 3 standard
YANG modules already (2 still I-Ds).

In reality, there are so many applications that expect ASCII,
that it is difficult to even use UTF-8 chars in user names.
(Even some of the email addresses on this thread cannot use their
real spelling because of non-ASCII chars in them.)

Andy

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Wednesday, March 09, 2011 7:02 AM
To: Martin Bjorklund
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT) 

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 9 Mar 2011 10:08:16 -0800

Hi -

> From: "Phil Shafer" <[email-masked]>
> To: "Juergen Schoenwaelder" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
> Sent: Wednesday, March 09, 2011 5:34 AM
> Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)
>
...

Since these things would need to be matched, I tried to find where the
document spells out which normalization form is to be used.  I couldn't.
Did I miss something, or is the choice of normalization form left to the
implementors' imaginations?

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Mar 2011 21:25:55 +0100

> We have to play along with the rules invented by XML.  YANG does the

RFC 6020 says for the string data type:

   The string built-in type represents human-readable strings in YANG.
   Legal characters are tab, carriage return, line feed, and the legal
   characters of Unicode and ISO/IEC 10646 [ISO.10646]:

     ;; any Unicode character, excluding the surrogate blocks,
     ;; FFFE, and FFFF.
     string = *char
     char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD /
            %x10000-10FFFF

Is this 100% identical with what section 2.2 in [1] says? Since we
need to represent user names in YANG data models, we better make sure
this is doable without any complications.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Mar 2011 21:34:36 +0100

> implementors' imaginations?

<http://en.wikipedia.org/wiki/Unicode_equivalence> makes an
interesting recommendation that applications should preserve input
code points, only normalizing strings to the application's preferred
normal form for internal use only...

YANG does not force a normalization for the string type. It tries to
preserve them.

/js

---

From: "David Harrington" <[email-masked]>
Date: Wed, 9 Mar 2011 21:36:21 +0100

Hi,

I would like the (implicitly) in your response made explicit in the
document. 

I don't care that much whether this is specified as cross-transport
(i.e., in 4741bis) or per-transport (i.e. in 4742bis), but the
expectation should be documented.

dbh

> From: Martin Bjorklund [mailto:[email-masked]] 
> Sent: Wednesday, March 09, 2011 9:01 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Netconf] David Harrington's Discuss on

---

From: "David Harrington" <[email-masked]>
Date: Wed, 9 Mar 2011 22:01:36 +0100

Hi,

The crux of my discuss for 4741bis is that the netconf username will
be used by other things, such as CLIs, scripts, YANG, etc. and should
be in a format compatible with expected usage.
Expected usage appears to include embedding in XML documents, YANG
data models, native CLI handling, and matching (such as during lookup
in an access control system, whether proprietary or standardized).

I don't care whether the format of the netconf username is compatible
with section 2.2 of the XML specification, or with RFC 6020's string
data type, or ascii, or some other choice of the WG (although I
recommend using something standardized).

The (implicit) expectation should be made explicit in documentation
(and I think 4741bis makes the most sense to define the expected
format of a netconf username).

dbh

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, March 09, 2011 9:26 PM
> To: Martin Bjorklund
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Mar 2011 22:09:55 +0100 (CET)

Hi David,

> in an access control system, whether proprietary or standardized).

Agreed.

> format of a netconf username).

Would the following change resolve your DISCUSS?

OLD:

NEW:

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 9 Mar 2011 19:51:35 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "Phil Shafer" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
> Sent: Wednesday, March 09, 2011 12:34 PM

Let me re-ask the question with an example.
How are implementations required to treat the sequence
U+0061 U+0308 and  U+00E4 in user names?  Are they
identical, different, or is the answer implementation-specific?
(Both are "ä".)

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Mar 2011 08:03:05 +0100

> identical, different, or is the answer implementation-specific?

See why I avoid these characters. ;-) I see your point but whatever
the answer is, it really needs to be answered for the YANG string data
type.

Right now, 4741bis does not really do anything with the user name,
except requiring that transports provide one. I know, this is a rather
poor excuse. Well, that said, there are of course protocol functions
that do comparisons like the subtree filter. I guess we need to check
what XPATH has to say about this - well xpath 2.0 provides
normalization functions and requires NFC. Is there some sort of a
guideline which normalization form is preferred in IETF standards?

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 10 Mar 2011 15:36:00 +0100

Does it sound correct if 4741bis says:
"The algorithm used to derive the username is transport protocol
specific"

and 4742bis says:
"How the NETCONF Server extracts the user name from the SSH layer is
implementation-dependent. " ?

How can NETCONF SSH transport can . . .

"explain how a NETCONF username is derived from the authentication 
mechanisms supported by the transport protocol." ?

Mehmet 

PS: I think we don't need to put IESG always on CC.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Martin Bjorklund
> Sent: Wednesday, March 09, 2011 10:10 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-
> netconf-4741bis-09: (with DISCUSS and COMMENT)
> 
> Hi David,
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Thu, 10 Mar 2011 15:46:13 +0100

But this way... it may take a long time before DBH sees it.
At least we need to copy him explicitly.
Adding IESG too creates an extra chance that he sees it.

Bert

On 3/10/11 3:36 PM, Ersue, Mehmet (NSN - DE/Munich) wrote:
>> "David Harrington"<[email-masked]>  wrote:
>>> Hi,
>>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Mar 2011 16:40:48 +0100

> mechanisms supported by the transport protocol." ?

4741bis says a NETCONF transport must provide a username. I think this
is about all 4741bis can do (plus the addition to say that usernames
must be XML representable, but there is text in the making for this so
lets consider this point addressed).

With SSH, what typically happens, is that you 

(a) run a certain authentication protocol within SSH that may
(b) interface with external AAA services and that typically
(c) results into a notion of a system account

and the username NETCONF implementations pick is likely the notion of
a system account (or system "user") than the identity used in the SSH
authentication protocol. While for many case the step from (a) to (b)
and from (b) to (c) is an identity transform, this does not
necessarily have to be this way. This was the core of the discussion
of one of the IETF meetings.

The intention of 4742bis (at least as I understand things) is to say
the NETCONF transport picks the username from whatever is the result
of (c) or (b) if step (c) does not exist or (a) if steps (b) and (b)
do not exist.

Is this is a reasonable description of the situation?

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 10 Mar 2011 18:56:39 +0100

Juergen,

> Is this is a reasonable description of the situation?

It is at least the way you interpret it from the pov. of 
an implementer.

> NETCONF transport protocols therefore MUST

However, I don't think it is a good idea to say that the 
"SSH transport MUST explain how a NETCONF username is derived 
from the authentication mechanisms."

This is a very hard "MUST" which SSH transport specification 
cannot provide. 

The only thing SSH transport specification does say is:
"How the NETCONF Server extracts the user name from the SSH layer is
implementation-dependent."

What SSH transport document could say is e.g. (but not much more):

"   There is no standard way for an application running on an SSH
    server to determine a user name for the current session.  How the
    NETCONF Server extracts the user name from the SSH layer is
    therefore implementation-dependent. 

    The user name provided by the SSH implementation will be made 
    available to NETCONF message layer as NETCONF username without 
    any modification. Any transformations applied to the authenticated 
    user name by the SSH layer are outside the scope of this document."

However this would be insufficient with the MUST statement in 4741bis 
above. IMO 4741bis shouldn't impose to 4742bis something, which 4742bis 
cannot provide.

Mehmet 

> From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Thursday, March 10, 2011 4:41 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: ext Martin Bjorklund; [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Mar 2011 19:33:03 +0100

> above. IMO 4741bis shouldn't impose to 4742bis something, which 4742bis 

I give up. I meanwhile do not know anymore what the text says since I
fail to be able to track which changes have been agreed and which ones
not.

I maintain the statement that a NETCONF transport that does not
provide a username is unacceptable - or we give up on access
control. The issue is also not that SSH does not provide a username -
the issue is that documenting exactly how this is done without
restricting SSH authentication protocols and/or AAA systems is
difficult. Since the easy way forward of declaring this implementation
dependent does not seem to fly, someone has to cast creative text that
says a bit more than "this implementation dependent" without saying
too much. This is what we should discuss, not the MUST provide
username requirement in 4741bis.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 10 Mar 2011 10:56:24 -0800

Hi,

I agree with Juergen that 4741bis (and even 4742bis) does not
need to define exactly how a user-name must be derived from each transport
layer that NETCONF uses.  The specific user name values are not relevant
to the monitoring or NACM modules.

Operators will need to be familiar with the user name details within
their own network, but they control the creation of user accounts.
IMO, this is a site-specific detail, outside the scope of the 
combination of protocols in use.

There are lots of site-specific details outside the scope
of NETCONF and SSH standards (like server configuration).

It seems like SSH should define properties it exports to higher
layers, such as a user name.  Having NETCONF define how SSH must work
does not seem right.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, March 10, 2011 10:33 AM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 10 Mar 2011 11:01:41 -0800

Hi -

> To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
> Cc: <[email-masked]>
...
> > cannot provide

Let's get real.  Even though "implementation-dependent" isn't the most
satisfying way of describing how something happens, there are times
(and this is probably one) where it's the only reasonable way, unless
one is willing to accept that any effort to further specify matters will almost
inevitably end up over-constraining implementations.

...
> control.

Agreed.  "Implementation-dependent" may be distasteful, but the
alternative of abandoning access control would be throwing the
baby out with the bathwater.

>  The issue is also not that SSH does not provide a username -

I agree that the username requirement is not what should be
under discussion.  I reluctantly agree that if this group is unwilling to let
the implementation-dependent sleeping dog lie, the only alternative is
to spell out and get agreement on the "blessed" set of implementation-
dependent things that might be done to produce a username.  And I
strongly agree that that exercise will need to take care not to say too
much - an over-specification here could cause as much trouble as the
under-specification that caused the mess in the first place.

Randy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 10 Mar 2011 21:26:12 +0100

Hi Juergen,

we are all trying to get the two bis drafts one step further.

> provide a username is unacceptable - or we give up on access control. 

Nobody said it shouldn't.

> difficult. 

Yes, it is difficult to describe what SSH transport is not aware 
of. 

> Since the easy way forward of declaring this implementation
> dependent does not seem to fly, someone has to cast creative 
> text that says a bit more than "this implementation dependent" 
> without saying too much. 

Fine, see below for a proposal.

> This is what we should discuss, not the MUST provide username 
requirement in 4741bis.

Actually, the text Martin proposed imposes much more than "provide 
username". 
The point is that the SSH transport does not know how the NETCONF 
username is derived from the authentication mechanisms. IOW 
SSH transport does not know how things are done in lower layers.

Now trying a compromise:

The proposed text (below) for 4742bis is probably not bad for 
the purpose and for what SSH transport can state:

<First the implementation dependent etc...>

"The user name provided by the SSH implementation will be made
available to NETCONF message layer as NETCONF username without
any modification. Any transformations applied to the authenticated 
user name by the SSH layer are outside the scope of this document."

If you guys know anything what can be said additionally, please 
let me know.

With this, we still have kind of mismatch between the proposed texts 
for 4741bis and 4742bis. 
As 4742bis cannot fulfil the MUST statement, SHOULD would be probably
more appropriate.

Cheers, 
Mehmet 

> Sent: Thursday, March 10, 2011 7:33 PM

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Mar 2011 21:45:48 +0100 (CET)

> username requirement in 4741bis.

+1 to this!!

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 10 Mar 2011 15:30:14 -0500

>satisfying way of describing how something happens, there are times

Amen.  Maybe we should just ape the words from SFTP (which also
uses SSH as a substrate):

http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13

   This protocol assumes that it runs over a secure channel, such as a
   channel in [RFC4251], that the server has already authenticated the
   client, and that the identity of the client user is available to the
   protocol.

It talks about restricting owner and group fields to UTF-8, but
only when it's talking about transmitting these fields over the
wire.

I'd be happy to change our current text to something patterned
after the above.  Terming it an assumption may be more palatable
than calling it "implementation dependent".

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Mar 2011 22:25:17 +0100 (CET)

> than calling it "implementation dependent".

I assume you want to put this text in 4741bis, instead of the "MUST
explain how a username..." text?  (Or did you really mean 4742bis?
that's where the "implementation dependent" text is...)

I don't think it helps if we replace 2119 language with "assume".  It
seems to me that this "assume" really is a MUST.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 10 Mar 2011 16:56:22 -0500

>seems to me that this "assume" really is a MUST.

My take is that we're spending more time on this than an issue this
minor needs.  If this language is good enough to SFTP, it should
be good enough for us.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Mar 2011 00:48:16 +0100 (CET)

> minor needs.  If this language is good enough to SFTP, it should

The problem is that your text and the current text both say the same
thing, so your text does not solve the problem.  The both say that a
NETCONF transport must provide a user name.

But the problem is in 4742bis that we can't really specify *how* SSH
provides a user name, since it depends on the authentication protocol
used.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 10 Mar 2011 20:55:09 -0500

>provides a user name, since it depends on the authentication protocol

This is because it's implementation dependent, which is what the
current text says.  I don't see this as a problem, since it is
completely internal to the implementation.

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 10 Mar 2011 18:48:45 -0800

Hi -

> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, March 10, 2011 3:48 PM
...
> provides a user name, since it depends on the authentication protocol

There are apparently different expectations of what satisfies
a requirement to explain how something is done.  For me,
"it's implementation dependent" is a perfectly reasonable way
to address such a requirement when the realities of deployed
infrastructure don't permit a more detailed description.  Ugly?
Yes, but the alternative is to "fix" SSH, and that seems far
outside this group's charter.

Randy

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 11 Mar 2011 10:16:22 +0100

WG, please express your opinion on the below text changes

On 3/10/11 7:33 PM, Juergen Schoenwaelder wrote:

..snip....
> fail to be able to track which changes have been agreed and which ones
.. snip ...
> /js

Would be good to see if we have WG concensus... but I think we do.
We discussed this matter extensively in one of our IETF sessions, and we
had major (not full) consensus that the "implementation dependent" is
what we wanted.

We may not yet have OK from DBH, but we (WG chairs) will start work on that
together with our AD.

The current proposed text changes are:

For 4741bis, add one sentence:
    The username is a string of characters that match the "Char"
    production from section 2.2 of [1].

OLD:

NEW:

for rfc4742bis, the proposed change is:

OLD:
    How the NETCONF Server extracts the user name from the SSH layer is
    therefore implementation-dependent.
NEW:
    There is no standard way for an application running on an SSH
    server to determine a user name for the current session.  How the
    NETCONF Server extracts the user name from the SSH layer is
    therefore implementation-dependent.
    The user name provided by the SSH implementation will be made
    available to NETCONF message layer as NETCONF username without
    any modification. Any transformations applied to the authenticated
    user name by the SSH layer are outside the scope of this document.

Bert and Mehmet

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Mar 2011 10:57:47 +0100 (CET)

Hi,

>    therefore implementation-dependent.

It is obvious that *how* the username is passed from the SSH layer to
the application is implementation dependent, since it amongst other
things depends on the programming langauge used.

But the interesting thing that we want to try to capture is *what* the
user name is.  A naive (incorrect) attempt would be to say that the
username passed from SSH to NETCONF is the "user name" field in the
SSH_MSG_USERAUTH_REQUEST message.  But this is not correct, since
e.g. GSSAPI says that this field may be empty, and the real user name
will fall out from the GSSAPI procedure.

I suggest this simpler text:

OLD:

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

NEW:

    The user name provided by the SSH layer will be made
    available to NETCONF message layer as NETCONF username without
    any modification. Any transformations applied to the authenticated
    user name by the SSH layer are outside the scope of this document.

/martin

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 11 Mar 2011 11:24:01 +0100

Hi Martin,

the text is indeed a bit redundant could be more short.

However, I think the statement with "implementation dependent" 
is substantial from the NETCONF transport specification pov.
I don't mind to keep it in any form as explanation for ...

>     any modification.

Cheers, 
Mehmet 

> Sent: Friday, March 11, 2011 10:58 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: "t.petch" <[email-masked]>
Date: Fri, 11 Mar 2011 11:10:04 +0100

----- Original Message ----- 
From: "Phil Shafer" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 10, 2011 10:56 PM

> minor needs.  If this language is good enough to SFTP, it should

True but not relevant.  It has to be good enough to clear the IESG
DISCUSS and they have a different mind set to us, which we 
have to embrace (if you weren't part of the similar discussions
in ISMS, you haven't lived:-(

For myself, implementation dependent is fine (if imperfect).

Tom Petch

---

From: Phil Shafer <[email-masked]>
Date: Fri, 11 Mar 2011 07:33:22 -0500

>    user name by the SSH layer are outside the scope of this document.

These sentences seem to say the opposites, that is can be changed
and that changes are outside the scope of this document.

In fact if the user name contains control characters, it must be
modified to allow XML to handle it.  Also the user name provided
by the SSH layer (the "user name" field in the SSH_MSG_USERAUTH_REQUEST
message) may be overridden by the user name returned by RADIUS.

Or by "ssh layer" are you meaning sshd/login/pam/etc?

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Mar 2011 14:08:58 +0100 (CET)

Phil Shafer <[email-masked]> wrote:
> modified to allow XML to handle it.

Do you want to add text to handle this?

> Also the user name provided

Yes.  I.e. I don't want to go into what can happen down below, I want
to say as little as possible.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Fri, 11 Mar 2011 07:55:18 -0500

>to say as little as possible.

So you'd need to define the term "ssh layer".  Or say "underlaying
system software".  Or just say "implementation dependent" ;^)

Thanks,
 Phil

---

From: "David Harrington" <[email-masked]>
Date: Fri, 11 Mar 2011 15:54:29 -0500

Hi Martin,

That doesn't quite satisfy my DISCUSS, but we're getting close.

> > in an access control system, whether proprietary or standardized).

1) Randy has raised a good point about one of the expected usages -
matching.
I think the normalization issue will need to be addressed.
Access control specifications must know what the acceptable values and
matching algorithms are for the netconf username. 
It makes sense for that to be defined in 4741bis.

2) The second part of your (old and new) text says that netconf
transport protocol specs MUST explain how they derive the netconf
username from the authentication mechanisms used. I think that
requirement will be problmeatic, because most IETF security protocols,
like SSH and TLS, are typically required to be able to support a range
of existing authentication mechanisms and be able to support new
authentication mechanisms as they are developed (algorithm-agility). 

I recommend that 4741bis state that it the responsibility of the
netconf transport implementation (as compared to the security
implementation that the netconf transport uses) to provide a netconf
username in a format that meets the requirements (that the WG is
currently deciding on) regarding character set, normalization, etc.
How the transport protocol derives that from the authentication
mechanism used is implementation-dependent. 

I think the transport protocol specification (e.g., 4742bis) should
specify a **predictable** value-format for the username it provides,
so an operator and/or access control implementation can know what to
expect for the username format and value. 
How it derives that from the output of SSH is
implementation-dependent.

The discussion in 4741bis only talks about what the transport
protocols provide as the result of the authentication process - from
incoming connections presumably. The username hides the details of the
authentication parameters.
What happens if a netconf application wants to send a message, and no
session exists yet? what information needs to be provided to the
specific transport model to create the session? 4741bis and specific
transport protocol specs should set some ground rules about what the
transport expects to be provided (needs to have provided), such as a
netconf username in a particular format, for creating sessions. 

Hope this helps,
dbh

> Sent: Wednesday, March 09, 2011 4:10 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked];

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Mar 2011 22:52:45 +0100

On Fri, Mar 11, 2011 at 03:54:29PM -0500, David Harrington wrote:

[...]
 
I like to hear from an _operator_ that SSH is causing them problems to
deliver predicatable user names, making access control unpredictable.
SSH came along in the 1995s and since then it is heavily used on all
Unix-based systems and since a large number of years (10?) as well on
non-Unix platforms, routers, switches access points, ... There is a
significant deployed proof that "it works", many mission critical
systems that also do access control (all Unix systems do) have been
built around it. Do you really believe all this is fundamentally
broken since SSH does not provide predictable user names? Seriously?

/js

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Tue, 15 Mar 2011 10:39:04 +0100

David,

as you do know I think (at least my memory says that you were
in the NETCONF session where this was discussed), the WG
has extensively discussed the issue of "how to derive/extract
the username from the SSH layer". We then had major consensus
(not full consensus, I believe you indeed objected somewhat)
that "implementation dependent" was the way to go.

Over the last few weeks, the WG has also discussed your DISCUSS,
and yet more people have expressed that "implementation dependent"
is the best we can do in this situation.

If anything needs to be done, then it seems that SSH needs to
be "fixed". See wg email thread extracts below.

However, we have tried to address your DISCUSS with the
following text changes, so that at least at the NETCONF
level we do as much as we can.

PLEASE reconsider your DISCUSS and see if you can clear it
with the following changes that have been posted in new
revisions of the 4741bis and 4742bis documents:

For 4741bis, add one sentence and change "MUST explain how" into
"MUST provide". Exact change:

OLD:

NEW:

    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 username is a string of characters that match
    the "Char" production from section 2.2 of [W3C.REC-xml-20001006] .
    The algorithm used to derive the username is transport protocol
    specific and in addition specific to the authentication mechanism
    used by the transport protocol.  The transport protocol MUST provide
    a username to be used by the other NETCONF layers.

OLD:

NEW:
     The username provided by the SSH implementation 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 SSH session MUST be
dropped. Any transformations applied to the authenticated identity
of the SSH client made by the SSH server (e.g., via authentication
services or mappings to system accounts) are outside the scope of
this document.

We have also addressed your other discuss points and most of your remarks/comments.
The complete diffs are here:
http://tools.ietf.org/wg/netconf/draft-ietf-netconf-4741bis/draft-ietf-netconf-4741bis-10-from-09.diff.html
http://tools.ietf.org/wg/netconf/draft-ietf-netconf-rfc4742bis/draft-ietf-netconf-rfc4742bis-08-from-07.diff.html

Bert Wijnen
Document shepherd 4741bis
Mehmet Ersue
Document shepherd 4742bis

-------- Original Message --------
Subject: 	Re: [Netconf] David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)
Date: 	Thu, 10 Mar 2011 11:01:41 -0800
From: 	Randy Presuhn <[email-masked]>
To: 	<[email-masked]>

Hi -

>  From: "Juergen Schoenwaelder"<[email-masked]>
>  To: "Ersue, Mehmet (NSN - DE/Munich)"<[email-masked]>
>  Cc:<[email-masked]>
...

...

Randy

-----In a later email (dated 3/11/2011) Randy further stated:

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 Mar 2011 11:50:23 +0100

> the answer is, it really needs to be answered for the YANG string data

I don't think the YANG string type has to be changed. As long as we deal with strings inside NETCONF protocol messages, everything is fine. The present problem is with strings that are obtained via other channels and this is out of scope for YANG.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 15 Mar 2011 12:54:21 +0100

Hi All,

unfortunately there are two bugs in 4742bis v08, which need 
to be added to the RFC Editors notes. I assume Dan will change 
the IESG write-up page soon.

Change 1:
======
Appendix A) from v07 got somehow deleted and needs to be 
added again.

Change 2:
======
The text in Section 3.1 contains MUST statements copied from
4741 and is inappropriate. As requested by Alexey we had 
changed the formulation but forgot to update the Write-up page.

--------------------------------------------------------------------

RFC Editors notes for draft-ietf-netconf-rfc4742bis-08.txt:

OLD (v08):
[empty]

NEW:
Appendix A. Changes from RFC 4742	 		
				
	This section lists major changes between this document and RFC
4742.			
				
	o Introduced the new Chunked Framing Mechanism to solve known

	security issues with the EOM framing.			
				
	o Extended text in Security Considerations, added text on EOM

	issues.			
				
	o Added examples to show new chunked encoding properly,
highlighted			
	the location of new lines.			
				
	o Stated that the extraction of the SSH user name by a NETCONF

	server is implementation-dependent.			
				
	o Changed use of the terms client/server, manager/agent to SSH

	client/server and NETCONF client/server.			
				
	o Consistently used the term operation, instead of command or

	message.			
				
	o Integrated previously-approved errata from			
	http://rfc-editor.org/errata_search.php?rfc=4742

3. Section 3.1.

OLD (v08):
   As specified in [I-D.ietf-netconf-4741bis] the NETCONF server MUST
   indicate its capabilities by sending an XML document containing a
   <hello> element as soon as the NETCONF session is established.  The
   NETCONF client can parse this message to determine which NETCONF
   capabilities are supported by the NETCONF server.

   As [I-D.ietf-netconf-4741bis] states the NETCONF client must also
   send an XML document containing a <hello> element to indicate the
   NETCONF client's capabilities to the NETCONF server.  The document
   containing the <hello> element MUST be the first XML document that
   the NETCONF client sends after the NETCONF session is established.

NEW:
   As specified in [I-D.ietf-netconf-4741bis] the NETCONF server
indicates its 
   capabilities by sending an XML document containing a <hello> element
as 
   soon as the NETCONF session is established.  The NETCONF client can
parse 
   this message to determine which NETCONF capabilities are supported by
the 
   NETCONF server.

   As [I-D.ietf-netconf-4741bis] further specifies, the NETCONF client
also 
   sends an XML document containing a <hello> element to indicate the
NETCONF 
   client's capabilities to the NETCONF server.  The document containing
the 
   <hello> element is the first XML document that the NETCONF client
sends 
   after the NETCONF session is established.

Cheers, 
Mehmet 

> Behalf Of ext Bert (IETF) Wijnen
> Sent: Tuesday, March 15, 2011 10:39 AM
> To: David Harrington
> Cc: netconf; The IESG; [email-masked]; draft-ietf-
> [email-masked]
> match
http://tools.ietf.org/wg/netconf/draft-ietf-netconf-4741bis/draft-ietf-
> netconf-4741bis-10-from-09.diff.html
> http://tools.ietf.org/wg/netconf/draft-ietf-netconf-rfc4742bis/draft-
> ietf-netconf-rfc4742bis-08-from-07.diff.html
> 
> Bert Wijnen
> >  >  "How the NETCONF Server extracts the user name from the SSH
layer
> is
> >  >      server to determine a user name for the current session.
How
> the

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 15 Mar 2011 14:30:41 -0800

Hi -

> From: "Ladislav Lhotka" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Tuesday, March 15, 2011 2:50 AM
> I don't think the YANG string type has to be changed. As long as
> we deal with strings inside NETCONF protocol messages,
> everything is fine. The present problem is with strings that are
> obtained via other channels and this is out of scope for YANG.

"Other channels" isn't the question.
Is the a string consisting of the sequence U+0061 U+0308 equal
to one consisting of  U+00E4?  Are two configurations which differ
only in this way "the same" configuration?

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 15 Mar 2011 22:35:32 +0100 (CET)

Hi,

[pruning the send list a bit]

"Randy Presuhn" <[email-masked]> wrote:
> > Cc: "Randy Presuhn" <[email-masked]>; <[email-masked]>;
> > <[email-masked]>;
> > Subject: Re: [Netconf] David Harrington's Discuss
> > ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)
> >

How does this work with normal SSH and e.g. RADIUS?

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 15 Mar 2011 15:09:46 -0800

Hi -

> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, March 15, 2011 1:35 PM
...
> How does this work with normal SSH and e.g. RADIUS?

I repeat, "other channels" isn't the question.

But to answer *your* question,  RFC 6065 (the isms AAA  / VACM
integration) would treat these two sequences as *not* identical, if that
was what the AAA infrastructure considered to be the user name.  I'm
*not* going to argue that that is "right".  In many ways it's quite broken,
but it's a consequence of how Unicode support happened in
SNMP-land, where normalization would have to have been done by
whatever entity provisioned things in the first place.  Making it 
"un-broken" there would have required breaking too many other things.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 15 Mar 2011 23:16:56 +0100 (CET)

"Randy Presuhn" <[email-masked]> wrote:
> was what the AAA infrastructure considered to be the user name.

I was thinking about e.g. a CLI user that presents a user name to
SSH, and SSH uses RADIUS to authenticate.  Will RADIUS perform any
normalization?  I suppose not.  Then I don't see why NETCONF would
impose a normalization procedure.  So I think that these two sequences
also in NETCONF would be treated as different.  Do you think that this
is a problem?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Mar 2011 15:18:37 -0700

Hi,

I think Martin is asking why you think this is a NETCONF-specific issue.
I would think string normalization of UTF-8 is a generic problem, and not
specific to NETCONF whatsoever.  Why would a NETCONF server do some 1-off
special transformation, instead of following rules written for every
protocol?

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Presuhn
Sent: Tuesday, March 15, 2011 4:10 PM
To: [email-masked]
Subject: Re: [Netconf] David Harrington's Discuss ondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)

Hi -

...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 15 Mar 2011 16:15:35 -0800

Hi -

> Sent: Tuesday, March 15, 2011 2:16 PM
...
> also in NETCONF would be treated as different.  Do you think that this

It needs to be a conscious decision.

The bottom line is that "Schönwälder" can be represented in UTF-8
by four different byte sequences, and user interfaces don't typically
give users much (if any) control over which one is used.  It doesn't
take too much imagination to think up difficulties if a system
considers all four to be different.  Of course, one might say that that's
an acceptable trade-off.  It just needs to be a conscious design
decision.

I don't know specifically about RADIUS, but, for example, RFC 5802
is quite explicit in its use of normalization forms.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Mar 2011 08:18:59 +0100

> only in this way "the same" configuration?

Neither XML 1.0 nor YANG assumes any character model normalization, so IMO the two sequences are different.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Mar 2011 09:04:59 +0100

> an acceptable trade-off.  It just needs to be a conscious design

We already have a similar case with IP addresses: "::1" and "::0:1" are different as generic strings but equivalent as IPv6 addresses, and the "ipv6-address" type in RFC 6021 defines a unique canonical form. Therefore, it could be left to the access control module to define a type like "username" whose canonical form *may* involve character model normalization.
My point is that there is no need to change the definition of the "string" built-in type.

Lada 

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, 16 Mar 2011 09:16:03 +0100

Hi all,

I have taken off IESG and the log for 4741bis email addresses.
The topic was/is not part of any IESG DISCUSS or COMMENT.

I did this, because I am not sure this is a problem we should try to address
in this revision of rfc4741bis.
AS Lada stated, we can (for now at least I think) assume that two different
sequences are different users. As far as we know, it has not caused any
practical problem.

Perfect is the enemy of good (enough). I (personally) would not want to hold
up this document any longer in order to try and make sure everyone understands
the details of this thread/discussion and is able to express an informed
opinion on what to do.

I suggest that for now we conclude: it is a conscious OK to consider two
different character sequences as different usernames.

If anyone dis-agrees, please speak up asap.

Bert Wijnen
document shepherd

On 3/16/11 8:18 AM, Ladislav Lhotka wrote:
>>> From: "Ladislav Lhotka"<[email-masked]>
>>> To: "Juergen Schoenwaelder"<[email-masked]>
>>> Cc: "Randy Presuhn"<[email-masked]>;<[email-masked]>;<[email-masked]>;
>> <[email-masked]>;<[email-masked]>;<[email-masked]>

---

From: "t.petch" <[email-masked]>
Date: Wed, 16 Mar 2011 11:09:00 +0100

----- Original Message -----
From: "Bert (IETF) Wijnen" <[email-masked]>
To: "Randy Presuhn" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 16, 2011 9:16 AM

Hi all,

<tp>

I have no problem with Netconf not specifying a normalisation scheme for
Unicode.
As Juergen said, SSH has been working without it for years.

But... lack of normalisation is a vector for attack, phishing and such like, so
I think
that the fact that normalisation is not specified, that multiple user names
which
appear identical on display are in fact different, needs adding to the security
considerations, as, for example, in RFC3629.

Tom Petch
</tp>

Bert Wijnen
document shepherd

On 3/16/11 8:18 AM, Ladislav Lhotka wrote:
>>> Cc: "Randy
Presuhn"<[email-masked]>;<[email-masked]>;<draft-ietf-netconf-47
[email-masked]>;

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Mar 2011 12:19:03 +0100

On Wed, Mar 16, 2011 at 11:09:00AM +0100, t.petch wrote:
 
> I have no problem with Netconf not specifying a normalisation scheme
> for Unicode.  As Juergen said, SSH has been working without it for
> years.  But... lack of normalisation is a vector for attack,
> phishing and such like, so I think that the fact that normalisation
> is not specified, that multiple user names which appear identical on
> display are in fact different, needs adding to the security

But that text can go into the NACM document - NETCONF itself so far is
not using the username.

/js

---

From: "t.petch" <[email-masked]>
Date: Wed, 16 Mar 2011 17:14:37 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Bert (IETF) Wijnen" <[email-masked]>; "Randy Presuhn"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 16, 2011 12:19 PM
> But that text can go into the NACM document - NETCONF itself so far is

Weeelll, um.  RFC4742 does make reference to the extraction of the user name
and we have been having this DISCUSSion for the past fortnight, so I think that
4742bis should capture the current thinking with at least the first sentence
below
lest we have a rerun in six months time
eg

This memo does not specify any normalization of the user name as provided
by or to the SSH layer.  The same character display can be generated by
different UTF-8 byte sequences which may give rise to the potential for attacks.
See [RFC3629] for more details.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Mar 2011 18:36:45 +0100

On Wed, Mar 16, 2011 at 05:14:37PM +0100, t.petch wrote:
 
> This memo does not specify any normalization of the user name as
> provided by or to the SSH layer.  The same character display can be
> generated by different UTF-8 byte sequences which may give rise to
> the potential for attacks.  See [RFC3629] for more details.

This text would actually be wrong since there is no mandate whatsoever
that the username is encoded in UTF-8 when it is picked up.

Randy's comment concerned comparions. I maintain my position that
NETCONF, more precisely 4741bis and 4742bis, does not do any
comparisons of the username. NACM will do so if there is a risk of
"surprising" comparisions, it should be fine this in NACM.

If you have other concerns about the usage of XML encoded in UTF-8 in
NETCONF, you should start a new thread (and perhaps check that other
protocols using XML do explicitely deal with your concern).

/js

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 17 Mar 2011 10:59:25 -0700

>>>>> On Fri, 11 Mar 2011 22:52:45 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> Do you really believe all this is fundamentally broken since SSH
JS> does not provide predictable user names? Seriously?

Juergen,

Though I actually agree that this is likely a non-issue, I don't think
you can compare the past history of SSH with the new usages.  Most of
the previous SSH usage has *only* been for command-line logins where you
rarely need to know, once you're inside, what your user name is and even
if you do it likely wasn't needed by the global system.  IE, there was
never a set of configuration that needed to be pushed into every device
that should match everywhere such that 'bob' was 'bob' everywhere and
not 'b0b' somewhere else where the access control configuration settings
prevented him from operating on that device.

So, having said that, even though I'm not sure you can easily extrapolate
the past history forward into the future of netconf (and other protocols
leveraging SSH as a tunneling platform), I still don't think it's going
to be a problem.  And if it is, I think the implementations will likely
be fixed quickly.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Mar 2011 19:47:02 +0100

> prevented him from operating on that device.

I (like many others) happen to use SSH for lots of system
administration tasks, also often across domain boundaries, where
accounts have different names and all this works reasonably well
_because there are mechanisms to translate names_. If I setup RADIUS
to rewrite bob to b0b, then this is done for a reason. If I do not
want to remember that I have to authenticate as [email-masked], I
configure my client to do the translation automatically. The same goes
for the selection of keys and so on and so on.

If the resulting username (or account name for that matter) on one
device is bob and on another b0b, that this is something config can't
ignore. If you copy files across Unix systems, you better pay
attention to the owner names and or uids (depending on what you use
during the unpacking process). This is how it has been for a long time
and this will continue to be so, also with NETCONF access control
rules.

Back to the topic of the discussion: The claim was that the username
ending up on the server side is unpredictable. I believe this is not
correct. The username is predictable but the result of a potentially
complex transformation that is outside of the scope of NETCONF and
also outside the scope of SSH since it may involve authentication
systems external to SSH. And the reason we have these transformations
is the need to deal with real-world complexity, in particular when
dealing with domain boundaries. Pretenting this complexity does not
exist or even more ruling this out in a specification would in my view
have been a _major_ mistake.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Mar 2011 20:38:41 +0100

> have been a _major_ mistake.

+1.

In fact, since the user must already have logged in through SSH, it shouldn't be such a big deal for the server to find out who the user really is from the OS perspective. How this identity translates to NETCONF credentials is a different (and inherently system-dependent) matter.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 18 Mar 2011 00:49:48 +0100

Hi All,

the DISCUSSes have been already cleared. As Bert 
suggested please do not CC iesg for this discussion. 

Mehmet 

> Behalf Of ext Ladislav Lhotka
> Sent: Thursday, March 17, 2011 8:39 PM
> To: Juergen Schoenwaelder
> Cc: [email-masked]; [email-masked]; David
> Harrington; [email-masked]; [email-masked]
ondraft-ietf-netconf-
> 4741bis-09: (with DISCUSS and COMMENT)
> 
> 
> >>>>>>> On Fri, 11 Mar 2011 22:52:45 +0100, Juergen Schoenwaelder
> <[email-masked]> said:
> >>
> >> the previous SSH usage has *only* been for command-line logins
where
> you
> In fact, since the user must already have logged in through SSH, it
> shouldn't be such a big deal for the server to find out who the user
> really is from the OS perspective. How this identity translates to
> NETCONF credentials is a different (and inherently system-dependent)
> matter.
> 
> Lada
> 
> >
> > /js
> >
> > --

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 18 Mar 2011 09:37:19 +0100 (CET)

> But that text can go into the NACM document - NETCONF itself so far is

+1.  4741bis doesn't use it, and 6022 simply reports it.

/martin

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 18 Mar 2011 10:50:13 +0100

From the discussion on the below in which only a few have participated sofar,
we (WG chairs) conclude that we are done with 4741bis and that if any text
is needed to address this, then it would probably go into one of
the NACM documents, but not in 4741bis.

Both chairs (as technical contributors) also support this position.

Bert and Mehmet

On 3/16/11 9:16 AM, Bert (IETF) Wijnen wrote:

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 18 Mar 2011 07:33:04 -0700

>>>>> On Thu, 17 Mar 2011 19:47:02 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> Back to the topic of the discussion: The claim was that the username
JS> ending up on the server side is unpredictable. I believe this is not
JS> correct.

Trying to keep on topic (IE, ignoring the rest of the post):

I think there are two different parts of that statement.

  From a standards perspective: the user name isn't predictable, because
  nothing says it has to be.

  From a real world and implementation point of view: it is, because
  all the implementations behave the same way.

So, I agree it's a non-issue in the real-world and I support the current
text because I think it's sufficient.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 18 Mar 2011 07:33:40 -0700

>>>>> On Fri, 18 Mar 2011 00:49:48 +0100, "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]> said:

"M(> the DISCUSSes have been already cleared. As Bert 
"M(> suggested please do not CC iesg for this discussion. 

I hate it when I read the rest of the thread too late.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "t.petch" <[email-masked]>
Date: Fri, 18 Mar 2011 18:07:09 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Bert (IETF) Wijnen" <[email-masked]>; "Randy Presuhn"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 16, 2011 6:36 PM
> protocols using XML do explicitely deal with your concern).

Juergen

My primary concern, snipped from the extract above, is that the IESG
wanted us to specify normalisation, the rough consensus as I see it
is the Netconf does not do normalisation, therefore it would be good
to record that in the I-D, lest this discussion crops up again in 6 (and
12 and 18 and ...:-) months.

Tom Petch

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 18 Mar 2011 11:30:14 -0800

Hi -

> From: "t.petch" <[email-masked]>
> Sent: Friday, March 18, 2011 9:07 AM
> Subject: Re: [Netconf] David Harrington's Discussondraft-ietf-netconf-4741bis-09: (with DISCUSS and COMMENT)
...
...

I raised the normalization question; I don't recall seeing it in the IESG
comments.  Although I raised the issue, I don't support changing the
text at this time.  Even a seemingly innocuous statement like "NETCONF
doesn't do normalization" is at odds with what some people have said
on this list about their expectations, at least as far as *system* behaviour
is concerned.  Consequently I think the question needs additional
implementation and (un)interoperability experience before it can properly
be nailed down one way or the other, and this iteration should not be
delayed while that learning is taking place.

Randy

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 25 Mar 2011 10:07:43 +0100

OK, having had a few more "support" statements I conclude that we have
consensus to move forward and not make any more changes. I will
move forward and ask Dan to send the documents on to the RFC-Editor.

As you can see on the netconf list, Alexey still wanted 2 small (editorial)
changes, but they are considered IESG COMMENTS, and I think it is not
needed (as you can see in my response to Aleaxey).

Bert
document shepherd