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

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 5 Nov 2006 01:13:24 +0100

I have reviewed <draft-ietf-isms-secshell-05.txt> and below are my
comments (as a technical contributor).

/js

01: Page 1: Reference [RFC 3411] in the third paragraph in section 1.

02: Page 5: The last sentence in the 3rd paragraph of section 1.3
    somehow does not read well.

03: Page 5: "User Security Model" -> "User-based Security Model"

04: Page 6: Keyboard-interactive [RFC4256] has been excluded from the
    discussion of authentication mechanisms and I think it should be
    mentioned.

05: Page 7: Is the last paragraph on this page needed?

06: Page 8: I think we should replace the term "tunnel" with "channel".

07: Page 10: "SSH.This" -> "SSH. This"

08: Page 10: I think we need to mention here keyboard-interactive
    again.

09: Page 11: Expland "DH" the first time it is used.

10: Page 11: The first paragraph in section 3.1.7 actually is part of
    an applicability statement and perhaps should be factored out into
    a separate section.

11: Page 12: I think engineID discovery is so widely used with USM
    that we can't make the discovery implementation-dependent. We need
    an interoperable solution.

    The USM discovery procedure concerns the securityEngineID (the
    contextEngineID is actually not passed to a security model). My
    understanding is that implementations usually do securityEngineID
    discovery and subsequently use the securityEngineID also as the
    contextEngineID (basically assuming that they talk to the
    non-proxy agent). Please correct me if my assumption is wrong.

    Dave Perkins wrote a private message on this subject to a few
    people on Thu, 8 Sep 2005 which led to the conclusion that one
    should get an snmpUnknownPDUHandlers report if there is not value
    engineID (or the PDU type is invalid) and that this can be used to
    pickup the "local" engineID. Dave Perkins, can you post the
    relevant part of your message to this list? [Note that we also
    discussed this durng the Boston interim.]

    An alternative approach could be to introduce a "fake"
    securityEngineID into the Transport Security Model for the only
    purpose to let it be discovered and to let clients to continue to
    assume that the securityEngineID is the contextEngineID to use.

    Another alternative would be to introduce a general "default"
    contextEngineID (while conceptually simply and appealing, this
    does not really work due to the fact the no existing
    implementation has something like that and all SNMPv3/USM
    implementations are not likely to change).

    We need to settle on one approach and document it properly.

12: Page 13: 1st paragraph in 3.3: Is it OK to be silent how
    credentials are provisioned?

13: Page 14: Why do you use the tms prefix here? Note that the names
    of the transport domain etc. may need to be updated. I am not sure
    why you want to have the security model in the LCD.

14: Page 16: tmsTransportModel can't be "SSH Transport Model"

15: Page 16: Add a comment after tmStateReference in the ASIs.

16: Page 17: Add a comment after tmStateReference in the ASI and
    fix the alignment of the comments.

17: Page 18: [todo]: This is mainly an architectural problem since we
    can't write the EoP; I assume that in most implementations, you
    still know whether you send a response or a request. I am not sure
    what to do about it. This needs discussion.

18: Page 18: [todo]: I think it is always the client invoking the
    ssh-userauth service. Shall we state as in step 1) that it is
    implementation dependent where the parameters are coming from?

19: Page 19: drop "(TBD by IANA)"

20: Page 19: The last paragraph in 5.3 likely needs updates depending
    how we want to deal with engineID discovery. And I kind of believe
    we should deal with this in the Transport Security Model, not in
    every Transport Model.

21: Page 19: The first sentence in 5.4 needs a rewrite - closeSession
    does not pass data between the Transport Model and the SSH
    Service.

22: Page 21: "SSHTM-MIB" -> "SNMP-SSH-TM-MIB" to be consistent with
    prior naming conventions. This module should likely be registered
    under snmpModules as well.

23: Page 23: I am not sure we need TransportAddressSSH; we should be
    able to use TransportAddressDns.

24: Page 24: I think transportDomainSSH should be snmpSshDomain and be
    registered below snmpDomains (now that we even have an IANA
    registry for this).

25: Page 24: Does sshtmSessionOpenErrors count all open errors ranging
    from TCP connection establishment failures to SSH user
    authentication failures?

26: Page 24: When will sshtmSessionSecurityLevelNotAvailableErrors be
    incremented? Does the document not say SSH is always providing
    good enough security and we trust it?

27: Page 30: I do not understand the [discuss].

28: Page 30/31: The MIB module security section needs to be updated.

29: Page 31: IANA considerations need to be updated (mib-2 ->
    snmpModules, registration of snmpSshDomain, creation of the
    transport modules registration is done the transport model
    architectural extension document.

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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