Subject: [Isms] More questions on Security name

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Mon, 20 Aug 2007 22:22:16 -0700

I've been reviewing the working group documents and I am not quite sure
how security name is/should used.

In USM it appears that there is a single SecurityName representing both
sides of a conversation, is this true and is this true of SNMPv3 in
general.  

I'm still a bit confused as to where an why SecurityName is used in
various cases. Is the following accurate?

A securityName is used in authorization on a command process to make
sure that the command generator is authorized (security name applies to
command generator).  A security name may be used on a notification
generator to determine if the notification receiver is authorized to
receive a message (security name applies to notification receiver). 

In SSH, generally there is more than one entity identity involved.  One
entity is identified by a SSH user authentication (username) and another
is identified by SSH server authentication (IP address/domain name).  

Some of the difficulty around securityName may originate from this.  We
may need to split up securityName into two pieces, but this seems like
it would have some impact on SNMP, although maybe it would always be
clear which name is used in particular case.  Another option (well
really it probably maps to the same thing) is to treat the mutual
authentication as a single securityName such as something like
[email-masked].  This seems like it would affect how
authorization is set up in VACM. 

If other people are as confused as me then perhaps we need to have a
section in the document that describes the interaction with
authorization. 

Joe

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

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Tue, 21 Aug 2007 08:52:56 +0200

Inline

Bert Wijnen  

> -----Original Message-----
> From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
> Sent: Tuesday, August 21, 2007 7:22 AM
> To: [email-masked]
> Subject: [Isms] More questions on Security name
> 
> I've been reviewing the working group documents and I am not 
> quite sure how security name is/should used.
> 
> In USM it appears that there is a single SecurityName 
> representing both sides of a conversation, is this true and 
> is this true of SNMPv3 in general.  
> 

Yes. But... there is an authoritative side on each conversation.
The agent is the authoritative side of the communication for all
PPU exchanges except for the INFORM, where the manager is the
authoritative side. The importance of the authoritative side is
that the shared USM username/password is the one the the 
authoritative side knows about. Inside the message, the user is
represented by msgUserName in UsmSecurityParameters (see RFC3414, 
sect 2.4)

> I'm still a bit confused as to where an why SecurityName is 
> used in various cases. Is the following accurate?
> 
> A securityName is used in authorization on a command process 
> to make sure that the command generator is authorized 
> (security name applies to command generator).

Yep. Although I would word it different.
The securityName gets mapped into a groupName, and the groupName 
(together with securityLevel and securityModel) determins (via the
VACM tables) of the command generator has access to the object-instances

it is trying to access.

> A security 
> name may be used on a notification generator to determine if 
> the notification receiver is authorized to receive a message 
> (security name applies to notification receiver). 
> 
Nope. The securityName gets mapped into a groupName and together
with securityLevel and securityModel, the VACM tables control if 
all the object-instances included in the notifications can indeed be
accessed and if so they will be sent as varBinds in the notification.

On the receiving end there is no "access control".

> In SSH, generally there is more than one entity identity 
> involved.  One entity is identified by a SSH user 
> authentication (username) and another is identified by SSH 
> server authentication (IP address/domain name).  
> 

The userName (in the msgUserName in the UsmSecurityParameters,
see RFC3414 sect 2.4) gets translated into securtyName (1 to 1, 
identity function) and then gets used to do the authentication,
and privacy en/decription)
Specifically, here it is important to know about the authoritative
side. As stated above, normally it is the agent, but for INFORM
PDUs it is the notofication receiver (running at the manager).

> Some of the difficulty around securityName may originate from 
> this.  We may need to split up securityName into two pieces, 
> but this seems like it would have some impact on SNMP, 
> although maybe it would always be clear which name is used in 
> particular case.  

