Subject: RE: [TLS] draft-tuexen-dtls-for-sctp-00.txt

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Mon, 28 Aug 2006 08:37:17 -0700

Hi Michael,

In the context of extended EAP keying material, we have been looking at
the problem of deriving multiple keys from a single root in a
coordinated fashion to avoid conflicts.  A similar approach may work for
TLS. I'm not sure that it makes sense to use the same details such as
IANA registry or key derivation function, but it may.  

The current version of the draft is
http://www.ietf.org/internet-drafts/draft-salowey-eap-emsk-deriv-01.txt.
Let me know if you have any questions. 

Cheers,

Joe 

> -----Original Message-----
> From: Michael Tuexen [mailto:[email-masked]] 
> Sent: Monday, August 28, 2006 3:26 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [TLS] draft-tuexen-dtls-for-sctp-00.txt
> 
> Dear all,
> 
> I would like to get some comments on draft-tuexen-dtls-for- 
> sctp-00.txt. This includes
> 
> - technical comments
>    We would like to use the TLS master secret to generate an 
> additional shared secret which
>    we would use at the transport layer (SCTP) for SCTP-AUTH. 
> It was already brought up,
>    that this is a layer violation (but a nice one) and the 
> risk would be that multiple
>    instances would do this, then these multiple instances 
> would use the same key material
>    which is definitely bad.
>    How should we progress here? From an implementation point 
> of view I see only a limited
>    risk here, because we will modify the TLS implementation 
> to generate the additional
>    material and would provide to to SCTP via a socket option. 
> So there is NOT API to the
>    TLS user involved.
>    Another point was to have something like a registry for 
> the material generated. This
>    would avoid two instances to use the same material. What 
> about this? Is this a good or
>    bad idea? How can we achieve this, if it is a good idea?
> 
> - procedural advises (Sam, Lars this is why you are CCed)
>    Currently this document is an individual submission. How 
> can it be progressed? Should
>    it be taken to a WG? Which one? SCTP (including SCTP-AUTH) 
> is handled in TSVWG and
>    TLS is handled in the TLS WG. I'm not sure where DTLS was 
> handled, if it was handled in
>    any WG.
> 
> I think having DTLS for SCTP is important because it is 
> needed by anyone using SCTP with PR-SCTP or unordered 
> delivery and wanting to have a TLS like security solution.
> IPFIX is one example.
> 
> Best regards
> Michael
> 
> 
> 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tls
> 

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

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 28 Aug 2006 21:19:59 +0200

Hi Joe,

(taking of the ADs from CC...)

thank you very much for the pointer. I'll look into it.

Best regards
Michael

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 28 Aug 2006 15:36:35 -0700

After a quick look at the documents in consideration, I am thinking 
something like an IKEv2 PRF+ might also work.

Each time an instance draws on the key material there would be a new 
key.  Would that work?

regards,
Lakshminath

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Aug 2006 15:41:34 -0700

> Each time an instance draws on the key material there would be a new

Well, the issue isn't really which PRF to use.

Given that TLS has one and that it's got the ability generate disjoint
keys from the same underlying entropy, that's kind of the obvious one
to use.

that's kind of a no-brainer. The issue is the layer violation
and making sure that each side gets the same (unique) key
even if multiple other protocols are trying to get keys out
of TLS this way...

-Ekr

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 28 Aug 2006 20:22:54 -0700

>even if multiple other protocols are trying to get keys out

Hi Eric,

Thanks for the explanation.  Looks like I have some more reading to 
do to understand this fully :).
Let me ask you a follow-up question: would a PRF with protocol labels 
and protocol specific data as input would work better instead?  It is 
plausible then to maintain an IANA registry of such labels so there 
is a unique key per protocol.  That was the idea Joe was proposing earlier.

regards,
Lakshminath

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Aug 2006 20:48:57 -0700

Lakshminath Dondeti <[email-masked]> writes:
> Thanks for the explanation.  Looks like I have some more reading to do
> to understand this fully :).
> plausible then to maintain an IANA registry of such labels so there is
> a unique key per protocol.  That was the idea Joe was proposing
> earlier.

That's basically what Michael is talking about....

-Ekr