Issue 1: Comments for RFC 2486bis Last Call
Submitter: Pasi Eronen
Submitter email address:
pasi.eronen@nokia.com
Date first submitted: August 17, 2004
Reference:
http://ops.ietf.org/lists/radiusext/2004/msg00680.html
Document: RFC
2486bis-02
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Some minor comments about draft-arkko-roamops-rfc2486bis-02:
- In
Section 2.1, on the line
c
=/ %x2b ; '*'
allowed
the '*' in the comment should be '+'
- In Section
2.1, the line
c
=/ %x5e-7e ; '^' - '
allowed
would probably be easier to understand if written out:
c =/ %x5e
; '^'
allowed
c
=/ %x5f ; '_'
allowed
c
=/ %x60-7a ; 'a'-'z'
allowed
c
=/ %x7b ; '{'
allowed
c
=/ %x7c ; '|'
allowed
c
=/ %x7d ; '}'
allowed
c
=/ %x7e ; '~'
allowed
- In Appendix A, fourth bullet: it seems there are no
stricter requirements on the part preceding the '!'
sign _unless_
it's explicitly known that this realm
supports this syntax.
So it's not a backwards-compatibility problem: something
like "foo!bar@example.com" continues to be a valid NAI
(even though "foo" is not a valid realm) unless it's
known that
example.com uses the stricter syntax
from section 2.7.
[Jari Arkko]
Working group last call completed on this document some
time ago. I have now put a modified draft revision and diffs
at
http://www.arkko.com/publications/nai/naibis.txt http://www.arkko.com/publications/nai/naibisdiff.html
The modifications include a few editorial improvements
on the ABNF that Pasi suggested, a couple of other
editorial things, and the removal of a claim that
the bis version '!' puts stricter requirements on the
parts preceding the '!' sign than in RFC 2486.
Proposed Resolution: Accept
Issue 2: IKEv2 Compatibility
Submitter: Jari
Arkko
Submitter email address:
jari.arkko@piuha.net
Date first submitted: August 17, 2004
Reference:
http://ops.ietf.org/lists/radiusext/2004/msg00679.html
Document: RFC
2486bis-02
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
First some background: In traditional EAP usage, the client's identifier
has been determined through the EAP Identity Request/Response exchange.
The
identifier is typically a Network Access Identifier (NAI). Basically
an
identifier similar to an e-mail address, used to identify the user
and to
find the right home network in case of a roaming user.
IKEv2-14 says the
following:
Note that since IKE passes an indication of initiator identity
in
message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be
used.
it also defines one of the identity type as follows:
ID_RFC822_ADDR 3
A fully-qualified RFC822 email address string, An
example of
a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST
not
contain any terminators.
In the RADEXT and EAP WGs, we have recently
discussed some
problems that this causes. Here are the issues:
1. A
revision of the NAI specification, RFC 2486bis, intends
to extend the
existing user@domain format in
draft-arkko-roamops-rfc2486bis-02.txt,
partially based on
existing practise. This spec is currently in WGLC in the
RADEXT WG.
One of the extensions is to allow the client's identity
to
be hidden from the access server / IKEv2 gateway,
if the used EAP method
supports end-to-end encrypted
tranmission of the identity. Syntactically,
this
happens through specifying an empty username, "@domain"
but keeping
the domain pawrt in order to make the AAA
routing possible.
The issue
with IKEv2 is strictly speaking, this
string would be illegal in RFC 822.
Hence an IKEv2
implementation can not be relied upon to accept such
"privacy" user names.
2. Another extension from this draft is
internationalized
NAIs. The domain parts are IDNs, i.e., converted to ASCII
via a specific mapping, but the username part is UTF-8.
Again, this is
strictly speaking not conformant to RFC 822,
so sending an internationalized
username via IKEv2 might
not be possible. For instance, someone might be
assigned
a username for WLAN access, but the usage of this username
for
IKEv2 purposes might not be possible if it contains
international characters.
Some of the possible solutions to avoid this problem include
o Decide
that support of privacy & international usernames
is not necessary in IKEv2.
o Remove the privacy and international username (not domain)
parts from RFC
2486bis.
o Change the international username part so that instead of
UTF-8, it uses a IDN-like ASCII mapping which can represent
non-ASCII
characters but it looks like ASCII to the carrier.
Either remove the privacy
feature or just say it can not
be used in all carrier protocols.
o
Define a new IKEv2 ID type to carry the new types NAIs.
(If so, would this
type be defined in the NAIbis, IKEv2
or some other draft?)
o Rely on
IKEv2 implementations to not check the contents
of the identifier for RFC 822
compliance.
o Go against the SHOULD NOT when the given NAI requires this.
3. Ongoing work (and some existing practise) provides some
information
through the EAP identity request. More specifically,
the client can get a
hint of what type of identifier it should
offer. See
draft-adrangi-eap-network-discovery-03.txt.
This functionality does not
appear to be present when running
EAP over IKEv2. (I have not heard of any
customer who wanted
this functionality in this context, but I'd like to avoid
special cases where possible.)
[Charlie Kaufman]
I agree that this is likely to become a problem, that any of your
'possible solutions' could be used to fix it (except that I don't
believe the
first two 'define the problem away' were serious proposals),
and that the
community SHOULD agree on one standard approach to maximize
interoperability.
My favorite would be:
o Go against the SHOULD NOT when the given NAI requires
this.
...because this also addresses the identity type hint that you say
might
be coming. But others have argued heatedly that it is important to
minimize the number of messages in an IKE exchange, and this would
result in
an eight message exchange while some of the other proposals
work in six.
I'm really glad it's not my job anymore to herd the cats towards one
approach
or the other.
--Charlie
p.s. If you are going to define a new ID
type, it would need to be added
to the IANA registry for IKEv2. The procedure
for this is "expert
review". It could probably be defined in some EAP RFC and
ratified by
some expert chosen by the security ADs, but I don't know.
[Jari Arkko]
I think the conclusion from the IKEv2 discussion is
that there's a couple of promising alternatives for
transporting i18n or privacy enhanced NAIs over IKEv2.
But it seems that we should not do them in the NAIbis
spec. (But I volunteer to draft a spec for that in
some other context.)
If I missed anything, scream now. I will submit this
to the I-D directories in a couple of days.
Proposed Resolution: Accept
Issue 3: Editorial Issues
Submitter: Miguel
Garcia
Submitter email address:
Miguel.An.Garcia@nokia.com
Date first submitted: August 6, 2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00007.html
Document: SIP-03
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of
issue:
1) Abstract: The abstract looks more like an introduction to me,
providing a motivation for this work. I think the abstract should just indicate
what this document provides, rather than a historical description of the
capabilities of RADIUS, SIP and HTTP. I would suggest a text around this lines:
"This document specifies an extension to RADIUS that allows a RADIUS client in a
SIP/HTTP server, upon reception of a SIP/HTTP request, retrieve and compute
Digest authentication information from a RADIUS server. Additionally, a scenario
describing the authentication of a user emiting a SIP/HTTP request is provided."
[Wolfgang Beck] Thank you for this proposal.
3) draft-sterman defines a Digest-Body attribute. But actually, the attribute will not contain a body, but the hash of a body. I would suggest to rename this attribute to Digest-Entity-Body-Hash. It happens that this is the name of the same AVP in Diamter SIP app.
[Wolfgang Beck] Digest-Body-Digest looked a bit strange to me and Digest-Entity-Body-Hash a bit long. But I've no problem changing it.
6) Question of documentation. I noticed that all the attribute descriptions in draft-sterman include a figure containing the position of Type, Length and String. I wonder if it is needed to repeat the figure in all the attribute descriptions or whether you can indicate in a general paragraph the commonality shared by all the attributes (among others, the structure represented in those figures).
[Wolfgang Beck] OK.
7) Section 2.1 in draft-sterman. The definition of
Type says:
Type
DIG-RES for Digest-Response. Early implementations have
used
the experimental type 206.
I would suggest to remove the last
sentence. It is not relevant for this document the value an early implementation
has used or not. What is important is the value assigned by IANA.
[Wolfgang Beck] OK.
9) Section 4, migration path to Diameter: Digest-URI
First, a typo: s/DIAMETER/Diameter
We should synchronize the name of
Digest-URI AVP. Diameter SIP app calls it Digest-Digest-URI. The reason is that
the first "Digest-" refers to the prefix used for all those Digest AVPs. The
second "Digest" refers to the name of the Digest direction, which is called
"digest-uri". It is not so important, so I am willing to change the name in
Diameter SIP app to Digest-URI.
Proposal: I will change the name of
Digest-Digest-URI to Digest-URI. There is no action to draft-sterman.
11) Section 5:
I would expect that this section starts with the
following sentence:
"This document serves as IANA registration request
for ..."
Particularly, I would remove the dependency on becoming a
working group (item) or IESG document.
[Wolfgang Beck] OK.
12) Examples in Section 7:
This one was a shock to me. It violates all
the rules of writing RFCs. For instance, it does not use the IP address space
suggested for examples, it does not use the example.com domain name.
The
SIP examples luck a few mandatory headers (e.g., Max-Forwards), contains the
name of commertial products, contains undocumented extensions to SDP, misses
recommendations of populating several SIP headers and SDP lines...
If you
want to continue in this path, I may suggest that an expert reviewer assigned by
the transport AD should inspect this examples.
I have a better
suggestion: at the end of the day, this draft is about Digest and RADIUS. So why
don't you focus on Digest and RADIUS in the examples? create some sort of
abstract SIP/HTTP request, and just write down the Digest headers, but not the
whole SIP message.
[Wolfgang Beck] To be honest, I took the examples without much review from
the -00 version
which was based on RFC 2543.
[Wolfgang Beck] Here is the proposed resolution:
1) Abstract
new text:
'Several protocols borrow the syntax and authentication mechanisms
from the Hypertext Transfer Protocol, HTTP. This document specifies
an extension to RADIUS that allows a RADIUS client in a HTTP-style
server, upon reception of a request, retrieve and compute Digest
authentication information from a RADIUS server. Additionally, a
scenario describing the authentication of a user emitting a
HTTP-style request is provided.'
2) body digest
renamed to Digest-Entity-Body-Hash
3) figures in attribute description
only one figure for all attributes
4) mentioning of early number assignments
removed
5) DIAMETER
-> Diameter
6) IANA request
added "This document serves as IANA registration request for ..."
7) horrible examples
shortened and fixed
Proposed Resolution: Accept
Issue 4: Attribute reuse
Submitter: Miguel
Garcia
Submitter email address:
Miguel.An.Garcia@nokia.com
Date first submitted: August 6, 2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00007.html
Document: SIP-03
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of
issue:
First, I think that in general, both drafts are aligned. This is good news, since there is not need for a lot of rework. Here are some comments though:
2) Attributes/AVP: I am happy to see that we both drafts are aligned with the
attributes/AVP names and semantics. But on reading draft-sterman I found
suggestions for the Diameter SIP app.
In Diameter SIP app we had a
conflict with the duplication of information. For instance, we use the User-Name
AVP as well as Digest-Username AVP. We don't have, though, a Digest-Method AVP,
since we have a SIP-Method AVP that does the same. I think this is wrong, and I
propose to add a Digest-Method AVP to the Diameter SIP app. The idea is:
Digest-xxx AVPs are used to compute the Digest authentication, wherease
SIP-Method or User-Name are used to authorize the user to proceed with a
particular request.
This adds a duplication of information, but on the
other hand, it provides a clear split between Digest authentication and
authorization of a request.
If I found no objections, next version of
Diameter SIP app will include a new Digest-Method AVP.
4) I noticed that
draft-sterman does not specify a Digest-Nextnonce attribute, but we have a
Digest-Nextnonce AVP in Diameter SIP app. It seems that draft-sterman reuses
Digest-Nonce to transport a nextnonce. While the mechanism probably works, I
would suggest to define a new Digest-Nextnonce attribute in draft-sterman, since
the semantics of Nonce and Nextnonce are completely different, so they are sent
in different parameters in the Digest header. Is this acceptable?
Wolfgang Beck wrote:
After converting the draft to flat attributes, I tried to save attribute
space. It is a scarce resource in RADIUS.
Bernard Aboba wrote:
Also, saving attribute space is not a design goal of this document.
Diameter compatibility *is* a design goal.
[Jari Arkko]
In general, I'd rather have a larger number of attributes
in a draft than cause problems for translation. Of course
we can build special cases for attributes, but I'd rather
have NASREQ-style completely automatic mapping (attribute =>
AVP from RADIUS space) or at least simple table driven
mapping (attribute => AVP from Diameter space with same
type).
Note: if RADIUS attribute space really runs out, we can
create more, through an IETF "vendor" attribute, for
instance.
5) Similar to #4 above, I noticed that draft-sterman defines a Digest-Response
that presumably is used to map it to both "response" and "rspauth" in Digest.
As in #4, the semantics of both Digest parameters are different, so the
attributes should be. In Diameter SIP app. we define Digest-Response and
Digest-Response-Auth AVPs. I would suggest that draft-sterman splits
Digest-Response similarly. Is this acceptable?
[Wolfgang Beck] Here is the proposed resolution:
Remove attribute reuse, introduce new attributes
Proposed Resolution: Accept
Issue 5: RADIUS/Diameter compatibility
Submitter: Miguel Garcia
Submitter email address:
Miguel.An.Garcia@nokia.com
Date first submitted: August 6, 2004
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg00007.html
Document: SIP-03
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of
issue:
8) Section 2.16, Digest-Stale. I notice that draft-sterman and Diameter SIP
app are not synchronized with the possible values of this attribute.
Draft-sterman indicates that if Digest-Stale is present, its value will always
be set to "1". This will be mapped to the stale="true" parameter in Digest. I
understan that if Digest-Stale is not present, then the RADIUS client should
assume that stale="false" or simple not present in Digest
Diameter SIP
app. maps strictly the contents of the "stale" parameter in Digest, meaning that
the contents can be "true" or "false" (we actually refer to RFC 2617).
I
like more the approach taken by Diameter SIP app. There is no assumptions (as if
the attribute is not present, it means stale="false"). And I found it more
future proof, in case someone defines an extension with more values of stale
(unlikely though, but this is not a justification).
My proposal is that
draft-sterman aligns with Diameter SIP app and the value of the Digest-Stale AVP
includes a quoted string that is straight forward mapped to the stale parameter
in Digest. Is this acceptable?
[Wolfgang Beck] Yes.
10) Section 4:
This section will need an
update after the discussion in this e-mail. Some other typos I found:
-
Remove all the "AVP" instances
-
s/SIP-Entity-Body-Hash/Digest-Entity-Body-Hash
You can also see how ugly
is to overload an existing attribute when the semantics of the request differ
from the semantics of the response. See the Digest-Response attribute
The
"Access-Request Digest-Response" attribute should be mapped to the
"Digest-Response" in Diameter SIP app.
The "Access-Accept
Digest-Response" attribute should be mapped to the "Digest-Response-Auth" in
Diameter SIP app.
Note that table 2 will become obsolete when we add the
proposed changes in this e-mail. However the contents of the table should move
to table 1 with the appropriate values.
In general, I found that this
section 4 has to be rewritten once we agree on the proposals in this e-mail. It
would become easier to map both documents now.
[Wolfgang Beck] There will be some more changes as I will use Access-Challenge in the next version of the draft.
[Wolfgang Beck] Here are the proposed resolutions:
1) Digest-Stale
Use is now mandatory if server chooses nonces.
2) Typos: fixed
[Jari Arkko]
Miguel Garcia wrote:
I am deliberately cross posting to AAA and Radius-ext because I believe this topic is of interest for both lists.
Yesterday Wolfgang and me met for a few hours and set the goal of reconcile the Diameter SIP application and the RADIUS HTTP/SIP Digest drafts. These are the drafts:
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-04.txt
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt
These are the main points we discuss. If you have any comments, speak up now, otherwise we will do the proposed changes in the relevant drafts:
1- We agreed to modify the Diameter SIP application so that it imports the Digest-* AVP from the corresponding RADIUS attributes address space.
This came out of a comment from Jari Arkko, and I think it is important to avoid duplication of AVP/attributes.
As a side effect of the above, the SIP-Authentication-Context will disappear in Diameter SIP app. This was a grouped AVP that only contained a Digest-Entity-Body-Hash AVP. The latter will remain (in the RADIUS draft).
Great!
2- We noticed a divergence in the Digest-Expected-Response AVP in Diameter, which does not exist in RADIUS. RADIUS defines a Digest-HA1 attribute. The difference: Digest-HA1 contains H(A1), which is computed at the Radius server and sent to the Radius client, and it is used to compute the expected response. In Diameter, the expected response is computed at the Diameter server and sent to the client. This assumes a secure connection to avoid eavesdropping, which is not a problem for Diameter that mandates IPsec or TLS. I think Diameter can go for the Radius approach for compatibility reasons.
Proposal: Diameter will remove Digest-Expected-Response AVP and will import Digest-HA1 from Radius.
Ok.
3- Radius does not define UTF8String data types, so all these attributes will remain as String, but the Radius draft will indicate that contain a
UTF8String verbally (this is required by HTTP and SIP).
Hm, I guess this is OK.
4- Currently here is a divergence on the definition of Digest-Stale attribute: Diameter uses "true" and "false" (as per RFC2617), Radius uses 1 and 0. We agreed to use "true" and "false" to avoid stupid transcodings.
This is much better. Good.
5- Diameter indicates that the Digest-* AVPs contain the quotes from/to the Digest directive, Radius assumes (although does not indicate) no quotes. We agreed that the Digest-* attributes do not need to include the quotes from HTTP Digest parameters. So, there will be an explicit indication that quotes are not part of the attribute value.
This is better too.
6- We run into a problem when multiple SIP proxies are authenticating
the user, because at some point in time the SIP request may contain
several Proxy-Authorization headers. The key here is the realm, it
will be always different. If different Diameter/Radius servers are serving different realms, there is not problem. But, if a common Diameter/Radius server is serving different realms, then the server is not able to determine which credentials should be evaluated.
We propose that the Diameter/Radius client MUST send only one set of credentials at a time, those belonging to the served realm. This requires to configure the Diameter/Radius client with the realm it is serving. We will include some text indicating this case.
I fail to see the problem, most likely due to the insufficient
understanding of the protocol details on my part. But will
your solution lead to some problem if there's roaming
involved?
7- Some of the attributes (e.g, Digest-Response and
Digest-Response-Auth) had an artificial limit of 32 octets in the
value. While this value is correct for MD5 hashes, if in the future
other hashes are added to HTTP Digest, will run into
trouble. Proposal: don't restrict the length of a value.
Right.
8- In the Radius document, scenario 1, we have a question. We suspect
that this scenario does not work if the Radius client generates a
nextnonce. The reason is that in the following authentication, when the
nextnonce becomes a nonce, the Radius server will not recognize the
nonce as locally generated (it was generated by the Radius client), and will reject the request with a "state=true". RFC 2617 seems to describe the case:
If the
nextnonce field is present the client SHOULD use it when constructing
the Authorization header for its next request. Failure of the client
to do so may result in a request to re-authenticate from the server
with the "stale=TRUE".
Does anyone have any comment? Can anyone confirm that the operation in Digest is as we indicate? We will add some text indicating the limitations of Scenario 1.
In looking at this, I have the same question as you. So no
help from me, sorry.
9- The Radius draft, in section 2.15, indicates:
RADIUS
servers that do not implement a parameter contained in a
Digest-Auth-Param attribute MUST respond with an Access-Reject
message. RADIUS clients that do not implement a parameter
contained in a Digest-Auth-Param attribute MUST reject the
original HTTP-style request.
The problem is that the text seems to go against RFC 2617 that says:
auth-param
This directive allows for future extensions. Any unrecognized
directive MUST be ignored.
The proposal is to remove the above text from the RADIUS draft.
Yes, this is correct.
10- Similar contradictory text was found in Section 2.16 of the RADIUS draft, that says:
RADIUS servers that do
not implement AKA Digest MUST response with an Access Reject
message.
We propose to remove the above text. The motivation is that the algorithm already conveys the AKA (AKA extends the algorithm to be AKAv1-MD5 and AKAv1-MD5-sess). The server chooses the algorithm, so the situation currently described, where the client may include an auts attribute, is just an error case, where the client made a mistake and included AUTS when not doing AKA. In case the Radius server does not implement AKA authentication, it will safely ignore this AVP.
Right.
11- We noticed that most of the HTTP Digest directives contain just a single token. However, the "qop" directive may contain a comma-separated collection of tokens. For instance, qop="auth,auth-int". The question is how do encode these tokens in the Digest-Qop attribute. The options are:
a) Treat the whole thing as one token and put it into the attribute value.
b) Each token is an attribute, thus, there might be multiple Digest-Qop attributes in a particular Radius/Diameter message.
We think that option b) is cleaner. Particularly it will be easier for the Diameter/Radius client to encode different values in different attributes.
I think option a) is cleaner, although I don't care enough to
think it should be a showstopper. But here's my reasoning:
avoid unnecessary mapping work that the client needs to do;
handle everything as much as possible by taking all text
from the SIP syntax and putting it blindly into an AVP...
[Avi Lior]
Just one point now. RADIUS "Text" type attributes are UTF-8 compliant. I
just want to make sure that the definition of Text and UTF8String are the
same. And they appear to be.
From RFC 2865:
text 1-253 octets containing UTF-8 encoded 10646 [7]
characters. Text of length zero (0) MUST NOT be sent;
omit the entire attribute instead.
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
From RFC 3588:
This is a human readable string represented using the
ISO/IEC IS 10646-1 character set, encoded as an OctetString using
the UTF-8 [UFT8] transformation format described in RFC 2279.
So where applicable the attributes in Sterman should be set to Text.
[Jari Arkko]
Option b) is cleaner because it requires less parsing work by AAA server.
Regarding the following comment:
> handle everything
> as much as
> > possible by taking all text from the SIP syntax and putting
> it blindly
> > into an AVP...
Wolfgang's original document did that for all the attributes (using
subtypes) which could have been handled by both RADIUS and Diameter. Lets
not go there again.
[Avi Lior]
I am trying to get a deeper understanding here. But it seems to me that in
Scenario 1 where the RADIUS Client is generating the nonces, the client
really needs to be the one that determines the staleness of the nonces and
not the AAA. Therefore, the client will not even invoke the AAA server when
the nonce is stale; and the AAA will just assume that all nonces are valid.
Again I think that only option b is the valid one. Unless I am missing
something, I think a Proxy must be able to identify the the
Proxy-Authorization that is associated with it. From RFC 2616:
"When multiple proxies are used in a chain, the
Proxy-Authorization header field is consumed by the first outbound
proxy that was expecting to receive credentials. A proxy MAY relay
the credentials from the client request to the next proxy if that is
the mechanism by which the proxies cooperatively authenticate a given
request."
Therefore you would think that a particular proxy would extract the
credentials from its headers and those would be the only ones that are sent
to the AAA infrastructure.
And this also implies that the Proxy has a way to identify the
Proxy-Authroization header.
Is this right?
Proposed Resolution: Discuss
Issue 6: Comments
Submitter: Pete McCann
Submitter email address:
mailto:Miguel.An.Garcia@nokia.com
Date first submitted: August 26, 2004
Reference:
http://ops.ietf.org/lists/radiusext/2004/msg00698.html
Document: SIP-03
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of
issue:
Document should start with an overview of the assumed architecture, as
shown in e.g. Figure 1 of Section 1.3. However, the text of Section
1.3
dives into a particular scenario and a broader overview is
necessary first.
(I think Miguel made this comment earlier)
Section 1.2 (although I think
this text should be deleted):
Change:
lacking support,
too: even two years
To:
lacking support, too; even two years
Change:
SIP service providers whishing
To:
SIP service providers wishing
Section 1.5:
Change:
Section 1.4 describes an mechanism
To:
Section 1.4 describes a mechanism
However, in some cases the RADIUS server is better off with pre-computed hashes.
Section 1.4 describes an mechanism that enables this style of
authentication.
This paragraph mentions "precomputed hashes" but then the
issue is never
revisited. Is it true that precomputed hashes can be
used with arbitrary
message contents, or is some other coordination required
between the
home RADIUS server and the client?
Section 2:
Reformat
list of attributes into a table, and use values like "TBD-DIG-RES"
in the
table. Create an IANA considerations section which requests allocations.
Don't use text like "if this specification becomes a working group or IESG
document..."
Get rid of " Early implementations have used the
experimental type 206."
The following is confusing:
3.1
RADIUS Client Behaviour
A RADIUS client without an encrypted
or otherwise secured connection
to its RADIUS server only
accepts unsecured connections from its
HTTP-style clients (or
else the clients would have a false sense of
security).
It is not quite clear what is meant by "encrypted or otherwise
secured",
because there are several different security mechanisms
available in RADIUS,
including the hop-by-hop message authenticator
and the shared-key method of
obfuscating individual attributes. I
assume this would not be adequate
to provide the protection you are
looking for. Also, what counts as an
"unsecured connection" from an
HTTP-style client? Do you mean one that
doesn't use either TLS or
IPSec? Maybe this paragraph is adequately
covered by the security
considerations (or should be) and could be deleted.
[Wolfgang Beck] > Document should start with an overview of the assumed
architecture, as
> shown in e.g. Figure 1 of Section 1.3. However, the
text of Section
> 1.3 dives into a particular scenario and a broader overview
is
> necessary first. (I think Miguel made this comment earlier)
>
Section 1.2 (although I think this text should be deleted):
When I started
working on the draft, people asked for a motivational
section.
I'll do
an overview section which includes the 2 scenario sections
1.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3.1 Scenario 1, RADIUS
client chooses nonces . . . . . . . 5
1.3.2 Scenario 2, RADIUS server chooses nonces . . . . . . . 6
Section 1.3 will be the '1.5 Approach' section of -03 without the last
paragraph.
> However, in
> some cases the
RADIUS server is better off with pre-computed hashes.
> Section
1.4 describes an mechanism that enables this style of
>
authentication.
> This paragraph mentions "precomputed hashes" but then the
issue is never
> revisited. Is it true that precomputed hashes can be
used with arbitrary
> message contents, or is some other coordination
required between the
> home RADIUS server and the client?
Proposal:
"1.3.2 Scenario 2, RADIUS server chooses nonces
In
most cases, the operation outlined in Section 1.3.1 is sufficient.
It reduces the load on the RADIUS server to a minimum. However, when
using AKA [RFC3310] the nonce is partially derived from a precomputed
authentication vector. These authentication vectors are often stored
centrally.
Figure 3 depicts an scenario, where the RADIUS
server chooses nonces."
> Section 2:
> Reformat list of attributes
into a table, and use values like "TBD-DIG-RES"
> in the table. Create
an IANA considerations section which requests allocations.
There is a IANA
consideration section at the end of the document. I didn't want
to use
DIG-RES etc. in the sub sections of 2. before explaining that they are
attribute names.
Proposal:
"2. New RADIUS attributes
DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG,
DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP,
DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that
are taken from the RADIUS attribute type number space (see Section
<IANA considerations>)."
> Don't use text like "if this specification
becomes a working group or IESG
> document..."
> [..]
> Get rid of "
Early implementations have used the experimental type
> 206."
Ok.
The following is confusing:
> 3.1 RADIUS Client Behaviour
>
> A RADIUS client without an encrypted or otherwise secured
connection
> to its RADIUS server only accepts unsecured
connections from its
> HTTP-style clients (or else the
clients would have a false sense of
> security).
>
>
It is not quite clear what is meant by "encrypted or otherwise
> secured",
because there are several different security mechanisms
> available in
RADIUS, including the hop-by-hop message authenticator
> and the shared-key
method of obfuscating individual attributes. I
"encrypted" ~ eg. IPSEC
or proprietary tunnel technology
"otherwise secured" ~ eg. RADIUS client and
server are in a closed MPLS
VPN.
> assume this would not be adequate
to provide the protection you are
> looking for. Also, what counts as
an "unsecured connection" from an
> HTTP-style client? Do you mean one
that doesn't use either TLS or
> IPSec?
Yes. I'll insert a reference to
the security considerations section,
which has this paragraph:
"HTTP-style clients can use TLS with server side certificates together
with HTTP-Digest authentication. IPSec can be used in a similar way.
TLS or IPSec secure the connection while Digest Authentication
authenticates the user. If a RADIUS client accepts such connections,
it MUST have a secure connection to the RADIUS server."
> Maybe this
paragraph is adequately covered by the security
> considerations (or should
be) and could be deleted.
I disagree. If a SIP client wants the signalling to
be secure,
it uses sips: URLs. All SIP proxies along the way must use TLS
connections to forward requests with sips: URLs. I don't think
the SIP
proxies (=RADIUS clients) should expose parts of the SIP
message by using a
unencrypted RADIUS messages in this case.
As this is part of the client
behaviour, I put it into that section.
[Wolfgang Beck] Here are the proposed resolutions:
1) Overview too short
added overview section, rearranged document structure
1.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Scenario 1, RADIUS client chooses nonces . . . . . . . 6
1.3.2 Scenario 2, RADIUS server chooses nonces . . . . . . . 7
2) missing explanation for pre-computed hashes
new text:
'However, when using AKA [RFC3310] the nonce is partially derived from
a precomputed authentication vector. These authentication vectors are
often stored centrally.'
3) unclear defintion of 'secured connection'
added a reference to Security Considerations
added explanation in Security Considerations
[Pete McCann]
I went back to review the status of Issue 6. It looks to me like it
is all ok in draft-ietf-radext-digest-auth-00.txt except for the
security related issue. The proposed resolution from Wolfgang is ok
with me but I don't see the promised reference to the security
considerations.
One additional comment inserted into Wolfgang's text below...
Wolfgang Beck wrote:
> > The following is confusing:
> >
> > 3.1 RADIUS Client Behaviour
> >
> > A RADIUS client without an encrypted or otherwise secured connection
> > to its RADIUS server only accepts unsecured connections from its
> > HTTP-style clients (or else the clients would have a false sense of
> > security).
> >
> > It is not quite clear what is meant by "encrypted or otherwise
> > secured", because there are several different security mechanisms
> > available in RADIUS, including the hop-by-hop message authenticator
> > and the shared-key method of obfuscating individual attributes. I
>
> "encrypted" ~ eg. IPSEC or proprietary tunnel technology
> "otherwise secured" ~ eg. RADIUS client and server are in a closed MPLS
> VPN.
Can you make it clear in this text that the shared-key method for
encrypting individual attributes is not acceptable in this case?
[Wolfgang Beck]
Here's a proposal for the text regarding the encryption of RADIUS
which is required when accepting sips/https:
HTTP-style clients can use TLS with server side certificates together
with HTTP-Digest authentication. Instead of TLS, IPSec can be used,
too. TLS or IPSec secure the connection while Digest Authentication
authenticates the user. The RADIUS connection can be regarded as one
leg on the path between the HTTP-style client and the HTTP-style
server. To prevent the RADIUS link from being the weakest hop on the
path, a RADIUS client receiving an HTTP-style request via TLS or
IPSec MUST use an equally secure connection to the RADIUS server.
There are two ways to achieve this:
o the RADIUS client rejects HTTP-style requests received over TLS or
IPSec
o the operator of the RADIUS client takes actions to ensure that
RADIUS traffic is exclusively sent and received using IPSec.
When using IPSec, it MUST be set up as described [RFC3579] section
4.2.
[Pete McCann] This looks good and resolves my issue.
Proposed Resolution: Accept
Issue 7: Message-Authenticator
Submitter: Avi
Lior
Submitter email address:
avi@bridgewatersystems.com
Date first submitted: August 26, 2004
Reference:
http://ops.ietf.org/lists/radiusext/2004/msg00690.html
Document: SIP-03
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of
issue:
In the SIP doc I think you need to use Message-Authenticator(80) in the
access request.
The problem is this: without using a field such as
CHAP-Password or
Password, the RADIUS server has no way to validate that the
Access-Request
is arriving from a valid NAS.
Message-Authenticator(80)
is used to provide integrity protection for the
entire Access-Request packet
and can be used by the RADIUS Server to
validate that the packet was received
from a known Client (since the
Message-Authenticator uses a shared secret
shared by the Client-Server.)
[Bernard Aboba] Here is what it says in Section 5.19 of RFC 2869:
An Access-Request that contains either a User-Password or
CHAP-Password or ARAP-Password or one or more EAP-Message attributes
MUST NOT contain more than one type of those four attributes. If it
does not contain any of those four attributes, it SHOULD contain a
Message-Authenticator. If any packet type contains an EAP-Message
attribute it MUST also contain a Message-Authenticator.
Note that
Message-Authenticator is based on HMAC-MD5. Recent research has
demonstrated collisions in MD5 (though not in HMAC-MD5), so that it may
make
sense to define a new attribute that uses a more highly regarded
algorithm,
such as HMAC-SHA1.
[Joe Salowey] See
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt, this
defines an attribute that can SHA for message authentication.
[Barney Wolff] As I read the chatter on the crypto list, it's premature to
assume that
SHA-1 will survive better than MD5, although it probably will.
Arguments
have been made that HMAC-MD5 will not fall to MD5 attacks.
I'd suggest
waiting at least a couple of weeks for the smoke to clear before
acting.
We do know that the RADIUS Authenticator has long been considered
inferior
to HMAC-MD5, and the recent issues may seal its fate. It's
therefore
prudent to consider how to react when, or before, the authenticator
is
broken. Certainly boxes that have sufficient cpu and codespace can
use
IPsec, as has already been suggested. What, if anything, to do
for/with
boxes that cannot run IPsec is an open question.
[Wolfgang Beck]
Use of Message Authenticator should be mandatory
RfC 2869 is informational. I see that it is useful but
I hesitate to make it mandatory.
new text:
'Informational RfC 3579 [RFC3579], section 3.2 describes
a Message-Authenticator attribute which MAY be used to protect the
integrity of RADIUS messages.'
[Bernard Aboba]
Omitting Message-Authenticator enables an attacker to forge Access-Request
packets. The reason RFC 3579 could not make use of Message-Authenticator
mandatory for all RADIUS packets (just for packets containing an
EAP-Message attribute) was because Message-Authenticator was not required
in RFC 2865, so that it was not sent by legacy RADIUS-clients.
That problem does not occur here; Digest Authentication is a new RADIUS
capability.
[Avi Lior]
I think we all agreed that a message authenticator is needed here.
I think the debate was whether the Message-Autheticator will suffice here.
You suggested that maybe we introduce a new attribute. But as you pointed
out that while MD5 was found to be vunerable HMAC-MD5 was not. There was
lots of debate on this issue.
I don't think we would solve this issue in the near future. This is
because, judging from the emails I don't think we would get consensus even
if we created a new message authenticator based on HMAC-SHA1.
So my suggestion is to use Message-Authenticator(80) which is based
on(HMAC-MD5). Which is not broken and proceed with the work. Not having
anything is clearly bad.
[Avi Lior]
We would like to get closure on the issue of the use of Message
Authenticator for draft-sterman-aaa-sip-04.
Everyone seems to agree that we need to use some sort of RADIUS Message
Authenticator.
There was a discussion on the strength of HMAC-MD5. Some suggested that we
should stregthen the RADIUS Message-Authenticator to HMAC-SHA1.
-HMAC-MD5 is not busted (yet).
-draft-sterman-aaa-sip-04 carries HTTP digest which are based on MD5.
-draft-sterman-aaa-sip-04 seems to be addressing legacy deployements.
Recommending that greenfield implementation use Diameter.
-There is a push to get draft-sterman-aaa-sip-04 out quickly.
-keywrap proposes a new message authenticator Message-Authentication-Code
which supports either HMAC-MD5 or MHAC-SHA1 methods.
Options:
========
1) Allow draft-sterman-aaa-sip to use Message-Authenticator(80). And when
keywrap is ready we can state in keywrap that RADIUS implmentation should
upgrade to Message-Authentication-Code.
2) Require draft-sterman-aaa-sip to use Message-Authentication-Code.
Questions:
==========
-Will IESG accept a new RFC based on HMAC-MD5?
If not then we don't really have a choice.
-Will keywrap be ready in time?
This is important but the authors feel that it is ready to go. However,
note that Keywrap allows Message-Authentication-Code to be HMAC-MD5 isn't
this a problem?
Your comments and opinion would be appreciated.
[Glen Zorn]
The use of HMAC-MD5 is optional and included just for ease of
transition. It is _not_ required by the draft; if you like, we can
add text to the Security Considerations section deprecating its use
(or even remove it altogether -- I have no problem with that).
[Jari Arkko]
I may be missing some background here. [Ok, I confess I have
not read all the e-mails in my Inbox :-) ]
Why is this problem specific to RADIUS Digest draft? I realize
that it will have to reference the use of Message-Authenticator.
But so do other RADIUS specs. If the use of MD5 is an issue,
it would seem to be simpler that the IETF would just do it once
and for all in all of RADIUS. Alternatively, start mandating
IPsec.
Also, should RADIUS Digest go through unmodified,
standard RADIUS proxies? If so, how would they be aware of
a new AVP that they need to process?
Finally, if MD5 is bad, wouldn't that be a problem for
most Digest usage, RADIUS or not, given that the only
algorithms supported now are MD5 and AKA? I guess I'm
asking what makes the Message-Authenticator usage of
MD5 different from other RADIUS usage of MD5 or Digest
usage of MD5, both of which have to be relied upon anyway?
Or is the issue that the MD5 usage in Message-Authenticator
is particularly vulnerable?
[David Nelson]
> -Will keywrap be ready in time?
> This is important but the authors feel that it is ready to go.
Keywrap may well be important, to the extent that it successfully
addresses NIST certification requirements, but it includes more than
just an improved MAC, and would likely require a charter change to be in
scope (new RADIUS security methods are currently out of scope).
I think that Message-Authenticator is probably the way to go for the
Sterman draft. More extensive security enhancements to RADIUS could be
optionally applied to digest authentication, as well as any other RADIUS
application, when and if they are standardized.
[Avi Lior]
If you allow HMAC-MD5 people will keep using it. If HMAC-MD5 is an issue,
then in my opinion don't provide that option.
Besides folks already have Message-Authenticator that they can use.
> Alternatively, start mandating IPsec.
This is a problem for RADIUS in general. The discussion started around the
use of message authenticator for the digest draft.
Mandating Ipsec. Hmmmmm Ipsec could be mandated but I don't see that it will
be used in RADIUS.
> Also, should RADIUS Digest go through unmodified,
> standard RADIUS proxies? If so, how would they be aware of
> a new AVP that they need to process?
Yes that would be a problem. They wouldn't be aware of it. So there is that
issue as well.
> Finally, if MD5 is bad, wouldn't that be a problem for
> most Digest usage, RADIUS or not, given that the only
> algorithms supported now are MD5 and AKA? I guess I'm asking
> what makes the Message-Authenticator usage of MD5 different
> from other RADIUS usage of MD5 or Digest usage of MD5, both
> of which have to be relied upon anyway? Or is the issue that
> the MD5 usage in Message-Authenticator is particularly vulnerable?
It seems that everyone thinks MD5 is bad.
But note that in fact Message-Authenticator (is HMAC-MD5 based) and is *not*
vunerable (as I understand it).
MD5 is vunerable in that we can easily create collisions. But as Chiba
pointed out,
"From what I understand, having an easy way to generate collisions does
not mean that it will be easy to create valid RADIUS packets that result
in the collision hash."
Not being a security expert, I would be interested to see analysis if it is
feasable to apply the MD5 attacks to RADIUS messages.
[Glen Zorn]
So, does this mean that as far as the IETF is concerned RADIUS
security is good enough, forever (I assume that this reasoning was
at least in part behind the injunction against 'new security
methods' in the charter)?
[Avi Lior]
Based on the comments received on this issue.
-It is important to have some sort of authenticator.
-Message Authenticator(80) is not busted - HMAC-MD5
-Digest Authentication is based on MD5 anyway.
I propose that we make Message-Authenticator(80) mandatory to protect the
Access-Requests.
[Bernard Aboba] This still isn't fixed in DIGEST-01. From Section 8: To make simple denial of service attacks more difficult, the nonce issuer (RADIUS client or server) MUST check if it has generated the nonce received from an HTTP-style client. This SHOULD be done statelessly. For example, a nonce could consist of a cryptographically random part and some kind of signature of the RADIUS client, as described in [RFC2617], section 3.2.1. RADIUS servers MAY include Digest-Qop and Digest-Algorithm attributes in Access-Challenge messages. A man in the middle can modify or remove those attributes in a bidding down attack. In this case, the RADIUS client would use a weaker authentication scheme than intended. RfC 3579 [RFC3579], section 3.2 describes a Message-Authenticator attribute which MUST be used to improve the integrity protection of RADIUS messages. The RADIUS server can use this attribute to verify the identity of the RADIUS client. Message-Authenticator is not indicated in the attribute tables as being required. What messages require Message-Authenticator? Is this only the Access-Request?
[Wolfgang Beck] Here is the proposed resolution:
2. Detailed Description 2.1 RADIUS Client Behavior [..] To do the latter, it sends an Access-Request containing a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute. It adds a Message-Authenticator (see [RFC3579]) attribute to the Access-Request message. The RADIUS server chooses a nonce and responds with an Access-Challenge containing a Digest-Nonce attribute. [..] 2.2 RADIUS Server Behavior If the RADIUS server receives an Access-Request message with a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce attribute and sends it in an Access-Challenge message to the RADIUS client. The RADIUS server MUST add Digest-Realm, Message-Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes to the Access- Challenge message. [..] RADIUS servers issuing nonces MAY construct a Digest-Nextnonce attribute and add it to the Access-Accept message. This is useful to limit the lifetime of a nonce and to save a round-trip in future requests (see nextnonce discussion in [RFC2617], section 3.2.3). The RADIUS server adds a Message-Authenticator attribute (see [RFC3579]) and sends the Access-Accept message to the RADIUS client.
4. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. +-------------------------+-----+-----+--------+--------+-----------+ | Attribute | # | Req | Accept | Reject | Challenge | +-------------------------+-----+-----+--------+--------+-----------+ | User-Name | TBD | 1 | 0 | 0 | 0 | | Message-Authenticator | TBD | 1 | 1 | 1 | 1 |
Proposed Resolution: Accept
Issue 8: Rspauth generation not possible if RADIUS
server chooses nonces and qop=auth-int
Submitter: Wolfgang Beck
Submitter email address:
BeckW@t-systems.com
Date first submitted: August 25, 2004
Reference:
http://ops.ietf.org/lists/radiusext/2004/msg00689.html
Document: SIP-03
Comment type: T
Priority: 1
Section: 3.1, 3.2
Rationale/Explanation of
issue:
Jun Wang wrote:
> As the RADIUS server does not know about the response
body the
> RADIUS client is going to send, it can't generate A2.
>
> In 3GPP2, we do need to perform auth-int because we need to protect the
> response that is sent from the network to the MS. I hope in this draft you
> could allow solution 3 or at least you will not preclude solution 3 so that
> we can have 3GPP2 VSA to do it.
>
> Thanks,
> Jun
>
> Beck01,
Wolfgang wrote:
>> Hello Jun,
>>
>> thank you for your review. Rahul
Joshi told me about this problem
>> some weeks ago and I think there are
three possible solutions: 1)
>> don't use authentication-info with auth-int
2) send all possible
>> response body-digests to the RADIUS server 3) your
suggestion.
>>
>> I am not sure about the security implications of 3).
Replay
>> attacks might be possible. Solution 2) is a bit bloated as it
>>
would double the work on client and server.
>>
>> In the San Diego
meeting, I proposed using solution 1) and
>> did not hear any objections.
>>
>>
>> Jun Wang wrote
>>>
>>> By reviewing sterman draft (RADIUS
Extension for Digest Authentication,
>>> draft-sterman-aaa-sip-03.txt), I have questions on how the RADIUS sever
can
>>> calculate the Digest-Response that can be used by RADIUS client to
>>> construct Auth-info header (mentioned in section 3.2 in sterman draft).
>>> According to 3.2.3 of RFC 2617, if I understand correctly, the response
>>> digest is calculated as for the request-digest except that A2 is slightly
>>> different. But regardless, to calculate Digest-Response, the RADIUS server
>>> needs to know H(entity-body), here entity-body, I think, is the body
>>> contained in 200OK response. But RADIUS server doesn't know it. It seems
to
>>> me that the right thing is to pass some derived key to RADIUS client
so
>>> that the RADIUS client can calculate Auth-info.
>>>
>>>
Requested change:
[Jun Wang]
>>> [..] It seems to me that the right
thing is to pass some
>>> derived key to RADIUS client so that the RADIUS
client can
>>> calculate Auth-info.
[Wolfgang Beck]
When using
qop=auth-int, the response-auth value is
response-auth = <"> < KD
( H(A1), unq(nonce-value)
":" nc-value
":" unq(cnonce-value)
":" unq(qop-value)
":" H(A2)
) <">
with algorithm = MD5, A1 and A2 are:
A1
= unq(username-value) ":" unq(realm-value) ":" passwd
A2
= ":" digest-uri-value ":" H(entity-body)
Sending H(A1) in an
Access-Accept message would be risky as A1
has no random components. Replay
attacks are possible.
with algorithm = MD5-sess, A1 and A2 are:
A1
= H( unq(username-value) ":" unq(realm-value)
":" passwd )
":" unq(nonce-value) ":" unq(cnonce-value)
A2
= ":" digest-uri-value ":" H(entity-body)
here, A1 has some randomness. A
possible solution might be:
1. Add a new attribute to carry H(A1), Digest-HA1
2. Use Digest-HA1 if server chooses nonces, qop=auth-int and
algorithm=MD5-sess
3. Use a Digest-Response-Auth attribute (new, see issue 4,
5)
if server chooses nonces and qop != auth-int.
4. On reception of
Digest-HA1, the RADIUS client constructs
rspauth, using the nonce received in
a previous Access-Challenge
I don't know if this is really secure.
[Wolfgang Beck] Here are the proposed resolutions:
Rspauth generation not possible if RADIUS server chooses nonces and
qop=auth-int
In contrast to Diameter, RADIUS has no mandatory encryption support.
Sending H(A1) in the clear can make some attacks easier. Here's
the compromise:
A new attribute Digest-HA1 is introduced. It's use is restricted
to *-sess algorithms, where HA1 is constructed partially from random
values.
From the text:
o If the Digest-QoP attribute's value is 'auth' or unspecified, the
RADIUS server puts a Digest-Response-Auth attribute into the
Access-Accept message
o If the Digest-QoP attribute's value is 'auth-int' and the
Digest-Algorithm attribute's value is 'MD5-sess' or
'AKAv1-MD5-sess', the RADIUS server puts a Digest-HA1 attribute
into the Access-Accept message.
o If the Digest-QoP attribute's value is 'auth-int' and the
Digest-Algorithm attribute's value is 'MD5' or 'AKAv1-MD5', the
RADIUS server MUST NOT send a Digest-HA1 attribute unless the
connection between RADIUS server and client is encrypted or
otherwise protected against eavesdropping.
[Jun Wang]The following comments and questions are related to issue #8 and some other new issues.
2) Section 2.19 (Digest-HA1 attribute) first paragraph states:
a) Section 2.19 under string definition, states the following:
We can replace the above text to:
b) Text in Sections 3.1 and 3.2 states:
We can replace the above text to:
2.18 Digest-Stale attribute
Type
DIG-STALE
Length
3
String
The string consists of a single character. If the nonce presented by the RADIUS client was stale, the character is '1' and is '0' otherwise. If the RADIUS sever does not accept the nonce received in Access Request message but authentication was successful, the RADIUS server MUST include this attribute in Access Accept message and set it to '1'; the RADIUS server MUST also set the 'next-nonce' attribute in the Access-Accept message to the valid nonce-value. 7) In Section 3.1, the text on Digest-Stale attribute is not clear. It should be clarified as follows: If the RADIUS client receives an Access-Accept message from the RADIUS Server with the Digest-Stale attribute set to '1', the RADIUS client sends an error (401 or 407) response to the HTTP-style client containing WWW-/Proxy-Authenticate header with the stale flag set to "TRUE and the nonce value set to the 'next-nonce' value received in the Access-Accept message.
8) The following RADIUS Server procedure should be added to section 3.2:
Proposed Resolution: Discuss
Issue 9: Use of Access-Challenge
Submitter:
Wolfgang Beck
Submitter email address:
BeckW@t-systems.com
Date first submitted: August 25, 2004
Reference:
http://ops.ietf.org/lists/radiusext/2004/msg00688.html
Document: SIP-03
Comment type: T
Priority: 1
Section: 3.1, 3.2
Rationale/Explanation of
issue:
draft-sterman-aaa-sip-03 uses Access-Accept messages with a Digest-Nonce,
but without a Digest-Response parameter. This is a in fact a challenge
message and should use RADIUS Access-Challenge.
Requested change:
1.4
Scenario 2, RADIUS server chooses nonces
Figure 2 depicts an
alternative scenario, where the RADIUS server
generates nonces.
It shows a generic case where entities A and B
communicate in
the front-end using protocols such as HTTP/SIP, while
entities B
and C communicate in the back-end using RADIUS.
HTTP/SIP
RADIUS
+-----+ (1) +-----+
+-----+
|
|==========>| | (2)
| |
| |
| |---------->| |
| |
| | (3) |
|
|
| (4) |
|<----------| |
| |<==========| |
| |
|
| (5) | |
| |
| |==========>| |
| |
| A | |
B | (6) | C |
| |
| |---------->| |
| |
| | (7) |
|
|
| |
|<----------| |
| | (8) |
| |
|
|
|<==========| |
| |
+-----+ +-----+
+-----+
====> HTTP/SIP
----> RADIUS
Figure 2: RADIUS server chooses nonces
The roles played by
the entities in this scenario are as follows:
A: HTTP client
/ SIP UA
B: {HTTP server / HTTP proxy server /
SIP proxy server / SIP UAS}
acting also as a RADIUS NAS
C: RADIUS server
The relevant order of messages sent in this
scenario is as follows:
A sends B an HTTP/SIP request
without authorization header (step 1).
B sends an Access-Request
message with the newly defined
Digest-Method and Digest-URI
attributes but without a Digest-Nonce
attribute to the RADIUS
server, C (step 2). C chooses a nonce and
responds with an
Access-Challenge (step 3). This Access-Challenge
contains
Digest attributes, from which B takes values to construct a
HTTP/SIP "(Proxy) Authorization required" response. The remaining
steps are identical with scenario 1 (Section 1.3): B sends this
response to A (step 4). A resends its request with its credentials
(step 5). B sends an Access-Request to C (step 6). C checks the
credentials and replies with Access-Accept or Access-Reject (step 7).
Dependent on the C's result, B processes A's request or rejects it
3.1
RADIUS Client Behaviour
[..]
The RADIUS
client has three ways to obtain nonces: it generates them
locally, it has received one in a Digest-Nonce attribute of a
previously received Access-Accept message, or it asks the RADIUS
server for one. To do the latter, it sends an Access-Request
containing a Digest-Method and a Digest-URI attribute but without a
Digest-Nonce attribute. The RADIUS server chooses a nonce and
responds with an Access-Challenge containing a Digest-Nonce
attribute. If the RADIUS server responds with an Access-Reject, the
RADIUS client MAY generate a nonce locally. If the RADIUS client
does not generate nonces locally, the authentication has failed. The
RADIUS server can send Digest-QoP, Digest-Algorithm, Digest-Realm,
Digest-Domain and Digest-Opaque attributes in the Access-Accept
carrying the nonce. If these attributes are present, the client MUST
use them.
3.2 RADIUS Server Behaviour
If the
RADIUS server receives an Access-Request message with a
Digest-Method and a Digest-URI attribute but without a Digest-Nonce
attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce
attribute and sends it in an Access-Challenge message to the RADIUS
client. The RADIUS server MUST add Digest-Algorithm, Digest-Realm,
SHOULD add Digest-QoP and MAY add Digest-Domain, Digest-Opaque
attributes to the Access-Challenge message. If the server cannot
choose a nonce, it replies with an Access-Reject message.
[..]
[Wolfgang Beck]
On suggestion of Avi Lior, I replaced the special Access-Accept
with Access-Challenge
Proposed Resolution: Accept
Issue 10: Inconsistencies with UTF-8
Submitter: Nagi Reddy Jonnala
Submitter email address:
Nagi_Reddy.Jonnala@alcatel.be
Date first submitted: September 20, 2004
Reference:
http://ops.ietf.org/lists/radiusext/2004/msg00722.html
Document:
RFC2486bis-02
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
See the snips from formal syntax (In fact they are there in the original RFC
as well).
char =/ "\" x
x
= %x00-7F ; all 128 ASCII characters, no exception
I suppose that
you would want to allow the user name like
"myusername\x0\x1". I'm curious to
know in which cases do we make use
of these combo characters.
Doesn't it look consistent if you make the syntax of x to take all 256
includes ASCII and the remaining UTF-8 characters ( i.e., x = %x00-FF)
[Ignacio Goyret]
A detail:
c =/ %x60-7a ; 'a'-'z' allowed
^^^^ ^^^
0x60 ==
'`' (on a US keyboard, it is the key to the left of the '1'
0x61 == 'a'
...
This also looks odd:
c =/ %x26 ; '&et;' allowed
^^^
In
USASCII, 0x26 == '&' or '&' in html. Right?
Proposed Resolution: Discuss
Issue 11: Technical Issues
Submitter: Jari
Arkko
Submitter email address:
Jari.Arkko@piuha.net
Date first submitted: September 2, 2004
Reference:
http://ops.ietf.org/lists/radiusext/2004/msg00708.html
Document: SIP-03
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of
issue:
Due to the weaknesses of Digest authentication (see Section 6),
Section 6 does not talk about the weaknesses of Digest authentication
(original RFC reference might give you some security considerations;
I'm not sure if there's any other document that would talk the
issue).
Due to the weaknesses of Digest authentication (see Section 6),
PKI-based authentication and encryption mechanisms have been
introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633]. However,
Digest, TLS, and S/MIME are not necessarily in direct
competition with each other, as they provide slightly different
services. For instance, TLS is hbh, and Digest gives you
freshness which S/MIME does not. Plus all three protect
different parts of the SIP message.
Suggestion: soften the above statement a bit.
SIP service providers whishing to authenticate their clients have the
following options: they can
o build a PKI and wait for interopable S/MIME capable SIP
implementations,
o build a PKI and wait for SIP implementations supporting TLS with
client-side certificates,
o replace their existing RADIUS infrastructure with DIAMETER
[RFC3588], when DIAMETER supports HTTP Digest authentication,
o use TLS for server authentication and plaintext passwords (Basic)
for client authentication, which can be done with standard RADIUS,
o upgrade their existing RADIUS servers with the functionality
described in this document
PKI solutions only cover authentication, not authorization (EAP could
change this, but its use with SIP is not standardized). TLS / Basic
authentication works only with the limited number of SIP devices that
implement TLS. Basic authentication has been deprecated for SIP in
[RFC3261].
Somehow the above arguments feel a bit out of place here. Just
state that Digest is widely used in SIP, and leave it at that :-)
PKI solutions only cover authentication, not authorization (EAP could
change this, but its use with SIP is not standardized). TLS / Basic
authentication works only with the limited number of SIP devices that
implement TLS. Basic authentication has been deprecated for SIP in
[RFC3261].
Current RADIUS-based AAA infrastructures have been built and debugged
over years. Deficiencies of RADIUS have been mitigated with
proprietary (ie costly) extensions. Operators are therefore
reluctant to replace their RADIUS infrastructure in order to enable a
single new authentication mechanism.
Same as above. And I'm not sure all deficiences have been
mitigated.
DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG,
DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP,
DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that
will be assigned by IANA, if this specification becomes a working
group or IESG document.
Here's an idea: I'd prefer the attributes in this and the Diameter
draft to be constructed with the following rules:
(1) Don't invent too many of them. Maybe Dig-Alg, Dig-Auts, Dig-QoP,
and Dig-Authp could all use the same attribute? They all have
the same syntax in HTTP (param=value).
(2) If both RADIUS and Diameter are going to define the attributes,
IMHO it would make sense to allocate them from the RADIUS space
so a conversion box would not have to map attributes.
Alternative idea: use some of the extended RADIUS attribute
format ideas and allocate the numbers from the Diameter space.
(3) Use exactly the set of attributes for the pure digest function
(I did not check if this is already the case).
+-----+ (1) +-----+ +-----+
| |==========>| | (2) | |
| | | |---------->| |
| | | | (3) | |
| | (4) | |<----------| |
| |<==========| | | |
| | (5) | | | |
| |==========>| | | |
| A | | B | (6) | C |
| | | |---------->| |
| | | | (7) | |
| | | |<----------| |
| | (8) | | | |
| |<==========| | | |
+-----+ +-----+ +-----+
The choice between the server and client generated
nonces: is there some guidance on how the client knows
which one to do? if it believes it may have a user that
does Digest AKA then it should do use the server generated
scheme? But how would it know this in a roaming case?
Other ideas?
[Wolfgang Beck] >> Due to the weaknesses of Digest authentication (see Section 6),
>
> Section 6 does not talk about the weaknesses of Digest authentication
> (original RFC reference might give you some security considerations;
> I'm not sure if there's any other document that would talk the
> issue).
Section 6 of draft-sterman references section 4 of RfC 2617. Ok,
too many levels of indirections here.
> Due to the weaknesses of Digest authentication (see Section 6),
> PKI-based authentication and encryption mechanisms have been
> introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633]. However,
>
> Digest, TLS, and S/MIME are not necessarily in direct
> competition with each other, as they provide slightly different
> services. For instance, TLS is hbh, and Digest gives you
> freshness which S/MIME does not. Plus all three protect
> different parts of the SIP message.
>
> Suggestion: soften the above statement a bit.
HTTP Digest used to be the only security mechanism for SIP.
TLS and S/MIME cover the holes that HTTP digest left open.
>> SIP service providers whishing to authenticate their clients have the
>> following options: they can
>> o build a PKI and wait for interopable S/MIME capable SIP
>> implementations,
>> o build a PKI and wait for SIP implementations supporting TLS with
>> client-side certificates,
>> o replace their existing RADIUS infrastructure with DIAMETER
>> [RFC3588], when DIAMETER supports HTTP Digest authentication,
>> o use TLS for server authentication and plaintext passwords (Basic)
>> for client authentication, which can be done with standard RADIUS,
>> o upgrade their existing RADIUS servers with the functionality
>> described in this document
>>
>> PKI solutions only cover authentication, not authorization (EAP could
>> change this, but its use with SIP is not standardized). TLS / Basic
>> authentication works only with the limited number of SIP devices that
>> implement TLS. Basic authentication has been deprecated for SIP in
>> [RFC3261].
>
> Somehow the above arguments feel a bit out of place here. Just
> state that Digest is widely used in SIP, and leave it at that :-)
Some people wanted a motivational section. Some people complained
about that section. I will shorten it.
>> PKI solutions only cover authentication, not authorization (EAP could
>> change this, but its use with SIP is not standardized). TLS / Basic
>> authentication works only with the limited number of SIP devices that
>> implement TLS. Basic authentication has been deprecated for SIP in
>> [RFC3261].
>>
>> Current RADIUS-based AAA infrastructures have been built and debugged
>> over years. Deficiencies of RADIUS have been mitigated with
>> proprietary (ie costly) extensions. Operators are therefore
>> reluctant to replace their RADIUS infrastructure in order to enable a
>> single new authentication mechanism.
>>
> Same as above. And I'm not sure all deficiences have been
> mitigated.
'Deficiencies of RADIUS ..' --> 'Some deficiencies of RADIUS'
>> DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG,
>> DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP,
>> DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that
>> will be assigned by IANA, if this specification becomes a working
>> group or IESG document.
>
> Here's an idea: I'd prefer the attributes in this and the Diameter
> draft to be constructed with the following rules:
>
> (1) Don't invent too many of them. Maybe Dig-Alg, Dig-Auts, Dig-QoP,
> and Dig-Authp could all use the same attribute? They all have
> the same syntax in HTTP (param=value).
Well, I did this for nonce and nextnonce, response and rspauth.
Some reviewers found this ugly:
Miguel Garcia:
"4) I noticed that draft-sterman does not specified a Digest-Nextnonce
attribute, but we have a Digest-Nextnonce AVP in Diameter SIP app. It
seems that draft-sterman reuses Digest-Nonce to transport a nextnonce.
While the mechanism probably works, I would suggest to define a new
Digest-Nextnonce attribute in draft-sterman, since the semantics of
Nonce and Nextnonce are completely different, so they are sent in
different parameters in the Digest header. Is this acceptable?"
Bernard Aboba:
"Also, saving attribute space is not a design goal of this document.
Diameter compatibility *is* a design goal."
And a guy named Jari Arkko wrote on Mo 09.08.2004 :-)
"In general, I'd rather have a larger number of attributes
in a draft than cause problems for translation. Of course
we can build special cases for attributes, but I'd rather
have NASREQ-style completely automatic mapping (attribute =>
AVP from RADIUS space) or at least simple table driven
mapping (attribute => AVP from Diameter space with same
type)."
> (2) If both RADIUS and Diameter are going to define the attributes,
> IMHO it would make sense to allocate them from the RADIUS space
> so a conversion box would not have to map attributes.
>
not easy.
> Alternative idea: use some of the extended RADIUS attribute
> format ideas and allocate the numbers from the Diameter space.
>
This would introduce a new dependency on other drafts.
> (3) Use exactly the set of attributes for the pure digest function
> (I did not check if this is already the case).
+-----+ +-----+ +-----+
> The choice between the server and client generated
> nonces: is there some guidance on how the client knows
> which one to do? if it believes it may have a user that
> does Digest AKA then it should do use the server generated
> scheme? But how would it know this in a roaming case?
If you are expecting AKA users, you have to use server
generated nonces.
[Jari Arkko]
Miguel Garcia wrote:
Sure, these directives have the same syntax, but obviously share different semantics. Further more, we just transport the value of the directive, not the "param=value" pair. Consequently, I don't think all these AVPs can all use the same attribute. How can we distinguish what is being transported?
By looking at what's in front of the '=', which you need
to do for Dig-authp anyway?
But I see your point. I need to think about this before I become convinced, however :-)
I have a question: in Diameter SIP app, all these AVPs are part of parenet grouped AVP. I believe RADIUS does not offer the concept of grouped AVPs. Does it represent a problem if we define a Diameter SIP app grouped AVP that contains RADIUS AVPs. as it is the proposal?
I think it would imply that you'd not use grouped AVP, just
a set of AVPs. Your ABNF would be longer, but otherwise there
are no practical consequences, I think.
Alternative idea: use some of the extended RADIUS attribute
format ideas and allocate the numbers from the Diameter space.
For the time being, I am leaning towards the RADIUS address space.
Me too.
[Jari Arkko]
Beck01, Wolfgang wrote:
Somehow the above arguments feel a bit out of place here. Just
state that Digest is widely used in SIP, and leave it at that :-)Some people wanted a motivational section. Some people complained
about that section. I will shorten it.
Fair enough.
PKI solutions only cover authentication, not authorization (EAP could
change this, but its use with SIP is not standardized). TLS / Basic
authentication works only with the limited number of SIP devices that
implement TLS. Basic authentication has been deprecated for SIP in
[RFC3261].
Current RADIUS-based AAA infrastructures have been built and debugged
over years. Deficiencies of RADIUS have been mitigated with
proprietary (ie costly) extensions. Operators are therefore
reluctant to replace their RADIUS infrastructure in order to enable a
single new authentication mechanism.
Same as above. And I'm not sure all deficiences have been
mitigated.
'Deficiencies of RADIUS ..' --> 'Some deficiencies of RADIUS'
Ok.
DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG,
DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP,
DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that
will be assigned by IANA, if this specification becomes a working
group or IESG document.Here's an idea: I'd prefer the attributes in this and the Diameter
draft to be constructed with the following rules:
(1) Don't invent too many of them. Maybe Dig-Alg, Dig-Auts, Dig-QoP,
and Dig-Authp could all use the same attribute? They all have
the same syntax in HTTP (param=value).Well, I did this for nonce and nextnonce, response and rspauth.
Some reviewers found this ugly:
Miguel Garcia:
"4) I noticed that draft-sterman does not specified a Digest-Nextnonce attribute, but we have a Digest-Nextnonce AVP in Diameter SIP app. It seems that draft-sterman reuses Digest-Nonce to transport a nextnonce. While the mechanism probably works, I would suggest to define a new Digest-Nextnonce attribute in draft-sterman, since the semantics of Nonce and Nextnonce are completely different, so they are sent in different parameters in the Digest header. Is this acceptable?"
Bernard Aboba:
"Also, saving attribute space is not a design goal of this document.
Diameter compatibility *is* a design goal."
And a guy named Jari Arkko wrote on Mo 09.08.2004 :-)
"In general, I'd rather have a larger number of attributes
in a draft than cause problems for translation. Of course
we can build special cases for attributes, but I'd rather
have NASREQ-style completely automatic mapping (attribute =>
AVP from RADIUS space) or at least simple table driven
mapping (attribute => AVP from Diameter space with same
type)."
I can see that I possibly contradicted myself as far
as number of attributes goes :-( Anyway, my main priority is
that the SIP and Diameter versions work with automatic
translation (item 2) and that you and Miguel agree on
the attributes that should be used (item 3). I don't think
the number of attributes is a limiting factor in terms of
available space; you should design the attributes so that
people like the resulting set. My original thought in the
review was that it would be cleaner if the attributes that
looked the same syntactically were transported in the same attribute.
But I understand the argument that the parameters have different
functions, and I guess this is what other people are saying
makes the parameter merging look ugly. I'm OK with that approach
too.
(2) If both RADIUS and Diameter are going to define the attributes,
IMHO it would make sense to allocate them from the RADIUS space
so a conversion box would not have to map attributes.
not easy.
Can you elaborate why this would not be easy?
Alternative idea: use some of the extended RADIUS attribute
format ideas and allocate the numbers from the Diameter space.
This would introduce a new dependency on other drafts.
Yeah, I just included the suggestion for completeness'
sake. I'd prefer the RADIUS space allocation.
(3) Use exactly the set of attributes for the pure digest function
(I did not check if this is already the case).
+-----+ +-----+ +-----+
The choice between the server and client generated
nonces: is there some guidance on how the client knows
which one to do? if it believes it may have a user that
does Digest AKA then it should do use the server generated
scheme? But how would it know this in a roaming case?If you are expecting AKA users, you have to use server
generated nonces.
I guess my question was how do you know you are expecting
AKA users. Is there a fallback in case we were NOT expecting
them but one showed up because our roaming partner started
supporting AKA yesterday?
What does DIAMETER SIP do in this case? Always assume the additional
roundtrip?
[Wolfgang Beck]
1) missing reference
new text:
'Due to the limitations and weaknesses of Digest authentication (see
[RFC2617], section 4 />)..'
2) when to use server generated nonces
added a paragraph in the overview section
[Jari Arkko]
I am happy with the resolutions of everything in
issues 11 & 12, except for two parts:
(1) My understanding is that there's still
one version of at least of the AAA draft and maybe
of both drafts coming due to the attribute merge.
This was part of issue 11, so I'd like to check
the results when the final text is available.
(2) I think we didn't end the discussion on:
Jari wrote:
> The choice between the server and client generated
> nonces: is there some guidance on how the client knows
> which one to do? if it believes it may have a user that
> does Digest AKA then it should do use the server generated
> scheme? But how would it know this in a roaming case?
Wolfgang wrote:
> If you are expecting AKA users, you have to use server
> generated nonces.
Jari wrote:
> I guess my question was how do you know you are expecting
> AKA users. Is there a fallback in case we were NOT expecting
> them but one showed up because our roaming partner started
> supporting AKA yesterday?
(Or am I missing an e-mail?) I also looked through the draft
but did not spot text that deals with this. Can we provide
a server-generated error that says "please try again without
generating your own nonce"? Or is it too late if some message
has already been sent to the user at this point?
There's one more additional thing. Is Section 4 the final result
or will it be modified based on your agreement with Miguel? The
table below still has some mapping for the translation agent.
I think we should be able to do it completely without any
AVP mapping. But I don't dig into this deeper if you say Section
4 is still being worked on.
[Wolfgang Beck]
on http://www.drizzle.com/~aboba/RADEXT/, issue 11 is still marked
as 'open'. Most of this has been addressed in
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-00.txt.
One remaining thing is your concern about the interoperation of RADIUS
clients and servers that may or may not support nonce generation.
Here's a proposal:
"If the RADIUS server generates nonces, its RADIUS clients MUST NOT
try to generate nonces. If the RADIUS server does not generate
nonces, its RADIUS clients MUST generate nonces locally.
If at least one HTTP-style client requires AKA authentication
[RFC3310], the RADIUS server MUST generate nonces and its RADIUS
clients MUST NOT generate nonces locally."
However, if a RADIUS client accidentally chooses a nonce:
"If the RADIUS server does not accept the nonce received in an
Access-Request message but authentication was successful, the RADIUS
server MUST send an Access-Challenge message containing a
Digest-Stale attribute set to 'true' (without quotes). The RADIUS
server MUST add Digest-Nonce, Digest-Algorithm, Digest-Realm, SHOULD
add one or more Digest-Qop and MAY add Digest-Domain, Digest-Opaque
attributes to the Access-Challenge message."
and the RADIUS client will deal with it:
" If the RADIUS client receives an Access-Challenge message in response
to an Access-Request containing a Digest-Nonce attribute, the RADIUS
server did not accept the nonce. If a Digest-Stale attribute is
present in the Access-Challenge and has a value of 'true' (without
quotes), the RADIUS client sends an error (401 or 407) response
containing WWW-/Proxy-Authenticate header with the directive 'stale'
and the digest directives derived from the Digest-* attributes."
If neither RADIUS client nor RADIUS support nonce generation:
" If the RADIUS server receives an Access-Request message with a
Digest-Method and a Digest-URI attribute but without a Digest-Nonce
attribute, it chooses a nonce. [..] If the server cannot choose a
nonce, it replies with an Access-Reject message."
To summarize, we don't want to mix modes but if you do, the behaviour
is predictable. If you RADIUS server supports nonce generation, you
are on the safe side.
Is this sufficient to close the issue?
[Jari Arkko]
Checking from the issue tracker this issue and comparing it against -01. Here's what I found:
Due to the weaknesses of Digest authentication (see Section 6),
Section 6 does not talk about the weaknesses of Digest authentication
(original RFC reference might give you some security considerations;
I'm not sure if there's any other document that would talk the
issue).
Ok.
Due to the weaknesses of Digest authentication (see Section 6),Ok (but a nit: s/The majority of today's SIP clients only supports HTTP digest./
PKI-based authentication and encryption mechanisms have been
introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633]. However,
Digest, TLS, and S/MIME are not necessarily in direct
competition with each other, as they provide slightly different
services. For instance, TLS is hbh, and Digest gives you
freshness which S/MIME does not. Plus all three protect
different parts of the SIP message.
Suggestion: soften the above statement a bit.
SIP service providers whishing to authenticate their clients have the following options: they can o build a PKI and wait for interopable S/MIME capable SIP implementations, o build a PKI and wait for SIP implementations supporting TLS with client-side certificates, o replace their existing RADIUS infrastructure with DIAMETER [RFC3588], when DIAMETER supports HTTP Digest authentication, o use TLS for server authentication and plaintext passwords (Basic) for client authentication, which can be done with standard RADIUS, o upgrade their existing RADIUS servers with the functionality described in this document
PKI solutions only cover authentication, not authorization (EAP could
change this, but its use with SIP is not standardized). TLS / Basic
authentication works only with the limited number of SIP devices that
implement TLS. Basic authentication has been deprecated for SIP in
[RFC3261].
Somehow the above arguments feel a bit out of place here. Just
state that Digest is widely used in SIP, and leave it at that :-)
Ok.
PKI solutions only cover authentication, not authorization (EAP could change this, but its use with SIP is not standardized). TLS / Basic authentication works only with the limited number of SIP devices that implement TLS. Basic authentication has been deprecated for SIP in [RFC3261].
Current RADIUS-based AAA infrastructures have been built and debugged
over years. Deficiencies of RADIUS have been mitigated with
proprietary (ie costly) extensions. Operators are therefore
reluctant to replace their RADIUS infrastructure in order to enable a
single new authentication mechanism.
Same as above. And I'm not sure all deficiences have been
mitigated.
Ok.
DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG,
DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP,
DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that
will be assigned by IANA, if this specification becomes a working
group or IESG document.Here's an idea: I'd prefer the attributes in this and the Diameter
draft to be constructed with the following rules:
(1) Don't invent too many of them. Maybe Dig-Alg, Dig-Auts, Dig-QoP,
and Dig-Authp could all use the same attribute? They all have
the same syntax in HTTP (param=value).
(2) If both RADIUS and Diameter are going to define the attributes,
IMHO it would make sense to allocate them from the RADIUS space
so a conversion box would not have to map attributes.
Alternative idea: use some of the extended RADIUS attribute
format ideas and allocate the numbers from the Diameter space.
(3) Use exactly the set of attributes for the pure digest function
(I did not check if this is already the case).
Ok, this is mostly as I wanted it to be in the Radius document. However, I wonder if the current Diameter document should use individual AVPs instead of Grouped AVP:
SIP-Authenticate ::= < AVP Header: xx12 >
{ Digest-Realm }
{ Digest-Nonce }
[ Digest-Domain ]
[ Digest-Opaque ]
[ Digest-Stale ]
[ Digest-Algorithm ]
[ Digest-QoP ]
[ Digest-HA1]
* [ Digest-Auth-Param ]
* [ AVP ]Because translating this grouped AVP appears to require additional work from a gateway, no? Bernard/Miguel, can you file on issue to the Diameter document on this.
+-----+ (1) +-----+ +-----+
| |==========>| | (2) | |
| | | |---------->| |
| | | | (3) | |
| | (4) | |<----------| |
| |<==========| | | |
| | (5) | | | |
| |==========>| | | |
| A | | B | (6) | C |
| | | |---------->| |
| | | | (7) | |
| | | |<----------| |
| | (8) | | | |
| |<==========| | | |
+-----+ +-----+ +-----+
The choice between the server and client generated
nonces: is there some guidance on how the client knows
which one to do? if it believes it may have a user that
does Digest AKA then it should do use the server generated
scheme? But how would it know this in a roaming case?
Other ideas?
This has been raised by Bernard too, apparently we didn't do good enough job to fix it.
Conclusion: close issue 11. Bernard's roaming issue still needs to be kept alive, and I'm suggesting one new issue on the Diameter SIP document.
Issue 12: Editorial Issues
Submitter: Jari
Arkko
Submitter email address:
Jari.Arkko@piuha.net
Date first submitted: September 2, 2004
Reference:
http://ops.ietf.org/lists/radiusext/2004/msg00708.html
Document: SIP-03
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of
issue:
Basic and Digest authentication schemes are widely used in protocols
such as SIP and HTTP . RADIUS is a protocol for back end
s/HTTP ./HTTP./
support HTTP digest authentication only. Its interopability with a
back-end authentication protocol such as RADIUS is needed.
s/interopability/interoperability/
o build a PKI and wait for interopable S/MIME capable SIP
implementations,
s/interopable/interoperable/
SIP service providers whishing to authenticate their clients have the
following options: they can
s/whishing/wishing/
Basic and Digest authentication schemes are widely used in protocols
such as SIP and HTTP . RADIUS is a protocol for back end
Sterman, et al. Expires November 30, 2004 [Page 1]
Internet-Draft RADIUS Extension for Digest Authentication June 2004
authentication. RADIUS supports Basic authentication natively, as
well as several other authentication schemes, such as CHAP, but does
not support Digest authentication scheme. This document describes an
extension to RADIUS for Digest authentication and provides a scenario
of Digest user authentication.
What abbreviations need to be expanded in the abstract (or possibly
also in the title)? The used acroynyms are: RADIUS, SIP, HTTP, CHAP.
[Jari Arkko] (in response to a proposal from Wolfgang Beck):
What abbreviations need to be expanded in the abstract (or possibly
also in the title)? The used acrynyms are: RADIUS, SIP, HTTP, CHAP.RfC 2866 (RADIUS Accounting) uses the abbreviation
RfC 2617 (HTTP Digest) uses the abbreviation, too.
CHAP has already been eliminated from the abstract.
Proposal:
"Several protocols use HTTP digest authentication. This document specifies
an extension to RADIUS that allows a RADIUS client in a server, upon
reception of a request, retrieve and compute Digest authentication
information from a RADIUS server. Additionally, a scenario describing
the authentication of a user emiting a request is provided."
Ok.
Proposed Resolution: Accept
Issue 13: Inconsistencies with Diameter-CC
Submitter: David Mariblanca
Submitter email address:
david.mariblanca@ericsson.com
Date first submitted: September 13, 2004
Reference:
http://ops.ietf.org/lists/radiusext/2004/msg00719.html
Document:
ChargeUID-00
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Hi Farid and others,
for these purposes, in 3GPP it's used the
Subscription-Id AVP from the Diameter Credit Control application. It is a
grouped AVP with these values:
END_USER_E164
0
The identifier is in international E.164
format (e.g. MSISDN),
according to the ITU-T E.164
numbering plan as defined in [E164]
and [CE164].
END_USER_IMSI
1
The identifier is in
international IMSI format, according to the
ITU-T
E.212 numbering plan as defined in [E121] and [CE121].
END_USER_SIP_URI
2
The identifier is in the form of a SIP URI
as defined in [SIP].
END_USER_NAI
3
The identifier is in the form of a Network
Access Identifier as
defined in [NAI].
END_USER_PRIVATE
4
The Identifier is a credit-control
server private identifier.
If an attribute for a similar purpose is to
be created for RADIUS, shouldn't it be a mapping from this one ?
[John Loughney] Just to follow-on to David. This is what is defined in the
Diameter CCA,
and is used by 3GPP for charging. If there are additional
values that
would be useful to add, it would be consistent with the Diameter
CC application to add more.
If we could align the proposed draft with the
Diameter CC app, that would be great.
Proposed Resolution: Discuss
Issue 14: Review of Chargeable User Identity
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: September 20, 2004
Reference:
Document: ChargeUID-00
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
In certain authentication methods such as, EAP-PEAP or EAP-TTLS,
EAP-SIM, and EAP-AKA, the true identity of the subscriber can be
hidden
from the RADIUS AAA servers outside the subscriber’s home
network. In these
methods the User-Name(1) attribute contains an
anonymous identity (e.g.,
anonymous@example.com) sufficient to
route the RADIUS packets to the home
network but otherwise
insufficient to identify the subscriber. While this
mechanism is
good practice there are situations where this creates problems:
[BA] "anonymous@example.com" is NOT a valid use of NAI privacy, at
least as defined in RFC 2486bis. A better example would be
"@example.com".
- In certain roaming situations intermediaries and visited
network require
to be able to correlate an authentication session
with a user identity known to the user’s home network for fraud
detection and revenue assurance. For example, a broker may
require to
implement a policy where by only one session is allowed
per user entity, or
third party billing brokers may require to
match accounting records to a
user identity.
[BA] This paragraph is confusing to me. I think the issue
is not
about correlation with home network identities, but satisfaction of
intermediary and local network policies. In particular, isn't the
problem determining whether the local or intermediate provider is
likely
to be