Subject: [radext] Proposed new charter text

From: Stefan Winter <[email-masked]>
Date: Fri, 13 Mar 2015 11:13:10 +0100

Hello,

as you may recall, we discussed new charter text at IETF91, which was
unanimously accepted in the room.

We still need to verify consensus on the list, so below is the proposed
updated charter text. This mail starts a two week comment period on the
charter text. Please send your comments to the list until 2015-03-27
2400 UTC.

You'll notice that there is specific text for "data types", "CoA proxy"
and "Populating EAP identity" in the draft charter's Work Items. Judging
from the mailing list traffic and prior discussions at the last IETF
meeting, I believe there is consensus that the working group wants to
work on these problem. As soon as the charter is approved, I will issue
an adoption call for the individual drafts which go in that direction.

We should also adjust milestones (some items to be marked as Done, some
new target dates for the ongoing work). These are not formally part of
the charter update, but they fit nicely into this mail nontheless. For
the completion dates, some authors have indicated a very short timeframe
for completion, but I've set everything at least to "2 meetings ahead"
-> November 2015; simply because our working group has a certain track
record of always being slower than anticipated :-)

Here is the text, see the IETF91 slides for a rationale of the changed bits:

"The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol pending approval of the new work from the Area Director
and clarify its usage and definition.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restriction is imposed on extensions considered by the
RADEXT WG:
All documents produced MUST specify means of interoperation with legacy
RADIUS and, if possible, be backward compatible with existing  RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675,
5080, 5090, 5176 and 6158. Transport profiles should, if possible, be
compatible with RFC 3539.

The WG will review its existing RFCs’ document track categories and
where necessary or useful change document tracks, with minor changes in
the documents if needed. Any changes to document tracks require approval
by the responsible Area Director.

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- CoA proxying.  RFC 5176 permits proxying of CoA and Disconnect
messages, but makes no provisions for how that is done in a roaming
environment.  This work item will provide descriptions of how to use the
Operator-Name attribute in a roaming environment to proxy CoA packets.
It will also define a new attribute which defines an opaque NAS
identifier which can be used to uniquely identify a visited NAS, and
whose value will not be modified when proxying, as is done with
NAS-Identifier and NAS-IP-Address.

- Encoding Rules for EAP-Response/Identity packets over RADIUS. Neither
EAP (RFC3748) nor EAP over RADIUS (RFC3579) demand specific character
encoding and normalisation rules for EAP Identity responses. RADIUS
(RFC2865) requires User-Name attributes to be encoded in UTF-8. Where a
NAS is required to verbatimly copy an EAP-Identity into a User-Name,
invalid packets might be produced. This document will suggest
restrictions on EAP Identities so that transport over AAA becomes
correct under all circumstances (UTF-8) and deterministic (normalisation).

- Data Types. RFC 2865 defines a number of data types, but later
documents do not use those types in a consistent way.  This work item
will define data types, and update the IANA RADIUS Attribute Type
registry so that each attribute has a data type.  Where necessary, it
will correct issues with previous specifications.  This will be a
standards track document.

- Larger Packets. Support RADIUS packets greater than 4096-octets over
RADIUS transports with this capability.

- RADIUS Attributes for IP Port Configuration and Reporting. These
attributes are used by devices that implement IP port ranges to
configure and report TCP/UDP ports and ICMP identifiers, as well as
mapping behaviors. These attributes can be used in the context of
address sharing (e.g., NAT44 [RFC3022], Dual-Stack Lite AFTR [RFC6333],
CGN [RFC6888], NAT64 [RFC6146], Provider WLAN (e.g., [TR-146]), etc.).

Milestones

(mark RFC4282bis as Done [RFC Editor Queue now])
(mark RADIUS packet fragemntation as Done [in RFC Editor Queue now])
(mark Dynamic Discovery as Done [in IETF LC now])

Nov 2015 - Submit CoA Proxying as Standards Track RFC
Nov 2016 - Submit Populating EAP Identity as BCP RFC
Nov 2015 - Data Types as Informational RFC
Nov 2015 - Larger Packets for RADIUS over TCP as Experimental RFC
Mar 2016 - IP Port RADIUS Extensions as Standards Track RFC

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Peter Deacon <[email-masked]>
Date: Sun, 22 Mar 2015 12:35:39 -0700 (Pacific Daylight Time)

> NAS-Identifier and NAS-IP-Address.

Recommend following text:

