Subject: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell

From: Alexey Melnikov <[email-masked]>
Date: Sun, 3 May 2009 13:33:02 +0200

Discuss:
I have a couple minor related points here:

5.3.  Establishing a Session

 [...]

   3.  The client will then invoke an SSH authentication service to
       authenticate the principal, such as that described in the SSH
       authentication protocol [RFC4252].

       1.  If the tmTransportAddress field contains a user-name followed
           by an '@' character (ASCII 0x40), that user-name string that
           should be presented to the ssh server as the "user name" for
           user authentication purposes.  If there is no user-name in
           the tmTransportAddress then the tmSecurityName should be used
           as the user-name.

I think this text needs to say which character set is used for representing user-name, and ideally it needs to describe or point
to syntax of allowed usernames.

7.  MIB Module Definition

 [...]

SnmpSSHAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1a"
    STATUS      current
    DESCRIPTION
        "Represents either a hostname or IP address, along with a port
         number and an optional username.

         The beginning of the address specification may contain a
         username followed by an '@' (ASCII character 0x40). This
         portion of the address will indicate the user name that should
         be used when authenticating to an SSH server. If missing, the
         SNMP securityName should be used. After the optional user name
         field and '@' character comes the hostname or IP address.

Same comment as above: can you add a reference to the document defining syntax of the username?

         The hostname must be encoded in ASCII, as specified in
         RFC3490 (Internationalizing Domain Names in Applications)

Same comment about syntax: I think a reference to the <host> ABNF production from RFC 3986 would be appropriate here.

Nit: I also think the text as written is not quite right.
Internationalized hostnames must be encoded using the algorithm
specified in RFC 3490, but for all ASCII hostnames there is no need
to send people to review RFC 3490. So I would suggest:

    The hostname is always in ASCII. Internationalized Domain Names
    MUST be encoded in ASCII, as specified in
    RFC3490 (Internationalizing Domain Names in Applications).

         followed by a colon ':' (ASCII character 0x3A) and a
         decimal port number in ASCII. The name SHOULD be fully
         qualified whenever possible.

Comment:
1.2.  Conventions

 [...]

   Sections requiring further editing are identified by [todo] markers
   in the text.  Points requiring further WG research and discussion are
   identified by [discuss] markers in the text.

Please delete this paragraph.
I can't find any [todo] or [discuss] markers in the document.

   Note to RFC Editor - if the previous paragraph and this note have not
   been removed, please send the document back to the editor to remove
   this.

:-)

2.  The Secure Shell Protocol

 [...]

   The client sends a service request once a secure transport layer
   connection has been established.  A second service request is sent
   after client authentication is complete.

For my education, can you point out where this is described in more details?

   This allows new protocols
   to be defined and coexist with the protocols listed above.

3.1.2.  Message Authentication

 [...]

   The SSH Transport Model determines from SSH the identity of the
   authenticated principal, and the type and address associated with an
   incoming message, and provides this information to SSH for an
   outgoing message.  The transport layer algorithms used to provide

"SSH transport layer algorithms ..."?

   authentication, data integrity and encryption SHOULD NOT be exposed
   to the SSH Transport Model layer.  The SNMPv3 WG deliberately avoided
   this and settled for an assertion by the security model that the
   requirements of securityLevel were met The SSH Transport Model has no

I think there is a missing dot before "The".

   mechanisms by which it can test whether an underlying SSH connection
   provides auth or priv, so the SSH Transport Model trusts that the
   underlying SSH connection has been properly configured to support
   authPriv security characteristics.

5.  Elements of Procedure

 [...]

   To simplify the elements of procedure, the release of state
   information is not always explicitly specified.  As a general rule,
   if state information is available when a message gets discarded, the
   message-state information should also be released, and if state
   information is available when a session is closed, the session state
   information should also be released.

I am wondering why 2 "should"s are not SHOULDs or even MUSTs.

5.1.  Procedures for an Incoming Message

 [...]

   4.  Create a tmStateReference cache for subsequent reference to the
       information.

          tmTransportDomain = snmpSSHDomain

          tmTransportAddress = the derived tmTransportAddress from step
          3.

I think this is step 2.

          tmSecurityName = The derived tmSecurityName from step 2.

And this is step 3.

5.3.  Establishing a Session

 [...]

   3.  The client will then invoke an SSH authentication service to
       authenticate the principal, such as that described in the SSH
       authentication protocol [RFC4252].

       1.  If the tmTransportAddress field contains a user-name followed
           by an '@' character (ASCII 0x40), that user-name string that

Remove the last "that"?

           should be presented to the ssh server as the "user name" for
           user authentication purposes.  If there is no user-name in
           the tmTransportAddress then the tmSecurityName should be used
           as the user-name.

7.  MIB Module Definition

 [...]