In SNMP with USM, you basically only have one side that is 
authoritative (in each communication, that is per exchange of
a SNMP PDU pair (request/response), based on a shared 
msgUserName secret. In case of a TRAPv2-PDU there is just
one-way, so no response.

I am leaving the REPORT PDUs out of the discussion for now.
I think such is OK.

> Another option (well really it probably 
> maps to the same thing) is to treat the mutual authentication 
> as a single securityName such as something like 
> [email-masked].  This seems like it would affect 
> how authorization is set up in VACM. 
> 

I believe that USM uses the msgUserName/password indeed as
a mutual authentication (see description above and let me
know if you agree).

> If other people are as confused as me then perhaps we need to 
> have a section in the document that describes the interaction 
> with authorization. 
> 

Hope my comments helped.

Bert

---

From: "David Harrington" <[email-masked]>
Date: Tue, 21 Aug 2007 07:39:13 -0400

Hi, 

>From RFC3411:

3.2.1.  Principal

A principal is the "who" on whose behalf services are provided or
   processing takes place.

   A principal can be, among other things, an individual acting in a
   particular role; a set of individuals, with each acting in a
   particular role; an application or a set of applications; and
   combinations thereof.

3.2.2.  securityName

   A securityName is a human readable string representing a principal.
   It has a model-independent format, and can be used outside a
   particular Security Model.

>From "Secure Shell Transport Model for SNMP":

   4.  Verification of principal identity is important for use with
the
       SNMP access control subsystem, to ensure that only authorized
       principals have access to potentially sensitive data.  The SSH
       user identity will be used to map to an SNMP model-independent
       securityName for use with SNMP access control.

more inline.

> Sent: Tuesday, August 21, 2007 1:22 AM
> To: [email-masked]
> representing both

A securityName represents an authenticated principal on whose behalf
work is done.
For SSH-TM, securityName represents the SSH-USER authenticated during
user-auth.
For USM, securityName represents the usmUser authenticated using USM
authentication

The command generator, command responder, notification originator, and
notification receiver are "applications" that do work on behalf of an
authenticated principal.
The operation might be to read the data, to write the data, or to send
the data in a notification.
Authorization is checked by command responders and notification
originators.

When a request is being processed, the responder or originator checks
whether the authenticated principal is permitted to have that command
performed on its behalf and whether they are permitted to perform the
operation to the specified subset of data.

> involved.  One

Mutual authentication is required by the SSH transport model.
For the SSH transport model, securityName represents the authenticated
user, never the server.

In SNMP authorization, we always check whether the user is authorized
to access the data in the MIB database. 

> this.  We

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 22 Aug 2007 16:51:27 -0700

Thanks Bert,

> > Subject: [Isms] More questions on Security name

<snip>

> 
> > A security
> > name may be used on a notification generator to determine if the 
> > notification receiver is authorized to receive a message (security 
> > name applies to notification receiver).
> > 
> Nope. The securityName gets mapped into a groupName and 
> together with securityLevel and securityModel, the VACM 
> tables control if all the object-instances included in the 
> notifications can indeed be accessed and if so they will be 
> sent as varBinds in the notification.
> 

[Joe] OK, this is where I have been confused.  What entity does the
security name represent? I seems like it represents the user on the
notification receiver.  There is no access control on the receiving end,
but on the sending end there is access control based on who the message
is being sent to.  So, when sending a notification you need to
authenticate that the receiver is the 'user' you are authorized to send
to.  Correct?  

> 
> > In SSH, generally there is more than one entity identity involved.  
> > One entity is identified by a SSH user authentication 
> (username) and 
> > another is identified by SSH server authentication (IP 
> address/domain 
> > name).
> > 
> 
> The userName (in the msgUserName in the 
> UsmSecurityParameters, see RFC3414 sect 2.4) gets translated 
> into securtyName (1 to 1, identity function) and then gets 
> used to do the authentication, and privacy en/decription) 
> Specifically, here it is important to know about the 
> authoritative side. As stated above, normally it is the 
> agent, but for INFORM PDUs it is the notofication receiver 
> (running at the manager).
> 

[Joe] OK, this seems consistent with above. 

> > Some of the difficulty around securityName may originate 
> from this.  
> > We may need to split up securityName into two pieces, but 
> this seems 
> > like it would have some impact on SNMP, although maybe it 
> would always 
> > be clear which name is used in particular case.
> 
> > Another option (well really it probably maps to the same 
> thing) is to 
> > treat the mutual authentication as a single securityName such as 
> > something like [email-masked].  This seems 
> like it would 
> > affect how authorization is set up in VACM.
> > 
> 
> I believe that USM uses the msgUserName/password indeed as a 
> mutual authentication (see description above and let me know 
> if you agree).
> 
[Joe] yes, in a way USM uses the msgUserName/password as mutual
authentication.  More specifically it uses a secret derived from the
msgUserName/Password/(and perhaps AuthoritativeEngineID) to perform
mutual authentication.  

> > section in the document that describes the interaction with 
[Joe] They did, now I need to go back and try and make sense of it all.

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 23 Aug 2007 11:25:36 +0200

