> >Section 4: >The following text does not parse > The RADIUS SAML binding defined by this binding Section 5 uses two > attributes to convey SAML assertions and protocol messages > [OASIS.saml-core-2.0-os] respectively. > >I think it would be more clear if we move the reference after >respectively. >I don't think it's right to say that more and reserved are ignored. >More for example will be set often and reserved should be handled as in >RFC 6929.
I meant ignored in the sense of not depicted within the table, but happy with your change as it is less ambiguous. >Section 5: >"A SAML Responder that refuses to perform a message exchange with the >SAML requester MUST silently discard the request" > >Please clarify we mean ignore the attribute, not drop the entire RADIUS >packet on the floor. Yes, this needs clarifying. >It may well be that we generate an access reject as a result, but silent >discard at the radius level is not really what we want. >Section 5.3.1 > >Isn't the AAA server a SAML consumer of an authentication request? >If so, it seems like it's more realistic for it to apply policy based on >the NAS identity rather than the NAI realm as described in the text. Your following correction cleans this up, I think. >I wonder whether requester and responder might be better than issuer and >consumer in this section. Yes, you're right. I think those bullets now read correctly. >old: >A digitally signed request alone is not sufficient. >new: >A digitally signed request alone is not sufficient. A AAA entity can >include a SAML message that it observes that is never intended by the >issuing SAML entity for this AAA session. The new clarifying text is good. >How exactly would one include a realm identifier in metadata? That is, >is there well defined way to name a realm in SAML? Nope. I'll respond in the other thread. >Section 7.3.1`: >Is this request in the initial access-accept? Every access-accept? On your first question, this is unspecified because I don't think we need to be prescriptive. On your second question, the profile is explicitly defined as a profile of the SAML authentication request protocol, and that would not permit that kind of message exchange. Happy to include clarifying text on both counts. >Section 7.3.3: >Wait. You're saying that my RADIUS server MUST look inside the SAML >message and if a certain attribute is present go change my EAP state >machine? Where are you reading that? The text says "establish the identity [...] using RADIUS authentication" >I don't think anyone will ever implement that. Agreed, but that's not the intent! >Also, how does it interact with semi-long-term elements like Kerberos >TGTs or TEAP tickets? Out of scope. That's a problem at the RADIUS authentication level. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
