[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
open issues of draft-ietf-radext-digest-auth-00
Issue 3
can't see what is missing in draft-ietf-digest-auth-00
Issue 5
3- replaced type String with Text were diameter-sip-app expects UTF-8
values
4- see Section 2.18
5- added indication where (not) to use quotes
6- Section "RADIUS Client Behaviour" now explain which
Authorization header a RADIUS client has to choose
7- removed the 32 octet limit in relevant attributes
8- mixing of nonce generation modes is no longer allowed, see last
paragraph of section "Overview"
9,10- removed the text about rejection of unsupported attributes
11- draft now requiers one Digest-Qop attribute per qop token
the reference to diameter-sip-app was moved to "Informative References"
Issue 6
To be honest, I did not find an RfC that describes how to
encrypt individual RADIUS attributes other than User-Password
and Tunnel-Password.
Issue 7
My interpretation of the list discussion was that the consensus was to make
the Message-Authenticator mandatory. I'll copy the relevant parts
of section 3.1 and 3.2 of RfC3579, as Bernard proposed.
I don't think that integrity protection of Access-Requests is really
a big issue. Carrying HTTP Digest over unprotected RADIUS can't be
worse than carrying it over unprotected HTTP or SIP. Digest-HA1 is the only
exception, because a MITM can 'sign' arbitrary HTTP-style responses.
Here is a proposal:
- Message-Authenticator is optional
- Digest-HA1 MUST be encrypted like User-Password, using a shared key.
That means, Digest-HA1 can be used with MD5, AKAv1-MD5; reliance
on IPSec is no longer needed (the requirement remains with sips /
https where all attributes would have to be encrypted).
Issue 11
To Jari: what is missing ?
Issue 30
To Jari: what is missing ?
Wolfgang
--
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/>