- CoA proxying.  RFC 5176 permits proxying of CoA and Disconnect messages, 
but makes no provisions for how that is done in a roaming environment. 
This work item will provide descriptions of how to proxy Dynamic 
Authorization messages using realm based proxy.  It will also define a new 
attribute to assist the visited network in processing and forwarding 
Dynamic Authorization requests to appropriate NAS.

While I generally support approach and associated draft 
draft-dekok-radext-coa-proxy-00.txt have some concerns and would prefer to 
keep some prescriptive details out of the charter.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Sun, 22 Mar 2015 17:59:38 -0400

On Mar 22, 2015, at 3:35 PM, Peter Deacon <[email-masked]> wrote:
> While I generally support approach and associated draft draft-dekok-radext-coa-proxy-00.txt have some concerns and would prefer to keep some prescriptive details out of the charter.

  The only practical way to do CoA proxying is via Operator-Name.  Which is why it’s mentioned.  The use of an opaque NAS identifier was done at the specific request of the WG.  So I believe there is WG consensus for the approach taken.  The draft has been available for some time now.  The idea has been presented at meetings going back 3-4 years, IIRC.  The only discussion of this topic has been supportive of this approach taken here.

  What exactly is the benefit of making the charter more vague?  You have “some concerns”.   Well.. I would appreciate discussing those concerns openly, instead of changing the charter to address unspecified issues.

  Will the approach recommended here

a) not work?

b) not be applicable to some situations?

c) cause problems?

  As we’ve also seen, documents can be updated to reflect issues not known at the time the charter was written.  e.g. the extended attributes document was worked on for years, and then tossed and re-written from scratch.  I think any concerns you may have can be addressed in the document review, instead of via charter modifications.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Sun, 22 Mar 2015 17:44:10 -0700 (Pacific Daylight Time)

>> draft-dekok-radext-coa-proxy-00.txt have some concerns and would prefer 
>> to keep some prescriptive details out of the charter.

>  What exactly is the benefit of making the charter more vague?  You have 
> “some concerns”.  Well.. I would appreciate discussing those concerns 
> openly, instead of changing the charter to address unspecified issues.

My understanding this would be a new item rather than change to an 
existing WG work item currently on the charter.  Stefan solicited feedback 
and I gave it.  The CoA draft as written would certainly continue to fall 
under my proposed change.  I am aware of nothing lost by proposed text.

Concern regards intent of Operator-NAS-Identifier.

Dynamic authorization allows multiple sessions to be influenced with 
single requests.  Sufficient / required session identifying attributes 
varies between NASes and sometimes across access technologies within the 
same NAS.  There are no further constraints expressed in draft on both 
required / acceptable session identifying attributes and method of initial 
authentication proxy (realm based or other policy based)

So I'll throw the question back at you.. how the heck is this supposed to 
work?

Proxy of DM following initial realm based auth proxy:

Operator-Name
Operator-NAS-Identifier
Acct-Session-Id
NAS-IP

Proxy of DM following initial policy based auth proxy:

Operator-Name
Operator-NAS-Identifier
User-Name
NAS-IP

When the upstream proxy in a forwarding chain gets the request how is it 
supposed to know whether it is safe to pass up the chain without either 
keeping a lot of state or verifying some kind of secure stateless 
signature/token conveyed within Operator-NAS-Identifier?

Section 3.1 of the draft makes it clear Operator-NAS-Identifier is not 
just a fungible label for a generic state attribute with the "20 octets" 
language and associated removal of NAS-Identifying attributes.

I see two opportunities:

Get to working by constraining both means of authentication proxy and 
session identifying attributes.

Or you can get there by keeping state at which point the language of 
Operator-NAS-Identifier in my judgment is insufficient.  While it may 
well resolve any ambiguities as to "where" the request is going it does so 
while missing the larger problem.

> The idea has been presented at meetings going back 3-4 years, IIRC.
> The only discussion of this topic has been supportive of this approach 
> taken here.

As earlier I also support the general "idea".

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Sun, 22 Mar 2015 21:34:47 -0400

On Mar 22, 2015, at 8:44 PM, Peter Deacon <[email-masked]> wrote:
> My understanding this would be a new item rather than change to an existing WG work item currently on the charter. Stefan solicited feedback and I gave it.  The CoA draft as written would certainly continue to fall under my proposed change.  I am aware of nothing lost by proposed text.

  Deleting text is pretty much the dictionary definition of “losing something”.

