Subject: [Ace] About secure relay of authentication and authroization messages

From: "Hedanping (Ana)" <[email-masked]>
Date: Tue, 12 Aug 2014 03:49:42 +0000

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

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 12 Aug 2014 08:20:36 +0000

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]
Subject: [Ace] About secure relay of authentication and authroization messages

Hi,

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.

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Wed, 13 Aug 2014 00:57:55 +0000

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]
Subject: RE: [Ace] About secure relay of authentication and authroization messages

Hi Danping

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,

Regards,
Danping

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 Aug 2014 03:24:10 +0200

On 13 Aug 2014, at 02:57, Hedanping (Ana) <[email-masked]> wrote:

>  C and RS, which are not directly connected

I’m confused by this:  They sure are, via IP.
(ACE is not about network access control, where you often have to run the authorization *before* sending IP packets.)
But maybe I’m misunderstanding your point.

Grüße, Carsten

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Wed, 13 Aug 2014 02:30:03 +0000

Hi Carsten,

I agree that C got the right to access the network, thereafter it has the IP to communicate. My concern is:
C and RS might not always be the neighbors of each other due to weak wireless signal or topology design (imagine a energy constrained WSN with ad-hoc feature), thus packets between them should be relayed by nodes (Relay Elements) along the path, which is determined by a certain routing protocol. Furthermore, the Relay Elements are likely to be constraint devices, thus the battery resource and packet buffer will be consumed due to relay packet for C. 

Regards,
Danping

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Wednesday, August 13, 2014 9:24 AM
To: Hedanping (Ana)
Cc: Kumar, Sandeep; [email-masked]
Subject: Re: [Ace] About secure relay of authentication and authroization messages

>  C and RS, which are not directly connected

I'm confused by this:  They sure are, via IP.
(ACE is not about network access control, where you often have to run the authorization *before* sending IP packets.) But maybe I'm misunderstanding your point.

Grüße, Carsten

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Wed, 13 Aug 2014 07:23:31 +0000

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]
Subject: RE: [Ace] About secure relay of authentication and authroization messages

Hi Sandeep,

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

Regards
Sandeep

Hi,

Regards,
Danping

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Fri, 15 Aug 2014 03:35:21 +0000

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

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,

Regards,
Danping

Hi Danping

Regards
Sandeep

Hi,

Regards,
Danping

---

From: Robert Cragie <[email-masked]>
Date: Fri, 15 Aug 2014 08:13:08 +0100

I agree with Sandeep's assessment also; the access from C to the first RE
should be modelled in a similar way as C to RS. This meta-modelling, i.e.
modelling an AA resource as a resource almost always comes up and can
result in a "death spiral" of dependency if not modelled carefully, e.g. an
ACL is a resource, which needs an ACL,  which is a resource, which needs an
ACL...

In a constrained environment, the access to the RE must be carefully
controlled and may contain static/implicit rules regarding access. The RE
is then considered a pass-through for a higher-layer access; this in itself
may be layered any number of times before end-to-end is achieved, which may
or may not imply IP connectivity end-to-end but as Carsten has pointed out,
that is the assumption for the specific problem statement.

An RE is thus a pass-through intermediary; whilst we have generally
postponed discussion on intermediaries, this layered approach could
potentially apply to both pass-through and proxy intermediaries.

