Subject: Re: [radext] Extended IDs

From: Alan DeKok <[email-masked]>
Date: Fri, 1 Dec 2017 09:23:04 -0500

On Nov 30, 2017, at 9:02 PM, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 
> I generally don't like overloading a field with different semantics,

  I do agree it's weird.. but it *is* the minimal possible change to the protocol.

> because if one of the semantics needs to change in the future, the dependency
> on the other semantic will complicate the change.

  I'm not sure what that means... we are absolutely *not* going to change the meaning of the Request Authenticator field.  Doing so would mean RADIUS would be changed into something else entirely.

> For that reason, I prefer draft-chen-radext-identifier-attr-02.
> I do like some of the detailed discussion of the issues in
> draft-dekok-radext-request-authenticator-02.
> I think the final document should include some of these discussions.

  One large point for me is the subject of "conflicting packets".  i.e. what does a RADIUS server do when it's currently processing one packet, and it receives another one with the same src/dst ip/port, code, and ID?

  All of the specs are silent on this topic, despite implementations having to handle such a corner case.  So far as I can tell, all implementations have chosen a similar solution.  Even RFC 5080 ignores this topic... despite FreeRADIUS (among others) have explicit code to handle this situation.

  It was thinking about these "conflicting packets" that led me to my draft.  What if they *weren't* discarded / rejected, and instead the server could process them? 

  The conclusion was not only that it was possible, but that it wasn't much work, and wasn't a large change to the RADIUS protocol.  It just requirements agreement between the client and server to just behave differently.

  In contrast, adding an extended ID as an attribute to every packet is arguably changing the RADIUS header... while pretending we're not changing the RADIUS header.  We've avoided that for 20+ years because it's a slippery slope to just changing all of RADIUS...

  Alan DeKok.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 1 Dec 2017 16:15:49 +0000

What if the quantum computers turn out to live up to their promises? Then we can throw out all this authentication stuff and decide to not share our Ethernets with the attackers instead. No more request authenticator.

The request authenticator is already overloaded. It may be used for the CHAP challenge. Now, you want another overload?

The request authenticator is not reflected back in any return packets. The response authenticator is a different number. Suppose the client has several requests outstanding with the same id. When it receives a response, it has to hash it with every request authenticator from these outstanding requests to figure out which one the response is for. This looks like a lot of unnecessary hard work.

Conflicting requests: if the server receives a request identical to one it received before and has a cached response, then retransmit the cache, else process it again. How to determine “identical request” is a local matter. Comparing ID alone is clearly not enough. Comparing anything less than the whole request packet risks misidentified duplicates. If the short cut misleads, then don’t take the short cut.

Thanks,
Jakob.

On Dec 1, 2017, at 6:23 AM, Alan DeKok <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 30, 2017, at 9:02 PM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:

 Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 1 Dec 2017 11:39:54 -0500

> What if the quantum computers turn out to live up to their promises? Then we can throw out all this authentication stuff and decide to not share our Ethernets with the attackers instead. No more re…

  I'm sorry, but that just isn't realistic.

  If quantum computers can crack encryption, then RADIUS security will be the least of our issues.

> The request authenticator is already overloaded. It may be used for the CHAP challenge. Now, you want another overload?

  I'd like to use an existing field, yes.

  The draft explains why this works.  In detail.

> The request authenticator is not reflected back in any return packets. The response authenticator is a different number. Suppose the client has several requests outstanding with the same id. When it receives a response, it has to hash it with every request authenticator from these outstanding requests to figure out which one the response is for.

  Please don't claim there are problems with the draft until you read it.

  The draft EXPLICITLY STATES that the request authenticator is echoed back in a new attribute.  It has many, many, pages to discuss all possible issues with that practice.

> Conflicting requests: if the server receives a request identical to one it received before and has a cached response, then retransmit the cache, else process it again. How to determine “identical request” is a local matter.

  Those are duplicate requests.  They were defined 10 years ago in RFC 5080, Section 2.2.2, including how to determine what a "duplicate request" is.

 https://tools.ietf.org/html/rfc5080#section-2.2.2

  RFC 5080 also defines what RADIUS servers should do with these requests.  My comment was about *conflicts*.

  i.e. a RADIUS server receives an Access-Request from a client (src/dst, IP/port, ID 0, request authenticator A).  While the server is processing that packet, the client (for whatever reason) sends a *different* packet with the same src/dst IP/port.  ID 0, but a *different* request authenticator.

  Should be server respond to the first packet?  Or should the server respond to the second packet?  Or should it respond to both?

  Again... this issue is discussed in detail in my draft.

> Comparing ID alone is clearly not enough. Comparing anything less than the whole request packet risks misidentified duplicates.

  That simply isn't true.

  Again, please read the draft.  This is discussed in excruciating detail.  Including the possibility of false positives, false negatives, etc.

> If the short cut misleads, then don’t take the short cut.

  I think the only short cut here is the decision to skip reading the draft before commenting on it.

  Alan DeKok.

---

From: Astrid Smith <[email-masked]>
Date: Tue, 28 Nov 2017 12:18:53 -0800

Hello,

I prefer the option laid out in
draft-dekok-radext-request-authenticator-02, due to deficiencies in
the other proposal (draft-chen-radext-identifier-attr-02).

I'm concerned about the extended Code field it defines: How should
implementations treat messages where this Code differs from the Code
in the RADIUS header?  The precedence is poorly defined and liable to
cause issues.

The proposal also requires all proxies to explicitly support (by
parsing and passing through, or by stripping) the Identifier
Attribute; this requires protocol users to upgrade and test all the
software in their RADIUS deployment before any clients may safely
attempt to use the attribute.

It feels half-baked.

The request-authenticator proposal appears safe to deploy without
upgrading the software of any proxies in the network.  As a maintainer
of a RADIUS proxy I prefer this, and I suspect my customers would
agree :)

-- 
astrid smith     -------------------
--<[ c y b e r  |  s o f t w a r e  |  e n g i n e e r ]>--
    ------------                     ------------------

On Tue, Nov 28, 2017 at 02:54:32PM +0100, Stefan Winter wrote:
> Hello,
> 
> > thanks all for raising the awareness of these two drafts.
> >
> >
> > I think it would be good if all remaining readers of this list who care
> > enough now take some time to read both drafts and make up their mind on
> > what the preferred approach is.
> >
> >
> > In approx. two weeks' time I will start a call for adoption on both
> > drafts, and hopefully there are enough responses to make the exercise
> > meaningful. If so, the one with more votes wins.
> 
> Now that was a relaxed "two weeks" delay. My apologies, I've been on and
> off work for a while, with substantial backlogs.
> 
> This email starts a two week call for adoption of at most one of the
> following two drafts:
> 
> * draft-chen-radext-identifier-attr-02
> * draft-dekok-radext-request-authenticator-02
> 
> Since the two drafts treat the same topic, at most one can be selected
> to serve as the basis for future work.
> 
> In your reply to this call for adoption, please indicate which of the
> two drafts you think should be adopted. You can of course also indicate
> that none of the two are fit for purpose. The only thing you really
> shouldn't do is to vote for both; that wouldn't help the discussion move on.
> 
> Please reply by 12 dec 2017 2400 UTC.
> 
> Greetings,
> 
> Stefan Winter

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 1 Dec 2017 22:06:16 +0000

