From rgm@labs.htt-consult.com Wed Dec 4 03:20:57 2013 Return-Path: X-Original-To: siesta@ietfa.amsl.com Delivered-To: siesta@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91F71AE106 for ; Wed, 4 Dec 2013 03:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNh_Kv-Hi5zH for ; Wed, 4 Dec 2013 03:20:54 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 168081AE242 for ; Wed, 4 Dec 2013 03:20:53 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 054F762A6E for ; Wed, 4 Dec 2013 11:20:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPzArwjvjeiZ for ; Wed, 4 Dec 2013 06:20:34 -0500 (EST) Received: from lx120e2.htt-consult.com (ip-64-134-168-45.public.wayport.net [64.134.168.45]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 1EA3A62A6B for ; Wed, 4 Dec 2013 06:20:33 -0500 (EST) Message-ID: <529F1000.5040006@labs.htt-consult.com> Date: Wed, 04 Dec 2013 06:20:32 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: siesta@ietf.org Content-Type: multipart/alternative; boundary="------------070306010901040805000103" Subject: [siesta] Another Siesta approach X-BeenThere: siesta@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "SessIon layEr SecuriTy Approach discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 11:20:58 -0000 This is a multi-part message in MIME format. --------------070306010901040805000103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I saw this come through on the SAAG list, so it is appropriate to bring it up here and see how well it fits the problem statement and goals I have attempted to articulate: ========================================= On 11/25/2013 09:27 AM, Stephen Farrell wrote: FYI, please note this proposed new APPS area WG. We'll need to try get a bunch of security folks involved in that so please consider spending a few cycles to help out with the work. I'd say discussion of that charter would be best done on apps-discuss@ietf.org since its proposed as an APPS area WG and the apps-discuss list is probably where there's the best concentration of relevant expertise, so please direct any substantive discussion there. Thanks, S. -------- Original Message -------- Subject: WG Review: Using TLS in Applications (uta) Date: Fri, 22 Nov 2013 09:35:54 -0800 From: The IESG Reply-To:ietf@ietf.org To: IETF-Announce A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-12-02. Using TLS in Applications (uta) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Barry Leiba Charter: There is a renewed and urgent interest in the IETF to increase the security of transmissions over the Internet. Many application protocols have defined methods for using TLS to authenticate the server (and sometimes the client), and to encrypt the connection between the client and server. However, there is a diversity of definitions and requirements, and that diversity has caused confusion for application developers and also has led to lack of interoperability or lack of deployment. Implementers and deployers are faced with multiple security issues in real-world usage of TLS, which currently does not preclude insecure ciphers and modes of operation. This WG has the following tasks: - Update the definitions for using TLS over a set of representative application protocols. This includes communication with proxies, between servers, and between peers, where appropriate, in addition to client/server communication. - Specify a set of best practices for TLS clients and servers, including but not limited to recommended versions of TLS, using forward secrecy, and one or more ciphersuites and extensions that are mandatory to implement. - Consider, and possibly define, a standard way for an application client and server to use unauthenticated encryption through TLS when server and/or client authentication cannot be achieved. - Create a document that helps application protocol developers use TLS in future application definitions. The initial set of representative application protocols is SMTP, POP, IMAP, XMPP, and HTTP 1.1. It is expected that other protocols that use TLS might later be updated using the guidelines from this WG, and that those updates will happen through other WGs or through individual submissions. The WG will make the fewest changes needed to achieve good interoperable security for the applications using TLS. No changes to TLS itself will be made in this WG, and the WG will ensure that changes to current versions of popular TLS libaries will not be required to conform to the WG's specifications. This WG will collaborate with other IETF WGs, in particular with the TLS and DANE WGs. Milestones: --------------070306010901040805000103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I saw this come through on the SAAG list, so it is appropriate to bring it up here and see how well it fits the problem statement and goals I have attempted to articulate:

=========================================

On 11/25/2013 09:27 AM, Stephen Farrell wrote:

FYI, please note this proposed new APPS area WG. We'll need
to try get a bunch of security folks involved in that so
please consider spending a few cycles to help out with the
work.

I'd say discussion of that charter would be best done on
apps-discuss@ietf.org since its proposed as an APPS area
WG and the apps-discuss list is probably where there's
the best concentration of relevant expertise, so please
direct any substantive discussion there.

Thanks,
S.


-------- Original Message --------
Subject: WG Review: Using TLS in Applications (uta)
Date: Fri, 22 Nov 2013 09:35:54 -0800
From: The IESG <iesg-secretary@ietf.org>
Reply-To: ietf@ietf.org
To: IETF-Announce <ietf-announce@ietf.org>

A new IETF working group has been proposed in the Applications Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2013-12-02.

Using TLS in Applications (uta)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
  Barry Leiba <barryleiba@computer.org>


Charter:

There is a renewed and urgent interest in the IETF to increase the
security of transmissions over the Internet. Many application protocols
have defined methods for using TLS to authenticate the server (and
sometimes the client), and to encrypt the connection between the client
and server. However, there is a diversity of definitions and
requirements, and that diversity has caused confusion for application
developers and also has led to lack of interoperability or lack of
deployment. Implementers and deployers are faced with multiple security
issues in real-world usage of TLS, which currently does not preclude
insecure ciphers and modes of operation.

This WG has the following tasks:

- Update the definitions for using TLS over a set of representative
application protocols.  This includes communication with proxies, between
servers, and between peers, where appropriate, in addition to
client/server communication.

- Specify a set of best practices for TLS clients and servers, including
but not limited to recommended versions of TLS, using forward secrecy,
and one or more ciphersuites and extensions that are mandatory to
implement.

- Consider, and possibly define, a standard way for an application client
and server to use unauthenticated encryption through TLS when server
and/or client authentication cannot be achieved.

- Create a document that helps application protocol developers use TLS in
future application definitions.

The initial set of representative application protocols is SMTP, POP,
IMAP, XMPP, and HTTP 1.1. It is expected that other protocols that use
TLS might later be updated using the guidelines from this WG, and that
those updates will happen through other WGs or through individual
submissions.

The WG will make the fewest changes needed to achieve good interoperable
security for the applications using TLS.  No changes to TLS itself will
be made in this WG, and the WG will ensure that changes to current
versions of popular TLS libaries will not be required to conform to the
WG's specifications.

This WG will collaborate with other IETF WGs, in particular with the TLS
and DANE WGs.

Milestones:
--------------070306010901040805000103-- From diego@tid.es Wed Dec 4 07:45:51 2013 Return-Path: X-Original-To: siesta@ietfa.amsl.com Delivered-To: siesta@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A83C1AE2AF for ; Wed, 4 Dec 2013 07:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAfjTBEcyTHK for ; Wed, 4 Dec 2013 07:45:47 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA5681AE2A8 for ; Wed, 4 Dec 2013 07:45:45 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MXA00529H40ZE@tid.hi.inet> for siesta@ietf.org; Wed, 04 Dec 2013 16:45:41 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 43.14.03314.52E4F925; Wed, 04 Dec 2013 16:45:41 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MXA0053RH45XU@tid.hi.inet> for siesta@ietf.org; Wed, 04 Dec 2013 16:45:41 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.16]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.03.0158.001; Wed, 04 Dec 2013 16:45:41 +0100 Date: Wed, 04 Dec 2013 15:45:40 +0000 From: "Diego R. Lopez" In-reply-to: <529F1000.5040006@labs.htt-consult.com> X-Originating-IP: [10.95.64.115] To: Robert Moskowitz Message-id: <015B9D83-7BDF-43AD-B4AE-0B40EBBEBE8F@tid.es> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_HeW6hVcx/tYSXXT8qTxMKg)" Content-language: en-US Accept-Language: en-US, es-ES Thread-topic: [siesta] Another Siesta approach Thread-index: AQHO8OLv1B/YaqYqH0S/svN0GgfO9ppEHToA X-AuditID: 0a5f4068-b7fe58e000000cf2-cd-529f4e251529 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsXCFe/ApavqNz/I4P1JSYup8w+xOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/YL+4JLaRWbFjxibGB8E9bFyMkhIWAiMal9BQuELSZx4d56 ti5GLg4hgQOMEttfbmCBcH4wSnT1/WCEcDYwSvzadR+shUVAVaJ5w3Mwmw3IftT8mx3EFhbQ lTh66w0jiM0JtKLtxBVGiBUKEn/OPQarFxHQl9j9eDobiM0soCnRdPsiWC+vgKXE0seNzBC2 oMSPyfdYIGqiJX6cWM4KYYtLNLfeBIszCshKvJs/nxVipp7E8e0foGwjiS3H9rND7BWQWLLn PDOELSrx8vE/sBohAWOJfW/usE1gFJuFZN0sJOtmIVkHYetJ3Jg6hQ3C1pZYtvA1M4StKzHj 3yGoGjOJW1fWMSGrWcDIsYpRrDipKDM9oyQ3MTMn3cBQLyNTLzMvtWQTIyQeM3YwLt+pcohR gINRiYc3gXNekBBrYllxZe4hRgkOZiUR3l1284OEeFMSK6tSi/Lji0pzUosPMTJxcEo1MOqx f83qDy2yWPXDU29W9vcI2y3NGsrmN/k/ftnxKulEYbHu3Nawuxvi7fWP74j929fkX9hW8nfF rW1lrHtKZU/uZJmm/7qopszA6+K/wvLMXQe6fhlffvxOt7iWv/yt1yrVV5tNPhjpJEU+sCzh 5VX/LTDjt1tWo0Tkcrm25unfVsv8qE56r8RSnJFoqMVcVJwIAAM+kQWlAgAA References: <529F1000.5040006@labs.htt-consult.com> Cc: "" Subject: Re: [siesta] Another Siesta approach X-BeenThere: siesta@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "SessIon layEr SecuriTy Approach discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:45:51 -0000 --Boundary_(ID_HeW6hVcx/tYSXXT8qTxMKg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable I'm not that sure this, being essentially a work oriented towards best-prac= tices in TLS, would impact the ideas around SIESTA, with two probable excep= tions. First, the possibility of relying on TLS as KMP (as described in RFC= XXX with a potential application of DANE) Second, as a possibility to deli= mitate use cases well suited for TLS versus those use cases in which sessio= n-based security provides an advantage, like I think SDN and NFV are for ex= ample... Be goode, On 4 Dec 2013, at 12:20 , Robert Moskowitz wrote: I saw this come through on the SAAG list, so it is appropriate to bring it = up here and see how well it fits the problem statement and goals I have att= empted to articulate: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 11/25/2013 09:27 AM, Stephen Farrell wrote: FYI, please note this proposed new APPS area WG. We'll need to try get a bunch of security folks involved in that so please consider spending a few cycles to help out with the work. I'd say discussion of that charter would be best done on apps-discuss@ietf.org since its proposed as a= n APPS area WG and the apps-discuss list is probably where there's the best concentration of relevant expertise, so please direct any substantive discussion there. Thanks, S. -------- Original Message -------- Subject: WG Review: Using TLS in Applications (uta) Date: Fri, 22 Nov 2013 09:35:54 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) = by 2013-12-02. Using TLS in Applications (uta) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Barry Leiba Charter: There is a renewed and urgent interest in the IETF to increase the security of transmissions over the Internet. Many application protocols have defined methods for using TLS to authenticate the server (and sometimes the client), and to encrypt the connection between the client and server. However, there is a diversity of definitions and requirements, and that diversity has caused confusion for application developers and also has led to lack of interoperability or lack of deployment. Implementers and deployers are faced with multiple security issues in real-world usage of TLS, which currently does not preclude insecure ciphers and modes of operation. This WG has the following tasks: - Update the definitions for using TLS over a set of representative application protocols. This includes communication with proxies, between servers, and between peers, where appropriate, in addition to client/server communication. - Specify a set of best practices for TLS clients and servers, including but not limited to recommended versions of TLS, using forward secrecy, and one or more ciphersuites and extensions that are mandatory to implement. - Consider, and possibly define, a standard way for an application client and server to use unauthenticated encryption through TLS when server and/or client authentication cannot be achieved. - Create a document that helps application protocol developers use TLS in future application definitions. The initial set of representative application protocols is SMTP, POP, IMAP, XMPP, and HTTP 1.1. It is expected that other protocols that use TLS might later be updated using the guidelines from this WG, and that those updates will happen through other WGs or through individual submissions. The WG will make the fewest changes needed to achieve good interoperable security for the applications using TLS. No changes to TLS itself will be made in this WG, and the WG will ensure that changes to current versions of popular TLS libaries will not be required to conform to the WG's specifications. This WG will collaborate with other IETF WGs, in particular with the TLS and DANE WGs. Milestones: _______________________________________________ siesta mailing list siesta@ietf.org https://www.ietf.org/mailman/listinfo/siesta -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_HeW6hVcx/tYSXXT8qTxMKg) Content-id: <49E91B843CC3BE49AD038655A0E66A21@hi.inet> Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable I'm not that sure this, being essentially a work oriented towards best-prac= tices in TLS, would impact the ideas around SIESTA, with two probable excep= tions. First, the possibility of relying on TLS as KMP (as described in RFC= XXX with a potential application of DANE) Second, as a possibility to delimitate use cases well suited for = TLS versus those use cases in which session-based security provides an adva= ntage, like I think SDN and NFV are for example...

Be goode,

On 4 Dec 2013, at 12:20 , Robert Moskowitz wrote:

I saw this come through on the SAAG list, so it is= appropriate to bring it up here and see how well it fits the problem state= ment and goals I have attempted to articulate:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On 11/25/2013 09:27 AM, Stephen Farrell wrote:

FYI, please note this proposed new APPS area WG. We'll need
to try get a bunch of security folks involved in that so
please consider spending a few cycles to help out with the
work.

I'd say discussion of that charter would be best done on
apps-discuss@ietf.org since its proposed as an APPS area
WG and the apps-discuss list is probably where there's
the best concentration of relevant expertise, so please
direct any substantive discussion there.

Thanks,
S.


-------- Original Message --------
Subject: WG Review: Using TLS in Applications (uta)
Date: Fri, 22 Nov 2013 09:35:54 -0800
From: The IESG <iesg-secretary@ietf.org>
Reply-To: ietf@ietf.org
To: IETF-Announce <ietf-announce@ietf.org>

A new IETF working group has been proposed in the Applications Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2013-12-02.

Using TLS in Applications (uta)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
  Barry Leiba <barryleiba@computer.org>


Charter:

There is a renewed and urgent interest in the IETF to increase the
security of transmissions over the Internet. Many application protocols
have defined methods for using TLS to authenticate the server (and
sometimes the client), and to encrypt the connection between the client
and server. However, there is a diversity of definitions and
requirements, and that diversity has caused confusion for application
developers and also has led to lack of interoperability or lack of
deployment. Implementers and deployers are faced with multiple security
issues in real-world usage of TLS, which currently does not preclude
insecure ciphers and modes of operation.

