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

From: Stefan Winter <[email-masked]>
Date: Thu, 13 Feb 2014 18:26:47 +0100

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: +352 424409 1
>> Fax: +352 422473
>>
>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 14 Feb 2014 11:00:32 -0800

It turned out that there were some missing pieces. These are now in place.

IANA Considerations:

This document requires that  a number of Object Identifiers be assigned.
They re now under the control of IANA following [I-D.housley-pkix-oids].

IANA is requested to assign the following identifiers:

* TBD99 is to be assigned from the "SMI Security for PKIX Module Identifier
Registry".  The suggested description is id-mod-nai-realm-08.

* TBD98 is to be assigned from the "SMI Security for PKIX Other Name Forms
Registry."  The suggested description is id-on-nai.

New ASN.1 Module

PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6)
     internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
     id-mod-nai-realm-08 (TBD99) }

 DEFINITIONS EXPLICIT TAGS ::=

 BEGIN

 -- EXPORTS ALL --

 IMPORTS

    id-pkix
    FROM PKIX1Explicit-2009
        {iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-pkix1-explicit-02(51)}
           -- from RFC 5280, RFC 5912

    OTHER-NAME
    FROM PKIX1Implicit-2009
       {iso(1) identified-organization(3) dod(6) internet(1) security(5)
       mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
             -- from RFC 5280, RFC 5912
 ;

 -- Service Name Object Identifier

 id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }

 id-on-nai OBJECT IDENTIFIER ::= { id-on TBD98 }

 -- Service Name

 naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-nai }}

 NAIRealm ::= UTF8String (SIZE (1..MAX))

 END

---

From: Stefan Winter <[email-masked]>
Date: Mon, 17 Feb 2014 10:33:58 +0100

Hi,

good stuff, added all that to my working copy!

Thanks,

Stefan

-- 
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: +352 424409 1
Fax: +352 422473

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=0xC0DE6A358A39DC66