Hi Astrid,

When you say draft-chin-radext-identifier-attr requires all proxies to
explicitly support this and test all the software; what do you think of
draft-dekok-radext-request-authticator would do to the proxy servers?
the connection is hop by hop, each hop has to support the new
mechanism in order to have nas-proxy-home_server working
with the extended-id in all the mechanisms. Just because the
draft-dekok-radext-request-authticator does not explain how to
do that, does not mean it can have the original software working
unchanged:-) We are talking about the feeling of half-baked;-)

Cheers,
- Naiming

> On Nov 28, 2017, at 12:18 PM, Astrid Smith <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Fri, 1 Dec 2017 17:16:36 -0500

> in the RADIUS header?  The precedence is poorly defined and liable to

  That is a concern.  What happens if the same Extended ID is used in two different packets from the same src/dst IP/port + Code + ID?

> attempt to use the attribute.

  There are provisions for negotiation in both drafts.

> of a RADIUS proxy I prefer this, and I suspect my customers would

  The one benefit of the request authenticator draft is that even in the case of misconfiguration, it's *impossible* for the extended IDs to leak across a proxy boundary.

  draft-chen, on the other hand, would have the extended ID leaked across old-style proxies if the client was statically misconfigured.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Sun, 3 Dec 2017 00:22:35 -0800 (Pacific Standard Time)

> that none of the two are fit for purpose. The only thing you really

While both approaches achieve the same thing using similar means and 
similar properties of the two draft-dekok-radext-request-authenticator-02 
is my preference.  Details below for those interested.

----
draft-chen-radext-identifier-attr-02

While I have some minor concerns:

- structure of attribute
Please make it a normal integer?

- ordering requirement
Only one specification can ever demand its attribute be "first". You have 
to check the rest anyway to enforce stated constraint.  This should be 
relaxed.

- lack of details

The approach at a high level is reasonable and makes sense to me.

A very minor issue I see is behavior in face of misconfigured clients by 
allowing for manual configuration:

Consider client /w extended id support enabled sends Request to immediate 
upstream server in proxy chain not supporting extended id.

In this case some things may happen:

1. No server in the chain support extended id resulting in client never 
seeing a response.  This seems acceptable enough to me because the client 
is after-all misconfigured.

2. One or more servers in the chain support extended id.  What happens in 
this case is implementation specific.

A. Best case the benefits of extended id space are successfully tunneled 
back to requesting client thru servers that don't support it.  This is 
actually kind of cool assuming it's what actually happens.

B. Second best extended id attribute is dropped due to proxy specific 
policy restrictions causing client to never see response.  No response is 
an acceptable response to client misconfiguration.

C. Not so good proxy server is only checking srcaddr/srcport/id for 
duplicate requests resulting in a ton of dropped requests and a 
potentially difficult problem for operators to understand or troubleshoot.

----
draft-dekok-radext-request-authenticator-02

This approach also makes sense conceptually and seems to be marginally 
easier to manage.  No changes to request attributes, no worry about 
dynamic auth req and no sequence counter to maintain when generating ORA 
response.

This approach offers a small benefit ORA response always unambiguously 
correlated with requesting peer avoiding possibility of (C.) behavior in 
proxy chains.

I don't agree with client behavior when ORA is expected yet missing.  The 
response should always be to silently ignore request.  Certainly mandatory 
fallback mechanism for static configuration is going way too far in 
dictating behavior / controlling operator preference.

Wouldn't count on those who elect to implement a mechanism like this to 
also spend too much time working viable scalable connection management to 
provide useful interop with servers that don't support ORA otherwise to be 
honest likely wouldn't be much point in implementing this draft in the 
first place.  In my view it should not be assumed fallback is harmless or 
even a viable option.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Sun, 3 Dec 2017 09:18:50 -0500

On Dec 3, 2017, at 3:22 AM, Peter Deacon <[email-masked]> wrote:
> This approach also makes sense conceptually and seems to be marginally easier to manage.  No changes to request attributes, no worry about dynamic auth req and no sequence counter to maintain when generating ORA response.

  That was a major goal in the design.

> This approach offers a small benefit ORA response always unambiguously correlated with requesting peer avoiding possibility of (C.) behavior in proxy chains.

  It does have the possibility of a server sending the ORA attribute back in a response when it's not supposed to.  In that case, an old-style proxy *could* forward that attribute downstream.  We then have two cases:

- the downstream proxy / client doesn't implement the draft, in which case the attribute is ignored

- the downstream proxy / client does implement the draft, but hasn't negotiated it with the upstream (which doesn't implement it), and therefore the attribute is ignored.

  So the change is compatible with existing servers for all possible scenarios.

> I don't agree with client behavior when ORA is expected yet missing.  The response should always be to silently ignore request.  Certainly mandatory fallback mechanism for static configuration is going way too far in dictating behavior / controlling operator preference.

  That's certainly a good option.  I tried to cover all possible scenarios in the draft, with recommended behaviour.  But I'm open to changing the recommendations.

> Wouldn't count on those who elect to implement a mechanism like this to also spend too much time working viable scalable connection management to provide useful interop with servers that don't support ORA otherwise to be honest likely wouldn't be much point in implementing this draft in the first place.  In my view it should not be assumed fallback is harmless or even a viable option.

  I'm happy with that.

  i.e. if the server sends bad packets, the client should ignore them.

  Alan DeKok.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 4 Dec 2017 10:48:52 -0800

I prefer draft-chen-radext-identifier-attr-02. While both approaches
can work, I prefer not to overload the RA.

The draft needs some more work, but I believe it is ready for adoption.

Stig

---

From: Enke Chen <[email-masked]>
Date: Mon, 4 Dec 2017 11:51:12 -0800

Hi, Stefan:

1) I prefer draft-chen-radext-identifier-attr-02.

2) I believe that the draft offers a simple, and straightforward solution to the problem
   without overloading any unrelated fields.

3) The implementation is pretty simple too, about 190 lines of C code for the complete
   implementation (client / server /proxy, and both UDP and TCP)) in FreeRadius as posted
   in April 2017 to the RADEXT WG:

   https://www.ietf.org/mail-archive/web/radext/current/msg09905.html  

4) For a summary of the draft, please see the slides:

   https://datatracker.ietf.org/meeting/99/materials/slides-99-radext-radius-extended-identifier-attribute/

Thanks.  -- Enke

---

From: Peter Deacon <[email-masked]>
Date: Mon, 4 Dec 2017 20:26:53 -0800 (Pacific Standard Time)

On Fri, 1 Dec 2017, Jakob Heitz (jheitz) wrote:

