Subject: [Isms] my review of: draft-ietf-isms-secshell-08.txt

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 9 Aug 2007 12:17:13 +0200

Some of these are NITs, I know that.

- I think the abstract should also mention that there is a MIB module
  defined in this document.

- I think the last para of sect 1.2 can/should be removed, or at least
the
  RFC-Editor should be instructed to do so.

- Sect 1.4

      The work will address ...

      The work will include ...

  Maybe better: This document addresses ...
                This document includes/defines ...

- sect 5.1 and 5.1
  I assume that SSH_MSG_USERAUTH_REQUEST and SSH_MSG_CHANNEL_DATA
  are specified somewhere in the SSH RFC(s)? Maybe a citation to
  such RFC(s) is useful at these points.

- top of page 15:
      45 Extract any implementation-specific parameters from the LCD
      6) Pass the wholeMessage to SSH for encapsulation in an
      SSH_MSG_CHANNEL_DATA message.

  what is "45"? Should that be "5)"
  But the whole first sentence seems to not belong here?

- Should we root this MIB module under snmpModules? 
  see my arguments in my review of the MIB module in
  draft-ietf-isms-transport-security-model-05.txt

  If we do keep it under snmpModules, then 
    sshtmMIB MODULE-IDENTITY
  possibly would be better
    snmpSshtmMIB MODULE-IDENTITY
  to be consistent with the other MIB modules under snmpModules.

- Copyright in MIB module should be IETF Trust, not ISOC

- I see:
  sshtmGroups OBJECT IDENTIFIER ::= { sshtmConformance 1 }
  sshtmCompliances OBJECT IDENTIFIER ::= { sshtmConformance 2 }

  while RFC4181 suggests:

     xxxMIB
     |
     +-- xxxNotifications(0)
     +-- xxxObjects(1)
     +-- xxxConformance(2)
         |
         +-- xxxCompliances(1)
         +-- xxxGroups(2)

  i.e. first compliances, then groups.

- For SnmpSSHAddress ::= TEXTUAL-CONVENTION I read:

        "Represents either a hostname encoded in ASCII
        using the IDNA protocol, as specified in RFC3490, followed by
        a colon ':' (ASCII character 0x3A) and a decimal port number
        in ASCII, or an IP address followed by a colon ':'
        (ASCII character 0x3A) and a decimal port number in ASCII.
         The name SHOULD be fully qualified whenever possible.

  I am not well versed/experienced in IDNA. But is IDNA a protocol?
  The title of 3490 reads
      Internationalizing Domain Names in Applications (IDNA)
  And are we indeed speaking of a hostname, or of a domain name, or
  of both? I can't quickly determine that. So I wonder if/hope that
  we can be clearer here.

  I also assume (although this is not explicitly stated) that if we
  speak about an IP address, that it is a dotted decimal for
  IPv4 and and a colon separated IPv6 address in ASCII? Yes/no?

  I am concerned that for 
     SnmpUDPAddress ::= TEXTUAL-CONVENTION
         DISPLAY-HINT "1d.1d.1d.1d/2d"
  we use a / sign to separate the port from the IPv4 address
  and here we use a colon (:).
  I must admit that (RFC3419) also uses :
      TransportAddressIPv4 ::= TEXTUAL-CONVENTION
          DISPLAY-HINT "1d.1d.1d.1d:2d"

  And what do we use for IPv6 addresses/ports?

  Further I read:

         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. In this case,
         the OBJECT-TYPE declaration MUST include a 'SIZE' clause
         to limit the number of potential instance sub-identifiers."

  Mmm.. we do not normally enforce (i.e. MUST language) that a SIZE
  clause must be used. We allo the DESCIRPTION clause to explain
  that implementers must be aware and cater for OID limitations.
  So do we really want that MUST language here?

Bert Wijnen 

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 22 Aug 2007 18:22:15 -0400

>   such RFC(s) is useful at these points.

Yes; those are SSH protocol messages.  It's actually not clear that SSH 
messages should be referenced explicitly here; instead, we should be 
talking about SSH at a rather higher layer.  For example, SSH user 
authentication can be a fairly complex negotiation; it doesn't involve 
sending just one message.  Similarly, outside the SSH protocol channels are 
presented as streams, not sequences of SSH_MSG_CHANNEL_DATA messages, and 
in particular you can't assume that your messages will be sent in a single 
channel data message or infer the size of an incoming message from the 
underlying SSH protocol messages.

Similarly, if you are establishing a separate SSH connection for every 
session, you don't need data from the SSH channel open/confirmation 
messages, and in fact generally such data will not be available to you as 
it is buried in the details of the SSH protocol.  If you are establishing 
multiple channels over the same SSH session, then you may need to know 
which channel is which, but this is almost certainly done using identifiers 
provided to you by your SSH implementation (perhaps even file descriptors) 
and not necessarily using SSH protocol data.

>   I am not well versed/experienced in IDNA. But is IDNA a protocol?

That is a semantic question, which I'd just as soon not argue here.
Perhaps we could say "as specified by IDNA [RFC3490]" ?

>   of both? I can't quickly determine that. So I wonder if/hope that

We are talking about a hostname, but hostnames are domain names (however, 
not all domain names are valid hostnames).

>   IPv4 and and a colon separated IPv6 address in ASCII? Yes/no?

In fact, I think we are in trouble if, for an IPv6 address, we don't mean a 
colon-separated address with brackets around it.  Otherwise it may become 
rather difficult to determine where the port starts, or if it is present!

-- Jeff

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 22 Aug 2007 17:08:01 -0700

In particular I think we need to be careful of SSH_MSG_USERAUTH_REQUEST.
First an empty username may appear in this message and second there is a
loophole in the base SSH spec that could allow an authentication
mechanism in which the name in the username field is not an authorized
name of the authenticated party.  

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Wednesday, August 22, 2007 3:22 PM
> To: Wijnen, Bert (Bert); David Harrington; Joseph Salowey (jsalowey)
> Cc: [email-masked]; Jeffrey Hutzelman
> Subject: Re: [Isms] my review of: draft-ietf-isms-secshell-08.txt
> 
> 
> 
> Yes; those are SSH protocol messages.  It's actually not 
> clear that SSH messages should be referenced explicitly here; 
> instead, we should be talking about SSH at a rather higher 
> layer.  For example, SSH user authentication can be a fairly 
> complex negotiation; it doesn't involve sending just one 
> message.  Similarly, outside the SSH protocol channels are 
> presented as streams, not sequences of SSH_MSG_CHANNEL_DATA 
> messages, and in particular you can't assume that your 
> messages will be sent in a single channel data message or 
> infer the size of an incoming message from the underlying SSH 
> protocol messages.
> 
> Similarly, if you are establishing a separate SSH connection 
> for every session, you don't need data from the SSH channel 
> open/confirmation messages, and in fact generally such data 
> will not be available to you as it is buried in the details 
> of the SSH protocol.  If you are establishing multiple 
> channels over the same SSH session, then you may need to know 
> which channel is which, but this is almost certainly done 
> using identifiers provided to you by your SSH implementation 
> (perhaps even file descriptors) and not necessarily using SSH 
> protocol data.
> 
> 
> 
> We are talking about a hostname, but hostnames are domain 
> names (however, not all domain names are valid hostnames).
> 
> 
>

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 23 Aug 2007 11:25:44 +0200

Inline

Bert Wijnen  

> Sent: Thursday, August 23, 2007 12:22 AM
> To: Wijnen, Bert (Bert); David Harrington; [email-masked]

OK, so some clarification seems to make sense then.

> Perhaps we could say "as specified by IDNA [RFC3490]" ?
that would be better I think

> names (however, not all domain names are valid hostnames).
So we mean a FQDN that represents a hostname?
So just "myhostname" would not be OK, it would have to be
"[email-masked]"?
I guess we want to be somehwat more specific then.

And don't we nee dto specify when we expect such a name to be resolved
into
an IP address?

> rather difficult to determine where the port starts, or if it 
So let us be somewhat more explicit as to how then addresses are
formatted.

Bert

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 23 Aug 2007 10:43:01 -0400 (EDT)

> I guess we want to be somehwat more specific then.

No; it would be "myhostname.example.com", which is both a hostname and a
domain name.

> And don't we nee dto specify when we expect such a name to be resolved

I don't think so; that problem is specifically left to SSH, because SSH
actually needs to know the hostname in order to do things like checking
that you have the right keys.