Subject: Re: [abfab] [radext] Adoption call for draft-perez-radext-radius-fragmentation-05

From: Alan DeKok <[email-masked]>
Date: Fri, 08 Mar 2013 09:54:57 -0500

Jouni Korhonen wrote:
> It seems the document as such still needs more work to be
> acceptable as a WG item. We will have time for a discussion
> around the fragmentation in Orlando meeting agenda and see
> then where to head to.

  After much discussion in the past week, the fragmentation draft
authors have decided to change the draft, and re-issue it under a new
name.  The name change reflects a change in focus which we hope makes
fragmentation easier to understand.

  The net result is the same, but the underlying theory is different.
I'll give a short explanation here.

  The first goal is to work with existing RADIUS proxies.  This goal is
satisfied by using Access-Request / Access-Accept.  A User-Name is
included in the Access-Request, so that existing proxies can forward the
packets.

  The second goal is to do this *only* for authorization.  There is no
need to support "large data" for CoA, Accounting, etc.  This goal is
satisfied by using Access-Request / Access-Accept.

  The third goal is to not change existing authentication methods or
packet flows.  This goal is new, and results in the name change.  We are
no longer fragmenting "access requests", we are exchanging large amounts
of authorization data.

  The third goal is satisfied by exchanging *references* to the
authorization data in the Access-Request and Access-Accept.  These
references satisfy the requirements of RFC 6158, as pointed out by Bernard.

  The problem we're solving then becomes "how to dynamically provision
authorization data".  When defined that way, the discussion becomes
simpler.  The exchange of this data no longer affects existing
authentication methods.

  The exchange of large data happens pretty much as discussed in the
current draft.  There are technical details, of course.  These details
again become simpler when they don't affect existing methods.

  The resulting exchange is then done in three steps.

1. send pre-authentication authorization data NAS to Server.

2. authentication (as is done now)

3. send post-authentication authorization data Server to NAS.

  Step (1) finishes with a token which is used in the Access-Request for
step (2).  Step (2) finishes with a token in the Access-Accept, which
refers to step (3).

  Either or both of steps (1) and (2) can be omitted.  If the
authorization data is small enough, it can just be put into packets for
step (2).

  I hope that this explanation is clear, and satisfies the concerns
raised here.  We hope to have an updated draft ready by next week.

  Alan DeKok.