> What if the quantum computers turn out to live up to their promises? 
> Then we can throw out all this authentication stuff and decide to not 
> share our Ethernets with the attackers instead. No more request 
> authenticator.

RADIUS security already lost cause no matter what :(

Best practice for many years - use a secure transport and or RADIUS over 
(D)TLS.  Regardless of selected security option in all cases operation of 
authenticator is maintained.

> The request authenticator is already overloaded. It may be used for the 
> CHAP challenge. Now, you want another overload?

Authenticator currently also used for at least following:

Tunnel Passwords
Message-Authenticator
PAP
CHAP
MPPE Keys

Clearly no possibility of authenticator ever changing in RADIUS protocol 
without creation of an incompatible replacement.  In event of an 
incompatible replacement there would be no need for either of these two 
drafts.

I am aware of no practical downside to "Overloading".

regards,
Peter

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Sat, 9 Dec 2017 16:26:54 +0000

Hi Stefan,

My vote is for draft-dekok-radext-request-authenticator-02.

I think the implementation will be simpler in the majority of cases and I see no issues with overloading the authenticator field.

-Arran

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 10 Dec 2017 11:31:06 -0500

I strongly prefer draft-dekok.

draft-chen takes approaches outside the mainstream of RADIUS implementations and previous standards, and is very under-specified. 
As a result its implementation will be much more difficult than is necessary. 

It extends the Status-Server message for the purpose of capability discovery which is inappropriate and utilizes an adhoc complex data type which violates RFC 6929. 

> On Nov 28, 2017, at 11:16 AM, Alan DeKok <[email-masked]> wrote:
> 
>> On Nov 28, 2017, at 8:54 AM, Stefan Winter <[email-masked]> wrote:
>  I prefer draft-dekok-radext-request-authenticator-02
> 
>  If the WG decides to use draft-chen-radext-identifier-attr-02, then I believe it needs significant changes before it's ready for publication:
> 
> - use of "ad hoc" complex data type violates RFC 6929 Section 6.3
> 
> - the negotiation can be simplified with no loss of functionality.  See my draft for examples.
> 
> - there is minimal discussion as to how this affects proxies, TCP, UDP, etc. 
> 
> - there is minimal discussion of inter-operability considerations with existing RADIUS solutions
> 
> - there are few guidelines for implementors
> 
>  While some WG members may prefer the technical solution in draft-chen-radext-identifier-attr-02, I think everyone can agree that the other proposal has these issues exhaustively enumerated and discussed.
> 
>  Alan DeKok.
>

---

From: Alan DeKok <[email-masked]>
Date: Sun, 10 Dec 2017 13:22:54 -0500

> It extends the Status-Server message for the purpose of capability discovery which is inappropriate and utilizes an adhoc complex data type which violates RFC 6929. 

  My draft has that too.  Though looking at it some more, it's not strictly necessary.

  I would prefer explicit negotiation, even if overloading Status-Server is ugly.

  Alan DeKok.

---

From: Enke Chen <[email-masked]>
Date: Mon, 11 Dec 2017 16:55:18 -0800

Hi, Folks:

Apologies for not being able to reply earlier.  We are certainly open to revising the
draft based on suggestions from Alan and other members, and will start working on it
should draft-chen-radext-identifier-attr-02 be adopted by the WG.

Thanks.  -- Enke

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Tue, 12 Dec 2017 01:08:50 +0000

I’ve read through the latest versions of both drafts, and I do prefer the approach taken in draft-chen-radext-identifier-attr.

From a protocol perspective, the two approaches do not seem very far apart to me. They both seem to do the following. (1) Define a new per-connection attribute as part of a Status-Server message. (2) Specify that a client chooses when to use a larger identifier. (3) Specify that when the server recognizes the “new extended field”, then it is obligated to return the original values of both identity field and the “new extended field”. (4) The server need not have any knowledge as to how the “new extended field” is determined.  (5) If the server does not recognize the new attribute, it ignores it. So in neither case do that the mechanism seem to unduly modify RADIUS.

It seems to me that the real difference comes down to how the “new extended field” is carried — either in the new per-connection attribute, or by overloading the Request Identifier. I appreciate the arguments in draft-dekok that indicate that there should not be a problem with overloading, but because overloading protocol fields can carry unexpected risks my preference is to adopt the explicit approach in draft-chen. With the same thought process I’m a little worried about defining "behavior previously left open to implementation interpretation” (as mentioned in Section 2.1 of draft-dekok). I cannot disagree that it “should" be OK, but the lack of certainly does add some risk.

However, I also believe that there is a lot of good background and explanatory text in draft-dekok that is valuable and if the working group takes draft-chen as the base then some of this would be valuable to bring that into the draft. This might address some of the concerns that draft-chen is under-specified.

Thanks,
Brian

> On Nov 28, 2017, at 5:54 AM, Stefan Winter <[email-masked]> wrote:
> 
> Hello,
> 
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
> 2, avenue de l'Université
> L-4365 Esch-sur-Alzette
> 
> 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
> 
> <0x8A39DC66.asc>_______________________________________________
> radext mailing list
> [email-masked]

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Mon, 11 Dec 2017 20:52:50 -0500

> On Dec 11, 2017, at 8:08 PM, Brian Weis (bew) <[email-masked]> wrote:
> 

  The differences are that the draft-chen proposal effectively modifies the RADIUS header, and that it has the opportunity for "leakage" of extended IDs in the case of error or misconfiguration.

  My draft has none of these issues.

> It seems to me that the real difference comes down to how the “new extended field” is carried — either in the new per-connection attribute, or by overloading the Request Identifier. I appreciate the arguments in draft-dekok that indicate that there should not be a problem with overloading, but because overloading protocol fields can carry unexpected risks

  Risks like... ?

  I must admit to being a little surprised at the dislike of "overloading" the Request Authenticator field.  As Peter Deacon pointed out, it's already "overloaded" for many, many, other things.

  Given the existing definition of the Request Authenticator field, it is *impossible* at this time to change how it's calculated.  Similarly, it's impossible to change the meaning of the field for packet signatures.  And, it's impossible to change the usage of the field within other attributes.

  So we're left with a field that we cannot change, but we can look at.  What is the risk in looking at it?  What is the risk in echoing it verbatim in a response packet?

  I understand that saying "we add a 32-bit ID" is conceptually simpler.  But I still don't get where any "risk" or concern with "overloading" of the field comes from.  Some additional explanation would be useful here.

> my preference is to adopt the explicit approach in draft-chen. With the same thought process I’m a little worried about defining "behavior previously left open to implementation interpretation” (as mentioned in Section 2.1 of draft-dekok). I cannot disagree that it “should" be OK, but the lack of certainly does add some risk.

  How?

  The draft goes through exhaustive enumeration of the possibilities.  It shows that the proposal is no worse than existing RADIUS, and in some cases is substantially better.

> However, I also believe that there is a lot of good background and explanatory text in draft-dekok that is valuable and if the working group takes draft-chen as the base then some of this would be…

  I agree.

  I think a large part of the concern here is due to the background and explanatory text in my document.  i.e. a proposal which describes the risks seems risky.   A proposal which ignores the risks seems less risky.

  But I would still like to understand (a) what the risks are here, and (b) why there's a concern with "overloading" a field that cannot be changed, and is already used for many things.

  Alan DeKok.

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Tue, 12 Dec 2017 02:39:42 +0000

Hi Alan,

> On Dec 11, 2017, at 5:52 PM, Alan DeKok <[email-masked]> wrote:
> 
> 

From your comments I see that the point that the draft effectively modifying the RADIUS header is due to requiring that the Extended-Identifier be the first attribute. That seems to be an optimization that does not appear to be necessary, and could be removed to address this point. (I assume either draft would undergo change if it became a WG draft.)

>  My draft has none of these issues.

Regarding leakage, does a proxy normally replace the Request Authenticator field with a new value? (I’m asking for information.)

>  Given the existing definition of the Request Authenticator field, it is *impossible* at this time to change how it's calculated.  Similarly, it's impossible to change the meaning of the field for…

I’m missing where draft-chen does any of these things (assuming that the “MUST be first attribute” is removed).

>  The draft goes through exhaustive enumeration of the possibilities.  It shows that the proposal is no worse than existing RADIUS, and in some cases is substantially better.

I appreciate the enumeration, and I’m not implying that you’ve missed any known risk. But so often overloading fields leads to unforeseen results (due to bad assumptions by a developer or future specification writer) and that’s the basis for my concern.

>  I think a large part of the concern here is due to the background and explanatory text in my document.  i.e. a proposal which describes the risks seems risky.   A proposal which ignores the risks…

Personally, I did not find the background and explanatory text to make draft-dekok seem seem more risky. I’m reacting to the overloading, where given similar outcomes I prefer not to introduce additional semantics to an existing field.

Thanks,
Brian

---

From: David Carrel <[email-masked]>
Date: Tue, 12 Dec 2017 04:21:50 +0000

I also support moving forward with draft-chen-radext-identifier-attr as the
base for future work.  To me it seems to be a cleaner solution and that it
will be easier to create interoperability.  Adding additional semantic
meanings to an existing field (the Authenticator) does seem to be fraught
with potential risk. Certainly either of these could move forward to
address the scalability issue, but I prefer draft-chen-

As others have mentioned, I think we should look at removing the
requirement for this attribute to be in a fixed position (first).

Dave

---

From: Peter Deacon <[email-masked]>
Date: Mon, 11 Dec 2017 22:11:26 -0800 (Pacific Standard Time)

On Tue, 12 Dec 2017, Brian Weis (bew) wrote:

> draft-chen. With the same thought process I’m a little worried about 
> defining "behavior previously left open to implementation 
> interpretation” (as mentioned in Section 2.1 of draft-dekok). I cannot 
> disagree that it “should" be OK, but the lack of certainly does add some 
> risk.

Partially why I prefer draft-dekok-radext-request-authenticator.

Mitigates existing ambiguity that remains intact /w 
draft-chen-radext-identifier-attr.

> I appreciate the arguments in draft-dekok that indicate that there 
> should not be a problem with overloading, but because overloading 
> protocol fields can carry unexpected risks my preference is to adopt the 
> explicit approach in draft-chen.

Both drafts are "overloading" payload of RADIUS packets to carry 
identifiers that clearly belong in header.  This has objectively 
articulable consequences.

Due to "overloading" it is no longer possible to route and correlate 
packets based on header information.  Implementations are now required to 
decode attribute payloads to perform this function.  Possible new risks of 
request and response attributes being mishandled or misinterpreted in 
mixed environments.

Of the two draft-dekok-radext-request-authenticator appears to carry LESS 
"overload" risks as only responses are modified.  Most importantly ORA is 
native header information being used for header purposes unique to one and 
only one specific request packet.  The major reason I support 
draft-dekok-radext-request-authenticator it is intentionally designed to 
mitigate "overload" risk.

On "Overloading" invoked by transmission of ORA.. RFC2865 Section 3 
describes RA:

---
"In Access-Request Packets, the Authenticator value is a 16 octet random 
number"

...

"The value SHOULD be unpredictable and unique over the lifetime of a 
secret"

...

"Since it is expected that the same secret MAY be used to authenticate 
with servers in disparate geographic regions, the Request Authenticator 
field SHOULD exhibit global and temporal uniqueness."
---
For acct/dyn auth MD5 sum over packet.

I am aware of no objectively articulable consequences of using 
authenticator for this purpose.  There are no architecturally pure options 
on the table except time honored tradition of throwing more connections at 
the problem.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Dec 2017 08:27:58 -0500

> From your comments I see that the point that the draft effectively modifying the RADIUS header is due to requiring that the Extended-Identifier be the first attribute. That seems to be an optimizat…

  It still is effectively a modification of the RADIUS header.  i.e. the 25 year-history of "look at the first 20 octets" is now changed.

  In contrast, draft-dekok changes *nothing* about request packets.

> Regarding leakage, does a proxy normally replace the Request Authenticator field with a new value? (I’m asking for information.)

  Yes.  draft-dekok is hop-local by design.  There is no possibility to leak data which is never in the packet...

> I’m missing where draft-chen does any of these things (assuming that the “MUST be first attribute” is removed).

  It doesn't.  But neither does draft-dekok.  My comment was about risk, not about draft-chen.

  i.e. draft-dekok changes nothing about Request Authenticator, but it's risky.  Or, draft-chen adds a 32-bit ID which may leak across proxy boundaries, and has undefined behavior when an extended ID is re-used.  But that's less risky.

> I appreciate the enumeration, and I’m not implying that you’ve missed any known risk. But so often overloading fields leads to unforeseen results (due to bad assumptions by a developer or future sp…

  The exhaustive enumeration of possibilities was intended to mitigate the risk, by explaining and understanding all possible situations.

  As for unforeseen results, RFC 2865 Section 3 says:

         ... the Request Authenticator field
         SHOULD exhibit global and temporal uniqueness.

  That sure sounds like a unique ID to me.  The draft then proposes that:

1) if a server receives a request that matches a "live" one (src/dst IP/port, code, ID), then it MAY also use the Request Authenticator to differentiate the packets
2) as a result of (1), the original Request Authenticator is echoed back in response packets.

  That's really it.  I'll remind the WG that the behaviour of (1) is currently *undefined* in RADIUS.  So the draft is arguably mitigating the existing risk by defining that behaviour.  Not only for the new proposal, but also for existing RADIUS.