snmpSSHDomain OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION
        "The SNMP over SSH transport domain. The corresponding
         transport address is of type SnmpSSHAddress.

         When an SNMP entity uses the snmpSSHDomain transport
         model, it must be capable of accepting messages up to
         and including 8192 octets in size. Implementation of
         larger values is encouraged whenever possible.

         The securityName prefix to be associated with the
         snmpSSHDomain is 'ssh'. This prefix may be used by security
         models or other components to identify what secure transport

s/what/that ?

         infrastructure authenticated a securityName."

8.  Operational Considerations

   The SSH Transport Model will likely not work in conditions where
   access to the CLI has stopped working.

Can you elaborate on this a bit more?

   In situations where SNMP
   access has to work when the CLI has stopped working, a UDP transport
   model should be considered instead of the SSH Transport Model.

I don't think the reference to [RFC2865] (RADIUS) is normative.

---

From: "David Harrington" <[email-masked]>
Date: Tue, 5 May 2009 20:17:13 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alexey Melnikov
> Sent: Sunday, May 03, 2009 7:33 AM
> To: [email-masked]
> Cc: [email-masked]; 
> [email-masked]
> Subject: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell
> 
> Discuss:
> I think this text needs to say which character set is used 
> for representing user-name, and ideally it needs to describe or
point
> to syntax of allowed usernames.

Is this OK?

"The user name must be encoded in UTF-8 (per RFC4252)."
with a citation to [RFC4252] in the text,
with a REFERENCE clause to "RFC4252, The Secure Shell (SSH)
Authentication Protocol" in the SnmpSSHAddress definition

[...]
[...]
> 
> Same comment as above: can you add a reference to the 
> document defining syntax of the username?

yup.

> Same comment about syntax: I think a reference to the <host> 
> ABNF production from RFC 3986 would be appropriate here.

We have a REFERENCE to RFC3986 already.
If you want something more specific, can you provided suggested text?
I am a bit concerned about affecting readability with too many
references inside the DESCRIPTION clause. We have a REFERENCE clause.

Is this OK?

SnmpSSHAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1a"
    STATUS      current
    DESCRIPTION
        "Represents either a hostname or IP address, along with a port
         number and an optional user name.

         The beginning of the address specification may contain a
         user name followed by an '@' (US-ASCII character 0x40). This
         portion of the address will indicate the user name that
should
         be used when authenticating to an SSH server. The user name
         must be encoded in UTF-8 (per RFC4252). If missing, the
         SNMP securityName should be used. After the optional user
name
         field and '@' character comes the hostname or IP address.

         The hostname is always in US-ASCII (as per RFC3490),
         followed by a colon ':' (US-ASCII character 0x3A) and a
         decimal port number in US-ASCII. The name SHOULD be fully
         qualified whenever possible.

         An IPv4 address must be in dotted decimal format followed
         by a colon ':' (US-ASCII character 0x3A) and a decimal port
         number in US-ASCII.

         An IPv6 address must be in colon separated format, surrounded
         by square brackets ('[' US-ASCII character 0x5B and ']'
US-ASCII
         character 0x5D), followed by a colon ':' (US-ASCII character
         0x3A) and a decimal port number in US-ASCII.

         Values of this textual convention might not be directly
useable
         as transport-layer addressing information, and may require
         runtime resolution. As such, applications that write them
         must be prepared for handling errors if such values are
         not supported, or cannot be resolved (if resolution occurs
         at the time of the management operation).

         The DESCRIPTION clause of TransportAddress objects that may
         have snmpSSHAddress values must fully describe how (and
         when) such names are to be resolved to IP addresses and vice
         versa.

         This textual convention SHOULD NOT be used directly in
         object definitions since it restricts addresses to a
         specific format. However, if it is used, it MAY be used
         either on its own or in conjunction with
         TransportAddressType or TransportDomain as a pair.

         When this textual convention is used as a syntax of an
         index object, there may be issues with the limit of 128
         sub-identifiers specified in SMIv2, STD 58. It is 
         RECOMMENDED that all MIB documents using this textual 
         convention make explicit any limitations on index
         component lengths that management software must observe.
         This may be done either by including SIZE constraints on 
         the index components or by specifying applicable 
         constraints in the conceptual row DESCRIPTION clause or 
         in the surrounding documentation.
"
    REFERENCE 
      "RFC3490, Internationalizing Domain Names in Applications,
       RFC4252, The Secure Shell (SSH) Authentication Protocol,
       RFC3986, Uniform Resource Identifier (URI): Generic Syntax"
    SYNTAX      OCTET STRING (SIZE (1..255))

>    been removed, please send the document back to the editor to
remove

done.

> For my education, can you point out where this is described 

I think this refers to RFC4252 section 5.

> "SSH transport layer algorithms ..."?

OK.

> I think there is a missing dot before "The".

fixed.

> I am wondering why 2 "should"s are not SHOULDs or even MUSTs.