This WG has the following tasks:

- Update the definitions for using TLS over a set of representative
application protocols.  This includes communication with proxies, between
servers, and between peers, where appropriate, in addition to
client/server communication.

- Specify a set of best practices for TLS clients and servers, including
but not limited to recommended versions of TLS, using forward secrecy,
and one or more ciphersuites and extensions that are mandatory to
implement.

- Consider, and possibly define, a standard way for an application client
and server to use unauthenticated encryption through TLS when server
and/or client authentication cannot be achieved.

- Create a document that helps application protocol developers use TLS in
future application definitions.

The initial set of representative application protocols is SMTP, POP,
IMAP, XMPP, and HTTP 1.1. It is expected that other protocols that use
TLS might later be updated using the guidelines from this WG, and that
those updates will happen through other WGs or through individual
submissions.

The WG will make the fewest changes needed to achieve good interoperable
security for the applications using TLS.  No changes to TLS itself will
be made in this WG, and the WG will ensure that changes to current
versions of popular TLS libaries will not be required to conform to the
WG's specifications.

This WG will collaborate with other IETF WGs, in particular with the TLS
and DANE WGs.

Milestones:
_______________________________________________
siesta mailing list
siesta@ietf.org
https://www.ietf.org/mailman/listinfo/siesta


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_HeW6hVcx/tYSXXT8qTxMKg)-- From rgm@labs.htt-consult.com Mon Dec 9 10:28:10 2013 Return-Path: X-Original-To: siesta@ietfa.amsl.com Delivered-To: siesta@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9E61AE427 for ; Mon, 9 Dec 2013 10:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRyPDfAIdjvA for ; Mon, 9 Dec 2013 10:28:08 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 65C741AE418 for ; Mon, 9 Dec 2013 10:28:08 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 00D2662A62 for ; Mon, 9 Dec 2013 18:28:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IjEtwPliim4 for ; Mon, 9 Dec 2013 13:27:53 -0500 (EST) Received: from lx120e2.htt-consult.com (lx120e2.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 040FC62A5D for ; Mon, 9 Dec 2013 13:27:52 -0500 (EST) Message-ID: <52A60BA8.3020701@labs.htt-consult.com> Date: Mon, 09 Dec 2013 13:27:52 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: siesta@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [siesta] SSE/KMP - the westbound interface X-BeenThere: siesta@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "SessIon layEr SecuriTy Approach discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 18:28:10 -0000 We are making progress on a well crafted problem statement. Such things are very important, but need some meat here on the bones... A number of conversations around the westbound interface. What are the selectors passed to the KMP? What is returned? I will take a stab at it, and hoepfully I will get so good feedback (observation - some of you have done this for other KMP consumers like ESP): From SSE to KMP for setup request: What type of security context: Unicast or multicast. And for multicast, a single SPI or SPI per transmittor? What SSE format What ciphersuite: Crypto-algo{&mode of operation], keysize Other? For rekey request: SPI Return from KMP: SPI KEYMAT (size, key, type) Where type is unicast or group? Of course if there is some specific copyable text from an existing API document, that would help a lot.