Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt

From: Josh Howlett <[email-masked]>
Date: Mon, 1 Oct 2012 13:54:37 +0000

Jim,

First, I apologise for the appalling tardiness of this response to your
review. Thank you for your comments.

>Major
>
>1.  Do we have any other examples where we might have a SAML
>requester/responder other than the case of the RP/IdP?  If so, it might be
>wise to mention at least one other case in the introductory paragraph in
>section 1.  Otherwise it might be easier to just say that we are sending
>messages between the RP and the IdP and not generalize it.  Can anybody
>see
>a reason that one might want to reverse the endpoints?  So that the RP
>becomes the server and the IdP the client???

I agree that your proposed change would more clearly reflect the primary
motivating use case (Abfab), but I would strongly prefer to maintain the
generalisation because it maintains consistency with the other bindings
defined by OASIS SSTC. These bindings talk of requesters and responders,
and RPs and IdPs are instances of higher-level abstractions that happen to
use these bindings (as requesters and responders) to communicate.

I would be happy to add some text talking around this point, if you think
that would help?

>2. In section 3, I would suggest adding the text "There MUST be at most
>one
>SAML-Message Attribute in either a RADIUS request or response message."

Ok.

>3.  In section 4.1 and 5.1, the Identification will require an IANA
>action.
>I think we are looking at urn:ietf:params:xml:ns:abfab:<something goes
>here>
>I think that something probably looks like SAML:binding:RADIUS-binding in
>section 4.1.  The contact information should be [email-masked].

Ok.

> I don't see
>any requirement that the binding should be specific to the RADIUS
>transport
>- do you?

Well... I think it has to, by definition. The underlying transport is
inherent to a discussion of any binding. Perhaps I have misunderstood your
point?

>4.  In section 4.2 item #2 - If the SAML responder is going to response
>to a
>SAML request, is there a requirement that the responder MUST response no
>later than the Access-Accept or Access-Reject message?

I think that's implicitly true, because either of those messages
necessarily concludes a RADIUS exchange. However, I like the idea of
making this explicit in the text.

>  Also what other
>currently defined packets is the element permitted in - for example can I
>include it in an Access-Challenge packet?

I have a strong preference to constrain the SAML response to the
Access-Accept and Access-Reject packets. RADIUS has a really fuzzy notion
of a session, and I think drawing some clear boundaries here could avoid
inadvertently reaching inconsistent states at the AAA and SAML layers.

>5.  In section 5.2 - Section on Responses: - I am confused when I read
>this
>text.  It first says that you must return exactly one authentication
>statement.  It then says that the IdP can return other statements in the
>assertion.  Are these other assertions allowed to be authentication
>Statements

No; only allowed one of these.

> or are they some other type of statement?

Yes. A SAML assertion can contain three types of statements:
authentication, authorisation and attribute.

>6.  The last sentence in section 5.2 makes no sense to me.    I believe
>the
>sentence should finish "to a Relying Part without step 2 occurring."
>Doing
>it without having the EAP protocol run in section 3 would be bad news.

Right :-) thanks

>Ditto the last paragraph in section 5.3 - I think it should just say that
>"The Request in section 5.3.2 is omitted from the process."

Yes.

>7.  In section 5.3.4 - I would like to see a statement that in this
>profile,
>if the <samlp:AuthnRequest> is marked as fail then the EAP should also
>return fail.  That is there should not be difference in the returned value
>for the SAML request and the EAP dialog.

Agreed.

>8.  In section 5.4.1 paragraph 3 - I am not sure how this section
>interacts
>with the ability of an IdP to return a Pseudonymous identifier.  Are you
>stating that the identifier must already exist, or just that the policy
>for
>creating the identifier must already exist in the case AllowCreate is set
>to
>"false".  

The former. However, isn't this policy orthogonal to the question of
whether the identifier is pseudonymous or not?

>9.  In section 5.4.1 last paragraph - I think we should make some type of
>statement about what happens if either the request is not signed, or the
>signature on the request cannot be validated by the IdP.  I think that
>both
>of these cases are going to be more likely that the case of it is signed
>and
>the IdP happens to be able to validate the signature.

