Subject: [abfab] Direction Forward for aaa-saml

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jul 2015 05:56:18 -0400

Leif, I wanted to write up my understanding of our proposed direction
forward, just in case things take longer than we anticipate  to
implement.

During the meeting  Monday we discussed Alejandro's proposal.

He proposes adding two new role descriptor subtypes: Radiusidpdescriptor
and Radiusrpdescriptor.
That seems great.

He proposes adding a RadiusIdpService and RadiusRpService of
EndpointType as well.

In the meeting we discussed that we really aren't specifying an
edpoint.  In particular, the location of the service is implicit in this
RADIUS binding.  It's possible we might describe something in the future
where we included radsec endpoints and keys in metadata, but that's not
what we need now.

However we also discovered that a role descriptor doesn't actually need
any EndpointType subclasses.  So, instead, Alejandro will create a
different extension to rolldescriptor to include the naming information
we need.

This will allow us to avoid registering an unresolvable URI to describe
the security name of a RADIUS entity.

Have I accurately summarized what we discussed?
If so, I'd like to solicit any comments from the list.

--Sam

---

From: Leif Johansson <[email-masked]>
Date: Wed, 22 Jul 2015 12:09:44 +0200

> 22 jul 2015 kl. 11:56 skrev Sam Hartman <[email-masked]>:
> 

agree but it may be cheap/easy to include that upfront

not critical though

> If so, I'd like to solicit any comments from the list.

matches my recollection

> --Sam
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jul 2015 06:14:48 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    >> edpoint.  In particular, the location of the service is implicit
    >> in this RADIUS binding.  It's possible we might describe
    >> something in the future where we included radsec endpoints and
    >> keys in metadata, but that's not what we need now.

    Leif> agree but it may be cheap/easy to include that upfront

Doing the metadata specification would be cheap/easy.
Describing semantics would I suspect be more difficult.
We'd have to treat RADIUS as much less of a black box than we've done so
far.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 22 Jul 2015 14:44:53 +0200

> Describing semantics would I suspect be more difficult.

maybe... but lets think about it/try

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jul 2015 09:07:49 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> 22 jul 2015 kl. 12:14 skrev Sam Hartman
    Leif> <[email-masked]>:

    >>>> edpoint.  In particular, the location of the service is
    >>>> implicit in this RADIUS binding.  It's possible we might
    >>>> describe something in the future where we included radsec
    >>>> endpoints and keys in metadata, but that's not what we need
    >>>> now.
    >> 
    >> 
    >> Doing the metadata specification would be cheap/easy.  Describing
    >> semantics would I suspect be more difficult.

    Leif> maybe... but lets think about it/try

I'm happy to review suggested text.

I think you'd need to:

1) Explain how I figure out which entity I'm using for my RADIUS server

2) Explain how I validate the RADIUS server I'm talking to

3) Explain how the RADIUS server I'm talking to validates me.

Consider this especially in a case where you're retrieving metadata
dynamically rather than just having all the metadata in the world.

--Sam

---

From: Alejandro Pérez Méndez <[email-masked]>
Date: Wed, 22 Jul 2015 15:42:41 +0200

Hi Sam,

that's exactly what I extracted from the discussion in the session, thanks.

Regards,
Alejandro

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 22 Jul 2015 14:25:03 +0000

>1) Explain how I figure out which entity I'm using for my RADIUS server

If by "entity" you mean SAML metadata entity, you have to do that regardless if you do anything with metadata, that's the basis of the design. You don't have to necessarily be able to map directly from a PDU to an entity via an explicit "issuer" notion in a protocol, but it sure helps.

>dynamically rather than just having all the metadata in the world.

That's orthogonal to any use of SAML metadata. How you get it (and verify it) is architecturally distinct from what it means and how it's used.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jul 2015 10:41:46 -0400

>>>>> "Cantor," == Cantor, Scott <[email-masked]> writes:

    Cantor,> On 7/22/15, 9:07 AM, "abfab on behalf of Sam Hartman"
    Cantor,> <[email-masked] on behalf of
    Cantor,> [email-masked]>

    >> Consider this especially in a case where you're retrieving
    >> metadata dynamically rather than just having all the metadata in
    >> the world.

    Cantor,> That's orthogonal to any use of SAML metadata. How you get
    Cantor,> it (and verify it) is architecturally distinct from what it
    Cantor,> means and how it's used.

Not really.
If I'm starting with  an NAI realm and would like to find the entity
description of an entity that is at that NAI realm, I can only do that
if my metadata access mechanism lets me search by that.

However I do agree that this problem is general to the case where you're
using SAML naming rather than AAA naming, not just to the case where
you're getting protocol endpoints from metadata.

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 22 Jul 2015 14:57:37 +0000

>if my metadata access mechanism lets me search by that.

