Re: [radext] Fwd: RE: non-opsdir review of draft-ietf-radext-dynamic-discovery

[Stefan Winter <[e-mail]>]

Hi,

>> Well, one document has, it's the reference [I-D.ietf-radext-nai] "The
>> Network Access Identifier" (which is normative).
> 
> Ah, you're right. I looked for references to terminology in the terminology
> section.
> It would be helpful to list, in the terminology section, which terms are
> used and which references define the terms.
> Something like "[draft-nai] defines the following terminology related to
> identifiers: nai, realm, consortium"
> That way readers don't need to hunt through all your normative references to
> find the definitions.
> I would not have necessarily thought to read a work-in-progress draft on NAI
> to find the term realm.

Okay, that's easy enough to fix :-) I've added that note to my working copy.

> Keep in mind you are trying to get people to buy into your proposal; if you
> make it hard to read and understand, readers will just walk away.
>>
>> Many would think that referencing RFC4282 would be most natural when
>> talking about realms, as it is the current RFC on that topic. However,
>> it has many acknowledged errors, and [I-D.ietf-radext-nai] is an
>> attempts to fix them; so I'd rather point to current work instead, and
>> accept that our document gets delayed by a pending normative reference.
> 
> It might be useful to point to both and include an explanation of why you
> include the I-D.
> That way, anybody reviewing the draft (including potential implementers and
> IESG) will benefit from this additional information.
> When the ID becomes an RFC, you can change the reference.

Okay, adding RFC4282 with a note that it's soon-to-be-obsolete by
draft-nai (in Terminolofy section)

> So now that I better understand the purpose of realms, isn't the Diameter
> standard designed to handle collaborating entities for authentication?
> (obviously, not being a RADIUS, expert, neither am I a Diameter expert.)

That's correct; Diameter has this functionality "built-in" while for
RADIUS it's a retrofit.

This also relates to one of your points below: this whole mechanism is
much less experimental than the document track Experimental might suggest.

If you take a look at the Diameter counterpart, it's way less thoroughly
described; much more thought on the exact details on DNS usage for
discovery has gone into this radext draft. And yet, the Diameter one is
standards-track; while this one is "experimental".

>> This is a document where global interop is not a requirement. A roaming
>> agreement requires much more than technical discoverability; there's
>> paperwork attached to it. Service contracts, backoffice compensations,
>> procedures, ...
>>
>> So long as one consortium can settle on one deployment option, they will
>> be able to interoperate based on that choice; this is the scope we're
>> looking at here.
>>
>> The service contract for the consortium would nail down which CAs are
>> trustworthy anchors; which properties a certificate needs to have, etc.
>>
> 
> I suggest you include a "Operations and Manageability Considerations"
> section, and explain the expected applicability.
> Your explanation here would be useful to other reviewers.

Yes, that's a reasonable point. I'll add such a section.

Here is the current text:

"4.  Operations and Manageability Considerations

   The discovery algorithm as defined in this document contains several
   options; the major ones being use of NAPTR vs. SRV; how to determine
   the authorization status of a contacted server for a given realm;
   which trust anchors to consider trustworthy for the RADIUS
   conversation setup.

   Random parties which do not agree on the same set of options may not
   be able to interoperate.  However, such a global interoperability is
   not intended by this document.

   Discovery as per this document becomes important inside a roaming
   consortium, which has set up roaming agreements with the other
   partners.  Such roaming agreements require much more than a technical
   means of server discovery; there are administrative and contractual
   considerations at play (service contracts, backoffice compensations,
   procedures, ...).

   A roaming consortium's roaming agreement must include a profile of
   which choice points of this document to use.  So long as the roaming
   consortium can settle on one deployment profile, they will be able to
   interoperate based on that choice; this per-consortium
   interoperability is the intended scope of this document."

