Subject: [radext] Comments on draft-halwasia-radext-capability-negotiation-00

From: "Jim Schaad" <[email-masked]>
Date: Sun, 10 Feb 2013 15:09:51 -0600

I find it very difficult to begin to evaluate how this draft really works if
it is missing the section on RADIUS Proxy Behavior.  Proxies are going to
have different answers if they do not support this feature, and if they do. 

Proxies will also have different answers based on how they support or don't
support, but can ask the next proxy in line for an answer.  

Proxies may end up with different answers based on the routing of a message
that it obtains.  Thus talking to the same server, but over a different
route may come up with a different answer.

I think that there may be a security consideration on asking for and
recieveing different answers for capabilities.  For example, if one asks
about a security capability there is the possibility of a down grade attack
from any proxy in the system and possibly from people outside of the proxy
net based on the routing of messages.

Jim

---

From: Alan DeKok <[email-masked]>
Date: Sun, 10 Feb 2013 16:35:44 -0500

> have different answers if they do not support this feature, and if they do. 

  The intention of the draft is that capabilities are point to point.

> support, but can ask the next proxy in line for an answer.  

  I would be wary of multi-hop capabilities.

> route may come up with a different answer.

  Exactly.  Any multi-hop capability negotiation has to include the
capabilities of *all* hops, along with a "name" for the home server.

  For now, that's an area of discussion.  This draft fills a need for
NAS to local server negotiation.  Anything past that is unknown.

> net based on the routing of messages.

  If the packets are signed appropriately, impersonation attacks can't
occur.  The attacks left are then in-network downgrade attacks.  I'd
largely attribute those to misconfiguration instead of malice.

  I would view this draft as negotiating RADIUS capabilities, not
security ones.  e.g. negotiating TLS to a home server may be out of
scope.  But negotiating packet size, rate, or other features may be
relevant.

  Any issue of security negotiation would best be left for a later
draft, which specifies that negotiation.  This draft just tries to set
the framework for the negotiation process.

  Alan DeKok.

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 10 Feb 2013 15:41:45 -0600

It was suggested at one time that the fragmentation could be one of the
items negotiated, from what you state below I would assume that you would
generally disagree with this as this is an end-to-end capability and not a
single hop capability in general. 

Jim

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]]
> Sent: Sunday, February 10, 2013 3:36 PM
> To: Jim Schaad
> Cc: [email-masked];
> [email-masked]
> Subject: Re: [radext] Comments on draft-halwasia-radext-capability-
> negotiation-00
> 
> Jim Schaad wrote:
> > I find it very difficult to begin to evaluate how this draft really
> > works if it is missing the section on RADIUS Proxy Behavior.  Proxies
> > are going to have different answers if they do not support this feature,
and
> if they do.
> > Proxies will also have different answers based on how they support or
> > don't support, but can ask the next proxy in line for an answer.
> 
> > Proxies may end up with different answers based on the routing of a
> > message that it obtains.  Thus talking to the same server, but over a
> > different route may come up with a different answer.
> 
capabilities
> of *all* hops, along with a "name" for the home server.
> 
>   For now, that's an area of discussion.  This draft fills a need for NAS
to local
> server negotiation.  Anything past that is unknown.
> 
> > recieveing different answers for capabilities.  For example, if one
> > asks about a security capability there is the possibility of a down
> > grade attack from any proxy in the system and possibly from people
> > outside of the proxy net based on the routing of messages.
> 
occur.
> The attacks left are then in-network downgrade attacks.  I'd largely
attribute
> those to misconfiguration instead of malice.
> 
>   I would view this draft as negotiating RADIUS capabilities, not security
ones.
> e.g. negotiating TLS to a home server may be out of scope.  But
negotiating
> packet size, rate, or other features may be relevant.
> 
>   Any issue of security negotiation would best be left for a later draft,
which
> specifies that negotiation.  This draft just tries to set the framework
for the
> negotiation process.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 10 Feb 2013 16:50:48 -0500

> single hop capability in general. 

  Right now, capabilities are single hop.  The draft is relatively
simple, and easy to implement.

  In theory, they could be multi-hop.  I'm not sure what that would look
like.  Specifying that would require much discussion.  There are a
number of open issues and undefined concepts.

  Alan DeKok.