Re: [Isms] pre11 comments

[Wes Hardaker <wjhns1 at hardakers.net>]

>>>>> On Wed, 2 Jul 2008 18:45:11 +0800, "David Harrington" <ietfdbh at comcast.net> said:

DH> I think the TSM should do a 1:1 translation from tmSecurityName to
DH> securityName, and vice-versa.  I am not sure we need a securityName
DH> mapping table for TSM.

DH> The mapping happens at the transport model from the transport-specific
DH> principal to the tmSecurityName. That mapping is obviously
DH> necessary.

The current state of affairs, with a unique SM based security name per
security model lets the VACM carefully distinguish which securityName
gets authorization based on which model it comes from.  Thus:

  securityName:wes model:USM

can be given greater or lower access than:

  securityName:wes model:KSM

This may be necessary because local policy dictates that kerberos (KSM
in the above example) is considered "more secure" than the USM model
for some reason or another.  The wes/USM may not be given access to some
critical infrastructure that the wes/KSM model is given.


Fast forward to the new TSM model.  Now we have only a single model to
distinguish ourselves with and regardless of whether SSH or TLS is used
under the hood, we have no selection criteria to use within the VACM to
grant preferred access to TLS users over SSH users.  But we may trust
one protocol over another for one reason or another (possibly because we
suddenly found a bug in the implementation of one protocol that suddenly
renders it less secure so we'd rather lower the allowed access level to
read-only until the implementation is fixed but the other protocol is
still just fine so it can stay at read-write).


The VACM *only* has the securityModel and securityName at it's disposal
to make the distinction between how to grant authorization to a given
remote entity (ok, it also has context and level information, but that
doesn't help).


This all means that *if* we want to allow separate authorization levels
for different secure transports (and I'll argue that we do want to) we
either need to:

  - use different securityModel numbers per transport, which the WG has
    already decided not to do (although it could be revisited I suppose
    and could be done with a careful IANA controlled mapping of TM
    domain numbers to security models all which in the end "mean" TSM).

  - say it's up to the user to ensure duplication doesn't happen.  But
    if we want to make use of existing infrastructure, you're now
    imposing something on the user base they may not have had to deal
    with because right now SSH and TLS may have colliding user names but
    it's not a problem because one is authorizing shell access and the
    other a web database and authorization rights are already different).

  - OR: (*) Provide a mapping system so that identical user names
    from different security protocols can be mapped to different
    internal securityNames for things like authorization checks.

The questions so far:

  - Do we want to provide different authorization checks per security
    transport?  I think most will agree this would be good.

  - Do we want to require identity mapping capability so that identity X
    on transport SSH can be different than identity X on TLS.  I
    personally think this would be good to have.

  - Do we want to provide a standardized mapping for mapping X/TLS and
    X/SSH to (eg) securityName's X and Y...  I'd argue yes, since
    without a standardized mapping system then there will be
    inconsistency.

So, *if* we want to do a mapping where should it go?  There are really 3
choices:

  - Put it in the TSM document.  The TSM could map between incoming
    securityNames offered by the transport and use that combined with
    the transportDomain to map to a value the application should use.
    This makes the TSM a bit more aware of the transport protocol that
    is in use, but it already had access to the transportDomain in the
    tmStateReference anyway so it's really nothing new.

  - Put it in the TM document and have a common mapping table, indexed
    in a similar way.  The TM would use pass this into the rest of the
    engine.  This gives more consistency in the value passed around the
    engine, which is probably a plus.

  - Have each TM implementation to provide a mapping table.  This would
    mean that if SSH wanted to play nice with the above discussed model,
    it would have to add a mapping table from a local SSH specific
    identity name to a SNMPv3 specific securityName.  It would be up to
    the TM document to say whether each TM implementation MAY, SHOULD or
    MUST provide such a mapping.

I don't like the idea of the third choice because it's too much
duplication.  The other two require a single table, indexed by
transportDomain and tmSecurityName, and it works for all instantiations
of a TM regardless of whether they're standardized or not.

I do think such a mapping is needed because security needs to differ and
the cost is not high.  In the real world, security changes too and it's
much cheaper to put in such a mapping now so that authorization can be
changed in the field in an emergency situation without disabling the
entire protocol when it may still be safe to do some level of
"monitoring" even if config isn't safe (e.g.).  Right now, with only a
single transport in the works, this problem isn't as apparent and this
is simply good future planning.

-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms