Subject: LPSK revisited (was RE: [Isms] Thoughts on Encapsulation)

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Thu, 5 May 2005 12:54:10 -0700

I am glad that Sam provides some concrete options/criteria that we 
can use as a start for further discussions.  

Since I proposed LPSK last month, there have been a few persons 
expressing supports, but otherwise ISMS responses have been pretty 
mute.  So I'd like to take this opportunity to reexamine LPSK to
see how it can fit in Sam's options.

Please see inline and let me know your comments.  I'd rather 
be criticized than ignored :)

> -----Original Message-----
> From: Sam Hartman
>
> 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...

The LPSK proposal can be an instantiation of this approach:

+ SRP-SASL can be used to do mutual (not just client) authentication
  so no cert is needed (see http://srp.stanford.edu for more SRP info)

+ Localized passwords (similar to USM key localization) are used to 
authenticate the servers.  This is an extension of SRP.  I discussed 
this with Thomas Wu (creator of SRP), and he expressed strong support 
for it.  He also made some suggestion about how to do the localization
securely for SRP.  I included his idea in the revised LPSK proposal 
(attached below.)

> 
> 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.

Again, LPSK authentication is transport-independent so it can be used 
w/ SSH and DTLS too, in a similar way to SSL/TLS.

For more info, please see attachment for the revised LPSK.  I'd like to 
thank Juergen Schoenwaelder, David Harrington, Wayne Kading, Keith 
McCloghrie, Kaushik Narayan, Thomas Wu, and others who have provided 
comments, suggestions, and/or supports for this effort.

Khanh

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 05 May 2005 16:33:18 -0400

>>>>> "Khanh" == Khanh Nguyen (khanhvn) <[email-masked]> writes:

    Khanh> I am glad that Sam provides some concrete options/criteria
    Khanh> that we can use as a start for further discussions.

    Khanh> Since I proposed LPSK last month, there have been a few
    Khanh> persons expressing supports, but otherwise ISMS responses
    Khanh> have been pretty mute.  So I'd like to take this
    Khanh> opportunity to reexamine LPSK to see how it can fit in
    Khanh> Sam's options.

What are the IPR issues with LPSK?

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 5 May 2005 16:34:53 -0400

>   so no cert is needed (see http://srp.stanford.edu for more SRP
info)

I have a concern about the use of SRP, since it is encumbered by
intellectual property issues.
I infer from the Cisco IPR statement that implementers of an SRP-based
ISMS solution might be subject to licensing fees. I don't think it is
wise to build a standard atop encumbered protocols.

David Harrington
[email-masked]