Subject: [Isms] pre11 comments

From: "David Harrington" <[email-masked]>
Date: Wed, 2 Jul 2008 18:45:11 +0800

Hi,

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

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

I see us adding options and complexity that I don't see operators
asking for, such as administratively definable transform selection. I
hope these really are needed.

I agree that operators might want to disable SNMP use of a transport
that is allowed on the device for other purposes. For that, a TSM
domain table with an enable/disable object might be appropriate.
However, since we specifically use an "snmp" subsystem, isn't it
likely that an SSH config can control whether the user can use the
snmp subsystem, much like they can decide to disable X11 forwarding?
and even if they do get in, then VACM can prevent them from being able
to do anything snmp-related. So do we actually need to provide this
control?

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

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

---

From: "tom.petch" <[email-masked]>
Date: Thu, 3 Jul 2008 08:54:21 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 02, 2008 12:45 PM
Subject: [Isms] pre11 comments

> I am not sure we need a securityName mapping table for TSM.

David

I am reading 1:1 as being the identity mapping from the context.

The history as I see it is that it is the Security Subsystem that comes up with
the model independent securityName identifying the principal, and how it does it
is up to it.  Hence leaving the final decision to it and hence a mapping table.
Pragmatically, I have no problem with making the Transport Model do all the work
but that might go against architectural considerations that have been voiced
here in the past (although not by me).

I think too that there will still be an issue with securityLevel, in that the
MPM determines that, and there is currently no mechanism for the MPM to pass
that back to the TM when an inbound message is received over a session that the
TM received (as opposed to instigated).  Inbound message, TM creates a table
with SSH and transport details, message arrives, TM adds securityName tothe
table.  But when an outbound message is later passed from dispatcher to TM, the
TM cannot index to a session because it was never told what the application
level securityLevel is that is associated with that session (yup, same problem
as I been raising since ... )

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Thu, 3 Jul 2008 18:52:59 +0800

Hi, 

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> Sent: Thursday, July 03, 2008 2:54 PM
> To: David Harrington; [email-masked]
> Subject: Re: [Isms] pre11 comments
> 

No. Leaving the final decision, not to the security subsystem, but to
the security model.
How the security **model** does it is up to the security model.
So the TSM can make the decision to use an identity mapping rather
than a mapping table.

> here in the past (although not by me).

The transport model has the responibility for transforming the
transport-specific parameters into the tmStateReference format that
can be passed "up the stack".

Since the SSH transport model supports SSH, which allows various types
of identities, it may need to have a mapping table (or multiple
automatic algorithmic transforms).

> MPM determines that, 

I'll look closer at this, but I think that might be an overstatement.
For outgoing, the application determines the requested securityLevel.
For an outgoing SNMPv3 message, the v3MPM determines how to pass this
requested level in the v3 message format.
For an outgoing SNMPv1/v2c the MPM does not pass this requested value.

For incoming messages, the MPM determines what was requested by the
sending entity, either by convention (snmpov1/v2c=noAuthNoPriv), or by
getting the requested level from the v3 message. But that is only the
requested level.

The securityModel has the responsibility for ensuring that the
securityLevel request is met. RFC3414 checks that appropriate security
properties are supported, and if not, it generates an
unsupportedSecurityLevel error. So it is the security model that
determines the actual security level used (USM checks that appropriate
entry in the usmUserTable has an auth protocol specified, if the
requested security includes auth, and checks that the user has a priv
protocol if priv is part of the request.

TSM does the same thing. It compares the requested security level
provided by the MPM and the actual security level asserted by the
transport model, and verifies that the incoming message has met the
requirement. For outgoing, the TMS specifies the requested security
level to the TM, and the tM verifies that the actual properties (as
far as we can determine) meets the requested level. 

> and there is currently no mechanism for 
> the MPM to pass

There can be only one session for each transportdomia/address
securityname/level.
But with SSH, we ignore the requested level because SSH is always
authpriv.

I believe we state that very clearly:
"   Outgoing messages requested by SNMP applications and specified
with a
   lesser securityLevel (noAuthNoPriv or authNoPriv) are sent by the
SSH
   Transport Model as authPriv securityLevel."

So the SSHTM will never call openSession() and get an SSH session that
is not authpriv.
It will open one session for the domain/address/name and that will be
authpriv. If a user asks that a message be sent over SSH with
noAuthNoPriv, it will be sent over the one authpriv session associated
with the domain/address/name. If a user asks that a message be sent
over SSH with authNoPriv, it will be sent over the one authpriv
session. If a user asks that a message be sent over SSH with authpriv,
it will be sent over the one authpriv session.

There will never be multiple sessions to differentiate between on the
basis of securityLevel.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Jul 2008 15:08:54 -0700

>>>>> On Wed, 2 Jul 2008 18:45:11 +0800, "David Harrington" <[email-masked]> 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.

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 3 Jul 2008 18:40:20 -0400

Wes Hardaker writes...

> 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)...

Well, yeah, but where do we stop?  Someone might argue that the transport
protocol alone isn't enough.  Maybe they want to add cipher-suite into the
selection.  Or maybe key length, or maybe the specifics of the certificate
chain.  I could go on and on, specifying all sorts of security properties of
the transport that conceptually *could* make a significant difference in
*some* scenario.

I think that we should keep this very simple.  For that reason, I'm not
convinced that we need to sub-specify the TSM by its underlying protocol.
If a particular protocol is "compromised" the operator always has the option
to simply de-configure it.

Let's solve the "80% problem" and declare victory.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Jul 2008 16:10:49 -0700

>>>>> On Thu, 3 Jul 2008 18:40:20 -0400, "David B. Nelson" <[email-masked]> said:

