Subject: RE: [Isms] authoritative

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 6 Oct 2005 08:50:05 -0700

Steve,

Your points resonate with me in environments using shared secret keys.
However, other environments also exist such as:
1) Authoratative server acting as intermediary (e.g., Kerberos, RADIUS)
2) Keys issues from an authorative source (e.g., PKI)

In these latter two environments, neither the initiator nor the
responder is authorative but, rather, they use the agency of another
entity that is both authorative and trusted. In my own mind, ISMS is
trying to evolve from the original shared secret key model to a model in
which a trusted server or a trusted issuing agency is authoratative.
Given this transition, I have trouble understanding how this historic
argument is still an issue for ISMS. Do you believe that it is and, if
so, what are your thoughts on this matter?

--Eric

-----Original Message-----
From: Steve Waldbusser [mailto:[email-masked]] 
Sent: Wednesday, October 05, 2005 8:13 PM
To: [email-masked]
Subject: Re: [Isms] authoritative

David H. and Bert asked me to give some background on this because I 
represented one end of a long debate on this issue about 10 years ago.

My point back then was that it is very important for responders to be 
authoritative (as opposed to initiators being authoritative)

In this type of communication, one end is deemed authoritative and 
typically has keys stored in long-term storage. The other end either 
gets the key from a human or has a "cached" copy of the key (I say 
"cached" because in the event the authoritative end says the key is 
wrong, it is simply discarded at which point the usual fallback is to 
prompt the user for the correct key).

We are very accustomed to the situation where the responder is 
authoritative and I guess we don't give it much thought. A transaction 
initiated by a user asks the user for the key and sends it. If the 
responder says the key is wrong, the user is prompted for a new one. If 
the transaction is initiated by unattended software, the key must be
cached.

But imagine the case if the initiator was authoritative. Then the 
responder must be the end with the human and/or the cached key. When a 
request arrives at the responder, a human can't react quickly enough to 
a prompt to type the key within the retransmit period so this doesn't 
work (and there may not be a human or the right human sitting at the 
responder anyway). So basically we are forced to cache the key. That's 
not so bad until we ask which keys are we going to cache? Unfortunately,

one answer is *all of them*. If there are 1000 potential initiators each

with 10 users, then I have to cache all 10,000 keys because only the 
initiators will know if they ever have any intention of sending me a 
transaction and I need to be prepared in case they do. An alternative is

to treat it as a provisioning task: when I configure a system to 
initiate transactions, I must load the key into all systems that I plan 
to communicate with which is a burden best avoided. Plus it seems that 
having all of those keys floating around might not be in the best 
interests of security.

To summarize, making the initiator authoritative means either:
- a massive configuration of all possible initiators in all possible 
responders; or,
- an additional, expensive provisioning step for setting up a new 
initiator (or even if I'm just adding a new communications target for an

existing initiator).

Most apps (email, fileshare, web, ssh) follow the "responder is 
authoritative" model. I can't think of any exceptions.

I haven't been following your discussion so I might be wrong about the 
implications, but it seems to me that the implication is that the notion

of authoritative is really a snmpv3 notion and not just a USM notion.

Steve

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

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

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 06 Oct 2005 17:18:25 -0700

>2) Keys issues from an authorative source (e.g., PKI)
Yes, you're right.

>so, what are your thoughts on this matter?

The conclusion I draw from your message is that I was wrong to suggest 
that it is an snmpv3 issue (i.e. transport level) . Instead, it would be 
more correct to say that the issue applies to all shared secret key 
models like USM.

Or maybe rather than saying "the responder should be authoritative", we 
should say "the initiator shouldn't be authoritative" and note that even 
in your Kerberos, Radius, PKI examples *somebody* is always 
authoritative. Does that mean it's an snmpv3 issue again? Forgive me as 
I'm not up to speed on the issues here and I could see myself changing 
my mind a few more times before I'm done.

But what worries me the most is that this sounds less and less like the 
issue I was first asked to comment on which I thought was roughly "we're 
trying to define SNMP over SSH and for notifications it has been 
asserted that it would be better if we made the initiator 
authoritative."  If that's the question, then my opinion is it would be 
a bad thing.

Steve