I agree. I would prefer that the spec says words to the effect of "die if
the signature, if any, does not conform to policy" and remain silent on
the question of policy.

(I have a strong personal preference to deal with this question by
prohibiting message-level signatures altogether, and leaving integrity to
the transport level where deployers have a better record of getting this
right, but that wasn't a popular opinion in Taiwan).

>10.  I believe that a discussion of what is expected to happen as these
>messages cross federation boundaries is probably in order.

What would you expect to see in this discussion?

>Nits
>
>1.  We need to get a consistent method of doing Abfab or ABFAB.  I have
>always used all upper case, this document is doing mixed case.  We should
>be
>consistent and I think the all upper case is the normal way.  Please
>change.

Ok.

>2.  I object to the capitalization in the following sentence "The NAI
>SHOULD
>be used to route the
>       message towards the SAML responder, which MAY be more than one
>       RADIUS hop distant."  How are these requirements on the binding
>that
>is being produced?  Are these not intrinsic properties that are true just
>by
>saying that we are using RAIDUS?

Ok.

>3. There is an extraneous period in the last sentence of section 5.3.3

Ok.

>4.  Bad grammar /confirmation as the processing as defined in/  I don't
>know
>what this should be.

Sorry -- defined where?

>5.  Please add http links to your SAML references so I don't have to
>search
>for them - I am very lazy.

Ok.

>6.  Can we move some of the references out of normative?  For example I
>think that 3575 could be informative since it affects only the document
>writer and not the implementer.    The same is probably true for some of
>the
>other references.

Ok.

>s/reponse/response/
>s/Consequently here exists/Consequently there exists/
>s/unsolicited responser/unsolicited response/
>s/disgression/discretion/

I will have an update out by the end of the week.

Thanks, Josh.

Janet is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 1 Oct 2012 11:55:19 -0700

I have to both remember what I was thinking and find a copy of the document
for review again.

> -----Original Message-----
> From: Josh Howlett [mailto:[email-masked]]
> Sent: Monday, October 01, 2012 6:55 AM
> To: Jim Schaad; Sam Hartman
> Cc: [email-masked]
> Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt
> 
> Jim,
> 
review.
> Thank you for your comments.
> 
> >Major
> >
> >requester/responder other than the case of the RP/IdP?  If so, it might
> >be wise to mention at least one other case in the introductory
> >paragraph in section 1.  Otherwise it might be easier to just say that
> >we are sending messages between the RP and the IdP and not generalize
> >it.  Can anybody see a reason that one might want to reverse the
> >endpoints?  So that the RP becomes the server and the IdP the client???
> 
that
> would help?

Moving the first sentence of pargraph 4 into paragraph 1 would address my
concern, that people don't read one paragraph - say this is abfab only - and
skip.

> >I think that something probably looks like SAML:binding:RADIUS-binding
> >in section 4.1.  The contact information should be [email-masked].
> 
> Ok.
> 
> > I don't see
inherent to a
> discussion of any binding. Perhaps I have misunderstood your point?
> 

I think that this issue had to do with confusion on my part on the
differences between what happens for RADIUS and Diameter.  I agree with you
that this is a RADIUS specific transport now, and "RADIUS" can be
transported by Diameter.

> >to a SAML request, is there a requirement that the responder MUST
> >response no later than the Access-Accept or Access-Reject message?
> 
necessarily
> concludes a RADIUS exchange. However, I like the idea of making this
explicit
> in the text.

This currently feels good to me, however it means that there is a question
on how an Acceptor could later ask for additional attributes from the IdP.
While this is not currently supported by GSS-EAP (yuk), I don't know that I
also want to update this document to be able to do it here.  I don't know
that that is going to be in the Access-Accept/Reject.  However it may be
that is a different set of bindings and should be addressed separately.
Given the current GSS-EAP, this is an explicit requirement that needs to be
stated.  (OK - so I am arguing both sides of the issue).

> >  Also what other
> >currently defined packets is the element permitted in - for example can
> >I include it in an Access-Challenge packet?
> 
> I have a strong preference to constrain the SAML response to the Access-
> Accept and Access-Reject packets. RADIUS has a really fuzzy notion of a
> session, and I think drawing some clear boundaries here could avoid
> >this text.  It first says that you must return exactly one
> >authentication statement.  It then says that the IdP can return other
> >statements in the assertion.  Are these other assertions allowed to be
> >authentication Statements
> 

Ok - I think was I needed more SAML background at the time.

> >interacts with the ability of an IdP to return a Pseudonymous
> >identifier.  Are you stating that the identifier must already exist, or
> >just that the policy for creating the identifier must already exist in
> >the case AllowCreate is set to "false".
> 
whether
> the identifier is pseudonymous or not?

Yes, it is orthogonal to the question is the identifier pseudonymous.
Changing the text slightly might solve my issue.  The problem I have with
"establishing a new identifier for a principal if none exists".  The
question is, is a new pseudonymous tag for an existing principal
"establishing a new identifier".

> 
> >9.  In section 5.4.1 last paragraph - I think we should make some type
> >of statement about what happens if either the request is not signed, or
> >the signature on the request cannot be validated by the IdP.  I think
> >that both of these cases are going to be more likely that the case of
> >it is signed and the IdP happens to be able to validate the signature.
> 
the
> signature, if any, does not conform to policy" and remain silent on the
> question of policy.
> 
prohibiting
> message-level signatures altogether, and leaving integrity to the
transport
> level where deployers have a better record of getting this right, but that
> wasn't a popular opinion in Taiwan).
> 

I am in the same camp that you are and did not understand the ground swell
in Taiwan.

> What would you expect to see in this discussion?

My problems deal with the questions dealing with if names of attributes
should be changed/could be changed as federation boundaries are crossed.
The values could also be remapped at the same time if different federations
had different ideas of things.  Values could be silently removed if the
second federation does not believe that the first federation has the ability
to make such a statement, and this will make it appear as if the IdP was
unwilling to provide the information.  See the discussion from Paris in the
audio.

> >know what this should be.
> 
> Sorry -- defined where?

Section 5.4.2 bullet point 4 (search for the string)

> Janet is a trading name of The JNT Association, a company limited by
> guarantee which is registered in England under No. 2881024 and whose
> Registered Office is at Lumen House, Library Avenue, Harwell Oxford,
Didcot,
> Oxfordshire. OX11 0SG

---

From: Gabriel López <[email-masked]>
Date: Tue, 02 Oct 2012 10:36:10 +0200

> Ok - I think was I needed more SAML background at the time.

afaik, authorization statements are deprecated in SAML2.0

best regards, Gabi.

-- 
----------------------------------------------------------------
Gabriel Lpez Milln
Departamento de Ingeniera de la Informacin y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Josh Howlett <[email-masked]>
Date: Tue, 2 Oct 2012 13:15:59 +0000

>, however it means that there is a question

Recall that this text is describing the general case, where the SAML
requester is not necessarily an ABFAB acceptor; it could be wireless AP or
VPN concentrator and their existing RADIUS API is probably good enough.

However that's definitely not true in the case of an ABFAB acceptor; we
are dependent on the GSS API and so we also need a discussion in Kitten.

For the purposes of this document, I had been assuming that we could
safely decouple discussion of the abstract assertion request API (in
Kitten) from discussion of the protocol (in ABFAB), and that we should
define the latter first in order to motivate the necessary work in Kitten.
We may need to reconsider things if that is not a reasonable assumption...

>"establishing a new identifier".

Yes, for the particular identifier that denotes the subject of an
assertion (which, confusingly, may or may not be the "tag" used by the
application to denote the subject; often an attribute (e.g., 'mail') from
the assertion is used instead).

Do you have a specific concern?

>I am in the same camp that you are and did not understand the ground swell

Yes, I am now kicking myself for not digging my heels in. As I won't be in
Atlanta I will separately write mail arguing that the WG reconsiders this.

>unwilling to provide the information.  See the discussion from Paris in

This is about the application of policy, and so I would prefer if we
punted this discussion to the architecture document. Would this be ok?

Josh.

---

From: Josh Howlett <[email-masked]>
Date: Tue, 2 Oct 2012 13:39:13 +0000

On 02/10/2012 14:34, "Sam Hartman" <[email-masked]> wrote:
>I think that we need to have a mandatory-to-implement policy for
>signature handling to guarantee interoperability.  I think that
>mandatory-to-implement policy should be ignore the signature in all its
>bulk.
>
>I'm fine with implementations having other policies.

I'm happy with that.

---

From: Josh Howlett <[email-masked]>
Date: Tue, 2 Oct 2012 13:41:22 +0000

>>SAML-Message Attribute in either a RADIUS request or response message."

Just pedalling back here. Owing to the length constraint of RADIUS
attributes, we will generally need to fragment the SAML message across
multiple SAML-Message attributes within the RADIUS message.

Josh.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 02 Oct 2012 09:34:40 -0400

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Oct 2012 15:04:39 +0100

(jumping in with little context...)

> mandatory-to-implement policy should be ignore the signature in all its

Defining signature "handling" as ignoring the signature would
seem very insecure, no? How'd you justify that?

It'd seem to call for a lot of security considerations text
at minimum.

S.

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Oct 2012 15:36:01 +0100

On 10/02/2012 03:27 PM, Sam Hartman wrote:
>>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:
> 
>     Stephen> (jumping in with little context...)
> 
>     Stephen> On 10/02/2012 02:34 PM, Sam Hartman wrote:
>     >> mandatory-to-implement policy should be ignore the signature in
>     >> all its bulk.
> 
>     Stephen> Defining signature "handling" as ignoring the signature
>     Stephen> would seem very insecure, no? How'd you justify that?
> 
> But something that can actually be implemented.  The idea that you could
> actually construct a usable PKI is sufficiently preposterous that it
> need not be considered:-)
> 
> OK, now that we've squared off, let me try and make a serious
> contribution.

