======================================
Minutes of the ISMS session at IETF 64
Tuesday November 8, 13:00 h - 15:00 h
notes taken by David Partain
======================================

Integrated Security Model for SNMP working group

Chairs: Juergen Quittek         
        Juergen Schoenwaelder   


1. Discussed Internet drafts
----------------------------

[1] Transport Mapping Security Model (TMSM) for the 
    Simple Network Management Protocol, 
    

[2] Secure Shell Security Model for SNMP, 
    


2. Session Summary
------------------

The ISMS WG was re-chartered in October. The first documents
complying with the new charter were discussed at the meeting.
Discussions focused on the resolution of open technical issues
concerning the operation of SNMP over SSH. Several issues have
been closed. But since the WG did run out of time, several
still open issues have to be resolved on the mailing list.

The ISMS WG needs support from the RADEXT working group concerning
the specification of RADIUS attributes for transport mapping security
models. The ISMS WG will specify the RADIUS authentication and
authorization mapping model for SNMP, but the actual attributes need
to be specified by the RADEXT WG.


3. Action Items
---------------

 - define RADIUS requirements and feed them to the RADEXT WG
 - revise the transport mapping security model document
 - revise the SSH security model document


4. RADEXT Report
----------------

David Harrington presented to RADEXT that we need some attributes for
mapping user names to policy names for use by access control models
such as VACM.  RADEXT in general seemed willing to support this
effort.  ISMS however needs to work out the requirements. Since RADEXT
is behind some of their milestones, they are probably not going to
jump on ISMS related work right away.

Glen Zorn: The best thing you could do instead of waiting for RADEXT
is to write a draft, run it by them, and with any luck it'll be done.


5. Secure Shell Security Model Issues
-------------------------------------

Most of the meeting time was spend discussion open issues. Dave
Harrington lead the discussion based on the slides he prepared. Below
is a short summary of the discussions, indexed by the open issue
number used on the slides. The narrative notes taken by the note taker
can be found in the Appendix A.

[2a] Server authentication is a requirement and SSH will take care of
     it via the host authentication mechanism.

[2b] The SSHSM should generally trust the SSH layer to do its job and
     not try to verify whether SSH really got it right.

[2c] The security considerations should spell out different ways how
     clients can learn host keys (e.g., first time discovery with
     operator check or pre-configured host keys) and to leave the
     decision to the operators which solution they prefer.

[8]  The relationship between the SSH server identity (basically its
     host name) and SNMP context engineIds remains unclear. There seem
     to be two related issues: a) how to handle multiple contexts
     using a single SSH server and b) how to bind the authenticated
     host name to engineIds. This issue needs further discussion.

[12] There was some notion in the room to allow SSH to always provide
     auth/priv services, even in cases where less is requested by the
     SNMP security level parameter.
     
     SSH supports a null cipher. The security considerations perhaps
     should explain that usage of the null cipher is generally not
     expected, even though implementations might support it for
     special cases (e.g. someone running ISMS over a secure IPsec
     tunnel or environments where encryption is illegal).

[13] SSH does not seem to have specific provisions for host key
     changes and it was suggested that SSHSM does not do anything
     special (either there is a transport or the transport failed).

[14] Yes.

[15] This will fall out once we have solved the other open issues.

[16] It was clarified that the SSH client always chooses the username
     to be used with a specific user authentication mechanism. The
     securityName is therefore the authenticated user name (modulo
     some potential AAA interaction which we do not understand yet).

[18] The information will be collapsed into one place.

[19] It seems that current SSH implementations talk to AAA servers as
     part of the user authentication process. The question seems to be
     how parameters that are relevant for SNMP can be moved into the
     SNMP engine or whether SNMP has to talk AAA itself and what the
     binding between multiple requests would be. This need more
     discussion.

[32] Yes.

[3]  We need to provide text which discusses the impact of using
     sessions. Volunteers please speak up.

[23] The SNMP dispatcher interface does not provide hooks for opening
     and closing sessions and in particular, there are no specific
     provisions for handling failures of the transport to deliver
     messages. This issue was not resolved and session handling in
     general needs more discussion.

[29] It seems we need to support reports as an SNMP layer error
     reporting and discovery mechanism.

[9]  The handling of notifications, the establishment of sessions for
     notification delivery and the associated authentication questions
     (SSH is not symmetric) were not resolved during the meeting and
     need more discussion.


A. Narrative Notes
------------------

(Slide text is not repeated...)

#2a