> Personally, I did not find the background and explanatory text to make draft-dekok seem seem more risky. I’m reacting to the overloading, where given similar outcomes I prefer not to introduce addi…

  The concern here is that we *already* have these semantics on the Request Authenticator.   Implementations *cannot* inter-operate without choosing some semantics for Request Authenticator.  

  So draft-dekok just explains these semantics, documents existing practice, and explains how existing semantics can be leveraged to gain new functionality.

  I think the main difference here is that it's simple to say "add a 32-bit attribute".  In contrast, it seems weird to use the Request Authenticator like this.  But as an implementor... it's already being used like this in ever server implementation in the world.

  Alan DeKok.

---

From: Adam Bishop <[email-masked]>
Date: Tue, 12 Dec 2017 20:39:06 +0000

> shouldn't do is to vote for both; that wouldn't help the discussion move on.

Having read both drafts, I think the approach in draft-dekok is more suitable for adoption.

While assigning additional meaning to existing values can be problematic, there is sufficient explanation already present in the draft to reassure me that this shouldn’t interact negatively with existing implementations, and avoids changing or extending the header.

I agree with the observation that draft-chen could be problematic in federated deployments due to the potential for the identifier to leak between hops.

Regards,

Adam Bishop

  gpg: E75B 1F92 6407 DFDF 9F1C  BF10 C993 2504 6609 D460

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.