:-)

> The SAML signature mechanism is anselary to the security approach that
> we're using for this.
> I think a lot of us would like to not even support signatures in this
> SAML binding because we believe that the hop-by-hop integrity is
> sufficient and because those signatures will create interoperability
> problems.

Is there text somewhere that argues that hop-by-hop integrity
is enough for abfab? Is that for all use-cases or just some?

I reckon you'll need that text if "ignore signature" is the
MUST implement.

> It seems silly to me though to reject a request because it is signed
> when you would hapilly accept the same request were the signature
> stripped.

I agree. After lots of debate, DKIM also passes on signatures
even after they're sure to no longer be verifiable, so you have
a good precedent for not stripping.

OTOH, it also seems silly to say ignore signature is the MUST
implement, if you're able to pass the signature around and it
could in principle be verified.

S.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 02 Oct 2012 10:27:20 -0400

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 2 Oct 2012 08:35:32 -0700

> Sent: Tuesday, October 02, 2012 6:41 AM
> >>2. In section 3, I would suggest adding the text "There MUST be at
> >>most one SAML-Message Attribute in either a RADIUS request or
> response
> >>message."
> >
> >Ok.
> 
attributes,
> we will generally need to fragment the SAML message across multiple SAML-
> Message attributes within the RADIUS message.