Inline

Bert Wijnen  

> Sent: Thursday, August 23, 2007 1:51 AM
> To: Wijnen, Bert (Bert); [email-masked]
> Subject: RE: [Isms] More questions on Security name
> 
> Thanks Bert,
> 
> together with 
> > securityLevel and securityModel, the VACM tables control if all the 
> > object-instances included in the notifications can indeed 
> be accessed 
> > and if so they will be sent as varBinds in the notification.
> > 
> [Joe] OK, this is where I have been confused.  What entity 
> does the security name represent? I seems like it represents 
> the user on the notification receiver.  There is no access 
> control on the receiving end, but on the sending end there is 
> access control based on who the message is being sent to.  
> So, when sending a notification you need to authenticate that 
> the receiver is the 'user' you are authorized to send to.  Correct?  
> 

I think so. However "authorzied to send to"... you can send
whatever you want, if the keys don't match, the receiver
won't be able to decrypt (for authPriv messages). And authentication
would fail too, and so the message would get dropped. But the data of 
course did get to the destination, and if unencruptes, trhen they can
read.

So access control checks if the data can indeed be send to the
destination
based on securityName, securityModel, securityLevel.

For notifications it is important to understand we have 2 types:
- TRAPv2 (traps, unconfirmed notifications). They get sent
  from agent to manager and we have no idea if they ever arrive, we
  do not get a response.
- INFORM (confirmed notification). They get sent from agent
  to manager, and we DO get a response so we know if the notification
  gg/pipermail/isms>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Inline

Bert Wijnen  

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Thursday, August 23, 2007 12:07 AM
> To: Wijnen, Bert (Bert); 
> [email-masked]; David Harrington
> Cc: [email-masked]; Jeffrey Hutzelman
> Subject: Re: [Isms] tmStateReference in draft-ietf-isms-tmsm-09.txt 
> 
> 
> 
> On Wednesday, August 08, 2007 12:17:56 PM +0200 "Wijnen, Bert (Bert)" 
> <[email-masked]> wrote:
> 
> >
> > I am confused by the last 2 paragraphs in sect 6.2
> >
> >    The prepareOutgoingMessage ASI passes tmStateReference from the
> >    Message Processing Subsystem to the dispatcher.  How or if the
> >    Message Processing Subsystem modifies or utilizes the contents of
the
> >    cache is message-processing-model-specific.
> >
> >    This may sound underspecified, but keep in mind that a message
> >    processing model might have access to all the information from
the
> >    cache and from the message, and have no need to call a Security
Model
> >    to do any processing; an application might choose a Security
Model
> >    such as USM to authenticate and secure the SNMP message, but also
> >    utilize a secure transport such as that provided by the SSH
Transport
> >    Model to send the message to its destination.
> >
> > specifically the wording "an application...".
> > Applications in our RFC3411 context are CG or CR or NO or NR or
such.
> > I am sure that is not intended here. But then, what is an
"application"
> > in this sentence above?
> 
> Why not?  Is it not these applications which specify a 
> security model/name/level and transport domain and address?  
> If an application selects USM security parameters and an SSH 
> transport address, it has effectively chosen the use of USM and SSH.
> 

Mmm... I am less concerned now.. but still have an uneasy feeling.
Need to go lookup details before I can put words around it... or
maybe if I do my concerns go away.

> 
> > I am also not sure we should speak about the MPM to "not call a 
> > security model". From our architectural point of view, the MPM will 
> > ALWAYS call a security model. If an implementation does a shortcut, 
> > that is up to them... but should we discuss that here?
> 
> I agree.  Even if a new MPM were defined in the future, to 
> specify situations when using that MPM in which the security 
> model is not called would seem to violate the architecture.
> 

ack
Bert
> -- Jeff

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 23 Aug 2007 11:25:36 +0200

Inline

Bert Wijnen  

  got deleivered (at least delivered to the SNMP engine).