---

From: Jun Zhuang <[email-masked]>
Date: Tue, 12 Dec 2017 23:27:27 +0000 (UTC)

Hi,
After reading both drafts, I prefer draft-chen-radex-identifier-attr-02 over draft-dekok-radex-request-authenticator-02, as I think it is cleaner solution and will be easier to debug and deploy.  
Also, I noticed that draft-chen-radex-identifier-attr-02 was published last July to address the problem. The draft-dekok-radex-request-authenticator-02 was published this April this year, an interval of more than 10 months. Since both are open to revising and improvement, I vote for adopting the draft-chen-radex-identifier-attr-02 as the base and go forward.

Regards,
James Zhuang
    On Tuesday, December 12, 2017, 12:39:22 PM PST, Adam Bishop <[email-masked]> wrote:  

Regards,

Adam Bishop

jisc.ac.uk

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Tue, 12 Dec 2017 23:47:29 +0000

Stefan,

As a co-auther, I vote for draft-chen-radext-identifier-attr-02.

As for the attribute being the first attribute or not, if the working group
does not think it’s necessary, then we can change that to be general.
We will look through all the comments to have an update soon.

Best Regards,
- Naiming

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 13 Dec 2017 00:08:00 +0000

I have seen some comments about the draft-chen proposal has the potential of
leaking the extended-ID by the proxy server.

First of all, if an implementation has bugs or the configuration is mishandled,
then we need have ways to debug and troubleshoot. Being an attribute gives
explicitly ways for debugging; An implementation should also have instrustment
for better debug in radius programs.

Second, similar to some types of attributes, a proxy can be configured to
explicitly filter them out (Filter Radius Attributes). If we are arguing we can
not rely on the proxy to filter them out, since there might be bugs or
misconfiguration, thus we should not even allow those attributes in radius
packets, that logic does not sound reasonable;

Third, if assume an operation completely messed up, and leaking this
extended-ID towards the home-server, I still need to see a good example
on what the harm is that, and why this can not be debugged. The draft
I agree needs to add some text on various cases and how to debug
those in each of them.

Best Regards,
- Naiming

> On Dec 12, 2017, at 12:39 PM, Adam Bishop <[email-masked]> wrote:
>

---

From: Peter Deacon <[email-masked]>
Date: Tue, 12 Dec 2017 16:52:50 -0800 (Pacific Standard Time)

> I agree needs to add some text on various cases and how to debug

Offered an example in my initial response.  More detail below.

Request:
[+Client]  ---> [-Proxy A] ---> [+Proxy B] --> ...

Response:
... ---> [+Proxy B] ---> [-Proxy A] ---> [+Client]

+ supports extended id
- does not support extended id

Assumptions:

- Proxy A performs duplicate detection over (src ip/port) + id.
- Requests transmitted from Client /w extended ID.
- Client receives responses /w extended ID courtesy of Proxy B.

This scenario can easily result in high numbers of intermittently dropped 
packets because Proxy A is intentionally dropping what it believes are 
duplicates.  Proxy A does not implement extended id and so has no idea 
what is going on nor instrumented to know anything about extended id.

Client is similarly clueless.  It sees extended id requests AND extended 
id responses /w intermittent packet loss.  It has no clue the upstream 
proxy it is directly communicating does not support extended id.  There is 
no way for it to know.

>From the client perspective it would in my experience likely be very 
difficult for an operator to troubleshoot this kind of intermittent 
failure one that gets progressively worse as load increases unless they 
had an unrealistically high degree of technical knowledge.

This problem DOES NOT exist /w ORA because any and all such 
misconfiguration always results in client seeing no valid response at all. 
This is an acceptable response to misconfiguration.

A client receiving bogus ORA from some other peer or no ORA at all is free 
to complain loudly explicitly alerting operators of misconfiguration. 
This option simply is not possible /w extended id.

regards,
Peter

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 13 Dec 2017 01:00:23 +0000

then the Client which initiated this can detect the returned packets, and
terminate the extended-ID scheme. it’s up to the implementation to detect
this. also I can not imaging the server-status will be returned to the Client
correctly in this case to ‘fool’ the Client the Proxy-A supports this feature.

Regards,
- Naiming

> On Dec 12, 2017, at 4:52 PM, Peter Deacon <[email-masked]> wrote:
> 
> This scenario can easily result in high numbers of intermittently dropped packets because Proxy A is intentionally dropping what it believes are duplicates.  Proxy A does not implement extended id and so has no idea what is going on nor instrumented to know anything about extended id.
> 
> Client is similarly clueless.  It sees extended id requests AND extended id responses /w intermittent packet loss.  It has no clue the upstream proxy it is directly communicating does not support extended id.  There is no way for it to know.
> 
> From the client perspective it would in my experience likely be very difficult for an operator to troubleshoot this kind of intermittent failure one that gets progressively worse as load increases unless they had an unrealistically high degree of technical knowledge.
> 
> 
> This problem DOES NOT exist /w ORA because any and all such misconfiguration always results in client seeing no valid response at all. This is an acceptable response to misconfiguration.
> 
> A client receiving bogus ORA from some other peer or no ORA at all is free to complain loudly explicitly alerting operators of misconfiguration. This option simply is not possible /w extended id.
> 
> regards,
> Peter

---

From: Peter Deacon <[email-masked]>
Date: Tue, 12 Dec 2017 17:41:52 -0800 (Pacific Standard Time)

On Wed, 13 Dec 2017, Naiming Shen (naiming) wrote:

> then the Client which initiated this can detect the returned packets, 
> and terminate the extended-ID scheme. it’s up to the implementation to 
> detect this.

How specifically can this be achieved?  What is your proposal?  Risks? 
Implementation complexity?

> also I can not imaging the server-status will be returned to the Client 

Does extended id draft support manual configuration?

The question on the table is not whether extended id is good or bad in a 
vacuum.  The question is which of the options is technically the better 
option on the merits.

regards,
Peter

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 13 Dec 2017 02:07:36 +0000