>> levels for different secure transports (and I'll argue that we

DBN> Well, yeah, but where do we stop?

Right now the VACM and the security model can be used together to grant
or deny access based on a particular security model.  With a generic
"any sub-transport will do" security model not being put in place (TSM)
then we loose that ability.  I'm not trying to gain ground by doing
cipher-suite selection (that can still be left up to the individual
transport model's configuration since it's very specific to it).  What I
do think we're loosing, though, is the ability to select an
authorization set based on the protocol being used itself (like we used
be able to select between USM and KSM).  I don't think we should go
further than that, because further than that wasn't ever in the original
SNMPv3 architecture either.

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 3 Jul 2008 20:57:08 -0400

Wes Hardaker writes...

> Right now the VACM and the security model can be used together to
> grant or deny access based on a particular security model.  With 
> a generic "any sub-transport will do" security model not being put
> in place (TSM) then we loose that ability.

Correct.  Apparently the WG decided early on that, indeed, "any protected
transport will do".  I think what you're effectively suggesting is that we
should *not* have a general TSM, but a series of xSMs, where "x" is a
specific secure transport protocol.  KSM surely falls into that pattern.

Personally, I think it's very late for that kind of revision.  However, if
it can be "hacked in" without much disruption, I see no fundamental
objection to adding that feature.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 4 Jul 2008 10:58:45 +0800

Hi,

The whole reason SNMPv3 is modular is that "you can please some of the
people all of the time, and all of the people some of the time, but
you can never please all of the people all of the time." Let's not try
to make SSHTM and SSHSM perfect for every environment. Let's make it
good enough to work for most of the people all of the time, i.e., for
most environments it is secure enough, and keep things modular so the
unpleased people can write their own alternative models to suit their
specific environments.

I will observe that the SNMPv2 and SNMPv3 WGs had all sorts of
requirements that demanded support for particular use cases. In
reality, all the people who raised these additional requirements never
bothered writing alternative models to support their use cases (to my
knowledge). And many of the options we included in the 80% solution
seem to be go unused.

I think the case Wes is concerned with happens 1% of the time, and
with thoughtful configuration can be reduced to 0.00763% of the time
(OK, I'll settle for 80/20). I recommend writing TSM to handle the
80%, relying solely on the identity function, so we can avoid adding
yet another configuration table to SNMP. If this use case really is
perceived by operators as being a problem, a new diffTSM could be
created to include a table for differentiating between lower layer
transport protocols. TSM is an optional security model; for those 20%
environments where the differentiatioon is important, create another
optional modular security model and let operators use whichever they
prefer. 

Following the 80% rule, I also recommend making it even clearer that
there is one and only one SSH session per address/name tuple, and all
securityLevel requests are shoe-horned into the one authpriv SSH
session per address/name. This avoids adding yet another configuration
table to SNMP. If somebody really **needs** to have three different
authpriv sessions that are differentiated by overloading the purpose
of tmSecurityLevel and calling the three authpriv sessions
"noAuthNoPriv", "authNoPriv", and "authpriv", that can be done in a
different SSH transport model.

Following the 80% rule, I suggest that reuse of sessions initiated for
a different direction be disallowed. The initiator of a session MUST
act as a client, and authenticate as a client using the user_auth
protocol standard. If somebody finds this to be problematic, they can
write an alternative transport model to solve that problem.

Following the 80% rule, I would also recommend making the filling-in
of the SSH user_name field mandatory for use with SSHTM. SSH makes the
user_name field mandatory, but whether it is filled in is optional
with some authentication mechanisms. I suggest simplifying things by
requiring that, for use with SNMP, the user_auth protocol MUST be
used, and the user name field MUST be filled in with a value that
identifies the principal being authenticated. Then we can use the
identity mapping in SSHTM as well, eliminating yet another SNMP
configuration table. Toolkits that do not always fill in this field
for user_auth, or do bnot make this field available to calling
applications, will not be suitable for use with SSHTM. This makes no
changes to SSH; it only states implementation/deployment requirements
for compliance with SSHTM.

dbh

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David B. Nelson
> Sent: Friday, July 04, 2008 8:57 AM
> To: [email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Jul 2008 19:59:17 -0700

>>>>> On Thu, 3 Jul 2008 20:57:08 -0400, "David B. Nelson" <[email-masked]> said:

DBN> Apparently the WG decided early on that, indeed, "any protected
DBN> transport will do".  I think what you're effectively suggesting is
DBN> that we should *not* have a general TSM, but a series of xSMs,
DBN> where "x" is a specific secure transport protocol.

That was one of the suggestions that I said was possible if we wanted to
solve the issue.  I also said it was the one that I think was already
decided against.  The other one was a security name mapping.  If you go
back to my original post, I mentioned a few options and one of which was
a mapping table in the 

DBN> KSM surely falls into that pattern.

No, actually, it doesn't because it already was designed (in IETF
history of the past) to be a separate security model and wasn't based on
a tunnel transport and thus wasn't TSM based.  So with KSM we already
had the ability to separate out KSM from USM.  I'm simply looking for
a similar ability from future transport support.

DBN> Personally, I think it's very late for that kind of revision.  However, if
DBN> it can be "hacked in" without much disruption, I see no fundamental
DBN> objection to adding that feature.

There wouldn't be little disruption (a minor wording change here or
there and a MIB table).  I'd be happy to supply the text and table for
inclusion but I will wait until people think it's ok to consider
including before committing resources to it.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Jul 2008 20:01:43 -0700

>>>>> On Fri, 4 Jul 2008 10:58:45 +0800, "David Harrington" <[email-masked]> said:

DH> I think the case Wes is concerned with happens 1% of the time, and
DH> with thoughtful configuration can be reduced to 0.00763% of the time
DH> (OK, I'll settle for 80/20).

Then why was the VACM designed to operate differently based on the
security protocol?  Was that over-done and it should have been a simple
vc/v3 enum instead?

---

From: "David Harrington" <[email-masked]>
Date: Fri, 4 Jul 2008 11:58:54 +0800

Hi Wes,

I don't think VACM is designed to operate differently based on the
security protocol. It is designed to operate differently based on the
asserted securityLevel. Depending on the assertion made by the
security model rather than an assessment of the presumed strength of
the underlying security protocol was a deliberate decision of the
SNMPv3 WG.

In USM and SNMPv1 and SNMPv2c community-based security models, whether
auth and priv are asserted is based on a binary decision (an auth and
priv protocol have been specified or not), not the degree of trust in
the underlying security protocol. (RFC3413 3.1 2) and 3), and RFC3584
5.2.1)

