Subject: RE: [Isms] Thoughts on Encapsulation

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Thu, 19 May 2005 11:22:43 -0700

> -----Original Message-----
> From: Wayne Kading [mailto:[email-masked]] 
> 
> I would be interested to know whether the options below and 
> the SSH option support the "one touch" approach discussed 
> previously in this WG.

Sorry that I missed it... what's the "one touch" approach?

Khanh  

> 
> Wayne
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Blumenthal, Uri
> Sent: Thursday, May 19, 2005 10:05 AM
> To: Khanh Nguyen (khanhvn); [email-masked]
> Subject: RE: [Isms] Thoughts on Encapsulation
> 
> > Assume that we pick TLS and DTLS (correct me if that's a wrong 
> > assumption:), then I guess the next step in terms of architectural 
> > decisions will be about authentication.  There are a few 
> options that 
> > have been raised:
> > 
> > 1. Certificate (for server auth) + SASL (for client)
> 
> And we'd need to assume that (a) PKI is deployed within the 
> admin domain, and (b)SASL passwords (credentials) would be 
> provisioned somehow.
> 
> > 2. Mutual authentication using Kerberos
> 
> And we'd need to assume that those who don't have Kerberos, 
> will deploy it.
> 
> > 3. Mutual auth using PSK/LPSK (via SASL, TLS-SRP, SNMP PDU, etc.)
> 
> And again, the credentials would have to be provisioned somehow.
> 
> ...
> 

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

---

From: "Wayne Kading" <[email-masked]>
Date: Thu, 19 May 2005 14:34:02 -0500

I have added the string of previous "one touch" messages after my message
below.

Wayne

-----Original Message-----
From: Khanh Nguyen (khanhvn) [mailto:[email-masked]] 
Sent: Thursday, May 19, 2005 1:23 PM
To: Wayne Kading; Blumenthal, Uri
Cc: [email-masked]
Subject: RE: [Isms] Thoughts on Encapsulation

Khanh  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David T. Perkins
Sent: Wednesday, May 04, 2005 1:41 PM
To: Tom Petch
Cc: [email-masked]
Subject: Re: [Isms] One touch; was CALL FOR CONSENSUS: ISMS Architecture

HI,

Tom - the goal is not "zero touch for the box", but "zero touch"
to add support for SNMP. The ideal is that a box is configured
for management without support for SNMP. Then when it is decided
to support SNMP, the only thing that is done is to turn on
SNMP support for the box. Ideally, if syslog targets have already
been set up, then SNMP can use them for notification targets.
Ideally, the identities that have been set up for OTHER management
activities can be used for SNMP request operations on the box. 

On Wed, 4 May 2005, Tom Petch wrote:
> Wes
> 
> What is acceptable?  Ken said he could not imagine a zero touch secure
system
> and nor can I.  So at the very least, I have to put in a secret of some
shape or
> form when I instal the box, along with IPv4 address, default gateway,
sysName,
> sysContact etc.
> 
> Whether that happens to be the key for a preinstalled USM user, a secret
used
> for OOBK, the password of root/superuser, it makes no difference, I
believe it
> still has
> to be done.
> 
> Of course you also have to prevent its re-entry except under controlled
> circumstances but that is what we have today (in non-SNMP environments).
And
> with SNMPv3, it could be tied into the input of engine id, so both go in
> together or not at all.
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Wes Hardaker" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, May 03, 2005 10:35 PM
> Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> 
> 
> > >>>>> On Tue, 3 May 2005 12:05:22 -0700, "Randy Presuhn"
> <[email-masked]> said:
> >
> > Randy> However, any SNMP stack out there that supports USM should
> > Randy> provide the ability to use SNMPv3 to set the keys.  Rather than
> > Randy> modifying the SNMP stack, or modifying the existing "OOB
> > Randy> service", one could use an application acting on behalf of the
> > Randy> security administrator to talk to the OOB service, and use
> > Randy> SNMPv3 to set the USM keys.
> >
> > The thought had crossed my mind as well, but that still requires
> > either provisioning of the SNMPv3 service with an initial USM user
> > (bad IMHO) or requires the service to be run on the same host and a
> > noAuthNoPriv user with access privileges tied to the loopback address
> > (or any other form of an internal-to-the-box-trusted-network) which
> > probably doesn't exist in most implementations today.
> >
> > Requiring the setup of just one USM user instead of X is still bad,
> > IMHO, because operators don't want to do this today either.
> >
> > --
> > Wes Hardaker
> > Sparta, Inc.

Regards,
/david t. perkins