Eliot Lear:  #2a - all of 2 falls into the category of SNMP
making demands of SSH, but we shouldn't mess around with SSH's
business.  It's not our problem.

Jeff Hutzelman: How we learn the host key is in fact the one part
of this that we might want to consider.  We don't want to break
the abstraction.  How do you know that you have the right host
key?  Well, you'd better know the key in advance.  We may want to
consider that issue.

Eliot Lear: SSH requires a "leap of faith" in terms of the first
transaction when you get the host key.  How you get that in terms
of SNMP perhaps should not be a standardization issue.  We
shouldn't care.

Bill Sommerfeld: SSH documents already complete.  Agree with
Elliot.  There are some extensions at various levels of
completion which would make the leap of faith less of an issue.
X.509 is one.  The GSS-API bits provide an alternate means of
server auth.  You are better off not trying to avoid this leap of
faith in this working group.

Eric Fleischman: one of the differences between ISMS and USM is
that we have now made multiple authentication methods available.
When we get products from vendors, we want some consistency.  We
want at least one approach that everyone does.

Jeff Hutzelman:  Yes, we have mandatory to implement key exchange
mechanisms and authentication mechanisms.  If they're applicable
to ISMS we don't know.  There are ways to avoid the leap of faith
but we don't want to decide here what they must be.

Eliot Lear: Let's not standardize that here.

Jeff Hutzelman: We need to talk about it somewhere.  You need
text that discusses the operational aspect.

David Perkins: Operationally, a big part of SSH is the file where
you have the public key and the DNS name that goes with them.  If
I get software from different vendors, I don't want to go through
the "leap of faith" multiple times cause they have different file
formats.

David Harrington:  Could you send something to the list related
to this so we capture it?

Juergen Schoenwaelder: Do we need to do something with the text
or do we leave this up to SSH?

Eliot Lear: State somewhere in the document that you should
think about these issues, but not as normative text.  A note in
the security considerations to address the issue, but nothing
else.

Jeff Hutzelman: Particularly the 2C issue.

Jeff Hutzelman: Regarding 2a: The question is "does SNMP
sometimes always care about the service identity?"  Not sure this
is moot.  If we do care, the 2c advice is important for people to
heed.  Does the SSH client used by SNMP need to verify the
server's identity?

Sam Hartman: I think the answer is yes, but in the sense that SSH
always delivers.  Not add new stuff to make it more complicated.
Object to words that say that we need to do something more than
what is typically done.

Question from jabber " One question is whether the
server identity is ultimately verified by the user authentication
sucess?"

Sam Hartman: In general no.

#8 - mapping between SSH key and SNMP engineID.

Uri Blumenthal: WRT #8, you do need to bind the key.  Need to know
what to do if multiple agents are running on one system. Either bind
the key to the system or to the snmpEngineID so that there is a key
for each agent running on the system.

Sam Hartman: There has been a fair bit of traffic on this.

David Harrington: Haven't reached consensus.

Juergen Schoenwaelder: Do you understand the edits?

David Harrington: No.

Wes Hardaker: Two comments: 1) When we talk about engineIDs, can
we make sure we are consistent in talking about contextEngineID?
2) the mapping between the engineID and key happens in the
management apps, so do we need to standardize?  The management
app gets the key and the engineID and should do the mapping.

Sam Hartman: One disadvantage of that is that you must use an SSH
implementations that exports keys in that way.  Secondly, you
need to build things in a key exchange specific way.  What SSH
documents do is bind a name (host name) to some identity (key,
GSS name, etc.).  Do you want to add something on top of that or
do you want to use stock SSH implementations?  Also, a reminder -
the way you authenticate the server is different than the client
- it's asymmetric.

Wes Hardaker: I don't think we need to specify/mandate it.  We
should put something in the security considerations and we are done.

Sam Hartman: From an interoperability standpoint, what are you
going to put in ACLs.  contextEngineId?

Joseph Galbraith: Lots of keys floating around, so we need to be
explicit about which key we're talking about.

Jeff Hutzelman: SSH has no engineID.  The server doesn't have an
identifier when you connect to it with SSH.  You have to know who
you're going to talk to in advance.  Given a contextEngineID, you
have some way to know in advance who you're going to talk to
(e.g., name).

David Perkins: I'm confused since I know how proxies work.  If I
set up a connection to an SSH agent, the contextEngineId tells the
system which target should receive the request.  So, why do I
need to map?

Joseph Galbraith: If you are going to have one connection handle
multiple SNMP systems, you probably want multiple channels.