> Dynamic authorization allows multiple sessions to be influenced with single requests.

  Maybe I’m misunderstanding something, but no.  A CoA or Disconnect-Request packet addresses *one* session with *one* request.  Nothing in RFC 5176 suggests otherwise.

>  Sufficient / required session identifying attributes varies between NASes and sometimes across access technologies within the same NAS.  There are no further constraints expressed in draft on both required / acceptable session identifying attributes and method of initial authentication proxy (realm based or other policy based)

  Because the draft doesn’t address session identification.  It just addresses proxying.  RFC 5176 addresses session identification.  Badly, IMHO, but that’s the WG consensus.  No one could agree on a solution, so it was left pretty much the same as RFC 3576.

  i.e. session identification is explicitly outside of the scope of this document.

> So I'll throw the question back at you.. how the heck is this supposed to work?

  The document explains it’s assumptions and operating model in great detail.  If you don’t understand it, ask a *specific* question about a part you don’t understand.  I see no reason to re-post the document here to answer your question.

> When the upstream proxy in a forwarding chain gets the request how is it supposed to know whether it is safe to pass up the chain without either keeping a lot of state or verifying some kind of secure stateless signature/token conveyed within Operator-NAS-Identifier?

  A proxy isn’t supposed to know if a packet is “safe” to proxy.  It just proxies the packet.  That’s how RADIUS works.

> Section 3.1 of the draft makes it clear Operator-NAS-Identifier is not just a fungible label for a generic state attribute with the "20 octets" language and associated removal of NAS-Identifying attributes.

  Exactly.  It’s NOT a “generic state attribute”.   It’s not intended to be one.   All of the text explains in excruciating detail what it is, what it means, and how it’s used.  I fail to see how there is any potential for confusion.

> I see two opportunities:
> 
> Get to working by constraining both means of authentication proxy and session identifying attributes.

  Any constraint on proxying is out of scope of this work item.  Any change to session identification attributes is out of scope of this work item.

> Or you can get there by keeping state at which point the language of Operator-NAS-Identifier in my judgment is insufficient.  While it may well resolve any ambiguities as to "where" the request is going it does so while missing the larger problem.

  I suggest writing a document which addresses that larger problem.  Don’t try to extend this work item.

>> The only discussion of this topic has been supportive of this approach taken here.
> 

  Which is nice.

  If you want to write a document which describes how proxies can maintain per-user session state, and filter proxied CoA packets based on that information… go right ahead.  But that subject is out of scope for this document.

  Your charter changes would allow this document to include text on session identification, which is probably why you’re suggesting them.  The time to fix session identification with CoA was with RFC 5176.  That ship has sailed, the subject is closed.

  Everything you’ve said convinces me that the proposed charter text should stay the same.  RFC 5176 allows CoA packets to be proxied, but doesn’t specify how that’s done.  This document specifies how CoA packets are proxied in a roaming environment.  That’s it, that’s all.

  The document doesn’t address session identification attributes.  It doesn’t address generic state attributes.  It doesn’t address how proxies maintain per-user session state.  It doesn’t address how proxies “filter” packets they receive.  It doesn’t address all kinds of topics.  That’s fine.  Other topics are for other documents.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Sun, 22 Mar 2015 21:14:36 -0700 (Pacific Daylight Time)

>  Maybe I’m misunderstanding something, but no.  A CoA or 
> Disconnect-Request packet addresses *one* session with *one* request. 
> Nothing in RFC 5176 suggests otherwise.

RFC5176 Section 2.3 explains atomicity requirements while CoA or DM 
requests match multiple sessions.

>>  Sufficient / required session identifying attributes varies between
>>  NASes and sometimes across access technologies within the same NAS.
>>  There are no further constraints expressed in draft on both required /
>>  acceptable session identifying attributes and method of initial

>  Because the draft doesn’t address session identification.  It just 
> addresses proxying.  RFC 5176 addresses session identification.  Badly, 
> IMHO, but that’s the WG consensus.  No one could agree on a solution, so 
> it was left pretty much the same as RFC 3576.

This an important reason why I believe state will be required in some 
cases to facilitate correlation in the event insufficient information is 
available to do so.

I believe the mechanism to support can be fully opaque like 
Operator-NAS-Identifier and fully implementation dependant I advocate only 
enabling communication channel exist.

I believe Operator-NAS-Identifier's constraints make it insufficient for 
this role otherwise it would be sufficient.  Section 3.1 20 octets 
language is insufficient and automatic removal of NAS identifying 
attributes may be counterproductive.

