Subject: [Isms] DRAFT minutes for ISMS

From: Ken Hornstein <[email-masked]>
Date: Tue, 09 Nov 2004 15:46:49 -0500

Howdy all,

Here is a draft minutes for the ISMS WG meeting yesterday.  Please let me
know if you have any comments or suggestions.  Particularly let me know
if I've misattributed something in the minutes.

--Ken

DRAFT Minutes for the Integrated Security Model for SNMPv3 (ISMS) WG
IETF 61, November 8th, 2004

The meeting was opened by chairs Ken Hornstein (KH) and Juergen Quittek (JQ).

(JQ) - Review of meeting goals

       Oct 4 cut off for proposal submission
       Nov we decide which solution

       Currently there are three proposals:

       SBSM - A higher-level approach
       EUSM - Straight forward extension of USM to support AAA
       TLSM - SNMP over TLS (or some other transport mapping service).

Traditional agenda bashing was next (minor changes to the order were
suggested, but the original agenda order was kept).

(JQ) - procedure Question, due we want to create evaluation team to
       decide on which proposal?

Wes Hardaker (Wes) - maybe only examine proposals that work group
                     want (i.e. not necessarily all three)

JQ - let's select criteria for proposal acceptance 

Unknown - Perhaps we should use proposals to drive requirements

Wes - lets bring it back to talking about criteria again

Dave Perkins (DP) - looking at what drives operations for the same,
we should look at each proposal to see if we can reduce the pain
level for managers to use and implement.

Ken - Our charter:
      maximize usability in environment
      integration into existing infrastructures.
      must not modify SNMPv3 protocol
      should be compliant with SNMPV3 security model, RFC 3411/2
      if at all possible, don't change any other protocols

Unknown - make sure existing SNMPv3 support isn't changed

Ken - we're still going over charter right now.

Ken - discussion of per-PDU encryption on the list, regarding the
ability to have different encryption/authentication per PDU

Wes - point of order, what things are in scope at this point are we
listing anything (i.e. goals and/or requirements?),

JQ - we should make a difference between requirements and nice to
haves

Wes - I believe one of requirements is must not decrease security.

Ken - technically that is not in charter

Wes - It has been discussed before.

Jürgen Schönwälder (JS) - what does that mean?

Wes - we can't create a new protocol that doesn't provide same
strengths that USM provides.  But some of operators didn't like
strengths USM provides, they send passwords in clear so that they
can log in to the machines.  i.e. they don't find USM usable, so
there may be some question as to what strengths we need to support.
But we should have encryption / authentication capability and the
protection of breaking one client not breaking all clients.

Unknown - Operators pass passwords in clear for convenience; they prefer
	  convenience in this case instead of security.

Jeff Case (JC) - I'm concerned about usability line derived from the
charter, can it be broken into 4 things from the line in charter:
usability, deployment success, minimize implementation cost, quick
time to market...

usability
minimum implementation cost
minimum deployment cost
time to market

JC - should we consider what they export/import restrictions in top
countries in world so that the technology selected is acceptable to
most/all of them

Steve Belovin (SB) [AD] - we design technically sound protocols, let
the lawyers fight over legal acceptability.

Unknown - questioning usability, be clearer on what we do mean.

Ken - example of problem with USM, large scale re-keying of
passwords... In the eye of the beholder. 

JQ - usability, what functions are needed and how easy is it to use them

Michael St.John? (MSJ) - should differentiate between agent and
manager

Sam Hartman (SH) - deployment ease : security should work with existing the
authentication infrastructure you have

Wes - operator desirability, operators have varying environments so
we should have flexibility in ISMS, (within reasons).  Would
operators want to use it?, would someone actually start using it?

JQ - desirability

Wes - should we strike usability

JQ - we're high in abstraction, we should be talking about a lower
level

DH - 7 (integration into infrastructure) should be split into two
parts, management and security integration

Ken - management is done by SNMP proper

DH - snmp parity as example, it was nice and secure but one had to
go to the box to configure.  people use HP OV to find devices on
network but had to configure box before it could be discovered, it
wasn't usable.

DP - somewhat different view that when someone deploys a new box, if
they just plug it into the network, they have unreal expectations if
they think the can, without configuration, manage it and manage it
securely.  Many different ways to do initial configuration, but
something that may not be obvious to anyone is that wouldn't it be
nice if they didn't have to do anything extra to integrate with
SNMPv3.  Should go through use cases.