In both cases, access control (that is checking if the object instances 
in the notification are accessible for the specific securityName,
securityModel
and securityLevel. If not, the process stops. If yes, the process
continues.

For a TRAPv2, that is it. if access control says "OK send it", then the
trap
(with data) gets sent and that is all we know. We have no idea what gets
done at the manager side. At the manager side, the only thing that
happens is
that it checks (based on the securityName) the authentication and
decodes
the encrypted message. If the securityName/password(key in fact) is not
in
sync, the message gets dropped. If we ever find out (not specifie dhow
we can 
find this out) we must assume that the key at the agent is correct and
so to
fix it we need to fix the key at the manager (or generate new keys to
get
them in sync).

For an INFORM, the process is basically the same. But now the manager
sends 
a response. And if the passwords do not match, then the manager sends a
REPORT PDU and so we know it did not work. In this case, the assumption
is
that the password/key at the manager side is correct (authoritative) and
so the key on the agent needs to be changed (or new shared key needs to
be generated).

> > The userName (in the msgUserName in the UsmSecurityParameters, see 
> > RFC3414 sect 2.4) gets translated into securtyName (1 to 1, identity

> > function) and then gets used to do the authentication, and privacy 
> > en/decription) Specifically, here it is important to know about the 
> > authoritative side. As stated above, normally it is the agent, but
for 
> > INFORM PDUs it is the notofication receiver (running at the
manager).
> > authoritative (in each communication, that is per exchange 
> of a SNMP 
> > PDU pair (request/response), based on a shared msgUserName 
> secret. In 
> > case of a TRAPv2-PDU there is just one-way, so no response.
> > 
> > I believe that USM uses the msgUserName/password indeed as a mutual 
> > authentication (see description above and let me know if you agree).
> > 
> [Joe] yes, in a way USM uses the msgUserName/password as 
> mutual authentication.  More specifically it uses a secret 
> derived from the msgUserName/Password/(and perhaps 
> AuthoritativeEngineID) to perform mutual authentication.  

yep. The authoritativeEnginID is used to localize the keys so that
they are separate for every authoritative engine (mostly agents).
That way, if one agent gets comrpomised, the keys don't give you
access to other agents.
> [Joe] They did, now I need to go back and try and make sense 

Have fun ;-)
Bert
> > Bert
> > > Joe
> > > 
> > > _______________________ses:message
Subject: RE: [Isms] More questions on Security name
Date: Thu, 23 Aug 2007 11:25:36 +0200
From: "Wijnen, Bert \(Bert\)" <[email-masked]>
To: "Joseph Salowey \(jsalowey\)" <[email-masked]>, <[email-masked]>
Cc: 

Inline

Bert Wijnen  

  got deleivered (at least delivered to the SNMP engine).

In both cases, access control (that is checking if the object instances 
in the notification are accessible for the specific securityName,
securityModel
and securityLevel. If not, the process stops. If yes, the process
continues.

For a TRAPv2, that is it. if access control says "OK send it", then the
trap
(with data) gets sent and that is all we know. We have no idea what gets
done at the manager side. At the manager side, the only thing that
happens is
that it checks (based on the securityName) the authentication and
decodes
the encrypted message. If the securityName/password(key in fact) is not
in
sync, the message gets dropped. If we ever find out (not specifie dhow
we can 
find this out) we must assume that the key at the agent is correct and
so to
fix it we need to fix the key at the manager (or generate new keys to
get
them in sync).

For an INFORM, the process is basically the same. But now the manager
sends 
a response. And if the passwords do not match, then the manager sends a
REPORT PDU and so we know it did not work. In this case, the assumption
is
that the password/key at the manager side is correct (authoritative) and
so the key on the agent needs to be changed (or new shared key needs to
be generated).

> > The userName (in the msgUserName in the UsmSecurityParameters, see 
> > RFC3414 sect 2.4) gets translated into securtyName (1 to 1, identity

> > function) and then gets used to do the authentication, and privacy 
> > en/decription) Specifically, here it is important to know about the 
> > authoritative side. As stated above, normally it is the agent, but
for 
> > INFORM PDUs it is the notofication receiver (running at the
manager).
> > authoritative (in each communication, that is per exchange 
> of a SNMP 
> > PDU pair (request/response), based on a shared msgUserName 
> secret. In 
> > case of a TRAPv2-PDU there is just one-way, so no response.
> > 
> > I believe that USM uses the msgUserName/password indeed as a mutual 
> > authentication (see description above and let me know if you agree).
> > 
> [Joe] yes, in a way USM uses the msgUserName/password as 
> mutual authentication.  More specifically it uses a secret 
> derived from the msgUserName/Password/(and perhaps 
> AuthoritativeEngineID) to perform mutual authentication.  

yep. The authoritativeEnginID is used to localize the keys so that
they are separate for every authoritative engine (mostly agents).
That way, if one agent gets comrpomised, the keys don't give you
access to other agents.
> [Joe] They did, now I need to go back and try and make sense 

Have fun ;-)
Bert