I do not advocate for fixing Dynamic authorization or session identifying 
attributes.  I do not advocate for fixing Proxy.  In previous remarks 
possible courses of action were enumerated to assist in demonstrating why 
state is needed by implementations.

With regards to CoA draft I would support either a separate State 
attribute or loosening constraints of Operator-NAS-Identifier.

Regardless of concerns specific to CoA draft appreciate any consideration 
of my recommendation.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 23 Mar 2015 07:23:38 -0400

On Mar 23, 2015, at 12:14 AM, Peter Deacon <[email-masked]> wrote:
> RFC5176 Section 2.3 explains atomicity requirements while CoA or DM requests match multiple sessions.

  OK… I hadn’t noticed that before.  It still doesn’t change my opinion of the charter changes, though,

> This an important reason why I believe state will be required in some cases to facilitate correlation in the event insufficient information is available to do so.

  Correlation of what?  I find that sentence so vague that I don’t know what it means.

  The draft implements CoA proxying based on Operator-Name.  This is sufficient for all proxies to get the packet to the visited domain, independent of anything else in the packet.  The Operator-Name *is* “sufficient information” for all proxies.  The proxies need no other information, and can safely ignore every single other attribute in the packet.

  The draft allows for the visited network to get the packet to the NAS based on Operator-NAS-Identifier.  This is sufficient for the visited network to get the packet to the correct NAS, independent of anything else in the packet.  The Operator-NAS-Identifier is “sufficient information” for the visited network.  It needs no other information, and can safely ignore every single other attribute in the packet.

  The rest of the information in the packet is interpreted by the NAS.

> I believe the mechanism to support can be fully opaque like Operator-NAS-Identifier and fully implementation dependant I advocate only enabling communication channel exist.

  To support… what?  You’re making some kind of assumption, and not explaining it here.

> I believe Operator-NAS-Identifier's constraints make it insufficient for this role otherwise it would be sufficient.  Section 3.1 20 octets language is insufficient and automatic removal of NAS identifying attributes may be counterproductive.

  Why?

> I do not advocate for fixing Dynamic authorization or session identifying attributes.  I do not advocate for fixing Proxy.  In previous remarks possible courses of action were enumerated to assist in demonstrating why state is needed by implementations.

  I read those remarks.  I still have no idea why you think state is needed.

> With regards to CoA draft I would support either a separate State attribute or loosening constraints of Operator-NAS-Identifier.

  A separate State attribute to do… what?

> Regardless of concerns specific to CoA draft appreciate any consideration of my recommendation.

  I have no idea what you’re recommending.  Please explain.  Your remarks are cryptic and unhelpful.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 23 Mar 2015 11:14:30 -0700 (Pacific Daylight Time)

On Mon, 23 Mar 2015, Alan DeKok wrote:

To clear up any confusion I will go back and expand on my previous 
question.

Roaming network consisting of a number of participating organizations all 
sharing access.

'Home' system, roaming network (RoamA,B,C) and 'Visit' systems all 
controlled by separate companies.  Each use different RADIUS systems.

The word STATE refers to Operator-NAS-Identifier or something like it.

+------+    +-------+   +-------+   +-------+   +-------+   +----------+
| Home | -  | RoamA | - | RoamB | - | RoamC | - | Visit | - | VisitNAS |
+------+    +-------+   +-------+   +-------+   +-------+   +----------+

Scenario A:

'Home' user logs on to 'VisitNAS' as user@home using realm proxy, 
Access-Request proxied to home server and user admitted to the network.

At a later time home server decides to send a DM request to disconnect 
user@home.  It transmits a request to RoamA containing roughly:

Operator-Name="1visit"
Operator-NAS-Identifier=010100100101010
Acct-Session-Id="dontchawishwewerealwaysunique"
NAS-Port-Id="Astern123"
NAS-IP-Address=10.1.1.1

This request does NOT contain User-Name.

Issues:

- 'RoamA' can either use STATE included in the request to verify 
Acct-Session-Id is related to a session belonging to 'Home' before it 
enters the roaming network or it can simply punt responsibility up thru 
the proxy chain.

- If 'RoamA' decides to punt to 'RoamB' or 'RoamC' the same problem of 
using STATE to verify Acct-Session-Id is related is encountered. Also 
since there is no standard way of communicating 'Home' originated the 
request roaming network will need to manage some OOB or proprietary method 
of facilitating origination information so that it can render a coherent 
judgment.

- If RoamA-C all fail to verify Acct-Session-Id the request responsibility 
is punted to 'Visit'