DH - said you disagreed with what I said, but I just meant we should
be able to do discovery

DP - but I disagree, you should need to configure a box when putting
it on a network

DH - but I want to find a rogue box put on network.

Ken - I think both are compatible

DP - but different way of looking on world, a manager will need to
configure any device put on network

Unknown - don't break basic discovery.

JQ - let's move this discussion off-line

Unknown - we should support engine ID discovery for example

JQ - on the list we have integration into infrastructure, let's keep
requirements, but we can discuss details later.

Uri - change item 12 ???

Ken - since we're not changing SNMPv3, USM is still there, engine ID
discovery could be done via USM, just to throw an idea out there

JQ - does any one think we should have more criteria here?

DH - re URI, in RFC 3412 noAuthNoPriv specified in architectural
portion not security portion.

---

TLSM proposal			Dave Harrington

Transport Mapping Security Model

lot's of people on list said they wanted to see a TLS model, so I
did one.  Not a strong proponent but I thought it needed to be done.

Lower Layer protocols,  TLS, DTLS, SASL, SSH, others...

tried to create a proposal that would allow fitting a transport
layer mapping to the SNMP engine.

different protocols provide different services.

TM model, should understand what service mechanisms? available,
which services, which security principle

DP - from the list, if we provide lower level transport, do you
ignore the security level field in PDU or does it have to match the
transport or what.  How do these interact?

DH - message flags are SNMP requirements, that must be communicated
to lower layer.

Bert Wijnen (BW) [AD] - on the receiving side if the two don't
match, what do you do. It just needs to be worked out.

DH - quick tangent, this was a last minute proposal, a new version
of the proposal was published and a lot of these questions are
answered in it. In the new version the MP portion does same analysis
of message to see if security level maps to session.  If PDU
security level is greater than session it is dropped. undecided what
to do if it PDU security level is less than session.

Don't Know - alternative thing, ???, this is case that it isn't an
attack but a bug in implementation

Wes - the current draft doesn't talk about parameters to pass
between different lower level protocols.

DH - the appendix does have some mappings of security wrappings

JC - addressing DP questions, the ASI at the invoker says wants to
use a particular security level / security model.  What's in the PDU
may not match the security level of the SM or of the ASI information
to the application.... The message wrapper of security model may
need separate security bits to indicate security level and info
separate from security level in PDU.

DP - need clarification of ASI's

JC - a proposal would need to define, in separate bits or others ???

Gary? - no complete control between layers...

DH - in first iteration, I was going to pass to sets of bits,
security model level and message and placed in security parameters.
Didn't think ASN.1'ing of that was worthwhile. So new version of
draft uses cache, a pointer is passed to indicate a session's
security information for a packet.

Randy? - should probably skip some of the technical aspects here
and discuss on list

Wes - just though of another problem.  if encrypt packets that the
manager doesn't know are encrypted it will mess up benchmarking.
And more importantly it could mess up what is sent to VACM for
access control.

DH - if they don't match, ???

Randy - don't mess with flags if you need more security, it means
you need to create a new channel (session).

Unknown - how to handle different credential types with underlying
transports.  talks about Transpor Layer - SNMP transaction but not
with security negotiations within the transport layer.

JQ - next presentation, please.

Wes - update of ISMS

quick overview
current is draft-hardaker-snmp-sbsm-03.txt

creates session between two points

3 phases, init, running , closing

The init PDU'S are get and report PDU's.  Applications never see
these PDU's.  This is similar to engieID discovery or time synching
today)

picture of message flow...

Re-uses all existing transports because not tied to it.  SNMPv3
architecture, application compliant re-uses exist authentication
systems to extend authentication definitions.  compression, id
disclosure protection, replay protection, negation but rigid???

based on SIGMA

already have basic implementation
19.5 hours to implement (with a developer that has expert knowledge
SNMP toolkit used)

Eric - it's a re-invent of IKE

Wes - much simpler than IKE, based on SIGMA not IKE

Eric - both based on STS, I think that it's more complex than it
looks.  Adding new authentication schemes will each add a large
amount of complexity.  IKE's complex, but it is finished.

