Re: [Lurk] Is this scenario covered by LURK?

[Russ Housley <[e-mail]>]

I do not think this group should include this use case in the document.

Russ


On Jun 20, 2016, at 9:42 PM, Youjianjie <[e-mail]> wrote:

> Hi Russ,
> 
> In the diagram below, the TLS connection terminates at the content server side. The edge server (in the context here, e.g. middle-box)  is on the data path, and it needs the key because it needs to do some policy control on the traffic flow.
> 
> Thanks,
> Jianjie
> 
> 发件人: Lurk [mailto:[e-mail]] 代表 Russ Housley
> 发送时间: 2016年6月20日 23:17
> 收件人: Youjianjie
> 抄送: IETF LURK
> 主题: [Lurk] Fwd: Is this scenario covered by LURK?
> 
> Youjianjie:
> 
> I’m sorry, but I do not get it.  In your diagram, the TLS Connection terminates at the same place as the Content Server/Key Server.  So, LURK is not needed for the Key Server to perform operation on behalf of the Content Server, and the Edge Servers do not need key operations because they do not terminate the TLS Connection.
> 
> Russ
> 
> 
> Begin forwarded message:
> 
> 
> From: Youjianjie <[e-mail]>
> Subject: [Lurk] 答复: Is this scenario covered by LURK?
> Date: June 16, 2016 at 10:42:29 PM EDT
> To: Daniel Migault <[e-mail]>, "Fossati, Thomas (Nokia - GB)" <[e-mail]>, "[e-mail]" <[e-mail]>
> 
> Hi Daniel, Thomas,
> 
> Here’s a diagram illustrating the scenario I want to mean.
> 
> <image001.jpg>
> 
> Please also see my comments inline below:
> 
> Thanks,
> Jianjie
>> -----邮件原件-----
>> 发件人: Daniel Migault [mailto:[e-mail]]
>> 发送时间: 2016年6月16日 21:27
>> 收件人: Fossati, Thomas (Nokia - GB); Youjianjie; [e-mail]
>> 主题: RE: [Lurk] Is this scenario covered by LURK?
>> 
>> Hi Jianjie,
>> 
>> Thank you for bringing a potential new use case. Currently LURK aims at
>> providing an interface between Edge Servers and the Key Server in a context of
>> TLS. If I am correct, the use case you provide introduces an additional element
>> designated as a Key Manager.  From the description it is not clear to me what
>> role the Key Manager has, and its relation with the Edge Servers and the Key
>> Server.
> 
> The reason why we introduce a Key manager is that there're many edge servers in some cases. It's better not to expose the topology of edge servers to the content owner if the Content Provider and the Content Owner are in different administrative domain.
> 
>> Could you specify what role the Key Manager has as well as interactions
>> between:
>>  -  the Key Manger and Key Server
> 
> Key information needs to be interacted between them.
> 
>>  - the Key Manager and the Edge Server
> 
> Key information needs to be interacted between them.
> 
>> In addition, it might be also helpful to provide feed back why you think the use
>> cases of the draft do not address your use case. Could you please point what is
>> missing ?
> 
> Is the content owner also expected to deliver content traffic in the current use case doc?
> https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-01
> 
>> BR,
>> Daniel
>> 
>> 
>> -----Original Message-----
>> From: Lurk [mailto:[e-mail]] On Behalf Of Fossati, Thomas
>> (Nokia - GB)
>> Sent: Thursday, June 16, 2016 8:40 AM
>> To: Youjianjie; [e-mail]
>> Subject: Re: [Lurk] Is this scenario covered by LURK?
>> 
>> Hi Jianjie,
>> 
>> On 16/06/2016 04:31, "Lurk on behalf of Youjianjie" <[e-mail]
>> on behalf of [e-mail]> wrote:
>>> Hi
>>> 
>>> I've a question about the scenario. I'm not sure if the following
>>> scenario is covered by the LURK.
>>> 
>>> In this scenario, the Content Provider and the Content Owner are in
>>> different administrative domain. Content owner is also responsible to
>>> deliver the content. The content provider participates the delivery of
>>> a content, providing necessary traffic management, such as FW, IPS.
>>> 
>>> For example, the edge server can be middle-box in the operator's network.
>>> There may be multiple middle-boxes, which can be managed by a key
>>> manager in the operator's network. In order to do traffic management,
>>> the key manager needs to interact with the key server located in the
>>> content owner domain, in order to do traffic management since the
>>> packets are encrypted. Here, the interaction between key manager (e.g.
>>> operator's
>>> network) and key server (in content owner) needs to be standardized? Is
>>> this use case in the scope of LURK?
>> 
>> Could you spend a few more lines on the kind of interaction that you are
>> envisaging between the key manager and the key server?
>> 
>> Cheers, t