Even if you had all the metadata in the world, you'd still have to index it and search by something other than entityID.

I don't really know what an NAI realm is, but if it's anything like a domain, there's a pretty long-standing issue that there's never been a way to map domains to SAML metadata since putting things in DNS was always off the table (thanks to the joy of working with DNS admins). It's been a general assumption of mine that at some point that would need to change to address discovery in a world where you can't just load giant lists of IdPs. So perhaps there's a general here that can finally be tackled.

-- Scott

---

From: Leif Johansson <[email-masked]>
Date: Wed, 22 Jul 2015 17:00:00 +0200

> if my metadata access mechanism lets me search by that.

so its a requirement for the mdquery draft, not on metadata

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jul 2015 11:12:39 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> 22 jul 2015 kl. 16:41 skrev Sam Hartman
    Leif> <[email-masked]>:

    >> Cantor,> <[email-masked] on behalf of Cantor,>
    >> [email-masked]>
    >> Cantor,> wrote:
    >> 
    >> 
    >>>> 
    >>>> I think you'd need to:
    >>>> 
    >>>> metadata dynamically rather than just having all the metadata
    >>>> in the world.
    >> 
    >> Cantor,> That's orthogonal to any use of SAML metadata. How you
    >> get Cantor,> it (and verify it) is architecturally distinct from
    >> what it Cantor,> means and how it's used.
    >> 
    >> Not really.  If I'm starting with an NAI realm and would like to
    >> find the entity description of an entity that is at that NAI
    >> realm, I can only do that if my metadata access mechanism lets me
    >> search by that.

    Leif> so its a requirement for the mdquery draft, not on metadata

Nod.

I don't anticipate implementing using metadata  to select a RADIUS
endpoint.
So I don't have a lot of interest in working on that.  I'm happy to
review a specific proposal someone comes up with, but I'd prefer it not
end up in aaa-saml and I'd strongly prefer it not block aaa-saml.

--Sam

---

From: Leif Johansson <[email-masked]>
Date: Wed, 22 Jul 2015 17:14:39 +0200

> end up in aaa-saml and I'd strongly prefer it not block aaa-saml.

agree but i think endpoint could be useful for radsec and i suspect it will be reasonably simple to do

---

From: Alejandro Pérez Méndez <[email-masked]>
Date: Wed, 22 Jul 2015 18:12:19 +0200

> agree but i think endpoint could be useful for radsec and i suspect it will be reasonably simple to do

I might be mistaken, but wasn't that what we wanted to avoid in the 
first place when we decided not to use the RADIUS URI scheme from my 
original proposal?
I guess having an endpoint for radsec will require to define how the 
"Location" values will look like, and they should be in a URI format as 
well.

Regards,
Alejandro

---

From: Leif Johansson <[email-masked]>
Date: Wed, 22 Jul 2015 18:13:45 +0200

> "Location" values will look like, and they should be in a URI format as

We agree that we want something other than Entpoint for name2key binding
but we are still debating if we want Endpoint for the radsec
case. It is debatable.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jul 2015 12:15:04 -0400

>>>>> "Alejandro" == Alejandro Pérez Méndez <[email-masked]> writes:

    Alejandro> I might be mistaken, but wasn't that what we wanted to
    Alejandro> avoid in the first place when we decided not to use the
    Alejandro> RADIUS URI scheme from my original proposal?  I guess
    Alejandro> having an endpoint for radsec will require to define how
    Alejandro> the "Location" values will look like, and they should be
    Alejandro> in a URI format as well.

Standardizing a URI that /looked like
radsec://host:port would be *lots* easier than the URI you proposed.
However, yes I believe even that's work I don't think belongs in ABFAB
or aaa-saml.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 22 Jul 2015 18:18:20 +0200

> However, yes I believe even that's work I don't think belongs in ABFAB

Right but we _could_ add Endpoint and leave the work of specifying the
URL format of radius radsec servers to whomever wanted to deploy it

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jul 2015 12:20:21 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> Right but we _could_ add Endpoint and leave the work of
    Leif> specifying the URL format of radius radsec servers to whomever
    Leif> wanted to deploy it

I'm very against that.
It's not guaranteed to be interoperable without the URI and I don't
think we'd have confidence in the semantics without going through the
URI spec.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 22 Jul 2015 18:23:25 +0200

>>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

(I am and was speaking entirely wo any chair hats on btw)

> think we'd have confidence in the semantics without going through the

Thats why we have the Binding parameter! If you don't understand the
Binding then you can't use the Endpoint.

If your position made sense (which it doesn't) then we could never
deploy new bindings in SAML which actually does happen.

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jul 2015 12:26:51 -0400

>>>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> (I am and was speaking entirely wo any chair hats on btw)

    >> 
    >> I'm very against that.  It's not guaranteed to be interoperable
    >> without the URI and I don't think we'd have confidence in the
    >> semantics without going through the URI spec.

    Leif> Thats why we have the Binding parameter! If you don't
    Leif> understand the Binding then you can't use the Endpoint.

No, my point is that until the URI is specified, it seems unlikely that
two implementations would both work with this endpoint.
I absolutely agree that it wouldn't break other bindings.
But for example if one implementation wanted radsec://... and one wanted
radius+tls://... then they wouldn't both be able to consume the same
metadata.

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 22 Jul 2015 16:29:55 +0000

>radius+tls://... then they wouldn't both be able to consume the same

Leif's point is that if you don't specify any bindings, you won't have any interop issue. But if you don't account for the endpoint element(s) in the schema, you can't add them later.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jul 2015 12:31:59 -0400

>>>>> "Cantor," == Cantor, Scott <[email-masked]> writes:

    Cantor,> Leif's point is that if you don't specify any bindings, you
    Cantor,> won't have any interop issue. But if you don't account for
    Cantor,> the endpoint element(s) in the schema, you can't add them
    Cantor,> later.

O, that's irritating.
Thanks for explaining.
I understand now.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 22 Jul 2015 18:32:05 +0200

> two implementations would both work with this endpoint.

Sure but that is no worse than any SAML deployment. Until you agree on
the binding you can't talk.

> radius+tls://... then they wouldn't both be able to consume the same

If they invented the same binding then yeah life would suck for them.

Again: if somebody wants to use Location then have them define the
binding and URL format. Done.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Wed, 22 Jul 2015 18:32:23 +0200

> Leif's point is that if you don't specify any bindings, you won't have any interop issue. But if you don't account for the endpoint element(s) in the schema, you can't add them later.

just so

---

From: Leif Johansson <[email-masked]>
Date: Wed, 22 Jul 2015 18:33:53 +0200

>     Cantor,> the endpoint element(s) in the schema, you can't add them

:-)

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 22 Jul 2015 16:36:21 +0000

>    Cantor,> the endpoint element(s) in the schema, you can't add them

Well, it's not an absolute, you could do extensions to get them in later, but it's annoying to have to do that if you actually have a technical rationale for defining an endpoint type up front. It's better to just do it so it's a well-defined element and not buried inside an extension.

Of course, you can make them minOccurs="0" initially so they're optional and don't matter for now.

-- Scott

---

From: Leif Johansson <[email-masked]>
Date: Wed, 22 Jul 2015 18:55:24 +0200

> Of course, you can make them minOccurs="0" initially so they're optional and don't matter for now.

That was my thought

---

From: Alejandro Pérez Méndez <[email-masked]>
Date: Wed, 22 Jul 2015 23:28:44 +0200

>> Of course, you can make them minOccurs="0" initially so they're optional and don't matter for now.

Let me try to summarize, so I have a clear picture of what the next 
steps are:

in addition to add the new elements to the RADIUSIDPDescriptor and 
RADIUSRPDescriptor subtypes to include the naming information, we can 
keep the RADIUSIDPService and RADIUSRPService elements that I already 
defined (of type EndpointType, with minOccurs="0"), as a provision for 
the future use of locators/endpoints. We don't need to specify the 
specific URI format yet. Am I correct?

I have an additional question though. Leif mentioned that the URI format 
of the Locator attribute will be determined by the value of the Binding 
attribute, which is true. But, since in this document and section we are 
specifically defining the "urn:ietf:params:abfab:bindings:radius" 
Binding, shouldn't it be fixed to that value?

Regards,
Alejandro

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 22 Jul 2015 22:26:40 +0000

>specific URI format yet. Am I correct?

I think so.

>Binding, shouldn't it be fixed to that value?

No, you wouldn't constrain the Binding even if you were defining the whole thing now, that would preclude extensibility later.

There's no need to, any Binding value somebody doesn't understand is just ignored.

-- Scott

---

From: Leif Johansson <[email-masked]>
Date: Thu, 23 Jul 2015 09:19:20 +0200

>> specific URI format yet. Am I correct?

yep

> No, you wouldn't constrain the Binding even if you were defining the whole thing now, that would preclude extensibility later.

exactly

> There's no need to, any Binding value somebody doesn't understand is just ignored.

yep

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 29 Jul 2015 18:29:42 -0700

> -----Original Message-----
> From: abfab [mailto:[email-masked]] On Behalf Of Sam Hartman
> Sent: Wednesday, July 22, 2015 9:15 AM
> To: Alejandro Pérez Méndez
> Cc: [email-masked]
> Subject: Re: [abfab] Direction Forward for aaa-saml
> 
> However, yes I believe even that's work I don't think belongs in ABFAB or aaa-
> saml.

How much of this is to a large extent done with the DNS lookup draft that just got out of the RADEXT working group?