[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson
> Sent: Wednesday, October 15, 2008 10:44 AM
> To: radiusext@ops.ietf.org
> Subject: RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility
> Requirements for RADIUS"
>
> Following up...
>
> > It comes down to the RADIUS client advertising what it can
> support, by
> > means of hint attributes included in the Access-Request packet, and
> > the RADIUS server picking at most one of the options.
>
> So, it is apparent that use of encrypted packet payloads
> (either the entire PDU or per attribute) cannot succeed until
> the cipher-suite is selected and the client and server find
> that they share the required keys. Without getting into
> *design* of a solution, it seems feasible to me that the
> client could "discover" the existence a cipher-suite and keys
> shared in common with the server, without exposing any
> sensitive information using "classic"
> RADIUS exchanges, by simply using a device such as the
> Call-Check mechanism, to complete an Access-Request /
> Access-Accept (or Access-Reject) sequence without disclosing
> any end user credentials.
>
[Joe] Yes, this would be possible, I think it would involve defining the
behavior in this type of error condition and the associated signaling.
It wouldn't necessarily be too hard, but it would be additional
messaging.
>
>
> --
> 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/>
>
--
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/>