> On Dec 12, 2017, at 5:41 PM, Peter Deacon <[email-masked]> wrote:
> 
>> then the Client which initiated this can detect the returned packets, and terminate the extended-ID scheme. it’s up to the implementation to detect this.
> 
> How specifically can this be achieved?  What is your proposal?  Risks? Implementation complexity?

As the draft currently specified, the server-status message returned by the proxy/server has to match
the specified pattern/bits; the returned authentication-reply message has to match the id, extended-id,
if not there is an error. if the error is accumulated, the radius-client should know. simple to implement.

> 
>> also I can not imaging the server-status will be returned to the Client correctly in this case to ‘fool’ the Client the Proxy-A supports this feature.
> 

The draft specifiies the mechanism, not the operations. But my patch for this draft on FreeRadius,
does support manual configuration on the client and proxy. I sent my patch to this mailing list
months ago. This is the way to show how simple this mechanism. With client/proxy/server, with
tested on UDP/TCP, total of 200 lines of C code.

> 
> The question on the table is not whether extended id is good or bad in a vacuum.  The question is which of the options is technically the better option on the merits.

I understand. This is why I think draft-chen is the better one. simple, not overloading
the original radius header definitions, easy to implement.

Regards,
- Naiming

---

From: Peter Deacon <[email-masked]>
Date: Tue, 12 Dec 2017 18:49:27 -0800 (Pacific Standard Time)

> As the draft currently specified, the server-status message returned by 
> the proxy/server has to match the specified pattern/bits; the returned

Please assume status server is NOT being used and all configuration is 
manual as allowed per section 2.2:

"  Unless specified by configuration, a client MUST NOT send a RADIUS
    packet (other than the Status-Server request) with the "Extended
    Identifier Attribute" to a server until it has received a response
    from the server confirming its support for the Extended Identifier
    feature using the "Extended Identifier Attribute"."

I failed to explicitly state this when responding to your question 
regarding misconfiguration and ability for clients to detect problems.  I 
apologize for any confusion this has caused.

> authentication-reply message has to match the id, extended-id, if not 
> there is an error. if the error is accumulated, the radius-client should 
> know. simple to implement.

Unfortunately it's not this simple.  The problem described is one in which 
packets are being dropped while at the same time the client is also 
receiving exact extended-id attribute and values it expects to see during 
normal successful operation.

How does detection algorithm work so client can detect this 
misconfiguration?  How does it know lack of any response packet is caused 
by misconfiguration vs packet loss and or system issues?  Can you offer 
technical details?

regards,
Peter

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 13 Dec 2017 03:19:48 +0000

If you insist misconfiguration is the greatest thing we have to deal with,
then I can imagine you misconfigurae your server ip address and proxy ip address,
and packets will not be returned, how to you troubleshoot that? if you do
have ways, and this draft also have ways. Can you imaging an operator
insist to do a manual configuration without check the status of the server,
and without doing any checking after manual turning on a new feature, and
just have to misconfigure his/her radius client? amazing...

any text you mention can change also, it’s up to the working group how it
supports to work eventually.

as I mentioned, the draft-chen needs to be updated from the comments of this
emailing list.

Regards,
- Naiming

> On Dec 12, 2017, at 6:49 PM, Peter Deacon <[email-masked]> wrote:
> 
>> As the draft currently specified, the server-status message returned by the proxy/server has to match the specified pattern/bits; the returned
> 
> Please assume status server is NOT being used and all configuration is manual as allowed per section 2.2:
> 
> I failed to explicitly state this when responding to your question regarding misconfiguration and ability for clients to detect problems.  I apologize for any confusion this has caused.
> 
>> authentication-reply message has to match the id, extended-id, if not there is an error. if the error is accumulated, the radius-client should know. simple to implement.
> 
> Unfortunately it's not this simple.  The problem described is one in which packets are being dropped while at the same time the client is also receiving exact extended-id attribute and values it expects to see during normal successful operation.
> 
> How does detection algorithm work so client can detect this misconfiguration?  How does it know lack of any response packet is caused by misconfiguration vs packet loss and or system issues?  Can you offer technical details?
> 
> regards,
> Peter

---

From: Peter Deacon <[email-masked]>
Date: Tue, 12 Dec 2017 21:58:50 -0800 (Pacific Standard Time)

> If you insist misconfiguration is the greatest thing we have to deal with,

Decision to expand on original remarks in response to call for adoption 
was result of your inquiry:

"Third, if assume an operation completely messed up, and leaking this 
extended-ID towards the home-server, I still need to see a good example on 
what the harm is that, and why this can not be debugged. The draft I agree 
needs to add some text on various cases and how to debug those in each of 
them."

Otherwise I am happy with the relative strength of my remarks in their 
original context.

> and packets will not be returned, how to you troubleshoot that? if you do

If when manually switched on in an environment where it should not be the 
result is not working at all that would be perfectly fine.  Unfortunatly 
as I have shown this is not the case with extended-id.

In this aspect of consideration ORA clearly has an advantage both in 
ability to detect and report failure and nature of failure itself.

> insist to do a manual configuration without check the status of the server,

Yes absolutely.  This will defiantly occur.  Status-server is not 
universally supported.

regards,
Peter

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 13 Dec 2017 06:08:07 +0000

When I say “check the status of the server”, sorry I didn’t mean the server-status
message. When an operator decides to do manual configuration of a new feature
and override the normal automated discovery procedure, he/she needs to check
the radius server and/or radius proxy server software version, status, etc. He/she would
not just blindly configure the new feature, and go home to sleep and assume
everything is fine. That's just common sense. 

BTW, Status-server is not supported universally is not a problem here.
When the server software supports this draft, then it MUST implement the
Status-server message at least for this feature.

Regards,
- Naiming

> On Dec 12, 2017, at 9:58 PM, Peter Deacon <[email-masked]> wrote:
> 
> Decision to expand on original remarks in response to call for adoption was result of your inquiry:
> 
> "Third, if assume an operation completely messed up, and leaking this extended-ID towards the home-server, I still need to see a good example on what the harm is that, and why this can not be debugged. The draft I agree needs to add some text on various cases and how to debug those in each of them."
> 
> Otherwise I am happy with the relative strength of my remarks in their original context.
> 
> If when manually switched on in an environment where it should not be the result is not working at all that would be perfectly fine.  Unfortunatly as I have shown this is not the case with extended-id.
> 
> In this aspect of consideration ORA clearly has an advantage both in ability to detect and report failure and nature of failure itself.
> 
> Yes absolutely.  This will defiantly occur.  Status-server is not universally supported.
> 
> regards,
> Peter

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 13 Dec 2017 06:34:30 +0000

Once we are arguing "It doesn't work when there's bugs or misconfigs",
then we've sunk pretty low. But now that we're there, here is a more
likely bug: Retransmission with a new request-authenticator.
draft-dekok will interpret that as an entirely new request.
That is why keeping the id and authenticator separate is cleaner.

Thanks,
Jakob

