Re: [Ace] Adrian Farrel's Block on charter-ietf-ace-00-00: (with BLOCK)

[Göran Selander <[e-mail]>]

Adrian, thanks for clarification.


I don’t want to reopen this, but I think that the latest changes are a bit
misleading, in particular

"Note that the work is limited to CoAP and HTTP with DTLS and TLS. Other
application protocols with their related
transport protocols, and other protocols at other layers in the stack, are
out of scope.”

There is at least the multi-party protocol (referenced to as as “Existing
authentication and authorization protocols” in the preceding paragraph of
the charter) in scope. Its functionality may potentially complement or
overlap DTLS/TLS (e.g. providing keys, security context etc.) If we
consider this functionality out of scope at this stage we are making a
safe bet that the solution will not be optimal for constrained
environments.

So, the limitation to CoAP and HTTP is fine. DTLS and TLS as working
assumption/default security protocol is OK, but I think we should be open
to optimisations.

What do others think about this?


Göran




On 14/05/14 12:10, "Adrian Farrel" <[e-mail]> wrote:

>I have no attachment to the specific transports, and would be happy with
>the
>constraint being voiced as security or application layer protocols.
>
>My mention of DTLS and TLS was just picking up the text that was already
>there.
>
>A
>
>> -----Original Message-----
>> From: Göran Selander [mailto:[e-mail]]
>> Sent: 14 May 2014 06:25
>> To: Adrian Farrel; The IESG
>> Cc: [e-mail]
>> Subject: Re: [Ace] Adrian Farrel's Block on charter-ietf-ace-00-00:
>>(with
>BLOCK)
>> 
>> Adrian, and all
>> 
>> On 13/05/14 13:37, "Adrian Farrel" <[e-mail]> wrote:
>> >
>> >Reading the charter I don't see clearly that this work is limited to
>> >specific protocols or specific places in the stack. I sense that the
>> >intention is not to work on all protocols in constrained environments
>> >but I don't think that is what the text actually says. I think that
>> >the intention is to limit the work to the applications protocols with
>> >their related transport protocols (withness CoAP and HTTP with DTLS
>> >and TLS). Could this be called out more specifically?
>> >
>> 
>> I understand the concern that the work would not be sufficiently focused
>> unless restricting to specific protocols or protocol layers. I¹m fine
>>with
>> restricting to HTTP and CoAP for access to resources, but I like to
>> understand exactly what is meant by limiting the work to TLS/DTLS.
>> 
>> As I understand the problem, it is about a multi-party protocol where a
>> third party supports a client and a server, which are constrained, to
>> perform authenticated and authorized access. The third party is assumed
>>to
>> have established a key/security association at least with the server to
>> perform this. Compare section 1 of
>> http://tools.ietf.org/html/draft-tschofenig-ace-overview-00
>> 
>> 
>> The fact that the client and server are constrained implies in
>>particular
>> that a DTLS handshake has a significant performance impact. If we really
>> want it to support the constrained devices, we would use the established
>> security association(s) and allow the third party to also be involved in
>> authentication and key establishment between client and resource server.
>> Compare e.g. OAuth 2.0 MAC Tokens
>> http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-04
>> 
>> Now, the 00-01 version of the charter says:
>> 
>> "Once progress in identifying suitable candidate solutions has been
>>made,
>> the working group will verify whether the same mechanisms are also
>> applicable beyond the use of CoAP and DTLS, which are the two main
>> protocols the group will focus on for access to resources. In
>> particular, the ability to use the developed solution over HTTP and TLS
>> will be investigated. Note that the work is limited to CoAP and HTTP
>> with DTLS and TLS. Other application protocols with their related
>> transport protocols, and other protocols at other layers in the stack,
>> are out of scope."
>> 
>> When I first read ³other protocols Š are out of scope" I wondered if
>>this
>> multi-party protocol mentioned above is at all in scope. Maybe we could
>> reformulate to make this clear?
>> 
>> Assuming that the multi-party protocol is in scope, what is this
>>protocol
>> allowed to do? Only support with authorization information, or also
>> support client-server with authentication and/or key establishment?
>> 
>> If the latter is true, must the client-server anyway run DTLS? Or can
>>the
>> multi-party protocol in some aspect replace overlapping functionality in
>> DTLS (and thereby reduce its performance impact)?
>> 
>> 
>> Göran
>> 
>
>