Wes - I agree that inter-operability needs are important... ???

Eric - TLS took a long time to finalize exchanges, 2-4 years

Wes - 1-2 pages to define, but that doesn't count WG consensus time.
      The current way is simple...???

Eric - key exchange will get complicated very fast.

Unknown - haven't read draft, but flow diagram seems to violate
some of the layers... How is closing done? 

Wes - applications can close, low layer library can close.  It can
be an application decision, a toolset issue not a protocol issue

Nico Williams (NW) - besides echoing Eric, we (ietf) already have a lot of
key exchange protocol, I don't want to see another.  One thing that
worries me is that you're deriving keys for the existing v3 model.

Wes - no, only two modes defined in USM

NW - if transport layer model is rejected, you might want to
consider the way per PDU protection is done ??? adding new
mechanisms to SNMPv3

NW - adding new mechanisms to SNMPv3 not within charter

Wes - the reasons the modes are there today, is that is what is
available to SNMPv3.

NW - lastly shouldn't create a new key exchange protocol

Wes - you could conceivable do IKE within in SNMPv3, but IKE has
lots of deployment problems. I think we have two choices, place
authentication / encryption in lower layer underneath or you do it
within SNMP.

Eric - three levels, lower layer, SNMP, or side negotiations.  It is
a choice between transport mapping and application specific protocol
and which integrates better into SNMPv3 model. choice of which key
exchange protocol to use determined by assessment of applicability
of exchange models to user environment.

Wes - some background, one purpose of ISMS is to fix a major
complaint.  People are not using authentication mechanisms of
SNMPv3.

Eric - at minimum there are already at least 4 ways to do key
exchange and they support multiple protocols.

Wes - so many mechanisms in use. it's difficult to choose.

Unknown - pick one but don't go with all of them.

Wes - I agree... I designed an architecture that would let this work
group pick one.

Unknown  - shouldn't try to meet all cases.

EUSM presentation -- Kaushik Narayan  (KN)

I'll talk about changes and uniqueness from other proposals.

no new fields, but it uses existing SNMPv3 - USM as described in
RFCs

few small changes, setting up session is a high cost, so a goal was
to have the session / key negotiation setup be done by third party.
It uses existing key exchange protocols.

EAP was one example in draft, but not only one possible.

Randy - how does agent know what keying info to use with info from
radius server.

Dave Harrington - SNMPv3 created engine ID, because a
differentiation was necessary. We need to the engine id for this.

KN - caching, typical duration of 90-180 seconds for a 'session'.

JC - why choose that length.

KN - time window is not definitive just an example.  want to avoid
keeping keys on an agent for a long duration, but time should be
configurable. It's not hard coded. It is configurable.

KN - have a prototype implementation in AAA server and Cisco Works
product.  A motivations was as minimal changes to SNMP as possible,
and also to make sure that peer to peer exchanges for key creation was not
necessary (so use of third party AAA server)

DP - have you come out with a new draft.

KN - not yet

DP - In the current draft, it talked about in-band set up of
keys. Is that expanded upon in new draft?

KN - It will be covered in new draft.

DP - in draft and presentation the term AAA was used, this is fuzzy
to me what does this mean more precisely Radius, TACX+?, etc...

KN - when I'm talking about AAA in this context, I've been talking
about Radius and TACX+, but I want to make the protocol more generic
to allow others AAA servers.

DP - ??? (question of fuzzyness of AAA term)

KN - It does not require change in protocol to support different
types of AAA servers.

DP - It sound like you've done use case analysis, but I haven't seen
a use case of what to do when one adds a new box, adds a new user,
deletes a user,... ???

KN - reason to integrate with AAA servers is so that adding/deleting
user is covered by adding deleting user to AAA servers.  Other
proposals don't show these use cases either.  Should we cover these
use cases?

DP - use cases covered in IBSM in BOF's

Wes - should the WG require the use case?

DP - I'd like concrete steps to be able to understand how the
protocols work.

DH - I think that would be very useful

Gary - and it would apply to all proposals

DP - absolutely

Wes - ???... people still need to use USM, big difference because
the users today that don't use USM now, won't use it in the future
if AAA server is down (faulty network case???).

KN - ???

Wes - one USM user is required in this case and the operators do not
have any currently.