Jeff Hutzelman: But you need to map between how you authenticate
in SSH and how you authenticate in SNMP.

Eliot Lear: Could we have an example where we need the mapping?
Until we do, let's leave it out.

Bill Sommerfeld: What he said.  It seems that if you're serving
up multiple engineIds from one SSH client, you'll build up a
table over time.

Sam Hartman:  EngineId to hostname and key.

David Harrington:  Reminds us of the question...

David Perkins: Most management applications never need to know
the engineID unless they're doing proxies.  Most don't support
contextEngineID.  Don't store it.  They only support transport
address.  That's it.

David Harrington: We have to be consistent with the charter, which
says we should be using the contextEngineID to name SNMP entities.
Unless we don't have to follow the architecture, we seem to have to
take care of this issue.

(Question from jabber - get the question from jabber room)

Jeff Hutzelman: you need to know something about the identity in
advance.

Juergen Schoenwaelder: The issue isn't really resolved.  No clear
resolution.

Issue #12

msgFlag part:

Sam Hartman: Always assume that SSH provides all of the above
(auth, priv), so just don't worry about it.

part c:

Eliot Lear: Security area: How do you deal with this elsewhere?

Bill Sommerfeld: In general, there are a few countries where this
is an issue (crypto longer than X bits), but we haven't had to
deal with it in our products, so I'm not sure where this comes
from.

Eliot Lear: Can we leave part B to SSH?

Jeff Hutzelman: What is the state of the null cipher?

Sam Hartman: If concerned about issue, read RFC 1984.  If a site
selects null, it's okay and they're aware of it.   They may have
selected null because they're over an IPsec tunnel or the like.

Jeff Hutzelman: I wanted to know if it's possible for SSH to
provide a no-encryption environment.

David Harrington: Part b asks if it's okay for SSH to give more
security security than requested.  

Robert Story: We must allow SSH to provide higher security than
requested.

Bert Wijnen: When we designed security in v3, we discovered that
there is a lot of info retrieved that doesn't require security,
so we put in noAuth/noPriv.

Robert Story: We shouldn't force people to have separate connections.

Bert Wijnen: That's fine.

David Harrington: I prefer to use authPriv for everything.  We'll
take it to the list.

#13

Jeff Hutzelman: In traditional SSH implementations, the only
thing stored are the host keys.  What happens if re-keying
happens in the middle of a session?

Wes Hardaker: We shouldn't have to think about that here.

Bill Sommerfeld: That question hasn't been considered.

David Harrington: In USM, a keychange can be made and we need to
make sure we're getting an answer to

Joseph Galbraith: The transport's either there or not.  You don't
care about the details about things like how host keys are
stored.