Yes you are right it can be fragmented, is there a way to say that you can
only have one "unfragmented attribute" in a "logical message"?

Jim

Didcot,

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 2 Oct 2012 08:38:13 -0700

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2012 7:36 AM
> To: Sam Hartman
> Cc: Josh Howlett; Jim Schaad; [email-masked]
> > But something that can actually be implemented.  The idea that you
> > could actually construct a usable PKI is sufficiently preposterous
> > that it need not be considered:-)
> >
> Is there text somewhere that argues that hop-by-hop integrity is enough
for
> abfab? Is that for all use-cases or just some?
> 
> I reckon you'll need that text if "ignore signature" is the MUST
implement.
> I agree. After lots of debate, DKIM also passes on signatures even after
> they're sure to no longer be verifiable, so you have a good precedent for
not
> stripping.
> 
> OTOH, it also seems silly to say ignore signature is the MUST implement,
if
> you're able to pass the signature around and it could in principle be
verified.

But one of the current precepts of ABFAB is that you are not going to be in
a single trust anchor world, the TA of the signer may not be known or
trusted by the acceptor.  This means that you probably cannot validate the
signature even if it is present.

Jim

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Oct 2012 16:43:00 +0100

> signature even if it is present.

Sure. That says you have a hard problem. But not that
hop-by-hop integrity is sufficient, nor that "ignore the
signature" is the right MUST implement.