KN - if an authentication mechanism of local user is required, EUSM
could add it easily. IBSM would have same problem.

Wes - local user's already exist and IBSM can use local user, EUSM
still requires a local USM user which don't exist.

Gary - Could you clarify that?

Wes - EUSM still requires AAA server, if the network is broken this
is a problem.

KN - can fall back to USM users?

Gary? - if network not up, can't talk to machine anyway?

Ken - using other servers in the past have raised many complaints in
the SNMP community.

Gary? - biggest comment is shortness of key lifetime, but should
discuss on mailing list.

DP - We should accept that we sometimes need quick revocation of
keys (e.g. if someone is fired)

Randy - a comment on all proposals.  The reason integration of
current security models is important is because operators want to
log onto a machine without knowing how well or sick a network is.
So with a fall back to a local account, you'd really like the
mechanism to allow the same account to be able to fall back to the
same user?

KN - we'll clarify fall back to USM in draft.

Ken - should take this to mailing list.

Gary? - this issue will exist with any mechanism except local
accounts.  For revocation, either need to check over the network or
fall back.

Unknown - The way a broken device is handle today in operations,
it requires special procedures to fall back to a local user.
Particular you can't assume you can use the same credentials on the
box as off.

DH - I was wondering how much radius is used on core devices

KN - I think it's pretty universal for edge or core.

DH - in SNMP architecture we deliberatively moved away from manager-agent
terminology and your draft uses those terms.

KN - I need to clean up terminology in draft.

DH - can the key from the manager side be used for informs?

KN - one of the things we worried about is should the agent have to
talk to the AAA server ...???..., think we should discuss this on
list.

DH - ??
KN - ??

DH - can a radius server revoke a key?

KN - handle this via shortened key lifetime (although master key
could be revoked on server)

JQ - go back to criteria list, check blue sheets what are some of
the key differences in proposals?

KN - I think one of the big difference is use of third party by EUSM
for key acquiring.

Unknown - ??? something like EUSM sounds like a good idea with
fall back to USM is good but replication of all users to all devices
is bad idea.

KN - I think fall back has been beaten to death but not any different
from fall back to CLI or Netconf??

Unknown - not disagreeing, just want to reiterate, don't
replicate authentication of DB's everywhere

JQ - any difference of proposals for 

- no decrease of security

Wes - .... difficult to cover this in one spreadsheet row

JC - should replay protection be optimal or mandatory?

Randy - is available a bit in SNMP via some parameters

Eric - ... let's concentrate on inherent design of protocols and
not minor details.

JQ - close additional security features, items 9, 10, 11 are all
good let's discuss integration (8).

JC - should have chart show: same as USM, more than USM, or less
than USM, instead of OK

JQ - we agree they all have at least as much, but which has more
we're unable to resolve today.

Wes - ... probably won't be able solve discussion of which is more
secure today.

Randy - one thing they all have in common is the use of sessions.
With the introduction of that concept we might want to examine how
many exchanges it takes to initialize a session and to close
a session.  What types of operations to add/delete user in the big
sense.  How long to propagate that knowledge out to nodes.

Eric - want to look at big picture, the key important question is,
what type of architecture do you want.  One bound tightly to SNMP,
like EUSM (IBSM??), layered on top, like TLSM, external keying
system that wires into SNMP, like EUSM.  Many of these proposals are
orthogonal to requirement choices?

Wes - do we have time to make major changes to proposals.

Unknown - .... can we make a choice between to instead of three.

Ken - not sure we have consensus to remove one.

Wes - ... a significant difference between IBSM and EUSM, EUSM
forces third party keying.

KN - (respond to EUSM not be scaling any better than Kereberos?), a
motivation for EUSM proposals, we wanted to make sure that we made
as minimal a change to SNMP as possible because we have code already
and wanted to minimize the cost to upgrade.

Sam? - speaking as future AD, it would be difficult to get
architecture choice by March.

JQ - I don't think we can drop any of the three, so we will pass all
three onto to evaluation team.  

Ken - listed possibles, 4-5, for evaluation team

DP - any operations people

Ken - any here that want to volunteer

