Subject: [Isms] Next steps about the next steps

From: Wes Hardaker <[email-masked]>
Date: Tue, 05 Oct 2010 13:55:51 -0700

So,

I'm willing to draft up charter text that includes items for:

  - TLSTM to draft
  - KSM

(But I don't want to do it until the chairs say they're willing to
potentially accept it ;-)
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Oct 2010 00:04:17 +0200

> potentially accept it ;-)

Here is my view on these two items:

- Concerning the advancement of TLSTM plus related specifications to
  Draft Standard, I first checked with the ADs because some of these
  specifications will have normative dependencies to e.g. TLS and
  DTLS, which are likely going to remain Proposed Standards. The ADs
  told me that they are willing to defend this in the IESG, so this
  concern has been cleared. Since we also seem to have the necessary
  human resources, I am supportive to undertake this work.

- Concerning KSM I like to see a revised ID that better details the
  proposal and brings it more inline with the way we happen to write
  SNMP security models. Once an updated ID is available, I like to
  have some feedback in particular from Kerberos experts about the
  approach taken etc. In short, I like to better understand the
  technical details and the potential pitfalls, which is also needed
  in order to set realistic milestones.

Given that the next IETF meeting is coming up relatively soon, it
might make sense to discuss KSM in some technical detail in Beijing
before we execute the formal rechartering procedure through the IESG.

Russ, anything you like to add?

/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: Wes Hardaker <[email-masked]>
Date: Tue, 05 Oct 2010 15:56:43 -0700

>>>>> On Wed, 6 Oct 2010 00:04:17 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> - Concerning KSM I like to see a revised ID that better details the
JS> proposal and brings it more inline with the way we happen to write
JS> SNMP security models.

I happened to be in the same room as one of the authors today and
believe they're planning on a very-near-term republication.  Hopefully
that'll occur.

Thanks for the note and I'm glad that everyone agrees the 595[0,1,3]
advancement is a good thing.

JS> Given that the next IETF meeting is coming up relatively soon, it
JS> might make sense to discuss KSM in some technical detail in Beijing
JS> before we execute the formal rechartering procedure through the IESG.

I agree that's a possibility, but I'd rather see the charter hammered
out on the list and done with sooner so we can move to just technical
discussions on the list and at the meeting (which now looks like it
should be held) on the technical issues in an effort to move it forward.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: [email-masked]
Date: Tue, 5 Oct 2010 23:45:42 -0400

> Russ, anything you like to add?

This sounds like a good approach. In think advancement TLSTM and 
related specs is pretty straight forward.  We do need the new KSN spec 
as well as making sure there is sufficient interest and energy to work 
it.

Russ

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Oct 2010 13:32:47 +0200

> should be held) on the technical issues in an effort to move it forward.

I assume the authors do already work on the technical issues, which is
great. However, since milestones are part of the WG charters, I like
to get a better understanding whether there are any technical
obstacles that might causes this work to take years instead of a few
months. This is why I like to have early feedback from Kerberos
experts before attempting to charter this work.

If we meet in Beijing to discuss this work, we will focus on the
discussion of the technical issues, regardless of the rechartering
status.

That said, I do not mind receiving input for possible new charter 
text before the Beijing meeting. Activity to get work done is always
more than welcome.

/js

---

From: "Pejaver, Rajaram" <[email-masked]>
Date: Wed, 6 Oct 2010 11:42:00 -0400

>>> My reading of 
>>> the ID is that you are not really interested in the session key but 
>>> you only want to use it for a single SNMP request/response 
>>> interaction.
>> This is why I like to have early feedback from Kerberos

> The same ticket+sessionkey will be used if there are multiple SNMP
> interactions between the NMS (Manager) & the managed device.

Juergen,

I did not fully answer your earlier question.

KSM is aimed specifically for situations that involve short
transactions.
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.
SNMP interactions that involve a 'large' number of messages (or data)
will
require rekeying which is not envisioned for KSM.
Those interactions should use other stream based security models.

We welcome suggestions for guidelines for what values are 'large' vs.
'small'.
It is more of a AES/crypto question rather than a Kerberos one.

Regards

Rajaram Pejaver

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 6 Oct 2010 12:17:08 -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)?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 06 Oct 2010 12:27:36 -0400

> before we execute the formal rechartering procedure through the IESG.

I'm certainly willing to review and contribute to this work, if the WG 
takes it on.  You might find other reviewers by asking on the krb-wg list. 
I will not be in Beijing, but I will try to participate via jabber.

-- Jeff

---

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

> to include a Kerberos ticket in each and every SNMP message (even if it's

My understanding of the text was that KSM reuses the same *ticket* for
multiple transactions instead of establishing the session key and
session state. But I might be wrong...

/js

---

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

On Wed, Oct 06, 2010 at 05:42:00PM +0200, Pejaver, Rajaram wrote:
 
> transactions.  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.  SNMP interactions that
> involve a 'large' number of messages (or data) will require rekeying
> which is not envisioned for KSM.  Those interactions should use
> other stream based security models.
>
> We welcome suggestions for guidelines for what values are 'large'
> vs.  'small'.  It is more of a AES/crypto question rather than a
> Kerberos one.

USM has a long lived symmetric key and a management application has to
run a key update procedure to refresh the key. That is all fine. My
reading, however, was that you send the ticket containing the session
key multiple times instead of establishing the session key contained
in the ticket once and then reusing the session state. Am I confused?

/js

---

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

Hi Juergen,

You understanding is also my understanding.

Thanks,
Yiu