Subject: Re: [Isms] Next steps about the next steps

From: "Pejaver, Rajaram" <[email-masked]>
Date: Wed, 6 Oct 2010 13:54:44 -0400

>> The sessionKey in a Kerberos ticket is a random value generated
>> by the  KDC. It can be safely used to encrypt a 'small' number
>> of messages, or bytes of data.
>
> I think the question was whether a *single* Kerberos ticket would be
used
> for more than a single SNMP PDU, thereby requiring session state.  The
> "traditional" SNMP security models, such as USM, are stateless, in
that the
> credentials are contained in each and every SNMP message.  Are you
proposing
> to include a Kerberos ticket in each and every SNMP message (even if
it's
> the same ticket)?

Yes.  If the goal is to keep the managed device (MD) stateless,
a Kerberos ticket must be included in each and every SNMP message.
The same ticket cannot be reused because the MD will detect it as a
replay
based on the timestamp in the ticket.
SNMP traps may be an exception where the MD saves the session key (along
with
the manager's IP address) for continued use because there will be few 
destinations (typically 1) for traps.

Thanks for clarifying the question.

--raj

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Oct 2010 02:23:13 +0200

On Wed, Oct 06, 2010 at 07:54:44PM +0200, Pejaver, Rajaram wrote:
 
> Yes.  If the goal is to keep the managed device (MD) stateless, a
> Kerberos ticket must be included in each and every SNMP message.
> replay based on the timestamp in the ticket.

Are you saying that for every getnext I have to get a new Kerberos
ticket?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 07 Oct 2010 11:03:01 -0400

> Are you saying that for every getnext I have to get a new Kerberos

No.  That's not true, and the document doesn't say it, either.
You do have to generate a new AP_REQ, or at least, you do if the command 
processor is doing replay detection correctly.  With some care, it ought to 
be careful to avoid even this, by doing replay detection at the KSM layer 
instead of in Kerberos.  In either case, you're going to have to _send_ 
both the ticket and AP_REQ with every request, in order to allow the server 
to remain stateless.

I've done a very brief overview of this document and while it needs some 
work, the basic approach seems reasonable.  I look forward to seeing 
comments from Wes and Ken Hornstein, who co-wrote the last KSM attempt 
around 10 years ago.  And, I still recommend asking for additional review 
on the krb-wg list.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Oct 2010 17:14:06 +0200

> around 10 years ago.  And, I still recommend asking for additional review 

Thanks for looking at the document. I have noticed your suggestion to
ask the krb-wg for review but since the authors want to post a more
detailed ID soon, I thought I wait for this new revision to pop up
before asking on the krb-wg list for reviews.

/js

---

From: "Yiu L. Lee" <[email-masked]>
Date: Thu, 7 Oct 2010 11:27:48 -0400

Hi Dave and Raj,

If you want to stop replay, the same ticket can't be used. This is one-way
to implement it. However, this is not a requirement for Kerberos. RFC 4120
3.2.3 does not require a ticket only used one time. I think a more efficient
approach is to use the same ticket for a period of time (defined inside the
ticket) and the MD will expire the ticket when the time is reached. The
Session-Key will be inside the ticket so that the MD doesn't need to
remember any key.

For security reason, the ticket life time should be short enough (say 15
mins). This will sufficiently reduce the load to generate a new ticket for
each snmp message.

Thanks,
Yiu

On 10/6/10 1:54 PM, "Pejaver, Rajaram" <[email-masked]>
wrote:

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

---

From: "Yiu L. Lee" <[email-masked]>
Date: Thu, 7 Oct 2010 11:29:29 -0400

No. Please read my previous reply.

Thanks,
Yiu

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 07 Oct 2010 15:14:38 -0700

>>>>> On Thu, 07 Oct 2010 11:03:01 -0400, Jeffrey Hutzelman <[email-masked]> said:

JH> I look forward to seeing comments from Wes and Ken Hornstein, who
JH> co-wrote the last KSM attempt around 10 years ago.

One of the things we did in the implementation (or at least started to
do; I can't remember if we completed it) was to allow for a longer lived
session where the ticket would only be sent in the first transmission
and in subsequent transmissions both sides would cache information.  I'd
like to see this as an option as it may be that the use case they have
is stateless, but many many real-world kerberos deployment's don't need
to be stateless.  For small boxes it may be necessary, but there are
many larger boxes that would benefit from longer lived sessions.  It
should be easy to add a bit in the request field that indicates whether
the server is expected to cache the security credentials and a
corresponding bit in the response saying whether it did or not.

(We never documented this aspect of the plan since the work wasn't going
to go forward at that time)

-- 
Wes Hardaker
Cobham Analytic Solutions