Robert
On 15 Aug 2014 04:35, "Hedanping (Ana)" <[email-masked]> 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]
> <[email-masked]>]
> *Sent:* Wednesday, August 13, 2014 2:58 AM
> *To:* Kumar, Sandeep; [email-masked]
> *Subject:* RE: [Ace] About secure relay of authentication and
> authroization messages
>
>
>
> Hi Sandeep,
>
> 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]
> <[email-masked]>]
> *Sent:* Tuesday, August 12, 2014 4:21 PM
> *To:* Hedanping (Ana); [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] <[email-masked]>] *On
> Behalf Of *Hedanping (Ana)
> *Sent:* Tuesday, August 12, 2014 5:50 AM
> *To:* [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
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 15 Aug 2014 10:03:30 +0200

On 13 Aug 2014, at 04:30, Hedanping (Ana) <[email-masked]> wrote:

> C and RS might not always be the neighbors of each other due to weak wireless signal or topology design (imagine a energy constrained WSN with ad-hoc feature), thus packets between them should be relayed by nodes (Relay Elements) along the path, which is determined by a certain routing protocol.

Right, in the Internet, we call these relaying elements “routers", and the relaying “routing”.

I still don’t understand what application layer authorization has to do with it.

There also is a role for application layer proxies, but there is no point in using a proxy when you can simply route.

So I’m trying to understand the use case where one wouldn’t just route, and why.

Grüße, Carsten

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Fri, 15 Aug 2014 09:00:40 +0000

Hi Robert,

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Cragie
Sent: Friday, August 15, 2014 3:13 PM
To: Hedanping (Ana)
Cc: Kumar, Sandeep; [email-masked]
Subject: Re: [Ace] About secure relay of authentication and authroization messages

I agree with Sandeep's assessment also; the access from C to the first RE should be modelled in a similar way as C to RS. This meta-modelling, i.e. modelling an AA resource as a resource almost always comes up and can result in a "death spiral" of dependency if not modelled carefully, e.g. an ACL is a resource, which needs an ACL,  which is a resource, which needs an ACL...

In a constrained environment, the access to the RE must be carefully controlled and may contain static/implicit rules regarding access. The RE is then considered a pass-through for a higher-layer access; this in itself may be layered any number of times before end-to-end is achieved, which may or may not imply IP connectivity end-to-end but as Carsten has pointed out, that is the assumption for the specific problem statement.

[Danping] I totally agree that the access to RE should be carefully designed in constrained environment. AA_ace is designed for a higher level resource access/manipulation, the issue discussed here is to avoid RE unconditionally relaying the AA_ace. It seems that using an AA_ace to request relay for another AA_ace is a paradox, and a light-weight access control should be designed.

An RE is thus a pass-through intermediary; whilst we have generally postponed discussion on intermediaries, this layered approach could potentially apply to both pass-through and proxy intermediaries.

[Danping] OK, I am willing to contribute on this topic in the future.

Robert
On 15 Aug 2014 04:35, "Hedanping (Ana)" <[email-masked]<mailto:[email-masked]>> 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.

Regards,

Danping

From: Kumar, Sandeep [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 13, 2014 3:24 PM
To: Hedanping (Ana); [email-masked]<mailto:[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

Hi Sandeep,

Regards,
Danping

Hi Danping

Regards
Sandeep

Hi,

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

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Fri, 15 Aug 2014 09:08:21 +0000

Hi Carsten,
So I'm trying to understand the use case where one wouldn't just route, and why.

[Danping] The routers themselves may be energy constrained or the bandwidth of the network is constrained, which makes the network itself fragile under a DOS attack that might not target at the final RS...

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Friday, August 15, 2014 4:04 PM
To: Hedanping (Ana)
Cc: Kumar, Sandeep; [email-masked]
Subject: Re: [Ace] About secure relay of authentication and authroization messages

> C and RS might not always be the neighbors of each other due to weak wireless signal or topology design (imagine a energy constrained WSN with ad-hoc feature), thus packets between them should be r…

Right, in the Internet, we call these relaying elements "routers", and the relaying "routing".

I still don't understand what application layer authorization has to do with it.

So I'm trying to understand the use case where one wouldn't just route, and why.
[Danping] Because the router itself may be energy constrained or the bandwidth of the route is constrained that is fragile under DOS attack that might not target at the final RS...

Grüße, Carsten

---

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.
>
> 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]]
> 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]]
> *To:* Kumar, Sandeep; [email-masked] <mailto:[email-masked]>
> exchanged between the C and RS, which are not directly connected. To 
> solve DOS attack, I roughly have a solution in mind:
>
> 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]]
> *To:* Hedanping (Ana); [email-masked] <mailto:[email-masked]>
> 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)
> *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.
>
>
>

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Aug 2014 10:32:44 -0400

