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.
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 protected]. 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.
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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