David Harrington: (Editor - ???? sorry, didn't get the question)

Wes Hardaker: We shouldn't send out responses to questions from
previous sessions that aren't there anymore.

Nico's comment from jabber room.  A client would be free to
update its mappings if there was a rekey.

Joseph Galbraith: Client maintains a mapping file.  If that
changes, the client can say it doesn't accept or it does.  But
you don't care.

David Harrington: Resolution: we'll throw away the response.

#14

Yes

#15

Joseph Galbraith: what is the tmStateReference?

David Harrington: cached information.  When we send a response,
we must send it using the incoming state information.  Suggest we
take it to the list.

#16

Joseph Galbraith: In the userauth request, it either accepts the
user or sends back a list of methods that might work with that
username.  The client can then either choose a different method
or a different username.

David Perkins: what methods are there?

Joseph Galbraith:  There are a bunch of them.  This is a
non-issue.

Bert Wijnen: So do you get back a username?

Joseph Galbraith: No, username is input.  Client specifies
method, username, and authentication info.  Server says yes or
no, and if you get in, you're done. Further requests are ignored.

Bert Wijnen: What if it says no?

Joseph Galbraith:  It tells you methods to try.

Sam Hartman: You're going to get at least one no, then it'll tell
you what methods you should have tried (not usernames).

David Harrington: What username do you use?

Jeff Hutzelman: You use the username as a result of the
successful userauth request.

Sam Hartman: Don't want to specify to this level of detail
primarily due to RADIUS interactions, but ... yes.  It's the
username that's authenticated by the SSH server.

Sam Hartman: Enumerating auth methods is good to make sure you
don't have holes, but we shouldn't have a list of auth methods in
the documents.

Joseph Galbraith: No matter which auth method you use in SSH, it
has the same output - the username.  How you get that information
out of the SSH implementation into the SNMP implementation is an
implementation-specific question.

Juergen Schoenwaelder: Should we have language in the security
considerations section that says that you get the SSH username
into SNMP in a secure way.

Chris Lonvick: Is the username singular for all thousand boxes or
unique to each box?

Jeff Hutzelman: A deployment issue.  Either separate usernames
per client entity, RADIUS server, whatever.  The way these things
work today.

Chris Lonvick: Something to go in security considerations.  If
you're using the same username on all boxes, is there concern
that one box being compromised will compromise all?  Or do we
have unique users in all boxes.

#18:

David Harrington: Will collapse information in #18 into one place
in the document.

#19:

David Harrington: Don't expose SSH details into SNMP, but we may
need to do something here if we're going to use RADIUS for SNMP
authentication.

Eliot Lear: We are back to the triangular communication that we
had with EUSM, which we thought was ugly.

Sam Hartman: I am the manager and talk to agent using SSH.  I'm
the agent and talk RADIUS to the side.  I see two lines, no
triangle.

Eliot Lear: What information is exchanged with the RADIUS server?

Sam Hartman: Let's use a Cisco CLI example.  It will verify the
host key, i'll try to use none, Cisco box says no, says it wants
a password, so i send one.  The Cisco box asks the radius server.
A yes/no will then determine if I get access.

Eliot Lear: Just don't want to hard-code RADIUS since other
things will be used.

Sam Hartman: We need to think about communication between SNMP
and RADIUS.  Not hard-coded, but we need to do things that make
it easier.

Eliot Lear:  ???? (Editor - Sorry, didn't get this bit....)

Jeff Hutzelman: Not sure that a port number is needed.  The
client can provide auxiliary information in the authentication
request to identify the SSHSM channel.

Eliot Lear: It would be possible for me to provide as part of my
authentication something indicating the subsystem I want to
invoke?

Jeff Hutzelman: There is something in keyboard-interactive that
gives some hint to the server which backend to use.  Not sure
it's relevant here.

Sharfuddin Syed:  Sam's use case was helpful.  One thing was
overlooked.  When a client makes a request to the server,
shouldn't the request go through a NAS client as well?

Jeff Hutzelman: An implementation detail that Sam glossed over.
Assumption that the server is on the same box.

David Nelson (jabber): No, the RADIUS management authorization
work does not separate authorization from authentication.

#32

David Harrington: We have pseudo-code in the SNMP specs we have
to have a default mapping that would mean we default to the SSH
username.  Answer: Yes.

Sessions:

#3

Eliot Lear: Q? When you say "session", do you mean transport
layer connection or some other form of session.

David Harrington: Yes :-)  We just need to talk about
implications of "sessions".  Following points are also part of
this.

#23

David Harrington: We can't deal well with failure of the
transport to deliver the message.  ASI's don't allow for an error
from transport mappings portion of the SNMP engine.

Jeff Hutzelman: How do other transports deal with this?

David Harrington: UDP just fails.

Juergen Quittek: We have only 10 minutes left, so let's make sure we
talk about important issues.

David Harrington: The problem is that the important issues may be
ratholes.

SSHSM vs USM

#29

David Harrington: Yes, we need to support reports.

#30

David Harrington: We may not have security parameters, so do we
really need to parse the ASN.1?  We may need to make sure it's
not empty.

David Harrington blew through a bunch of issues

Notifications

#9

Wes Hardaker: unless there's a technical reason not to, why not?

Juergen Schoenwaelder: We have a fundamental question:  How do we
authenticate notifications since SSH is not symmetric.

Eliot Lear: Also, in which direction can those notifications
come?

Jeff Hutzelman: In my limited network operations experience,
normally notifications are used by a system configured to send
notifications to a centralized system to let you know about
interesting events.

Sharfuddin Syed: If the auth fails for a number of times, we
should send some kind of notification.

David Perkins: There may be another question that should be asked
before this one.  Today, using UDP, when you want to send a
trap/inform, you just send it.  If we in the future want to send
notifications, when do we set up the session?  When the event
occurs?  When the notification generator comes up?

David Harrington: Right now in the doc, when there's something to
send.

David Perkins: When do you tear it down?

David Harrington: Not decided.

David Perkins: There's a way to configure notification targets
today, we need a way to do this this in SSH.

Sharon Chisholm: When people want to manage a system, they're
going to want to set up the session when they start up the
system, not short-lived sessions.

Juergen Schoenwaelder: Let's take this to the list.  Reminds us
of the call-home BOF.  We need to look at the notification
handling.

Thanks, we continue on the list.