In TSM, we accept the assertion made by the transport model. SSHTM
makes its assertion based on "we have specified that the operator MUST
configure for authpriv and to do otherwise is not compliant with this
specification." It is up to the operator to ensure it is compliant.

If an operator does not feel the underlying protocol really provides
adequate authpriv support, then they should configure it to not be
used with SNMP. I do not support TSM having a table to decide whether
"auth" is "auth enough" or "priv" is "priv enough".

dbh

> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Friday, July 04, 2008 11:02 AM
> To: David Harrington
> Cc: 'David B. Nelson'; [email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Jul 2008 21:41:21 -0700

>>>>> On Fri, 4 Jul 2008 11:58:54 +0800, "David Harrington" <[email-masked]> said:

DH> I don't think VACM is designed to operate differently based on the
DH> security protocol.

But it is; that's my point...  And we're loosing that.  The security to
group table is indexed by the model and the name that the model provides:

  +--vacmSecurityToGroupTable(2)
     |
     +--vacmSecurityToGroupEntry(1)
        |  Index: vacmSecurityModel, vacmSecurityName
        |
        +-- ---- INTEGER   vacmSecurityModel(1)
        +-- ---- String    vacmSecurityName(2)
        +-- CR-- String    vacmGroupName(3)
        +-- CR-- EnumVal   vacmSecurityToGroupStorageType(4)
        +-- CR-- EnumVal   vacmSecurityToGroupStatus(5)

It provided the ability for "wes" in USM land to be different than "wes"
in KSM land.  Or the same; it was an operator decision.

Now with the ISMS based solution then all future transport protocols
operating as a TM underneath TSM will always have identical
securityNames mapped to the same group and there is no way to change
that.  "wes" in SSH will have to be equivalent to "wes" in TLS because
the model number will be constant for both (which will be the enum value
for TSM).

The WG needs to make a decision whether we care about this or not.  It
will mean that "wes" will be locked into the same group regardless of
whether the transport is SSH or any other future transport from now on
that is TM/TSM based, be it TLS, DTLS, or TELNET (yeah, I know...).
The point, though, is that there will be no separation from an access
right like we already have today with a different security model number
per security feature set.  Maybe we're willing to live with that; but I
personally think it's short sighted.

DH> In USM and SNMPv1 and SNMPv2c community-based security models, whether
DH> auth and priv are asserted is based on a binary decision

It has nothing to do with auth/priv decisions (well; it's related but it
wasn't part of the point I was trying to make).

DH> If an operator does not feel the underlying protocol really provides
DH> adequate authpriv support, then they should configure it to not be
DH> used with SNMP. I do not support TSM having a table to decide whether
DH> "auth" is "auth enough" or "priv" is "priv enough".

I think you're missing my point.  Again, I'm not at all making
suggestions that we map specific auth/priv algorithms into VACM
decisions.  We don't do that with the USM now and I'm not proposing we
add such a new feature.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Fri, 4 Jul 2008 13:40:27 +0800

Hi,

I think I do see the point.
The TSM model makes one assertion about whether authpriv is provided.
We need to decide whether a single assertion from the security model
is adequate, if the security model can "outsource" to different
lower-layer transports.

Do we need to make it possible for the administrator to provide a
mapping to different securityNames or different asserted
securityLevels based on the administrator's assumption of the strength
of the underlying transport.

I believe the SNMPv3 WG made the conscious decision that trying to
assess the strength of an underlying security mechanism, whether it is
at the SSH vs TLS level, or the DES vs AES level, is so difficult to
get right, and depends so much on the environment to which it is being
applied, that it is not worth trying to do this **within** SNMP. An
admin can control this better by determining whether and how to deploy
the underlying security mechanism.

I believe we should work with the same assumption - that an admin can
control this better by deciding how to deploy the underlying security
mechanism, whether it is at the SSH vs TLS level or the DES vs AE。

If an admin does not think SSH is adequate for SNMP, then they should
not authorize the creation of an SNMP subsystem in their SSH config.
Problem solved. No MIB tables to configure.

dbh

> Sent: Friday, July 04, 2008 12:41 PM
> To: David Harrington
> Cc: 'Wes Hardaker'; 'David B. Nelson'; [email-masked]

---

From: "tom.petch" <[email-masked]>
Date: Fri, 4 Jul 2008 11:41:19 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 03, 2008 12:52 PM
Subject: RE: [Isms] pre11 comments

<snip>
> There will never be multiple sessions to differentiate between on the

Right, this is where we part company.  I have always believed that there are
good operational reasons for there to be multiple sessions.  A change of
securityLevel means a change of session and I have always seen that as a
desirable feature eg that the mass of SNMP traffic is routine polling,
noAuthNoPriv, while third-level support sometimes use authPriv to find and fix
problems, and that it was important to keep them on separate TCP sessions, eg
lest a getBulk of the 150,000 entry routing table on one delayed a poll on the
other; or some
such.  The security aspects, of using a session of greater security than
securityLevel, are fine, we agreed that long since, but I have always expected
the traffic to be kept apart.  (Of course, the transportAddress can and may
provide separation of traffic)

And when I read in the SSHTM I-D eg in s5.2
"     1) Determine the target index by extracting the transportDomain,
      transportAddress, securityName, and securityLevel from the
      tmStateReference.
      2) Lookup the session in the Local Configuration Datastore using
      the target index"
then I read that as saying that a change in securityLevel is a change in target
index which leads to a different session [which I think is a good idea:-)].  If
you are saying, use this 4-tuple as an index and for three parts use an exact
match while the fourth must be less or equals, then I think that we need
different words.

Or if you are saying that the text means that the securityLevel is ignored, then
again I find that a bit of a stretch.  On a quick scan of the archives, I cannot
see any discussion of this previously.

So, I think you should get agreement that it is ok for the SSHTM to ignore the
securityLevel in determing which session to use.  In which case, I will go
through the I-Ds and flag places where I believe that the English could be
clearer; I suspect that there might be some such in tmsm e.g. s3.3 :-(.

Tom Petch

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 4 Jul 2008 08:51:07 -0400

Wes Hardaker writes...

> The security to group table is indexed by the model and the name 
> that the model provides:
> 
> It provided the ability for "wes" in USM land to be different 
> than "wes" in KSM land.  Or the same; it was an operator decision.

Was that a conscious goal of the VACM design, or was that simply an
unplanned outcome that some may have taken advantage of later?  After all,
if vacmSecurityName is supposed to be a model independent name, it seems odd
to make it model dependent again in this fashion.
 
> the model number will be constant for both (which will be the enum
> value for TSM).

I happen to think that level of simplification is probably a Good Idea (tm).
I also think that the level of access control complexity (down to leaf node
granularity) is more than 80% of operators find a valid use for.  Sometimes
having too many choices is a Bad Idea (tm).

> The WG needs to make a decision whether we care about this or not.

I personally don't care.  I think we can solve the 80% problem by having a
single TSM that is always "good enough" when correctly configured.  BTW,
correct configuration is *always* going to be a caveat for any security
related solution.  As Dave H. says, if there is a market demand for
"Differentiated Services" TSM, one could always take the current work and
spin up another document to describe it.

I think (and this is my subjective opinion) that to be true to SNMPv3
architecture, you'd need to have multiple Security Models, each with its own
name, rather than a single, parameterized Security Model that could export a
pseudonym for the purpose of VACM mapping.  At least for the sake of
architectural description; the implementation could optimize by creating a
single parameterized model, I suppose.

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Fri, 4 Jul 2008 15:04:28 +0200

W.r.t. David's question:
> if vacmSecurityName is supposed to be a model independent name,
> it seems odd to make it model dependent again in this fashion.
>

I remember the discussion very well, and I was opposed to see the
vacmSecurityModel as one of the index objects. But in the end I
was unable to convince (enough) others and so (rough) WG consensus
was to indeed include it.

> granularity) is more than 80% of operators find a valid use for.
> Sometimes having too many choices is a Bad Idea (tm).
>

I agree. In hindight, I think we overdesigned it which made it far more
complex than needed.

> architecture, you'd need to have multiple Security Models, each
> with its own name, rather than a single, parameterized Security Model that
> could export a pseudonym for the purpose of VACM mapping.  At least for
the sake of
> single parameterized model, I suppose.

Well, given my above comment, I guess you can understand that I am
in favor of just using TSM (at least for now) as the security model, no
matter what unerlying technology is being used.

Bert

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 23 Jul 2008 09:39:06 -0400

Jeffrey Hutzelman writes...

> In this way, the difference between an SSH user and a TLS user 
> becomes very clear in VACM, and the mapping from SSH username to 
> securityName and back is well defined.
> 
> Comments?

That may be useful for deployments where there are distinct namespaces for
SSH, TLS, Kerberos, Telnet, Unix login, and what-have-you.  I'm sure there
are such deployments.  On the other hand, another way to address the issue
of divergent namespaces is to use a single AAA service (or at least a single
back-end user database) for all authentication purposes within an
organization.  The ability to use existing AAA infrastructures (with a
common user namespace) was one of the primary goals of the ISMS work, no?

Universal single sign-on s still an elusive "holy grail" but it is often
achieved within the confines of a single organization.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 23 Jul 2008 08:28:49 -0700

>>>>> On Wed, 23 Jul 2008 09:39:06 -0400, "David B. Nelson" <[email-masked]> said:

DBN> The ability to use existing AAA infrastructures (with a common user
DBN> namespace) was one of the primary goals of the ISMS work, no?

The goal was to use the infrastructure pieces that the operators were
already using, which may include AAA infrastructures if they use them
(but not everyone does).
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Jul 2008 13:32:51 -0400

Hi,

Neither SSHTM nor TSM assume support for single sign-on across the
administartive domain now.
Neither SSHTM nor TSM assume lack of a single sign-on across the
administartive domain now.

SSHTM and TSM assume that the underlying protocols will not conflict,
and, when used with SNMP, that resolution of any such conflict between
secure transports should be resolved administratively by modifying the
configuration of the underlying transports. SSHTM and TSM try to make
it clear (and we may need to make it clearer) that if there is a
conflict, then SSHTM and TSM will not resolve the problem; the
administrator needs to eliminate the conflicts at the secure-transport
layer (or possibly by disabling support for a specific transport model
in SNMP). To not prevent such conflicts is a configuration error. I
think that is a reasonable approach.

dbh