DH - want to know how many of the operators think all three of these
are viable. I'd like to eliminate one of these.  Particular I think
we should drop the TLSM (DH's) proposal.

JQ - don't think we can resolve this today.

Wes - one of the goals to pick quickly is because we have a very
tight deadline.  If the AD's want us to consider all the proposals,
I'm worried we won't make our deadlines.

Sam? - I don't care if one is dropped on the mailing list, I don't
think there is enough time today to make a good decision.

With no further discussion, the meeting was closed.

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 10 Nov 2004 10:41:49 -0500

hi

Jabber 

http://www.xmpp.org/ietf-logs/[email-masked]/2004-11-08.html

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ken Hornstein
Sent: Tuesday, November 09, 2004 3:47 PM
To: [email-masked]
Subject: [Isms] DRAFT minutes for ISMS

Howdy all,

Here is a draft minutes for the ISMS WG meeting yesterday.  Please let me
know if you have any comments or suggestions.  Particularly let me know if
I've misattributed something in the minutes.

--Ken

DRAFT Minutes for the Integrated Security Model for SNMPv3 (ISMS) WG IETF
61, November 8th, 2004

The meeting was opened by chairs Ken Hornstein (KH) and Juergen Quittek
(JQ).

Dave Perkins (DP) - looking at what drives operations for the same, we
should look at each proposal to see if we can reduce the pain level for
managers to use and implement.

Ken - Our charter:

Ken - discussion of per-PDU encryption on the list, regarding the ability to
have different encryption/authentication per PDU

Wes - point of order, what things are in scope at this point are we listing
anything (i.e. goals and/or requirements?),

JQ - we should make a difference between requirements and nice to haves

Wes - we can't create a new protocol that doesn't provide same strengths
that USM provides.  But some of operators didn't like strengths USM
provides, they send passwords in clear so that they can log in to the
machines.  i.e. they don't find USM usable, so there may be some question as
to what strengths we need to support. But we should have encryption /
authentication capability and the protection of breaking one client not
breaking all clients.

Jeff Case (JC) - I'm concerned about usability line derived from the
charter, can it be broken into 4 things from the line in charter: usability,
deployment success, minimize implementation cost, quick time to market...

usability

JC - should we consider what they export/import restrictions in top
countries in world so that the technology selected is acceptable to most/all
of them

Steve Belovin (SB) [AD] - we design technically sound protocols, let the
lawyers fight over legal acceptability.

Ken - example of problem with USM, large scale re-keying of passwords... In
the eye of the beholder. 

Michael St.John? (MSJ) - should differentiate between agent and manager

Wes - operator desirability, operators have varying environments so we
should have flexibility in ISMS, (within reasons).  Would operators want to
use it?, would someone actually start using it?

JQ - desirability

JQ - we're high in abstraction, we should be talking about a lower level

DH - 7 (integration into infrastructure) should be split into two parts,
management and security integration

DH - snmp parity as example, it was nice and secure but one had to go to the
box to configure.  people use HP OV to find devices on network but had to
configure box before it could be discovered, it wasn't usable.

DP - somewhat different view that when someone deploys a new box, if they
just plug it into the network, they have unreal expectations if they think
the can, without configuration, manage it and manage it securely.  Many
different ways to do initial configuration, but something that may not be
obvious to anyone is that wouldn't it be nice if they didn't have to do
anything extra to integrate with SNMPv3.  Should go through use cases.

DH - said you disagreed with what I said, but I just meant we should be able
to do discovery

DP - but I disagree, you should need to configure a box when putting it on a
network

DP - but different way of looking on world, a manager will need to configure
any device put on network

Uri - change item 12 ???

DH - re URI, in RFC 3412 noAuthNoPriv specified in architectural portion not
security portion.

---

lot's of people on list said they wanted to see a TLS model, so I did one.
Not a strong proponent but I thought it needed to be done.

tried to create a proposal that would allow fitting a transport layer
mapping to the SNMP engine.

TM model, should understand what service mechanisms? available, which
services, which security principle

DP - from the list, if we provide lower level transport, do you ignore the
security level field in PDU or does it have to match the transport or what.
How do these interact?

DH - message flags are SNMP requirements, that must be communicated to lower
layer.

Bert Wijnen (BW) [AD] - on the receiving side if the two don't match, what
do you do. It just needs to be worked out.

DH - quick tangent, this was a last minute proposal, a new version of the
proposal was published and a lot of these questions are answered in it. In
the new version the MP portion does same analysis of message to see if
security level maps to session.  If PDU security level is greater than
session it is dropped. undecided what to do if it PDU security level is less
than session.

Don't Know - alternative thing, ???, this is case that it isn't an attack
but a bug in implementation

Wes - the current draft doesn't talk about parameters to pass between
different lower level protocols.

JC - addressing DP questions, the ASI at the invoker says wants to use a
particular security level / security model.  What's in the PDU may not match
the security level of the SM or of the ASI information to the
application.... The message wrapper of security model may need separate
security bits to indicate security level and info separate from security
level in PDU.

DH - in first iteration, I was going to pass to sets of bits, security model
level and message and placed in security parameters. Didn't think ASN.1'ing
of that was worthwhile. So new version of draft uses cache, a pointer is
passed to indicate a session's security information for a packet.

Randy? - should probably skip some of the technical aspects here and discuss
on list

Wes - just though of another problem.  if encrypt packets that the manager
doesn't know are encrypted it will mess up benchmarking. And more
importantly it could mess up what is sent to VACM for access control.

Randy - don't mess with flags if you need more security, it means you need
to create a new channel (session).

Unknown - how to handle different credential types with underlying
transports.  talks about Transpor Layer - SNMP transaction but not with
security negotiations within the transport layer.

Wes - update of ISMS

quick overview

The init PDU'S are get and report PDU's.  Applications never see these
PDU's.  This is similar to engieID discovery or time synching
today)