ot deleivered (at least delivered to the SNMP engine).

In both cases, access control (that is checking if the object instances 
in the notification are accessible for the specific securityName,
securityModel
and securityLevel. If not, the process stops. If yes, the process
continues.

For a TRAPv2, that is it. if access control says "OK send it", then the
trap
(with data) gets sent and that is all we know. We have no idea what gets
done at the manager side. At the manager side, the only thing that
happens is
that it checks (based on the securityName) the authentication and
decodes
the encrypted message. If the securityName/password(key in fact) is not
in
sync, the message gets dropped. If we ever find out (not specifie dhow
we can 
find this out) we must assume that the key at the agent is correct and
so to
fix it we need to fix the key at the manager (or generate new keys to
get
them in sync).

For an INFORM, the process is basically the same. But now the manager
sends 
a response. And if the passwords do not match, then the manager sends a
REPORT PDU and so we know it did not work. In this case, the assumption
is
that the password/key at the manager side is correct (authoritative) and
so the key on the agent needs to be changed (or new shared key needs to
be generated).

> > The userName (in the msgUserName in the UsmSecurityParameters, see 
> > RFC3414 sect 2.4) gets translated into securtyName (1 to 1, identity

> > function) and then gets used to do the authentication, and privacy 
> > en/decription) Specifically, here it is important to know about the 
> > authoritative side. As stated above, normally it is the agent, but
for 
> > INFORM PDUs it is the notofication receiver (running at the
manager).
> > authoritative (in each communication, that is per exchange 
> of a SNMP 
> > PDU pair (request/response), based on a shared msgUserName 
> secret. In 
> > case of a TRAPv2-PDU there is just one-way, so no response.
> > 
> > I believe that USM uses the msgUserName/password indeed as a mutual 
> > authentication (see description above and let me know if you agree).
> > 
> [Joe] yes, in a way USM uses the msgUserName/password as 
> mutual authentication.  More specifically it uses a secret 
> derived from the msgUserName/Password/(and perhaps 
> AuthoritativeEngineID) to perform mutual authentication.  

yep. The authoritativeEnginID is used to localize the keys so that
they are separate for every authoritative engine (mostly agents).
That way, if one agent gets comrpomised, the keys don't give you
access to other agents.
> [Joe] They did, now I need to go back and try and make sense 

Have fun ;-)
Bert

________________________

---

From: "David Harrington" <[email-masked]>
Date: Thu, 23 Aug 2007 08:02:37 -0400

Hi,

I think Joe and Bert are discussing two potentially different
scenarios.
Joe is asking questions that may be architectural or may be
SSH-specific.
Bert is answering from a USM standpoint.

The USM-specific way is not an accurate reflectoion of the
architectural requirements.
For example, the WG decided that "authoritative" is USM-specific, not
architectural.
It is important to keep the distinction between one model's approach
and the architectural requirements.

The issue of whether we need to authenticate the "user" who will
recieve notifications over an SSH transport has been discussed
multiple times already. It was included in the presentation at IETF67.
We held a teleconference to discuss the issue.  The issue is that,
while USM establishes a symmetric security relationship using shared
passwords, SSH has an asymmetric security relationship; it
authenticates a server on one side, and a user on the other side, and
these differ in granularity. If the chair is aware of consensus on how
to authenticate the "user" that is the notification receiver, then
please speak up. 

As I recall, no solution was found to this issue. I think we reached
consensus that 
1) if a client had already established a connection, so we have a
relevant securityname, then that connection could be reused for
notiications. 
2) if a notification needs to be sent, and no SSH connection exists,
then the transport model will try to create a connection. How the
credentials are supplied, and how the connectionis created is
implementation-specific. The slides from IETF67 present three options
for doing this, which may or may not work.
3) if a notification needs to be sent, and no SSH connection exists,
then the agent can use USM to send the notification. This is
implementation-specific.

That's my understanding of where we stand on this issue.

dbh

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Thursday, August 23, 2007 5:26 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> UsmSecurityParameters, see

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 23 Aug 2007 14:55:48 +0200

Inline

Bert Wijnen  

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, August 23, 2007 2:03 PM
> To: Wijnen, Bert (Bert); 'Joseph Salowey (jsalowey)'; [email-masked]
scenarios.
SSH-specific.
architectural.

