Subject: RE: [Isms] SSH / Reusability / etc

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 18 Apr 2005 17:55:20 -0400

Sorry, I don't quite understand the question.  AFAIK, TLS is not a key
agreement protocol - it's a data protection protocol that happens to
perform its own keying. Not designed for keying itself. Its use for
keying it tricky because you'd need to bind its credentials with those
negotiated by the "inner" key exchange - and then the question will be
"why not just use TLS itself to protect the data traffic".

I tend to think that GSSAPI is what should be employed (with some minor
modifications like exporting protection info). I'd be killed (or at
least assaulted :-) in 1996 for proposing this, but now I'll probably
get away with my hide intact. :-)

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]] 
Sent: Monday, April 18, 2005 2:48 PM
To: Blumenthal, Uri
Cc: Wes Hardaker; Sam Hartman; [email-masked]
Subject: RE: [Isms] SSH / Reusability / etc

HI,

Uri - two is understandable. However, how does that differ from
one security model where the data protection mechanism is
negociated like that which is done in other protocols such
as SSL/TLS?

Regards,
/david t. perkins

On Mon, 18 Apr 2005, Blumenthal, Uri wrote:

> I want one security model to provide session authentication, keying
> (derived from authentication), and session parameters (life-time and
> mapping to VACM, possibly other parameters). I'd like to have other
> security models that intake those parameters and actually protect the
> traffic. A-la IPsec approach.
> 
> This decoupling allows interchanging keying mechanisms and data
> protection mechnisms independently.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Wes Hardaker
> Sent: Sunday, April 17, 2005 1:32 PM
> To: Sam Hartman
> Cc: [email-masked]
> Subject: Re: [Isms] SSH / Reusability / etc
> 
> >>>>> On Sun, 17 Apr 2005 15:35:32 -0400, Sam Hartman
> <[email-masked]> said:
> 
> Sam> Also, note that SASL has its own mechanism for conveying the
> Sam> inner identity.  So if you were using SASL you might want to
> Sam> decide that you didn't need an identity in the SNMP PDU.
> 
> [FYI, this (and the other examples) are exactly why the SBSM running
> message has a numeric session identifier rather than a user string in
> it...  The user string is pulled from the authentication exchange and
> is stored by both sides and referenced via the session identifier.
> I'd expect TLS, SSH, or anything else that did the authentication
> elsewhere to do something similar (and yes, a USM user name field in
> the USM security model parameters could in theory be warped into a
> session identifier as well.  I'd argue heavily against that scheme
> using the same security model number even if the packet format was
> otherwise the same)]
> 
> -- 
> Wes Hardaker
> Sparta, Inc.
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 
> _______________________________________________
> 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: "David T. Perkins" <[email-masked]>
Date: Mon, 18 Apr 2005 18:19:45 -0700 (PDT)

HI,

Let me try again.

In your message, you said that you wanted two SNMP security models.
The first to set up a session, and the second to use the parameters
that were set up to exchange SNMP data messages.

And you said that your motivation was to "allow interchanging
keying mechanisms and data protection mechnisms independently."

My question was why could you not have two phases in a single
SNMP security model, since other protocols do so?

However, I was planning on bootstrapping a prototype by
first doing the "running" (your second security model)
assuming a fixed set of parameters, and then adding the
first phase that did the mutual auth, session keying, etc.
So, maybe it might work out to be a little easier.
Note that both the VACM "to group" and the "access"
tables use the security model as an index. Which of
the two security model identifiers were you going
to use?
 
Regards,
/david t. perkins