Re-uses all existing transports because not tied to it.  SNMPv3
architecture, application compliant re-uses exist authentication systems to
extend authentication definitions.  compression, id disclosure protection,
replay protection, negation but rigid???

based on SIGMA

already have basic implementation
19.5 hours to implement (with a developer that has expert knowledge SNMP
toolkit used)

Eric - both based on STS, I think that it's more complex than it looks.
Adding new authentication schemes will each add a large amount of
complexity.  IKE's complex, but it is finished.

Unknown - haven't read draft, but flow diagram seems to violate some of the
layers... How is closing done? 

Wes - applications can close, low layer library can close.  It can be an
application decision, a toolset issue not a protocol issue

Nico Williams (NW) - besides echoing Eric, we (ietf) already have a lot of
key exchange protocol, I don't want to see another.  One thing that worries
me is that you're deriving keys for the existing v3 model.

NW - if transport layer model is rejected, you might want to consider the
way per PDU protection is done ??? adding new mechanisms to SNMPv3

Wes - the reasons the modes are there today, is that is what is available to
SNMPv3.

Wes - you could conceivable do IKE within in SNMPv3, but IKE has lots of
deployment problems. I think we have two choices, place authentication /
encryption in lower layer underneath or you do it within SNMP.

Eric - three levels, lower layer, SNMP, or side negotiations.  It is a
choice between transport mapping and application specific protocol and which
integrates better into SNMPv3 model. choice of which key exchange protocol
to use determined by assessment of applicability of exchange models to user
environment.

Wes - some background, one purpose of ISMS is to fix a major complaint.
People are not using authentication mechanisms of SNMPv3.

Eric - at minimum there are already at least 4 ways to do key exchange and
they support multiple protocols.

Wes - I agree... I designed an architecture that would let this work group
pick one.

no new fields, but it uses existing SNMPv3 - USM as described in RFCs

few small changes, setting up session is a high cost, so a goal was to have
the session / key negotiation setup be done by third party. It uses existing
key exchange protocols.

Randy - how does agent know what keying info to use with info from radius
server.

Dave Harrington - SNMPv3 created engine ID, because a differentiation was
necessary. We need to the engine id for this.

KN - time window is not definitive just an example.  want to avoid keeping
keys on an agent for a long duration, but time should be configurable. It's
not hard coded. It is configurable.

KN - have a prototype implementation in AAA server and Cisco Works product.
A motivations was as minimal changes to SNMP as possible, and also to make
sure that peer to peer exchanges for key creation was not necessary (so use
of third party AAA server)

KN - not yet

DP - In the current draft, it talked about in-band set up of keys. Is that
expanded upon in new draft?

DP - in draft and presentation the term AAA was used, this is fuzzy to me
what does this mean more precisely Radius, TACX+?, etc...