You are correct. My appology. 
Now to my defense, I believe Joe was asking if he understood USM
correctly.
For example he asked:
> In USM it appears that there is a single SecurityName representing 
> both sides of a conversation, is this true and is this true of SNMPv3 
> in general.
> 

And I jumped on my USM explanation, forgetting the "is this true of
SNMPv3 in general". I think we need to look architectural for "SNMPv3
in general".

So the authoritative part of my comments should be ignore in terms of
architectural impact.
Again, I wish those who argued so vehemently in favor of making the
receiving end of an INFORM authoritative were participating.
There was (I believe, but do not recall details) more to it than just 
USM. But in our current archtecture and documents, indeed the
architecture
does not speak of authoritative sides. Only USM does.

> The issue of whether we need to authenticate the "user" who 
> will recieve notifications over an SSH transport has been 
> discussed multiple times already. It was included in the 
> presentation at IETF67.
> We held a teleconference to discuss the issue.  The issue is 
> that, while USM establishes a symmetric security relationship 
> using shared passwords, SSH has an asymmetric security 
> relationship; it authenticates a server on one side, and a 
> user on the other side, and these differ in granularity.

So I guess that the server is (for most PDUs) the agent and
the user is the principal at the manager side?

But such may not be true for notifications, right?

> If 
> the chair is aware of consensus on how to authenticate the 
> "user" that is the notification receiver, then please speak up. 
> 
> As I recall, no solution was found to this issue. I think we 
> reached consensus that
> 1) if a client had already established a connection, so we 
> have a relevant securityname, then that connection could be 
> reused for notiications. 

So that sounds as if we assume the same "user" on both ends in this
case.

> 2) if a notification needs to be sent, and no SSH connection 
> exists, then the transport model will try to create a 
> connection. How the credentials are supplied, and how the 
> connectionis created is implementation-specific. The slides 
> from IETF67 present three options for doing this, which may 
> or may not work.

Do we state anywhere that this case is implementation specific and
that we have no pre-scribed details/approach? That seems the least
we can do.

> 3) if a notification needs to be sent, and no SSH connection 
> exists, then the agent can use USM to send the notification. 
> This is implementation-specific.
> 
Yep, that can always be done.
It would eliminate a lot of the reasons why we are working on an
SSH based solution... but oh well.

> That's my understanding of where we stand on this issue.

So I am not clear then if we have consensus on the issue.

Chair?