S.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 02 Oct 2012 11:47:18 -0400

OK, I'm with Josh.  This is going to be one of those cases where digging
in heals now and saying MUST NOT sign will save us political grief
later.  A lot of people like Stephen are going to look at ignore
signatures and complain, where as they would be more willing to accept
that we're simply not using per-message signatures at all.  It's
unfortunate because I do think there ar situations where signatures are
valuable.  However, I'm imagining that we're going to be having this
argument again and again and again and it just won't be worth the cost.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Oct 2012 17:03:35 +0100

I had a quick look at the -03 draft and I'm confused.

Are "ignore signatures is the MUST implement" and
"MUST NOT sign" the only real options?

For example, I don't get why "IdP MAY sign +
RP is NOT REQUIRED to verify signature +
RP MUST implement signature verification"
is not an option. (Assuming you add text that
justifies why hop-by-hop integrity is ok.)

Note: I'm not saying that the above is what
you ought do, I'm saying I don't get why its
not possible.

S.

---

From: Josh Howlett <[email-masked]>
Date: Tue, 2 Oct 2012 19:44:48 +0000

>only have one "unfragmented attribute" in a "logical message"?

It says that already in section 4.2, in the context of the Binding: "The
SAML responder MUST NOT include more
       than one SAML response".

Josh.

---

From: Josh Howlett <[email-masked]>
Date: Tue, 2 Oct 2012 19:48:45 +0000

>SAML responder MUST NOT include more

Just to clarify, I believe that text says this implicitly. Obviously we
can certainly can call it out more explicitly if you think that would help.

Josh.

---

From: Josh Howlett <[email-masked]>
Date: Wed, 3 Oct 2012 10:57:59 +0000

I agree that is an option; and it wouldn't be the end of the world if
that's where we end up. But I believe it would impede interoperable
deployments because it defers this discussion to implementers and users
who won't, on the whole, care about or understand the issues. I would
prefer to have a simple interoperable solution that works for 99% of the
users than a less constrained but accordingly more complex solution that
satisfies the remaining 1%.

(This is, as I understand it, the reason why the SAML community ended up
with the 'Metadata Interoperability Profile'; which constrains the
possible expressible trust semantics of SAML 2.0 federation metadata to
facilitate interop).

Josh.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Oct 2012 12:11:40 +0100

On 10/03/2012 11:57 AM, Josh Howlett wrote:
> that's where we end up. 

Ok, good. (I mean its good that I'm not entirely misunderstanding
what's possible, I do not mean that the option I described below
is necessarily good.)

> But I believe it would impede interoperable
> who won't, on the whole, care about or understand the issues. 

I don't get that. Do you mean that the presence of the
signature and signature-verification code would lead
implementers to throw an exception if they don't have
the right keys to verify the signature? Surely that'd
depend on what you tell them, e.g. whether you say
they SHOULD or MAY verify the signature and about the
consequences (or lack thereof) of not verifying the
signature.

And all of these options seem to depend on having a
good argument that hop-by-hop integrity is ok. Is
that already written down somewhere? If not, it'll
need to be. (I keep harping on about that because I
worry that hop-by-hop may turn out to only be ok
in some use-cases/deployments.)

> I would

#include <motherhoodandapplepie.h> // :-)

S

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Oct 2012 09:04:27 -0400

>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

    Josh> I agree that is an option; and it wouldn't be the end of the
    Josh> world if that's where we end up. But I believe it would impede
    Josh> interoperable deployments because it defers this discussion to
    Josh> implementers and users who won't, on the whole, care about or
    Josh> understand the issues. I would prefer to have a simple
    Josh> interoperable solution that works for 99% of the users than a
    Josh> less constrained but accordingly more complex solution that
    Josh> satisfies the remaining 1%.

IDP MAY sign + RP MAY ignore + RP MUSt verify doesn't meet the IETf's
interoperability criteria because an IDP that does not support
signatures cannot work with an RP that requires them.

A solution  that depends on verifying signatures as the MTI  is the
wrong approach because we don't plan to have  trust anchors in common.
We don't believe there is a viable strategy for having trust anchors in
common in our deployments and are going to a lot of effort to avoid
needing that.

for my part, I've worked with a number of potential customers and
prepared Moonshot related proposals for two.  In both those situtaions,
shared trust anchors were not an option.
So, I would not support a MTI strategy that depended  on shared trust
anchors.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Oct 2012 09:58:46 -0400

So, I'm a bit confused why we're discussing whether hop-by-hop integrity
is good enough.
That's been how RADIUS handles integrity for authorization attributes
all along.
Why does describing authorization in terms of XML make that different
than authorization described in native RADIUS attributes?

No confidentiality and too many proxies is posing a problem for some
usecases that we're looking at deploying.  I'm looking to RADSEC as a
solution to that for my clients. SAML signatures would not help with the
confidentiality issues.  Also, since most of what I'd like to make
confidential is in RADIUS attributes not SAML, xml encryption wouldn't
help either.

--Sam

---

From: Josh Howlett <[email-masked]>
Date: Wed, 3 Oct 2012 14:30:41 +0000

>signatures cannot work with an RP that requires them.

I agree. I thought Stephen's suggestion was IdP MAY sign + RP MAY verify.
This at least gets you interoperability, in the absence of a common TA, if
the RP chooses not to verify the signature (if any).

Agreed.

Josh.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Oct 2012 15:30:44 +0100

> So, I'm a bit confused why we're discussing whether hop-by-hop integrity

I guess its at minimum a reaction to ignoring a signature.
It may well be ok, but I think it needs justifying, if the
WG go this way.

> That's been how RADIUS handles integrity for authorization attributes

Sure. Diameter too.

> than authorization described in native RADIUS attributes?

The encoding (XML vs. AVPs) doesn't make any difference. The
difference is that in principle an RP could verify the
SAML assertion signature and get e2e integrity, (if it
had the right keys) whereas that's not currently possible
for RADIUS or Diameter.

That seems like a change to the usual SAML trust model,
isn't it?

So I'm really asking that it be justified explicitly if
the WG are taking this route.

