Subject: [Isms] Separation of transport mapping from security model in SSHSM

From: "David B Harrington" <[email-masked]>
Date: Mon, 26 Jun 2006 14:46:41 -0400

Hi,

Should we define a transport-mapping subsystem? This was not done in
RFC3411. TMSM comes close to doing this, but doesn't go all the way.

We could define a transport mapping extension to RFC3411, with ASI
extensions showing a tmSessionReference (or tmStateReference) passed
between the transport mapping subsystem and the dispatcher, and
between the dispatcher and messaging subsystem, and between messaging
subsystem and the security subsystem. That represents the bulk of the
work done in the TMSM document.

Then we could define an SSH transport mapping that discusses how to
open or close an SSH session, and how to prepare the
tmSessionReference from SSH parameters. This would be greatly
simplified by only dealing with it as a transport mapping, and
separating it via ASIs from the security model.

In draft-ietf-isms-sechell-04.txt (submitted but not yet announced),
the MPSP processing appears to be independent of SSH. All the
transport-specific processing seems to be done by the TMSP portion.
The MPSP portion only extracts model-independent parameters from
tmSessionReference. (This assertion should be double-checked by others
to make sure I didn't miss anything.)

I believe the SSHSM-MPSP could be turned into a security model that
would work with SSH, TLS, BEEP and other transport mappings, assuming
comparable processing assumptions (authPriv only, no use of the
msgSecurityParameter fields, etc.). 

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

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Jun 2006 17:23:48 -0400

> RFC3411. TMSM comes close to doing this, but doesn't go all the way.

...

> msgSecurityParameter fields, etc.).

Hm; that's an interesting question.  To date, we've mostly been assuming 
that an SSH transport model and security mapping would be fairly tightly 
coupled to each other, at least in practice, and that the same would likely 
be true for other TMSM's.

I agree that it may well be possible to define a more general security 
model which could be shared by mappings for a variety of transports which 
provide security features.  I think this idea warrants further discussion.

-- Jeff