> Sent: Wednesday, July 23, 2008 9:39 AM
> To: [email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Jul 2008 13:38:38 -0400

Ideally, AAA support will be transparent to everything except the
actual secure transport. 
The authentication protocol that SSH uses to authenticate the user
should be hidden by SSH.
The authentication protocol that TLS uses to authenticate the user
should be hidden by TLS.
The authentication protocol that <XXX> uses to authenticate the user
should be hidden by <XXX>.

SNMP should not know or care which authentication protocol is used
(unless it is an SNMP-built-in algorithm like community or USM).
SNMP should only care about getting an assertion that authentication
has been done, and getting an identifier of the principal that was
authenticated.

dbh

> Behalf Of Wes Hardaker
> Sent: Wednesday, July 23, 2008 11:29 AM
> To: David B. Nelson
> Cc: [email-masked]

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 23 Jul 2008 14:44:15 -0400

<snip>

> has been done, and getting an identifier of the principal that was

and also...

 > configuration of the underlying transports.

I think that's the correct model for SNMP, given its strong "separation 
of concerns" and modular architecture.

However, if an operator is using *both* SSH and TLS, for example, with 
disjoint user databases having disjoint namespaces, the only ways to fix 
that issue "in the transport" would be to either synchronize the 
namespaces (i.e. either de jure or de facto single-sign on) or to 
incorporate some form of administrative "realm" element in the user 
name.  An example of such a construct may be found in the Network Access 
identifier [RFC 4282].

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 23 Jul 2008 02:07:22 -0400

--On Thursday, July 03, 2008 08:57:08 PM -0400 "David B. Nelson" 
<[email-masked]> wrote:

> transport will do".

Actually, no.  We started out with an SSH-specific security model and 
transport mapping, which were designed to be used together to fit within 
the SNMP architecture.  The decision to make TSM generic was made later, 
when we noticed that there wasn't actually anything SSH-specific in it.

I'm inclined to agree with Wes here, that it is desirable for the access 
control model to be able to make decisions based not only on the 
securityName but on the underlying security mechanism, which in the case of 
TSM depends on the transport model used.

This isn't just about saying you trust TLS more or less than SSH.  It's 
also about TLS, SSH, and other transport models having different 
namespaces, just as USM has a namespace different from any of these.  If we 
can provide a standardized way to say "the SSH user X" at the access 
control level, just as we have a standardized way to say "the USM user Y", 
then I think we have made significant progress.

I would note that it is not necessary to extend this to particular ciphers, 
as those do not affect the meaning of an SSH username or of the identity 
information in a certificate.  Similarly, it does not even need to extend 
to particular SSH userauth methods, because SSH only has one namespace for 
usernames, and userauth methods are simply about proving that you are 
authorized to assume a particular requested username.

Elsewhere, David Harrington writes...

> The initial WG discussion led to a design that took a securityName and
> mapped it to a
> transport-specific ID.
>
> The discussion now makes it clearer that the securityName should map
> to a tmSecurityName, and then the TM needs its own table to map from
> tmSecurityName to a transport-specific ID.
>
> personally, I think that's more levels of mapping than we need, and
> all these mappings impact the predictability of the ultimate mapping
> from the actual security ID to securityName.

I'm beginning to think that it is also more levels of mapping than we need. 
In order to simplify this somewhat and also address what I believe is Wes's 
concern (which has nothing to do with securityLevel), I'd like to propose a 
strawman.  Specifically, I propose that for TSM, the securityName always 
take the form "TM:name", where TM is a token indicating the secure 
transport model in use and name is a transport-specific ID.  Obviously we'd 
need an IANA registry of possible values for the TM token, and a new value 
would need to be allocated for each token.

In this way, the difference between an SSH user and a TLS user becomes very 
clear in VACM, and the mapping from SSH username to securityName and back 
is well defined.

Comments?

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 23 Jul 2008 02:07:19 -0400

--On Friday, July 04, 2008 11:41:19 AM +0200 "tom.petch" 
<[email-masked]> wrote:

> Right, this is where we part company.  I have always believed that there
> are good operational reasons for there to be multiple sessions.  A change
> of securityLevel means a change of session and I have always seen that as
> a desirable feature eg that the mass of SNMP traffic is routine polling,
> noAuthNoPriv, while third-level support sometimes use authPriv to find
> and fix problems, and that it was important to keep them on separate TCP
> sessions, eg lest a getBulk of the 150,000 entry routing table on one
> delayed a poll on the other; or some
> such.

That has to do with operational use, not with security level.  You get 
those on separate sessions by the simple fact of the third-level support 
person being a different client than the monitoring system that does 
periodic polling.

> then I read that as saying that a change in securityLevel is a change in
> target index which leads to a different session [which I think is a good
> idea:-)].

Except that we assert that SSH sessions are always authPriv.  This is a 
basic property of the transport; you're never going to get an SSH session 
that is not authPriv.  You may get a session over which you receive 
messages whose requested securityLevel (in the SNMPv3 message) is some 
lower level, but the SSH session itself will _always_ be authPriv.  This 
has been discussed several times.

> If you are saying, use this 4-tuple as an index and for three
> parts use an exact match while the fourth must be less or equals, then I
> think that we need different words.
>
> Or if you are saying that the text means that the securityLevel is
> ignored, then again I find that a bit of a stretch.

These are actually exactly the same thing, because the SSH session will 
always be authPriv.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 23 Jul 2008 15:24:24 -0700

>>>>> On Wed, 23 Jul 2008 14:44:15 -0400, "David B. Nelson" <[email-masked]> said:

DBN> However, if an operator is using *both* SSH and TLS, for example, with
DBN> disjoint user databases having disjoint namespaces, the only ways to
DBN> fix that issue "in the transport" would be to either synchronize the
DBN> namespaces (i.e. either de jure or de facto single-sign on) or to
DBN> incorporate some form of administrative "realm" element in the user
DBN> name.  An example of such a construct may be found in the Network
DBN> Access identifier [RFC 4282].

And a solution like that makes sense.  If every secure TM transport had
to hand up a securityName from below formatted something like
"user@TMTOKEN" where TMTOKEN was SSH, DTLS, TLS or whatever was defined
by the TM transport then it would solve the uniqueness problem in a very
very easy way.

Then, if that was objectionable because people wanted a merged database
the TSM mib could have a single scalar that would enable "strip all
domain suffixes" to flatten the name space.  A single TruthValue
configurable variable is a pretty simplistic model ;-)

The downside of it is that you loose a bit of the 32 octet admin
securityName string length to include the @ sign and the TM suffix (and
for that reason, I'd suggest very short names like "ssh", "dtls", etc).

Unfortunately, RFC4282 probably isn't quiet right since it A) requires
string lengths of up to 72 octets which is longer than SNMP can handle
and B) is really designed for distinguishing realms (example.com) not
protocols (ssh), which is where this is coming from.