Stating the equivalence with RADIUS almost does that. I
guess what remains to be said is that the SAML assertion
attributes (if that's the right term) that'll be used by
abfab are always ok to use with just hop-by-hop integrity.
I'm guessing that'll be the case, but I don't know.

> confidential is in RADIUS attributes not SAML, xml encryption wouldn't

Sure.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Oct 2012 15:36:19 +0100

> the RP chooses not to verify the signature (if any).

Sam clarified his take on the above for me offlist.

He's concerned that the option I wrote down would allow
an RP implementation that insisted on always checking
signatures and didn't offer the option to not verify
some or all signatures.

I agree that if its ok to not check some signatures
then its also ok to dis-allow implementations that
insist on checking all signatures.

I'm not so sure that's the same as saying that ignoring
signatures is *the* MTI though. You could also make
the ability to check signatures MTI. (Again, I'm not
saying such an option is right, I'm still trying to
understand this stuff.)

S.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Oct 2012 10:38:00 -0400

Stephen> On 10/03/2012 02:58 PM, Sam Hartman wrote:
    >> So, I'm a bit confused why we're discussing whether hop-by-hop
    >> integrity is good enough.

    Stephen> I guess its at minimum a reaction to ignoring a signature.
    Stephen> It may well be ok, but I think it needs justifying, if the
    Stephen> WG go this way.

I'd like to push back on this reaction in the strongest possible terms.
The idea that it's bad to ignore a signature, but it would be acceptable
to not have a signature at all decreases the value of signatures.  It
means that by adding a signature we decrease interoperability.  However
if the RP would accept an unsigned object, we gain no security
advantage.

I'd like to ask you to think about whether that reaction--the negative
response to ignoring a signature--is ever appropriate in a case where
the signature is optional. If so I'd like to understand why.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Oct 2012 10:34:28 -0400

>> 
    >> IDP MAY sign + RP MAY ignore + RP MUSt verify doesn't meet the
    >> IETf's interoperability criteria because an IDP that does not
    >> support signatures cannot work with an RP that requires them.

    Josh> I agree. I thought Stephen's suggestion was IdP MAY sign + RP
    Josh> MAY verify.  This at least gets you interoperability, in the
    Josh> absence of a common TA, if the RP chooses not to verify the
    Josh> signature (if any).

>From a purely process point of view IDP MAY sign and RP MAY verify
doesn't interop.
MAY means just that; the RP is permitted to verify. I.E. I can ship an
RP that always verifies.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Oct 2012 16:01:06 +0100

> I'd like to push back on this reaction in the strongest possible terms.

Push away.

But note that my reaction has not been to say "don't do
that" - I'm saying "justify that."

Note also that we're moving away from abfab-specific things
to generalities.

> to not have a signature at all decreases the value of signatures.  

Perhaps. Or maybe its that optionally-signed things decrease
the value of signatures when those are present compared to
always-signed things.

> It
> means that by adding a signature we decrease interoperability.  

That's definitely true. Adding any crypto decreases interop.

> However

An RP could choose depending on the to-be-signed/unsigned
value(s) and get a security advantage. For example, something
along the lines of being ok with "local" stuff not being signed
on the assumption that some border node will already have
prevented a bad version of that arriving, but treating
non-local signed or unsigned things differently. (For some
definition of "local.")

> the signature is optional. If so I'd like to understand why.

I think it can be appropriate sometimes as per the
above.

Cheers,
S.

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Wed, 3 Oct 2012 15:07:03 +0000

On Oct 3, 2012, at 3:58 PM, Sam Hartman wrote:

Sam,

> confidential is in RADIUS attributes not SAML, xml encryption wouldn't

I think Stephen raises a valid point. Just pointing to the RADIUS hop-by-hop protection is a bit weak, after all there is potentially a lot more authorization data going over the wire compared to the simple network access case. I think it is fine to call out the hop-by-hop behaviour and, as you mention above, state that if you want direct peer to peer connections you'll have to do RadSec. Don't you think that that would decrease the likelihood of ill thought through deployments? I have seen a couple of weird uses of the eduroam trust fabric (not looking at you Josh ;-), so a bit of discussion around this topic would help.

Klaas

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Oct 2012 11:11:06 -0400

OK.
Let me rephrase.

I claim for a given message the following reactions are reasonable:

1) require signature
2) ignore any present signature

and that

3) verify if present and fail if verified

is unreasonable.
It may be that verify if present and tell a human what verification
yielded is sometimes helpful but I'm dubious.

Are you arguing for 3?
Or are you arguing that we should add a new security requirement to
RADIUS that there are some messages that MUST be signed?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Oct 2012 11:33:07 -0400

>>>>> "Klaas" == Klaas Wierenga (kwiereng) <[email-masked]> writes:

    Klaas> I think Stephen raises a valid point. Just pointing to the
    Klaas> RADIUS hop-by-hop protection is a bit weak, after all there
    Klaas> is potentially a lot more authorization data going over the
    Klaas> wire compared to the simple network access case. I think it
    Klaas> is fine to call out the hop-by-hop behaviour and, as you
    Klaas> mention above, state that if you want direct peer to peer
    Klaas> connections you'll have to do RadSec. Don't you think that
    Klaas> that would decrease the likelihood of ill thought through
    Klaas> deployments? I have seen a couple of weird uses of the
    Klaas> eduroam trust fabric (not looking at you Josh ;-), so a bit
    Klaas> of discussion around this topic would help.

