[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-sterman-aaa-sip-03
Attached are some review comments on draft-sterman-aaa-sip-03.
Document should start with an overview of the assumed architecture, as
shown in e.g. Figure 1 of Section 1.3. However, the text of Section
1.3 dives into a particular scenario and a broader overview is
necessary first. (I think Miguel made this comment earlier)
Section 1.2 (although I think this text should be deleted):
lacking support, too: even two years
lacking support, too; even two years
SIP service providers whishing
SIP service providers wishing
Section 1.4 describes an mechanism
Section 1.4 describes a mechanism
some cases the RADIUS server is better off with pre-computed hashes.
Section 1.4 describes an mechanism that enables this style of
This paragraph mentions "precomputed hashes" but then the issue is never
revisited. Is it true that precomputed hashes can be used with arbitrary
message contents, or is some other coordination required between the
home RADIUS server and the client?
Reformat list of attributes into a table, and use values like "TBD-DIG-RES"
in the table. Create an IANA considerations section which requests allocations.
Don't use text like "if this specification becomes a working group or IESG
Get rid of " Early implementations have used the experimental type
The following is confusing:
3.1 RADIUS Client Behaviour
A RADIUS client without an encrypted or otherwise secured connection
to its RADIUS server only accepts unsecured connections from its
HTTP-style clients (or else the clients would have a false sense of
It is not quite clear what is meant by "encrypted or otherwise
secured", because there are several different security mechanisms
available in RADIUS, including the hop-by-hop message authenticator
and the shared-key method of obfuscating individual attributes. I
assume this would not be adequate to provide the protection you are
looking for. Also, what counts as an "unsecured connection" from an
HTTP-style client? Do you mean one that doesn't use either TLS or
IPSec? Maybe this paragraph is adequately covered by the security
considerations (or should be) and could be deleted.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.