Re: [Isms] wg last call followup - sshtm
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Isms] wg last call followup - sshtm



>>>>> On Tue, 3 Mar 2009 18:47:27 +0100, "tom.petch" <cfinss at dial.pipex.com> said:
tp> And what it is about is having different securityName in sender and
tp> receiver which to me is a change to the architecture.  I would have
tp> thought that RFC341x precluded it somewhere, but, like dbh, I cannot
tp> see anything to stop us.  But I do see it as different enough to
tp> need documenting, and tmsm is the place to make architectural
tp> comments.

In USM the securityName is explicitly passed and thus is the same on
both sides.  341x would be broken if it specified they had to be
identical on both sides, because it would prevent us from doing useful
things like we're doing today.

For SSHTM it actually turns out that the user name presented by ssh can
be useful in deriving a tmSecurityName.

If you look at the slides I presented in Dublin about the DTLSTM, you'll
see it discusses why this isn't as straight forward for DTLS and the
mappings are quite a bit more complex because DTLS doesn't hand a
principal name to the infrastructure (it only hands a certificate which
fields that are potentially much larger than a usable securityName).

All that being said, I actually don't object to wording be added that
much.  But I don't think it's needed, and I don't think it's important
from an interoperability point of view.  I do think it will slow down
the progress of these drafts which have been worked on for way too long
and the ADs are rightfully pushing the WG to complete.

If you wish to add text to the document I strongly suggest you propose
the text and identify where it should go immediately so we can consider
it.  If no one is willing to propose text then I don't think it should
hold up the documents because it's not a "technical" problem.
-- 
Wes Hardaker
Sparta, Inc.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.