-----Original Message-----
From: radext [mailto:[email-masked]] On Behalf Of Naiming Shen (naiming)
Sent: Tuesday, December 12, 2017 10:08 PM
To: Peter Deacon <[email-masked]>
Cc: [email-masked]
Subject: Re: [radext] Extended IDs

Regards,
- Naiming

---

From: Peter Deacon <[email-masked]>
Date: Tue, 12 Dec 2017 22:40:39 -0800 (Pacific Standard Time)

> Status-server message at least for this feature.

This is not my understanding based on text.  Can you offer relevant 
citation in draft-chen-radext-identifier-attr-02.txt supporting this 
position?

I don't support making status-server mandatory.

regards,
Peter

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 13 Dec 2017 07:03:20 +0000

The text of draft-chen currently assumes server-status is
an supported option. If the radius server software does not even support this,
then this extended-ID scheme more likely is not even relavent in
the environment. The design and implmenetation of the software should always
consider the ease of operational burden as the first priority, in particular
this automated discovery has been around for many years. One can always
develop its own discovery with each additional new feature/attributes, but
we should always try to maximize and share the existing mechanism.

Regards,
- Naiming

> On Dec 12, 2017, at 10:40 PM, Peter Deacon <[email-masked]> wrote:
> 
>> BTW, Status-server is not supported universally is not a problem here. When the server software supports this draft, then it MUST implement the Status-server message at least for this feature.
> 
> This is not my understanding based on text.  Can you offer relevant citation in draft-chen-radext-identifier-attr-02.txt supporting this position?
>

---

From: Stefan Winter <[email-masked]>
Date: Wed, 13 Dec 2017 08:15:11 +0100

Hello,

> then we've sunk pretty low.

As a chair:

I do not think that was the point made in this (sub)thread.

The substantial part of the discussion was about misconfiguration (not
bugs in implementation), and the *extent* to which a misconfiguration
does harm.

The argument was that draft-dekok has a more gentle failure consequence:
communication between a client and its communication target (server or
proxy) does not work, and deterministically so. The breakage is local
between the two.

Contrary to that, draft-chen's failure mode is that confusion about the
state of communication peers may transpire along all proxies and the
final server along the proxy chain, with the ability to debug and
isolate the problem becoming difficult.

It is a configuration problem because nobody is required to implement
this new RFC - so if a request comes in with the new attribute, it's by
default treated like any other unknown attribute in RADIUS: ignore as a
server, forward unchanged as a proxy. This simple "do-nothing" is what
triggers the unpleasant failure mode in draft-chen draft. To prevent it,
every proxy operator has to take action and configure this attribute as
to-be-deleted when proxying.

That appears to be a very strong argument against a new attribute.

As an individual:

Operating a global-scale proxy environment with hundreds of proxies
across hundreds of different administrative domains, I think I can say
with some certainty that a) proxies without support for the new RFC will
be around for timescales best measured in decades, and b) such
misconfigurations WILL occur.

Greetings,

Stefan Winter

>  But now that we're there, here is a more

---

From: Stefan Winter <[email-masked]>
Date: Wed, 13 Dec 2017 08:22:05 +0100

Hello,

again as a chair:

regarding the question of whether overloading of Request-Authenticator
should be considered harmful, I think the message from Peter below best
summarises the deployed reality in RADIUS.

Basically, it makes clear that the decision to overload
Message-Authenticator or not is not on our table. That decision has been
taken ages ago, by this working group, and for a good number of RADIUS
attributes.

So, for the discussion at hand, fears about overloading the
Request-Authenticator can safely be considered a non-argument.

Greetings,

Stefan Winter

> Best practice for many years - use a secure transport and or RADIUS
> over (D)TLS.  Regardless of selected security option in all cases
> operation of authenticator is maintained.
>
>> The request authenticator is already overloaded. It may be used for
>> the CHAP challenge. Now, you want another overload?
>
> Clearly no possibility of authenticator ever changing in RADIUS
> protocol without creation of an incompatible replacement.  In event of
> an incompatible replacement there would be no need for either of these
> two drafts.
>

---

From: Peter Deacon <[email-masked]>
Date: Tue, 12 Dec 2017 23:40:48 -0800 (Pacific Standard Time)

> an supported option. If the radius server software does not even support this,

I will assume this means the answer to my question is nothing in the text 
requires status-server.

> the environment. The design and implmenetation of the software should always

What is the linkage between status-server and expanded id space?

> this automated discovery has been around for many years. One can always

Certainly not my understanding.  The only RFC I know of "overloading" 
status-server for any sort of capability negotiation is RFC7930 and at 
least that has sense enough to be limited to stream transports.

regards,
Peter

---

From: Enke Chen <[email-masked]>
Date: Tue, 12 Dec 2017 23:48:13 -0800

Peter,

The "Status-Server" is used for capability negotiation by both drafts.
Neither mechanism will work with an ancient server that does not support
the "Status-server" properly.

Regards,  -- Enke

On 12/12/17 11:40 PM, Peter Deacon wrote:
> I will assume this means the answer to my question is nothing in the text requires status-server.
> 
> Certainly not my understanding.  The only RFC I know of "overloading" status-server for any sort of capability negotiation is RFC7930 and at least that has sense enough to be limited to stream transports.
> 
> regards,
> Peter
>

---

From: Peter Deacon <[email-masked]>
Date: Wed, 13 Dec 2017 00:21:46 -0800 (Pacific Standard Time)

> The "Status-Server" is used for capability negotiation by both drafts.

Completely agree.  None of my comments regarding status server are unique 
to either draft.

> the "Status-server" properly.

This is not my understanding.  I see nothing in text precluding anyone 
from manually configuring support for extended-id or ORA and never using 
status-server if they prefer not to for whatever reason.

Welcome specific citation saying I'm wrong or logical argument explaining 
why extended-id is not possible without status-server /w relevant 
citations.  Opinions of usefulness of status-server for capability 
negotiation NOT welcome.

What's the point of explicitly referencing the possibility of manual 
enablement if not to support extended-id without status-server?

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Dec 2017 08:05:22 -0500

> On Dec 13, 2017, at 1:34 AM, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 

  Insults aren't appropriate.

  Discussing how the proposal behaves in the event of misconfiguration is entirely appropriate.  In fact, that discussion can strongly influence the design of a solution.

> draft-dekok will interpret that as an entirely new request.

  That's not how RADIUS works. 

  Quoting RFC 2059, from 1997:

      ... For retransmissions where the
      contents are identical, the Identifier MUST remain unchanged.

      Note that if Acct-Delay-Time is included in the attributes of an
      Accounting-Request then the Acct-Delay-Time value will be updated
      when the packet is retransmitted, changing the content of the
      Attributes field and requiring a new Identifier and Request
      Authenticator.

  See also RFC 5080, as I suggested in an earlier response.

  If a packet is a *retransmission*, then all of it's contents are the same.  Including the header.  So both drafts will see the packet as a duplicate, as per RFC 5080 Section 2.2.2.

  If the packet contents are not the same, then it's not a retransmission.  And going back to 20 year-old standards, the Request Authenticator (among other fields) also changes.

