RADIUS/DTLS and RADIUS crypto-agility requirements

[Bernard Aboba <bernard_aboba@hotmail.com>]

Comments below (see [BA]). 

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.

[BA] What TLS ciphersuites would be mandatory to implement?  AES-CBC/SHA-1? 

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.

[BA] Is there a more automatic method available?  Having to configure
each NAS for DTLS support yes/no seems like a management burden, 
particularly if we end up with several crypto-agility solutions. 

At IETF 68 we discussed potential attacks on "up-negotiation",
where an initial (non-DTLS) RADIUS packet is sent, then RADIUS/DTLS
is negotiated.  If the RADIUS shared secret on the initial RADIUS
Request is cracked, then the attacker can create a bogus response that
would impersonate the RADIUS server, implying to the client that DTLS
is not supported.  Thus, an unprotected session proceeds even though
a RADIUS/DTLS session would be possible.

As I recall, the solution to this was to use a separate port number
for RADIUS/DTLS, rather than up-negotiating.  Is the idea to use
DNS SRV to determine if a given server supports DTLS or not, and if so,
does this imply a requirement for DNSSEC?

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.

[BA] Does RADIUS/DTLS require a separate port for both conventional and
RFC 3576 RADIUS exchanges?

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.

[BA]  What kind of state is required, and at what granularity?

  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.