> You are, however, asking IANA to register assignments.
> And I think you are using non-experimental registries.
> And those assignments are not likely to be unassigned at the end of the
> experiment.
> 
> This raises an additional point.
> When I was on the IESG, there was a push (by people still on the IESG) to
> require that experimental RFCs:
> 1) clearly state that the proposal is a proposed experiment,
> 2) explain what communities are expected to participate in the experiment,
> 3) explain the expected duration of the experiment,
> 4) describe the expected information to be gathered form the experiment,
> 5) describe "success" factors for the experiment,
> 
> There might be an RFC that more definitively states those (and possibly
> other) requirements. Check with your AD.

right; for RFC6614 I had included such information in a subsection
"Document Status". I'll write up the same for this draft.

The current text is:

"1.3.  Document Status

   This document is an Experimental RFC.

   The communities expected to use this document are roaming consortia
   whose authentication services are based on the RADIUS protocol.

   The duration of the experiment is undetermined; as soon as enough
   experience is collected on the choice points mentioned below, it is
   expected to be obsoleted by a standards-track version of the protocol
   which trims down the choice points.

   If that removal of choice points obsoletes tags or service names as
   defined in this document and allocated by IANA, these items will be
   returned to IANA as per the provisions in [RFC6335].

   The document provides a discovery mechanism for RADIUS which is very
   similar to the approach that is taken with the Diameter protocol
   [RFC6733].  As such, the basic approach (using NAPTR records in DNS
   domains which match NAI realms) is not of very experimental nature.

   However, the document offers a few choice points and extensions which
   go beyond the provisions for Diameter.  The list of major additions/
   deviations is

   o  a fallback mechanism using SRV records, should no matching NAPTR
      records be found (not defined for Diameter)

   o  Provisions for determining the authority of a server to act for
      users of a realm (declared out of scope for Diameter)

   o  much more in-depth guidance on DNS regarding timeouts, failure
      conditions, alteration of TTLs (not considered for Diameter)

   o  a partially correct routing error detection (not considered for
      Diameter)"

RFC6335 speaks of special considerations only for experimental ports,
not service names. Do service names have an experimental space? I don't
see that in RFC2782.

A STD-track update could also return assignments to IANA. RFC6335 has a
process for that.

> Radius/tls and radius/dtls are actually defined in documents other than this
> one.

As protocols, yes; but their static-config deployment does not need
service names for use in DNS. So the other documents don't discuss that.

> THIS document is about radius discovery using a specific approach and
> algorithms, for specific environments.
> This document is also experimental, and might never be published as an RFC.
> So it concerns me to have radiustls and radiusdtls names reserved by this
> document.

If the document doesn't get published as an RFC, IANA will not make the
assignment, so I don't know if that's really a significant issue.

I would also not say the document is for specific environments; it's
useful for everyone doing dynamic discovery in any roaming consortium -
the deployment only needs to be profiled to a specific roaming
consortium's setup.

This is in a way comparable to the applicability of PKI - it is of
generic usefulness in many contexts, but each of those contexts makes
its own independent choice regarding deployment properties of a PKI
(e.g. browsers have a different security model than VPN dial-in
deployments in an enterprise; but they all use the PKI standards).

> Might it be a good idea to separate this draft into two drafts?
> 	1) A standards-track document for registering RADIUS services in
> DNS, a simple DNS discovery of radiustls and radiusdtls servers,
> 	2) An experimental draft for explaining how to go further to
> discover realms, especially in the case of roaming consortia?
> I'm not quite sure where one thing ends and the other starts.

At least in my mind, these go together so closely that separating them
does not make much sense. E.g. one doesn't discover a RADIUS server on
its own for the sake of discovering; it's discovered for a reason,
namely authenticating someone. And that's where the realm immediately
comes in.

> One nit that I noticed in my initial review.
> You use an example of very.bad.example
> While cute, I did not understand whether this was simply cuteness in names,
> or actually implying that this particular example was an example of a very
> bad practice. I finally decided it was just cuteness, but ambiguity is not a
> good thing in standards-related documents ;-)
> I expect you could find better examples.

Umm... it's a leftover from an early rev of my individual submission, I
believe. I can just as well give it a generic name; there's no
particular reason for it.

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