Bert
> > > notification receiver.  There is no access control on the 
> receiving 
> > > end, but on the sending end there is access control based 
> on who the 
> > > message is being sent to.
> > > So, when sending a notification you need to authenticate that the 
> > > receiver is the 'user' you are authorized to send to.
> > Correct?  
> > > 
> > 
> whatever 
> > you want, if the keys don't match, the receiver won't be able to 
> > decrypt (for authPriv messages). And authentication would fail too, 
> > and so the message would get dropped. But the data
> of 
> > destination based on securityName, securityModel, securityLevel.
> > 
> > 
> > In both cases, access control (that is checking if the object 
> > instances in the notification are accessible for the specific 
> > securityName, securityModel and securityLevel. If not, the process 
> > stops. If yes, the process continues.
> > 
> > For a TRAPv2, that is it. if access control says "OK send it", then 
> > the trap (with data) gets sent and that is all we know. We have no 
> > idea what gets done at the manager side. At the manager 
> side, the only 
> > thing that happens is that it checks (based on the 
> securityName) the 
> > authentication and decodes the encrypted message. If the 
> > securityName/password(key in
> > fact) is not
> > in
> > a response. And if the passwords do not match, then the 
> manager sends 
> > a REPORT PDU and so we know it did not work. In this case, the 
> > assumption is that the password/key at the manager side is correct
> > (authoritative) and
> > so the key on the agent needs to be changed (or new shared 
> key needs 
> > to be generated).
> > 
> > 
> > > > 
> > > msgUserName/Password/(and perhaps
> > > [Joe] They did, now I need to go back and try and make 
> sense of it 
> > > all.
> > > 
> > 
> > Have fun ;-)
> > Bert
> > > > Bert
> > > > > Joe
> > > > >

---

From: "David Harrington" <[email-masked]>
Date: Thu, 23 Aug 2007 10:40:48 -0400

inline.

> does not speak of authoritative sides. Only USM does.

I think there may have been a number of motivations for the
authoritative difference. The main one in my mind is the use of clocks
to detect timeliness, to help prevent replay. There are certain
attacks that can be launched using replay, and causing the
re-synchronization of clocks. It is important to check timeliness
using the correct clock, and it is important to sync using the right
clock. 

> But such may not be true for notifications, right?

Abstractly, the clock "authoritative" issue is kind of like server
versus client authentication. You want to make sure the attacker
doesn't get to "authenticate" himself. In SSH for R/R traffic, the
agent is the server, and the manager is the client, and the
manager-client must prove he is authentic before the agent-server
permits access to the data. 

But in the notification situation, if the agent gets to be the SSH
client, then the agent-client is proving to itself it is authentic?
(i.e., the agent has the user credentials to prove it is authentic);
this isn't useful because the agent already has access to the data. We
never authenticate the manager's "user identity" to determine if they
are allowed to receive the potentially sensitive data.

Now, we can approach it that for notifications, the manager-client
needs to prove authenticity. But if no connection has been
established, the agent-server needs to initiate the connection and
force user-auth. I think that is unnatural SSH.

> So that sounds as if we assume the same "user" on both ends in this

No. The user is on one side only. In option #1, the manager-client end
represents the user, and if we have an established connection, the
manager-client must have created it for R/R traffic and already proved
itself authentic to the agent-server using SSH user-auth. The
server-agent can now reuse that existing connection as an
authenticated connection to the user that is the target for the
notification. If no connection exists, then the manager-agent cannot
create one to send notifications. (The option#1 scenario is like
Netconf notifications; the client must initiate the subscription; it
is never initiated by the server.)
 
> that we have no pre-scribed details/approach? That seems the least

I am not sure allowing this is good security. We, the experts in SNMP
requirements for security, have not figured out how to accomplish
this. I am not certain we want to permit any implementation-specific
approach to be used here, since it could compromise the security of
the whole system.

Creating the conection from the agent can be done three ways:
1) the agent-server can try to initiate a connection to a
manager-client, which may o rmay not be legal SSH
2) the agent-client can establish a connection to a manager server,
but the "user" is on the wrong side for authorization to be useful;
and this means the client credentials need to be kept on the agent
side somehow, which would defeat the purpose of ISMS.
3) a call-home mechanism is used, where the agent-server contacts the
manager-client and says "call me", and then the manager-client-user
authenticates itself, a connection is established, and then we can
follow option#1 and reuse that connection for notifications.

> > This is implementation-specific.

We could develop a "call-home" notification that the SNMP agent can
send to the SNMP manager using USM (or even v1/v2c trivial security),
to cause the manager-client to create an SSH connection to the
agent-server, which could subsequently be used for notifications over
SSH. (Actually, the call-home notification could specify in varbinds
which transportDomain/address/securityName/level and which
securityModel, needs a connection, so it could be used for TLS or
other transports, and for other security models. 

I'm not sure I feel comfortable reusing connections assuming correct
authentication given that we have no way to check what SSH authn was
actually done (i.e. it could be null set up by an attacker).

And, of course, a call-home over v1/v2c could be used for DoS.

dbh

> > > course did get to the destination, and if unencruptes, trhen
they
> > can
> > > sync, the message gets dropped. If we ever find out (not
specifie
> > dhow
> > > we can
> > > find this out) we must assume that the key at the agent is
correct
> > and
> > > so to
> > > fix it we need to fix the key at the manager (or generate new
keys
> > to
agent,
> > but
mutual

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 23 Aug 2007 17:03:53 -0700

> manager-client, which may o rmay not be legal SSH

[Joe] If the agent runs a client and the manager a server then this is
OK, however I don't believe that SSH allows the server to initiate user
authentication so you have the same problem as before.  

> 2) the agent-client can establish a connection to a manager 
> server, but the "user" is on the wrong side for authorization 
> to be useful; and this means the client credentials need to 
> be kept on the agent side somehow, which would defeat the 
> purpose of ISMS.

[Joe] I agree that this isn't really an acceptable option. 

> 3) a call-home mechanism is used, where the agent-server 
> contacts the manager-client and says "call me", and then the 
> manager-client-user authenticates itself, a connection is 
> established, and then we can follow option#1 and reuse that 
> connection for notifications.
> 
[Joe] I think this is the only one of the above options that would work.

