Subject: Re: [Dtls-iot] [Ace] About secure relay of authentication and authroization messages

From: Rene Struik <[email-masked]>
Date: Fri, 15 Aug 2014 09:18:49 -0400

Dear colleagues:

FYI - You may wish to have a look at the discussion on the IETF DICE 
mailing list end of May (messages 240-253; May 27-30, 2014) related to 
this, see, e.g., 
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00241.html. 
This discussion was triggered by some questions I had re suggestions in 
the security considerations section of draft-kumar-dice-dtls-relay-01 
aimed at countering Denial of Service attacks.

Best regards, Rene

On 8/14/2014 11:35 PM, Hedanping (Ana) wrote:
>
> Hi Sandeep,
>
> According to your solution "The first RE in the path checks whether C 
> holds a valid certificate or a pre-shared relay key" which itself is 
> an authentication/authorization decision. Infact it sounds more like 
> an AA decision to first access the one-hop relay and then an AA 
> decision to access the RS.
>
> [Danping] Your understanding is right.  In unconstraint environment, 
> Relay Elements simply relay the packets to destination. And as we 
> know,  the REs are likely to be constraint devices in constraint 
> environment such as ad hoc WSNs, thus the battery resource and packet 
> buffer will be consumed due to relaying packet for C. In other words, 
> to request resources over a RS that is multiple hops away 
> intrinsically hints a request of the resource over REs along the hops. 
>  Therefore I believe the a light AA is desired for the first-hop relay 
> to protect itself and other REs along the route.
>
> Would it not be simple to consider the relay to be an RS which is 
> one-hop away and use the not-yet-designed ACE solution for the 
> first-hop too.
>
> [Danping] It would be better to design a mechanism which allows AM/AS 
> issuing a permission for C to access the first-hop RE, the permission 
> might be transmitted separately or piggybacked with the first AA 
> message between C and RS. The not-yet-designed ACE solution might be 
> used too, but it is unnecessary to exchange key to secure the relay 
> message and the message flow would be different.  What do you think?
>
> Regards,
>
> Danping
>
> *From:*Kumar, Sandeep [mailto:[email-masked]]
> *Sent:* Wednesday, August 13, 2014 3:24 PM
> *To:* Hedanping (Ana); [email-masked]
> *Subject:* RE: [Ace] About secure relay of authentication and 
> authroization messages
>
> HI Danping
>
> According to your solution "The first RE in the path checks whether C 
> holds a valid certificate or a pre-shared relay key" which itself is 
> an authentication/authorization decision. Infact it sounds more like 
> an AA decision to first access the one-hop relay and then an AA 
> decision to access the RS. Would it not be simple to consider the 
> relay to be an RS which is one-hop away and use the not-yet-designed 
> ACE solution for the first-hop too.
>
> Regards
>
> Sandeep
>
> *From:*Hedanping (Ana) [mailto:[email-masked]]
> *Sent:* Wednesday, August 13, 2014 2:58 AM
> *To:* Kumar, Sandeep; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [Ace] About secure relay of authentication and 
> authroization messages
>
> Hi Sandeep,
>
> Thanks for the information and also thank you for showing interest in 
> this issue.
>
> The assumption is that, during the AA procedure, there are AA messages 
> exchanged between the C and RS, which are not directly connected. To 
> solve DOS attack, I roughly have a solution in mind:
>
> A relay key/certificate is needed. There might exist more than one RE 
> along the path between C and RS. The first RE in the path checks 
> whether C holds a valid certificate or a pre-shared relay key. If 
> verified, the AA messages from C are relayed normally. Otherwise, the 
> AA messages from C are ignored.
>
> Regards,
>
> Danping
>
> *From:*Kumar, Sandeep [mailto:[email-masked]]
> *Sent:* Tuesday, August 12, 2014 4:21 PM
> *To:* Hedanping (Ana); [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [Ace] About secure relay of authentication and 
> authroization messages
>
> Hi Danping
>
> I think ACE is at a very early stage that it is better to first solve 
> the problem without the relay path. At a later stage, the relay path 
> can be added for scenarios that might need them and ofcourse DoS 
> protection will be an important issue to consider then. Do you have 
> any specific solutions to solve the problem? If the DoS protection 
> solution depends heavily on the AA data then imho it should be solved 
> in ACE.
>
> Regards
>
> Sandeep
>
> *From:*Ace [mailto:[email-masked]] *On Behalf Of *Hedanping (Ana)
> *Sent:* Tuesday, August 12, 2014 5:50 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [Ace] About secure relay of authentication and 
> authroization messages
>
> Hi,
>
> There is an issue that I am not sure whether it is suitable for a 
> draft: should we consider secure relay of the Authentication and 
> authorization (AA) messages to protect relay elements along the relay 
> path?
>
> DTLS relay and PANA relay have been proposed, however the relay 
> elements simply relays the AA messages to the server. To avoid DOS 
> attack, the they limit the frequency and maximum number of times to 
> relay the AA requests.
>
> In constraint environment, the relay elements might be energy 
> constrained devices. If a malicious client intends to exhaust the 
> relay elements' power by frequently sending AA requests with forged 
> IPs or IDs, is there any countermeasure to this issue? Do we need to 
> consider this issue in ACE WG?
>
> Regards,
>
> Danping
>
> ------------------------------------------------------------------------
>
> The information contained in this message may be confidential and 
> legally protected under applicable law. The message is intended solely 
> for the addressee(s). If you are not the intended recipient, you are 
> hereby notified that any use, forwarding, dissemination, or 
> reproduction of this message is strictly prohibited and may be 
> unlawful. If you are not the intended recipient, please contact the 
> sender by return e-mail and destroy all copies of the original message.
>
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363