(the other option I considered was having the magic token spec to be
specified in the transport domain definition, but in the end I decided
the TM's should really hand it up since it otherwise requires the TSM to
directly understand every TM that it might receive a message from)

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 23 Jul 2008 21:20:08 -0400

Wes Hardaker writes...

> string lengths of up to 72 octets which is longer than SNMP can handle

One could simply specify an NAI limited to a total length of 32 octets.

> protocols (ssh), which is where this is coming from.

A rose by any other name...  While the original intent (in support of global
roaming) was to use FQDNs as the realm identifier, there is nothing inherent
in the syntax of the NAI that *requires* that to be the choice.  We could
easily substitute protocol "tags".

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 23 Jul 2008 22:33:26 -0400

> by the TM transport then it would solve the uniqueness problem in a very

This is pretty much exactly what I proposed, but with a different syntax.
I don't have a strong reason to prefer one syntax over the other, though I
think it is slightly more intuitive not to use '@' to introduce things
other than domain names.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Jul 2008 09:17:19 +0200

On Wed, Jul 23, 2008 at 02:07:22AM -0400, Jeffrey Hutzelman wrote:

> [...] In order to simplify this somewhat and also address what I believe 
> is Wes's concern (which has nothing to do with securityLevel), I'd like 
> to propose a strawman.  Specifically, I propose that for TSM, the 
> securityName always take the form "TM:name", where TM is a token 
> indicating the secure transport model in use and name is a 
> transport-specific ID.  Obviously we'd need an IANA registry of possible 
> values for the TM token, and a new value would need to be allocated for 
> each token.

Speaking as technical contributor...

Assuming the TM allows operators to configure "name" mappings. Isn't
that sufficient? Do we really have to enforce a specific mapping or
are we not better served by simply discussing the issue in the
documents and suggesting certain configurations options addressing the
issue?

For some secure transports (e.g. TLS and DTLS), there might be valid
reasons to not make a difference and so I prefer a clear separation of
mechanism and policy here.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 24 Jul 2008 04:03:58 -0400

> mechanism and policy here.

I'm inclined to say that distinguishing between secure transports in a 
useful way is something that TSM must handle, just as SNMP must handle 
distinguishing between security models.  I can see three ways to do this:

(1) Wave your hands and say that TSM must magically deal with any potential 
conflicts, but not say how.  This approach works surprisingly well for SSH 
and SASL, among other things, but does not lend itself to the sort of 
formalized, standardized configuration that people are likely to want for 
TSM.

(2) Provide a standardized mapping table in TSM, which allows configuration 
of a bidirectional mapping between that TM's transport-specific ID's and 
the transport-independent securityName.  This mapping could potentially be 
distinct for different TM's, or the same for all TM's, depending on the 
reality of the deployment.  In any case, it will need to be the case that 
for any given (TM, transport-ID) in the table there is only one 
securityName, _and_ that for any given (TM, securityName) there is only one 
transport-ID -- you have to be able to convert in both directions, but you 
don't have to be able to infer a TM from a securityName, because for 
outgoing messages you already know what TM will be used.  Naturally, the 
contents of this mapping table would be exposed in the TSM MIB.

(3) specify a standard algorithm for transforming a transport-specific ID 
into a securityName and the reverse, without resorting to a mapping table. 
This is essentially the approach that Wes and I have both proposed, where 
the transport-specific ID is concatenated with a fixed token naming the TM. 
This makes the TM in use visible at the ACM later in a predictable way, at 
the expense of some flexibility.

I'm inclined to prefer (3), because it works without anyone having to load 
configuration for every possible name, and I consider that a win.  Part of 
the goal in using existing authentication infrastructures is avoiding 
having to explicitly provision every user on every device.

Note that even if we go with (2), I think it is sufficient to have a single 
mapping table in TSM; I don't think we need an additional layer of 
username-mapping indirection in SSHTM or any other transport model.

-- Jeff

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 24 Jul 2008 08:45:38 -0400

> I'm inclined to say that distinguishing between secure transports
> in a useful way is something that TSM must handle...

If so, then I think it is incumbent upon us to describe the utility
obtained.

I think we've dismissed the issues of differing protocols, cipher-suites,
and so forth, and being irrelevant to the interests of TSM, e.g. "secure" is
always "secure enough".  So, that leaves us with the issue of multiple
authentication mechanisms that might involve multiple user namespaces.  Are
there other issues we are attempting to deal with?  Or are we also adding
the "tag" as a "hook" to deal with possible differences that someone decides
are important in the future?

> (3) specify a standard algorithm for transforming a transport-specific
> ID into a securityName and the reverse, without resorting to a mapping
> table.

Wes also suggested that this mechanism me capable of being disabled, in
those deployments where no distinction is necessary or desirable.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 24 Jul 2008 13:16:50 -0400

--On Thursday, July 24, 2008 08:45:38 AM -0400 "David B. Nelson" 
<[email-masked]> wrote:

> and so forth, and being irrelevant to the interests of TSM, e.g. "secure"
> is always "secure enough".  So, that leaves us with the issue of multiple
> authentication mechanisms that might involve multiple user namespaces.
> Are there other issues we are attempting to deal with?  Or are we also
> adding the "tag" as a "hook" to deal with possible differences that
> someone decides are important in the future?

I think we are specifically talking about distinguishing between names in 
different namespaces, which is necessary because the access control model 
can assign different access to different principals only if it can 
distinguish between them.

> those deployments where no distinction is necessary or desirable.

Yes.  The only potential problem I see with that is that doing so changes 
all of the securityNames reported by TSM.  That means that changing this 
setting may make existing access control entries using those names 
meaningless and/or cause other entries using unqualified names to start 
having effect.  It also means that life is harder (but not impossible, as 
long as the setting is exposed in a MIB) for tools that attempt to present 
a user-friendly interface for managing access control, because the meanings 
of names they use depend on this setting.  I have no position on whether 
the benefit of being able to turn off labelling outweighs this cost.

-- Jeff

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 24 Jul 2008 13:39:19 -0400

> Yes.  The only potential problem I see with that is that doing so
> changes all of the securityNames reported by TSM.

I think this is likely a "configure once" type of choice, but I see your
point.

> I have no position on whether the benefit of being able to
> turn off labeling outweighs this cost.

There is an "other side of the coin" type of added cost if there are
multiple TMs in use, with a single namespace.  In that case, each name would
need to be entered twice in the VACM table(s), with differing "labels".
Without labels, the names would only need to be entered once.

I guess we can attempt to predict whether authentication methods using
multiple namespaces would be present in the majority of deployments.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 24 Jul 2008 13:06:58 -0700

Hi -

> From: "David B. Nelson" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, July 24, 2008 10:39 AM
...
> Without labels, the names would only need to be entered once.
...

If this group had allowed itself to address the user/group VACM mapping
(which is really needed to solve the configuration problem the group
is trying to address) then this would be a non-issue.  (This whole process
started because the provisioning of USM and VACM was perceived to
be too much work.  The TMs discussed here work around the provisioning
of USM, but don't address the user/group mapping in VACM needed
to make it actually work.

Look on the bright side - if/when the WG gets around to automating
the VACM user/group mapping, the problem of the differing labels
will go "poof".

Randy

---

From: "tom.petch" <[email-masked]>
Date: Fri, 25 Jul 2008 10:03:25 +0200

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Jeffrey Hutzelman" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, July 24, 2008 9:17 AM
Subject: Re: [Isms] pre11 comments

> documents and suggesting certain configurations options addressing the
I agree; TM is the place to do the mapping.  This is a TM related issue and we
should fix it close to where the problem arises, namely in the TM.

(And, at the risk of being repetitive, there is a problem with a mapping table
in the SM with the ASIs as currently defined; fixable, but requiring a change to
the ASIs).

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 28 Jul 2008 01:48:30 -0700

>>>>> On Thu, 24 Jul 2008 13:06:58 -0700, "Randy Presuhn" <[email-masked]> said:

RP> Look on the bright side - if/when the WG gets around to automating
RP> the VACM user/group mapping, the problem of the differing labels
RP> will go "poof".

True, unless the user name "randy" is being distributed by two different
protocols but should have different access rights under one vs the
other.  The current discussions surround being able to separate
different users from different protocols so that something configuration
over some magic distribution protocol can actually work to make the
problem go "poof".
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Jul 2008 13:19:52 +0200

> over some magic distribution protocol can actually work to make the

I assume we more or less agree that we have to be able to
differentiate between names coming from different secure transport
models. Any violent disagreement with this statement?

If the above is correct, then question seems to be whether a) we by
default make all the names different leaving it to explicit
configuration to treat them the same if needed or b) we make them by
default the same leaving it to explicit configuration to make them
different where needed. Is this a fair statement?

/js

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 28 Jul 2008 09:59:12 -0400

Changing the subject line *again*...

Wes Hardaker writes...

> The current discussions surround being able to separate different
> users from different protocols so that something configuration

s/protocols/authentication mechanisms/

> over some magic distribution protocol can actually work to make 
> the problem go "poof".

This has nothing to do with the properties of any secure transport protocol
and everything to do with the practice of coupling disparate transports with
disparate sources of user authentication.  (The "USM Problem".)

I agree that we need to find a solution, but let's lay the blame for the
problem where it belongs, shall we?

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 28 Jul 2008 10:06:38 -0400

Changing the subject line...

Juergen Schoenwaelder writes...

> models. Any violent disagreement with this statement?

Yes.  I disagree.  This has nothing to do with different secure transport
models and everything to do with the underlying source of user identity.
The "tagging" needed to disambiguate the usernames needs to be tied not to
the protocol but to the source or identity, e.g. an administrative realm.
When the source of identity is the local database of the secure transport
implementation, we take the shortcut (incorrect, IMHO) of "tagging" with the
protocol name.
 
> different where needed. Is this a fair statement?

That is certainly one decision to be made.

Another is the source, syntax and semantics of the "tagging" information.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Jul 2008 16:42:29 +0200

Some time ago, we decided to treat SSH as a black box that delivers a
name that we can later (perhaps translated) use as a securityName with
securityLevel authPriv and that we do not peek into the internals of
SSH to say validate the securityLevel. Are you now saying we have to
peek into SSH internals to figure out which "realm" a name provided by
SSH belongs to?

> Another is the source, syntax and semantics of the "tagging"

Playing devil's advocate: Why do we need have to standardize this? 

As far as I can tell, the mapped name only has to be consistent with
the local ACM policy. In USM, the authenticated name is usmUserName
and the usmUserTable allows me to map this name to a security name. In
other words, with USM I can already today map usmUserName "schoenw" to
"usm:schoenw" if I like to. Likewise, with the snmpCommunityTable I
can map the community string "schoenw" to "csm+schoenw" if I want to.
With a mapping table in TSM, I may be able (depending on the table
structure) to map "schoenw" authenticated by an SSH transport to
"ssh_schoenw". Is this not good enough?

/js

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 28 Jul 2008 11:30:57 -0400

> Some time ago, we decided to treat SSH as a black box 
> that delivers a name that we can later (perhaps translated)
> use as a securityName ... Are you now saying we have to
> peek into SSH internals to figure out which "realm" a name
> provided by SSH belongs to?

