Re: [Ace] Call for adoption for draft-somaraju-ace-multicast-02

[Göran Selander]

I’m in favour of adopting a profile of the ACE framework [1] providing the 
functionality outlined in this draft.

It was acknowledged in the latest ACE interim that this draft will be 
transformed into an ACE profile, but currently the mapping to ACE is not very 
clear:

- Many of the "Requirements on Profiles” (Appendix C of [1]) are not fulfilled, 
e.g. how is the "resource server" of the ACE framework mapped? Is it the KDC?
- Will the proposed ACE-DTLS profile [2] be used or will we have different 
methods for authorising DTLS in different profiles?

There has been a lot of discussion of this draft, whereas "non-controversial” 
profiles of ACE ([2], [3], [4]) has been disregarded in the process. If one 
profile is being adopted without consideration of other profiles it may lead to 
duplication of specification, or different mechanisms being defined doing the 
same thing.

Chairs: What is the plan for coordinating the functionality in the different 
ACE profiles being adopted?


Göran


[1]  https://tools.ietf.org/html/draft-ietf-ace-oauth-authz
[2] https://tools.ietf.org/html/draft-gerdes-ace-dtls-authorize
[3] https://tools.ietf.org/html/draft-seitz-ace-oscoap-profile
[4] https://tools.ietf.org/html/draft-sengul-kirby-ace-mqtt-tls-profile




From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Kepeng Li mailto:kepeng@alibaba-inc.com>>
Date: Thursday 23 February 2017 at 10:48
To: "Ace@ietf.org" mailto:Ace@ietf.org>>
Cc: Kathleen Moriarty 
mailto:kathleen.moriarty.i...@gmail.com>>, 
Hannes Tschofenig mailto:hannes.tschofe...@gmx.net>>
Subject: [Ace] Call for adoption for draft-somaraju-ace-multicast-02

Hello all,



This note begins a Call For Adoption for draft-somaraju-ace-multicast-02 [1] to 
be adopted as an ACE working group item, and added in the charter. The call 
ends on Mar 7, 2017.


Keep in mind that adoption of a document does not mean the document as-is is 
ready for publication. It is merely acceptance of the document as a starting 
point for what will be the final product of the ACE working group. The working 
group is free to make changes to the document according to the normal consensus 
process.



Please reply on this thread with expressions of support or opposition, 
preferably with comments, regarding accepting this as a work item.


Thanks,



Kind Regards

Kepeng (ACE co-chair)

[1] https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] edhoc section 4.3.2

[Göran Selander]

Hi Michael,

Please see the latest version of EDHOC:
https://ericssonresearch.github.io/EDHOC/

The draft has gone through a number of reviews and is in many ways
rewritten. We will submit a new version next week. Inline:

On 2017-02-24 03:08, "Michael Richardson"  wrote:

>
>It says:
>>4.3.2.  message_1 -> V
>>
>>   Party V processes the received message_1 as follows:
>>
>>   o  Party V SHALL verify that the nonce has not been received before.
>> If the verification fails, the message MUST be discarded.
>> Otherwise, Party V SHALL store a representation of the nonce
>> for future verifications.
>
>Please clarify "has not been received before". Ever? Or within some
>interval?  In IKE, we care about the nonces not being reused during the
>time
>that the node continues to use the same keypair at its end. (In DH,
>this means the same y value for g^y). But, you specify a fresh keypair
>each
>time.

Verification of nonces is now optional (e.g. section 4.2.3). Nonces are
not allowed to be reused but it is noted that replay of message_1 cannot
be detected unless unless previous nonces are stored (see security
considerations).


In issue 16 it was requested to allow multiple uses of ephemeral keys and
it was added in the security considerations. I think it makes sense to
mandate the verification of nonce uniqueness during reuse of ephemeral
keys and have reopened issue 16:


https://github.com/EricssonResearch/EDHOC/issues/16


>
>Can two nodes U1 and U2 both use the same nonce (by random chance!)
>Or must it be unique among all peers?
>
>Storing such nonces is impossible for a constrained node...
>Even a non-constained node V won't be able to store many nonces received,
>once you count adding indexes to search for the list efficiently.

Agree.

Göran








___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] edhoc section 4.3.2

[Michael Richardson]

It says:
>4.3.2.  message_1 -> V
>
>   Party V processes the received message_1 as follows:
>
>   o  Party V SHALL verify that the nonce has not been received before.
> If the verification fails, the message MUST be discarded.
> Otherwise, Party V SHALL store a representation of the nonce
> for future verifications.

Please clarify "has not been received before". Ever? Or within some
interval?  In IKE, we care about the nonces not being reused during the time
that the node continues to use the same keypair at its end. (In DH,
this means the same y value for g^y). But, you specify a fresh keypair each
time.

Can two nodes U1 and U2 both use the same nonce (by random chance!)
Or must it be unique among all peers?

Storing such nonces is impossible for a constrained node...
Even a non-constained node V won't be able to store many nonces received,
once you count adding indexes to search for the list efficiently.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Call for adoption for draft-somaraju-ace-multicast-02

[Kepeng Li]

Hello all,
 
This note begins a Call For Adoption for draft-somaraju-ace-multicast-02 [1]
to be adopted as an ACE working group item, and added in the charter. The
call ends on Mar 7, 2017.
 
Keep in mind that adoption of a document does not mean the document as-is is
ready for publication. It is merely acceptance of the document as a starting
point for what will be the final product of the ACE working group. The
working group is free to make changes to the document according to the
normal consensus process.
 
Please reply on this thread with expressions of support or opposition,
preferably with comments, regarding accepting this as a work item.
 
Thanks,
 
Kind Regards
Kepeng (ACE co-chair)
 

[1] https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace