Subject: [abfab] Review - draft-ietf-abfab-aaa-saml-04

From: "Jim Schaad" <[email-masked]>
Date: Sun, 11 Nov 2012 13:52:25 -0800

1. Introduction  para #2, Definition of binding is not well stated.  I
believe a better description would be:
"in the SAML architecture, the description of how messages are transported
is called a 'binding'."

2. Not immediately clear these are two not one from the text "specific use
cases:
   authentication and assertion query/request."  suggest
"In addition to the new RADIUS attribute and the RADIUS binding,  this
document also creates two profiles for their use.  The first profile is for
the case of ABFAB authentication and the second is for assertion
query/request.  This is intended to promote interoperability between
implementations for these common use cases."

3.  Introduction - Summary points - s/An Authentication Profile/An ABFAB
Authentication Profile/

4.  Section 4.  Title - Look for an be more consistent about the term you
are using.  I prefer "RADIUS SAML-Message Attribute" to "SAML RADIUS
attribute".  Consistent name of the topic would be good.

5.  Section 4 - I think Scott raised an interesting question in the meeting
about the ability for this attribute to be deflated (optionally?) before
being sent.  This would tend to make the message a lot smaller.  One could
probably detect the deflation based on the first character in the data field
(i.e. '<' vs ???) so no signaling method would be required.

6.  Section 5.2 - "RADIUS can be used over multiple underlying transports;"
It is unclear to me that this binding really needs to care about what the
underlying transport is and why it would need to state what the transport is
going to be.   I have problems with trying to state what the transport
should be because there is no way for the application to be able to control
it.  

7.  Section 5.2 - Item #1 - "MAY transmit a SAML request" there is no MAY
here, it just "transmits a SAML request"  If it is not transmitting the
request is not acting as a SAML requester and is not relevant to the
document

8.  Section 4.2 - Item #2 - "A SAML requester MUST NOT send a second SAML
request element in a subsequent SAML request element."  I think this is also
an added restriction as well.

9.  Section 4.2 - I don't know if this goes here or someplace else, but
there may be an issue with an IdP being unable to satisfy the conditions in
an AuthzContext request.   Would this be returned as a SAML error and failed
authentication?  Note in this case no EAP would be run by the IdP.

10.  Section 6 - last sentence - who is the name identifier being
established for?

11.  Section 6.2 - Bindings: Eliminate the first sentence and just say that
it requires the SAML binding.

12. - Section 6.3.1 - The GSS Initiator not the GSS Acceptor invokes the GSS
EAP mechanism.    I think the language in this paragraph is being very
sloppy about what is happening.

13.  Section 6.3.4 - the text starting with "MAY issue" is fuzzy.  
  a) is it may issue or the issued response may be consistent w/ the
authentication result?  
  b) the A and B and C at the end of the sentence seems to meander without a
point.

14. Section 6.4.1  para #2 - Needs to say that a failure will occur if it
either will not or cannot satisfy the request.  MUST NOT do an access accept
using different criteria than asked for.

15. Section 6.4.2 para #3 - This paragraph actually bothers me for the
following reason.  It allows an RP to determine if a pseudonymous identifier
that is going to be specific to it will be returned or not.  (say don't
create and then say allow create).  It is not clear to me that this is
desirable behavior.

16. Section 6.4.2 - last bullet point - This is a partial address of a
previous point in this mail.  I think this is an incorrect statement.  I
think that the statement should be, if you return a response, you must have
a AuthnStatement that matches the request.  If you do not return a response,
then you are not bound to obey any of the requested context.  This set of
rules would allow the RP to determine if the request has been satisfied or
not.

17.  Section 6.4.3 - Bullet #2 - This implies some type of re-authentication
protocol.  As we are not having a GSS-EAP based server re-authentication
operation, does this need to be clarified here or is the text I am going to
put into the architecture document suffice?

Jim