Subject: [Isms] draft-schoenw-snmp-tlsm-02.txt

From: "David B Harrington" <[email-masked]>
Date: Thu, 26 May 2005 11:36:33 -0400

Hi,

I have requested the publication of draft-schoenw-snmp-tlsm-02.txt
Here is a copy of the file for WG perusal until it shows up in the I-D
directory.

The primary changes have been in the text discussing the TMSM
framework.
Comments welcome, especially when accompanied by suggested text.

We could use some help developing the sample mappings, especially from
those familiar with the transport security protocols.

Thanks,
David Harrington
[email-masked]

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

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 31 May 2005 15:03:59 +0200

Good stuff; when the question arose recently of what next, I did think a
revision of this would be useful and here it is:-)

A general question; what is the distinction you are making between ssh and tls,
as in

   A solution based on this approach might also
   utilize a "transport application" that is actually another
   application operating at the application layer, such as SSH [SSHauth]

which is your only reference to ssh and so might seem to be the reason why it
gets no further coverage.  I had seen ssh and tls as equal alternatives
(assuming a reliable transport) and had expected them to be covered equally.
The ietf architecture tends to bundle everything above tcp/udp as application
and so in this sense, ssl, tls and ssh are all equally applications - or
tranport layer extensions, depending on your point of view.

  Tom Petch

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 31 May 2005 11:59:51 -0400

> I have requested the publication of draft-schoenw-snmp-tlsm-02.txt

A quick feedback about the draft
draft-schoenw-snmp-tlsm-02.txt in the isms working
group activities. My bias is towards a clarification of
key management principles in support of SNMPv3 security
improved with an isms solution.

Basically, the SNMPv3 security is an application-level
security concern. The usefulness of the draft
draft-schoenw-snmp-tlsm-02.txt is to present a roadmap
to adapt transport-layer security (or perhaps network-
layer security since IPSEC is not excluded from the
options) to the application-level security
requirements.

The key management principles are mainly stated in the
draft by the following sentence:
      "The TLS TM-security model MUST support the TLS
      Handshake Protocol with mutual authentication."
Such mutual authentication requires provisioning of
keys in the systems where the SNMPv3 engine resides,
and this is where AAA infrastructure reuse comes into
play (hinted by isms charter). This limits the
available options for transport-layer security
protocols that fits the TMSM, which is productive
because the surviving options would meet the
requirements with greater certainty. However, the
working group should watch the pitfalls of protocol
usage diversion (using a protocol for a usage that was
not envisioned in the first place).

There is no explicit recognition of a trust
relationship (and corresponding key material
provisioning requirement) between an SNMPv3 engine and
a owner organization, the one who would be authorized
to set up authorization tables. The draft is explicit
in not addressing authorization tables provisioning.
However, provisioning VACM tables was seen as one of
the major obstacles to SNMPv3 adoption (isms charter).
Perhaps this other aspect of isms deserves another
draft standard.

The isms faces a demanding target of providing
application-level SNMPv3 security with no incremental
burden on initial provisioning of configuration
material. Some progress is being made with this draft.
Looks like good material.

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 31 May 2005 12:59:31 -0400

Hi Tom,

TLS is "transport layer security", so it appears to me to be
categorized as being an extension of the transport layer. But I could
be wrong.

SSH, SASL, BEEP, and other security-related protocols that are often
layered atop TLS seem to be application layer protocols.  

I would be happy to modify the document to reflect the official
categories.

David Harrington
[email-masked]

> -----Original Message-----
> From: Tom Petch [mailto:[email-masked]] 
> Sent: Tuesday, May 31, 2005 9:04 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [Isms] draft-schoenw-snmp-tlsm-02.txt
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 May 2005 17:57:52 +0200

> Perhaps this other aspect of isms deserves another

The charter identifies two major problems in the first paragraph
and then starts the second paragraph saying that ISMS focusses
on the first of the two identified problems. So VACM provisioning
according to my reading of the charter not in scope of this work.

/js

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 May 2005 19:09:30 +0200

> layered atop TLS seem to be application layer protocols.  

SSH layered atop of TLS???

/js

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 31 May 2005 13:47:36 -0400

> according to my reading of the charter not in scope of this work.

Your reading of the charter seems appropriate. My apologies for any 
inconvenience from my incorrect reading.

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 31 May 2005 13:21:11 -0400

Hi Thierry,

The ISMS WG charter has recognized two synchronization problems -
authentication and authorization. The charter limits our current scope
to the authentication problem. The authorization problem will need to
be solved in a separate effort, although solutions to the first might
provide some means of interfacing to a solution of the second problem
(preferably in a manner consistent with the RFC3411 architecture).

TMSM provides an architecture for building security models that layer
atop other security layers (or applications), such as TLS, SSH, SASL.
The statement about the TLS TM-security model mutual authentication
you quoted was explicit to a TLS-based solution, not all possible TMSM
solutions. The MUST was requested by some, so I changed it from the
original document; I'm not sure it will remain as currently written.
So I would avoid extrapolating too much from that one sentence.

David Harrington
[email-masked]

> From: Thierry Moreau [mailto:[email-masked]] 
> Sent: Tuesday, May 31, 2005 12:00 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 31 May 2005 13:30:00 -0400

Whoops! 

David Harrington
[email-masked]

> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Tuesday, May 31, 2005 1:10 PM
> To: David B Harrington
> Cc: 'Tom Petch'; [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Tue, 31 May 2005 22:39:43 -0400

>>>>> "David" == David B Harrington <[email-masked]> writes:

    David> Hi Tom, TLS is "transport layer security", so it appears to
    David> me to be categorized as being an extension of the transport
    David> layer. But I could be wrong.

    David> SSH, SASL, BEEP, and other security-related protocols that
    David> are often layered atop TLS seem to be application layer
    David> protocols.

    David> I would be happy to modify the document to reflect the
    David> official categories.

I think it doesn't matter so much what we call tls or ssh.  Tom's
question still stands: how do you see ssh interacting with your
protocol?

Are you expecting to use the ssh authentication protocol without the
ssh transport?  I don't think that's within the scope of that
protocol.

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 31 May 2005 23:42:25 -0400

Hi Sam,

I would use SSH as it was designed to be used. 

I am not very knowledgeable about the SSH suite, but I would expect to
use the SSH transport layer, and the SSH authentication protocol. 

Netconf also runs over SSH, using the SSH transport and
authentication; then the SSH connection protocol creates a session,
and runs an SSH subsystem called netconf. I expect something
comparable for SNMP. I consider it desirable to utilize a similar
approach between netconf and SNMP, to the degree the two management
protocols are similar.

I have not worked on the details of how the binary formatted SNMP
messages might impact the SSH approach differently than the netconf
approach. 

Netconf punted on the notification channel because not all their
"transports" could handle such a thing. SNMP obviously requires
notification capabilities, so we'd need to determine how that could be
done with SSH, as with any other possible transport layer security
protocols. 

If it is difficult to make protocols not designed to support
notifications meet notification requirements, and it is expected that
USM will continue to be deployed for troubleshooting purposes when a
TMSM solution is deployed for non-troubleshooting purposes, it might
be reasonable to expect that notifications be sent using the USM
security model rather than the TMSM security model. The cost of USM
configuration for a security association with one or a few
presumably-centralized notification receiver applications would be
small compared to configuring the notification and filter tables and
the VACM access tables of the SNMP engine, and once a security
association is created between a "manager" and "agent" using TMSM, it
should be easy to configure USM "users" that represent the
notification receiver applications. 

David Harrington
[email-masked]

> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Tuesday, May 31, 2005 10:40 PM