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

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Alejandro Perez Mendez
> Sent: Thursday, March 15, 2012 1:05 AM
> To: [e-mail]
> Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt
> 
> 
> > Comments on the current version of the document.
> >
> > First let me say that overall I am very happy with the state of this
> > document.  It is slightly repetitive, but is very clear about what
> > happens when and where.  I believe that I now have a clear
> > understanding of how I would go about using SAML statements in Plasma
> > by starting with using the Authentication Profile and then following
> > it up with generic queries using the identity that was returned in the
> Authentication response.
> >
> > Jim
> >
> >
> > 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???
> >
> > 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."
> 
> It is almost impossible to fit a entire SAML message into a single SAML-
> Message attribute (253 bytes), so almost always there will be more than on
> SAML-Message attribute in both, RADIUS requests and responses when
> transporting SAML data. All these attributes are part of the same extended
> fragmented attribute, but section 3 is talking about the basic RADIUS
> attribute. Note that this draft has not yet adopted extended attributes
> format.
> 
> If your intention was to suggest that no more than 1 SAML Message MUST
> be included per RADIUS packet, I'm not sure to agree either. At least, I
do not
> see a clear motivation for such limitation.

My intent was to say that there was at most one SAML Assertion in a RADIUS
request or response message.  If this is not true then we need to find a way
to say that assertion #1 has ended and we are now dealing with assertion #2.

> 
> >
> > 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 [e-mail].  I don't
see
> > any requirement that the binding should be specific to the RADIUS
> transport
> > - do you?
> >
> > 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?  Also what other
> > currently defined packets is the element permitted in - for example can
I
> > include it in an Access-Challenge packet?
> 
> That's an interesting question. In a previous discussion we were
> thinking on moving all the authorization data retrieval exchanges
> _after_ the Access-Accept exchange. I think Josh already shown interest
> on changing to that kind of flow, though I guess until
> radius-fragmentation draft moves a little forward this need to be hold on.
> 
> The basic idea would be to perform the EAP authentication without SAML
> exchanges. Within the Access-Accept, the RADIUS server provides a State
> attribute and the service-type would be Authorize-Only, indicationg
> further authorization need to be performed. Then the RP sends the SAML
> Authn Req and the IdP provides the SAML Assertion. This way both
> authentication and attribute retrieval follow the same exchange pattern.
> 
> 
> >
> > 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 or are they some other type of statement?
> 
> Other type of statement, for example, attribute statement.
> 

Ok the text could be clearer.

> >
> > 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.
> > 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."
> >
> > 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.
> 
> IMO this is not required. EAP is meant to provide authentication, while
> SAML is intended to provide authorization. A principal may be succesfuly
> authenticated, but fail to obtain authorization information. One process
> should not interfere in the other. Think that a RP may not issue the
> AuthnReq. Besides, if the RADIUS server and the IdP are not collocated,
> I do not think it is a good idea to trick the EAP stack in the RADIUS
> server to force an EAP failure if the IdP replies with an SAML error.
> 
> 

Allowing for different answers makes more sense if the flow changes as
above.  Otherwise I don't see that this is necessarily true.  We have
already stated that the AuthnRequest can and should in some cases affect how
the EAP is performed.  Are you talking about failing because you are not
going to return some attributes or because you are going to say that yes I
know who they are, but they are not supposed to talk to you.  In this case
ABFAB has already said you are supposed to fail the EAP conversation as
well.  Under what circumstances do you think this would occur.

> >
> > 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".
> >
> > 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 think a general statement must be included saying that if SAML
> messages/assertion are not singed, authenticity and integrity protection
> are implicitly provided by the AAA infrastructure. If signatures are
> provided, they have precedence.
> 
> >
> > 10.  I believe that a discussion of what is expected to happen as these
> > messages cross federation boundaries is probably in order.
> >
> > 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.
> Agree
> 
> >
> > 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?
> >
> > 3. There is an extraneous period in the last sentence of section 5.3.3
> >
> > 4.  Bad grammar /confirmation as the processing as defined in/  I don't
> know
> > what this should be.
> >
> > 5.  Please add http links to your SAML references so I don't have to
search
> > for them - I am very lazy.
> >
> > 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.
> >
> > s/reponse/response/
> > s/Consequently here exists/Consequently there exists/
> > s/unsolicited responser/unsolicited response/
> > s/disgression/discretion/
> >
> >
> >
> > _______________________________________________
> > abfab mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/abfab
> _______________________________________________
> abfab mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/abfab