- If 'Visit' trusts the roaming network and STATE is never used to verify 
relationship of DM to 'Home' the effective outcome any 'Home' network is 
able to disconnect any of their competitors users with only knowledge of 
session identifying attributes.

- If 'Visit' is more cautious and can get trusted originating 'Home' 
information from 'Roam' and STATE this could be used to verify the 
relationship itself.

Scenario B:

'Home' user logs on to 'VisitNAS' as user using policy based proxy on a 
VSA.  Access-Request proxied to home server and user admitted to the 
network.

At a later time home server decides to send a DM request to disconnect 
user.  It transmits a request to RoamA containing roughly:

Operator-Name="1visit"
Operator-NAS-Identifier=010100100101010
User-Name="user"
Acct-Session-Id="dontchawishwewerealwaysunique"
NAS-Port-Id="Astern123"
NAS-IP-Address=10.1.1.1

This request does NOT contain VSA used for policy based proxy.

Issues are identical to scenario A.

STATE is helpful in addressing situations where there is a mismatch 
between session identification and means of proxy.

>  The draft implements CoA proxying based on Operator-Name.  This is 
> sufficient for all proxies to get the packet to the visited domain, 
> independent of anything else in the packet.  The Operator-Name *is* 
> “sufficient information” for all proxies.  The proxies need no other 
> information, and can safely ignore every single other attribute in the 
> packet.

No unfortunately this does not work across administrative domains as 
operators are able to affect operation of unrelated sessions belonging to 
other operators without the checks in place.  While all parties explicitly 
trust roaming infrastructure they may not necessarily trust each other.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 23 Mar 2015 17:38:52 -0500

On Mar 23, 2015, at 1:14 PM, Peter Deacon <[email-masked]> wrote:
> To clear up any confusion I will go back and expand on my previous question.

  That helps a lot, thanks.

> - 'RoamA' can either use STATE included in the request to verify Acct-Session-Id is related to a session belonging to 'Home' before it enters the roaming network or it can simply punt responsibility up thru the proxy chain.

  The RADIUS answer is that RoamA simply proxies the request.  It does no verification or filtering of proxied packets.

> - If 'RoamA' decides to punt to 'RoamB' or 'RoamC' the same problem of using STATE to verify Acct-Session-Id is related is encountered. Also since there is no standard way of communicating 'Home' originated the request roaming network will need to manage some OOB or proprietary method of facilitating origination information so that it can render a coherent judgment.

  Yes.  Exactly.  The proxies just proxy the packets.  Nothing more

> - If RoamA-C all fail to verify Acct-Session-Id the request responsibility is punted to ‘Visit'

  Yes.  Exactly.

> - If 'Visit' trusts the roaming network and STATE is never used to verify relationship of DM to 'Home' the effective outcome any 'Home' network is able to disconnect any of their competitors users with only knowledge of session identifying attributes.

  Unfortunately, yes.  That’s an issue with 5176.  And with this document.  I don’t think fixing roaming is in scope for it.

  The recommended way to address this issue is to use Acct-Session-Id, and User-Name in the CoA packets.  That information is “private”, and random home servers can’t guess it.  Proxies can still watch the traffic and forge disconnects… but they’re trusted.  That’s the nature of the trust relationship they have with the other parties.

> - If 'Visit' is more cautious and can get trusted originating 'Home' information from 'Roam' and STATE this could be used to verify the relationship itself.

  There is little or nothing to be gained by having the proxies (or visited network) maintain any kind of session state.  Doing so would be costly, and would only make it more difficult for malicious home servers to disconnect their competitors users.  All of the proxies could still disconnect any users, because they’re proxies, and have all of the state information.

> Scenario B:
> 
> 'Home' user logs on to 'VisitNAS' as user using policy based proxy on a VSA.  Access-Request proxied to home server and user admitted to the network.
> 
> At a later time home server decides to send a DM request to disconnect user.  It transmits a request to RoamA containing roughly:
> 
> Operator-Name="1visit"

  It doesn’t need to.  It contains the Operator-Name, which is sufficient for the CoA packets to be proxied to the visited network.

> Issues are identical to scenario A.

  Yes.

> STATE is helpful in addressing situations where there is a mismatch between session identification and means of proxy.

  I’m not sure I agree.

