Subject: [abfab] Trying to get Plasma text correct.

From: "Jim Schaad" <[email-masked]>
Date: Fri, 16 Dec 2011 00:01:06 -0800

I am starting to try and develop text for the Plasma documents on how to use
GSS-API.  At least initially, I want to write it to be generic GSS-API and
then do specifics for the ABFAB GSS-API/EAP case.

To make my life simpler, we are going to require that the client/RP
transport method always be TLS.  Which means that I will at some point in
the future need to worry about cases where path validation is not completely
successful.  But I am planning to punt that issue for now.

So since we always know the name of the entity we are going to be talking
to.  My assumption is that we are always going to pass an acceptor name into
GSS-API.  The acceptor name would be "plasma/serverName@domainName".  We
would say strip the left most dotted name as the server name and leave the
rest as the domain name.   Thus an example name might be
"plasma\[email-masked]".

Now we start looking at some fun things.  

1.  If the url was
https://mailPDP.windows.example.com/internalPolicyChecker, should the extra
verbage be reflected in the service name string?

2.  Do we need to say anything special about walking up domain names when
doing checking or during AAA processing?  Specifically, should a domain
string be truncated when doing the channel binding processing called out in
the EMU channel bindings document wrt to the database lookup code?

3.  In the current code, one would expect that the client would send the
full name to the RP as part of the first GSS-API handshake message.  I still
feel somewhat uncomfortable with telling the RP what its full name is going
to be, but I don't see any way around this with the current GSS-API calling
code.  That is since I want the channel binding to occur w/ a specific
server and domain, there is no way not to let the RP know what they are
going to be in advance.  I understand that the AAA system will validate that
the RP has the right to the name so there should not be any issues, but is
there any way to make me feel  more comfortable with this?

4.  Since I am using TLS, I will need to specify that TLS channel binding
will occur (and find the appropriate references about how this works for
extraction).  I am still trying to debate if I need to include additional
channel binding data from my protocol dialog as well.  Has anybody written
any guidance on when this is recommended and what types of data need to be
included?  I think I have re-designed my protocol so this is no longer
necessary, but I would like some assurance that I am correct.

5.  If I get to this point, have I already selected the credential that I
will be using with the EAP server, or I have just gotten to the point of
saying that I will be using one of a set of credentials?  This is an LOA
question.  I will have already selected the realm that I am going to be
authenticated against since I know that goes out in the first GSS-API/EAP
message.  I also understand that by selecting a realm, I may have restricted
the set of possible LOAs that I can be dealing with.  Should my protocol
allow for some type of re-start of negotiation if a different LOA is needed?
I assume that would need to be a total re-start of the GSS-API/EAP
negotiation at a minimum although I could leave up the TLS session.

6.  Should I be setting up some type of negotiation in my protocol to allow
for a different GSS-API mechanism to be selected?  I.e. if one is within a
single company one could use the Kerberos GSS-API rather than going with the
EAP version.  Would be think this is of importance or can I just restrict to
using the one GSS-API mechanism and be done with it?  Can this type of
negotiation be done within GSS-API?  I don't remember seeing anything of
this sort but that does not mean it does not exist.  My understanding was
that it amounted to configuration information on the client side.

Jim

---

From: Nico Williams <[email-masked]>
Date: Fri, 16 Dec 2011 13:07:29 -0600

> successful.  But I am planning to punt that issue for now.

Since we're talking about doing channel binding the simplest thing to
do is to say that whatever certificate the server uses, you'll accept
-- i.e., simply turn off validation.  (Oh, you might want to say that
the cert must not be expired, and you'll definitely want to say
something about key algorithms and key sizes, but validation? just
turn it off.)

> to.  My assumption is that we are always going to pass an acceptor name into

You always know the name of the RP that you want to be talking to.

If you want to do GSS w/ CB to TLS then ignore the RP's name from TLS.
 Note that CB implies that GSS must authenticate the RP to the client.

> GSS-API.  The acceptor name would be "plasma/serverName@domainName".  We

Something like that, yes.

> "plasma\[email-masked]".

The details of this will likely be different.

I'd say that you'd use GSS_C_NT_HOSTBASED syntax: service@hostname
(FQDN).  If a "realm" is needed we'll either inspect the actual target
name after authentication completes or we'll use
GSS_Set_name_attribute() to set the expected realm name of the target
on the client side.  The mechanism's translation of this might be
service/hostname.fqdn@REALM, e.g., in the case of Kerberos.

> verbage be reflected in the service name string?

If the URL's scheme was HTTP and we're usign HTTP/Negotiate then the
RP's name should be [email-masked].  We could agree
to make it different, but that would break the current convention.  Or
we could use something other than HTTP/Negotiate.

> the EMU channel bindings document wrt to the database lookup code?

I don't understand this.  Are we talking about EAP channel binding
here instead of GSS channel binding?

> to be, but I don't see any way around this with the current GSS-API calling

It is not possible to design an authentication protocol that provides
privacy protection (from active attacks) to both peers, not without
having a trusted third party to which the two peers authenticate first
and which then decides if/what they should be allowed to know each
other.

Moreover, traffic analysis alone will generally disclose the name of
the RP, except in peer-to-peer applications.  Is this a p2p
application?

> there any way to make me feel  more comfortable with this?

What is the problem with the RP knowing what it was called by the
client?  (I'm not saying there can't be a problem, just that I want to
know it :)

> channel binding data from my protocol dialog as well.  Has anybody written

You certainly can!

> necessary, but I would like some assurance that I am correct.

CB can be used to provide [after-the-fact] integrity protection to
non-CB data that is sent in the clear before or during the GSS
security context token exchange.

More later, after lunch,

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 16 Dec 2011 16:25:59 -0600

> allow for some type of re-start of negotiation if a different LOA is needed?

It's always nice to be able to restart authentication if it fails.

SSHv2 supports multiple userauth attempts, but not multiple key
exchange attempts, which means that SSHv2 with GSS key exchange (an
option where we do GSS and key exchange in one go) is painful when GSS
fails.

I strongly recommend that authentication be retriable.  I believe
HTTP/Negotiate is (you're already using HTTP/1.1 if you're using
HTTP/Negotiate with multi-round-trip mechanisms anyways!).

Also, I don't think you'll always know the realm of the target a
priori.  Certainly not in the case of HTTP, not unless the realm
directly matches the server's DNS domain.

> negotiation at a minimum although I could leave up the TLS session.

Yes, it'd be a restart of GSS, but there'd be no need to restart TLS,
unless the application protocol really can't deal with the GSS
restart.

> for a different GSS-API mechanism to be selected?  I.e. if one is within a

If we're talking about HTTP/Negotiate well, you already have SPNEGO for that.

> that it amounted to configuration information on the client side.

SPNEGO is a pseudo-mechanism that negotiates mechanisms, so that's "within GSS".

Some application protocols can do this negotiation themselves.  For
example: SSHv2.

Nico
--

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 18 Dec 2011 12:02:07 +0200

Hi Jim, 

When you say "Plasma" you are referring to "The PoLicy Augmented S/Mime
(plasma)"
https://www.ietf.org/mailman/listinfo/plasma

Correct?

To judge whether it is useful to write about that work I have to admit
that I am not fully up-to-speed with the latest status of that effort. 

Can you shed some light on that? 

Ciao
Hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Jim Schaad
> Sent: Friday, December 16, 2011 10:01 AM
> To: [email-masked]
> Subject: [abfab] Trying to get Plasma text correct.
> 
> to.  My assumption is that we are always going to pass an acceptor
name
> into
> going to be in advance.  I understand that the AAA system will
validate
> that
> the RP has the right to the name so there should not be any issues,
but
> is
> any guidance on when this is recommended and what types of data need
to
> be
> 5.  If I get to this point, have I already selected the credential
that
> I
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 18 Dec 2011 12:32:15 -0800

The set of Plasma people is close to finishing the use case/architecture
document and already we have a fairly stable document for how CMS is used.
I am currently trying to get finished with a huge set of edits to the
client/server protocol document which includes the use of GSS-API as one of
the options.

However, many of the questions below fall into the category of how do you do
things with GSS-API/EAP and thus are not restricted to the Plasma work.

Jim

> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:[email-masked]]
> Sent: Sunday, December 18, 2011 2:02 AM
> To: ext Jim Schaad; [email-masked]
> Subject: RE: [abfab] Trying to get Plasma text correct.
> 
> Hi Jim,
> 
that I
> am not fully up-to-speed with the latest status of that effort.
> 
> > I am starting to try and develop text for the Plasma documents on how
> > to use GSS-API.  At least initially, I want to write it to be generic
> > GSS-API and then do specifics for the ABFAB GSS-API/EAP case.
> >
> > transport method always be TLS.  Which means that I will at some point
> > in the future need to worry about cases where path validation is not
> > completely successful.  But I am planning to punt that issue for now.
> >
> > So since we always know the name of the entity we are going to be
> > talking to.  My assumption is that we are always going to pass an
> > acceptor
> name
> > into
> > GSS-API.  The acceptor name would be
> "plasma/serverName@domainName".
> > We
> > https://mailPDP.windows.example.com/internalPolicyChecker, should the
> > extra verbage be reflected in the service name string?
> >
> > 2.  Do we need to say anything special about walking up domain names
> > when doing checking or during AAA processing?  Specifically, should a
> domain
> > string be truncated when doing the channel binding processing called
> > out in the EMU channel bindings document wrt to the database lookup
> > code?
> >
> > 3.  In the current code, one would expect that the client would send
> > the full name to the RP as part of the first GSS-API handshake
> > message.  I still feel somewhat uncomfortable with telling the RP what
> > its full name is going to be, but I don't see any way around this with
> > the current GSS-API calling code.  That is since I want the channel
> > binding to occur w/ a specific server and domain, there is no way not
> > to let the RP know what they
> are
> > 4.  Since I am using TLS, I will need to specify that TLS channel
> > binding will occur (and find the appropriate references about how this
> > works for extraction).  I am still trying to debate if I need to
> > include additional channel binding data from my protocol dialog as
> > well.  Has anybody written any guidance on when this is recommended
> > and what types of data need
> to
> > be
> > will be using with the EAP server, or I have just gotten to the point
> > of saying that I will be using one of a set of credentials?  This is
> > an LOA question.  I will have already selected the realm that I am
> > going to
> be
> > authenticated against since I know that goes out in the first GSS-
> > API/EAP message.  I also understand that by selecting a realm, I may
> > have restricted the set of possible LOAs that I can be dealing with.
> > Should my protocol allow for some type of re-start of negotiation if a
> > different LOA is needed?
> > 6.  Should I be setting up some type of negotiation in my protocol to
> > allow for a different GSS-API mechanism to be selected?  I.e. if one
> > is within a single company one could use the Kerberos GSS-API rather
> > than going with the EAP version.  Would be think this is of importance
> > or can I just restrict to using the one GSS-API mechanism and be done
> > with it?  Can this type of negotiation be done within GSS-API?  I
> > don't remember seeing anything of this sort but that does not mean it
> > does not exist.  My understanding was that it amounted to
> > configuration information on the client side.
> >
> > Jim
> >
> >