Subject: [abfab] Authentication attributes and aaa-saml

From: Sam Hartman <[email-masked]>
Date: Fri, 07 Mar 2014 07:05:30 -0500

Josh, the meeting was very confused about how aaa-saml interacts with
the requirement from 2865 to have an authentication attribute in
access-request.

Where does that come up for this draft?

--Sam

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 12 Mar 2014 09:18:24 +0100

> Where does that come up for this draft?

Dear all,

during last IETF meeting I had no chance to properly explain the issue 
with the ietf-abfab-aaa-saml and RFC 2865 due to some remote audio 
problems, thus I was requested to do it on the list. Let me complete 
Sam's question with further information.

This issue is related with the one we had with our RADIUS fragmentation 
draft, and debated in RADEXT. However, I think that it may require a 
different solution than the one took for our draft, as they happen at 
different levels.

RFC 2865 specifies that:

    An Access-Request MUST contain either a User-Password or a CHAP-
    Password or a State. An Access-Request MUST NOT contain both a
    User-Password and a CHAP-Password. If future extensions allow other
    kinds of authentication information to be conveyed, the attribute
    for that can be used in an Access-Request instead of User-Password
    or CHAP-Password.

This implies that an Access-Request packet will be invalid if it does 
not contain any authentication attribute.

In section 7.3.2., ietf-abfab-aaa-saml defines how the RP uses a RADIUS 
Access-Request message to communicate with the IdP, prior the EU 
authentication, and provide the <samlp:AuthnRequest>. In section 8.3.2, 
the contents of this Access-Request message are described as:

  * MUST use User-Name (not authentication attribute)
  * MUST include Service-Type = Authorize-Only (Not authentication
    attribute)
  * SHOULD include RADIUS State (authentication attribute, but not
    available when sent before the principal is authenticated; i.e.
    before EAP).

Therefore, this message may not contain any authentication attribute, 
and therefore in those cases might be considered as invalid by entities 
following RFC 2865 to the letter.

However, as RFC 2865 leaves the door open for new attributes to be 
considered as authentication, we think that a feasible solution for this 
issue would be declaring SAML-Message and/or the SAML-Assertion 
attributes as authentication attributes. We think this would make sense 
as as they might affect how the subsequent authentication process will 
be performed.

Regards,
Alejandro

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Mar 2014 09:18:55 -0400

We're discussing section 8 of draft-ietf-abfab-aaa-saml.

>   this issue would be declaring SAML-Message and/or the SAML-Assertion

I don't support that approach mostly because it assumes there will be
subsiquent authentication.  If there is such I'd expect eap-message or
similar to be present in the radius access-request

My recommendation is that we indicate in section 8 that this draft only
covers the case where the request in in the context of an existing
session and includes state.
In future, the profile can be expanded.  I'd probably leave state as a
SHOULD with a note about 2865 and indicate that if you're using this
profile without state you need a spec describing how to do that and that
spec needs to tell you what authentication attributes to include.

--Sam

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 12 Mar 2014 15:20:22 +0100

> similar to be present in the radius access-request

Following Alan's suggestions, we decided for our draft that it was
better to do not mix things up and keep RADIUS-EAP (and other
authenticaiton mechanisms) completely unmodified.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Mar 2014 10:22:09 -0400

>>>>> "Alejandro" == Alejandro Perez Mendez <[email-masked]> writes:

    Alejandro> El 12/03/14 14:18, Sam Hartman escribiÃ³:
    >>> this issue would be declaring SAML-Message and/or the
    >>> SAML-Assertion attributes as authentication attributes. We think
    >>> this would make sense as as they might affect how the subsequent
    >>> authentication process will be performed.
    >> I don't support that approach mostly because it assumes there
    >> will be subsiquent authentication.  If there is such I'd expect
    >> eap-message or similar to be present in the radius access-request

    Alejandro> Following Alan's suggestions, we decided for our draft
    Alejandro> that it was better to do not mix things up and keep
    Alejandro> RADIUS-EAP (and other authenticaiton mechanisms)
    Alejandro> completely unmodified.

Right.
I don't understand how that applies to aaa-saml.

---

From: Gabriel Lopez <[email-masked]>
Date: Wed, 12 Mar 2014 15:30:27 +0100

Hi Sam,

> session and includes state.

	What's about an initial SAMLAuthRequest from the RP to the idP (before
the EAP exchange) pointing out, for example, some kind of LoA
requirement? I though it was one of the motivations for the use of SAML
here.
	In this case there is not a "state" attribute.

	Regards, Gabi.

-- 
Gabriel López Millán, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888504 Fax: +34868884151 e-mail: [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Mar 2014 10:39:27 -0400

>>>>> "Gabriel" == Gabriel Lopez <[email-masked]> writes:

    Gabriel> 	What's about an initial SAMLAuthRequest from the RP to
    Gabriel> the idP (before the EAP exchange) pointing out, for
    Gabriel> example, some kind of LoA requirement? I though it was one
    Gabriel> of the motivations for the use of SAML here.  In this case
    Gabriel> there is not a "state" attribute.

That would be inconsistent with the profile described in section 8.
That would be more consistent with the profile in section 7.
There, though, I'd expect the SAML request and EAP message to be in the
same initial access-request.

---

From: Gabriel Lopez <[email-masked]>
Date: Wed, 12 Mar 2014 16:04:48 +0100

> That would be more consistent with the profile in section 7.

right

> same initial access-request.

ok, so what would happen if the SAMLAuthRequest has to be fragmented?
the first message would include the EAP message? btw, Does It preclude
the use of a pre-authorization exchange in this context?

Regards, Gabi.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 12 Mar 2014 16:12:58 +0100

> I don't understand how that applies to aaa-saml.
Because you are suggesting to include in the same packet EAP information
with SAML. Am I wrong? Therefore, that would be against Alan's suggestion.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 12 Mar 2014 16:18:57 +0100

Hi Sam:

Then, there will not be a "pre-authorization phase prior an authentication" use case/profile in this draft, correct?

I ask you this since you showed some time ago your interest in this case (pre-authz prior authentication). I thought you had an use case/profile in mind in the context of aaa-saml.

Best Regards.

> same initial access-request.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Mar 2014 11:27:03 -0400

>>>>> "Rafa" == Rafa Marin Lopez <[email-masked]> writes:

    Rafa> Hi Sam: Then, there will not be a "pre-authorization phase
    Rafa> prior an authentication" use case/profile in this draft,
    Rafa> correct?

If you need fragmentation, then you should follow the rules of
draft-ietf-radext-radius-fragmentation.
And there, yes the SAML would come before EAP, and you'd end up
violating the MUST in 2865 as we discussed in radext last week.

However, from the standpoint of draft-ietf-abfab-aaa-saml, by the time
the fragmented packet is reassembled, but authentication and saml
attributes will be present.

My understanding of Alan's concern is that you didn't want to intermix
fragmentation of authorization information with fragmentation of EAP.
For example, you didn't want to have an EAP and SAML conversation going
on at the same time.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Wed, 12 Mar 2014 11:32:28 -0400

> For example, you didn't want to have an EAP and SAML conversation going

  Yes.  I would avoid that as much as possible.

  Alan DeKok.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 12 Mar 2014 17:05:23 +0100

Hi Sam

> violating the MUST in 2865 as we discussed in radext last week.

Yes, that is clear.
> attributes will be present.

So, in the end, there won't be pre-authz prior an authentication in aaa-saml. That is what I wanted to make sure.

Thanks.