Subject: [Isms] review of secshell-12

From: "David Harrington" <[email-masked]>
Date: Thu, 9 Oct 2008 23:05:41 -0400

Hi,

Wes did much of the updating this time, so I get to review it ;-)
Wes was instrumental in identifying technical issues and proposing
solutions, based on his work with the DTLS transport model, and taking
on editor responsibilities while I have been tied up with the day job,
so I asked him to add himself as an editor.

David Shields provided a long list of proposed editorial changes that
have not yet been applied, except the cross-document-consistent
description of the cached information and references section. This
revision is focused on the proposed technical changes, so the WG can
see the technical changes more easily using diff.

The prefix approach has been localized to the Security Model as much
as possible. 

4.3.1 I have concerns about the predictability of creating
tmSecurityName for protocols like GSSAPI. (In the following GSSAPI can
be replaced by other mechanisms) I think implementations of the
mappings must be accompanied by a description of what operators can
expect for the output format (for an incoming message) and what format
must be supplied for outgoing messages (from TARGET-MIB et al).
Operators MUST know what the tmSecurityName format will be for a given
<GSSAPI> identity, and the operator MUST provide tmSecurityName in a
format that the transform can work with to get to a given <GSSAPI>
identity. The transform can vary by implementation, to allow
variations in the <GSSAPI> identity formats, but within a given
implementation, the transform must be consistent and predictable.

I do not think we should require administratively configurable
transforms. This was originally addede to address the potential for
conflicting tmSecurityNames from different transport models, but the
prefix approach eliminates that need. Implementers should only be
required to provide one predictable transform per mechanisms that does
not use the default user name transform.

4.3.3 needs some editorial rewording.

5.2 I am a bit concerned about the new text regarding "implementations
might do somehting different". We shouldn't be talking about what
implementations must do, we should be talking about the standardized
expectations. 

s/Other implementation dependent steps may also be needed.//
s/or some other implementation dependent way//
	We expect a mapping from tmTransportAddress and tmSecurityName
to identify, in an SNMP-specific interface, some
implementation-dependent LCD. We should maintain the SNMP-interface
requirement, but how the implementation does their mapping from that
point is implementation-dependent.

5.3 
s/should presented/should be presented/
s/may/MAY/
s/should/will/
	I recommend rewriting 1) to split out the different steps
better.

in 3) s/user/SSH principal/

The MIB
Copyright year needs updating

snmpSSHDomain - I would eliminate the discussion of what the security
model can do, and the reference (which cannot be made from within a
MIB document).

s/may/MAY/
s/must/MUST/
s/SNMP securityName/tmSecurityName/

10.
The IANA section needs to request the craetion of a registry for
domains and associated prefixes.

References 
Wes's version of xml2rfc formats references differently than mine. I
prefer the less white space from my version. We'll discuss which
version to use.

Change Log
Wes's changes got listed under the 08-09 changes rather than under the
11-12 changes.

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

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 14 Oct 2008 09:14:29 -0700

>>>>> On Thu, 9 Oct 2008 23:05:41 -0400, "David Harrington" <[email-masked]> said:

DH> Wes did much of the updating this time, so I get to review it ;-)

I'm assuming that this means you think I still have the editing pen(s), so
I've updated the document and will send you fresh sources later...

Here's my responses to your notes...

Quick legend:

  - [-]:  nothing done; more info or discussion needed
  - [/]:  partially done
  - [X]:  done

Your words are prefixed with a '|', and my replies with WH:

| - [-] 4.3.1 I have concerns about the predictability of creating
|           tmSecurityName for protocols like GSSAPI. (In the
|           following GSSAPI can be replaced by other mechanisms) I
|           think implementations of the mappings must be accompanied
|           by a description of what operators can expect for the
|           output format (for an incoming message) and what format
|           must be supplied for outgoing messages (from TARGET-MIB et
|           al).  Operators MUST know what the tmSecurityName format
|           will be for a given <GSSAPI> identity, and the operator
|           MUST provide tmSecurityName in a format that the transform
|           can work with to get to a given <GSSAPI> identity. The
|           transform can vary by implementation, to allow variations
|           in the <GSSAPI> identity formats, but within a given
|           implementation, the transform must be consistent and
|           predictable.

        WH: IIRC, the working group decided not to do a SSH-mode
        specific mapping to security names because multiple people
        declared it out of scope because it was diving into the
        black box that is SSH.  The current version of the draft
        hasn't changed that at all.  The last version had a table
        that allowed a mapping from one string to another, and we
        can certainly put that back but the operators would still
        need to know what comes out of GSSAPI in order to put an
        entry into the mapping table.  The only thing the older
        mapping table had that we've lost is the ability to
        force-shrink to 32 characters so VACM doesn't barf later
        on.  Does this mean you're suggesting we revisit the need
        for providing a mapping from SSH specific authentication
        algorithm to the tmSecurityName string that is handed to
        TSM?