> That is why keeping the id and authenticator separate is cleaner.

  Both drafts behave identically in the situation when a duplicate packet is retransmitted.  Both drafts behave identically when the packet contents change.

  And in both situations, both drafts follow the existing RADIUS standards.

  Please go back and read the standards to see how RADIUS works.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Dec 2017 08:20:03 -0500

> everything is fine. That's just common sense. 

  I agree.  Many administrators don't. :(  I've seen some "inventive" administrative practices.

  It would be good to have a solution that is robust in the event of misconfiguration, or software changes.

  i.e. I upgrade my RADIUS server, but don't tell people who send packets to it.  If those servers are statically configured to do extended-ID, then the extended-id attribute will "leak" to my server, and to any later proxy servers.

  My concern is that the Extended-ID is intended for signalling in one hop, and should not leak across proxy chains.

> Status-server message at least for this feature.

 Then I would also suggest mandating that manually enabling it on the client is forbidden.

  And should the negotiation be done on every connection from client to server?  If not, why not?

  The bulk of draft-dekok goes through all of these issues and tries to give explanations.  Much of that text is applicable to both drafts.

  And because draft-dekok is largely implemented on the server, manually enabling it on the client doesn't really do much.

  Alan DeKok.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Dec 2017 13:21:24 +0000

Stefan, 

I believe you are speaking as a contributor and not as a chair when making
technical contributions to this discussion (last two E-mails).

Thanks,
Acee

---

From: Adam Bishop <[email-masked]>
Date: Wed, 13 Dec 2017 22:38:09 +0000

On 13 Dec 2017, at 00:08, Naiming Shen (naiming) <[email-masked]> wrote:
> First of all, if an implementation has bugs or the configuration is mishandled

My concern is less around implementation bugs, and more around the kind of behaviour that can happen upstream - it’s one thing to make your own deployment misbehave, it’s another to trigger misbehaviour in something that isn’t under your control (and therefore, cannot be debugged, or potentially, even resolved without outside assistance).

As a participant in a roaming consortium, that makes me uncomfortable.

> The draft I agree needs to add some text on various cases and how to debug
> those in each of them.

I can’t make a choice based on text that doesn’t yet exist, but I would give it due consideration if it were to appear.

Somewhere in the thread simpler debugging was cited as a desirable property of draft-chen  - I’m not sure I grasped the argument though. What makes a byte string in the header more difficult to validate/printf than an byte string encapsulated in a TLV?

Regards,

Adam Bishop

jisc.ac.uk

---

From: Enke Chen <[email-masked]>
Date: Wed, 13 Dec 2017 14:50:54 -0800

Hi, Stefan:

Here is my count of the votes:

13 for draft-chen-radext-identifier-attr-02
 6 for draft-dekok-radext-request-authenticator-02

Is this correct?

Thanks.  -- Enke

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Dec 2017 21:05:38 -0500

> Somewhere in the thread simpler debugging was cited as a desirable property of draft-chen  - I’m not sure I grasped the argument though. What makes a byte string in the header more difficult to val…

  I think the opinion is that looking at one packet, an *explicit* Extended-ID attribute is easier to see than the idea that the Request Authenticator is *implicitly* also used as an ID.

  But... it's 2017.  There are many, many, solutions for correlating requests and responses.  Doing this in software is easy.  There are many free / open source products that will be available.

  And both proposals will confuse existing packet sniffing software.  That can't be helped, unfortunately.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 14 Dec 2017 15:38:59 +0100

Hello,

> technical contributions to this discussion (last two E-mails).

Your belief if wrong. There are two obvious reasons:

- I stated "as a chair" when beginning my mails
- I am not a contributor to either of the two drafts

Greetings,

Stefan Winter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Dec 2017 15:13:14 +0000

>- I am not a contributor to either of the two drafts

Of course, I meant a WG individual contributor and not a contributor to
the documents. Normally, you’d speak "as a chair" only when you are
addressing WG process and not when you are making technical comments.

Acee

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Dec 2017 10:15:20 -0500

> addressing WG process and not when you are making technical comments.

  To be fair, deciding which topics are on point is part of the WG process, and within the bounds of a chairs discretion.

  Alan DeKok.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Dec 2017 15:32:48 +0000

On 12/14/17, 10:15 AM, "Alan DeKok" <[email-masked]> wrote:

>  To be fair, deciding which topics are on point is part of the WG
>process, and within the bounds of a chairs discretion.

While they are no longer in the thread, these were clearly technical
comments as to how RADIUS works and is deployed. These comments should
stand on their own merit and not the chair position.

Acee

---

From: Stefan Winter <[email-masked]>
Date: Fri, 15 Dec 2017 08:07:53 +0100

Hi,

> stand on their own merit and not the chair position.

Much rather, these were statements regarding past working group practice.

There are several RFCs overloading the Request-Authenticator for a
number of reasons.

By issuing those RFCs, the working group has repeatedly (either
implicitly or explicitly; feel free to browse the mail archive for
details) made the decision that this is not an issue.

It is also an easy observation that the sky has not fallen onto RADIUS
as a result of those decisions back then.

The sentences above are not an opinion; they are merely statements
reminding the working group participants of our collective past.

It is part of the "moderate discussions" job of a chair to point out
such things.

Greetings,

Stefan Winter

---

From: Alexander Clouter <[email-masked]>
Date: Fri, 15 Dec 2017 14:22:31 +0000

> to serve as the basis for future work.

My post deadline £0.02...

Though on every ones lips is extending the ID, I would disagree that the drafts
cover the same topic and that draft-dekok only solves this problem indirectly.

draft-dekok covers a real problem, not considered by draft-chen, on how to 
handle late responses to authentications where the ID collides, this is 
something that should be firmed up.  Firming up with draft-dekok happens to 
mean there is no need to also push ahead with draft-chen.  Pushing with 
draft-chen, still leaves everyone with this ambiguity around ID collisions.

I do not perceive anything to indicate that draft-chen is easier to reason 
about than draft-dekok, they strike me as in effect identical as both return a 
special attribute in the *response*.

The request packet though is less interesting and for me irrelevant where the 
extra entropy appears from.  From an implementation perspective the difficulty 
exists at the NAS/proxy rather than the server.  The impact of doing duplicate 
work at the server is negligible compare to a NAS/proxy not being able to 
reconcile replies to their requests.

In regards to the draft its self, draft-chen looks straight forward, but having 
had the unsavoury experience of implementing a specification that states only 
the 'what' rather than the 'why' or 'how' (TACACS, I am looking at you...) I 
find it hard to rally behind something I am hesitant to believe is as simple as 
it looks.

draft-chen reads as "this is what is baked in an existing codebase" with no 
information on the 'what if' or detailing any edge cases the implementers 
experienced.

I need to know about problems and caveats I need to know about, I do not need 
to know how to clone an existing implementation, I have tcpdump for that :)

...draft-dekok gets my, no doubt too late for consideration, vote.