Re: [radext] Review comments for draft-ietf-radext-dynamic-discovery-08

[Stefan Winter <[e-mail]>]

Hi,

> > I guess we should take another close look at the *exact* bytes of
> this ASN.1 definition after the next rev...
> The process of getting OIDs assigned is being changed.  I will create a new
> module and IANA section to deal with this and send it to you by the end of
> the week.

Which week was that? ;-)

>>> 12.  Section 3.1 - Not sure that I understand the reasoning for item b.
>> Routing of DynAuth packets is asynchronous to that of authentication
>> requests; and the DynAuth Server which can handle DynAuth packets could
>> be different from the authentication server in that domain.
>>
>> So, both need to be configurable and be discovered independently. They
>> both take an input in form of a domain name though, so by using two
>> different service tags, they can both use the same algorithm to discover
> their
>> respective targets:
>>
>> a) to discover RADIUS servers which can authenticate users
>>
>> b) to discover DynAuth servers for a domain which can receive DynAuth
>> packets to alter user sessions.
>>
>> Should I maybe reference RFC5176 for clarity regarding b) ? I do in the
> service
>> tag table, but a little more verbosity here may not hurt. Please let me
> know.
> It would seem to me that this should then be the case of accounting as well.
> It might be better to say that it needs to be unique for each service and
> then state that new conversations would be needed for each service.  Is
> DynAuth always a single round trip?

I have added a sentence about the "for each service", and added
Accounting as an item in its own right.

To my knowledge, DynAuth is always just one round-trip, yes.

Of course authorization for a session might change multiple times during
the session lifetime; and arguably only the first packet should need
dynamic discovery - the DynAuth client could memorize the discovery
result for subsequent authorization changes.

I've added a note to that effect as well.

>>> 13.  In Section 3.4.3  step 13 - should the 'or' be 'and/or' as it
>>> would seem that one could do a lookup for both _tcp and _udp if
>>> desired.  An input or output to the algorithm may need to be if udp or
>>> tcp is the desired mechanism to use.  (I don't see a comparable
>>> selection in the NAPTR
>>> processing.)
>> Yes; it's a non-exclusive OR. It depends on the capabilities of the RADIUS
>> client which executes the algorithm... if it only implements TCP/TLS, it
> would
>> only query for _tcp; if it supports both, it could try both labels (which
> one it
>> prefers is out of scope though).
>>
>> NAPTR doesn't need this decision point - the NAPTR RR authoritatively
> tells
>> the querying entity which variant to try in which order.
> That makes sense.  However the question does arise if the mechanism then
> needs to be an output.
>
> tuples {hostname; port; protocol; order/preference; Effective TTL}

Good point: I've added "protocol" as one element of the output tuple in -10.

>>> 14.  In section 4 paragraph 1/2 - It is not clear to me if these
>>> paragraphs are saying that DNS is required.  If this is not the case
>>> then you should be more explicit about what being trusted means for an
>>> output.  From the "even if" sentence it would appear nothing.
>> DNS - trust neither the resulting IP/port nor infer authorisation DNSSEC -
>> trust the IP/port, but still don't inter authorisation
>>
>> (So, use DNSSEC or not, you still have to do extra work afterwards)
>>
>> Actually, the section would read more clearly if I'd simply remove the
> first
>> para - it's redundant because the first sentence of para 2 says it all.
>>
>> I've removed the first para, does this clear up the ambiguity?
> Yes that does make it better
>
>>> 15.  In section 5 - I am having a problem with the fact that you are
>>> saying that big clearing houses are no longer a problem.  On the
>>> mailing list you have explicitly stated that this is still a standard
>>> configuration that will exist.  It is also going to be unknown to
>>> either the user and to operators if a clearing house is being used.
>> I don't think I'm saying that they are not a problem any more. The section
>> states that discovery can technically make them obsolete if the operators
> in a
>> consortium really want that.
>>
>> There may be reasons unrelated to discovery which make them not want
>> that. That's a pity, but nothing this draft can help with (and the second
> bullet
>> makes clear that proxies are likely to remain in existence).
>>
>> Packet inspection by all kinds of intermediates is big topic these days,
> and I'm
>> all for eliminating such snooping points. The TLS part does its share, IP
> nodes
>> can't read stuff any more; the discovery part can do its part by taking
> away 0
>> or more intermediate RADIUS proxies.
>>
>> This doesn't solve all problems in the space; including that the existence
> of a
>> proxy or not is not known to the end user. It also doesn't tehcnically
>> eliminate the possibility to deploy proxies at all.
>>
>> If you are looking for that, we're talking of a different draft (but that
> is such a
>> complex problem that I have no idea what to write into that one ;-) )
> I still find this paragraph somewhat confusing.  How about:
>
> This protocol allows for RADIUS clients to identify and directly connect to
> the RADIUS home server.  This can eliminate the use of clearinghouses to do
> forwarding of requests, it also eliminates the ability of the clearinghouse
> to then aggregate the user information that flows through it.  However,
> there exist reasons why clearinghouses might still be used.  One reason to
> keep a clearinghouse is to act as a gateway for multiple backends in a
> company.

Ok, if that's clearer, fine :-) I've replaced my paragraph with your
suggestion.

> - I would rather talk about your issue in Eduroam as the reason as that is
> probably more interesting, but I don't remember the details anymore.

One big reason to have an intermediate system is for sanitisation of
requests. With that I mean: filter out "dangerous" attribues (e.g. a
VLAN assignment attribute sent from an IdP very likely does not make
sense in a roaming scenario - of course we expect IdPs to exercise
hygiene themselves and not send those attributes, but mistakes do
happen) or adding tagging attributes (e.g. if the SP did not indicate
it's real-world name in Operator-Name, its next-hop proxy can do that
for him (again, of course SPs should do this themselves, but not
everyone can be bothered to).

I've added a half sentence in the end of that para to give a hint that
filtering and tagging are useful things a proxy may have to do.

Another round of thanks for this subsequent review. This certainly makes
the document better!

Greetings,

Stefan
 
>
>
> Jim
>
>> And this concludes my actions on your review. Phew!
>>
>> I'm planning to publish a roundup -09 on Friday. If you have comments
>> before that, I'll try to get them in, if not, it's either a -10 or maybe
> IETF LC (as I
>> hope we are now nearing zero bugs :-) ).
>>
>> Greetings,
>>
>> Stefan Winter
>>
>> --
>> Stefan WINTER
>> Ingenieur de Recherche
>> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de
>> la Recherche 6, rue Richard Coudenhove-Kalergi
>> L-1359 Luxembourg
>>
>> Tel: [phone]
>> Fax: [phone]
>>
>> PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
> recipient's key
>> is known to me
>>
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC6
>> 6
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext