Subject: [abfab] #19: Setion 1.4 - Overview -

From: "abfab issue tracker" <[email-masked]>
Date: Sun, 11 Dec 2011 01:19:26 -0000

#19: Setion 1.4 - Overview -

 a)  I think you might need to have a step 2a - Client Application creates
 a channel to the RP.  This is not done by the GSS-EAP mechanism as I had
 originally assumed.  Let's make it clear additionally that fact will be
 needed in order to setup the channel binding at a later time.  Note that
 at some point there will need to be a discussion of the properties of this
 channel.  It should also be noted that the type of channel used
 potentially provide different issues.

  b) in step 5  either /forward a RADIUS request/ or /forward RADIUS
 requests/.  AAA ignorance - would message be better than request to avoid
 confusion between RADISU request and GSS/EAP request?

 c) Step #5 - I would ignore how the SAML request is encoded at this point.
 So maybe s/SAML request as a series of attributes/ SAML request for a set
 of attributes/ s/.././

 d) in step 9, I think I have a problem with the last sentence.  These
 policy checks would have been done by the AAA system or the RP and not by
 the IdP.
 As such I don't think the title for the paragraph makes sense.

 e)  Step 10, Is the sentence at the end of the paragraph wrong?  Is it
 returned to the subject (not covered by the
 title) or the RP?  The subject should already have the MSK.  There is a
 difference between two types of EAP procedures.  One where the MSK is
 published to the Principle and one where the Principle derives the key
 (thus allowing for mutual auth to occur).  I believe that the trust model
 is requiring the later.  Also note - subject should be principle in this
 text.

 f) I don't understand part of step 11 --  It may have information that
 leads it to make additional attribute queries.  I can see it needing to
 make additional attributes because it needs more information, but not
 because it has the information it needs.

-- 
--------------------+-------------------------------------
 Reporter:  ietf@…  |      Owner:  draft-ietf-abfab-arch@…
     Type:  defect  |     Status:  new
 Priority:  major   |  Milestone:
Component:  arch    |    Version:
 Severity:  -       |   Keywords:
--------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/abfab/trac/ticket/19>
abfab <http://tools.ietf.org/abfab/>

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Dec 2011 12:21:04 -0600

>  potentially provide different issues.

See my other reply, from yesterday, regarding channels.

The TLS channel is optional, not required.  True, there cannot be
channel binding if there's no channel to bind to, but an application
that doesn't do channel binding will presumably be using GSS
per-message tokens, thus using GSS itself as a channel.

As to desired properties of channels, RFC5056 should suffice.  In
practice the channel will always be TLS, thus also needed is RFC5929.

>  confusion between RADISU request and GSS/EAP request?

We should use "security context token", or just "token" to refer to
GSS messages in this section.

We definitely need to be careful to not confused terminology.

Nico
--