Subject: [Netconf] PSK comment during NETCONF session at IETF

From: Badra <[email-masked]>
Date: Mon, 28 Nov 2011 16:40:54 +0100

On Wed, Nov 23, 2011 at 5:09 PM, Carsten Bormann <[email-masked]> wrote:

> On Nov 23, 2011, at 08:46, Bert Wijnen (IETF) wrote:
>
> > I will let Carsten explain what his exact question was/is.
> > My understanding of it was that he wonders what happens
> > during key roll-over. The way I understood it, one can
> > have 2 keys (ofr a period of time) during roll-over (i.e.
> > during the time that you are switching from one PSK to a new PSK).
> > So how is that being dealth with?
>
> Exactly.  Below please find the question as I posed it to two of the
> authors of RFC4279 (I don't have a reply yet), with some additional
> comments:
>
> > I'm neither a netconf nor a TLS expert, but I'm trying to do the same
> > thing in CoRE that draft-badra-netconf-rfc5539bis-00.txt tries to do
> > in section 3.2.2: use the PSK identity mechanism defined in RFC4279
> > section 2 as a way to establish a user name that is authenticated by
> > the TLS (/DTLS) session.
> >
> > RFC4279:
> >   Both clients and servers may have pre-shared keys with several
> >   different parties.  The client indicates which key to use by
> >   including a "PSK identity"...
> >
> > I would expect many organizations to have a policy that limits the
> > lifetime of a PSK.  (I'm not talking about rekeying of the TEK here --
> > this is taken care of by starting a new TLS connection.)  To do key
> > rollover, at any time an old and a new key may be active
> > simultaneously for one user.  I'd expect these to have different PSK
> > key identities.  So how can they map to the same username?
> >
> > 1) we can define an algorithmic mapping from the PSK identity to a
> > user name (by removing some information, which then effectively
> > becomes the key generation ID).
>
> e.g., the UTF-8 PSK identity string would be something like [email-masked]/1,
> [email-masked]/2, and the mapping to the username would get rid of the part
> starting with the slash.
>
>

RFC4279 doesn't specify that; I believe it is up to the application layer
to manage that.

Your approach can help. I can insert it to the document if people agree.

> 2) We can store the username with the key and use the PSK identity as
> > just that, a key identity; the username is then retrieved with the key.
>
> e.g., the UTF-8 PSK identity string would be something like Jpzb3YWS, and
> there would be a table like
>
> Jpzb3YWS [email-masked]             (key…)
> K3nV6qh0 [email-masked]             (key…)
> A4AINPdk [email-masked]     (key…)
> n5Dft5CQ [email-masked]     (key…)
> 2qQbLrhI [email-masked]     (key…)
>
> (probably with columns added that maintain the key validity time ranges).
>
> > 3) We can expect the TLS implementation to maintain multiple keys
> > under one identity and select the one that happens to authenticate.
>
> (which is a bit ugly to implement and would AFAIK be a new requirement on
> a TLS library that no existing one meets.)
>

> I'd like to know what is the right way to do this.  I'll then send a
> > message to the netconf and core WGs providing some explanation.
> >
> > Gruesse, Carsten
>
> In order to get this discussion going, please feel free to forward this
> message to the netconf list (I'm subscribing now, too).
>
>
The WG is cced to this message, and are invited to comment on that issue

Best regards
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Nov 2011 16:59:16 +0100

On Wed, Nov 23, 2011 at 05:09:24PM +0100, Carsten Bormann wrote:

> e.g., the UTF-8 PSK identity string would be something like [email-masked]/1, [email-masked]/2, and the mapping to the username would get rid of the part starting with the slash.
> 
> e.g., the UTF-8 PSK identity string would be something like Jpzb3YWS, and there would be a table like
> 
> (which is a bit ugly to implement and would AFAIK be a new requirement on a TLS library that no existing one meets.)
> 
> In order to get this discussion going, please feel free to forward this message to the netconf list (I'm subscribing now, too).

While we could invent option 1), things get bad if other WGs choose to
invent a different notation as there does not seem to be a common
notation for this (yet).

Option 2) seems to be a safe bet since it pushed the problem to
controllable configuration (and as a side effect we would have a
NETCONF way of managing PSK keys).

Option 3 seems to be out of scope since PSK does not allow "key
probing" (and I assume security folks might not like this either).

/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: "t.petch" <[email-masked]>
Date: Tue, 29 Nov 2011 11:40:46 +0100

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Carsten Bormann" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 28, 2011 4:59 PM
> invent a different notation as there does not seem to be a common

I think that the underlying problem is a lack of interest in PSK
and allied technologies.  There was an I-D brought to the TLS
recently in this area which provoked the response, 'why do
you expect this one to succeed when the previous three I-Ds
have not?'

Logically, PSK makes a lot of sense but as here, more work
is needed.  But it just does not seem to get used, hence, IMO, the
unresolved details.

Tom Petch

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Nov 2011 16:09:23 +0100

> NETCONF way of managing PSK keys).

Sounds good to me.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Nov 2011 21:19:45 +0100

On Nov 29 2011, at 11:40, t.petch wrote:

> lack of interest in PSK
> and allied technologies

I see the same problem in a slightly different light:
TLS is just not yet being used a lot for PSK (just as, e.g., TLS 1.2  
hasn't seen a lot of use yet).
If we want to get TLS there (and I certainly want to get the DTLS part  
of TLS there), we have to make it fit for PSK.
Or we'll have to use something else, and that would be a pity.

But then I don't think the mapping between the identity hints used in  
the handshake and application layer user-ids used in ACLs is something  
that needs to be part of TLS itself.
Different applications may have different needs here.
Where they don't, something like RFC 6125 may emerge.

Gruesse, Carsten