> No unfortunately this does not work across administrative domains as operators are able to affect operation of unrelated sessions belonging to other operators without the checks in place.  While all parties explicitly trust roaming infrastructure they may not necessarily trust each other.

  i.e. what you’re saying is that there is a requirement for home server A to NOT be allowed to disconnect users for home server B in a visited network.  That is a *new* requirement, which doesn’t negate my comments above.

  I want to solve one problem at a time.  Operator-Name and Operator-NAS-Identifier are sufficient to get the packet to the visited NAS.   Your earlier comments seemed to say that they were NOT sufficient, which is what was unclear.

  To solve the NEW problem of forged disconnects, we need a NEW solution.  i.e. rely on Acct-Session-Id, which is hard to guess.  I think that would be sufficient for most intents and purposes.

  If you have *specific* suggestions for a solution, I’d be happy to hear them.  But please explain it clearly.  Most of the time your posts are full of unstated assumptions, which makes it nearly impossible to understand them.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 23 Mar 2015 16:03:42 -0700 (Pacific Daylight Time)

On Mon, 23 Mar 2015, Alan DeKok wrote:

>> operators are able to affect operation of unrelated sessions belonging 
>> to other operators without the checks in place.  While all parties 
>> explicitly trust roaming infrastructure they may not necessarily trust 
>> each other.

>  i.e. what you’re saying is that there is a requirement for home server 
> A to NOT be allowed to disconnect users for home server B in a visited 
> network.  That is a *new* requirement, which doesn’t negate my comments 
> above.

I recommend effective means of isolation of administrative domains be 
explicitly required as part of any charter for this work item.

Even if many of details are left up to implementations there has to be a 
reasonable enabling means.  Without it I don't support the work item as 
resulting product would not be suitable for deployment.

regards,
Peter

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Mar 2015 19:21:17 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   i.e. what you’re saying is that there is a requirement for
    Alan> home server A to NOT be allowed to disconnect users for home
    Alan> server B in a visited network.  That is a *new* requirement,
    Alan> which doesn’t negate my comments above.

    Alan>   I want to solve one problem at a time.  Operator-Name and
    Alan> Operator-NAS-Identifier are sufficient to get the packet to
    Alan> the visited NAS.  Your earlier comments seemed to say that
    Alan> they were NOT sufficient, which is what was unclear.

I think solving this requirement would be necessary for moving COA to
the standards track or removing the health warning in 5176.

I'm fine not solving that problem provided that we have a fairly serious
health warning on this draft.
For this and other reasons COA massively fails to meet our current
security expectations for standards track.

--Sam

---

From: Stefan Winter <[email-masked]>
Date: Tue, 24 Mar 2015 08:20:47 +0100

Hello,

thanks Alan, Peter and Sam for taking the discussion to this point. You
have collectively revealed the issue that was causing the confusion; and
it leads to a need to tweak the charter IMHO:

Either the document needs to consider safeguards against "generous
disconnects" in other domains - I understand from the discussion that
this is a very hard problem - or the document can't be standards track
and needs a big warning that such generous disconnects are a security
problem in this draft.
I understand that this problem has always been there; it's not new in
this draft but a problem of RFC5176 itself - it is only exacerbated now
because proxying was previously totally undefined (making sending malign
DM/CoA packets a private workflow and hard) and now becomes mostly
defined and thus more easily exploitable.

The latter solution, off of standards track, is easier: the target track
and milestone info for the document could be changed towards
Informational (matching RFC5176 itself) and the WG would during the
normal WG workflow suggest appropriate warning text for the draft.

I like that way out, if everyone else can live with it. I'd appreciate
comments from the working group on that topic, particularly from the
three of you of course :-)

Greetings,

Stefan Winter

On 24.03.2015 00:21, Sam Hartman wrote:
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
> 

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Mar 2015 06:47:15 -0500

On Mar 23, 2015, at 6:03 PM, Peter Deacon <[email-masked]> wrote:
> I recommend effective means of isolation of administrative domains be explicitly required as part of any charter for this work item.

  I don’t see a need for the charter to be updated.  Security is always a factor in every work item.  It doesn’t need to be explicitly called out.

> Even if many of details are left up to implementations there has to be a reasonable enabling means.  Without it I don't support the work item as resulting product would not be suitable for deployment.

  You’re assuming that without the charter update, everyone will ignore the problem.  I don’t think that’s realistic.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Mar 2015 06:59:16 -0500

