Subject: [Isms] Thoughts on encapsulation

From: Sam Hartman <[email-masked]>
Date: Wed, 04 May 2005 16:22:45 -0400

The following thoughts are presented as an individual.  I'm trying to
give a background on all the sorts of things you could do with
encapsulation for SNMP.  I may miss some things and I may over
simplify things.

So there are several different security technologies you might want to
support.  I'd argue that you probably want to support more than one.

1) TLS/SASL.  The combination of TLS and SASL go well together.  You
   typically use one or both.  In one common mode, TLS is used to
   authenticate the server (responder) to the client.  The server has
   a cert and the client does not.  You then use SASL to authenticate
   the client to the server.  TLS is used to protect the session.
   Another common mode supported by the TLS+SASL option only involves
   SASL.  You use a SASL security layer that provides mutual
   authentication to provide both data confidentiality and integrity
   to the session  and to authenticate both parties.  This SASL-only
   mode is used by Kerberos.  A third mode involves only TLS.  Both
   the client and server have certificates.  This actually often looks
   like the first mode because the SASL external mechanism is used to
   signal that TLS has provided the client authentication.

2) Ssh.  This provides for authentication  using public keys, Kerberos
   and passwords among other options.  I'd look at the netconf over
   ssh document as a starting point for how to do this.

3) DTLS.  DTLS is probably going to be important because it provides
   UDP support.  The catch with DTLS is going to be figuring out how
   to authenticate the client to the server if the client doesn't have
   credentials.  You could use SASL while not supporting security
   layers but doing so will make the Kerberos camp quite unhappy.

I'd also recommend trying to treat notifications as no different than
any other message.  Try two approaches and see which works out best.
The first is to try using the existing security context for
notifications.  The second is to try treating notifications as their
own security context; most of the mechanisms discussed work if you let
the notifier be the client/initiator.  The party receiving
notifications will need credentials but that's actually probably OK.

Here are some things I'd recommend against.  Note that these
recommendations are not things that would cause me to reject a
solution so much as things that would cause me as an individual to
have a bunch of questions about why you were taking that approach.

1) Supporting TLS and SASL without supporting all three modes as
   described above.

2) Using ssh keys but not ssh.

3) Assuming that SASL can be used in a datagram-like manner without
    ordering and reliable delivery.

4) Using Kerberos directly (*)

5) Using/recommending the Kerberos TLS ciphersuites.  The Kerberos ssh
   support is fine though.

6) Using raw public-key operations.

7) Extracting the session key from a SASL mechanism.  That's just not
supported by SASL implementations.

(*) It may be that SASL is not good enough for the datagram case and
thus you may want to provide for future extension to GSS.  That might
look a lot to some like raw Kerberos; it certainly would be
complicated.  I'm a bit concerned that UDP support is going to end up
complicated.

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

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Mon, 9 May 2005 11:30:33 -0700

> -----Original Message-----
> From: Sam Hartman
> > Tom Petch <[email-masked]> writes:
>     Tom> Sam, In which part of your dichotomy would you place
>     Tom> draft-ietf-tls-psk-08.txt

TLS-PSK is an interesting development.  I cited it in the LPSK 
proposal as it can be the one of the most straightforward ways 
to implement LPSK.  Its advantage is that binding b/w authen 
and encryp is built-in.  Some disadvantages are:

+ Weak protection against offline dictionary attacks. (EKE, SRP...
have been developed to solve this problem)
+ Transport-dependent (TLS).  There is no equivalent method 
defined for DTLS, SSH, etc. 
+ Not a TLS standard yet.

Those disadvantages are not really grave (e.g. dict attacks
can be prevented by long passwds), so it may still be a viable 
option, especially if it become a standard. 

> I don't think it fits well into ISMS.  You *could* ues it.  
> If you did I'd expect you to then use SASL external.  But it 
> only works well if you already have TLS PSKs configured 
> somehow.  It doesn't work well with RADIUS or other existing 
> mechanisms.
> 
> Same goes for any TLS SRP solution only more so.
> 
> Don't get me wrong: if your organization wants to deploy SRP 
> or TLS PSKs that's great.  You'll get better security; you'll 
> have all sorts of warm fuzzy feelings.  You won't be using 
> the infrastructure you have today though and supporting 
> existing infrastructure is the goal of ISMS.

The above issues are among problems that LPSK tries to solve.
LPSK uses the localized community strings and/or user passwords 
as the shared secrets for PSK authentication.  This way you can 
leverage the existing configurations of SNMPv1/USM infrastructure.
The use of user credentials to generage LPSK values also 
facilitates AAA integration.

Regards.

Khanh

> 
> Naturally I'm going to be concerned if we come up with an 
> ISMS solution that won't work with potential future 
> infrastructures.  I don't see that happening though.
>

---

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