I guess I'm saying that SSH should deliver a "decorated" name that contains
that information.  That might be out of scope for ISMS, though.  It's
frustrating when the architecture design is hemmed in by charter
constraints.  :-(

In the case where the local database of the protocol is used to authenticate
the user, it may be sufficient to "tag" the identity with the protocol name,
as the protocol name and the namespace name are one in the same.  This is
common case, but by no means the most general case, however.  I just want to
see that whatever we specify works in the most general case.

> Playing devil's advocate: Why do we need have to standardize

I suppose if the use of the "tag" is entirely within the scope of an
implementation, e.g. it does not appear in any MIB objects, we need not
standardize it.  It's only when the choices made by disparate
implementations are exposed to organization-wide management tools that we
require consistency.  It's not [yet] clear to me that the "tags" are
"private data" of the implementation, and not exposed to other systems.  The
discussion of mapping tables leaves open the possibility that the "tags" are
"public data".

> As far as I can tell, the mapped name only has to be consistent
> with the local ACM policy.

Well, doesn't that expose the "tags" to other systems?  In a multi-vendor
environment, wouldn't that mean that the configuration of ACM policy across
the organization would need to be customized on a per-vendor basis?  I see
that as a negative.

> Is this not good enough?

Maybe it's "too" good, i.e. it offers sufficient flexibility to inhibit
multi-vendor interoperability (if not used carefully).

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Jul 2008 18:03:56 +0200

> multi-vendor interoperability (if not used carefully).

With USM and CSM, we have a mapping mechanism in place that allows
operators to _configure_ mappings as they see fit. With TSM, can we
not provide a similar mechanism allowing operators to _configure_
mappings when needed? The mappings then become part of the SNMP
configuration and I do not see a multi-vendor interoperability issue
(at least nothing worse than what we are used to ;-).

We need to figure out how we can keep simple installations simple and
put the costs on more complex installations. This might require to
think about a wildcarding mechanisms that allows me to specify a
policy such as "all SSH user names not listed in the table are passed
unaltered as securityNames" or "all TLS/DTLS names not found in the
table are mapped to a specific securityName (so VACM can deny access
for example)".

/js (still speaking as technical contributor)

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 28 Jul 2008 13:09:20 -0400

> The mappings then become part of the SNMP configuration and
> I do not see a multi-vendor interoperability issue

Well, perhaps.  I thought part of the issue with non-deployment of SNMPv3
that we are attempting to solve was that the configuration required today
*is* too complicated.

> We need to figure out how we can keep simple installations
> simple and put the costs on more complex installations.

OK, that *sounds* good.

> This might require [us] to think about a wildcarding mechanism
> that allows me to specify a policy such as "all SSH user names
> not listed in the table are passed unaltered as securityNames" or 
> "all TLS/DTLS names not found in the table are mapped to a 
> specific securityName (so VACM can deny access for example)".

The issue arises when there are multiple authentication methods (i.e.
multiple user namespaces).  That most often occurs with there are multiple
transport protocols.  I think that is likely already outside the "80% rule",
and that the simple case is a single protocol with a single user namespace.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 28 Jul 2008 14:40:04 -0400

Allow me to clarify my remarks.

> Playing devil's advocate: Why do we need have to standardize this?

If any portion of the name mapping or tagging scheme is not end-user
configurable, it would need to be standardized.  Otherwise, the name that
the ACM is confronted with may be implementation dependent.  That would
introduce multi-vendor interoperability issues, as the ACM table
provisioning would have to take this vendor dependence into account.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Jul 2008 00:11:44 +0100

--On Monday, July 28, 2008 11:30:57 AM -0400 "David B. Nelson" 
<[email-masked]> wrote:

> I guess I'm saying that SSH should deliver a "decorated" name that
> contains that information.  That might be out of scope for ISMS, though.
> It's frustrating when the architecture design is hemmed in by charter
> constraints.  :-(

It is a design feature of ISMS that we delegate to SSH the entire problem 
of mapping names coming from potentially disparate authentication 
namespaces into a common namespace which is provided to us.  This is a 
feature because SSH has to (and does) solve it anyway.

If we extend this approach to every future secure transport mapping, such 
that all such mappings can be expected to deal with any differences or 
false similarities between names used by their authentication mechanisms, 
then we are left only with the problem of dealing with differences and/or 
false similarities between names provided us by different possible secure 
transports.

One possible approach for this is to deliver to the application and access 
control model a securityName that consists of the name provided by the 
secure transport, decorated with an identifier indicating which transport's 
namespace it belongs to.  And yes, the namespace belongs to a transport 
model, not to an authentication method, because it is the result of the 
transport model and/or the underlying transport having resolved conflicts 
between possible authentication methods and applied appropriate mappings. 
If I use SSH-gss-krb5 to log in to your ssh server, the username SNMP gets 
to see will not be my Kerberos principal name; it will be my SSH username, 
which is virtually never the same.

Another possible approach is to invent the concept of a "TSM" namespace 
which is transport-independent.  If we do this, there must be a mapping 
from names specific to a particular secure transport (again, NOT an 
underlying authentication method) to TSM names.  This could be done by a 
table in TSM mapping (transport, transport-name) tuples to TSM names on the 
way up, and (transport, TSM-name) tuples to transport names on the way 
down.  Or it could be done by a table in each secure transport model 
providing a bidirectional mapping between transport names and TSM names in 
the context of that transport.

Basically, the question is, where do you want to deal with the issue that 
different secure transports may use different namespaces?  We can deal with 
it in the secure transport model, or in TSM, or in VACM.  The advantage to 
dealing with it further down is that the higher layers don't have to care 
about it in the case where there aren't multiple distinct namespaces 
(either because only one secure transport is used or because multiple 
transports are used that export the same names for all the names you care 
about).  The advantage to dealing with it further up is that the lower 
levels don't have to do something special when the names _are_ different, 
and that you don't have a situation where a new transport appears with 
different names, some admin forgets (or doesn't know) to turn it off, and 
now there are clients who can get access to his system that they're not 
supposed to have.

> "private data" of the implementation, and not exposed to other systems.
> The discussion of mapping tables leaves open the possibility that the
> "tags" are "public data".
>
> environment, wouldn't that mean that the configuration of ACM policy
> across the organization would need to be customized on a per-vendor
> basis?  I see that as a negative.

I think it does, and that therefore the "tags" must be standardized.

-- Jeff