Re: RADIUS Crypto-Agility work item

[Alan DeKok <aland@nitros9.org>]

David B. Nelson wrote:
> In preparation for the RADEXT session at the IETF 69 meeting later this
> month, I'd like to ask the authors of drafts submitted for WG consideration
> as potential WG drafts in this area, to review the requirements we had
> agreed upon, and submit, to this mailing list, a brief write-up to of how
> their submissions address each of the items in the requirements description.

2. Negotiation & confidentiality
 --> satisfied by the TLS negotiation mechanisms.
   Encryption of existing attributes
 --> satisfied by TLS

3. Proposals MUST support replay protection.  The existing mechanisms
for replay protection are considered adequate and should be maintained.
  --> satisifed by TLS replay protection

4. Crypto-agility solutions MUST specify mandatory-to-implement
algorithms for each mechanism.
  --> not specified in the -00 draft, but can be specified
      easily, as is done with other protocols leveraging TLS.

5. Solutions to the problem MUST demonstrate backward compatibility
with existing RADIUS implementations.
  --> satisfied by not using TLS for a particular client.
      This can be configured as a per-client item

6. Bidding down attacks
  --> clients can be configured as TLS-only, or legacy RADIUS
      No bidding down attack can occur if the server requires TLS.
      No bidding down attack can occur if the client requires TLS.

  i.e. Bidding down attacks can occur only when neither client nor
server knows the capability of the other before they communicate.  Since
the same shared secret has to be configured on both already for RADIUS,
the information about capabilities is available at the same time, and
can be used.

7. Proposals MUST indicate a willingness to cede change control to
the IETF.
  --> Yes.

8. Crypto-agility solutions MUST be interoperable between independent
implementations based purely on the information provided in the
specification.
  --> There are already DTLS implementations.  Simplistically, this
      proposal is simply "DTLS + RADIUS".

9. Crypto-agility solutions MUST apply to all RADIUS packet types,
including Access-Request, Challenge, Reject & Accept,
Accounting-Request/Response, and CoA/Disconnect messages.
  --> DTLS is just a wrapper around RADIUS.  It is agnostic towards
      RADIUS messages.

10. Proposals MUST include a Diameter compatibility section, although
it is expected that the work will occur purely within RADIUS or in the
transport, and therefore does not affect message data that is exchanged
with Diameter.
  --> in draft-00.

11. Crypto-agility solutions SHOULD NOT require fundamental changes to
The RADIUS operational model, such as the introduction of new commands
Or maintenance of state on the RADIUS server.
  --> No new commands.
  "issues & fixes" already mandates state on the RADIUS server.  When
RADIUS servers include EAP, they already maintain state for TLS sessions.

  My $0.02 here is that we should just give up on the idea of RADIUS
being a stateless protocol.  Server implementations have been
maintaining state for a decade.  Recent discussions about rfc3576bis
indicate that the most obvious way to implement reverse proxying is by
maintaining massive amounts of state on the RADIUS server.  (More than
would be required here.)

11a.  Similarly, a proposal
Should focus on the crypto-agility problem and nothing else.  For
example, proposals should not require new attribute formats or include
definition of new RADIUS services.
  --> Yes.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>