I'm all for security considerations text.
Heck, I'm all for MTI RADSEC if we could find a process way to do it.

--Sam

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Oct 2012 16:51:48 +0100

Hiya,

> I claim for a given message the following reactions are reasonable:

I'm assuming we're talking generalities here and not
just about abfab.

> 3) verify if present and fail if verified

Did you mean:

3) verify if present and fail transaction if not good-signature
   but handle transaction if no signature present as if a
   good signature was present

If so, yes that'd almost certainly be unreasonable.

> yielded is sometimes helpful but I'm dubious.

I'm arguing that in general (perhaps not for abfab, not
sure), your three choices are too binary:-)

Signature checking can fail for various reasons (hash
compare fails, wrong key, don't have key, don't have path
for key, revocation, naming, ...) and the reaction to
failure of a signature check can also vary (fail the
transaction, subject transaction to more checks as in
DKIM, re-route transaction, log the transaction
somewhere special, ...).

The appropriate reaction to not being able to verify
a signature on a signed message can reasonably be
different to the reaction to an unsigned message.

For example, if I were using key continuity, then
the first time I see a signed thing I might allow
the transaction even though I've no good reason to
accept the public key. But the 2nd time different
checks will apply, with possibly different results.
For example, I might start rejecting transactions
that claim to be from that source but don't have
signatures that verify with the key I saw on the
first signed transaction from that source.

And again, the above are generalities. I'm not
saying how the argument might or might not apply
to abfab. (And I think we've wandered off topic
somewhat.)

> RADIUS that there are some messages that MUST be signed?

No, I've made no argument about RADIUS at all.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Oct 2012 17:03:50 +0100

On 10/03/2012 04:56 PM, Sam Hartman wrote:
>     Stephen> 3) verify if present and fail transaction if not
>     Stephen> good-signature but handle transaction if no signature
>     Stephen> present as if a good signature was present
> 
>     Stephen> If so, yes that'd almost certainly be unreasonable.
> 
> Yes  that is what I meant.
> 
> I've been interpreting your request in the ABFAB context as a request
> for exactly that.

It wasn't.

> If that isn't what you've been asking us to consider I'd like to
> understand better
> 
> 1) What you're asking for specifically

The justification for why its safe to ignore a signature,
when one is present that could, in principle, be verified
and thus provide e2e integrity/origin-authentication for
the attributes extracted from the signed SAML assertion.

Stating that its hard to get the right keys in the
right places explains your design choice but doesn't
communicate why that design is a safe one.

> 2) Why the departure from the standard RADIUS assumptions about
> integrity and authorization is justified.

I'm asking that you justify the departure from the
standard SAML assumptions about assertions that are
signed by an IdP.

S.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Oct 2012 11:56:59 -0400

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Oct 2012 12:09:13 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

I'm sorry.
I'm still not seeing the difference between what you're asking for and
what we've both stated we see as unreasonable.

I'm going to withdraw from the discussion at this point, because I don't
think me stating that I'm confused more will help.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 08 Oct 2012 11:37:15 +0200

>> The SAML signature mechanism is anselary to the security approach
>> that we're using for this. I think a lot of us would like to not
>> even support signatures in this SAML binding because we believe
>> that the hop-by-hop integrity is sufficient and because those
>> signatures will create interoperability problems.
> 
> Is there text somewhere that argues that hop-by-hop integrity is
> enough for abfab? Is that for all use-cases or just some?

with chair as off:

	I'm a bit worried about out-of-band attribute-authorities
	here. In-band hop-by-hop _may_ be good enough when all of the
	attributes come from the IdP.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 08 Oct 2012 08:55:22 -0400

This specification only covers in-band.
I agree with you that you need to do something about integrity for
out-of-band.

--Sam