|           I do not think we should require administratively
|           configurable transforms. This was originally addede to
|           address the potential for conflicting tmSecurityNames from
|           different transport models, but the prefix approach
|           eliminates that need. Implementers should only be required
|           to provide one predictable transform per mechanisms that
|           does not use the default user name transform.

        WH: well, it is a lower case should currently.  But if
        others don't think it's appropriate, removing it certainly
        possible.  Personally, I'd rather see it there.

|  - [X] 4.3.3 needs some editorial rewording.

            WH: I'd be happy to copy in any text you wish to propose for
            it.  I didn't touch that section (other than to remove a mib
            reference).  The first sentence came from the -11 draft, and
            the second came from either you or Dave Shield.

|  - [X] 5.2 I am a bit concerned about the new text regarding "implementations
|           might do somehting different". We shouldn't be talking
|           about what implementations must do, we should be talking
|           about the standardized expectations.
|
|           s/Other implementation dependent steps may also be needed.//
|           s/or some other implementation dependent way//
|
|                 We expect a mapping from tmTransportAddress and
|           tmSecurityName to identify, in an SNMP-specific interface,
|           some implementation-dependent LCD. We should maintain the
|           SNMP-interface requirement, but how the implementation
|           does their mapping from that point is
|           implementation-dependent.
|
        WH: done

        WH: but...  I'm not necessarily happy.  The problem with
        the SSH draft is that it's a mix of what needs to be done
        on the wire to be compatible, and what must be done to be
        compatible with the "an" architecture.

        WH: To get more specific, I don't think 99% of the
        implementations that will be written will not follow this
        particular statement because they'll already have that
        information in state data they've passed around because
        they implement a session-oriented stack in the first place
        and a direct reference to the LCD will be used instead.
        IE, the bits on the wire will match perfectly but I'm
        betting the architecture blocks won't.

|  - [X] 5.3 
|           s/should presented/should be presented/
|           s/may/MAY/
|           s/should/will/
|
        WH: done

|  - [-] I recommend rewriting 5.3 1) to split out the different steps
|           better.
|
|        WH: I'd need a suggestion for what you want split.  Most
|        of it is 'open the connection' spelled out in gory
|        detail.  We could split the decision about what SSH user
|        name to use into a step just above this one, is that what
|        you were thinking?

| - [X] in 3) s/user/SSH principal/

        WH: done

| - [X] (The MIB) Copyright year needs updating

        WH: done

| - [/] snmpSSHDomain - I would eliminate the discussion of what the security
|           model can do, and the reference (which cannot be made from
|           within a MIB document).

        WH: half done: It seems a bit odd to specify a prefix with
        no definition of why you're specifying it.  I've deleted
        the reference but left the rough usage description in it
        because I think we need somethere there other than just
        (functionally) '"ssh" is a prefix'.

| - [X] s/may/MAY/
|           s/must/MUST/
|           s/SNMP securityName/tmSecurityName/

        WH: done

| - [X] 10.
|           The IANA section needs to request the craetion of a
|           registry for domains and associated prefixes.

        WH: You're thinking about the wrong document, that should be
        and is in the TSM document.

| - [-] Wes's version of xml2rfc formats references differently
|       than mine. I prefer the less white space from my
|       version. We'll discuss which version to use.

        WH: Well ya could have compiled it yourself before
        publishing it ya know ;-)

        WH: I'm using the latest version so I suspect that all
        newer RFCs will likely look like that output, unless there
        is an option we can set to match your preferred format.
        Personally, I don't care that much what it looks like so
        I'd be happy to do whatever you want.  However, it won't
        really matter since the RFC editor will certainly compile
        it with the latest and it's likely moot point from the WG
        perspective.

| - [X] Wes's changes got listed under the 08-09 changes rather
|       than under the 11-12 changes.

        WH: fixed

-- 
Wes Hardaker
Sparta, Inc.