Hedanping (Ana) <[email-masked]> wrote:
    > [Danping] The routers themselves may be energy constrained or the
    > bandwidth of the network is constrained, which makes the network itself
    > fragile under a DOS attack that might not target at the final RS...

Out of scope.
If the network is so fragile, then nothing ACE does will help or hinder.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Robert Cragie <[email-masked]>
Date: Sun, 17 Aug 2014 18:52:36 +0100

Hi Danping,

Comments inline, bracketed by <RCC></RCC>.

Robert

On 15/08/2014 10:00 AM, Hedanping (Ana) wrote:
>
> Hi Robert,
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Robert Cragie
> *Sent:* Friday, August 15, 2014 3:13 PM
> *To:* Hedanping (Ana)
> *Cc:* Kumar, Sandeep; [email-masked]
> *Subject:* Re: [Ace] About secure relay of authentication and 
> authroization messages
>
> I agree with Sandeep's assessment also; the access from C to the first 
> RE should be modelled in a similar way as C to RS. This 
> meta-modelling, i.e. modelling an AA resource as a resource almost 
> always comes up and can result in a "death spiral" of dependency if 
> not modelled carefully, e.g. an ACL is a resource, which needs an ACL, 
> which is a resource, which needs an ACL...
>
> controlled and may contain static/implicit rules regarding access. The 
> RE is then considered a pass-through for a higher-layer access; this 
> in itself may be layered any number of times before end-to-end is 
> achieved, which may or may not imply IP connectivity end-to-end but as 
> Carsten has pointed out, that is the assumption for the specific 
> problem statement.
>
> [Danping] I totally agree that the access to RE should be carefully 
> designed in constrained environment. AA_ace is designed for a higher 
> level resource access/manipulation, the issue discussed here is to 
> avoid RE unconditionally relaying the AA_ace. It seems that using an 
> AA_ace to request relay for another AA_ace is a paradox, and a 
> light-weight access control should be designed.
>
<RCC>In the problem statement case, as Carsten points out, there is no 
relay as such and intermediaries are simply routers. Also, as has been 
pointed out, how end-to-end IP connectivity is achieved is out of scope 
wrt. the problem statement. My personal view is that if modelled 
correctly, the same model can be applied in the meta-cases as described 
earlier. However, I think initially we should focus on the problem 
statement.</RCC>

> On 15 Aug 2014 04:35, "Hedanping (Ana)" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Hi Sandeep,
>
<RCC>What typically happens in practice in the constrained case is 
basically a "lockdown", whereby perimeter nodes (i.e. those which could 
act as relay) silently discard any incoming packet which cannot be 
authenticated. Therefore, the network has to be "opened" to allow 
unauthenticated traffic (which is typically the case in an initial 
authentication handshake) to be relayed to the authenticator. This can 
be modelled in a similar way to the C-RS case, whereby the 
unauthenticated node is C, the RE is RS and the access policy is a 
simple rule which allows or denies traffic based on a boolean value. In 
this case, neither C (unauthenticated node) nor RS (RE) have credentials 
as such as the traffic is completely unauthenticated.</RCC>
> message and the message flow would be different.  What do you think?
<RCC>
The first AA message is likely to be completely unauthenticated so the 
concept of AM/AS seem to disappear in this case for this simple reason: 
The RE cannot make any access decisions based on the message coming from 
C (the unauthenticated node) at all, as no part of it can be trusted, 
nor can it ask an AS to make any decisions on its behalf, nor can any 
token have been set up a priori with an AS. Therefore access is, as 
described above, allowed or denied based on whether the network is open.

Once the unauthenticated node is authenticated and has network access, 
it no longer has a C-RS relationship with the RE. Subsequent 
authentication and authorization decisions will be made that are closer 
to the problem statement described in ACE.
</RCC>