> From: Eliot Lear [mailto:[email-masked]] 
> 
> Khanh Nguyen (khanhvn) wrote:
> > It has been a couple of weeks since we decided to use EK.  
> What should 
> > we do next?  Sam gave some thoughts about 3 choices of transport
> > encapsulation: TLS, SSH, and DTLS, and our recent 
> discussions seem to 
> > indicate a consensus that we may need more than one (to 
> support both 
> > TCP and UDP.)
> 
> For interoperability's sake I strongly suggest that we add a 
> single mechanism.

I agree, but sometime we need some tradeoff b/w interoperability and
flexibility.

Khanh

> Eliot

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 19 May 2005 15:04:47 -0400

>> > What should we do next?  Sam gave some thoughts about 3 choices
>> > of transport encapsulation: TLS, SSH, and DTLS, and our recent 
>> > discussions seem to indicate a consensus that we may need more
>> > than one (to support both TCP and UDP.)
>> 

Since (according to Wes's survey) the user population is split about
evenly between RADIUS, Kerberos, PKI and SSH - which single mandatory
mechanism is going to make at least 51% of the users happy?

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Thu, 19 May 2005 12:30:44 -0700

> From: Blumenthal, Uri [mailto:[email-masked]] 
> Sent: Thursday, May 19, 2005 12:05 PM
> To: Khanh Nguyen (khanhvn); Eliot Lear
> Cc: [email-masked]
> Subject: RE: [Isms] Thoughts on Encapsulation
> 
> >> > What should we do next?  Sam gave some thoughts about 3 
> choices of 
> >> > transport encapsulation: TLS, SSH, and DTLS, and our recent 
> >> > discussions seem to indicate a consensus that we may 
> need more than 
> >> > one (to support both TCP and UDP.)
> >> 
> >> For interoperability's sake I strongly suggest that we add 
> a single 
> >> mechanism.
> >
> Since (according to Wes's survey) the user population is 
> split about evenly between RADIUS, Kerberos, PKI and SSH - 
> which single mandatory mechanism is going to make at least 
> 51% of the users happy?
> 

66%  local accounts 

Khanh :)

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Fri, 20 May 2005 11:18:51 -0700

> BTW, PSKs have their own sets of problems, like 
> preprovisioning of keys, again in a managed service environment.
> 

Any authentication system will need preprovisioning of some 
credentials.  Of course we can talk about leveraging existing 
credentials, but that's another topic.

Khanh

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 20 May 2005 14:26:54 -0400

> credentials, but that's another topic.

I thought the main thrust behind this exercise was to find a way to
re-use existing credentials to make deployment easier. 

Another (smaller but still significant) issue was the desire to
introduce temporary short-term (session) keys to complement long-term
keys.

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Fri, 20 May 2005 11:28:34 -0700

> From: Sam Hartman [mailto:[email-masked]] 
> 
> >>>>> "Khanh" == Khanh Nguyen (khanhvn) <[email-masked]> writes:
> 
>     Khanh> Assume that we pick TLS and DTLS (correct me if that's a
>     Khanh> wrong assumption:), then I guess the next step in terms of
>     Khanh> architectural decisions will be about authentication.
>     Khanh> There are a few options that have been raised:
> 
>     Khanh> 1. Certificate (for server auth) + SASL (for client)
> 
> That's certainly not what I said.  I said certificate+SASL.  
> Certs are normally used for servers; SASL for clients.  
> However you should support all the combinations if you go this route.

Sorry for missing that.  BTW, if you use SASL password auth for
both client and server (mutual auth), then that belongs option 3
(PSK/LPSK) 

> 
>     Khanh> 
>     Khanh> 2. Mutual authentication using Kerberos 
> 
> You should not directly use Kerberos unless you explain why 
> SASL and SSH fail to meet your needs.  Both of these 
> approaches get you reasonable Kerberos support.

I didn't say that we should use Kerberos directly :)  I mentioned
Kerberos as a class of authentication method in general, which can 
be implemented by different transport mechanisms (SASL, SSH, etc).
I was trying to decouple transport from authentication, at least 
conceptually for the sake of our architectural decisions.

Khanh

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Fri, 20 May 2005 13:58:59 -0700

> From: Blumenthal, Uri
> I thought the main thrust behind this exercise was to find a 
> way to re-use existing credentials to make deployment easier. 

Sorry for not making myself clear.  I do strongly support reuse.
My point is that reuse is a _means_ to achieve the _end_ which 
is easing SNMPv3 deployment & maintenance.  We should not try
to reuse just for the sake of reuse.  Any reuse method should be 
evaluated in terms of its total benefit-cost contribution toward 
the end goal of ISMS:

"The solution should maximize useability in operational environments
to achieve high deployment success and at the same time minimize 
implementation and deployment costs to minimize the time until 
deployment is possible..."

> 
> Another (smaller but still significant) issue was the desire 
> to introduce temporary short-term (session) keys to 
> complement long-term keys.

Agree.  This issue is sometime overlooked.  Maybe we should 
add this point to ISMS charter.

Khanh