> the standards track or removing the health warning in 5176.

  I agree.

  Let’s say that each proxy selectively forwards CoA packets based on it’s knowledge of the user sessions.  This means that every proxy has to maintain information on every user session, which is untenable.

  Or maybe the sessions contain some kind of state that the proxy can cryptographically verify.  That means sharing the cryptographic keys with all proxies, which is also untenable.

  In the end, I don’t see this as a session state problem.  It’s a routing problem.  For a situation Visited -> Proxy -> Home, packets are usually forwarded based on User-Name, and realm.  When the Home server wants to disconnect a user, it typically sends User-Name as part of the session identification attributes.  So all that’s needed is for the proxy to look up that realm.

  i.e. the algorithm is this:

forwarding proxy: receive packet with User-Name, look up realm, and forward packet to that realm.

CoA proxy: receive packet with Operator-Name and User-Name.  Look up realm from *User-Name*.  If the source of the packet does not match a known destination for that realm, then drop the packet as being non-compliant.  Otherwise, look up realm from *Operator-Name*, and forward the CoA packet there.

  This solution does have limitations.  It requires that the forwarding path contain information about CoA clients.  It requires that proxying is done on User-Name.

  However, I think that those restrictions are reasonable.  All of the cross-organization roaming I’m aware of is done via User-Name, so this solution imposes no operational changes on current systems.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Mar 2015 10:28:09 -0400

Ah, I didn't catch that the COA proxy document was labeled standards
track.  That's not OK unless we're moving 5176, which I don't support
absent some serious changes.

So, yes I support same status as 5176.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Mar 2015 10:59:43 -0400

Alan> On Mar 23, 2015, at 6:21 PM, Sam Hartman <[email-masked]> wrote:
    >> I think solving this requirement would be necessary for moving
    >> COA to the standards track or removing the health warning in
    >> 5176.

    Alan>   I agree.

    Alan>   Let’s say that each proxy selectively forwards CoA packets
    Alan> based on it’s knowledge of the user sessions.  This means that
    Alan> every proxy has to maintain information on every user session,
    Alan> which is untenable.

I actually can think of ways of approaching this.
This scaling problem seems no worse than some scaling problems websites
face and some of the solutions there seem applicable.
However, this seems like the wrong approach to me, because it is more
complex than needed.

    Alan>   Or maybe the sessions contain some kind of state that the
    Alan> proxy can cryptographically verify.  That means sharing the
    Alan> cryptographic keys with all proxies, which is also untenable.

It's much less obvious to me that this is untenible.
We definitely have key distribution mechanisms that seem up to the task.
This is especially true in deployments where the original access request
travels through  the same operators as  the COA packet travels in
reverse.
In that case, operators can add/transform their own state, and need only
manage keys within  their own domain.

    Alan>   In the end, I don’t see this as a session state problem.
    Alan> It’s a routing problem.  For a situation Visited -> Proxy ->
    Alan> Home, packets are usually forwarded based on User-Name, and
    Alan> realm.  When the Home server wants to disconnect a user, it
    Alan> typically sends User-Name as part of the session
    Alan> identification attributes.  So all that’s needed is for the
    Alan> proxy to look up that realm.

    Alan>   i.e. the algorithm is this:

    Alan> forwarding proxy: receive packet with User-Name, look up
    Alan> realm, and forward packet to that realm.

    Alan> CoA proxy: receive packet with Operator-Name and User-Name.
    Alan> Look up realm from *User-Name*.  If the source of the packet
    Alan> does not match a known destination for that realm, then drop
    Alan> the packet as being non-compliant.  Otherwise, look up realm
    Alan> from *Operator-Name*, and forward the CoA packet there.

This seems fairly weak to me.

I'd be much more comfortable with a solution that took routing and
session state into account.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Mar 2015 05:42:07 -1000

To back up a bit, most of the forgery problem can be avoided by noting that the Operator-NAS-Identifier is itself a unique key.  If the visited realm creates many values for the attribute, then guessing correct values is hard, and forgery is trivially detectable.

  i.e. if each user session has a different Operator-NAS-Identifier, then a home server can forge a CoA packet, but it will get detected by the visited realm as a forgery.  The proxies need to do nothing.

  The visited realm could simply track user sessions in a database (as they mostly do now), and create unique Operator-NAS-Identifiers for each user.  When receiving a CoA request, look up the identifier in a DB, and get the IP of the NAS from there.  Or, the visited realm could be stateless, and encrypt the real NAS IP address with a combination of a secret local key, and the destination realm.  This makes a unique (and secret) identifier for each realm, and for each NAS in the visited realm.

  Remember, all of these packets are sent within a trusted network.  The systems aren’t open to the wider internet, and there isn’t a requirement to protect against DoS attacks from every single IP on the planet.

  I view the forgery problem as something which is best dealt with by non-technical means.  *Detecting* forgery is a technical requirement.  But *preventing* forgery isn’t necessarily a requirement.

  i.e. it’s OK for the visited realm to detect a forged request, ignore it, and escalate the problem to an administrator.  The intermediate proxies don’t need to detect or prevent the forgery.  That’s a hard problem to solve.