> > > then the agent can use USM to send the notification.
> We could develop a "call-home" notification that the SNMP 
> agent can send to the SNMP manager using USM (or even v1/v2c 
> trivial security), to cause the manager-client to create an 
> SSH connection to the agent-server, which could subsequently 
> be used for notifications over SSH. (Actually, the call-home 
> notification could specify in varbinds which 
> transportDomain/address/securityName/level and which 
> securityModel, needs a connection, so it could be used for 
> TLS or other transports, and for other security models. 
> 
> I'm not sure I feel comfortable reusing connections assuming 
> correct authentication given that we have no way to check 
> what SSH authn was actually done (i.e. it could be null set 
> up by an attacker).
> 
[Joe] I think call home functionality would be useful here, however
there are details that need to be worked out.  Another option may be to
change the way the security name is created.  Instead of just placing
the authenticated username in the securityName you can put the
authenticated username and server name, for example:
[email-masked] or [email-masked].  The SSHSM would only
fill in this values if they where truly authenticated.  Then your group
mappings would need to be based on the combined user@server securityName
instead of just username.  This is not so neat because then you
transport address becomes part of the security name,  but I think it
might work.  

> > It would eliminate a lot of the reasons why we are working 
> on an SSH 
> > based solution... but oh well.
> >

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 27 Aug 2007 18:32:07 -0400

> side somehow, which would defeat the purpose of ISMS.

This approach is actually not entirely useless.  In particular, I would 
expect one common operational practice to be to set up a small number of 
"collector" systems to receive and log notifications, and possible do 
something about them.  In that scenario, it makes reasonable sense for such 
a collector to act as an SSH server, and accept connections from devices 
which act as SSH clients and notification senders.

Such connections could be authenticated using any of a number of methods 
which would not defeat the goals of using existing infrastructure and 
avoiding the need to provision pairwise keys on every device.  For 
example...

- If devices are accepting SSH connections for R/R authenticated using
  GSS-krb5 and SSH's GSS-API key exchange and user auth methods, then
  they already have Kerberos principals and keys which can be reused to
  authenticate outgoing connections for notifications.
- If devices are accepting SSH connections for R/R and using one of SSH's
  public-key-based host key algorithms, they already have a public key
  pair which can be reused to authenticate outgoing connections.
- Obviously, outgoing connections can be authenticated using a password.
- And so on...

The tricky part here is that the notification originator needs to know
(1) what the transport address is of the server
(2) the server's identity, for authentication
(3) its own identity and credentials

In USM, (2) and (3) are summed up in a single securityName and password, 
which can be used in either direction between a pair of servers.  But in 
other systems, including SSH, they may be distinct.  For requests, we 
resolved this by effecitvely folding (2) into the transport address, and 
assuming that the securityName is really describing the client's identity. 
For responses, we still assume that securityName describes the client's 
identity (that is, the identity of the requestor), but that works out 
because we require reuse of an existing incoming conection from that 
requestor.

When we get to talking about notifications, it still works to fold (1) and 
(2) into the transport address, because that is still the address of the 
agent we want to contact.  However, we run into trouble with (3) because 
SSH needs to know the username of the notification originator, while the 
architecture seems to assume here that securityName is the name of the 
notification receiver.  In USM that doesn't matter, because the 
securityName actually names the pair.  But for SSH it does; my name is 
_not_ the same as your name.

Obviously it is possible for an implementation to work around this by 
providing an implementation-specific way to specify the username to be 
used, or by ignoring the architecture and declaring that for a 
notification, the username actually describes the NO and not the NR.  I 
imagine there are other possibilities as well.

This problem is not unique to SSH; rather, the lack of it is unique (or 
nearly so) to USM.  IMHO that means there is a problem either with the 
architecture or with our understanding of it, and that problem needs to be 
solved before a clean solution to authenticating outgoing notifications is 
possible.  However, I would like to see that problem solved, because 
otherwise I don't see how we can have interoperable transport of 
notifications using the specifications we are developing, and requiring the 
use of USM for notifications _does_ defeat the purpose of ISMS.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 27 Aug 2007 18:37:19 -0400

> [Joe] I think this is the only one of the above options that would work.

That works for the manager-client case, but I expect we've mostly got that 
covered, because notifications to such a thing are only meaningful while it 
is still running, in which case it can keep a connection open.  I'm much 
more concerned about the central-collector case.

> transport address becomes part of the security name,  but I think it

Ew.  I haven't thought about this enough yet to be able to say whether I 
think it's a good idea, but my first instinct is to say "Ew".

-- Jeff