two reasons.
1) cut and paste from SNMPv3 standard documents.
2) the shoulds refer to implementation-specific processing that
happens strictly inside the SNMP entity, not on the wire.

>           tmSecurityName = The derived tmSecurityName from step 2.

fixed.

>            by an '@' character (ASCII 0x40), that user-name 

fixed.

>          models or other components to identify what secure
transport

"which" has the right meaning.

> Can you elaborate on this a bit more?

How's this?
The SSH Transport Model will likely not work in conditions where
      access to the CLI has stopped working. Remote access to a CLI is
often
      over TCP, which is also used by SSH. 
> I don't think the reference to [RFC2865] (RADIUS) is normative.

OK.

> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 May 2009 16:07:01 +0200

On Wed, May 06, 2009 at 11:57:45AM +0200, Alexey Melnikov wrote:

> I think this has implications on interoperability, so I am not entirely 
> convinced by your point # 2.
> Maybe you can give me an example of when it would be Ok not to discard 
> such state?

I do not see any interoperability issues; this text is really just a
hint that it is a good idea to release message specific state when the
message gets discarded. But protocol wise, an implementation would not
break anything if it would never release any message specific state
information (but such an implementation might run out of memory of
course and be an easy target for a DoS attack).

Since this same wording has worked in other SNMPv3 specifications
(i.e., RFC3412 and RFC3414, both part of STD62), I am not sure this
needs any changes.

/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: "David Harrington" <[email-masked]>
Date: Wed, 6 May 2009 13:04:18 -0400

Hi,

I think this is really about memory management. 

In SNMPv3 WG, we did not want to talk about getting rid of the cache
everytime we suggested discarding a message (and for ISMS, closing
sessions), so we put the advice about "releasing" the cache in one
general statement. While memory management is an implementation
detail, we wanted to assert that it was OK to release the memory at
specific points, so implementers would know the related state
information was no longer needed.

The SNMPv3 standard uses the same text, and we have never, to my
knowledge, had any implementer have problmes with implementing or with
interoperability as a result of this text.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Wednesday, May 06, 2009 10:48 AM
> To: Juergen Schoenwaelder
> Cc: David Harrington; [email-masked]; 
> [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-secshell
> 
> Juergen Schoenwaelder wrote:
> 
> Juergen,
> Your response makes me think that I don't really understand 
> what is the 
> meaning of "release" is in this case.
> I understood "release" as "don't use this information again, it is 
> invalid". I wasn't thinking about "release" as an advice about
memory 
> management.
> Which one is it?
> Thanks,
> Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 06 May 2009 10:57:45 +0100

Hi David,
My comments inline:

David Harrington wrote:

>>for representing user-name, and ideally it needs to describe or point
>>    
>>
Yes, this would work.

>If you want something more specific, can you provided suggested text?
See my corrections to your text, othetwise it looks fine.

>         The hostname is always in US-ASCII (as per RFC3490),
I was trying to hint at that, but RFC 3490 is not a good reference in 
this case: it defines both Internationalized domain names (in Unicode) 
and their US-ASCII encoding.
I think RFC 1033 (Section "Names") would be a better reference, unless 
you know a newer one.
So I suggest something like the following:

   The hostname is always in US-ASCII (as per 1033), Internationalized hostnames
   are encoded in US-ASCII as specified in RFC 3490. The hostname ...

>         Values of this textual convention might not be directly useable
Maybe add RFC 1033 to this list.

 [...]

 [...]

>"which" has the right meaning.
Ok.

>      The SSH Transport Model will likely not work in conditions where
I think inserting "remote" here would be even better.

>      access to the CLI has stopped working. Remote access to a CLI is often
Ok, I think this is clearer.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 06 May 2009 15:48:24 +0100

>(i.e., RFC3412 and RFC3414, both part of STD62), I am not sure this
Juergen,
Your response makes me think that I don't really understand what is the 
meaning of "release" is in this case.
I understood "release" as "don't use this information again, it is 
invalid". I wasn't thinking about "release" as an advice about memory 
management.
Which one is it?

Thanks,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 06 May 2009 19:07:12 +0100

>interoperability as a result of this text.
Ok, I've updated my COMMENT in the id-tracker.
I think it would have been nice if the text is more clearer that it 
talks about memory management and nothing else, but this is only a 
non-blocking comment.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 May 2009 10:46:48 -0700

Hi -

> From: "Alexey Melnikov" <[email-masked]>
> To: "Juergen Schoenwaelder" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Wednesday, May 06, 2009 7:48 AM
...
> invalid". I wasn't thinking about "release" as an advice about memory 

When this text was written, we were thinking about memory management.

It comes from a time when did not yet have agreement about whether
the procedures should be described in terms of APIs.  We did not want
to constrain implementation technologies, but it was felt that this could
be helpful to those writing new implementations.

Randy