On Mar 24, 2015, at 4:59 AM, Sam Hartman <[email-masked]> wrote:
re: crypto keys

> manage keys within  their own domain.

  If we do want the proxies to get involved, we could use per-proxy encryption keys.

  Each proxy has it’s own secret key, K_p.  The proxy uses the key to encrypt the Operator-NAS-Identifier when proxying auth / acct packets to a home server.  It uses the same key to decrypt the Operator-NAS-Identifier when proxying CoA / Disconnect packets to the visited realm.  Forged packets from home servers get decrypted to nonsense, and the visited realm will reject the CoA packet.

  The reason this works is that no one but the visited realm can interpret Operator-NAS-Identifier.  Therefore, it’s safe to transform the value in a “conservative” or reversible way.

re: User-Name verification.
> This seems fairly weak to me.

  It’s not perfect, but it’s not wrong.  It’s a good idea to do, in any case.

  I agree.

  In the end, I think the solutions to this are pretty simple.  CoA proxies can protect themselves by doing reverse realm lookups on User-Name.  Visited realms can prevent forgery by using unique Operator-NAS-Identifiers within a large space.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Mar 2015 11:44:04 -0400

What you say here makes sense too.
>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   To back up a bit, most of the forgery problem can be avoided
    Alan> by noting that the Operator-NAS-Identifier is itself a unique
    Alan> key.  If the visited realm creates many values for the
    Alan> attribute, then guessing correct values is hard, and forgery
    Alan> is trivially detectable.

    Alan>   i.e. if each user session has a different
    Alan> Operator-NAS-Identifier, then a home server can forge a CoA
    Alan> packet, but it will get detected by the visited realm as a
    Alan> forgery.  The proxies need to do nothing.

    Alan>   The visited realm could simply track user sessions in a
    Alan> database (as they mostly do now), and create unique
    Alan> Operator-NAS-Identifiers for each user.  When receiving a CoA
    Alan> request, look up the identifier in a DB, and get the IP of the
    Alan> NAS from there.  Or, the visited realm could be stateless, and
    Alan> encrypt the real NAS IP address with a combination of a secret
    Alan> local key, and the destination realm.  This makes a unique
    Alan> (and secret) identifier for each realm, and for each NAS in
    Alan> the visited realm.

---

From: Peter Deacon <[email-masked]>
Date: Tue, 24 Mar 2015 09:33:47 -0700 (Pacific Daylight Time)

My best estimation of how this would work was simply to specify a generic 
state attribute.. Dynamic-Proxy-State and call it a day.

Any administrative domain (RoamA-C or Visit) requiring verification 
injects Dynamic-Proxy-State into Access-Request.

Dynamic Auth Clients are required to forward this information when issuing 
DM/CoA requests.

Any admin domain in the path requiring verification then checks 
Dynamic-Proxy-State.. ideally at the border (RoamA) where the identity of 
sender is well established but intra-domain implementations can coordinate 
however they want.  If attribute is missing but required and triplet of 
proxy state, identity and session identifiers of request do not add up the 
request is rejected.

It would have the following general properties:

- Injectable by anyone in proxy path via Access-Request .. "0+"
-- Ideally once per admin domain implying some form of implementation 
dependant Intra-domain coordination.

- DACs must transmit ALL Dynamic-Proxy-State atttributes from access 
request.
- Recommendations to keep size and number of Dynamic-Proxy-State 
attributes as low as possible but specify no cutoff or required minimum.

This is basically it.. implementations can do whatever they want to 
implement it... They can keep a state table or stuff the attribute with 
source, session identifying hints, cryptographic signatures and not have 
to keep much of any state at all.

It should provide general advice on design options, tradeoffs, 
recommendations and perils of which I'm sure we call all dream up plenty.

I prefer a solution that does not depend on keeping secrets.. Even if 
competitors sniffed out Dynamic-Proxy-State from my wires and know all of 
the session identifiers for my customers it would be preferable if 
re-injecting this information (often sent in the clear right now): not 
yield fruit.

regards,
Peter