KN - when I'm talking about AAA in this context, I've been talking about
Radius and TACX+, but I want to make the protocol more generic to allow
others AAA servers.

KN - It does not require change in protocol to support different types of
AAA servers.

DP - It sound like you've done use case analysis, but I haven't seen a use
case of what to do when one adds a new box, adds a new user, deletes a
user,... ???

KN - reason to integrate with AAA servers is so that adding/deleting user is
covered by adding deleting user to AAA servers.  Other proposals don't show
these use cases either.  Should we cover these use cases?

DP - I'd like concrete steps to be able to understand how the protocols
work.

DP - absolutely

Wes - ???... people still need to use USM, big difference because the users
today that don't use USM now, won't use it in the future if AAA server is
down (faulty network case???).

KN - ???

Wes - one USM user is required in this case and the operators do not have
any currently.

KN - if an authentication mechanism of local user is required, EUSM could
add it easily. IBSM would have same problem.

Wes - local user's already exist and IBSM can use local user, EUSM still
requires a local USM user which don't exist.

Wes - EUSM still requires AAA server, if the network is broken this is a
problem.

Ken - using other servers in the past have raised many complaints in the
SNMP community.

Gary? - biggest comment is shortness of key lifetime, but should discuss on
mailing list.

DP - We should accept that we sometimes need quick revocation of keys (e.g.
if someone is fired)

Randy - a comment on all proposals.  The reason integration of current
security models is important is because operators want to log onto a machine
without knowing how well or sick a network is. So with a fall back to a
local account, you'd really like the mechanism to allow the same account to
be able to fall back to the same user?

Gary? - this issue will exist with any mechanism except local accounts.  For
revocation, either need to check over the network or fall back.

Unknown - The way a broken device is handle today in operations, it requires
special procedures to fall back to a local user. Particular you can't assume
you can use the same credentials on the box as off.

KN - one of the things we worried about is should the agent have to talk to
the AAA server ...???..., think we should discuss this on list.

DH - ??
KN - ??

KN - handle this via shortened key lifetime (although master key could be
revoked on server)

JQ - go back to criteria list, check blue sheets what are some of the key
differences in proposals?

KN - I think one of the big difference is use of third party by EUSM for key
acquiring.

Unknown - ??? something like EUSM sounds like a good idea with fall back to
USM is good but replication of all users to all devices is bad idea.

KN - I think fall back has been beaten to death but not any different from
fall back to CLI or Netconf??

Unknown - not disagreeing, just want to reiterate, don't replicate
authentication of DB's everywhere

Eric - ... let's concentrate on inherent design of protocols and not minor
details.

JQ - close additional security features, items 9, 10, 11 are all good let's
discuss integration (8).

JC - should have chart show: same as USM, more than USM, or less than USM,
instead of OK

JQ - we agree they all have at least as much, but which has more we're
unable to resolve today.

Wes - ... probably won't be able solve discussion of which is more secure
today.

Randy - one thing they all have in common is the use of sessions. With the
introduction of that concept we might want to examine how many exchanges it
takes to initialize a session and to close a session.  What types of
operations to add/delete user in the big sense.  How long to propagate that
knowledge out to nodes.

Eric - want to look at big picture, the key important question is, what type
of architecture do you want.  One bound tightly to SNMP, like EUSM (IBSM??),
layered on top, like TLSM, external keying system that wires into SNMP, like
EUSM.  Many of these proposals are orthogonal to requirement choices?

Wes - ... a significant difference between IBSM and EUSM, EUSM forces third
party keying.

KN - (respond to EUSM not be scaling any better than Kereberos?), a
motivation for EUSM proposals, we wanted to make sure that we made as
minimal a change to SNMP as possible because we have code already and wanted
to minimize the cost to upgrade.

Sam? - speaking as future AD, it would be difficult to get architecture
choice by March.

JQ - I don't think we can drop any of the three, so we will pass all three
onto to evaluation team.  

DH - want to know how many of the operators think all three of these are
viable. I'd like to eliminate one of these.  Particular I think we should
drop the TLSM (DH's) proposal.

Wes - one of the goals to pick quickly is because we have a very tight
deadline.  If the AD's want us to consider all the proposals, I'm worried we
won't make our deadlines.

Sam? - I don't care if one is dropped on the mailing list, I don't think
there is enough time today to make a good decision.