The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Aaron Wyatt <aaron.wyatt AT bc.edu>]

Tomasz-

Thanks for the quick reply. 

It seems to be a much healthier approach to provide the server cert and all
intermediates on the server side, but ship the root.

For clarity, did you mean to say "...skip the root"?

_________________________
Aaron Wyatt
Collaborative Services

Boston College IT Services
aaron.wyatt AT bc.edu
617.552.1278
_________________________

On Tue, Jan 17, 2017 at 2:37 PM, Tomasz Wolniewicz <twoln AT umk.pl> wrote:

Hi Aaron,


W dniu 17.01.2017 o 19:21, aaron.wyatt AT bc.edu pisze:
> Hi All-
>
> We recently obtained a new RADIUS certificate and so I am in the process of
> rebuilding the CAT configuration for our organization.  Running through the
> static connectivity tests, we pass without issue, but there are two pieces of
> feedback I get:
>
>   (1) This realm has no NAPTR records.
>   (2) The certificate chain includes the root CA certificate. This does not
> serve any useful purpose but inflates the packet exchange, possibly leading to
> more round-trips and thus slower authentication.
>
> Regarding #1, a quick google search tells me that NAPTR records are commonly
> used for SIP and other telephony protocols.  What role do they plan in the
> RADIUS world?
They are used for the so-called dynamic discovery. You may read more
about it in
section 4.2 of RFC 7593 https://tools.ietf.org/html/rfc7593#section-4.2
Connectivity checks test if the realm is configured for dynamic
discovery, if it was more tests would be run.
>
> Regarding #2, this makes sense to me but I had never heard it explained
> before.  Does this mean I don't need any of my chain in the RADIUS certificate
> used for CAT?  Does this also mean I don't need to provide the entire chain
> when I install the certificate on my RADIUS servers?  i.e. I don't need to
> present the entire chain to clients attempting to authenticate?
The root certificate is the anchor of the whole trust, therefore it
needs to be known to the client in advance so that it can use it to
verify the server chain.
Obviously verifying the server certificate against the root that the
server provides by itself would be pointless.
If every of your client devices had all intermediates installed then, in
principle they should be able to verify the server certificate even if
nothing else was sent, but this would mean that you would need to update
the intermediates on the clients if one of them was changed. It seems to
be a much healthier approach to provide the server cert and all
intermediates on the server side, but ship the root.

It would seem to be a contradiction to the above, that CAT installers
allow for intermediates loading and installation on the clients (as this
would seem an overkill), unfortunately we have observed that some
clients had a problem using the wireless profile unless the
intermediates were also local. This is why we suggest the safest
strategy to put the intermediates on both sides.
Tomasz

>
> Any insights would be much appreciated.
>
> Aaron
> Boston College
> To unsubscribe, send this message: mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
> Or use the following link: https://lists.geant.org/sympa/sigrequest/cat-users

--
Tomasz Wolniewicz
          twoln AT umk.pl        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne       Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika         Nicolaus Copernicus University,
pl. Rapackiego 1, Torun                pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576