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

Lakshminath Dondeti <ldondeti@qualcomm.com> Mon, 28 August 2006 22:36 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpiu-0001XJ-4z; Mon, 28 Aug 2006 18:36:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpis-0001XE-Ug for tls@ietf.org; Mon, 28 Aug 2006 18:36:50 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHpir-0007m3-I1 for tls@ietf.org; Mon, 28 Aug 2006 18:36:50 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7SMad6O032707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Aug 2006 15:36:41 -0700
Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-68.qualcomm.com [10.50.77.68]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7SMaZPB025243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Aug 2006 15:36:37 -0700 (PDT)
Message-Id: <7.0.1.0.2.20060828153142.06aa3fd0@qualcomm.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Mon, 28 Aug 2006 15:36:35 -0700
To: "Joseph Salowey \(jsalowey\)" <jsalowey@cisco.com>, "Michael Tuexen" <Michael.Tuexen@lurchi.franken.de>, <tls@ietf.org>
From: Lakshminath Dondeti <ldondeti@qualcomm.com>
Subject: RE: [TLS] draft-tuexen-dtls-for-sctp-00.txt
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE502580384@xmb-sjc-225.amer. cisco.com>
References: <AC1CFD94F59A264488DC2BEC3E890DE502580384@xmb-sjc-225.amer.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: lars.eggert@netlab.nec.de, hartmans-ietf@mit.edu
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

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

At 08:37 AM 8/28/2006, Joseph Salowey \(jsalowey\) wrote:
>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:Michael.Tuexen@lurchi.franken.de]
> > Sent: Monday, August 28, 2006 3:26 AM
> > To: tls@ietf.org
> > Cc: lars.eggert@netlab.nec.de; hartmans-ietf@mit.edu
> > 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
> > TLS@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/tls
> >
>
>_______________________________________________
>TLS mailing list
>TLS@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls