Subject: [abfab] charter take 5

From: Leif Johansson <[email-masked]>
Date: Tue, 24 Aug 2010 21:19:33 +0200

This is a version with Nicos GSS-API contraints folded in. I've left the
Goals and Milestones folded into in the Deliverables section - we can
separate them when we reach consensus on the charter.

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 24 Aug 2010 14:54:00 -0500

On Tue, Aug 24, 2010 at 09:19:33PM +0200, Leif Johansson wrote:
> Abfab - Application Bridging for Federated Access Beyond web

I only have nits, and they're not really worth exploring (e.g., the
second sentence of the first paragraph could be replaced with "This is
needed for scalability.", but I don't mind all that extra verbiage :).

We might need more RFC references in this paragraph:

 - GSS_Pseudo_random() [RFC4401]
 - SASL [RFC4422]
 - GS2 [RFC5801]

> In order to be usable in all current Internet protocols, GSS-API 
> [...]
> 
> The working group will ensure that any solution developed has technical 
> controls for privacy protection.

Presumably that's privacy of protection only for the client/initiator/
user identity and attributes, protection from eavesdroppers.

> The deliverables of the working group are:

The GSS mechanism itself is missing from this list!  :)

Otherwise it looks good to me.  Cheers,

Nico
--

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Aug 2010 22:24:33 +0200

I'm sorry I couldn't comment sooner, Leif, and while I can live with
what is proposed, I do think discussion of particular functions such as
GSS_Pseudo_random() is really getting us WAY into the weeds.  Do we have
to NOW have the discussion of just when GSS_pseudo_random() is
appropriate?  That seems like a working group item.  As such, I prefer
"take 4".

Eliot

> separate them when we reach consensus on the charter.

_______________________________________________
abfab mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/abfab

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 24 Aug 2010 15:37:13 -0500

> appropriate?  That seems like a working group item.  As such, I prefer

That paragraph is carefully worded.  It does not say that
GSS_Pseudo_random() is required; GSS_Pseudo_random() is optional.  That
paragraph does list the other GSS-API features that are required.  Those
features are required because the Internet application protocols that
the WG is targeting that use the GSS-API... require those features.

Listing those features that are required by such applications is rather
useful: it helps explain that the requirements discussed in earlier
threads on this list are neither capricious nor constructed in such a
way as to keep specific technologies out of scope -- these requirements
are an indirect result of the stated primary goal.  Dispensing with
these requirements would require abandoning that goal.

Without stating those requirements the WG will re-live such threads.

I much prefer take 5 to take 4, and not just because I contributed that
paragraph.

Now, I'd not oppose removing the bit about GSS_Pseudo_random().  But it
is a useful reminder for the authors that there's really no good excuse
to not provide it given that the necessary key exchange is also an
implied requirement of per-message token ("security layers") support.

If you disagree with specific requirements listed in that paragraph,
then we should discuss that.  But if you don't, then why remove that
paragraph?

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Wed, 25 Aug 2010 09:23:31 +0200

> then we should discuss that.  But if you don't, then why remove that

Strictly speaking as a participant and in no way as any other kind of
animal, real, fictional or mythological I am inclined to agree with
Eliot.

To me it sounds like part of a very good requirements document for
the GSS-API interface which *begs* to be written by Nico :-)

I'd be inclined to include _some_ text in the charter to state something
along the lines of "The WG must seek guidance on any work on GSS-API
mechanisms from the KITTEN working group." This is analogous
with our other coordination requirements.

However I am also dis-inclined to re-open this can of worms.

I am also worried that we're loosing our audience!

	Cheers Leif

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Aug 2010 11:24:21 +0200

> then we should discuss that.  But if you don't, then why remove that

Because this is precisely the discussion that should happen IN the
working group when there is more code and more experience.  We are meant
to have a starting point, Nico, and not an end point.  And while I agree
that we should have constraints on the group, saying that we would begin
with a set of documents and that the basis of the work will be GS2/EAP,
to me covers the ground adequately.  Engineering inside the charter can
be taken too far.

Eliot

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 25 Aug 2010 13:46:54 +0200

On 8/25/10 9:23 AM, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

I would prefer to leave the first bit that talks about functional 
requirements (mutual authentication, key confirmation etc.) in (the 
"what" we want to achieve) and remove the implementation requirements 
(GSS_Pseudo_random etc., the "how" we want to achieve that). I think the 
latter is typical something that should be discussed in the WG rather 
than beforehand.

Klaas

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Aug 2010 08:09:11 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    >> then we should discuss that.  But if you don't, then why remove that

    Eliot> Because this is precisely the discussion that should happen IN the
    Eliot> working group when there is more code and more experience.  We are meant
    Eliot> to have a starting point, Nico, and not an end point.  And while I agree
    Eliot> that we should have constraints on the group, saying that we would begin
    Eliot> with a set of documents and that the basis of the work will be GS2/EAP,
    Eliot> to me covers the ground adequately.  Engineering inside the charter can
    Eliot> be taken too far.

Eliot, you're doing a great job of convincing me that we need to be When
Nico proposed this text, I thought it was kind of redundant; I thought
we were all agreed there.

These requirements are things that three people very familiar with GSS
have wanted: Simon, Nico and myself.

I know for myself that if we work on something that does not meet these
constraints I'd consider the work somewhere between completely useless
and actively harmful.  So, to me, these are the sort of constraints that
affect whether the work is worth doing.

I agree the text is verbose, and I'd like to avoid saying it in the
charter.  However, this is exactly a discussion I don't want to have in
the WG because it strikes at whether the resulting mechanism will be
useful from a security standpoint and at what our scope is.  I'm not
trying to close down discussion.  I'm trying to say that if there is
disagreement on this issue it should be handled with the greatest
urgency--before we get started.

So, I'd like to explore why you believe the discussion should happen in
the WG?  Do you believe we lack the necessary expertise here? Do you
believe that these may not be requirements for our work being useful?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Aug 2010 08:13:11 -0400

>>>>> "Klaas" == Klaas Wierenga <[email-masked]> writes:

    Klaas> I would prefer to leave the first bit that talks about functional
    Klaas> requirements (mutual authentication, key confirmation etc.) in (the
    Klaas> "what" we want to achieve) and remove the implementation requirements
    Klaas> (GSS_Pseudo_random etc., the "how" we want to achieve that). I think
    Klaas> the latter is typical something that should be discussed in the WG
    Klaas> rather than beforehand.

Can you propose exact text?  This might work for me.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Aug 2010 14:35:55 +0200

Sam,

I for one don't understand why a specific PRN call interface needs to be
specified at all.  Even calling this specific interface guarantees you
nothing by way of PRN quality.  If someone is really concerned, they're
going to have to go under the hood anyway.  And so perhaps you or Nico
could explain precisely WHY it needs to be in the charter, as opposed to
in a document, and even if  it's going in a document at least a brief
explanation would be in order.

Again, I think we're going WAY TOO FAR (not a little- WAY TOO FAR) which
leads to the sort of bureaucratic silliness when problems are found with
an approach down the road.

This would be like adding into Applications Area charter the specific
names of commands to be used with their specific connotations.  Nobody
does that because it's unnecessary.

Eliot

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 25 Aug 2010 14:59:13 +0200

On 8/25/10 2:13 PM, Sam Hartman wrote:
>>>>>> "Klaas" == Klaas Wierenga<[email-masked]>  writes:
>

I'd propose:

"In order to defend against phishing attacks GSS-API
mechanism must provide host-based service naming, mutual authentication 
and support for channel binding"

In combination with Leif's suggestion:

"The WG must seek guidance on any work on GSS-API
mechanisms from the KITTEN working group."

I am not so sure about the host-based service naming requirement, but am 
happy to trust your guidance on this.

Klaasd

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Aug 2010 09:29:24 -0400

I'm noticing that the folks who have worked with GSS-API seem more
comfortable with Nico's text than the rest of the community.
Let me go through Nico's requirements and explain why they're needed in
order to accomplish our goals.

* Mutual authentication: Required by RFC 4462 in order to work with SSH
  and RFC 5801 for XMPP, SMTP, IMAP, LDAD, and the like.  You introduce
  MITM attacks for CALDAV, WEBDAV, ATOM and the like if you use GSS to
  authenticate without mutual authentication.

* Channel binding: required by RFC 5801 if we want to support IMAP,
  XMPP, LDAP, and the like.

* Per-message security services (gss_wrap, gss_get_mic, the like):
  Required by RFC 4462 if we want to support SSH. Required by
  NFS. Required by CIFS.
\
* Host based service naming: Required by RFc 4462 for ssh, RFC 5801 for
  XMPP, IMAP, SMTP, and the like. Required for CALDAV, WEBDAV, ATOM, and
  the HTTP protocols. Required by NFS. Probably required by CIFS
  although that's more complicated.

* gss_pseudo_random: Required by some of the JANET applications and by
  RXGK, the AFS distributed filesystem security class. This is less of a
  requirement than the previous items, although once you have
  per-message security, gss_pseudo_random is trivial.

* key confirmation: Required for channel binding to provide meaningful
  security.

So, if we don't meet Nico's requirements then we cannot actually work
with most of the applications we want to work with.

However, for me, that's not the most important motivation.  I've been
working on security systems that are more resistant to phishing than the
web for a long time. These technical requirements will meet the higher
level requirements necessary to provide the technical aspects of good
phishing defense. It happens these requirements are a fairly good
mapping of the most important issues discussed in
draft-hartman-webauth-phishing to non-web applications.  So, that's why
I personally care a lot about these issues and whether these are going
to be part of the solution significantly affects how good of an idea I
think doing the work is.  I can totally appreciate that someone might
disagree with me, but I hope you can understand why I care about the
issue.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Aug 2010 09:38:50 -0400

>>>>> "Klaas" == Klaas Wierenga <[email-masked]> writes:

    Klaas> I'd propose:

    Klaas> "In order to defend against phishing attacks GSS-API
    Klaas> mechanism must provide host-based service naming, mutual
    Klaas> authentication and support for channel binding"

Your text is insufficient to work with SSH, NFS, or CIFS.
How about:

In order to be usable in all current Internet protocols, GSS-API
mechanism must provide the following features: mutual authentication,
key confirmation, host-based service naming, per-message tokens and
channel binding.  As a result, all of those features are required for
GSS-API and SASL mechanisms produced by this WG. Support for
GSS_Pseudo_random() is desirable. Other application integration
strategies are very likely to mirror these constraints.  In particular,
service naming, mutual authentication and support for channel binding
are likely to be important for defense against phishing attacks.

    Klaas> In combination with Leif's suggestion:

    Klaas> "The WG must seek guidance on any work on GSS-API
    Klaas> mechanisms from the KITTEN working group."

I don't think this constraint is needed: I think we have sufficient GSS
 expertise, but can live with it if consensus requires it.

    Klaas> I am not so sure about the host-based service naming requirement, but
    Klaas> am happy to trust your guidance on this.

It didn't have to be host-based,except that we need to work with
deployed code.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Aug 2010 15:40:42 +0200

Sam,

Perhaps our differences are fairly small then.  When I go down your
list, I agree with everything you've written at the high level, with one
exception:

On 8/25/10 3:29 PM, Sam Hartman wrote:
> * Mutual authentication

Absolutely.

> * Channel binding

I agree as long as we have a clear understanding of what is being bound.

> * Per-message security services

I *probably* agree.

>  (gss_wrap, gss_get_mic, the like):
> * Host based service naming

At a minimum.

> * gss_pseudo_random:

Here's the test as to whether it should be in the charter– If I *DON'T*
implement it, will you notice on the other side?  If not, what's all the
commotion?

> * key confirmation

Ok.

See how close we are?!

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Aug 2010 10:02:04 -0400

>> * Channel binding

    Eliot> I agree as long as we have a clear understanding of what is being bound.
I think we're talking about RFC 5554 and RFC 5056.

    >> * gss_pseudo_random:

    Eliot> Here's the test as to whether it should be in the charter– If I *DON'T*
    Eliot> implement it, will you notice on the other side?  If not, what's all the
    Eliot> commotion?

First, while I'd like to end up with this requirement, this is
definitely the area where compromise is easiest.  However, let me
explain what it does then you'll perhaps agree it is desirable.

The idea behind gss_pseudo_random is that once you have GSS set up, both
sides can get the same value out of gss_pseudo_random.  So, assume you
have some other cryptographic protocol--you want to encrypt some media,
or do something else.  Your other protocol works with preshared keys but
doesn't handle authentication.  Without actually exchanging the key, you
can call gss_pseudo_random on both sides and get the same key to fall
out.  It's a way of safely using the fact that you have a GSS-API
context to get good cryptographic keys for other purposes without adding
round trips.  So, it's absolutely critical that both sides ends up with
the same value or the later crypto fails.

You might ask whether it would be simpler to just have a function to
give the application the GSS-API context key to do with as it liked.  It
turns out that's bad from a crypto design standpoint: the key might not
be of the right format and using the same key for different purposes
introduces problems. gss_pseudo_random is relatively easy to use and
provides protection against these problems.

The down side to gss_pseudo_random is that it's not widely used today.
The main reason for that is that it was specified after most
applications already supported GSS-API. So it took a long time to get
implemented for Kerberos. At this point, you could use it in a new
application for Kerberos and have a high enough chance it would be
available that it might be worth doing. (You'd have to do extra work on
Windows, but that work is possible).  See draft-howlett-radsec-kmp for
one of a couple of examples of how Moonshot plans to use
gss_pseudo_random.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Aug 2010 09:35:52 -0500

> I agree as long as we have a clear understanding of what is being bound.

RFCs 5056 and 5929.

> > * Per-message security services

Without that you lose SSHv2 and NFSv4 support, for example (and
GSS-TSIG, and SMB, and...).

> > * Host based service naming

Oh, indeed, it certinly shouldn't be a maximum!  There's also
domain-based service names, and we can always introduce new types of
names.

> implement it, will you notice on the other side?  If not, what's all the

I called it optional.  Sam mentions apps that need it, but none are
Internet apps (i.e., IETF standards-track apps).

What's the harm in listing this as optional?  And why do you find it so
onerous?

> See how close we are?!

Very, evidently.  I strongly agree with Sam that the paragraph in
question needs to stay.  Wordsmithing is OK, but the requirements and
their rationale need to stay, and the debate over them needs to be had
now (we've been having it).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Aug 2010 09:42:22 -0500

> I think we're talking about RFC 5554 and RFC 5056.

And RFC5929.

> explain what it does then you'll perhaps agree it is desirable.

Your explanation is good, but it can be simplified: GSS_Pseudo_random()
is a keyed PRNG, where the key derives from the same shared key material
used for GSS per-message tokens (security layers).

And the implementation story is wonderful: surely you'll want to re-use
RFC4121's (Kerberos) per-message tokens, for why bother designing new
ones?  If so you'd also be happy to re-use RFC4402 (Kerberos'
GSS_Pseudo_random()).

Even if you don't want to re-use RFC4121/RFC4402, as long as you have
key material shared between the GSS initiator and acceptor (which you
need for security layers anyways), it's still trivial to derive a key
for a keyed PRNG.

Nico
--

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Aug 2010 16:52:34 +0200

Sam,

Thanks for the explanation.  But here's the thing: the specification for
gss_pseudo_random doesn't actually explain the algorithmic
transformation to get the pseudo-random data.  The algorithm isn't
standardized.  How do two sides, then, end up with the same value?

Eliot

On 8/25/10 4:02 PM, Sam Hartman wrote:
>     Eliot> Here's the test as to whether it should be in the charterâ€“ If I *DON'T*

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Aug 2010 11:03:40 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Sam,
    Eliot> Thanks for the explanation.  But here's the thing: the specification for
    Eliot> gss_pseudo_random doesn't actually explain the algorithmic
    Eliot> transformation to get the pseudo-random data.  The algorithm isn't
    Eliot> standardized.  How do two sides, then, end up with the same value?

RFC 4401 provides the application interface.  That isn't sufficient to
get interop.  RFc 4402 describes how to get interop for Kerberos.

In particular, it says that you use the pseudo_random operation from
your Kerberos encription type So, RFC 4402 tells to you to go read RFC
3961 and do roughly what that says.  RFC 3961 does tell you how to get
pseudo_random for DEs and 3DES.  It sends you off to RFC 3962 for AES.

The Kerberos RC4 RFC tells you how to do this for RC4.

For GSS-EAP, we plan to inheret the above algorithm, although obviously
that's up to the WG.

Now, that is kind of a twisty mess of RFCs.  We do have interoperability
for this: draft-ietf-krb-wg-preauth-framework includes test vectors for
krb-fx-cf2, which heavily depends on the RFC 3961 PRF.  We did find some
issues putting together those test vectors.  One of those is that people
found it to be a lot of specifications to wade through to get the bits
they needed.  So, it may well be that the Kerberos and GSS community
have some work to do to make this easier to implement,but I am aware of
three implementations of the RFC 3961 code and two implementations of
RFC 4402.

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 25 Aug 2010 17:08:06 +0200

Sam,

Thanks for the explanation, very helpful to me at least!

Klaas

---

From: Luke Howard <[email-masked]>
Date: Wed, 25 Aug 2010 17:10:16 +0200

> standardized.  How do two sides, then, end up with the same value?

It is specified in the concrete GSS mechanism specification.

eg. RFC 4402 is for Kerberos. One would be specified here too.

-- Luke

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Aug 2010 10:11:02 -0500

I meant "PRF" not "PRNG".  Please excuse that slip.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Aug 2010 17:15:35 +0200

Ok.  I officially Get It.  If you want it in the charter, given that
there IS interoperability work to be done, I'm cool with that.

Thanks for your patience.

Eliot

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Aug 2010 10:19:27 -0500

> eg. RFC 4402 is for Kerberos. One would be specified here too.

And we'll almost certainly want to re-use Kerberos', just we'll almost
certainly want to re-use Kebreros' per-message tokens.

Re-use is a good thing.

Now, I agree with Sam's point that we should work to make the generic
bits of RFC4121 and RFC4402 more easily re-usable by re-packaging them
into new specifications.  Implementation-wise we should do the same.

Implementation-wise it'd be nice to be able to break up, say, the MIT,
and/or Heimdal, and/or Shishi, and/or...  krb5 library and mechanism
into these components:

 - re-usable crypto framework (RFC3961, RFC3962)
 - re-usable GSS internal context crypto bits:
    - re-usable GSS per-message tokens [RFC4121]
    - re-usable GSS PRF [RFC4121]
 - the rest of libkrb5
 - the actual krb5 GSS mech

so that the last two items could be left out of a distribution of a
mechanism that re-uses RFC4121 tokens and RFC4402 PRF.

Some implementations may be almost there to a large degree (at least as
to the crypto framework).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Aug 2010 11:21:37 -0500

On Wed, Aug 25, 2010 at 01:46:54PM +0200, Klaas Wierenga wrote:
> "what" we want to achieve) and remove the implementation
> requirements (GSS_Pseudo_random etc., the "how" we want to achieve
> that). I think the latter is typical something that should be
> discussed in the WG rather than beforehand.

I'm having trouble understanding the distinction between "functional
requirements" and "implementation requirements".

As far as the GSS-API is concerned, there's no functional/implementation
difference between "mutual authentication" and "per-message tokens".
They're all features.  And they're all features that the relevant
Internet applications require.

My guess is that the fact that one of these features is called out by a
[abstract] function name makes readers think it's an implementation
detail.  It's not.  I should have said "PRF", and I'd bet (if I somehow
could) that if I'd written "PRF" instead of the function's name then
there'd have been no controversy.

In fact, that's the change that I suggest: s/GSS_Pseudo_random/PRF/.

Nico
--

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 25 Aug 2010 19:50:19 +0200

Hi Nico,

> requirements" and "implementation requirements".

Let me give an example from a technology area I am more familiar with, 802.1X and EAP/RADIUS.

Functional Requirement: mutual authentication of client and server 
Technical Implementation: use EAP-TLS (for example)

> difference between "mutual authentication" and "per-message tokens".

To me they are of a different order, mutual authentication states that both ends of the communication need to be able to verify each others identity, but not how. Whereas per-message tokens are a way of implementing message integrity/confidentiality, presumably you could achieve the latter also by using a per-flow token or something like that. So per-message tokens are to me an implementation choice (with obvious benefits). 

Sam's explanation answered for me the question why we would require these "implementation choices", namely to satisfy requirements from existing protocols that we want to support with our solution.

> In fact, that's the change that I suggest: s/GSS_Pseudo_random/PRF/.

Actually that would work better for me, because more generic indeed, though the question remains "why do we need PRF, what does it buy us?"

Does this make more sense to you?

Klaas

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 25 Aug 2010 13:20:28 -0700 (PDT)

Draft charter says:

  Specifically EAP will be used to authenticate the subject to a trusted
  party, AAA (RADIUS and Diameter) will be used to authenticate and convey
  information from that party to a relying party and SAML is used for
  authorization and personalization.

This SAML text seems insufficient.  As far as I can tell there are no 
plans to use SAML protocol for anything, just SAML message formats 
encapsulated in RADIUS.  And "used for authorization" is profoundly vague. 
I hope this vagueness is just due to lack of attention rather than lack of 
clarity on how SAML will be used.  So perhaps better text is:

  ... and SAML message formats are used to carry subject information that
  can be used for authorization and personalization by a relying party.

  - RL "Bob"

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Aug 2010 15:32:08 -0500

On Wed, Aug 25, 2010 at 07:50:19PM +0200, Klaas Wierenga wrote:
> > As far as the GSS-API is concerned, there's no
> > functional/implementation difference between "mutual authentication"
> > and "per-message tokens".
> 
> To me they are of a different order, mutual authentication states that
> both ends of the communication need to be able to verify each others
> identity, but not how. Whereas per-message tokens are a way of
> implementing message integrity/confidentiality, presumably you could
> achieve the latter also by using a per-flow token or something like
> that. So per-message tokens are to me an implementation choice (with
> obvious benefits). 

I don't know what "per-flow token" would be.  There are only these
choices in the GSS world:

 - per-message tokens
 - channel binding
 - nothing

The last one, I think we'll all agree, is not a very good choice as the
only required to implement option!

Now, most GSS apps use per-message tokens, and most SASL apps will be
using channel binding only (except for legacy GS1 implementations, which
use and will continue to use per-message tokens).

I don't see how we could say that we want this new mech to be usable in
Internet GSS/SASL apps, say this requires mutual authentication, and not
say that this requires per-message tokens (for some apps) and channel
binding (for other apps).  I think that'd be gaping hole in the
requirements list.

> Sam's explanation answered for me the question why we would require
> these "implementation choices", namely to satisfy requirements from
> existing protocols that we want to support with our solution.

Right.  But they are not implementation choices, they are specification
choices; the choice was made when we chose to target those apps.

An implementation choice would be to use a C/Java/Python/Ruby/C++/Perl5/
ECMAScript/PHP/Clojure/whatever function/method named anything like
'GSS_Pseudo_random'.  That is completely beyond the scope of this WG.

The string 'GSS_Pseudo_random' in this context denotes a GSS-API
feature, much as GSS_Wrap and GSS_GetMIC would.

> Actually that would work better for me, because more generic indeed,
> though the question remains "why do we need PRF, what does it buy us?"

Sure.

> Does this make more sense to you?

I understand the desire to s/GSS_Pseudo_random/PRF/.

I don't quite understand the rest but I think the issue really is that
GSS-API _abstract_ "function" (and type, and constant) names resemble
implementation details in the sense of function/class/method/... names
for specific programming languages.  Rest assured: use of the _abstract_
GSS-API nomenclature implies no requirement for specific implementation
choices regarding names, function/method signatures, etcetera in
whatever programming language an implementor chooses.

(I don't see why an implementor would not use straightforward [or
standard, where there is one] bindings of the abstract GSS API to
whatever programming language they are using, but hey, that's none
of my business.)

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Wed, 25 Aug 2010 22:39:54 +0200

On 08/25/2010 10:20 PM, RL 'Bob' Morgan wrote:
> and SAML message formats are used to carry subject information that

I think this makes the text more readable and arguably more correct. I
missed it for v6 but unless people have a problem with this it will go
into the final (I'm being that optimistic tonight) version.

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Aug 2010 15:41:54 -0500

On Wed, Aug 25, 2010 at 01:20:28PM -0700, RL 'Bob' Morgan wrote:
> This SAML text seems insufficient.  As far as I can tell there are
> no plans to use SAML protocol for anything, just SAML message
> formats encapsulated in RADIUS.  And "used for authorization" is
> profoundly vague. I hope this vagueness is just due to lack of
> attention rather than lack of clarity on how SAML will be used.  So
> perhaps better text is:
> 

I like your text.

I think we could resolve the vagueness by relating these SAML assertions
to GSS-API name attributes[*].  However, I fear that this might only
serve to confuse those who don't have a deep background in the GSS-API.
And either way, the point is that these can be used "for authorization
and personalization by a relying party".

Nico

[*] For the benefit of those who aren't aware of it, "name" and "name
    attribute" (and "credential", and so on) have very specific meanings
    in the GSS-API world.

    A GSS "name" is actually an instance of an abstract API type called
    "NAME", and it represents a "principal" (a user, a host-based
    service, etcetera).

    A "name attribute" refers to attributes of a principal other than
    its "display name" (a display name is the string that a program
    would display to a user as being the name of a principal).  Name
    attributes are not yet standard, though they are implemented in
    shipping products.

    I could go on.  I really need to find the time to author a gentle
    introduction to the GSS-API as an Informational RFC.  Given that
    this WG will bring a wider audience in contact with the GSS-API (and
    SASL), it's really about time I got around to that.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Aug 2010 17:30:34 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    >> can be used for authorization and personalization by a relying party.

    Leif> I think this makes the text more readable and arguably more correct. I
    Leif> missed it for v6 but unless people have a problem with this it will go
    Leif> into the final (I'm being that optimistic tonight) version.

Well, we do plan to use the SAML attribute query protocol, and in the
current drafts, it is possible to send a SAML authentication request.
So, one could quibble about whether it's just SAML message formats or
not.
However we definitely are using SAML message formats and the rest of the
text definitely adds clarity.
So, I'm OK with it.

---

From: Luke Howard <[email-masked]>
Date: Thu, 26 Aug 2010 14:12:00 +0200

> to GSS-API name attributes[*].  However, I fear that this might only

Right, and isn't sorting this out part of the work to be accomplished?

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Thu, 26 Aug 2010 14:12:55 +0200

> whatever programming language an implementor chooses.

Right, if I had no prior GSS-API knowledge, I would likely be making the same criticism.

+1 for Nico's comments above.

-- Luke

---

From: Klaas Wierenga <[email-masked]>
Date: Thu, 26 Aug 2010 14:35:51 +0200

> +1 for Nico's comments above.

ok, criticism "withdrawn" ;-)

Klaas

---

From: Josh Howlett <[email-masked]>
Date: Thu, 26 Aug 2010 16:07:54 +0000

> text definitely adds clarity.

+1

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG